Wonder if the web hosting industry will rebel and build another RHEL clone project that just gets the 10-year supported patches. Red Hat still has to release the patches, right?
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.
There's a silent but relatively big user base of CentOS in HPC and scientific computing.
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...
Okay, this is a serious question. For me, not an official RH position. In my time in HPC, nodes were baked with a specific image and then that basically never ever got updates. As I came to that as a sysadmin from other areas, I found that somewhat horrifying, but it seemed pretty universal. Have things changed such that applying patches regularly (like, more often than once a month or so except in emergencies) is a thing?
Not much, but in our setup the image is not something which can evolve or change over time. This practice has some very practical reasons though.
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.
We will certainly try. Need to mirror a repo, freeze it and update our installation infra so it looks to the local repo rather than the national mirror.
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 can totally reassure you on your last concern: everything that goes into Stream is approved for a minor release in RHEL. That's not changing at all. Cutting edge is still Fedora's turf. :)
To be clear, I'm RHEL and CentOS _adjacent_, rather than actively _in_ them. But I think (rough launch and more than a few communication issues) aside this is generally gonna be positive.
I think that's because HPC users are largely non-technical developers. We changed a DHCP schema at one point and had a bunch of angry academics in the IT office because their Matlab scripts were broken. Many of them had been hard coding IP addresses into the code itself.
When your company software stack is turned inside-out by Oracle reps to look for unlicensed JVM's on penalty of really big fines (sorry, opportunities to buy more Oracle software) all those nice-to-have features don't seem to matter that much.
> I hope they squash Android Java, Google had the opportunity to buy Sun after screwing them up.
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??
They've done all of them because they think it'll allow them to earn more money with less effort on the long run, not because of the sheer love of computer science and research.
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?"
I don't think that's really true. My understanding from talking to people there is that Java funding was increased for so many years despite losing money because Larry Ellison just thought it was cool tech and they use it a lot. Likewise, GraalVM is so well funded largely because it's cool and Oracle doesn't have many cool R&D projects. It's not clear it's all that commercially driven when you observe that so much of it is open source.
That said, their supported versions of Java and Graal are expensive. Some things never change.
Do we need to have free beer JIT, AOT and GC implementations for every language?
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?
> What we need are top level JIT, AOT and GC implementations, anything else is just going backwards.
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.
C and C++ development is sponsored by the corporations of Apple, Microsoft, IBM, Oracle, Google....
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.
> 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 don't think that's really true. My understanding from talking to people there is that Java funding was increased for so many years despite losing money because Larry Ellison just thought it was cool tech and they use it a lot. Likewise, GraalVM is so well funded largely because it's cool and Oracle doesn't have many cool R&D projects. It's not clear it's all that commercially driven when you observe that so much of it is open source.
Development of programming languages by corporations is not something I object but, all of the stuff told about Oracle here is correct.
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].
It is naïve to think that the employees of the companies aren't driving their employers agenda, regardless how "independent" those governing bodies are.
Of course but, there are sub-committees which melt all the agendas into a single pot and create solutions which makes everyone happy. Also some of these languages have or had BDFLs.
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.
Nope, IBM, Azul, Amazon, Red-Hat, Alibaba, Twitter, Microsoft also seat at the Java table.
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.
> Nope, IBM, Azul, Amazon, Red-Hat, Alibaba, Twitter, Microsoft also seat at the Java table.
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?
And none of the companies you're listing here have been at all litigious about those programming stack contributions like Oracle has been. You're disproving the point that you're trying to make here -- Oracle is uniquely bad about this.
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.
I don't think many people who want to use something stable like CentOS, but don't want to pay for a RHEL support contract would want to pay Oracle for RHEL-but-with-Oracle-sprinkles-on-top
Not to mention Oracle is not known to leave money on the table, and if they see they can start charging for Oracle Linux because there's no large well known free version, I wouldn't put it past them.
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.
> Not to mention Oracle is not known to leave money on the table
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. "
never, Ever, EVER trust Oracle. Especially with something as important as an open source product. Evidence: Oracle's Sen. VP Glueck statement that "There is no math that can justify open source from a cost perspective." No chance you'll ever see me running OEL.
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.
The fact that you aren't comfortable discussing the details of how you were screwed by Oracle, even anonymously on the internet, is really all anyone needs to know about Oracle.
From their page, does this even read professional? Sounds like some startup wrote it trying to make them look bigger than they're.
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?
My thoughts exactly. All our workstations and small-ish clusters run CentOS (we don’t maintain ourselves the large clusters so these are not our problem). It’s going to be a huge pain.
> Red Hat still has to release the patches, right?
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.
> 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).
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.
That is not how the GPL works. The GPL only entitles you to the source code of software for which you have been provided binaries. If the software has not been provided to you in binary form, you have no claim to the source.
This is why the cloud providers can get away with custom in-house patches to the Linux kernel.
Yep, this is actually one of those things Stallman has been saying for decades and people like to ignore: the GPL doesn’t mean all code must be in the public domain, only that users of a given program should be able to modify it. There are a number of ways to allow for that while still keeping distribution restricted.
You can only ask them for the source if you already have the binaries and you've gotten them from Red Hat. If you got the binaries from someone else, you can ask that someone else.
Can you help me understand why GPL v2 3(b) doesn't obligate Red Hat to provide source code for the kernel, as an example, to anyone who asks?
>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,
Really? When I do a yum update on my rhel systems to get the latest updates from rhn, they never download the source code. Now that I think about it, I don't think RH has even sent me any kind of medium which is commonly used for interchange.
GPLv2 was written in 1991. GPLv3 changes the wording in Section 3(a) to "durable physical medium", but at the same time it gives other possibility including "Convey the object code by offering access from a designated place (gratis or for a charge), and offer equivalent access to the Corresponding Source in the same way through the same place at no further charge".
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.
I think that access to the private repository is considered a distribution. You have access to the sources with `dnf download --source` or something like that. The fact that those sources originally are on the remote server probably is not significant in 2020.
Amazon Linux 2 could be a viable alternative. In addition to being available to run on AWS, it's also available as a container image and in various machine image formats:
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.
We had some folks try installing Amazon Linux images in our network. They spammed the network looking for a nonexistent link local metadata service, which is how we found out about them.
I tried to find official information about Amazon Linux but I can't find. Is it based on what distro? (maybe RHEL7 but not mentioned) How it's compatible to EPEL and other software for RHEL even though they are different from RHEL? (at least they uses different glibc version)
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.
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.
LOL at the corporate guff. The primary use case of CentOS is "I want to run RHEL without paying anyone anything". The best way to "serve that need"? Don't kill off CentOS 8.3+.
I mean, that's de-facto what CentOS was; RHEL but non-paid and with different branding. But I mean... they were built from the (exact) same sources, so similar that you could convert between them by un/installing a few packages.
The difference is that CentOS is really free. RHEL free will be whatever RedHat wants. Of course it won't be as free as CentOS. But if it'll be free enough to satisfy most CentOS users, that might be good enough.
I've heard the idea being mentioned from several sources. My guess is that unless Oracle does some kind of magic an manages to get anyone to trust them, then we'll see a new community project to replace CentOS very soon.
Either that, or Debian's user-base will grow a lot within the next few months. :)
Oh cool. As for CloudLinux, "not free" probably scale for some hosting environments, including non-managed cloud instances.
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.
> 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.
Remember that, in Ubuntu, the majority of packages are actually ONLY supported for nine (9) months -- not the full 5 years!
> 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.
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, 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.
Not only does this not "stick it to the man", it's directly addressed in the FAQ. If folks want to boot up another rebuild project, there's nothing preventing that. There are also several existing ones that you could go join.
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.
> @syshum, yes, but it's not exacly RHEL, and it's not distributed outside AWS
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.
Yeah, resources and infrastrucure are not some magic that only Redhat can provide. If sources will be released on https://git.centos.org/ or somewhere else, then it may work. Just like the old times [1]
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.