161–170 of 235 posts
Earlier quoted context omitted.
Starting by having systems programming languages that actually have proper strings, arrays and bounds checking.
What are some of those languages? I'm curious to learn more.
Also Pascal and BASIC compilers with several extensions, e.g. VMS Pascal and VMS BASIC.
I'm sorry, but this paragraph proves that the author has not fully understood the purpose of enterprise distributions.
The primary selling point is not the stability of the software, but the stability of the API and ABI. There is closed source software such as SAP that is compiled against the ABI of RHEL and SLES. And lots of expensive enterprise hardware ships Linux kernel drivers in binary form only, so that a stable, i.e. never-changing kernel ABI is required. Examples for such hardware is the SGI UV series whose drivers come in binary form only and therefore the hardware is supported on enterprise distributions only.
Both RedHat and SUSE put a lot of effort into keeping their API and ABI stable, so that enterprise customers are guaranteed that no distribution update is going to break the software that they're running on the hardware they're using.
Also, when you deploy Linux on hundreds or thousands of clients, a rolling release distribution would be a pure nightmare. Given the large amount of clients and applications, there will always be a combination of applications and use-cases that will break after a distribution package was updated to a completely new upstream version.
Companies don't want software that changes all the time since they want to control the time for an update rollout themselves.
> The Case for Oracle Linux I did not see that twist coming. Strangely, the author makes a good point. Oracle or not, sticking closer to the upstream kernel is not a bad way to manage an “enterprise” kernel. Maybe we’ve all been too willing to sit back and accept how RHEL does kernels as “the way”.
Also kernel updates breaking drivers is a thing.
So there's definitely value with frozen kernel version. And its almost the same value as frozen software. It just works and it won't break after update.
Earlier quoted context omitted.
I didn’t see a particular appeal for trust in the OP. Not mentioning anything about non association would have seemed weirder. Sometimes it’s interesting to read or hear from someone with a high trust score. Other times it’s interesting to read or hear a line of reasoning without - or even negative - trust score. Only going by trust arguably is one of the fundamental problems with tribalism and echo chambers.
>I didn’t see a particular appeal for trust in the OP It's implicit within the statement that they don't have a conflict of interest. Trust is precisely what conflicts of interest are about, where their presence often (maybe not always) introduces the need to be more skeptical of the person's motives, i.e., less trust.
»Defenders will counter that this is a necessary tradeoff – you can’t have both stability and being fully up-to-date on security fixes. I’m not convinced that’s true as there are other Linux distributions that have shown you can have both. Rolling release distributions like OpenSUSE Tumbleweed follow upstream much more closely while still maintaining stability through thorough automated testing. Additionally, distrib…
Vs, the other LTS distros that just track the upstream LTS kernel. That kernel both breaks things, as well as is "old" because its only generally taking security and bug fixes.
Earlier quoted context omitted.
The difference is: If there is a weekly breakage on a weekly update, delaying with it is just part of the process and timed in. If you only update every few years, each update becomes a full project distracting from and conflicting with other projects.
> The difference is: If there is a weekly breakage on a weekly update, delaying with it is just part of the process and timed in. That entirely depends on your operations model. There's a difference between, say, a nuclear power plant and a colo web hosting shop. With the latter, sure, no problem risking "minor" weekly breakage. With the former, I'd much rather have scheduled, heavily tested and carefully monitored m…
There is another problem that wasn't covered in the article. The 10+ years of stability leads to behaviors and outcomes that remind me of the long-lived SSL certificate problem. Updating is done so infrequently that the "how?" is forgotten. As the 10 year support limit approaches, most of the old team members who did it last time are gone, tech debt is through the roof, few people know where everything is or how to b…
That is a good point, however I've not heard of too many cases where organizations intentionally skip RHEL releases. Systems that are being actively developed do regularly upgrade through each RHEL release, and the 10 year support just lets them be lazy about how quickly they do so. The only systems I see intentionally riding out the 10+ year support are deprecated systems that are already announced to sunset by the…
Earlier quoted context omitted.
Think of all the places Linux runs. Planes, trains, and automobiles. Medical equipment. So many other places. Many places that don't have readily available network access. Yet, many "enterprises" need support here. If a medical device or train works but needs support for years and years, should someone be constantly updating Linux? What about the software that runs on Linux and is tested there? Considering just the m…
> If a medical device or train works but needs support for years and years, should someone be constantly updating Linux? What about the software that runs on Linux and is tested there? Yes. If you have embedded software in the field and it is running on hardware that has not reached its EOL, then you absolutely should be fixing bugs and vulnerabilities, doubly so when that hardware is attached to any kind of network,…
Ok, I'll be the unpopular person here.
Some bugs, even security ones: are ok.
I know that a very significant amount of software is mature these days, but sometimes upgrading causes different bugs, which are either harder to diagnose or even potentially more deadly.
I work in gamedev though, releases are tradeoffs with which bugs we accept.
It is very frequently the case that fixing one bug will incur several other bugs, it's just a case of understanding if they're worse or not.
For example: I don't care that my TV will have a 1/100 crash when launching the settings. I will just launch settings again-
Coincidentally: having everything constantly updating and internet connected is counter-intuitive. I used to spend entire evenings waiting for my PS4 to install new software on itself, but the PS2 (which contained many bugs!) worked much more often.
Earlier quoted context omitted.
Think of all the places Linux runs. Planes, trains, and automobiles. Medical equipment. So many other places. Many places that don't have readily available network access. Yet, many "enterprises" need support here. If a medical device or train works but needs support for years and years, should someone be constantly updating Linux? What about the software that runs on Linux and is tested there? Considering just the m…
> If a medical device or train works but needs support for years and years, should someone be constantly updating Linux? What about the software that runs on Linux and is tested there? Yes. If you have embedded software in the field and it is running on hardware that has not reached its EOL, then you absolutely should be fixing bugs and vulnerabilities, doubly so when that hardware is attached to any kind of network,…
I mostly agree, but the severe punishment for not keeping software or services updated and running should be to release as much of the software as you own and a full hardware spec, well before you turn off the lights. People have to be allowed to get out of a business.
There is another problem that wasn't covered in the article. The 10+ years of stability leads to behaviors and outcomes that remind me of the long-lived SSL certificate problem. Updating is done so infrequently that the "how?" is forgotten. As the 10 year support limit approaches, most of the old team members who did it last time are gone, tech debt is through the roof, few people know where everything is or how to b…
That is a good point, however I've not heard of too many cases where organizations intentionally skip RHEL releases. Systems that are being actively developed do regularly upgrade through each RHEL release, and the 10 year support just lets them be lazy about how quickly they do so. The only systems I see intentionally riding out the 10+ year support are deprecated systems that are already announced to sunset by the…