>I mean, just look at HN for examples. Quite literally yesterday it happened again: Heroku decided to turn off all old free apps. That's a whole bunch of my old apps that are about to deprecate and break unless I do some work on them.
Yeah, pretty short-sighted of you to go out of your way to design those systems in a way that is dependent on a single company hosting it.
>I suppose you could argue that some apps are "finished", but I tend to see those as a rather small subset of all apps - things like single-use command-line utilities, say, like grep and awk. It's hard for me to fathom Photoshop ever being finished
In an ideal computing environment, the functionalities of a single bloated program like adobe photoshop are completely encompassed by an environment of general-purpose utilities in a way that is analogous to unix shell programs that can interact to perform a variety of tasks.
Modern operating systems are intentionally designed in a way that promotes the commercialization of software. For example, why is it that all third-party software on iOS or android is packaged into distinct, sandboxed "apps" each with their own accompanying icons and whatnot? It's clear that the ability for these "apps" to perform any real inter-process communication is hampered, because the boundaries of the apps represent the boundaries of different competing commercial entities. It is sort of like conway's law, but in reverse: by enforcing a certain structure on software that is distributed, you are selecting for a particular corporate development structure. This analogy goes much deeper than what I can current find the words for. The whole system is quite insidiously woven together.
It is impossible to run any sort of background process (for example, a daemon) in a way that is transparent to other running processes, but it does allow apps to make outgoing connections. This makes the user dependent on an intermediate to provide inter-app communication as a sort of internet-based service.
So I hear you say that software has to compete with the endless "upgrades" of its competitors. I think we have almost never seen a market in which free software based on the unix philosophy has actually competed on its own terms. What we've seen is a market where free software competes on a commercial basis- in producing a distinct, marketable product (as opposed to an environment of inter-working tools) that is comparable to an existing product such that consumers are familiar with it. The unix shell environment is a rare example of an actually good idea coming out of the commercial software, and it's a major foothold for free software that has continued that legacy.
>But this is exactly what vulnerabilities do. One day, there isn't Heartbleed. The next day there is.
If a tree falls in the middle of a forest and no one hears it, does it make a sound?
If there's a bug in software but no one uncovers it, is it a vulnerability? Apparently not according to you.
There would be no heartbleed if there was no implementation of the mostly-useless heartbeat faculty.
There would be no log4jshell if there was no implementation of the bloated JNDI crap.
You are correct, this is exactly what happens when programmers include many useless, bloated, and unvetted dependencies in their project.
Here is the way I see it: At some point you will reach a point in your work where the utility-to-complexity tradeoff will taper off. There is an ideal version of every program that is bug-free and at the plateu of this utility-to-complexity curve. The purpose of all programming is to get close enough to the ideal system and finish- to make something that works well reliably.
Saying that one must continuously revise a program forever to account for new features or vulnerabilities or service providers is like saying that you should continuously revise a book forever because you need to add another chapter or fix another typo or move to another publisher because Heroku stopped printing your book. The goal of writing is to produce a useful-enough book built on sound knowledge, if you are producing something that you think constantly deserves to be revised then you are incompetent- either because you cannot recognize a finished product or because you cannot produce one.
The reason why commercial software is often updated with useless and inane features (much like a college textbook!) obviously serves a much more sinister motive than what you've described here.
>People have inserted themselves as middlemen because servers require upkeep, and up-keeping a server takes the time of an experienced professional. They need to be patched for vulns (again), maybe you need to swap out your SSD because it finally ran out of writes, or any in a litany of other problems.
I see the fact that a service is critically dependent on a single server or maintainer as a design failure. Software should allow users to be more self-sufficient, not less. These centralized systems make you reliant on some sysadmin or someone who essentially performs a "useless job". Check out that book I linked earlier. It's an interesting read.
"It is difficult to get a man to understand something, when his salary depends on his not understanding it."
>> the fact that a service is critically dependent on a single server or maintainer as a design failure. Software should allow users to be more self-sufficient, not less.
Software allows users to be as self-sufficient or not, depending on their skills and resources. There is room for a whole spectrum of users, and obviously as developers we fall on that spectrum as well.
Self suffiency, in any area, is expensive in time, and money. I can grow my own food by buying the land and devoting all day to farming. I'm self sufficient, but I don't have time for anything else.
Equally I can choose to spend time running my own servers. I can buy hardware, learn many things, make mistakes, but be self sufficient.
However all that time spent is time I'm not focusing on my business. If my cousin runs a school, they want a "system that just works". They aren't interested in being self-sufficient. They don't have the time, or money, to (safely) host their own software. They are too busy adding value to their business elsewhere.
(most) OSS to some extent solves a problem that only very few people have. It caters to those who are time rich but cash poor. Most people though are time poor, and can easily find cash to make problems go away.
Adobe wins over Gimp because it does more, faster, thus saving the user time. Its a lot easier to find money than time, so paying the subscription is trivial. If it saves an hour a month, you're ahead even at minimum wage levels.
Of course there are those who value self-sufficiency, who seek out solutions that reduce, or remove, the supply chain. These folk exist in every part of society, and it is a perfectly good approach.
But it is worth understanding that this is a tiny subset of people. Most buy their food in a shop. Most are just using their computer to perform tasks. They have no more desire to write their own code, or host their own server, than they do to grow their own food.
Yeah, pretty short-sighted of you to go out of your way to design those systems in a way that is dependent on a single company hosting it.
>I suppose you could argue that some apps are "finished", but I tend to see those as a rather small subset of all apps - things like single-use command-line utilities, say, like grep and awk. It's hard for me to fathom Photoshop ever being finished
In an ideal computing environment, the functionalities of a single bloated program like adobe photoshop are completely encompassed by an environment of general-purpose utilities in a way that is analogous to unix shell programs that can interact to perform a variety of tasks.
Modern operating systems are intentionally designed in a way that promotes the commercialization of software. For example, why is it that all third-party software on iOS or android is packaged into distinct, sandboxed "apps" each with their own accompanying icons and whatnot? It's clear that the ability for these "apps" to perform any real inter-process communication is hampered, because the boundaries of the apps represent the boundaries of different competing commercial entities. It is sort of like conway's law, but in reverse: by enforcing a certain structure on software that is distributed, you are selecting for a particular corporate development structure. This analogy goes much deeper than what I can current find the words for. The whole system is quite insidiously woven together.
It is impossible to run any sort of background process (for example, a daemon) in a way that is transparent to other running processes, but it does allow apps to make outgoing connections. This makes the user dependent on an intermediate to provide inter-app communication as a sort of internet-based service.
So I hear you say that software has to compete with the endless "upgrades" of its competitors. I think we have almost never seen a market in which free software based on the unix philosophy has actually competed on its own terms. What we've seen is a market where free software competes on a commercial basis- in producing a distinct, marketable product (as opposed to an environment of inter-working tools) that is comparable to an existing product such that consumers are familiar with it. The unix shell environment is a rare example of an actually good idea coming out of the commercial software, and it's a major foothold for free software that has continued that legacy.
>But this is exactly what vulnerabilities do. One day, there isn't Heartbleed. The next day there is.
If a tree falls in the middle of a forest and no one hears it, does it make a sound? If there's a bug in software but no one uncovers it, is it a vulnerability? Apparently not according to you.
There would be no heartbleed if there was no implementation of the mostly-useless heartbeat faculty. There would be no log4jshell if there was no implementation of the bloated JNDI crap. You are correct, this is exactly what happens when programmers include many useless, bloated, and unvetted dependencies in their project.
Here is the way I see it: At some point you will reach a point in your work where the utility-to-complexity tradeoff will taper off. There is an ideal version of every program that is bug-free and at the plateu of this utility-to-complexity curve. The purpose of all programming is to get close enough to the ideal system and finish- to make something that works well reliably.
Saying that one must continuously revise a program forever to account for new features or vulnerabilities or service providers is like saying that you should continuously revise a book forever because you need to add another chapter or fix another typo or move to another publisher because Heroku stopped printing your book. The goal of writing is to produce a useful-enough book built on sound knowledge, if you are producing something that you think constantly deserves to be revised then you are incompetent- either because you cannot recognize a finished product or because you cannot produce one.
The reason why commercial software is often updated with useless and inane features (much like a college textbook!) obviously serves a much more sinister motive than what you've described here.
>People have inserted themselves as middlemen because servers require upkeep, and up-keeping a server takes the time of an experienced professional. They need to be patched for vulns (again), maybe you need to swap out your SSD because it finally ran out of writes, or any in a litany of other problems.
I see the fact that a service is critically dependent on a single server or maintainer as a design failure. Software should allow users to be more self-sufficient, not less. These centralized systems make you reliant on some sysadmin or someone who essentially performs a "useless job". Check out that book I linked earlier. It's an interesting read.
"It is difficult to get a man to understand something, when his salary depends on his not understanding it."