RHEL Response Discussed by SFC Conference's Panel - Including a New Enterprise Linux Standard (sfconservancy.org) 66
And long-time free software activist Bradley M. Kuhn (currently a policy fellow/hacker-in-residence for the Software Freedom Conservancy) hosted a lively panel discussion on "the recent change" to public source code releases for Red Hat Enterprise Linux which shed light on what may happen next. The panel also included:
- benny Vasquez, the Chair of the AlmaLinux OS Foundation
- Jeremy Alison, Samba co-founder and software engineer at CIQ (focused on Rocky Linux). Allison is also Jeremy Allison - Sam Slashdot reader #8,157.
- James (Jim) Wright, Oracle's chief architect for Open Source policy/strategy/compliance/alliances
"Red Hat themselves did not reply to our repeated requests to join us on this panel... SUSE was also invited but let us know they were unable to send someone on short notice to Portland for the panel."
One interesting audience question for the panel came from Karsten Wade, a one-time Red Hat senior community architect who left Red Hat in April after 21 years, but said he was "responsible for bringing the CentOS team onboard to Red Hat." Wade argued that CentOS "was always doing a clean rebuild from source RPMS of their own..." So "isn't all of this thunder doing Red Hat's job for them, of trying to get everyone to say, 'This thing is not the equivalent to RHEL.'"
In response Jeremy Alison made a good point. "None of us here are the arbiters of whether it's good enough of a rebuild of Red Hat Linux. The customers are the arbiters." But this led to an audience member asking a very forward-looking question: what are the chances the community could adopt a new (and open) enterprise Linux standard that distributions could follow. AlmaLinux's Vasquez replied, "Chances are real high... I think everyone sees that as the obvious answer. I think that's the obvious next step. I'll leave it at that." And Oracle's Wright added "to the extent that the market asks us to standardize? We're all responsive."
When asked if they'd consider adding features not found in RHEL ("such as high-security gates through reproducible builds") AlmaLinux's Vasquez said "100% -- yeah. One of the things that we're kind of excited about is the opportunities that this opens for us. We had decided we were just going to focus on this north star of 1:1 Red Hat no matter what -- and with that limitation being removed, we have all kinds of options." And CIQ's Alison said "We're working on FIPS certification for an earlier version of Rocky, that Red Hat, I don't believe, FIPS certified. And we're planning to release that."
AlmaLinux's Vasquez emphasized later that "We're just going to build Enterprise Linux. Red Hat has done a great job of establishing a fantastic target for all of us, but they don't own the rights to enterprise Linux. We can make this happen, without forcing an uncomfortable conversation with Red Hat. We can get around this."
And Alison later applied a "Star Wars" quote to Red Hat's predicament. "The more things you try and grab, the more things slip through your fingers." That is, "The more somebody tries to exert control over a codebase, the more the pushback will occur from people who collaborate in that codebase." AlmaLinux's Vasquez also said they're already "in conversations" with independent software vendors about the "flow of support" into non-Red Hat distributions -- though that's always been the case. "Finding ways to reduce the barrier for those independent software vendors to add official support for us is, like, maybe more cumbersome now, but it's the same problem that we've had..."
Early in the discussion Oracle's Jim Wright pointed out that even Red Hat's own web site defines open source code as "designed to be publicly accessible — anyone can see, modify, and distribute the code as they see fit." ("Until now," Wright added pointedly...) There was some mild teasing of Oracle during the 50-minute discussion -- someone asked at one point if they'd re-license their proprietary implementation of ZFS under the GPL. But at the end of the panel, Oracle's Jim Wright still reminded the audience that "If you want to work on open source Linux, we are hiring."
Read Slashdot's transcript of highlights from the discussion.
SFC's Kuhn: I've often called the business model, "If you exercise your rights under GPL, your money is no good here." The argument that Red Hat makes for their GPL compliance is, "All we're doing is saying 'We don't want a business relationship with people who exercise their rights under GPL.'" And it's hard to find in the GPL any section that says "You have to maintain a business relationship with somebody..."
SFC's Kuhn: But I think the interesting thing is, what do we do about the intimidation part of it? The agreements that Red Hat puts forward have the right to audit every single customer. At any time, if you're a customer of Red Hat, they can come into your enterprise -- you agree to this, if you want their services -- and they can look at every server and see whether or not you're running a copy of RHEL that has a subscription. And if you are running copies of RHEL that don't have a subscription, you have a choice to start paying them more money, or not be their customer any more. And a lot of people are in fear about this. So how do we deal with this, as a community that wants to rebuild this stuff, If the folks who have the source code are afraid to give it to us because they might lose their business relationship.
Oracle's Wright: I'd go even further ... What their agreement says -- and to be clear, I'm not going to come up here and accuse Red Hat of breaching an agreement, violating the GPL or anything else. But what their agreement says is it's a material breach if you distribute this code. It doesn't just say we can terminate the business relationship. By saying it's a material breach, there are other implications -- like potential damages and other things. Right?
Like I said, I'm not going to accuse them of anything, but I think it's kind of funny that they say that people who are rebuilding don't add value, when Oracle has many years of kernel contributions that they're including in RHEL and MySQL and Java. But besides that, I think there are other copyright holders -- not us, because I think frankly this crowd wouldn't like us to be an enforcer, even if we thought that was the right thing to do -- but there are other copyright holders, maybe sitting on this stage, or maybe watching out here, that might have an opinion about this.
Audience question: Would you consider adding some features that RHEL doesn't do, such as high-security gates through reproducible builds?
AlmaLinux's Vasquez: 100% -- yeah. One of the things that we're kind of excited about is the opportunities that this opens for us. We had decided we were just going to focus on this north star of 1:1 Red Hat no matter what -- and with that limitation being removed, we have all kinds of options.
Samba/CIQ's Alison: Yeah, sure. One of the things that I've been working on in the last few months is FIPS certification. If you don't know what that is, you're very lucky; if you do know what it is, my commiseration. We're working on FIPS certification for an earlier version of Rocky, that Red Hat, I don't believe, FIPS certified. And we're planning to release that. We got the go-ahead to release that as open source. So all the changes for FIPs certification for Rocky will be published... Obviously it won't be upstream, because Red Hat's not going to take that back, but it will be available for people who want to do FIPS certification. God help you.
Oracle's Wright: The OpenSSL folks have now released an open FIPS module. So that's kind of huge.
Samba/CIQ's Alison: Sure, but not for this version. We've backported that to an earlier version.
Audience question: Are you planning to expand upstream contributions?
Oracle's Jim Wright: So, we're hiring a ton, right? We're going to be hiring a lot, effectively, to have our own compatible distribution. Now as to what's upstream, obviously we upstream the vast majority of our work to the kernel tree. And frankly I'm not sure that Red Hat would even want our upstreams. And it would be difficult to manage under the circumstances.
SFC's Kuhn: And if Jim at Oracle does hire you, tell them you won't work for 'em unless he lets you keep your own copyrights on your contributions to open source. [Laughs]
Samba/CIQ's Alison: I live upstream... The stuff I write is built upstream, and Red Hat is downstream from me. And as CIQ grows and has more contributors, then yes, more work is going to go on upstream as the business grows.
AlmaLinux's Vasquez: As the one that doesn't have a company, we are already involved in Fedora, right? The community that is around AlmaLinux is a bunch of people who have been involved in the entire ecosystem for a very long time. So there's no question of whether or not we're going to continue or expand... Whoever joins AlmaLinux contributes wherever they want to, whenever they want to. And we certainly continue to encourage people to contribute upstream. For sure.
[An audience question came from Karsten Wade, a one-time Red Hat senior community architect who left Red Hat in April after 21 years.] I was the architect who was responsible for bringing the CentOS team onboard to Red Hat, and all of that deal, and then Engineering Manager and was on the board for a while -- Red Hat liason and other junk. So here's the question:
You all talked about various versions of digging around in source in a very disparaging manner. And It strikes me that it's possibly disingenuous. And so I'm asking you to -- like, not to get into the technical weeds, but to really consider this. I'm familar with the rebuild process of what CentOS has gone through. CentOS has always been a clean-room rebuild, without knowing what was in the build tree around it. So when they do the rebuild, they just run a rebuild, and then whatever doesn't work, you go back and manually figure out, and start making guesses based off of Fedora. So it's always been steps removed, right? It's -- everyone else has insisted that CentOS and RHEL were the same thing. And so finally people just said, "Well it's the same thing, or it's good enough." Right? So what we're looking at now is the source is there. It's a couple of steps removed. It's not in the source RPM.
Now whether source RPM is a GPL-required artifact or not -- I don't know, right? But the --
[Panelist]: It is.
Former Red Hat community architect Wade: -- the source is still there, but the.. Well, okay. So my question to you is, isn't all of this thunder doing Red Hat's job for them, of trying to get everyone to say, "This thing is not the equivalent to RHEL." Right?
AlmaLinux's Vasquez: Yeah, it makes perfect sense. But I would like to kind of say -- like, we're not afraid of digging around in source code. Right? That's why we're doing what we're doing.
Samba/CIQ's Alison: It's make-work. It's like when Red Hat stopped publishing the kernel patches. It's make-work. People will figure it out. Why do it? "Oh, yes, we're going to make your life more difficult." Thank you, congratulations, you've wasted a bunch of people's time. Great. Okay, now can we get on with contributing and working together?
Oracle's Wright: To go not too far, but one step into the weeds -- half a step into the weeds? Saying that some piece of code was extracted from one thing and put into another thing -- and that that other thing that you put it into, all the source is available? -- I think is a logically specious conclusion. When you backport something from one package to another, that does not mean that the thing you backported it to has all the code. A lot of times modifications are made in backporting. So the argument that the code is all out there, I think is just factually incorrect.
Former Red Hat community architect Karsten Wade: It's always been that case, though, Jim. That's the point. My point is that if the goal of Red Hat is to say "Your thing is not the same as RHEL," right? Then you're proving the point. By going out and making all that noise and saying, "Now you've made it so much harder and so different, our thing can't be the same as RHEL." It never was. The sources that run from the build system, and all the packages in the build system, were never available. CentOS was always doing a clean rebuild from source RPMS of their own. And then they'd build those from disk.get. I mean it's been this long. So yes it's true, it's like the patches -- it's make-work, it's making it more difficult. So aside from it being more difficult... Are you not doing Red Hat's job for them by making so much thunder and noise about how this is so different and such a big break of trust and such a big thing, instead of just saying "Oh, well the source is over here now. Thanks. We'll just build from there. Have a nice day."
SFC's Kuhn: So I have to respond to Karsten's point. The first is -- and I told Karsten this back when he was bringing CentOS into Red Hat. That my big concern with CentOS being integrated into Red Hat was coming from the perspective of somebody that spent most of their career enforcing the GPL. The reason I, for a good 12-year period, didn't worry about whether RHEL was complying with the GPL or not, was because CentOS, as an independent project, was getting something that all the CentOS developers were telling me was relatively easily constructed -- with some work, as you point out Karsten -- and was a match for a rebuild of Red Hat from the sources that were released due to GPL requirements on Red Hat. So that watchdog aspect of CentOS was what was most interesting to me -- because I'm not a CentOS or a RHEL user. Or an Alma user or a Rocky user, sorry to say. I'm certainly not an Oracle Linux user. I'm a Debian. But I want to be sure that folks living RHEL/CentOS enterprise Linux space are getting the things they're right to get under GPL. And CentOS was that watchdog.
Now I have two other watchdogs to talk to, Alma and Rocky. (I'm not counting you Jim. Sorry.) And they're telling me, "Hey, it's hard right now for us." And then I get worried, as a GPL enforcement. I'm like, wait. If the people who are trying to exercise the rights under GPL are telling me, "It's hard right now to exercise our rights," I get worried as an enforcer.
Then I look at another aspect of it, which is kind of what Jim was getting to his with quoting from Red Hat's statement about open source. Which is I always had viewed Red Hat as a company that wanted to be a top-tier open source company, and from my point of view, if you just barely make it into being compliant with the GPL, I give you a C. It's a passing grade, but when I was at school at least, I think most people in this room when they were in school, they really worked hard to get the A not the C. And I'm very, very sad to see that Red Hat wants no more A's in GPL compliance. They're going to settle for straight C's.
Samba/CIQ's Alison: And to be honest, none of us here are the arbiters of whether it's good enough of a rebuild of Red Hat Linux. The customers are the arbiters of is this good enough for our purposes. And customers who really need absolute and complete fidelity? Buy Red Hat. That's what I would say. Go out there, give them money, get the real thing. You know, if you can live with something that's close, then there are alternatives.
Oracle's Wright: This is sort of an important point. People ask why we're doing this, and the answer is because customers require it in substantial part by virtue of other projects that target compatibility. Right? They only want to build and test on a single system. Some of them are open source, some of them are proprietary products that the customers are using. And so why do it? The reason is that customers -- and it doesn't have to be paying customers -- end users require it.
Audience question: With Red Hat pushing the community away, what the odds of creating a new open enterprise Linux standard that distributions can follow?
AlmaLinux's Vasquez: I think, to answer the direct question? Chances are real high. Right? This is a very new thing -- we're, what, three weeks into it? So I think everyone sees that as the obvious answer. I think that's the obvious next step. I'll leave it at that.
Samba/CIQ's Alison: Remember, enterprise Linux is what the customers say it is. And so if the customers say something that's close to Red Hat but not exactly Red Hat is good enough, then that's what we will be. If the customers say, "No, it has to be a rebuild, bug-for-bug compatible, then that's what we're going to try and be. We're going to try and meet the market needs. We're going to try and do what the users require. Because, I mean, that's the whole point of this thing, is to produce freedom for the people using, developing, creating, using the software. The maximum amount of freedom.
Oracle! (Score:5, Insightful)
Re: (Score:3)
I have a belief it was Oracle that basically destroyed RedHat.
After all, Oracle Linux is basically RHEL rebuilt - but Oracle makes sure if you want to use Oracle, you use Oracle Linux instead of RHEL.
It's why RedHat switched the way to released patches to one gigantic patch over many smaller ones - to make companies like Oracle do work in actually applying the patches to their code.
I'm guessing this final move is RedHat basically trying to get Oracle Linux to be more than a recompiled RHEL, hence stopping C
Re: (Score:2)
Oracle Linux seems like a good bet because Oracle builds its RHEL software on Oracle Linux and NOT on RHEL.
Any divergence that Oracle Linux causes will, hopefully, be detected immediately when running on RHEL.
"You're thing" (Score:4)
Why would I read an overly verbose transcript that doesn't have much of value said in it when it can't even spell words correctly?
Re: (Score:1)
Why would I read ...
Why would you whine your little ass about this on a public forum?
Re: (Score:2)
Here's hoping this improves your enjoyment of reading the overly verbose transcript that doesn't have much of value said in it!
Re: (Score:2)
Gentlemen, I give you EditorDavid.
I'm always giving the editors shit for not editing, so it's only fair that I acknowledge this one.
Enterprise Linux perhaps the end of Red Hat (Score:5, Interesting)
Re: (Score:3)
Indeed it occurred to me while listening to Mike MacGraw speak in an interview recently that Red Hat is a proprietary company with a proprietary product. The Red Hat we remember as an open source company died well over a decade ago when they realized they couldn't make money selling support for open source software, so they created a proprietary product, based on open source software, but encumbered it with what are essentially seat licenses (in all but name), and by contractually binding their customers t
Re: (Score:2)
Oh my. Mike McGrath. Sorry, Mike!
Re: Enterprise Linux perhaps the end of Red Hat (Score:1)
Re: (Score:2)
It's so disingenuous to say RH wasn't making money from RHEL, they made increasing profits year on year, and still are.
I think RH might have "pissed on their chips" now. RHEL is a lot less useful without the re-builders and I speak as someone who used to recommend RHEL and had a large contract with them whilst at a previous employer. Without the rebuilders there will be a lot less testers/bug reports/workarounds found, less 3rd party ISVs being interested in RHEL software as you just shrank the installed ba
Re: (Score:2)
>"It's so disingenuous to say RH wasn't making money from RHEL, they made increasing profits year on year, and still are."
I agree. They were making good money BEFORE "license" seating, selling actual technical support, training, certifications, manuals/documentation, installation assistance, value-added stuff, etc. The seat thing was a later money grab. And now IBM wants more of that sweet free seat money and stepped over the bounds.
RedHat could have done just fine without, as you said, "pissing in t
Re: (Score:2)
Corrent. RH's early attempts to sell support for Red Hat Linux, which was freely re-distributable, nearly bankrupted the company. Once they pivoted to RHEL plus a SLA as a combined, proprietary product, they started to make a decent profit, and continue to do so to his day.
Great point about EPEL! In my experience using RHEL is not the best experience without these important packages. Certainly using CentOS, Alma, or Rocky required them for the most part. And as RH has come down pretty hard on the clone m
Re: (Score:2)
Again with the leeches (Score:1)
Upward of mine a comment saying that Oracle and Amazon only take and don't give.
First, there is no requirement to give, just to share. The difference is that if you innovate,
it is up to you to choose to add your innovation to the public codebase. FOSS (GPL)
suggests if you don't, it's still your fork.
More importantly Oracle is stepping up, and no matter how big of a dick they were with
respect to Java, Google, APIs, etc., if they want to come to the table and be nice, the
FOSS community should give them that
Re: (Score:2)
There are many leeches here. It's the business goal of many managers and start-ups to leverage open source enough to sell their proprietary software and services, exposing only a small API to their vendor specific tools. It's what Microsoft did with Azure, which is built extensively on open source tools but which Microsoft has failed to keep up-to-date and is suffering for their refusal to expose their tools.
Amazon has an interesting opportunity. They're abandoning RHEL as their reference open source operat
Re: (Score:2)
>"Amazon has an interesting opportunity. They're abandoning RHEL as their reference open source operating system, and drawing directly form Fedora for Amazon Linux 2023. They're in a position to compete very directly with RHEL in the cloud"
Yes, I too have pointed this out (but Fedora is not an option, it is far too unstable and unsupported). Amazon and Oracle, whether you love them or hate them or somewhere inbetween, hold a LOT of power. If they turn that power to point to some other project, be it Alm
Re: (Score:2)
Amazon Linux has a habit of updating core components without renaming them, including python itself. That does not work well in a RHEL clone, it's why almost none of the EPEL published python modules work on Amazon Linux. 2. It's not clear that Amazon can publish a recent enough operating system based directly on any RHEL release or RHEL clone without running headlong into the new, anti-free-software copyrights and licenses from RHEL.
Re: (Score:2)
Talk is easy. Action takes work. I wouldn't trust Oracle's promises. Someone else suggested they could open-source ZFS. If they don't, perhaps that's a measure of their commitment.
OTOH, it would take more than just a few actual good actions before I'd start trusting Oracle. They've established some pretty strong priors that they shouldn't be trusted.
Re: (Score:2)
ZFS is Open Source. That's why we are able to have it on Linux.
ZFS is not Free Software, and moreover, its license is not compatible with Free Software licenses like the GPL. This is why it can be included in FreeBSD and not in Linux. Linux is Free Software, FreeBSD is only Open Source.
What Oracle could (some say should) do is change the license of ZFS away from CDDL, to GPLv2, GPLv3, or to some other license which is GPL-compatible. They have done it before, with GlassFish [wikipedia.org]. This would erase any need to acc
Re: Again with the leeches (Score:2)
FreeBSD is also free software as defined by the FSF. ZFS is too.
Re: (Score:2)
Oracle would do wonders with ZFS... (Score:5, Interesting)
First, It would be an extremely nice thing to have ZFS as part of the mainline kernel of a commercially supported Linux distribution. Right now, you can install OpenZFS, but it has to be kept updated in parallel with the kernel. Having it as an integral part of the kernel would make that not an issue, especially something as critical as a filesystem in production. Oracle would make a lot of gains, just because if people are used to ZFS in Linux, Oracle would get mindshare... and marketshare for their ZFS NAS appliances (which even though people justifiably have gripes about Oracle, their NAS appliances are extremely solid and worth the price.)
Re:Oracle would do wonders with ZFS... (Score:5, Interesting)
Re: (Score:2)
I've met the people that wrote ZFS in the Sun days. They specifically said their license was written so that it could be included in the Linux kernel without issues. They couldn't understand why it wasn't
The people at Sun didn't understand a lot of things. That's how Oracle ate their company.
Re:Oracle would do wonders with ZFS... (Score:5, Informative)
They specifically said their license was written so that it could be included in the Linux kernel without issues.
The FSF and Redhat both have lawyers who concluded that CDDL code is incompatible with the GPL. So probably the notion that it could have been included legally with the license text used wasn't well founded, even if it was their intention that it be able to be..
Even CDRTools [wikipedia.org] got dropped from Fedora and Debian, etc, due to containing parts the author decided to change license to CDDL back when the author was having their little fit about distributions shipping modified versions of their software.
So certainly it wasn't about "not invented here". And it wasn't just ZFS or OpenSolaris
Re: (Score:3)
Re: (Score:2)
Why not use FreeBSD then?
Re: (Score:3)
>"Why not use FreeBSD then?"
Because it isn't Linux. There is a *HUGE* mindshare in Linux- installations, resources, programmers, software, training/education, etc. That isn't even counting Android and other such projects. BSD is just a tiny fraction of a fraction. I am not hating on BSD, it has a lot of good stuff, and more power to it! (Look at pfSense for a great example). I am just stating the reality of organizations needing to get things done, and that tends to happen under Linux.
Even TrueNAS
Re: (Score:2)
Re: (Score:2)
Thank you. TIL about SCALE. I've thought TrueNAS was always based on FreeBSD with all variants.
Re: (Score:2)
>"TrueNAS has two branches - CORE which is based on FreeBSD, and SCALE which is based on Debian."
That is correct
>"TrueNAS didn't "move" from BSD to Linux, they just maintain multiple product lines.
My understanding is that the developers are pretty clear that all future real development will be done in Scale. Thus, Core is now "legacy". So for all intents, TrueNAS has moved to Linux. I do expect Core will be supported for quite a while, though.
Re: (Score:1)
Also OpenZFS development will primarily be on linux as well, which is probably another reason why SCALE will see most of the future development.
Re: (Score:2)
If the only thing you want to do is run a Filer, then FreeBSD is fine and there's no reason not to use it for that. But there's a bunch of stuff that Linux does that FreeBSD doesn't, including having a bigger installed base of software ready to go without having to compile it oneself, and that makes it a clear choice if you need the machine to do other things as well.
FreeBSD is fine for a bunch of purposes, but if you're going to have Linux around anyway, then it's just another OS to think about and maintai
Re: (Score:3)
Audience question: In the spirit of harmonizing different licenses and agreements, would Oracle by willing to relicense its proprietary ZFS implementation under the GPL?
Oracle's Wright: I'm not going to answer that here -- it's not the first time I've been asked... But in fairness, there's already, if memory serves, the Canonical folks were making a ZFS kernel module...
SFC's Kuhn: Which is in violation of t [theregister.com]
Re: (Score:2)
>"Speaking as a copyright holder in the kernel, and in ZFS itself, we're not complaining if you do that."
For now....
It is interesting to watch Oracle squirm, trying to hold the high moral ground in that line of questioning while the earth is sinking beneath their feet. I would love to know what exactly Oracle would really have to lose at this point by changing the license to make it crystal clear it is free for all. They need to put their actions where their mouths are.
Re: (Score:2)
Re: (Score:2)
Speaking as a copyright holder in the kernel, and in ZFS itself, we're not complaining if you do that.
It's not just a complaint, it's a threat. They chose a license which is incompatible with the GPL. They could choose a different license, but they choose not to. They are choosing to make threats against those who ship ZFS with Linux. They could choose to stop doing so, by choosing a different license.
Wright is just a liar, which makes sense, because he works for Oracle. Oracle has a long tradition of altering deals, and he paid to do their bidding. His opinion on copyrights held by Oracle is irrelevant.
More OS forks and push customers away (Score:1)
Re:More OS forks and push customers away (Score:4, Interesting)
But Ubuntu is also silly. They are pushing snap. Using snap to add non-system applications is one thing (one which I still do not want, to be fair) but using it for elements of the base system is just not what most people are looking for.
Re: (Score:2)
>"But Ubuntu is also silly. They are pushing snap."
They also have a track record of being hostile to the community in other ways and pushing or forcing their own "solutions." The snap stuff is just the latest incident.
Jumping out of the RedHat bed and into bed with Canonical is just moving from one large commercial entity to another, hoping things might be different. Given history, this seems more like the definition of insanity (doing the same thing over and over, expecting different results).
What we
Re: (Score:2)
They also have a track record of being hostile to the community in other ways and pushing or forcing their own "solutions." The snap stuff is just the latest incident.
*cough, cough* NETPLAN *cough* whatever tf they call their install system post 20.04
Re: (Score:2)
Canonical is orders of magnitude smaller than IBM/Dead Hat. However, yes, they have demonstrated that they are willing to purposely fragment the community, e.g., with Snaps. Leaving Debian, for now, as one of the few options for a genuinely non-commercial enterprise Linux (by some definitions of the term anyway).
I would like to have additional, but preferably compatible, choices.
But for the time being, I'm recommending that people deploy server software to containers, and UI software to some combination o
Re: (Score:2)
I'm curious what is the animosity towards Snap and Flatpak?
macOS has been using an equivalent containerized solution for its apps for over a decade.
Re: (Score:2)
>"I'm curious what is the animosity towards Snap and Flatpak?"
The main animosities with Ubuntu on this topic are:
1) Ubuntu forcing their own "SNAP" system down everyone's throats, despite the community clearly favoring the much more open and wide-spread Flatpak.
2) Ubuntu forcing the use of containers for many packages by not providing native (non-containerized) packages, which takes away the choice to NOT use containers when they are not desired or needed.
There are plenty of good reasons to use container
Re: (Score:2)
I use flatpak. snap is bad both technically and in other ways. When Ubuntu gives the whole thing away and it's easy to set up other sources of snaps, I'll take another look at it.
Re: (Score:2)
More likely they'll keep using something based on the last good RHEL fork. There are supposed to be tools that work with RHEL that don't work with other distros. But Alma and Rocky have people who can fix bugs and continue development.
Ubuntu has it's points, but I've never preferred it. OTOH, I've preferred Debian since potato. I'll occasionally try a different distro, but I've kept coming back to Debian.
FIPS Validation (Score:4, Interesting)
We're working on FIPS certification for an earlier version of Rocky, that Red Hat, I don't believe, FIPS certified. And we're planning to release that.
I'd have a little more faith if he actually knew what he was talking about. "FIPS certified" refers to NIST's FIPS 140-2 or 140-3 Cryptographic Module Validation Program (CMVP) [nist.gov], and doesn't apply to a distribution or operating system. He's confusing Common Criteria (CC) [wikipedia.org] with CMVP.
I have no idea if CC is still actively used outside of a very small circle of gov't customers. That isn't something you see much anymore. But FIPS certification is a common requirement for any US gov't contract. For the record, Red Hat has 13 active certificates [nist.gov]. They aren't the only vendor. There's even a general OpenSSL [nist.gov] certificate if you want to use that.
Re: (Score:2)
It's a fair cop :-). I've only started FIPS work in earnest since I got laid-off from Google and joined CIQ, so I'm not cognizant of all the correct terms.
Yeah, it's important for customers though.
Re: (Score:2)
Just to add, for this reason I'm only helping out with the C coding, not leading the effort :-). The person in charge knows his stuff !
Re: (Score:2)
Awesome! Best of luck in your endeavors and thank you for your efforts.
A focus on security is important, and knowing it is in the right hands is even more important. I see from CIQ's government page [ciq.com] you take this seriously, and that is very good to know.
Work together (Score:5, Interesting)
This is a good sign of cooperation, and the ideas are similar to what we have been discussing on Slashdot.
"Enterprise Linux" is too important to the world now to allow RedHat/IBM to have total control over it. The standard needs to be taken away from RedHat and placed into the FOSS community, they have violated the spirit of FOSS, and the stewardship and trust of users too much this time.
The big players like Alma/Rocky/SuSE/Oracle/Amazon need to work together and make this happen- a community-driven, free, very-long supported/updated enterprise Linux distribution. It isn't enough to just have something, they need to also get HP/Dell/etc on-board to fully support a non-RHEL Enterprise Linux officially on their hardware and middleware. With players like Amazon and Oracle, that shouldn't be difficult, however. And with a little momentum, all the other vendors will likely follow.
Re: (Score:2)
This is a good sign of cooperation, and the ideas are similar to what we have been discussing on Slashdot.
"Enterprise Linux" is too important to the world now to allow RedHat/IBM to have total control over it. The standard needs to be taken away from RedHat and placed into the FOSS community, they have violated the spirit of FOSS, and the stewardship and trust of users too much this time.
The big players like Alma/Rocky/SuSE/Oracle/Amazon need to work together and make this happen- a community-driven, free, very-long supported/updated enterprise Linux distribution. It isn't enough to just have something, they need to also get HP/Dell/etc on-board to fully support a non-RHEL Enterprise Linux officially on their hardware and middleware. With players like Amazon and Oracle, that shouldn't be difficult, however. And with a little momentum, all the other vendors will likely follow.
Actually I think it's a lot more difficult than you think. Enterprise Linux customers go to Red Hat because they want a big boring company who is happy to sell support of their system, and a whole ecosystem of 3rd party vendors who are happy to commit to supporting their product on that system.
The market will always collapse to a single distribution since every additional system basically doubles parts of the QA budget for the 3rd party vendors.
There's a small possibility you could get a single distro with
Thanks Jeremy (Score:3)
Re: (Score:2)
Agreed, I really appreciate THIS type of article. Actually news that matters to the tech crowd, with some effort behind it. Well done.
This panels view is âoeoffâ to me (Score:2)
LSB (Score:1)
https://refspecs.linuxfoundati... [linuxfoundation.org]
maybe of interest here.
Star Wars quotes (Score:2)
. "The more things you try and grab, the more things slip through your fingers."
The one that occurred to me was, "I am altering the deal. Pray I don't alter it any further."
Poll - What is the communities definition of EL (Score:1)
We need a poll for the communities definition of Enterprise Linux (assuming it requires publicly available source code).
My current understanding is enterprise Linux will be what people are willing to go out and buy and use in a place of business with service-level agreements. I believe CIQ, Oracle, and SUSE offer these levels of support, so they clearly have a vested interest.
Re: (Score:2)
I would rephrase the question.
What I would like to see in an “enterprise” Linux distro is a long support cycle. Ubuntu LTS is only 5 years, and that's way too short. RH was 10, but usually quite some time between release, so effective support window was shorter. I very much would like a distro with a much longer support lifecycle.
Sure on my development desktop I don't mind tinkering, but rebuilding a server every 3-4 years is undesirable.