The hypothetical you posed is the actual situation, I am now learning, I have apparently forced on my team. We've ramped up labor 3x revenue preparing product launch in 90 - 180 days. We created an image containing centos 8 , Java , postgres and tomcat a year ago and that what is deployed to beta clients and what we've been testing.
What's ironic is that I sort of went out on a limb with my team by forcing us to go with Linux over Windows and the way I allayed concerns was to ask them to just "wait and see" in hopes that the performance differential would make it a moot point.
edit: after a little thought it seems that moving to RHEL might cost us the least amount of money and downtime. Still sucks and not what we need to be working on right now.
You build software, you ship it on an OS so it works, cool, this makes sense (I assume you need hardware and VM support, not just VM).
Why would you accept additional risk on the OS if you can easily reduce the risk, and ultimate cost, by going with an OS that has vendor support written into the actual contract? RHEL is 11-13 years total, Windows is... I'm guessing my grandkids will be using some form of Windows 10. CentOS is, and always was a community "best effort", with some serious delays occasionally (not often, but it happened).
A RHEL server license starts at $349, I have to assume that's at least an order of magnitude (or two or three) less than the cost of your software based on the technologies involved (sounds enterprise-solutiony). In other words a rounding error overall.
And that is exactly what IBM is counting on. Vendor lock in.
We are switching to Debian-based distros because, frankly, we don't trust IBM not to knife us in the back even on RHEL for more money. Of course we have the advantage of being able to take the time to convert.
CentOS was acqui-hired because Red Hat's upstream for layered products (at the time mostly RDO/OpenStack and oVirt/RHEV) could not use Fedora because it was too far from RHEL a year of two after RHEL was released, could not use RHEL because upstream contributors would have to pay, and could not use CentOS because its releases had too large delays. The solution was to make CentOS releases happen timely by paying people to make them.
These days a RHEL downstream is not enough for the layered products. Some of them require the kind of bleeding edge feature that is backported every six months to the RHEL kernel, and corresponding userspace changes (BPF, virtualization, etc.) and cannot afford waiting for the CentOS release because development must be done in parallel with RHEL. So the solution was to move CentOS from happening after RHEL to before RHEL which is what CentOS Stream is.
I can confidently say that the reasons are technical because other CentOS downstream have the same needs (e.g. Facebook's) and they also want to send patches to CentOS for bugfixes or features themselves, instead of waiting for Red Hat to find out about that bug, or decide they need the same feature. Plus there's no reason for rebuilds to disappear. The SRPMs will still be released by Red Hat.
CentOS was a community project whose leadership and control was taken over (acqui-hired as you say) by Red Hat and then it's core use case for the majority of people actually using it was discontinued. That is a statement of facts that happened as I understand them, not some spin on my part.
If Red Hat had not stepped in, perhaps some of CentOS problems (trouble getting releases out on time) would have been worse, or perhaps some other companies would have stepped in. We don't know, but we do know that CentOS has not been changed to be something different than it was before. It used to be a free re-spin of RHEL. Going forward it's something entirely different.
Red Hat always had the option to stop funding/providing resources to CentOS and name their new thing something else, but they didn't, and now they've effectively co-opted CentOS to be something different than it was originally intended to be.
Because they don't need it anymore. CentOS Linux or other rebuilds can still exist (just not using the name; I disagree with that but I can understand Red Hat doesn't want its name attached to something that might have large delays in security fixes in the future) if somebody funds it or volunteers to do it, just like CentOS still supports Xen but RHEL does not.
Also for what is worth there have been lots of engineering changes to RHEL in the past couple of years that make nightlies (and CentOS Stream) much more stable than they used to be, especially with respect to regressions. Running CentOS Stream is not going to be like Fedora Rawhide or Debian sid.
I understand the business reasons for doing so. I don't agree with anyone branding this as done for purely technical reasons. Having CentOS Stream may be needed for technical reasons. Stopping CentOS 8 is in no way a technical decision. They are unrelated in any technical sense.
If Red Hat just doesn't want to put resources towards CentOS as it traditionally existed anymore, that's their option, but they deserve any flak they get for taking over an open source project just to extinguish it, since CentOS is in no way really needs to be linked to their Stream product. They could just as easily called it RHEL Stream and said it's free, and it would be a less confusing and more direct funnel of people that want RHEL stability into RHEL subscriptions. Using the CentOS name is just a mind-share grab and screwing over an open source community. They control it so can do it, but that doesn't mean I'm not going to call them out for doing so.
If I effectively took control of the EFF and then a couple years later changed the website copy to say that the EFF is a vehicle for litigating cases that kbenson thinks are important, and then actually changed its actions to do so, would you argue the same points? How is this any different? Something that was a net good for many people has been taken over and eventually killed. I think we're all worse off for that.
I don't disagree.
Isn’t that the crux of the problem? CentOS used to be about “us” (the users), not “them.”
In particular I started doing that and I got to the Sep 2019-Dec 2019 range, around the time CentOS Stream was launched. At that time this:
> For users, we offer a consistent manageable platform that suits a wide variety of deployments. For open source communities, we offer a solid, predictable base to build upon
was changed to this:
> CentOS Linux is a consistent, manageable platform that suits a wide variety of deployments. For some open source communities, it is a solid, predictable base to build upon.
They're a business ... are you honestly and in good-faith actually confused about this outcome?
This is a really smart more on their part to get people to stop doing precisely this, and getting them to pay money for RH. Pepople who are not willing to pay (me included) are now rightly annoyed, but we were never their customers in the first place, so we don't really matter.
Now? “¯\_(ツ)_/¯“ Probably Debian.
I’ve always used CentOS for clusters, but part of the reason for that is that there are some research packages that support RPM installation, but not deb. At least this gas historically been the case.
If a large amount (maybe even a majority) of users have to switch away from CentOS and RPM packaging, I think we’ll see an acceleration away from RPM as a default option.
So, in that way, I think we do matter, but just not on the balance sheet.
I have a hard time imagining, and the only scenarios that come to mind are those where things have gone awfully haywire.
I'm sure I'm missing something. Enlighten me?
Depending on how good is the source, its usefulness and dependencies, packaging it to Debian is pretty straight forward. The dh_* helpers[2] does the job automatically most of the time. There is also tools for helping with specific languages, like dh-make-golang, dh-python, etc...
[1] https://packages.debian.org/buster/alien
[2] https://manpages.debian.org/testing/debhelper/debhelper.7.en...
It’s not only the differences in the packaging format that you have to take care of. There’s also version differences, path differences, dependency handling, and many other stuff to take care of. These are the kind of tasks which can’t be automated away and require non-trivial amount of work.
For organizations that maintain tens, hundreds, or thousands of CentOS packages that spans multiple teams, moving to other distros would be time-consuming and costly. It would certainly pay off if it was driven by technical reasons, but for organizations that are forced to switch by this announcement, this is just pure overhead.
That's his stack...
>So unless there’s some magic piece of technology that can take CentOS RPMs and make it work flawlessly on any Linux distro,
It's not magic, just alien.
> That's his stack...
What’s your point and when did I ever mention Java?
> It's not magic, just alien.
Dumping the contents of an RPM archive on random distros is never going to work except for the most simple of cases.
That says allot about you packing hygiene, and you don't dump it..that you can do with tar alone. You convert it to a deb.
I suggest you read the source code too, because otherwise you can cause real damage if you use it without understanding how it works.
Though my experience with package manager is that dependency management is hell (rife with potential conflicts), so I do see the problem a bit better.
Still, it shouldn't take that long to fix? Like a few days of sprint to setup Nix or something like that?
As for pinning packages, that’s only practical if you’re using Nix. As much as I prefer Nix over RPMs, not all of us have the pleasure of using Nix at work. It’s kind of a bummer because Nix packages are so much easier to work with and maintain compared to the competition.
If you run a for-profit operation, and downtime is costly, you (or your VP of eng) want a way to pay for immediate assistance from the OS's maker / distributor, when (not if) things go wrong.
There is a difference between asking "how do I ensure there is one throat to choke when things go wrong?", and "how do I minimize the potential for things to go wrong?"
RHEL is a decent solution if you are trying to answer the former question (or both), but many budget conscious orgs focused on the latter and chose CentOS. Red Hat has now pulled the rug out from under them by trimming eight years off the EOL previously committed to with little notice.
EOL in this case means "no security updates" so even if your org was prepared, technically, to deal with a zero-day for example by rolling out an update in a timely manner without relying on paying a vendor for hand-holding, that option has now been eliminated.
Essentially, you now only get the stability and problem-minimization if you also pay the vendor for support. Otherwise you're stuck with a (relatively) unstable rolling release that will keep your internal teams very busy with a constant stream of minor issues, or potentially trying to roll-your-own updates or backports after the EOL for anything serious.
It's difficult to see this as anything other than a naked, money-grabbing betrayal of users.
https://web.archive.org/web/20201101131417/https://wiki.cent...
That's like polar opposites of stability and bleeding edge.
I will argue that there is less maintenance when handling virtual machines images, because it uses less bandwidth and need less tooling around it comparing with container image based infrastructure.
But in general both are nothing more than the golden image concept.
As a sysadmin i have never heard of this and es tun 800 VMs.
A really big chunk of the world's traditionally shared hosted websites run on CentOS, because most commercial control panel packages and hosting automation systems are built for that. A rebadged CentOS is also AWS's default distro.
Wonder of the hosting industry, AWS included, will build a new stable clone of RHEL 8's upstream security patches. There are some big companies, like GoDaddy in there, whose business models are unlikely to accommodate for RHEL support subscriptions.
This is truly a bummer, and if someone doesn't pick up the pieces and continue offer RHEL rebranded, there's no(?) open sauce operating system with a decade-long support lifecycle. I wonder if this might cause an increase in unpatched servers and appliances when the alternatives offer five years at best.
ScientificLinux and CentOS rules all HPC clusters. Clusters are like enterprise servers. Big, monolithic, rarely upgraded. They're upgraded in one big-fell swoop and left to run.
There'll be another clone of RHEL since HPC can't accept CentOS Stream as the alternative. The whole infra is too big to move to Debian too.
So with today's announcement, a new distro is born. Also Greg (CentOS' founder's) domain (HPCng) is very telling...
We'll see. We're in for a hell of a ride. If you excuse me, I need to dust-off my XCAT servers...
Scientific applications can be very picky about the libraries they use or need, down to minor version since the results they produce are very, very precise. Even if not very accurate, you need to know the inaccuracy. An optimization in a math library can change this and, it's not something we want. Also program verification and certification generally includes versions of the libraries used.
Piecewise upgrades are a no go too. Your cluster generally can't work well in heterogeneous configurations (due to library mismatches) and draining a node is not a straightforward task (due to length of the jobs). If your cluster has a steady stream of incoming jobs, reducing resources also means queue bloat and recovering it is not easy sometimes. If you want to drain the whole cluster, it takes almost 2-3 weeks so, you lose ~1 month of productivity. When you start an empty cluster to churn its queues, its saturation takes time so, it doesn't go to 11 directly.
Also, worker nodes are highly isolated from the user's point of view. No users can log-in, only known people submit jobs, etc. Unless there's a rogue academic trying to do nefarious things, the place is pretty safe and worry-free. In past 15 years, we got two rootkit infections due to a server which can be world-accessible by design. Other than that, nothing ever got infected.
At the end of the day, this approach has some valid reasons to be alive. It's not that we're a bunch of lazy academics who refrain from applying good system administration practices. :D
Addendum: The images generally get updated when new hardware is added, since new processors tend to work better with newer kernels. Also sometimes we bit the bullet and update all the cluster at once. XCAT helps a lot in this space. If your image is sane, you can install batches of 150+ servers in 15 minutes while sipping your coffee.
All repo settings will look to local repo so we'd have no dependency problem or version creep if we need to install an additional package.
Didn't completely think how to handle the occasional emergency update though.
Also, we need to compile in some packages. Hope they won't break. High performance stuff needs optimized/customized compilations.
I just want to add: Hope that the packages in CentOS stream won't end up too cutting edge for the scientific software community. These communities move slow due to stability requirements. We'll certainly see but it might be another potential problem.
I think HN is the only place where you can casually provide feedback and get answers about an OS project from one of the core people in it. Fun!
Glad to meet you, BTW.
Seems like the kernel was last updated in May.
$ uname -r -v
3.10.0-1127.8.2.el7.x86_64 #1 SMP Wed May 13 10:45:47 CDTThe license for RH precludes you from running unlicensed RH, if you have any licensed RH. I don't believe SuSE does the same.
There is a page describing the conversion: https://linux.oracle.com/switch/centos/
They have a shell script to convert a CentOS install to Oracle Linux, so you can buy support if you want.
The converter only works with versions 5, 6, and 7.
It does not work with CentOS 8. It would be nice if that could get updated.
"Out of the frying pan into the fire"
And I'll forever hate them for what they did to Java (and in setting the precedent that APIs can be copyrighted).
- Brought MaximeVM of research and creating GraalVM
- In the process of adding value types to Java
- In the process of adding support for explicit SIMD in Java
- In the process of adding co-routines to Java
- Added type inference support
- Added pattern matching
- Added record types
- Integrated J/Rockit support for JIT caches
- Made Flight Recorder available in OpenJDK
- In the process of making AOT compilation work, instead of requiring you to fork money for a JDK with AOT compiler like Sun used to do
- Integrated almost pauseless GC with support for TB sized heaps
- Long term roadmap to replace C++ with Java on the JDK, as yet another proof of Java capabilities
- In the process of having a JNI replacement
And plenty more, https://openjdk.java.net/jeps/0
I hope they squash Android Java, Google had the opportunity to buy Sun after screwing them up.
Anything else is just FUD.
Do you really think that would be a reasonable thing to happen, and good for technology and the world in general? It seems disproportionately punitive, and the "right" thing to happen only if all you care about is watching things burn.
And you haven't addressed the precedent that's been set that APIs are now copyrightable. Do you like that precedent? Do you ever use anyone else's APIs in your daily development, and do you like how that now opens you to huge potential liability? Is all of this worth it just because Google didn't acquire Sun??
Oracle creates cool tech in the legacy of Sun because it impresses the right people who can influence the decision makers.
To recap: "Hey, Oracle's these new toys are capable and fun to use. We can do much more with them. Can you buy these for us, engineers so we can be happy like children again?"
That said, their supported versions of Java and Graal are expensive. Some things never change.
The supported versions of Java and Graal are the same price as any other enterprise product.
They put the effort, someone has to pay for it.
Where are the free beer JIT, AOT and GC implementations for free beer languages that outperform Java?
If I understood it correctly, a programming language has some foundational design decisions (including its memory and execution model) to attack a particular set of problems?
The people capable of achieving that, naturally have bills to pay.
Not always. As I aforementioned in another thread, we also need C/C++, Python, Perl, etc. as is since they fill different roles and attack different problems.
I've written Java, C, C++, Python, Perl, PHP. Had to abuse some of them to fit roles which they're not designed to do. At the end of the day, these languages satisfy different needs and solve different problems in different scenarios. Java wouldn't be able to do all of them. Neither C++, nor Python.
As I said, you may like Java but, it's not the king of every programming language. No programming language is king of everything BTW.
PHP was mostly driven by Facebook needs.
None of them is any different from Oracle.
And apparently you fail to understand who has contributed to state of the art implemetnations of AOT compilation to toolchains like LLVM, hint the companies that HN loves to hate, it weren't weekend and late night coders.
I'm pretty aware that nearly all clang/LLVM development is driven by apple.
On the other hand you apparently fail to understand my point of view about Oracle and Java ecosystem. I'm neither against Oracle nor Oracle's development of Java or Java's development in the interest of Oracle mainly.
I'm only against Oracle's motives about making Java a walled garden and usage of this programming language to extort license money from others.
On the other hand, I personally use OpenJDK runtime countless times every day, knowingly or unknowingly. I'm written Java in the past and have no reservations or bad things to say about it. Contrary to your view about other programming languages, I'm pretty neutral against every other programming language.
> C and C++ development is sponsored by the corporations of Apple, Microsoft, IBM, Oracle, Google.... PHP was mostly driven by Facebook needs.
There are no news for me here either. Development of a programming language or any tool with input from its users is a non-issue. Also, every user has needs from the products they use, so they will provide feedback and communicate their needs.
The difference, I want to highlight and highlight again, none of these corporations can use C++ or PHP or Python to extort license money from their customers. PHP is owned by Zend, so they may try. C++ is almost public domain now. LLVM is under apache license. Either way I use GCC which is GPL. Python is 20+ years old and is also almost public domain.
Contributing to a tool to get what you want is different from owning a tool and to use it to extort licensing money is different.
Either way, as aforementioned, I have nothing against Java, contrary to your views against other programming languages.
I just hope that it's true. We really need that.
I guess the "community" would love to keep using Java frozen in version 6.
[0] - Only IBM considered it, which from these threads people here wouldn't be happy anyway.
They're not a nice entity unless you pay money to them and they're greedy. They always want more. Also, their hardware can fail in strange ways and they'd shrug it off.
I've met with some nice people who migrated from Sun but they all say that the terms they work are draconian.
I like Java too but, developing a nice language doesn't make Oracle good. Don't get distracted [0].
> I guess the "community" would love to keep using Java frozen in version 6.
Python doesn't stop. C++ doesn't drop. Even brainfuck doesn't stop. It'd have prevailed. OpenJDK is one fruit of the project. After removing patent encumbered image processing stuff, OpenJDK just took off. Yes, it's still part of Oracle in a sense but, OracleJDK is compiled from OpenJDK, not vice versa. Again, don't get distracted [0].
IBM, Microsoft, Google, Apple, Oracle, Amazon, Sony, Nintendo
So much better.
These companies employ people who contribute to these programming languages. So the model is somewhat different.
I'm not that oblivious about the real/programming world.
Oracle's governance is different from this. C++ is an ISO committee. Python has a lot of working groups, etc.
Java is much more centralized when you compare with others.
Should I also start listing the dark sides of each company that seats at ISO C and ISO C++ table?
Python working groups also need money from those corporations, and Python is yet to provide the performance levels of Java, so much for free beer development.
I know Java has stakeholders but, what I'm trying to say is the table is at Oracle's HQ, not somewhere else.
> Should I also start listing the dark sides of each company that seats at ISO C and ISO C++ table?
A primer would be nice, actually.
> Python working groups also need money from those corporations, and Python is yet to provide the performance levels of Java, so much for free beer development.
I've never alleged that Python takes no money from corporations and, Python doesn't aim the performance of Java. Their byte-code even doesn't get optimized. Instead Python prefers native libraries for performance. SciPy, NumPy, PyTorch and others obtain native performance on any system they run and, it's enough for Python.
No need to move the goalposts and compare apples to oranges. Python is never meant to replace Java. Java is not meant to replace system programming languages like C/C++. You may like Java and it might help you to pay the bills but, pushing other languages around just because they don't fill your needs from your point of view is not the correct stance.
Microsoft, the evil company over here, that keeps being compared to Oracle. Several C++20 features like Modules and co-routines were driven by their VC++ implementations.
Apple, the company hated over here by bringing the end of open platforms, without it LLVM and clang wouldn't ever exist.
Google, the spying company and forking Linux with Android, the second major clang and llvm contributor.
IBM and Red-Hat, with their own Linux agenda pushing stuff like systemd hated over here, major GCC contributors.
You are missing the whole point with Java, it isn't about Java, rather all mainstream languages just like Java only move forward with dirty money (from HN point of view), but hey it is cool to hate Oracle.
Hint they are one of the first enterprise contributors to the Linux kernel and have been ever since.
Do you also feel like removing Oracle contributions from the Linux kernel?
All big companies have a number of dirty deeds in their history, that's right. But I'm not a person who generalizes this to overall companies, incl. Oracle.
I personally don't use Microsoft OSes, however I have several licenses since my family uses them. I also have a personal lincense (albeit it's booted once a year) for some odd application I may need if stars align on the Friday, 13th. OTOH, I always have praised them for their ergonomics research, resulting hardware and their choice for keeping Kinect open back in the day. I won't ever trust them but, I'm not delusional.
I don't use Android devices or Chrome. Only some Google services. However day by day, I'm using their services less and contemplating to switch over to something like Proton. Also I loathe them for making pseudo-open stuff and closing it later. However, they're pioneer of software defined network due to sheer size of their networks.
I have Apple laptops and iPhones but, my main desktops/workstations are vanilla Debian boxes and always will be.
> You are missing the whole point with Java, it isn't about Java, rather all mainstream languages just like Java only move forward with dirty money (from HN point of view), but hey it is cool to hate Oracle.
No, I don't hate Oracle per se. I only hate their money greed. Especially the money greed via Java. I've used their ZFS appliances after they acquire Sun. They were nice up to a point. I applaud them for the enterprise ecosystem around their OracleDB. I like how they managed to fuse Sun's hardware with their software. But I don't like their greed. Maybe this greed is required from their point of view, but I don't like it.
Similarly I'm not keen on nVidia's strong-arming everyone and pushing people around. Also I don't like their arrogance. Yes, CUDA is nice, it's the de-facto standard for now but, it doesn't justify bullying others around.
Microsoft also contributes to Linux Kernel, I'm aware who's doing what.
> Do you also feel like removing Oracle contributions from the Linux kernel?
No, but I feel like you may like replacing it with a Java re-implementation running on a bare-metal HotSpot VM.
Not liking a part of something doesn't need to spread all over that thing. Do you leave your car to a junkyard because you dislike the engine sound at a particular RPM? Do you change your PC because its USBs are a little slow to a similar model? Same idea.
Put another way, if you jump ship from CentOS because IBM caused Red Hat to change it into a funnel to pay them money, if you landed on Oracle, you might be setting yourself up to do it all over again fairly soon.
You're underselling it: Oracle grab money in a way that I would describe as "aplomb ruthlessness". They've managed to fuck no less than 3 orgs I've worked for.
If they ask you for a license count or how many cores are in use, ignore them. Larry Ellison doesn't need another boat.
"Unlike many other commercial Linux distributions, Oracle Linux is easy to download and completely free to use, distribute, and update. Oracle Linux is available under the GNU General Public License (GPLv2). Support contracts are available from Oracle. "
Been burned by them before. Not at liberty to give details, but the outcome is that I never choose Oracle for anything for the rest of my career. Even if it would save time and money.
Writing like this makes me very wary of putting Oracle Linux anywhere near my employer's systems
https://www.computerworld.com/article/2992597/law-firm-warns...
https://blog.dbwatch.com/how-to-avoid-oracles-licensing-trap...
Then there's the famous lawn mover quote from Bryan Cantrill https://news.ycombinator.com/item?id=5170246
Community based sounds better to me.
> But if you're here, you're a CentOS user. Which means that you don't pay for a distribution at all, for at least some of your systems. So even if we made the best paid distribution in the world (and we think we do), we can't actually get it to you... or can we?
We only need RH equal of Debian, since the software we use generally have explicit CentOS/RHEL support.
I think that's a gray area. For example RHEL has some support branches where they'll produce security updates for minor updates. For example you can pay a lot of money and you'll get RHEL 7.2 with security updates. They won't release sources for those packages unless you'll ask for those packages (you, as a paid client, not you as nobody in the Internet). But if you'll ask sources and then publish those sources in the internet again and again, so other entity like CentOS or whatever could pick them up and build CentOS 7.2 LTS, they will terminate your contract.
So that's a weakness in GPL. You won't break any law, but they'll just terminate contracts with those who publish those sources. So those sources are effectively unavailable for a large public.
Currently they publish their mainstream branch sources to the public. But they could stop doing that any time and only provide those sources to their clients on request.
If the code in question is licensed under the GPL and Red Hat isn't the owner of the code, then I as a rando on the Internet can ask them for the source and if they don't provide it, the person who does own the code can sue them and revoke their license to distribute said code. And I'd say that the majority of code in RHEL is not owned by Red Hat.
This is why the cloud providers can get away with custom in-house patches to the Linux kernel.
>3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:
> b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
Everyone was doing network distribution of GPL software long before GPLv3 came out, effectively treating a download as a medium customarily used for software interchange. Not a physical one, but GPLv2 does not say anything about that.
https://aws.amazon.com/amazon-linux-2/#Resources
AL has had enough work put into it over the years that, while it may have been inspired by CentOS/RHEL originally, calling it a rebadged CentOS is not accurate these days. A full and competent team maintains it. While it's clearly made similar architectural choices, those are also for compatibility reasons.
However I doubt that support is available for anyone not running it on AWS, at least not from AWS -- but then again folks running CentOS weren't paying for support from RHEL either.
I also wonder if the announcement is as bad as people make it sound. I'm not an expert in Linux distros, but my understanding is that AL2 also uses a streams-like model, in that it provides long term support (patches for existing software) while also making new software available. My understanding was that, while it is inevitably versioned by making artifacts like VMs and containers available over CDNs ( https://cdn.amazonlinux.com/os-images/2.0.20201111.0/ ), the expectation is that most users will always launch the latest version, relying on its backward compatibility. Perhaps someone who knows more about the specifics of its release model could comment.
Works ok on a RPi.
I'm really curious whether Amazon Linux is accepted by Linux guru or not. It seems that there are very little docs for a distribution.
Q: What does this mean for users of CentOS Linux?
The creation of CentOS Stream provides a new mechanism for partners and community members to add innovation to the next version of RHEL as it’s being built instead of after it’s built. We also recognize that there are different kinds of CentOS Linux users, and we are working with the CentOS Project Governing Board to tailor programs that meet the needs of different user groups.
In the first half of 2021, we will be introducing low- or no-cost programs for a variety of use cases, including options for open source projects and communities, partner ecosystems and an expansion of the use cases of the Red Hat Enterprise Linux Developer subscription to better serve the needs of systems administrators and partner developers. We’ll share more details on these initiatives as they become available. For those converting to RHEL, there is guidance available today for converting from CentOS Linux to RHEL.
[0] https://www.redhat.com/en/blog/faq-centos-stream-updates#Q10
Either that, or Debian's user-base will grow a lot within the next few months. :)
Whether or not Red Hat "has to", Red Hat is an all open source company and does and will.
IBM is open source friendly, but the days of RH being an "all open source company" ended in July 2019.
Other RHEL-clones: Oracle Linux (best one), Springdale Linux.
Other alternatives: openSUSE Leap and Debian. I am not even listing Ubuntu because I hate it since snaps.
But something like Springdale, given resources, might be able to provide. They're still tracking RHEL 7, though.
Debian and Ubuntu, which offer five years of Long Term Support are the next best thing available, and that's already kind of tight for long-term deployments of self-hosted, old-fashioned business software.
Debian is particularly impressive, since they, on paper, aim to support all packages with security fixes, whereas Ubuntu's main repo is a lot more limited.
OpenSUSE Leap versions seem to get three years, which really isn't enough software that needs to just work for a long while.
Here's the full ISO for 8.1: http://puias.princeton.edu/data/puias/8.1/x86_64/iso/
And then you can add the repos to update to 8.3: http://puias.princeton.edu/data/puias/8.3/
Or you can take the small ("boot") ISO and install 8.3 directy: http://puias.princeton.edu/data/puias/8.3/x86_64/os/images/
In fact, they are even building Springdale Linux 8 for i386, which RHEL and CentOS never did.
If you need more than three years on openSUSE Leap, then you need to upgrade to SUSE Linux Enterprise Server.
Remember that, in Ubuntu, the majority of packages are actually ONLY supported for nine (9) months -- not the full 5 years!
What are the track records of the claim?
I'm sure Ubuntu will patch stuff up if some vulnerability shows up outside of main that gets patched upstream or elsewhere.
I claim no deep expertise on this, but for a distribution of 56k packages, this looks quite good https://security-tracker.debian.org/tracker/status/release/s...
To anyone here who's worked secops and has to track these things, I'm really interested to hear opinions about how well Debian follows up on this
I claim no deep expertise on this, and I assume Canonical has more money to throw at this. Or are there contributions to Debian security in the form of paid personnel?
This is actually quite interesting to me, anyone with real knowledge of the subject is welcome to interject.
My best hope is that the major hosting vendors, or maybe some industry consortium might offer resources for this.
But the point is indeed that there are resources and infrastructure, so one might be hopeful that there will be a good outcome.
One possible outcome would be increased demand and resources for Debian and/or Ubuntu and I definitely wouldn't mind that (five years of support isn't all that much in IT). Realistically though, a lot of people need RHEL for free and I suspect there will be a way.
On the first point you are correct. It's not exactly RHEL7.
On the second point, Amazon provides images for running on prem[0]. We run a lot of dev AmazonLinux2 VMs on prem so that the local computing environment matches the deployed EC2 environment.
0: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-l...
So a few years ago when Debian decided to have faster release cycles I migrated all my VM to CentOS: once the OS is installed I don't want to think about it for the next 10 years.
I still didn't finish my Windows 7 to 10 on all my desktops, I'm swamped with users wanting to do Zoom / Teams / Skype / Whatever visio conferences, I have 3 new dev projects for 2021 and now I have to migrate all my CentOS VM...
Yeah, thank you RedHat I won't forget / forgive that.
https://www.redhat.com/en/blog/faq-centos-stream-updates#Q10
You've burned people. Don't expect to then sell them Aloe Vera.
I have nothing against you in particular, but if you know the guys that made this decision tell them the same words that Linus Torvalds said to Nvidia.
I will never touch anything Red hat ever again because I will remember how after a quite sucky 2020, Red Hat made sure my 2021 would not disappoint either.
No, they won't migrate to paid RHEL. This is massive goodwill burn for RH.
Well, you've panicked people who are/were moving forward with CentOS 6/7 to 8, and not on RHEL because no budget. "Don't worry, sometime in the next 6 months there might be useful info for you, or there might not".
People aren't going to stick around waiting for that information. You've pulled the rug out from under us and we need to plan sooner rather than later. RHEL isn't do-able due to cost, CentOS isn't do-able because you've just killed it, so away we have to go.
I think people would panic less if the CentOS Linux cancellation were announced at the same time as these upcoming announcements. Without them, there's a lot of uncertainty and it's hard for anyone depending on CentOS 8 to plan.
Here [1] is an example of what I dislike. That page doesn't explain if a subscription is for 1 host or all my hosts and it doesn't explain if it needs to be renewed annually or if I get a perpetual license after the first year of support.
I currently have 11 (extremely light usage) CentOS VMs running, but almost everything is Docker containers. I could likely consolidate it onto a single, bare-metal host if I wanted. It would be worse for me, but I could get a single $800 license instead of $8800 for 11 licenses. It's a moot point though. $800 is already too much for the value I'm getting out of it.
I could use the developer program, but I use an issue tracker to track work I do and I back up the whole system nightly. Technically that's production (to me), and I've seen IBM bait and eviscerate someone for licensing using extremely unethical tactics, so I'll never use something that isn't very explicitly free for production.
I think RHEL is technically superior to Ubuntu, but Ubuntu is a far better product when it comes to support lifecycle, licensing, and support. I can spin up an Ubuntu server and unlimited VMs with the promise of a reasonable lifecycle and the option to click a button and buy support.
Where is that in the RedHat world? If RedHat would have released a product like CentOS Stream, but with RHEL branding and a dead simple way to go from a free, community supported version to a paid, commercially supported version then for people like me it makes sense to be the "beta" tester. I think it's a fair trade. Downtime doesn't have a huge impact on me and I'm willing to spend time bug hunting / reporting bugs.
TLDR; The licensing is a massive hassle and is a terrible value proposition for small users. You're not winning any mindshare unless it's as simple as Ubuntu makes it.
1. https://www.redhat.com/en/store/red-hat-enterprise-linux-ser...
It kind of does matter, though, because at least for me, I am much more familiar with my home systems than what I use at work.
I started out using Redhat at work, so I migrated my home lab to CentOS to gain more familiarity, which meant that when new projects started, I advocated for Red Hat. But if I'm forced to migrate to a different production grade distro at home and develop expertise with it, the next time there's a question about what OS to use for a new project, I can imagine myself pushing for the one I will have spent the last few years tinkering with at home by that point instead.
I think the movement to this outcome already started in January 2014 with this event:
https://www.zdnet.com/article/red-hat-incorporates-free-red-...
Have you considered Ubuntu Server? "Being boring" and "having no vision" are frequent critiques of Ubuntu, which(as we probably all know) can be the highest possible compliment in some scenarios, like servers. They also have pretty decent LTS.
It is like a completely new OS to me, and I've been hacking on UNIXes for 25 years now.
> In 2009, Red Hat decided to deprecate ifconfig as the default command line network interface management utility, because the “net-tools” package (which provides ifconfig) did not support InfiniBand addresses (commonly used interconnect in high-performance computing applications).
So, many of the things that make Ubuntu look like a new OS to you, were actually decisions made by RedHat years ago, and they will also be present in newer RHEL versions.
I find it easier to configure than SELinux.
Specifically in RHEL/CentOS/Fedora I like that everything in the base system is reasonably well confined out of the box - including random container images that users insist on downloading/running. I don't know if AppArmor is even capable of doing this:
https://access.redhat.com/documentation/en-us/red_hat_enterp...
i.e., if I 'docker run --rm -it debian:unstable sleep 300' twice, then:
$ pgrep sleep | xargs ps -Z LABEL PID TTY STAT TIME COMMAND system_u:system_r:svirt_lxc_net_t:s0:c563,c603 1595289 pts/0 S+ 0:00 sleep 123 system_u:system_r:svirt_lxc_net_t:s0:c25,c163 1595325 pts/0 S+ 0:00 sleep 345
Both containers are confined by the svirt_lxc_net_t domain, but since they have different labels, they aren't able to interfere with each other, or the host system, even if the process inside the container is running as uid 0.
Sadly, the danger of running on free software.
Even more sadly, this puts a bad taste in peoples mouths, making them hesitant to start new projects on free software.
CentOS offered free software, but with unpaid community support, which isn’t guaranteed at all as there’s no contract.
This is an unpopular opinion but this is why I prefer Ubuntu over Debian - there’s a corporation on the other end that’s being paid to update software, and if you choose, you can always upgrade to paid support that is backed by a legally binding contract.
We could debate forever about whether fault lies with projects overpromising, or users having unrealistic expectations, or whatever else, but I don't think that changes the situation.
If you have are paying someone for the software/support, shit still happens, but you have a relationship and ways to get recourse.
So I defaulted back to CentOS 7. Which I now realize was lucky.
I personally run a CentOS 7 server (as do members of my family), and was planning on upgrading them all to 8. Luckily, I didn't get round to it yet. I guess I'll have to consider an alternative. For my server I want a boring, stable OS, so I'm definitely not using Streams. This is going to ripple throughout the whole industry, as CentOS is used all over the place, from regular home users to businesses (and things like CloudLinux).
It's very disappointing that Red Hat can't see the damage they'll do not only to the community, but to themselves too. Someone will come along and take the CentOS user base, and it won't be Red Hat :(.