Article quite a mess and, honestly, largely devoid of content. For starters, complains that SL should've continued because other community options might eventually be discontinued/change (as happened with CentOS). Like, duh. By this reasoning every effort should be duplicated to guard against the possibility that one option might disappear. In the end though all those RHEL rebuilds depend on Red Hat maintaining RHEL. The article never notes this and indirectly equalizes the effort and existence of a a genuinely independent community-driven distro (Debian, that CERN decided to move their accelerator-control computers) and RHEL rebuild (e.g., AlmaLinux, that CERN will keep the rest of infrastructure on, e.g. data centers, compute farms, etc). And here's the misguided part. If SL as still active it'll have been necessary to recompile numerous upstream RHEL source packages to remove the microarchitecture restrictions. This will've turned SL to entire new, independently maintained distro. The thing they wanted to avoid.
Well, it's not an unreasonable assumption that RHEL will continue to be maintained even if we don't go down the whole CentOS path which I won't on a public forum. But, yes, there are always dependencies. There's certainly no guarantees that any of the ~rebuilds will still be around in n years.
lo and behold, a 1000 word sample comes back in Pangram as AI generated. This should not be worth anyone's time (and maybe you have spent more time on your comment than the author did in their blogpost).
I'm surprised it doesn't annoy the author. I use LLMs extensively for code but I cannot stand their natural language output a lot of the time, it always reminds me of that example from Orwell's Politics and the English Language:
Now that I have made this catalogue of swindles and perversions, let me give another example of the kind of writing that they lead to. This time it must of its nature be an imaginary one. I am going to translate a passage of good English into modern English of the worst sort. Here is a well-known verse from Ecclesiastes:
> I returned and saw under the sun, that the race is not to the swift, nor the battle to the strong, neither yet bread to the wise, nor yet riches to men of understanding, nor yet favour to men of skill; but time and chance happeneth to them all.
Here it is in modern [1946] English:
> Objective consideration of contemporary phenomena compels the conclusion that success or failure in competitive activities exhibits no tendency to be commensurate with innate capacity, but that a considerable element of the unpredictable must invariably be taken into account.
A 2026 version of this phenomenon would instead be:
> Here's the thing: success isn't just about talent — it's about timing. The fastest runner doesn't always win. The strongest army doesn't always prevail. Ultimately, life is a complex interplay of skill and chance, and recognizing that can be both humbling and empowering.
That's actually Claude and you can see precisely why the resulting vague language is bad; the LLM has changed the actual meaning of the passage from a sober reflection on the futility of expecting natural justice from the universe to one that emphasises skill and timing, exactly what the author is telling us is futile.
Admittedly the slop text LLMs produce in the 21st century isn't the same as the 20th century slop humans produced, but there's definitely a family resemblance in my view! Orwell was concerned with the idea language can be used to curtail thought, and he disliked what we'd now call slop because it merely gestures at a thought without actually instantiating it directly.
The whole essay is worth a read in my view, it remains highly relevant.
Subsection titles, and how the text flows. When I read these kinds of LLM-Powered posts, I feel the same thing. Like remembering the taste of some canned food which was not great, but I had to consume to stay alive. It feels like junk food, not optimized to taste great, but doesn't reek of machine oil either. A price-optimized, slightly unhealthy substance which is somewhat compatible with my body because of food engineering magic.
These posts are not only a waste of time, but it also makes me feel deceived and betrayed. Why this is important? Because it's the honest take and bears the load of the reality of the post.
Please, don't make me read something you didn't write.
Disclosure: This post, incl. llm-sounding paragraph is typed by a human. All of the keystrokes are 100% human and made possibe by burning ATPs and firing tiny lightning bolts across some brain cells. No humans are harmed or GPU hours are burned in this comment.
Total water consumption: 50ml of cold spring water, because I'm thirsty.
I just don't see the "LLM-speak" here at all, for example. And I'm very tired of people who throw around the LLM-power critique as an easy criticism when there's no clear basis for it. It's lazy and stupid.
There are certain styles for a post like this that some people may not like but things like subheads and what would be, by historical standards somewhat clipped writing are just how writing in this content is mostly encouraged theese days. I'd just add that when people do post long-form New Yorker pieces there's plenty of whining about getting to the point.
I think this mostly boils down to experience with writing styles. I am an avid reader, albeit mostly read in Ukrainian/Russian, but I can confidently tell whether some paragraph was written by Platonov or Nabokov or Zhadan or Sorokin; even when the guys are stylizing their texts (Sorokin does this all the time) there are still subtle things in how text is composed that tell you who wrote it. If my reading menu was mostly contemporary blogs, probably I would be less sensitive to distinct writing styles.
The first tech book I did with a publisher, I was pretty much told that I needed to break things down more with subheads and the like. And I was already doing some writing of whitepapers and blogs with my then-employer which had a somewhat similar structured style. Certainly very different from Dickens, Trollope, Collins, etc.
I'm not making a value judgement, but modern writing on technical topics has generally been steered toward digestible formats whether or not LLMs are involved.
Until I left, I was on social media and style committees at my former employer and there was a lot of data-based evidence around keeping things (in various multimedia formats) shorter and easier to consume. In fact, we mostly got away from writing white papers at all in favor of shorter pieces.
I don't disagree with you that contemporary technical writing, editing
and technical blogs were converging to what is known as llm style even before provisioning of llms. In the end, llm
were trained on these recent writing and recent blogs and this is why similarity exists. Still one can find some technical writing that stands aside and has very distinct style without compromising on clarity/digestability, i.e. Martin Fowler, Armin Ronacher, Michell Hashimoto write very differently from each other and Claude, but their content is always sharp and very much digestable. Take this paragraph by Claude
> Scientific Linux gave the scientific community its own implementation of a RHEL-compatible computing environment. More importantly, it kept alive the people, processes, infrastructure, and institutional knowledge needed to maintain one.
> That capability had option value. You might not need to exercise the option this year, or even this decade. It becomes valuable when the assumptions underneath your primary platform change. Those assumptions changed surprisingly quickly.
Can't imagine this lengthy style with paraphrases coming from Hashimoto or Fowler. Yes, it can appear not only in llm writing, but also in some heavily edited o'reilly book, sure, but I miss the times when tech blogs and o'reilly books were different.
Why would a person use RHEL in the first paragraph, making the assumption that people already know what that means. Then a few paragraphs later, write the full name?
Theoretically a mistake a person could make, but it feels a bit unlikely in this context to me.
Also, the repeating pattern of Prompt:List through multiple paragraphs.
"Scientific Linux was never simply "RHEL with a different wallpaper." It gave the scientific community an institutionally independent implementation of the Enterprise Linux platform."
You obviously can't get proof. But there are enough stylistic tells to confidently say that AI was substantially involved in writing this. It's annoying to read. That's enough to dislike AI writing IMO.
If I remember correctly, the reason why Scientific Linux was RHEL based instead of Debian because RedHat was a company and can pay them for services.
We used to run it on our Grid nodes, and while it was not bad, it was not that smooth, either. It was a little kludgy but worked if you didn't diverge from the happy paths much.
Now Debian has Extended Long Time Support via Freexian, I believe CERN has enough confidence to use Debian instead of RH family, and that will make lives of some people way easier. Debian is still easier to manage than RH based systems, and .deb is a really good package manager, and is arguably more sophisticated than RPM.
> Debian is still easier to manage than RH based systems, and .deb is a really good package manager, and is arguably more sophisticated than RPM.
I realize I'm veering a bit off-topic :), but I've used Debian for a long while, but I do wonder how is that deb is more sophisticated than rpm?
The one feature I remember (a long time ago) rpm being able to install the different versions of the same package, although I suppose this in practice would only work for packages made for this, and libraries would usually be such packages. With debs this means the version number needs to be embedded to the package name with some developer-chosen precision.
This is still true from what I see, but in both families of distributions this is not a big requirement anymore. In my Debian based systems, libx264 is the only thing which requires multiple versions needs to be installed from what I remember.
On the other hand, RPM still doesn't know about reverse dependencies, automatically/manually installed packages, version holds, etc.
Either one is advanced enough to handle a big distribution and have their advantages w.r.t. each other, but I still prefer .deb as a person who works with both. Also, .deb can encode much more information about the software package it contains.
> .deb is a really good package manager, and is arguably more sophisticated than RPM.
Perhaps. I wouldn't argue either way, but dpkg still maintains its "data base" of installed and available packages/files as plain text files rather than using a DB format like sqlite (which one might chose for such today) or Berkeley DB (back when). The performance difference is negligible today on fast hosts with NVMe backed storage, but fairly annoying when using lesser machines with slower storage, e.g. RPi with root fs on a SD card.
I don't know the reasons behind the design decisions of apt. I know its workings up to a point, but not the history behind them.
On the other hand, I have been using Kingston Canvas Go SD cards on my Raspberry Pi boards for a fairly long time now, and these cards' random access speed is above and beyond of other, older cards while not being expensive.
Quite possibly! It was always a pleasure to see the ATLAS jobs running in a process list on an OpenStack hypervisor. We supported Lancaster University for compute (amongst others!).
You can pay companies just fine to support Debian.
> Debian is still easier to manage than RH based systems, and .deb is a really good package manager, and is arguably more sophisticated than RPM.
It's so bad. Coming back to RHEL (new client requirement) after sitting mostly on Debian for years is such a bizzare experience.
You want to install a PostgreSQL database, it doesn't even initialize it, you need to manually do DB init and the rest of the dance.
You want to run DRBD, sorry, we didn't bother to pick that kernel compile option, you can add extra repository for that. But hey, it's the kernel module, which means now you have to enroll cert in Secureboot, and that requires actual KVM access to the VM for someone to confirm it so now I'm on meeting with customer's IT just so they click some buttons in VM's boot process.
Even some common utilities are not in main repos but need EPEL
RedHat has a bad habit of dropping support for things not because they need maintenance but because they're just old.
I once installed a Sun workstation with AMD processor (Athlon64?) and nForce (4?) chipset. The ethernet card was there but it didn't initialize, why? Because RedHat EOLd the kernel module. Why? Because.
Reinstalled the thing with Debian after fighting it for 30 minutes or so, and the thing worked happily ever since.
> You can pay companies just fine to support Debian.
Yes, but this sentence didn't convince who was making these decisions back at CERN, approximately 20 years ago! I'm not even convinced that it was that possible and painless 20 years ago.
We agree about the rest of us, but I still ask why about EPEL stuff while writing salt recipes.
Update system, install EPEL, update system, install creature comforts is a such a bizarre dance to make while I can just write a one long apt command and get a better system in 30 seconds.
...and aptitude. Yes, that TUI thing. It's magnificent.
The benefits of SL described are pretty handwaivy to me. Having used a fork of scientific Linux, this was a huge pain because of outdated openSSL packages. Now you could argue this deserves being maintained separately, but I think it makes total sense to use the security- benefits of long term distros and only modify the parts required for reproducible scientific work.
I was really glad when the vendor started unofficially supporting OpenSuse so I could finally use git on these distros.
I think the premise of this article is wrong. Scientific Linux was important once upon a time but these days with userspace containers there is no need for the same level of homogeneity. In practice everyone is using Apptainer on machines that don’t have a singular purpose.
That needs a citation. I’m not aware of anyone doing anything more than containers. For older experiments VMs have been used but that’s a legacy thing that predates containerisation and isn’t driven by reproducibility.
just way way too much words to parse everythings...
in general a lot of people wants a lot of things from the free time of the others but not doing anything about it.
if you are using your tokens to write lengthy blog posts maybe spend them instead on trying to improve distros for LTS if that's what you want from SL.... Supporting old stuff, packages, kernel and hardware is really really a shitty and non rewarding job tho (been there done that), people only complains -- for example with length blog post -- and you don't get much rewards....
I read this article and was beginning to feel like it wasn't really going anywhere or making good arguments. Was disappointed, although in hindsight not surprised to find out that it was AI-slop.
I suspect that at the time they had to make a decision, Rocky Linux was not in good enough state, so they went with Debian, and now they already standardized around Debian, so no need to change.
Debian is to be used for some legacy systems because RHEL introduced microarchitecture restrictions. Rest of their infra is on AlmaLinux (a RHEL-compatible distro ala Rocky).
> If one site builds against one version of glibc, another uses something slightly different
The architecture problem that keeps on giving.
It's amazing how much damage this one brain dead decision, to make it basically impossible to use different glibc versions on one instance, made to Linux. Containers in a way are another solution to this problem, even if they were created to solve a different one (optimal resource usage).
Article quite a mess and, honestly, largely devoid of content. For starters, complains that SL should've continued because other community options might eventually be discontinued/change (as happened with CentOS). Like, duh. By this reasoning every effort should be duplicated to guard against the possibility that one option might disappear. In the end though all those RHEL rebuilds depend on Red Hat maintaining RHEL. The article never notes this and indirectly equalizes the effort and existence of a a genuinely independent community-driven distro (Debian, that CERN decided to move their accelerator-control computers) and RHEL rebuild (e.g., AlmaLinux, that CERN will keep the rest of infrastructure on, e.g. data centers, compute farms, etc). And here's the misguided part. If SL as still active it'll have been necessary to recompile numerous upstream RHEL source packages to remove the microarchitecture restrictions. This will've turned SL to entire new, independently maintained distro. The thing they wanted to avoid.
Well, it's not an unreasonable assumption that RHEL will continue to be maintained even if we don't go down the whole CentOS path which I won't on a public forum. But, yes, there are always dependencies. There's certainly no guarantees that any of the ~rebuilds will still be around in n years.
lo and behold, a 1000 word sample comes back in Pangram as AI generated. This should not be worth anyone's time (and maybe you have spent more time on your comment than the author did in their blogpost).
> author
prompter*
Thanks, this was much more insightful and on topic, than the complains about llm usage in the article.
Scientific Linux was great! Sad to see the blog in its memory having so much llm-speak. I hope one day writing without llm will become a trend.
Yeah but it seems to be a losing battle, sadly.
Low effort LLM-written content gets upvoted here anyway, despite the writer having little respect for peoples’ time.
I'm surprised it doesn't annoy the author. I use LLMs extensively for code but I cannot stand their natural language output a lot of the time, it always reminds me of that example from Orwell's Politics and the English Language:
Now that I have made this catalogue of swindles and perversions, let me give another example of the kind of writing that they lead to. This time it must of its nature be an imaginary one. I am going to translate a passage of good English into modern English of the worst sort. Here is a well-known verse from Ecclesiastes:
> I returned and saw under the sun, that the race is not to the swift, nor the battle to the strong, neither yet bread to the wise, nor yet riches to men of understanding, nor yet favour to men of skill; but time and chance happeneth to them all.
Here it is in modern [1946] English:
> Objective consideration of contemporary phenomena compels the conclusion that success or failure in competitive activities exhibits no tendency to be commensurate with innate capacity, but that a considerable element of the unpredictable must invariably be taken into account.
A 2026 version of this phenomenon would instead be:
> Here's the thing: success isn't just about talent — it's about timing. The fastest runner doesn't always win. The strongest army doesn't always prevail. Ultimately, life is a complex interplay of skill and chance, and recognizing that can be both humbling and empowering.
That's actually Claude and you can see precisely why the resulting vague language is bad; the LLM has changed the actual meaning of the passage from a sober reflection on the futility of expecting natural justice from the universe to one that emphasises skill and timing, exactly what the author is telling us is futile.
Admittedly the slop text LLMs produce in the 21st century isn't the same as the 20th century slop humans produced, but there's definitely a family resemblance in my view! Orwell was concerned with the idea language can be used to curtail thought, and he disliked what we'd now call slop because it merely gestures at a thought without actually instantiating it directly.
The whole essay is worth a read in my view, it remains highly relevant.
https://www.orwellfoundation.com/the-orwell-foundation/orwel...
People are asking for evidence. FWIW, pangram classifies this post as 97% AI, 3% human.
Any proof?
Subsection titles, and how the text flows. When I read these kinds of LLM-Powered posts, I feel the same thing. Like remembering the taste of some canned food which was not great, but I had to consume to stay alive. It feels like junk food, not optimized to taste great, but doesn't reek of machine oil either. A price-optimized, slightly unhealthy substance which is somewhat compatible with my body because of food engineering magic.
These posts are not only a waste of time, but it also makes me feel deceived and betrayed. Why this is important? Because it's the honest take and bears the load of the reality of the post.
Please, don't make me read something you didn't write.
Disclosure: This post, incl. llm-sounding paragraph is typed by a human. All of the keystrokes are 100% human and made possibe by burning ATPs and firing tiny lightning bolts across some brain cells. No humans are harmed or GPU hours are burned in this comment.
Total water consumption: 50ml of cold spring water, because I'm thirsty.
I just don't see the "LLM-speak" here at all, for example. And I'm very tired of people who throw around the LLM-power critique as an easy criticism when there's no clear basis for it. It's lazy and stupid.
There are certain styles for a post like this that some people may not like but things like subheads and what would be, by historical standards somewhat clipped writing are just how writing in this content is mostly encouraged theese days. I'd just add that when people do post long-form New Yorker pieces there's plenty of whining about getting to the point.
I think this mostly boils down to experience with writing styles. I am an avid reader, albeit mostly read in Ukrainian/Russian, but I can confidently tell whether some paragraph was written by Platonov or Nabokov or Zhadan or Sorokin; even when the guys are stylizing their texts (Sorokin does this all the time) there are still subtle things in how text is composed that tell you who wrote it. If my reading menu was mostly contemporary blogs, probably I would be less sensitive to distinct writing styles.
The first tech book I did with a publisher, I was pretty much told that I needed to break things down more with subheads and the like. And I was already doing some writing of whitepapers and blogs with my then-employer which had a somewhat similar structured style. Certainly very different from Dickens, Trollope, Collins, etc.
I'm not making a value judgement, but modern writing on technical topics has generally been steered toward digestible formats whether or not LLMs are involved.
Until I left, I was on social media and style committees at my former employer and there was a lot of data-based evidence around keeping things (in various multimedia formats) shorter and easier to consume. In fact, we mostly got away from writing white papers at all in favor of shorter pieces.
I don't disagree with you that contemporary technical writing, editing and technical blogs were converging to what is known as llm style even before provisioning of llms. In the end, llm were trained on these recent writing and recent blogs and this is why similarity exists. Still one can find some technical writing that stands aside and has very distinct style without compromising on clarity/digestability, i.e. Martin Fowler, Armin Ronacher, Michell Hashimoto write very differently from each other and Claude, but their content is always sharp and very much digestable. Take this paragraph by Claude
> Scientific Linux gave the scientific community its own implementation of a RHEL-compatible computing environment. More importantly, it kept alive the people, processes, infrastructure, and institutional knowledge needed to maintain one.
> That capability had option value. You might not need to exercise the option this year, or even this decade. It becomes valuable when the assumptions underneath your primary platform change. Those assumptions changed surprisingly quickly.
Can't imagine this lengthy style with paraphrases coming from Hashimoto or Fowler. Yes, it can appear not only in llm writing, but also in some heavily edited o'reilly book, sure, but I miss the times when tech blogs and o'reilly books were different.
I might have avoided the option value phrasing. But both sentences seem pretty ordinary to me and something I would write. But agree to disagree.
Personally, I make at least some things I write more personal but, yes, that tends to be somewhat frowned upon in corporate blogs.
Why would a person use RHEL in the first paragraph, making the assumption that people already know what that means. Then a few paragraphs later, write the full name?
Theoretically a mistake a person could make, but it feels a bit unlikely in this context to me.
Also, the repeating pattern of Prompt:List through multiple paragraphs.
Headlines, that are sentences
Headline that goes "A was this" and next headline "Then b was that".
"Scientific Linux was never simply "RHEL with a different wallpaper." It gave the scientific community an institutionally independent implementation of the Enterprise Linux platform."
You obviously can't get proof. But there are enough stylistic tells to confidently say that AI was substantially involved in writing this. It's annoying to read. That's enough to dislike AI writing IMO.
Any proof that you're a human and not a sealion?
Urgh. Thanks for saving me a click.
After two alineas I was fully convinced it was llm slop and the message it might have intended to pass is completely lost.
Well they could have used Debian from the start. I get why, but it's such a strange argument, the way it's posited.
If I remember correctly, the reason why Scientific Linux was RHEL based instead of Debian because RedHat was a company and can pay them for services.
We used to run it on our Grid nodes, and while it was not bad, it was not that smooth, either. It was a little kludgy but worked if you didn't diverge from the happy paths much.
Now Debian has Extended Long Time Support via Freexian, I believe CERN has enough confidence to use Debian instead of RH family, and that will make lives of some people way easier. Debian is still easier to manage than RH based systems, and .deb is a really good package manager, and is arguably more sophisticated than RPM.
> Debian is still easier to manage than RH based systems, and .deb is a really good package manager, and is arguably more sophisticated than RPM.
I realize I'm veering a bit off-topic :), but I've used Debian for a long while, but I do wonder how is that deb is more sophisticated than rpm?
The one feature I remember (a long time ago) rpm being able to install the different versions of the same package, although I suppose this in practice would only work for packages made for this, and libraries would usually be such packages. With debs this means the version number needs to be embedded to the package name with some developer-chosen precision.
This is still true from what I see, but in both families of distributions this is not a big requirement anymore. In my Debian based systems, libx264 is the only thing which requires multiple versions needs to be installed from what I remember.
On the other hand, RPM still doesn't know about reverse dependencies, automatically/manually installed packages, version holds, etc.
Either one is advanced enough to handle a big distribution and have their advantages w.r.t. each other, but I still prefer .deb as a person who works with both. Also, .deb can encode much more information about the software package it contains.
> .deb is a really good package manager, and is arguably more sophisticated than RPM.
Perhaps. I wouldn't argue either way, but dpkg still maintains its "data base" of installed and available packages/files as plain text files rather than using a DB format like sqlite (which one might chose for such today) or Berkeley DB (back when). The performance difference is negligible today on fast hosts with NVMe backed storage, but fairly annoying when using lesser machines with slower storage, e.g. RPi with root fs on a SD card.
I don't know the reasons behind the design decisions of apt. I know its workings up to a point, but not the history behind them.
On the other hand, I have been using Kingston Canvas Go SD cards on my Raspberry Pi boards for a fairly long time now, and these cards' random access speed is above and beyond of other, older cards while not being expensive.
Now apt works like it's running on an SSD.
Yea, long time user of both here (I even supported ATLAS workloads running on our public UK cloud). Debian long-term is the right choice
We might have exchanged some mails back in the day probably, then. :D
I'm in this for a couple of decades now.
Quite possibly! It was always a pleasure to see the ATLAS jobs running in a process list on an OpenStack hypervisor. We supported Lancaster University for compute (amongst others!).
We ran and still run things bare-metal. If you remember the site names, we had quite a few TR-XX sites. I hailed from some of those.
Now a colleague of mine is handling these. I'm more on the OpenStack & HPC side for other stuff.
You can pay companies just fine to support Debian.
> Debian is still easier to manage than RH based systems, and .deb is a really good package manager, and is arguably more sophisticated than RPM.
It's so bad. Coming back to RHEL (new client requirement) after sitting mostly on Debian for years is such a bizzare experience.
You want to install a PostgreSQL database, it doesn't even initialize it, you need to manually do DB init and the rest of the dance.
You want to run DRBD, sorry, we didn't bother to pick that kernel compile option, you can add extra repository for that. But hey, it's the kernel module, which means now you have to enroll cert in Secureboot, and that requires actual KVM access to the VM for someone to confirm it so now I'm on meeting with customer's IT just so they click some buttons in VM's boot process.
Even some common utilities are not in main repos but need EPEL
Ironically back around 2007 we had to use RHEL to get DRBD setup for the Redhat HA / Pacemaker things
RedHat has a bad habit of dropping support for things not because they need maintenance but because they're just old.
I once installed a Sun workstation with AMD processor (Athlon64?) and nForce (4?) chipset. The ethernet card was there but it didn't initialize, why? Because RedHat EOLd the kernel module. Why? Because.
Reinstalled the thing with Debian after fighting it for 30 minutes or so, and the thing worked happily ever since.
> You can pay companies just fine to support Debian.
Yes, but this sentence didn't convince who was making these decisions back at CERN, approximately 20 years ago! I'm not even convinced that it was that possible and painless 20 years ago.
We agree about the rest of us, but I still ask why about EPEL stuff while writing salt recipes.
Update system, install EPEL, update system, install creature comforts is a such a bizarre dance to make while I can just write a one long apt command and get a better system in 30 seconds.
...and aptitude. Yes, that TUI thing. It's magnificent.
The benefits of SL described are pretty handwaivy to me. Having used a fork of scientific Linux, this was a huge pain because of outdated openSSL packages. Now you could argue this deserves being maintained separately, but I think it makes total sense to use the security- benefits of long term distros and only modify the parts required for reproducible scientific work.
I was really glad when the vendor started unofficially supporting OpenSuse so I could finally use git on these distros.
They are. Debian + additional repo with scientific packages would be far more preferable for anyone involved.
I think the premise of this article is wrong. Scientific Linux was important once upon a time but these days with userspace containers there is no need for the same level of homogeneity. In practice everyone is using Apptainer on machines that don’t have a singular purpose.
Userspace containers don’t provide the level of reproducibility that is required for a scientific experiment, though.
That needs a citation. I’m not aware of anyone doing anything more than containers. For older experiments VMs have been used but that’s a legacy thing that predates containerisation and isn’t driven by reproducibility.
Thats literally what the author descirbes. Its about the cost of infra and making choices, not to go back
Does it still matter now that we have Linux VMs and Docker files? Seems like OS on the actual hardware could be any Linux or even non-Linux.
just way way too much words to parse everythings...
in general a lot of people wants a lot of things from the free time of the others but not doing anything about it.
if you are using your tokens to write lengthy blog posts maybe spend them instead on trying to improve distros for LTS if that's what you want from SL.... Supporting old stuff, packages, kernel and hardware is really really a shitty and non rewarding job tho (been there done that), people only complains -- for example with length blog post -- and you don't get much rewards....
I read this article and was beginning to feel like it wasn't really going anywhere or making good arguments. Was disappointed, although in hindsight not surprised to find out that it was AI-slop.
Stop upvoting AI-slop people!
Great text!
I didn’t comment much on this whole topic but what I wondered is: why not Rocky Linux?
It’s quite literally the modern day CentOS
> AlmaLinux and RHEL remain the main supported Linux distributions across much of the organization
Alma and Rocky provide almost the same thing.
I suspect that at the time they had to make a decision, Rocky Linux was not in good enough state, so they went with Debian, and now they already standardized around Debian, so no need to change.
Debian is to be used for some legacy systems because RHEL introduced microarchitecture restrictions. Rest of their infra is on AlmaLinux (a RHEL-compatible distro ala Rocky).
CentOS was always the hosting companies OS, which is continued with Alma Linux. Rocky certainly not
Sad that the author chose to generate slop instead of writing an article about SL
This LLM slop is borderline unreadable.
> If one site builds against one version of glibc, another uses something slightly different
The architecture problem that keeps on giving.
It's amazing how much damage this one brain dead decision, to make it basically impossible to use different glibc versions on one instance, made to Linux. Containers in a way are another solution to this problem, even if they were created to solve a different one (optimal resource usage).
Maybe an interesting topic, but I won't be reading this because it's AI slop.
[dead]
[dead]