16 ms·

A Brief Goodbye to CentOS

179 points by notadeveloper 6y ago

deleted 6y ago
[deleted]
chmod775 6y ago
Call me old fashioned, but I ship both my private projects and those at work as debian packages. Debian packages are trivial to put into a container, and we tried that, but honestly it's not half as nice to work with. With containers you have to do a ton of extra steps to get functionality and debugging on a level a default debian system provides you. Additionally the tools to automate the installation and configuration of debian systems are way more mature compared to docker et al. Containers aren't quite there yet.
- q3k 6y ago
  How do you handle multiple versions of the same project/software/deployment on the same machine?
  - starfallg 6y ago
    The simple answer is you can choose not to. In many ways, a VM is a better abstraction than a container due to the simplicity of virtualising the hardware interface, as opposed to creating another abstraction layer in the kernel dealing with process isolation, permissions and system controls.
    - q3k 6y ago
      On the other hand, VMs are wasteful resource-wise (and $$$-wise) and have a much larger operational overhead (suddenly for every deployment you have a different Linux installation, with its own root /, with its own configuration drift, which you have to manage separately via CM).
      - kijin 6y ago
        To be fair, containers often end up being its own Linux installation with its own configuration drift. So many dockerfiles mindlessly pull in an entire Ubuntu system just to run a simple app.
        q3k 6y ago
        But the image [1], once built, is still idempotent. You can deploy it and it will always contain the same configuration and code. Meanwhile, a month-long Ubuntu VM that has received regular CM pushes (including system updates) will likely vastly differ from a branch new Ubuntu VM and a single CM push. To the point, where you can't be sure anymore that your current CM config will even work on a brand new machine, unless you're regularly testing that. [1] - Yes, Dockerfiles do not make for reproducible builds - but once an OCI image is built, its deployment going to be reproducible. And there's more ways to build images than via Dockerfiles - some of which solve this problem (using Nix or Bazel, for example).
        inetknght 6y ago
        > But the image [1], once built, is still idempotent. You can deploy it and it will always contain the same configuration and code. VMs can be idempotent too. It's just that traditionally people attach storage to it. But VM snapshots are a thing. > To the point, where you can't be sure anymore that your current CM config will even work on a brand new machine, unless you're regularly testing that. The same can be argued about attached storage to a container.
        wejick 6y ago
        By idempotent do you mean immutable?
      - starfallg 6y ago
        That same issues exists with docker containers. You can also build a pipeline to deploy very barebones VMs that contain the kernel, a barebones userland and the application. Use KSM to minimise memory usage. What you get with containers is a shared page cache and reduced context switching. Once upon a time in tech, the thinking was hardware is cheap, technical staff is expensive, hence we moved on to systems and programming languages that saved us time at the expense of efficiency on the hardware. 20 years on, the cost equation hasn't changed. In fact, its probably shifted drastically towards the extremes. We'd likely save more energy by eliminating crypto mining than moving all VMs onto containers.
  - ComputerGuru 6y ago
    Isn't that a sign of technical debt? Not OP, but for development/testing: in a VM.
    - q3k 6y ago
      How is it technical debt? How else do you handle software rollout and rollback, or canarying? Do you have a VM for every single version of your software?
      - NDizzle 6y ago
        Uhhh... backups?! Not all companies release daily, weekly, and sometimes not even monthly. Stage the rollout, do your testing, get your evidence, get your plan, perform the release.
        q3k 6y ago
        So if you deploy a new release which turns out to be buggy, your only recourse is doing a full backup restore?
        Proven 6y ago
        No there are snapshots for that.
        NDizzle 6y ago
        q3k, I can't reply to you at this depth. But yes. You're saying a "full backup / restore" but it's not the entire system. Let's say you have an app, in a folder, that reads config files from 3 other locations on the machine. It talks to two databases. You back up two databases and 4 total folders. That's your backup. It's simple and straight forward to me.
        q3k 6y ago
        (you have to wait until you can reply after a certain depth - this is HN's anti-flamewar system kicking in) I understand you can restore from backups, but this doesn't seem simple to me - especially when you deal with situations where there's more than just one person deploying to production. In comparison, my rollbacks are performed the same way rollouts/rollforwards are - by editing a single line in Git (ie. changing the OCI image string) and running `kubecfg update`. No need to access backups, no need for special procedures.
  - z3t4 6y ago
    You can for example have many SQL databases on the same db server, or many web sites on a www server. So you solve it with configuration. If you need different kernels you have to use virtual servers anyway.
  - deleted 6y ago
    [deleted]
  - pmontra 6y ago
    On my development laptop: a mix of VMs, docker containers, language/package managers. It's a per project choice, either mandated by my customers or advised by me. To name a few technologies I'm using right now in three different projects open in different virtual desktops: docker vagrant VirtualBox (even some scripts to mimic EC2's spawning of machines with VBoxManage) asdf (really, my fingers didn't slip on the keyboard) npm rvm python's virtualenvs
  - phkahler 6y ago
    Why would you want to do that?
    - oblio 6y ago
      For development, for example. Or for some kinds of shared hosting.
  - chmod775 6y ago
    I never had the need to do that and I'm not sure in what kind of situation I would. For updates I just install the new version of the software, then perform a restart (new version starts, once it's ready, old version stops).
  - zemo 6y ago
    each version of the project gets a directory and contains everything the project needs. put all of those into a parent directory. use a symlink to point to the currently active version. E.g.: /usr/local/thing/versions/thing-v1.3.7 /usr/local/thing/versions/thing-v1.4.2 /usr/local/thing/current -> /usr/local/thing/versions/thing-v1.3.7
    - sickygnar 6y ago
      I do it similarly. I run multiple versions of a service at once with systemd service files. It gives me the same stuff as containers - cgroups, isolation, logging, service definitions and automation with ansible, but its easier on my feeble psyche.
    - q3k 6y ago
      I mean, sure, I've done this too with a handful of scripts. But is this something you do via .debs? I'm asking specifically about how to handle this with plain Debian/Ubuntu packaging.
- Thaxll 6y ago
  "Containers aren't quite there yet." The rest of the world beg to differ, it's not a question of is it ready or not, it's "Am I going to use it or not". We're way passed that question.
  - wirrbel 6y ago
    IMHO we are in a phase of enthusiasm, but we can already anticipate the peak and the trough of disillusionment will come. In 10 years, the pendulum will ice swung a bit back and forth and we‘ll know better what works well. I bet it’s some form of lambda architecture. Let me say that I am not pro or against docker per se. I just happen to have started my career with a strong team pre-docker and a lot of the docker-enthusiasm isn’t all that much addressing what was lacking in the operations space pre-docker.
    - oblio 6y ago
      > I bet it’s some form of lambda architecture. Well: https://aws.amazon.com/blogs/aws/new-for-aws-lambda-container-image-support/ https://aws.amazon.com/blogs/aws/new-for-aws-lambda-containe...
    - pjmlp 6y ago
      In 2000, I had HP-UX Virtual Vault (aka containers) and CGIs (aka lambda functions). Everything old is new again.
- ghshephard 6y ago
  Re: Containers aren't quite there yet. I think they've been there for 12-14 months. It's no longer a question of "If" but "When" a company decides on its container strategy (and its more than just k8s - see https://blog.coinbase.com/container-technologies-at-coinbase-d4ae118dcb6c https://blog.coinbase.com/container-technologies-at-coinbase...) I work for a company that is 100% k8s. Base linux of the containers is Debian 8- but honestly doesn't really matter that much - the OS is more kubectl and the orchestration around k8s (GKE, Prometheus, Sysdig, Grafana, ELK) - the "operating system" has moved up a stack.
  - folkhack 6y ago
    When I was working in a stack like this I found people spending outstanding amounts of time not actually working to improve the stability/performance of the application. The reason you triggered that memory was "GKE, Prometheus, Sysdig, Grafana, ELK" - that's exactly what we were dealing with. The support infrastructure/compute needs for it far exceeded the 20-30 hosts that actually needed to be there to operate the application. We either were using someone else's prebuilt orchestration for something like ELK (insecure, needs constant auditing to be OK) or rolling it ourselves (very expensive in engineer time). None of it was ever working 100% and that was because we were jumping at software packages no one had really taken the time to fully understand. The mentality was "it's containerized!" which many on my team took to mean "we don't need to really grok it, it's in a container!" That burnt us, both on our TIG and ELK stacks. I left that job because it became putting out dumb fires that were not business-justifiable. All-in-all I'm not saying what anyone is doing is wrong, I'm just saying that if you're going for an orchestrated environment like this you have to have a very mature team. You have to really care about learning these services well, and you have to be careful to not let your own architecture take your time away from solving real problems for the business. The team I was on did not have that maturity outside of a couple bitter/broken ops guys who didn't deserve what the team had done to them while buzz-word driven leadership gutted their very-proven and stable VMWare infra into a total cluster-f K8s setup because "that's what we're suppose to do in 2018! That's what the new engineers want to work in!" > the "operating system" has moved up a stack Splitting hairs: The OS is still the same. The "stack" is newly imposed abstraction on-top of already established paradigms where we are trying to abstract ourselves away from the OS. It's distributed compute more than it is the "OS moving up a stack". Edit: Ha I think you may have edited your comment with the Coinbase article. That article is actually what I point people to when explaining that K8s isn't some golden bullet, I personally think Coinbase is a great compromise in leveraging containers without going off of the rails (as they write about, ex: talking about the need for dedicated "compute" teams etc).
- folkhack 6y ago
  I'm really considering doing this for a new spin-up myself... The stability of Debian tooling for large-scale, hyper scaleable solutions is outstanding. I just feel like the world balks at me every time I do something considered slightly "old fashioned" completely ignoring the finished product to shame me for not using buzz-word tooling. Containerization is fantastic don't get me wrong, but I've had more success with old-school approaches to package management, deployment, optimization, debugging, etc. running thin Debian servers. Just... prod ops is easier and more stable at the end of the day. I really don't see the need to containerize everything outside of cross-platform development tooling. I also really prefer having a semblance of an OS/bash terminal when it comes to ops! Also: this is purely anecdotal. And, to get ahead of the folks yelling "you just don't understand Docker and K8s" - yes I do. I still think they're great, I just am not fully sold on them for every use-case.
  - dsr_ 6y ago
    Debian plus an automation system like Puppet, Chef, etc works extremely well. It's just not sexy enough for people to write hundreds of posts about how to set up your own package repo, understand unattended-upgrades, and do monitoring.
    - cactus2093 6y ago
      > Debian plus an automation system like Puppet, Chef, etc works extremely well. Eh, it does until it doesn't. Sooner or later you run into pitfalls around the leaky abstraction of pretending your state is truly idempotent and path-independent. E.g. spinning up a new instance works fine, but the existing instances that need to uninstall a previous version to upgrade to the newer one end up breaking. Or vice-versa, existing servers work fine but then when you need to launch a new one your realize the config no longer works on a clean install and you hadn't noticed it for weeks. Container-based systems certainly have their own problems, but it is really nice having a model where you don't allow long-lived implicit state and cruft to accumulate on your application servers in the same way.
      - dsr_ 6y ago
- jonfw 6y ago
  I make heavy use of both package managers and containers at my job, they solve different problems. Just because you don't have the problem that containers solve doesn't mean they aren't there yet
- cactus2093 6y ago
  I guess call me new fashioned, but I've never really understood how to use debian packages well. I recall vaguely looking into the dpkg and build commands many years ago, it felt kind of inscrutable and clunky and I didn't find good resources that made it easy to learn so I just gave up on it and kept using the shell script to install the thing I needed with its dependencies. By contrast, docker build and docker run are super simple to get started with (at least at a high level, figuring out the right order of flags and options to mount volumes and expose ports can get a little cumbersome). And the docker registry is super simple to browse. It's so easy to get up and running with, and the model it promises of isolation and self-contained dependencies makes a lot of sense which I think is why it has taken off so much. Despite the fact, which I think is what you're pointing out, that there often end up being a lot of pitfalls lurking just around the corner.
  - spicybright 6y ago
    I think this too. Debian packages I'm sure are powerful but I never sat down and RTFM yet, which I think is a solid requirement. Docker is easier to understand and I picked it up pretty easily just running through a quick tutorial. Definitely pros/cons to both depending on your situation. I can imagine debian packages being more useful in large scale multi-developer environments.
  - oblio 6y ago
    A deb file is just an ar archive of 2 tgzs, one with metadata and one with the actual files. Now, the tools that build them are a whole different kettle of fish. Plus some stuff is really old school, ar is an archive format that nobody has used on its own since 1996, it's a sort of transparent bundler/archiver à la tar, I think it was originally used to bundle .so file into a bigger package but still have the symbols inside visible. I don't really remember all the details, it's been a while since I looked into .deb packages. I think the main problem is that Debian is not a commercial project and it shows sometimes. The tooling is kind of "hidden" (you have to poke around the distribution, mailing lists, etc. to figure things out) and the processes are kind of the same thing. The docs on the site are ok in some regards but they're far from complete and up-to-date. Meanwhile the Dockerfile format is reasonably well documented and the tooling is also quite straightforward. You can see that a company made it for a while its raison d'être and wanted to make it easy to use.
vondur 6y ago
As others have noted, something like this was expected once IBM purchased RedHat. Looking forward, I’m excited for the future of Rocky Linux.
- _red 6y ago
  Rumor is RH was planning this from before merger. Supposedly they wanted to do it before C8 release. It was handled in a very hamfisted way. Permitting entities to rebase from C7 -> C8 and then pulling the plug has caused tremendous ill will.
  - wfuser 6y ago
    > Rumor is RH was planning this from before merger. I fully believe this. Like I noted in another comment https://news.ycombinator.com/item?id=25358847 https://news.ycombinator.com/item?id=25358847, they have done this exact similar thing in the past with the JBoss application server community edition.
ThinkBeat 6y ago
If you are operating a billion-dollar computer paying IBM/Redhat is probably a good idea.
- unreal37 6y ago
  Linux has come so far in the past 20 years, that not paying an annual license fee is now shameful.
- ethbr0 6y ago
  If you are operating a billion-dollar computer, not using IBM/Redhat is probably a good idea. At that scale, hiring your own quality support and running open systems is a drop in the bucket. If you want the full IBM/Redhat experience, then you can even afford to hire 5+ layers of middle management and PMs between you and your engineers.
  - dboreham 6y ago
    > At that scale, hiring your own quality support and running open systems is a drop in the bucket. "support" doesn't mean reading man pages, it means diagnosing and fixing some intermittent bug in Intel's 10G NIC driver.
    - bachmeier 6y ago
      Also, and this is why you pay Red Hat specifically: Having easy access to the developer that compiled a package, made a particular design decision for the OS, etc.
- deleted 6y ago
  [deleted]
- bitcharmer 6y ago
  No offence, I've been in Linux business for 15+ years but I'm struggling to comprehend your comment. Apologies in advance, I'm not a native speaker.
- bachmeier 6y ago
Lendal 6y ago
I'm still relatively new to Linux. My question is why wouldn't Fedora Server be considered an alternative for the CentOS diaspora? It seems a better fit than Debian to me.
- spijdar 6y ago
  CentOS releases were supported for something like 8 years, while Fedora releases a new OS every ~6 months. It does support up to 2 older versions with updates, but that means potentially breaking major upgrades every 6-18 months, compared to once every 8 years. Debian, OTOH, has a much longer release cycle, and more of a reputation for moving like molasses, which for better or worse mirrors CentOS a bit more closely.
- alias_neo 6y ago
  You want your server OS to be a mountain. It shouldn't move from under you as you build. Fedora is a river, it never stops moving.
  - ethbr0 6y ago
    For people who this doesn't make sense, it's the timeline of the stack on top that drives the OS stability requirements. If you work in heavily regulated industries, systems migrations and software development can be order-of-years. Having a mandatory OS upgrade mid-development/deployment is not desirable. It's a terrible way to develop, but when changes need to be documented in excruciating detail and signed off on by legal... sometimes it's just the way things are.
- AdmiralAsshat 6y ago
  Previous product I worked on required a supported RHEL/CentOS environment on which to install our product. Even with the six years or so of support, our customers would piss and moan every time we'd tell them that RHEL/Centos5 was hitting EOL and they'd need to upgrade their servers to Centos 6 or 7 to stay supported. Most of them wouldn't even entertain the idea of "upgrading": for them, business as usual was holding on to the existing OS as long as possible, then buying an entirely new server with the latest-greatest CentOS release freshly installed on it, and doing a data migration. I can't even imagine the amount of headache we would have gotten if they needed to upgrade every two years.
_jal 6y ago
RedHat's goodwill will be spent down over the next decade or so, and eventually I fully expect to think of them the same way I do IBM. (Which is, roughly, the same way I think of Oracle.) All of the people I deal with there are the same as before the acquisition, so things have not changed much for me personally, yet. But I am looking at building replacements for certain tools we depend on; the writing is on the wall.
- cubano 6y ago
  It's easy to want to do, but much harder to justify banging on public companies for trying to increase revenue.
  - deleted 6y ago
    [deleted]
  - dvfjsdhgfv 6y ago
    Well, if you ignore the history of Red Hat. It used to be "the" Linux company, a paragon of what you can achieve by combining business acumen of the corporate world with complete transparency of the open source process. When the first clones of RHEL appeared, they received C&D letters about the use of "Red Hat" in the name, so they complied and started to replace the branding before recompiling. Who would expect that the only free-as-in beer RHEL clone we'll be able to use will be Oracle Linux.
    - laurent92 6y ago
      I’m deeply interrogated by Atlassian forcefully moving users to the cloud. It’s as if, in 5 years, we developers wouldn’t have a safe Linux to deploy on, and then we’d be required to use Amazon Linux or GCP Linux, the other ones being not officially supported and therefore not insured in case of leak, or not approved for PCI or PII or GDPR or...
  - yjftsjthsd-h 6y ago
    > but much harder to justify banging on public companies for trying to increase revenue I assure you, it is very easy to be unhappy with a company for screwing over its users, even if they think it might net them more revenue (bonus points for this being a questionable assumption)
ben509 6y ago
I wasn't clear what's changing that is so problematic, so to summarize this post[1] and various comments: CentOS Stream will track ahead of RHEL and thus will be more like a beta channel, losing the stability guarantees that CentOS users depended on. [1]: https://blog.centos.org/2020/12/future-is-centos-stream/ https://blog.centos.org/2020/12/future-is-centos-stream/
- pelasaco 6y ago
  so will it be basic the same as openSUSE Tumbleweed for SUSE Linux?
  - viccuad 6y ago
    Debian Unstable -> Testing -> Stable -> Oldstable -> Oldstable with LTS Fedora -> Centos Stream -> RHEL -> RHEL with LTS Opensuse Tumbleweed -> Leap -> SLES -> SLES with LTS Debian supports upgrades with major versions, and doesn't bump package major versions between minor versions. SLE/Leap don't support upgrades between major versions, and bump package major versions between minor versions.
    - rombert 6y ago
      Note that the gap between Leap and SLE will become quite small after Leap 15.3, with binary packages for SLE being reused for Leap. It's interesting that while RH/IBM are moving away from the 'community rebuild' model SUSE are moving close. https://en.opensuse.org/Portal:Leap/FAQ/ClosingTheLeapGap https://en.opensuse.org/Portal:Leap/FAQ/ClosingTheLeapGap
    - pferde 6y ago
      It is untrue that SLES does not support upgrades between major versions: https://documentation.suse.com/sles/15-SP2/single-html/SLES-upgrade/#sec-upgrade-paths-supported https://documentation.suse.com/sles/15-SP2/single-html/SLES-... It is, however, true that SLES is less conservative than e.g. RHEL when it comes to bumping software versions between their minor releases (service packs). I remember that they switched from 2.6 to 3.0 kernels sometimes in SLES10 days. Fun stuff.
3np 6y ago
A common criticism of CentOS is that it's too stable. I don't see a mention anywhere of LTS channel of CentOS Stream, but wouldn't the next RHEL release effectively mean that current CentOS Stream channel becomes the LTS alternative, if RedHat commits to providing security backports?
softinio 6y ago
I have noticed more companies adopting Amazon Linux when a few years back they would have used CentOS. I wonder how much this affected the decision. Wish we would see more adoption of Freebsd and NixOS in the future. For now I like my Debian :-)
jolmg 6y ago
The server response on clicking the link lacks a "Content-Type" header. I just thought I'd mention that in case the admin would be here and interested. It's causing a download extension in my browser to show a download dialog on clicking the link. I don't think it's a bug in the extension, but rather a required behavior because of the limitations of extensions. The extension has no sure way to know what my browser's treatment of the response will be after it inspects the body content to guess the type, so the safer thing to do in its case is to show the dialog. I don't think Content-Type is required by HTTP, but it's pretty rare for servers to not include it. Might be good to add it if only in interest of the Robustness Principle[1]. [1] https://en.wikipedia.org/wiki/Robustness_principle https://en.wikipedia.org/wiki/Robustness_principle
SloopJon 6y ago
I somehow missed that Red Hat started sponsoring CentOS a while back, and owns the trademarks. I mean, money and cooperation is great and all, but how could anyone have expected CentOS Linux to continue for long when Red Hat has such a fundamental conflict of interest? Edit: here's the HN post at the time: https://news.ycombinator.com/item?id=7019914 https://news.ycombinator.com/item?id=7019914
- Pxtl 6y ago
  Yeah, I assume this ends with somebody forking CentOS into another "redhat without redhat branding and license costs".
  - deng 6y ago
    Maybe CERN will revitalize Scientific Linux.
    - navanchauhan 6y ago
      Scientific Linux[0] is still maintained ( Although, by Fermi National Accelerator Laboratory and not CERN ) [0] https://scientificlinux.org https://scientificlinux.org
      - j0057 6y ago
        There's no RHEL8 equivalent of Scientific Linux.
      - deng 6y ago
        Yes, maintained, but no new versions since they switched to CentOS. https://lwn.net/Articles/786422/ https://lwn.net/Articles/786422/
  - FireBeyond 6y ago
    There is already an announcement for Rocky Linux, from the same person who started CentOS, doing a Monty from MySQL.
ehayes 6y ago
Am I the only one who doesn't get the "risk using CentOS Stream" stuff? Isn't it going to be slightly-less stable RHEL? I actually worked at Red Hat a few years back and almost all work was released upstream-first. The one time I fixed something security-related, the fix was still made upstream first, but just embargoed until the fix was made and released for downstream versions. If I recall correctly, we pushed the upstream fix the day the downstream patch was public. Now I run CentOS in production for a small web app. I get wanting a decade of support for your OS, but at least for cloud-based web apps that seems pretty unnecessary. What am I missing here?
- dvfjsdhgfv 6y ago
  It's not about risk; many vendors produce software for a specific version of RHEL - we want to use exactly that version, but we don't want to pay through the nose for the support we don't need.
  - rhodysurf 6y ago
    Exactly this. You can produce software that is compatible with a RHEL version without paying for RHEL if you’re not even using it
    - yjftsjthsd-h 6y ago
      FWIW, redhat does offer developer licenses of RHEL specifically for this kind of thing. Maybe not quite as nice, but probably workable.
- rhodysurf 6y ago
  I worked in defense for a while. Every DoD contractor is locked to RHEL version that their DoD targets use as end users. But they don’t need to pay for RHEL support currently because they all just use CentOS instead. This forces all of those companies to finally pay up, which they will def not be happy about.
  - abruzzi 6y ago
bachmeier 6y ago
> With the advent of DevOps and SRE, businesses and startups are moving away from the old-school concept of traditional server clusters to running their applications on disposable containers. The trend is clear and true. Developers are increasingly less reliant on a tried-and-true Linux distribution that lasts for a decade. With containers, developers can develop, test, deploy, and rollback with blazing fast velocity. As a user of Linux as my main OS since 2005, and using it partially for years before that, I think another issue is that the quality of software releases is just much higher than it used to be. There used to be a tradeoff between "trustworthy" and "recent". These days it's more "possibility of a problem" vs "absolutely rock solid". And of course the general move to the web. Apps that run in your browser no longer need to run on a server. When I started in my current job in 2004, there was a Debian stable server used for teaching. (It might still be in use for all I know.) This semester I used CoCalc. That's one less use for an ultrastable server.
- jmnicolas 6y ago
  > These days it's more "possibility of a problem" vs "absolutely rock solid". CentOS is mostly a server distro, I bet 99% of installs are without GUI. So "possibility of a problem" is a no go for a server.
  - leotaku 6y ago
    Sorry to break this to you, but if the possibility of a problem is a no go for your servers, you will unfortunately have to pull the plug on them. All software has bugs, so does hardware.
    - jmnicolas 6y ago
      Come on. Possibility of a problem is say Arch, rock stable is Debian / CentOS. There are certainly bugs in the later too, but I never experienced any in 15 years since I run a dozen Linux servers in production.
      - leotaku 6y ago
fractal618 6y ago
No mention of Fedora? Is it not feasible that those currently using CentOS, and don't wish to use the supported Red Hat, will gradually migrate to the CoreOS, IoT or Server version of Fedora? I would think that would be easier than migrating to a different package management system.
- twic 6y ago
  People use CentOS because it's stable - you can run one version for years, and get security and bug fixes, with no feature changes. This change to CentOS means it won't have that stability, so some will need alternatives. Fedora changes even faster than the new CentOS - a new version every six months! Each version is maintained for just over a year, and the maintenance includes new features.
that_guy_iain 6y ago
I think IBM/Red Hat know someone will fork and carry on with CentOS under a different name. They just won't be paying for it.
60secz 6y ago
Too bad Rocky Linux isn't called DollarLinux
lizknope 6y ago
Looks at cluster of over 5000 machines running CentOS. Doesn't look dead to me.
darksaints 6y ago
The future of operating systems, at least from a non-GUI perspective, is going to look a lot like SeL4 + Nix. A rock-hard provably secure capabilities-oriented kernel, combined with reproducible declarative package management that can handle any combination of dependencies that you want. Essentially this means that the idea of different distributions for LTS, stable, beta, alpha, bleeding edge, etc., goes away completely. You are never forced to update an old package, nor prevented from updating a new package. You get the best of all worlds. And since the kernel is about as secure and performant as you can get, you essentially always have the latest kernel. Drivers get updated as necessary (defined by your policy, not the distribution's) in userspace, potentially as quickly as the moment they are released, with no downtime whatsoever.
- mixmastamyk 6y ago
  Sounds good, but unless there’s a developer and end-user product approaching the maturity of BlueHat or even Debian it doesn’t seem likely to happen.
- yjftsjthsd-h 6y ago
  So there's 2 ideas here: kernel, and packages. For the kernel, I'm curious how your suggestion is better than Linux is already. Linux, today, is already a performant, secure kernel with an incredibly stable userspace-facing ABI. For packages, the problem isn't so much being able to install old and new packages (although that's certainly useful); the problem is maintaining a stable version while still fixing bugs and security issues. It's no good just having a packaging system that lets me run a 5-year-old glibc with a fresh-from-git application server if that ancient glibc has multiple known exploits in it. The work in an LTS system is carefully backporting fixes to your chosen old version while holding its ABI stable.
  - pjmlp 6y ago
    The CVE database and Linux Kernel Self Preservation project beg to differ in regard to security.
  - darksaints 6y ago
g051051 6y ago
> With containers, developers can develop, test, deploy, and rollback with blazing fast velocity. Wow, that has not been my experience with containers.
- kkapelon 6y ago
  Can you elaborate? Even the basic ability to just spin a container with all your stuff and start developing is an important advance. (especially for cases like python2/3, java5/8 etc) Coupled with the remote containers feature of visual studio, working with containers is now a game changer.
  - g051051 6y ago
    Maybe for very small projects. But the scale of things I work on doesn't lend itself to that sort of thing.
- ghshephard 6y ago
  A lot of this depends on your CI/CD environment. In ours, every single push to every branch on the remote repo ends up building a testing/building a full container environment that is ready for deployment in the cloud - with no differentiation between production/development in terms of completeness. It's fast enough, that some (obv not most) developers don't even set up their local docker environment, and just use the CI/CD deployments to test their work. With the advantage being that if it looks good - single deploy moves all of the production environment to it.
  - g051051 6y ago
    They want to implement that sort of thing, but it just doesn't work for very large projects.
dang 6y ago
Recent and related: https://news.ycombinator.com/item?id=25345428 https://news.ycombinator.com/item?id=25345428 https://news.ycombinator.com/item?id=25357885 https://news.ycombinator.com/item?id=25357885 https://news.ycombinator.com/item?id=25354811 https://news.ycombinator.com/item?id=25354811 (a bit) https://news.ycombinator.com/item?id=25360217 https://news.ycombinator.com/item?id=25360217 (a bit)
indymike 6y ago
The only place I run into RHEL or CentOS is maintaining old PHP apps where the web host is running someone's control panel... Often times, it's like stepping into a time machine because it's pretty obvious that things haven't been updated in quite some time. I'm not sure that a 10 year promise of stability is one we want kept (security patches, etc...)
- mixmastamyk 6y ago
  The whole reason for the distro family to exist is for security patches.
nikolay 6y ago
Without being a free version of RHEL, nobody would have bothered with CentOS. There was White Box Linux back then. Maybe this would give another chance to that forgotten project.
120bits 6y ago
I'm still confused about this? Why everyone is calling it death of CentOS?
teilo 6y ago
Honestly, I won't be sad if this means appliance and VM image providers (for on-prem / private cloud application hosting) switch to Debian en masse. I only use CentOS where Debian is not an option.
tekmonks 6y ago
We are creating the next RHEL based Enterprise Linux - same as CentOS used to be. Targeted first release is January 31, 2021. Looking for both volunteers or people who want to be paid for their efforts. Join us to secure Enterprise Linux as a free (as in beer and freedom) for the foreseeable future. https://monkos.org https://monkos.org

179 points by notadeveloper 6y ago

deleted 6y ago

[deleted]

Call me old fashioned, but I ship both my private projects and those at work as debian packages. Debian packages are trivial to put into a container, and we tried that, but honestly it's not half as nice to work with. With containers you have to do a ton of extra steps to get functionality and debugging on a level a default debian system provides you. Additionally the tools to automate the installation and configuration of debian systems are way more mature compared to docker et al. Containers aren't quite there yet.

q3k 6y ago
How do you handle multiple versions of the same project/software/deployment on the same machine?
- starfallg 6y ago
  The simple answer is you can choose not to. In many ways, a VM is a better abstraction than a container due to the simplicity of virtualising the hardware interface, as opposed to creating another abstraction layer in the kernel dealing with process isolation, permissions and system controls.
  - q3k 6y ago
    On the other hand, VMs are wasteful resource-wise (and $$$-wise) and have a much larger operational overhead (suddenly for every deployment you have a different Linux installation, with its own root /, with its own configuration drift, which you have to manage separately via CM).
    - kijin 6y ago
      To be fair, containers often end up being its own Linux installation with its own configuration drift. So many dockerfiles mindlessly pull in an entire Ubuntu system just to run a simple app.
      - q3k 6y ago
        But the image [1], once built, is still idempotent. You can deploy it and it will always contain the same configuration and code. Meanwhile, a month-long Ubuntu VM that has received regular CM pushes (including system updates) will likely vastly differ from a branch new Ubuntu VM and a single CM push. To the point, where you can't be sure anymore that your current CM config will even work on a brand new machine, unless you're regularly testing that. [1] - Yes, Dockerfiles do not make for reproducible builds - but once an OCI image is built, its deployment going to be reproducible. And there's more ways to build images than via Dockerfiles - some of which solve this problem (using Nix or Bazel, for example).
        inetknght 6y ago
        > But the image [1], once built, is still idempotent. You can deploy it and it will always contain the same configuration and code. VMs can be idempotent too. It's just that traditionally people attach storage to it. But VM snapshots are a thing. > To the point, where you can't be sure anymore that your current CM config will even work on a brand new machine, unless you're regularly testing that. The same can be argued about attached storage to a container.
        wejick 6y ago
        By idempotent do you mean immutable?
    - starfallg 6y ago
      That same issues exists with docker containers. You can also build a pipeline to deploy very barebones VMs that contain the kernel, a barebones userland and the application. Use KSM to minimise memory usage. What you get with containers is a shared page cache and reduced context switching. Once upon a time in tech, the thinking was hardware is cheap, technical staff is expensive, hence we moved on to systems and programming languages that saved us time at the expense of efficiency on the hardware. 20 years on, the cost equation hasn't changed. In fact, its probably shifted drastically towards the extremes. We'd likely save more energy by eliminating crypto mining than moving all VMs onto containers.
- ComputerGuru 6y ago
  Isn't that a sign of technical debt? Not OP, but for development/testing: in a VM.
  - q3k 6y ago
    How is it technical debt? How else do you handle software rollout and rollback, or canarying? Do you have a VM for every single version of your software?
    - NDizzle 6y ago
      Uhhh... backups?! Not all companies release daily, weekly, and sometimes not even monthly. Stage the rollout, do your testing, get your evidence, get your plan, perform the release.
      - q3k 6y ago
        So if you deploy a new release which turns out to be buggy, your only recourse is doing a full backup restore?
        Proven 6y ago
        No there are snapshots for that.
      - NDizzle 6y ago
        q3k, I can't reply to you at this depth. But yes. You're saying a "full backup / restore" but it's not the entire system. Let's say you have an app, in a folder, that reads config files from 3 other locations on the machine. It talks to two databases. You back up two databases and 4 total folders. That's your backup. It's simple and straight forward to me.
        q3k 6y ago
        (you have to wait until you can reply after a certain depth - this is HN's anti-flamewar system kicking in) I understand you can restore from backups, but this doesn't seem simple to me - especially when you deal with situations where there's more than just one person deploying to production. In comparison, my rollbacks are performed the same way rollouts/rollforwards are - by editing a single line in Git (ie. changing the OCI image string) and running `kubecfg update`. No need to access backups, no need for special procedures.
- z3t4 6y ago
  You can for example have many SQL databases on the same db server, or many web sites on a www server. So you solve it with configuration. If you need different kernels you have to use virtual servers anyway.
- deleted 6y ago
  [deleted]
- pmontra 6y ago
  On my development laptop: a mix of VMs, docker containers, language/package managers. It's a per project choice, either mandated by my customers or advised by me. To name a few technologies I'm using right now in three different projects open in different virtual desktops: docker vagrant VirtualBox (even some scripts to mimic EC2's spawning of machines with VBoxManage) asdf (really, my fingers didn't slip on the keyboard) npm rvm python's virtualenvs
- phkahler 6y ago
  Why would you want to do that?
  - oblio 6y ago
    For development, for example. Or for some kinds of shared hosting.
- chmod775 6y ago
  I never had the need to do that and I'm not sure in what kind of situation I would. For updates I just install the new version of the software, then perform a restart (new version starts, once it's ready, old version stops).
- zemo 6y ago
  each version of the project gets a directory and contains everything the project needs. put all of those into a parent directory. use a symlink to point to the currently active version. E.g.: /usr/local/thing/versions/thing-v1.3.7 /usr/local/thing/versions/thing-v1.4.2 /usr/local/thing/current -> /usr/local/thing/versions/thing-v1.3.7
  - sickygnar 6y ago
    I do it similarly. I run multiple versions of a service at once with systemd service files. It gives me the same stuff as containers - cgroups, isolation, logging, service definitions and automation with ansible, but its easier on my feeble psyche.
  - q3k 6y ago
    I mean, sure, I've done this too with a handful of scripts. But is this something you do via .debs? I'm asking specifically about how to handle this with plain Debian/Ubuntu packaging.
Thaxll 6y ago
"Containers aren't quite there yet." The rest of the world beg to differ, it's not a question of is it ready or not, it's "Am I going to use it or not". We're way passed that question.
- wirrbel 6y ago
  IMHO we are in a phase of enthusiasm, but we can already anticipate the peak and the trough of disillusionment will come. In 10 years, the pendulum will ice swung a bit back and forth and we‘ll know better what works well. I bet it’s some form of lambda architecture. Let me say that I am not pro or against docker per se. I just happen to have started my career with a strong team pre-docker and a lot of the docker-enthusiasm isn’t all that much addressing what was lacking in the operations space pre-docker.
  - oblio 6y ago
    > I bet it’s some form of lambda architecture. Well: https://aws.amazon.com/blogs/aws/new-for-aws-lambda-container-image-support/ https://aws.amazon.com/blogs/aws/new-for-aws-lambda-containe...
  - pjmlp 6y ago
    In 2000, I had HP-UX Virtual Vault (aka containers) and CGIs (aka lambda functions). Everything old is new again.
ghshephard 6y ago
Re: Containers aren't quite there yet. I think they've been there for 12-14 months. It's no longer a question of "If" but "When" a company decides on its container strategy (and its more than just k8s - see https://blog.coinbase.com/container-technologies-at-coinbase-d4ae118dcb6c https://blog.coinbase.com/container-technologies-at-coinbase...) I work for a company that is 100% k8s. Base linux of the containers is Debian 8- but honestly doesn't really matter that much - the OS is more kubectl and the orchestration around k8s (GKE, Prometheus, Sysdig, Grafana, ELK) - the "operating system" has moved up a stack.
- folkhack 6y ago
  When I was working in a stack like this I found people spending outstanding amounts of time not actually working to improve the stability/performance of the application. The reason you triggered that memory was "GKE, Prometheus, Sysdig, Grafana, ELK" - that's exactly what we were dealing with. The support infrastructure/compute needs for it far exceeded the 20-30 hosts that actually needed to be there to operate the application. We either were using someone else's prebuilt orchestration for something like ELK (insecure, needs constant auditing to be OK) or rolling it ourselves (very expensive in engineer time). None of it was ever working 100% and that was because we were jumping at software packages no one had really taken the time to fully understand. The mentality was "it's containerized!" which many on my team took to mean "we don't need to really grok it, it's in a container!" That burnt us, both on our TIG and ELK stacks. I left that job because it became putting out dumb fires that were not business-justifiable. All-in-all I'm not saying what anyone is doing is wrong, I'm just saying that if you're going for an orchestrated environment like this you have to have a very mature team. You have to really care about learning these services well, and you have to be careful to not let your own architecture take your time away from solving real problems for the business. The team I was on did not have that maturity outside of a couple bitter/broken ops guys who didn't deserve what the team had done to them while buzz-word driven leadership gutted their very-proven and stable VMWare infra into a total cluster-f K8s setup because "that's what we're suppose to do in 2018! That's what the new engineers want to work in!" > the "operating system" has moved up a stack Splitting hairs: The OS is still the same. The "stack" is newly imposed abstraction on-top of already established paradigms where we are trying to abstract ourselves away from the OS. It's distributed compute more than it is the "OS moving up a stack". Edit: Ha I think you may have edited your comment with the Coinbase article. That article is actually what I point people to when explaining that K8s isn't some golden bullet, I personally think Coinbase is a great compromise in leveraging containers without going off of the rails (as they write about, ex: talking about the need for dedicated "compute" teams etc).
folkhack 6y ago
I'm really considering doing this for a new spin-up myself... The stability of Debian tooling for large-scale, hyper scaleable solutions is outstanding. I just feel like the world balks at me every time I do something considered slightly "old fashioned" completely ignoring the finished product to shame me for not using buzz-word tooling. Containerization is fantastic don't get me wrong, but I've had more success with old-school approaches to package management, deployment, optimization, debugging, etc. running thin Debian servers. Just... prod ops is easier and more stable at the end of the day. I really don't see the need to containerize everything outside of cross-platform development tooling. I also really prefer having a semblance of an OS/bash terminal when it comes to ops! Also: this is purely anecdotal. And, to get ahead of the folks yelling "you just don't understand Docker and K8s" - yes I do. I still think they're great, I just am not fully sold on them for every use-case.
- dsr_ 6y ago
  Debian plus an automation system like Puppet, Chef, etc works extremely well. It's just not sexy enough for people to write hundreds of posts about how to set up your own package repo, understand unattended-upgrades, and do monitoring.
  - cactus2093 6y ago
    > Debian plus an automation system like Puppet, Chef, etc works extremely well. Eh, it does until it doesn't. Sooner or later you run into pitfalls around the leaky abstraction of pretending your state is truly idempotent and path-independent. E.g. spinning up a new instance works fine, but the existing instances that need to uninstall a previous version to upgrade to the newer one end up breaking. Or vice-versa, existing servers work fine but then when you need to launch a new one your realize the config no longer works on a clean install and you hadn't noticed it for weeks. Container-based systems certainly have their own problems, but it is really nice having a model where you don't allow long-lived implicit state and cruft to accumulate on your application servers in the same way.
    - dsr_ 6y ago
jonfw 6y ago
I make heavy use of both package managers and containers at my job, they solve different problems. Just because you don't have the problem that containers solve doesn't mean they aren't there yet
cactus2093 6y ago
I guess call me new fashioned, but I've never really understood how to use debian packages well. I recall vaguely looking into the dpkg and build commands many years ago, it felt kind of inscrutable and clunky and I didn't find good resources that made it easy to learn so I just gave up on it and kept using the shell script to install the thing I needed with its dependencies. By contrast, docker build and docker run are super simple to get started with (at least at a high level, figuring out the right order of flags and options to mount volumes and expose ports can get a little cumbersome). And the docker registry is super simple to browse. It's so easy to get up and running with, and the model it promises of isolation and self-contained dependencies makes a lot of sense which I think is why it has taken off so much. Despite the fact, which I think is what you're pointing out, that there often end up being a lot of pitfalls lurking just around the corner.
- spicybright 6y ago
  I think this too. Debian packages I'm sure are powerful but I never sat down and RTFM yet, which I think is a solid requirement. Docker is easier to understand and I picked it up pretty easily just running through a quick tutorial. Definitely pros/cons to both depending on your situation. I can imagine debian packages being more useful in large scale multi-developer environments.
- oblio 6y ago
  A deb file is just an ar archive of 2 tgzs, one with metadata and one with the actual files. Now, the tools that build them are a whole different kettle of fish. Plus some stuff is really old school, ar is an archive format that nobody has used on its own since 1996, it's a sort of transparent bundler/archiver à la tar, I think it was originally used to bundle .so file into a bigger package but still have the symbols inside visible. I don't really remember all the details, it's been a while since I looked into .deb packages. I think the main problem is that Debian is not a commercial project and it shows sometimes. The tooling is kind of "hidden" (you have to poke around the distribution, mailing lists, etc. to figure things out) and the processes are kind of the same thing. The docs on the site are ok in some regards but they're far from complete and up-to-date. Meanwhile the Dockerfile format is reasonably well documented and the tooling is also quite straightforward. You can see that a company made it for a while its raison d'être and wanted to make it easy to use.

vondur 6y ago

As others have noted, something like this was expected once IBM purchased RedHat. Looking forward, I’m excited for the future of Rocky Linux.

_red 6y ago
Rumor is RH was planning this from before merger. Supposedly they wanted to do it before C8 release. It was handled in a very hamfisted way. Permitting entities to rebase from C7 -> C8 and then pulling the plug has caused tremendous ill will.
- wfuser 6y ago
  > Rumor is RH was planning this from before merger. I fully believe this. Like I noted in another comment https://news.ycombinator.com/item?id=25358847 https://news.ycombinator.com/item?id=25358847, they have done this exact similar thing in the past with the JBoss application server community edition.

ThinkBeat 6y ago

If you are operating a billion-dollar computer paying IBM/Redhat is probably a good idea.

unreal37 6y ago
Linux has come so far in the past 20 years, that not paying an annual license fee is now shameful.
ethbr0 6y ago
If you are operating a billion-dollar computer, not using IBM/Redhat is probably a good idea. At that scale, hiring your own quality support and running open systems is a drop in the bucket. If you want the full IBM/Redhat experience, then you can even afford to hire 5+ layers of middle management and PMs between you and your engineers.
- dboreham 6y ago
  > At that scale, hiring your own quality support and running open systems is a drop in the bucket. "support" doesn't mean reading man pages, it means diagnosing and fixing some intermittent bug in Intel's 10G NIC driver.
  - bachmeier 6y ago
    Also, and this is why you pay Red Hat specifically: Having easy access to the developer that compiled a package, made a particular design decision for the OS, etc.
deleted 6y ago
[deleted]
bitcharmer 6y ago
No offence, I've been in Linux business for 15+ years but I'm struggling to comprehend your comment. Apologies in advance, I'm not a native speaker.
bachmeier 6y ago

Lendal 6y ago

I'm still relatively new to Linux. My question is why wouldn't Fedora Server be considered an alternative for the CentOS diaspora? It seems a better fit than Debian to me.

spijdar 6y ago
CentOS releases were supported for something like 8 years, while Fedora releases a new OS every ~6 months. It does support up to 2 older versions with updates, but that means potentially breaking major upgrades every 6-18 months, compared to once every 8 years. Debian, OTOH, has a much longer release cycle, and more of a reputation for moving like molasses, which for better or worse mirrors CentOS a bit more closely.
alias_neo 6y ago
You want your server OS to be a mountain. It shouldn't move from under you as you build. Fedora is a river, it never stops moving.
- ethbr0 6y ago
  For people who this doesn't make sense, it's the timeline of the stack on top that drives the OS stability requirements. If you work in heavily regulated industries, systems migrations and software development can be order-of-years. Having a mandatory OS upgrade mid-development/deployment is not desirable. It's a terrible way to develop, but when changes need to be documented in excruciating detail and signed off on by legal... sometimes it's just the way things are.
AdmiralAsshat 6y ago
Previous product I worked on required a supported RHEL/CentOS environment on which to install our product. Even with the six years or so of support, our customers would piss and moan every time we'd tell them that RHEL/Centos5 was hitting EOL and they'd need to upgrade their servers to Centos 6 or 7 to stay supported. Most of them wouldn't even entertain the idea of "upgrading": for them, business as usual was holding on to the existing OS as long as possible, then buying an entirely new server with the latest-greatest CentOS release freshly installed on it, and doing a data migration. I can't even imagine the amount of headache we would have gotten if they needed to upgrade every two years.

_jal 6y ago

RedHat's goodwill will be spent down over the next decade or so, and eventually I fully expect to think of them the same way I do IBM. (Which is, roughly, the same way I think of Oracle.) All of the people I deal with there are the same as before the acquisition, so things have not changed much for me personally, yet. But I am looking at building replacements for certain tools we depend on; the writing is on the wall.

cubano 6y ago
It's easy to want to do, but much harder to justify banging on public companies for trying to increase revenue.
- deleted 6y ago
  [deleted]
- dvfjsdhgfv 6y ago
  Well, if you ignore the history of Red Hat. It used to be "the" Linux company, a paragon of what you can achieve by combining business acumen of the corporate world with complete transparency of the open source process. When the first clones of RHEL appeared, they received C&D letters about the use of "Red Hat" in the name, so they complied and started to replace the branding before recompiling. Who would expect that the only free-as-in beer RHEL clone we'll be able to use will be Oracle Linux.
  - laurent92 6y ago
    I’m deeply interrogated by Atlassian forcefully moving users to the cloud. It’s as if, in 5 years, we developers wouldn’t have a safe Linux to deploy on, and then we’d be required to use Amazon Linux or GCP Linux, the other ones being not officially supported and therefore not insured in case of leak, or not approved for PCI or PII or GDPR or...
- yjftsjthsd-h 6y ago
  > but much harder to justify banging on public companies for trying to increase revenue I assure you, it is very easy to be unhappy with a company for screwing over its users, even if they think it might net them more revenue (bonus points for this being a questionable assumption)

ben509 6y ago

I wasn't clear what's changing that is so problematic, so to summarize this post[1] and various comments: CentOS Stream will track ahead of RHEL and thus will be more like a beta channel, losing the stability guarantees that CentOS users depended on. [1]: https://blog.centos.org/2020/12/future-is-centos-stream/ https://blog.centos.org/2020/12/future-is-centos-stream/

pelasaco 6y ago
so will it be basic the same as openSUSE Tumbleweed for SUSE Linux?
- viccuad 6y ago
  Debian Unstable -> Testing -> Stable -> Oldstable -> Oldstable with LTS Fedora -> Centos Stream -> RHEL -> RHEL with LTS Opensuse Tumbleweed -> Leap -> SLES -> SLES with LTS Debian supports upgrades with major versions, and doesn't bump package major versions between minor versions. SLE/Leap don't support upgrades between major versions, and bump package major versions between minor versions.
  - rombert 6y ago
    Note that the gap between Leap and SLE will become quite small after Leap 15.3, with binary packages for SLE being reused for Leap. It's interesting that while RH/IBM are moving away from the 'community rebuild' model SUSE are moving close. https://en.opensuse.org/Portal:Leap/FAQ/ClosingTheLeapGap https://en.opensuse.org/Portal:Leap/FAQ/ClosingTheLeapGap
  - pferde 6y ago
    It is untrue that SLES does not support upgrades between major versions: https://documentation.suse.com/sles/15-SP2/single-html/SLES-upgrade/#sec-upgrade-paths-supported https://documentation.suse.com/sles/15-SP2/single-html/SLES-... It is, however, true that SLES is less conservative than e.g. RHEL when it comes to bumping software versions between their minor releases (service packs). I remember that they switched from 2.6 to 3.0 kernels sometimes in SLES10 days. Fun stuff.

3np 6y ago

A common criticism of CentOS is that it's too stable. I don't see a mention anywhere of LTS channel of CentOS Stream, but wouldn't the next RHEL release effectively mean that current CentOS Stream channel becomes the LTS alternative, if RedHat commits to providing security backports?

softinio 6y ago

I have noticed more companies adopting Amazon Linux when a few years back they would have used CentOS. I wonder how much this affected the decision. Wish we would see more adoption of Freebsd and NixOS in the future. For now I like my Debian :-)

jolmg 6y ago

The server response on clicking the link lacks a "Content-Type" header. I just thought I'd mention that in case the admin would be here and interested. It's causing a download extension in my browser to show a download dialog on clicking the link. I don't think it's a bug in the extension, but rather a required behavior because of the limitations of extensions. The extension has no sure way to know what my browser's treatment of the response will be after it inspects the body content to guess the type, so the safer thing to do in its case is to show the dialog. I don't think Content-Type is required by HTTP, but it's pretty rare for servers to not include it. Might be good to add it if only in interest of the Robustness Principle[1]. [1] https://en.wikipedia.org/wiki/Robustness_principle https://en.wikipedia.org/wiki/Robustness_principle

SloopJon 6y ago

I somehow missed that Red Hat started sponsoring CentOS a while back, and owns the trademarks. I mean, money and cooperation is great and all, but how could anyone have expected CentOS Linux to continue for long when Red Hat has such a fundamental conflict of interest? Edit: here's the HN post at the time: https://news.ycombinator.com/item?id=7019914 https://news.ycombinator.com/item?id=7019914

Pxtl 6y ago
Yeah, I assume this ends with somebody forking CentOS into another "redhat without redhat branding and license costs".
- deng 6y ago
  Maybe CERN will revitalize Scientific Linux.
  - navanchauhan 6y ago
    Scientific Linux[0] is still maintained ( Although, by Fermi National Accelerator Laboratory and not CERN ) [0] https://scientificlinux.org https://scientificlinux.org
    - j0057 6y ago
      There's no RHEL8 equivalent of Scientific Linux.
    - deng 6y ago
      Yes, maintained, but no new versions since they switched to CentOS. https://lwn.net/Articles/786422/ https://lwn.net/Articles/786422/
- FireBeyond 6y ago
  There is already an announcement for Rocky Linux, from the same person who started CentOS, doing a Monty from MySQL.

ehayes 6y ago

Am I the only one who doesn't get the "risk using CentOS Stream" stuff? Isn't it going to be slightly-less stable RHEL? I actually worked at Red Hat a few years back and almost all work was released upstream-first. The one time I fixed something security-related, the fix was still made upstream first, but just embargoed until the fix was made and released for downstream versions. If I recall correctly, we pushed the upstream fix the day the downstream patch was public. Now I run CentOS in production for a small web app. I get wanting a decade of support for your OS, but at least for cloud-based web apps that seems pretty unnecessary. What am I missing here?

dvfjsdhgfv 6y ago
It's not about risk; many vendors produce software for a specific version of RHEL - we want to use exactly that version, but we don't want to pay through the nose for the support we don't need.
- rhodysurf 6y ago
  Exactly this. You can produce software that is compatible with a RHEL version without paying for RHEL if you’re not even using it
  - yjftsjthsd-h 6y ago
    FWIW, redhat does offer developer licenses of RHEL specifically for this kind of thing. Maybe not quite as nice, but probably workable.
rhodysurf 6y ago
I worked in defense for a while. Every DoD contractor is locked to RHEL version that their DoD targets use as end users. But they don’t need to pay for RHEL support currently because they all just use CentOS instead. This forces all of those companies to finally pay up, which they will def not be happy about.
- abruzzi 6y ago

bachmeier 6y ago

> With the advent of DevOps and SRE, businesses and startups are moving away from the old-school concept of traditional server clusters to running their applications on disposable containers. The trend is clear and true. Developers are increasingly less reliant on a tried-and-true Linux distribution that lasts for a decade. With containers, developers can develop, test, deploy, and rollback with blazing fast velocity. As a user of Linux as my main OS since 2005, and using it partially for years before that, I think another issue is that the quality of software releases is just much higher than it used to be. There used to be a tradeoff between "trustworthy" and "recent". These days it's more "possibility of a problem" vs "absolutely rock solid". And of course the general move to the web. Apps that run in your browser no longer need to run on a server. When I started in my current job in 2004, there was a Debian stable server used for teaching. (It might still be in use for all I know.) This semester I used CoCalc. That's one less use for an ultrastable server.

jmnicolas 6y ago
> These days it's more "possibility of a problem" vs "absolutely rock solid". CentOS is mostly a server distro, I bet 99% of installs are without GUI. So "possibility of a problem" is a no go for a server.
- leotaku 6y ago
  Sorry to break this to you, but if the possibility of a problem is a no go for your servers, you will unfortunately have to pull the plug on them. All software has bugs, so does hardware.
  - jmnicolas 6y ago
    Come on. Possibility of a problem is say Arch, rock stable is Debian / CentOS. There are certainly bugs in the later too, but I never experienced any in 15 years since I run a dozen Linux servers in production.
    - leotaku 6y ago

fractal618 6y ago

No mention of Fedora? Is it not feasible that those currently using CentOS, and don't wish to use the supported Red Hat, will gradually migrate to the CoreOS, IoT or Server version of Fedora? I would think that would be easier than migrating to a different package management system.

twic 6y ago
People use CentOS because it's stable - you can run one version for years, and get security and bug fixes, with no feature changes. This change to CentOS means it won't have that stability, so some will need alternatives. Fedora changes even faster than the new CentOS - a new version every six months! Each version is maintained for just over a year, and the maintenance includes new features.

that_guy_iain 6y ago

I think IBM/Red Hat know someone will fork and carry on with CentOS under a different name. They just won't be paying for it.

60secz 6y ago

Too bad Rocky Linux isn't called DollarLinux

lizknope 6y ago

Looks at cluster of over 5000 machines running CentOS. Doesn't look dead to me.

darksaints 6y ago

The future of operating systems, at least from a non-GUI perspective, is going to look a lot like SeL4 + Nix. A rock-hard provably secure capabilities-oriented kernel, combined with reproducible declarative package management that can handle any combination of dependencies that you want. Essentially this means that the idea of different distributions for LTS, stable, beta, alpha, bleeding edge, etc., goes away completely. You are never forced to update an old package, nor prevented from updating a new package. You get the best of all worlds. And since the kernel is about as secure and performant as you can get, you essentially always have the latest kernel. Drivers get updated as necessary (defined by your policy, not the distribution's) in userspace, potentially as quickly as the moment they are released, with no downtime whatsoever.

mixmastamyk 6y ago
Sounds good, but unless there’s a developer and end-user product approaching the maturity of BlueHat or even Debian it doesn’t seem likely to happen.
yjftsjthsd-h 6y ago
So there's 2 ideas here: kernel, and packages. For the kernel, I'm curious how your suggestion is better than Linux is already. Linux, today, is already a performant, secure kernel with an incredibly stable userspace-facing ABI. For packages, the problem isn't so much being able to install old and new packages (although that's certainly useful); the problem is maintaining a stable version while still fixing bugs and security issues. It's no good just having a packaging system that lets me run a 5-year-old glibc with a fresh-from-git application server if that ancient glibc has multiple known exploits in it. The work in an LTS system is carefully backporting fixes to your chosen old version while holding its ABI stable.
- pjmlp 6y ago
  The CVE database and Linux Kernel Self Preservation project beg to differ in regard to security.
- darksaints 6y ago

g051051 6y ago

> With containers, developers can develop, test, deploy, and rollback with blazing fast velocity. Wow, that has not been my experience with containers.

kkapelon 6y ago
Can you elaborate? Even the basic ability to just spin a container with all your stuff and start developing is an important advance. (especially for cases like python2/3, java5/8 etc) Coupled with the remote containers feature of visual studio, working with containers is now a game changer.
- g051051 6y ago
  Maybe for very small projects. But the scale of things I work on doesn't lend itself to that sort of thing.
ghshephard 6y ago
A lot of this depends on your CI/CD environment. In ours, every single push to every branch on the remote repo ends up building a testing/building a full container environment that is ready for deployment in the cloud - with no differentiation between production/development in terms of completeness. It's fast enough, that some (obv not most) developers don't even set up their local docker environment, and just use the CI/CD deployments to test their work. With the advantage being that if it looks good - single deploy moves all of the production environment to it.
- g051051 6y ago
  They want to implement that sort of thing, but it just doesn't work for very large projects.

dang 6y ago

Recent and related: https://news.ycombinator.com/item?id=25345428 https://news.ycombinator.com/item?id=25345428 https://news.ycombinator.com/item?id=25357885 https://news.ycombinator.com/item?id=25357885 https://news.ycombinator.com/item?id=25354811 https://news.ycombinator.com/item?id=25354811 (a bit) https://news.ycombinator.com/item?id=25360217 https://news.ycombinator.com/item?id=25360217 (a bit)

indymike 6y ago

The only place I run into RHEL or CentOS is maintaining old PHP apps where the web host is running someone's control panel... Often times, it's like stepping into a time machine because it's pretty obvious that things haven't been updated in quite some time. I'm not sure that a 10 year promise of stability is one we want kept (security patches, etc...)

mixmastamyk 6y ago
The whole reason for the distro family to exist is for security patches.

nikolay 6y ago

Without being a free version of RHEL, nobody would have bothered with CentOS. There was White Box Linux back then. Maybe this would give another chance to that forgotten project.

120bits 6y ago

I'm still confused about this? Why everyone is calling it death of CentOS?

teilo 6y ago

Honestly, I won't be sad if this means appliance and VM image providers (for on-prem / private cloud application hosting) switch to Debian en masse. I only use CentOS where Debian is not an option.

tekmonks 6y ago

We are creating the next RHEL based Enterprise Linux - same as CentOS used to be. Targeted first release is January 31, 2021. Looking for both volunteers or people who want to be paid for their efforts. Join us to secure Enterprise Linux as a free (as in beer and freedom) for the foreseeable future. https://monkos.org https://monkos.org