This article ignores pretty much all modern trends. Developers don't use the language tools or libraries that ship with the OS. They often deploy using containers or by compiling static binaries...
This article ignores pretty much all modern trends. Developers don't use the language tools or libraries that ship with the OS. They often deploy using containers or by compiling static binaries to avoid OS dependencies as much as possible. Browsers do their own security updates. Web applications ship updates more and more frequently.
How I wish this were true. I see people doing this all the time, despite my attempts to educate. I see this especially on StackOverflow. And folks are upset that the vendor changes things for what...
Developers don't use the language tools or libraries that ship with the OS.
How I wish this were true. I see people doing this all the time, despite my attempts to educate. I see this especially on StackOverflow. And folks are upset that the vendor changes things for what they need (i.e. to work with other packages) rather than what the end-user developer needs. Sigh.
In addition to ignoring nonfree software, Drew ignores the fact that it's incredibly difficult to get your package into popular distributions like Debian. Yay great! Relying on more volunteers to...
In addition to ignoring nonfree software, Drew ignores the fact that it's incredibly difficult to get your package into popular distributions like Debian.
Thankfully, each distro includes its own set of volunteers dedicated to this specific job: packaging software for the distribution and making sure it conforms to the norms of the target environment.
Yay great! Relying on more volunteers to do an arcane and annoying job.
Drew doesn't really cover the reasons developers distribute their own software, either, which feels like a significant omission.
And to users: install packages from your distro’s repositories, and learn how its packaging process works so you can get involved when you find a package missing.
Great - so instead of getting developers (who are at least presumably "technical") to package their software, we're now asking users of that software to learn both how the software works and how to get it into distributions.
It’s not as hard as it looks,
Bullshit. I have tried at least three times to learn how to "properly" build a .deb, and have come away confused each time.
Studying and reading about technology, I frequently remember my rowing coach from twenty years ago. He was a great, experienced rower, and had little patience to teach me the fundamentals. He...
Great - so instead of getting developers (who are at least presumably "technical") to package their software, we're now asking users...
Bullshit. I have tried at least three times to learn how to "properly" build a .deb, and have come away confused each time.
Studying and reading about technology, I frequently remember my rowing coach from twenty years ago. He was a great, experienced rower, and had little patience to teach me the fundamentals. He couldn't understand why I was unable to keep the racing shell straight, causing me to taste the foul water three times.
Rowing was so natural to him that he simply forgot that his knowledge was not universal.
I generally agree with the points laid out by the article. The author's perspective as someone who is writing about open source operating systems... proprietary software is mostly irrelevant. So...
I generally agree with the points laid out by the article.
The author's perspective as someone who is writing about open source operating systems... proprietary software is mostly irrelevant.
So the main point of contention seems to be regarding the speed of deployment. But the author makes a very valid point: The distros should handle it.
Debian is immensely popular because it is slow to add new software. That stability is a feature, not a bug. Ubuntu and other variants of Debian release faster for end users who need it.
Even faster options are out there. Arch deploys very quickly, but stability can suffer. This is why I run OpenSuse Tumbleweed...it is rolling like Arch, but is gated by a huge automated test suite that prevents releasing horribly broken updates.
Browsers mostly need auto-updates on Windows because prior to Windows 10 there wasn't a centrally managed repository at all, and even Microsoft's is lackluster. On most Linux distros I've used, Firefox and Chromium rely on the OS to update it.
In short, if you're developing open-source software, release tarballs and insure your build process is smooth enough for easy deployment across any distro. Users will either wait for their distro, build it themselves, or switch to a distro that better suits their needs.
Separation of development and deployment applies to virtually any software deployment by an organization. When Developer and Deployer are different people there are better opportunities for auditing, and insures smoother deployments. Yes, deployment can and should be automated, but the person responsible for writing that deployment should be a different person than the developer.
This article ignores pretty much all modern trends. Developers don't use the language tools or libraries that ship with the OS. They often deploy using containers or by compiling static binaries to avoid OS dependencies as much as possible. Browsers do their own security updates. Web applications ship updates more and more frequently.
How I wish this were true. I see people doing this all the time, despite my attempts to educate. I see this especially on StackOverflow. And folks are upset that the vendor changes things for what they need (i.e. to work with other packages) rather than what the end-user developer needs. Sigh.
In addition to ignoring nonfree software, Drew ignores the fact that it's incredibly difficult to get your package into popular distributions like Debian.
Yay great! Relying on more volunteers to do an arcane and annoying job.
Drew doesn't really cover the reasons developers distribute their own software, either, which feels like a significant omission.
Great - so instead of getting developers (who are at least presumably "technical") to package their software, we're now asking users of that software to learn both how the software works and how to get it into distributions.
Bullshit. I have tried at least three times to learn how to "properly" build a .deb, and have come away confused each time.
You don't say.
Studying and reading about technology, I frequently remember my rowing coach from twenty years ago. He was a great, experienced rower, and had little patience to teach me the fundamentals. He couldn't understand why I was unable to keep the racing shell straight, causing me to taste the foul water three times.
Rowing was so natural to him that he simply forgot that his knowledge was not universal.
I generally agree with the points laid out by the article.
The author's perspective as someone who is writing about open source operating systems... proprietary software is mostly irrelevant.
So the main point of contention seems to be regarding the speed of deployment. But the author makes a very valid point: The distros should handle it.
Debian is immensely popular because it is slow to add new software. That stability is a feature, not a bug. Ubuntu and other variants of Debian release faster for end users who need it.
Even faster options are out there. Arch deploys very quickly, but stability can suffer. This is why I run OpenSuse Tumbleweed...it is rolling like Arch, but is gated by a huge automated test suite that prevents releasing horribly broken updates.
Browsers mostly need auto-updates on Windows because prior to Windows 10 there wasn't a centrally managed repository at all, and even Microsoft's is lackluster. On most Linux distros I've used, Firefox and Chromium rely on the OS to update it.
In short, if you're developing open-source software, release tarballs and insure your build process is smooth enough for easy deployment across any distro. Users will either wait for their distro, build it themselves, or switch to a distro that better suits their needs.
Separation of development and deployment applies to virtually any software deployment by an organization. When Developer and Deployer are different people there are better opportunities for auditing, and insures smoother deployments. Yes, deployment can and should be automated, but the person responsible for writing that deployment should be a different person than the developer.