"Using the UBI image, it is easily possible to obtain Red Hat sources reliably and unencumbered... Another method... is pay-per-use public cloud instances. With this, anyone can spin up RHEL images in the cloud and thus obtain the source code for all packages and errata."
I wonder how stable the cloud path is ... can RedHat have cloud vendors "voluntarily agree" to not spin up VMs for rebuilders? (Kinda like how subscribers "agree" that distributing GPL'd sources could put their subscription renewal in jeopardy.)
>an RedHat have cloud vendors "voluntarily agree" to not spin up VMs for rebuilders?
I mean, maybe, but does it matter? You only need one person with access to the code to distribute it to everyone else, and the identity of that one person doesn't have to be public, so I really don't see how Red Hat could ever hope to stop it.
> That confusion manifested as accusations about us going closed-source and about alleged GPL violations. There is CentOS Stream the binary deliverable, and CentOS Stream the source repository. The CentOS Stream gitlab source is where we build RHEL releases, in the open for all to see. To call RHEL “closed source” is categorically untrue and inaccurate. CentOS Stream moves faster than RHEL, so it might not be on HEAD, but the code is there. If you can’t find it, it’s a bug – please let us know.
> Anyone is allowed to create an account, get GPL'ed code and redistribute that code as much as they want according to the license. But they don't actually want the code because as I've said over and over, its not about the code (Free as in freedom). The code is out there (as proven by the fact that none of these rebuilders stopped nor will they stop)
PS: How many people do you see linking to the actual Red Hat posts? I don't see many, which is why I think many comments on these threads are not made with honest intentions. The misinformation is rampant.
While it’s important to get both sides, RH’s actions are the exact opposite of what he’s saying there. And your belief that this somehow absolves them and that their anti-FLOSS actions are “misinformation” is incredibly disingenuous.
What actions? What anti-FLOSS? They are complying fully with the terms of all licenses of RHEL and CentOS Software. Don't believe me? Here is what Fedora says about it [1]. It's no problem for them. "There is no change in Fedora or with anything related to Fedora."
> 3) So what happened?
>
> - CentOS Engineers will not be producing that git
> repo of exploded SRPMs anymore because there is
> no need for them in CentOS project.
>
> - Red Hat recommends to take RHEL sources from
> CentOS Stream repositories because that is the
> actual source from which RHEL packages are built
> by RHEL Engineers.
>
> Can you still get access to SRPMs and create
> exploded sources repo - Yes. But there is no
> practical reason for Red Hat or for CentOS
> Project to maintain such a service.
>
> There is no change in Fedora or with anything
> related to Fedora.
>
> --
> Aleksandra Fedorova,
> member of Fedora Council
> RHEL/CentOS Strem CI Engineer
> We have not yet heard anything from Oracle, which hopefully implies that these changes are not a problem.
Giant corps move slowly, and companies like Oracle will require official communication only, which moves even slower. I think it's too early to read anything into it.
AlmaLinux should just start their own RHEL, with blackjack and hookers...
They have a company behind them, they have values, so why ride Red Hats coattails? Start your own distro.
They could even try and make it somewhat compatible with RHEL, in the sense that famous proprietary software like EMC and Dell stuff could run on it. A lot of times it's just a matter of having the right RPMs, environments and strings in all the right places to get them to run.
> Anyone is allowed to create an account, get GPL'ed code and redistribute that code as much as they want according to the license. But they don't actually want the code because as I've said over and over, its not about the code (Free as in freedom). The code is out there (as proven by the fact that none of these rebuilders stopped nor will they stop)
It's clear that all the misinformation about RHEL, misinterpretations of the GPL, et al. are not actually about those issues. There is a concerted effort to attack Red Hat.
Become familiar with the "Twenty-Five Rules of Disinformation" [2] and you will see them everywhere.
Not really, RedHat started this. They're in the enshittening phase now. Management has run out of ideas for real growth, so they are instead squeezing the customer base.
Yeah, but not many companies are like MS and let one or two cash cows carry all the other ambitions, many companies prefer each unit be profitable. OpenShift might be printing money, but clearly the RHEL division isn't.
It's not obvious to me that the user you're replying to believed that these were your opinions. It seemed more obvious to me that they were replying indirectly to the comments made by the Red Hat staff member.
But now that you've gotten to the point of having your own opinion and take: what is "the main issue" as you've mentioned here?
The main issue is that people in this thread, and elsewhere in related threads, are coming to believe that Red Hat is somehow doing something illegal or improper -- due to inaccurate and misleading headlines, and misinterpretations of the requirements of GPL licenses.
Which, of course, is untrue since Red Hat has stated several times, in the links I've posted above, that Red Hat are (a) STILL providing complete corresponding source code, which one will still receive when they are distributed a binary by Red Hat, and (b) FULLY complying with the terms of GPL and other FLOSS licenses.
These are the two issues that people are misrepresenting, by saying either that Red Hat is (a) locking-down or otherwise disallowing access to complete corresponding source for binary recipients, which is untrue, or (b) that Red Hat is not complying with the FLOSS licenses their software are used under, which is also not true.
The next issue that is raised, one that was mentioned by the Software Freedom Conservancy [1], is that Red Hat is somehow extorting their customers by either making them choose between exercising their GPL rights, or continuing to receive support.
Red Hat is free to terminate support with any of their customers--that is not a GPL issue. The transaction the GPL covers is: Red Hat gives (or sells) the user a binary, the user can request the complete corresponding source code (not need to be immediately provided with), and once requested then Red Hat must provide that code. That is the end of the transaction. The GPL does not cover any additional period, or force Red Hat to continue business with a particular user.
I feel that I've very rarely actually heard people complain that what Red Hat is doing is illegal. The overwhelming majority of negative opinion takes that I've heard has been, "Red Hat is trying to squeeze out money from users which is against the spirit of Linux." Which is to paraphrase the generally ineloquent takes I've heard on the matter. Though there's a point to be made there, why did Linus Torvalds start the Linux project? To make a free alternative to the expensive Unix of the time. I think that point falls a bit short, there are plenty of completely free Linux-based distributions out there to choose from. People just wanted an "Enterprise Linux" for free, which for years had been CentOS, and now Rocky/Alma Linux. People feel like they're going to have to change to a new OS or pay Red Hat money, which given the spirit of RHEL, change probably isn't something these people are accustom to.
In short, I've heard of people being generally annoyed by the change, which may be fair. I haven't heard too many people seriously trying to make the claim that what Red Hat is doing is illegal.
It is in the spirit, and here it is straight from the horse's mouth:
> Many people believe that the spirit of the GNU Project is that you should not charge money for distributing copies of software, or that you should charge as little as possible—just enough to cover the cost. This is a misunderstanding.
> Actually, we encourage people who redistribute free software to charge as much as they wish or can. If a license does not permit users to make copies and sell them, it is a nonfree license. If this seems surprising to you, please read on.
It's all well and good that RH follows the legal requirements of the GPL by providing the sources to their customers. All above board there.
The problem is that, as a downstream customer of that software, RH threatens to terminate my business contract with them if I exercise my own freedom to redistribute that software. It's completely in bad faith.
Yeah, Red Hat is free to terminate their business with you. And you are free to get that software from somewhere else. To quote again from the Selling Free Software article (linked above):
> With free software, users don't have to pay the distribution fee in order to use the software. They can copy the program from a friend who has a copy, or with the help of a friend who has network access. Or several users can join together, split the price of one CD-ROM, then each in turn can install the software. A high CD-ROM price is not a major obstacle when the software is free.
And so all these arguments, once all the misinformation is expelled, eventually boil down to this "it's in bad faith" schtick. Well, what is the faith of Rocky Linux when they are purveying a bug-for-bug clone of RHEL, selling support contracts on top of that, and directly competing with Red Hat's business?
Trick question, because "faith" doesn't matter. It's all legal, and these are businesses. They are making business decisions. If one thinks that some corporation--any corporation--owes "faith" or loyalty to their customers, then I got a bridge to sell you.
You're free to hate Red Hat--no one is forcing anyone to _like_ them--but I hope you have some substance somewhere within, and can articulate why.
>f one thinks that some corporation--any corporation--owes "faith" or loyalty to their customers
If you don't think it is well past time to start forcing ethical behaviour on corporations... I don't know what to say to you.
I notice a certain country is fast tracking them to have human rights, like civic voting, but nothing at all about joining in responsible stewardship for our world.
What a ridiculous take. There is a concerted attack on RH, but that’s because RH is making a concerted attack on open source and was hoping we’d all just stand by and let it happen.
Hardly. Making RHEL harder to clone isn’t an attack on open source. It may be Red Hat is slightly less open, but calling it a concerted attack on open source is silly.
RHEL isn’t a project. It’s a product. All the actual work is still happening + being released (albeit less conveniently & not as timely). If Red Hat comes up with a fantastic new feature in RHEL the source will still be released - but it’s up to others to reassemble it. That’s hardly a concerted attack on open source. It’s a jab at copycats.
the loaded words "freeloader" and to a lesser extent "copycats" .. misses an important aspect of the real lifecycle of GNU/Linux software.. maybe you have heard of a book about tech markets called "crossing the chasm".. one part of that book says that there are easily four layers to participation and customers with tech in some markets.. you can imagine those four yourself because there is more than one valid diagram, but basically developers and their employment or income is innermost, their immediate dependancies for inputs, and their most rabid consumers are second, most customers and business relations of varying flavors third, and then "the Chasm" .. a catchy term to say that getting to those outside the regular channels, is very challenging.
So in the RedHat so-called "copycat" case, the immediate downstream fill an important role in getting to the fourth+ layer.. there are more informal, unexpected, temporary or otherwise oddball cases than anyone can imagine. So in a growing and evolving network, the full, paid product from the original brand name source is aided and abetted by these immediate downstream distros. Thats not the same as simply counterfeit on black markets. Neither is it low effort, since these two distros Alma and Rocky, show long-term commitment and good skill levels. Those are valuable growth themselves.
What this squeezeplay on the copycats does is remove growth at the edges for lots of people, and consolidate revenue in the center, at RedHat. This is common knowledge among MBAs, and they do it all the time.
That’s a lot of words that in no way actually support what Red Hat is doing as a concerted attack on open source. Attempt at consolidating revenue? Ok. Attack on open source? No. The rest of the community and industry can route around Red Hat and it’s not trying to prevent others from doing anything with, to, around or on open source development or business models except straight up copying RHEL - which is supported by the licenses anyway.
as a copyleft supporter + never-been-a-customer, what I see is .. there was an existing agreement with the "community" that spread across access, updates, license terms for the code, license terms for market exchange of services. IBM purchased RH and are now changing those relationships (maybe) staying within bounds of the code side, but definitely changes to the other parts.
I guess the there is money that can be extracted from customers for formal business agreements, because the companies that themselves have contractual relationships with their own customers, care about having paperwork intact; similarly with insurance or compliance contracts. At the same time, this is a squeeze play against at least two downstream distros, Alma and Rocky.
So the attack is not complete, nor all in one place. I am interested to hear if this is accurate, from others with more skin in the game.
The repository you linked previously contained RHEL source code, but it is no longer being updated as of a few weeks ago. This is the entire thing being discussed.
Really weird for you to be grandstanding about how misinformation is bad, while spreading it yourself.
Yes, it is now. From Red Hat's original June 21 article [1] (they even put it in bold).
> CentOS Stream will now be the sole repository for public RHEL-related source code releases.
RHEL is in there somewhere, even if a user has to pick specific commits for it.
Furthermore, for the totally-bundled source for the exact binary RHEL release (which Red Hat only is required by the GPL to give to their customers, whom they already gave a binary to):
> For Red Hat customers and partners, source code will remain available via the Red Hat Customer Portal.
> RHEL is in there somewhere, even if a user has to pick specific commits for it.
This is not true. There are Red Hat package versions that do not correspond to any commits in that repository. For example, if a package gets updated from 1.1.0 to 1.2.0 in CentOS Stream, then later a patch is released (lets say, 1.1.1, or 1.1.0-2) then that patch will never show up in this repository. In such a situation, the 1.2 version will probably get an equivalent patch eventually, but not the 1.1 version.
Others have pointed out that embargoed security patches are not pushed to CentOS Stream until the embargo ends, and often at the end of the embargo they still don't push it until several weeks later, due to RH developers forgetting to do so.
> Ubuntu tried that, with AFAIK limited success. Yet another player would inevitably fizzle.
They also spent hundreds of thousands of dollars shipping free install CDs to people all over the world and piggy-backing off of the Debian community's progress. All so they could (almost two decades later) put small dent into Red Hat's enterprise entrenchment.
You would need to offer a significantly better product than RHEL, if you hoped to unseat them.
you are right, but there is news.. on AWS in go-go years, Ubuntu with easy defaults and permissive licenses became the number one installed VM .. by a very large margin. The numbers were not even close.. like 15x more daily volume of VMs on AWS than the next closest three or whatever.. look for yourself.
That in turn begat the very hot breath of MSFT upon Ubuntu-Canonical, which shows in the boot signing keys for Ubuntu, the MSFT-private partition type in the disk installer, and the WSL. MSFT influences can be seen in the push for always-on snap with libc and unattended-upgrades phone home and the like.
AlmaLinux, thank you for taking the constructive/positive approach that you do. Red Hat is not our enemy, and although they've made decisions that are disappointing, I deeply appreciate that you aren't antagonistic toward them, and in fact add value to them. This is why I chose and use AlmaLinux for many things. The contrast between you and the others is big, and I'm very grateful that you are what you are. And thank you for improving this ecosystem!
> We have also enriched the upstream community. AlmaLinux community members have submitted PRs to projects such as RPM, AWX, and VirtualBox. Our community has sent over 50 PRs to GlusterFS and also extended openQA. A Red Hat employee even thanked us for enabling Fedora tests to run on ELN and RHEL. An AlmaLinux contributor (who was formerly an ArchLinux user) was so fired up by our community that he now maintains over 600 Fedora and Extra Packages for Enterprise Linux (EPEL) packages, including some widely-used ones like certbot, brotli, iperf3, imapsync, and countless Python libraries, many of them as the primary contributor maintaining them for the greater Fedora and Enterprise Linux ecosystem. EPEL is tremendously important to both Red Hat and RHEL users.
I wasn't aware of this. So it's looks like RH/IBM argument that they don't contribute back is bullsh*t.
So it doesn't count when AlmaLinux does contribute upstream, but somehow counts when RH contributes and has this "100% upstream policy"? Is this RH's argument?
Don't read one guy's opinion on Reddit and attribute it to the whole company. There are surely others who agree with him, and others who don't. This is the kind of dumb stuff that leads to most tech companies barring employees from saying anything. Let's stay reasonable.
This situation is somewhat confusing, as someone who doesn't have a RedHat subscription. Rocky and Alma claim that RH's new policy is a hindrance to the re-distribution of RH's code, while RH's staff claims that "Anyone is allowed to create an account, get GPL'ed code and redistribute that code as much as they want according to the license".
Some genuine questions:
1. If Bob doesn't currently have a RedHat subscription, does he have a way to obtain RHEL source code, legally, continuously, without the help of a current subscriber, and for free?
2. If Bob has a RedHat subscription, and has access to RHEL source code through the customer portal, is he free to continuously re-publish the source code else where? (in other words, facing no legal threat, and won't be cut off the subscription)
3. RH's staff mentioned "GPL'ed code", so it sort of implies the possibility that some other code are not GPL'ed, and might be subject to less favorable terms regarding redistribution. So, are all the code authored by RH and re-distributed by Rocky/Alma licensed with GPL? Or in other words, are there code whose re-distributability changes with the new policy of RedHat?
I evaluted SUSE quite a bit some years ago, and I ran into a handful of problems that were (at the time at least) showstoppers. The biggest one was that not all packages could be reliably installed from the command line. There was a GUI package manager application that used a different system than the command line, which for me was super confusing but also not viable on headless systems (which is most of them). There were also something different about their RPMs, where even though it was RPM based you couldn't use centos/fedora RPMs.
This was all at least 5 years ago, maybe 10, so take with a grain of salt.
I'm sure if I really learned the system it would be fine, but I've got two decades of the Red Hat Way engrained in me. It would be hard to change.
>The biggest one was that not all packages could be reliably installed from the command line. There was a GUI package manager application that used a different system than the command line
This doesn't make any sense. I've been using OpenSUSE for a decade and there's no package that can be installed via Yast (the GUI) but not via zypper (the CLI).
>There were also something different about their RPMs, where even though it was RPM based you couldn't use centos/fedora RPMs.
Obviously. They're different distros with different package names and library paths. "RPM" is just a file format.
> Obviously. They're different distros with different package names and library paths. "RPM" is just a file format.
This is absolutely not obvious to a person coming from EL/Fedora (which is the context we are discussing here). Things that are "obvious" to an existing user are not necessarily obvious to new users.
If you thought you could install RHEL packages on SLES, what did you think the difference between RHEL and SLES was?
Also I'm not sure what "new" or "existing" users have to do with it. I've never used RHEL so I'm technically a new RHEL user, but I don't have the misconception that distro packages are interchangeable.
> If you thought you could install RHEL packages on SLES, what did you think the difference between RHEL and SLES was?
I didn't know what the differences were. I learn by doing. Everybody has to install and try a distro for the first time at some point. Unless you are arguing that you were born with innate knowledge of Suse, then at some point you didn't know either.
> Also I'm not sure what "new" or "existing" users have to do with it. I've never used RHEL so I'm technically a new RHEL user, but I don't have the misconception that distro packages are interchangeable.
I would argue that you actually have the misconception, so this is ironically pretty good evidence that "new" or "existing" users does matter.
In the RHEL ecosystem, packages can often be installed on any other (non-Suse) RPM distro, as long as the dependencies are met. For example, Fedora packages can be put on RHEL or CentOS or Alma or Rocky or Amazon Linux or Oracle Linux or Scientific Linux etc. I have some packages built for EL9 that are installed on my Fedora machine right now. Putting on a different distro you run a risk of having broken dependencies, but things are largely the same.
The same is also true for Debian, Ubuntu, and many other .deb distros. This is far more common in the linux ecosystem than not. Suse seems to me to be the odd-one-out here.
> The same is also true for Debian, Ubuntu, and many other .deb distros. This is far more common in the linux ecosystem than not. Suse seems to me to be the odd-one-out here.
Agreed. I didn't and wouldn't say it's a good practice. It can be quite risky in fact. I only said it was possible. Your warning is a good one as I didn't intend to imply that just because you ,can doesn't mean you should
>Everybody has to install and try a distro for the first time at some point. Unless you are arguing that you were born with innate knowledge of Suse, then at some point you didn't know either.
No, it's absurd to assume that you can transplant distro packages, not that you can't. And I don't really care to argue with you about this. Your incorrect assumptions are your problem, not mine.
>I would argue that you actually have the misconception, so this is ironically pretty good evidence that "new" or "existing" users does matter.
Wrong. Once again I remind you that you're the one who made the incorrect assumption and got burned by it, so your attempt at deflecting is laughable.
>In the RHEL ecosystem, packages can often be installed on any other (non-Suse) RPM distro, as long as the dependencies are met.
"As long as the dependencies are met" is doing some pretty heavy lifting there, isn't it? And why do you think your attempt to install those RHEL RPMs on SUSE failed?
>For example, Fedora packages can be put on RHEL or CentOS or Alma or Rocky or Amazon Linux or Oracle Linux or Scientific Linux etc.
First of all, four of the distros in that list are intentionally the same distro (RHEL, Alma, Rocky, Oracle), so it is expected that their assumptions and dependencies line up to allow you to install packages built for one on the other.
Second of all, it is absolutely not true that packages from CentOS (assuming we're referring to Stream) and Fedora can always be installed on RHEL or vice versa. The whole point of them being upstream of RHEL is that they can have newer dependencies. Hypothetically Fedora can switch the libfoo package to v3 with a different soname while RHEL still has it as v2, so any package that depends on the v3 soname cannot be installed on a v2 OS or vice versa.
Also, unlike all those distros which are either upstream or downstream of RHEL, SLES is not. So once again I ask, what did you think the difference between RHEL and SLES was? It sounds like you just assumed that SLES is upstream or downstream of RHEL, and made not even a cursory documentation search, nor talked to the SLES reps apparently, to relieve yourself of that assumption.
>I have some packages built for EL9 that are installed on my Fedora machine right now. Putting on a different distro you run a risk of having broken dependencies, but things are largely the same.
"The packages work as long as you ignore all the things that make them not work."
>The same is also true for Debian, Ubuntu, and many other .deb distros. This is far more common in the linux ecosystem than not.
Debian and Ubuntu will have exactly the same problem as the Fedora and RHEL example. Actually worse, because Ubuntu isn't a strict downstream of Debian but a random snapshot of Debian while it's between releases. The packages in Ubuntu can end up not corresponding to any Debian stable nor unstable.
And again, the scenario of taking RPMs from RHEL and trying to put them onto SLES is equivalent to taking RPMs from RHEL and trying to put them onto Debian. If the latter sounds absurd to you, why did you think the former made sense?
>Suse seems to me to be the odd-one-out here.
No, you just have very bad ideas about how Linux works and are weirdly stubborn about correcting them.
You're arguing against a straw man, but if that makes you feel better, go for it. You're putting words in my mouth that I never said and twisting the ones I did say as uncharitably as you can, and then arguing against them.
I'm not going to engage anymore because I'm starting to get irritated by that, and my goal of commenting on HN is to broaden horizons and satisfy curiosity, not to engage in unproductive Internet arguments.
If my criticisms of suse hit a sore point with you, then I apologize. My intent was not to criticize suse. I'm sure it's a fine distro. My intent was to share my experience of moving from RHEL to Suse, as others were discussing changing from RHEL to possibly Suse. If you do that, you will probably have to modify your RPM specs because they won't (or at least didn't back when I tried) work on Suse without changes. Since many RHEL users use it to run their own apps in production, and all their RPM writing experience is RHEL, it's relevant to consider.
I think the end-all-be-all of this obviously spiraling conversation is: the other user expected SLES to be a drop-in replacement for RHEL/CentOS, but it wasn't. So why did they not consider Suse for their enterprise uses? Because they had existing workflows that work on RHEL-like operating systems, and Suse would require more work and time to adopt than those alternatives. All of that is completely fair and valid. And to make your point: all you have to do is learn the operating system and suddenly that's not much of a concern any more. If the free alternatives aren't as feasible in the future, I'm sure there may be more appetite for that kind of effort.
I don't really have any comment on whether SLES was suitable for their RHEL shop or not. This entire subthread rabbit hole is just about their absurd assumption that packages can be transplanted between distros and their subsequent doubling-down on it.
Eh... It's absurd if you actually know how packages work or have ever built a package. A Linux end user, just starting out experimenting with different distros trying to install random packages they find online and not reading the right high-level documentation (like that debian link above) could very easily have the (false) experience that there are three kinds of Linuxes inside of which packages are largely interopable: RPM, DEB, and pacman . And to be fair, if they don't mind really messing up their system and bring enough different versioned dependencies in, this is kinda true, at least until they try to update. SUSE completely breaks this illusion.
This thread brought me back to when I was first messing with Linux distros, I used some insane program called something like 'alien' to try to install .deb packages into Fedore Core, with no idea how wrong minded that whole enterprise was
People with tight dependency with RHEL usually have a hard time migrating to SuSE Linux, and vice versa. For example, SuSE Linux is popular among meteorologists running their own weather models. A few years ago, I was trying to run a popular open source weather model on CentOS and failed to do so after a few days of full time tinkering with the source. Gave up and installed OpenSuSE and I got it up and running in a couple hours.
Place I used to work at in Australia 15+ years ago used SUSE. Novell owned it and they positioned it as their replacement for NetWare, and a lot of ex-NetWare sites ending up running it (at least for a while). But even that place, we had more Oracle Linux than SUSE. Everything that ran on Solaris got migrated to Oracle Linux (e.g. Oracle RDBMS); everything that ran on NetWare (GroupWise, eDirectory) got migrated to OES (SUSE plus extra ex-NetWare bits). But then I think most of the SUSE went away when GroupWise/eDir were replaced by Exchange/AD on Windows. Whereas they are probably still using Oracle Linux today. Actually, originally we were going to use RHEL, but found Red Hat’s sales team too difficult to deal with, whereas we already were an Oracle customer.
SUSE is a fascinating company. They’ve been in the game since the 90s. They have over 2300 employees. Revenue is ~650 MM USD. But I rarely hear of anyone using their distro.
EPEL Fedora maintainers should just stop updating their packages, if RHEL uses Fedora packages, just stop updating them or make them available explicitly for Red Hat through closed sources that you need to pay for. Fight fire with fire.
I have little faith that RHEL will change, especially after that blog post from the vice-president calling AlmaLinux and Rocky Linux "freeloaders" and that they bring no value to RHEL. They are the reason RHEL is as big as it is today and they're actively fighting against what made them big.
Red Hat never called anyone "freeloaders" in any of their blog posts.
Also, there is nothing wrong with making people pay for free software. That is explicitly in the philosophy of free software and the GNU Project.
> Many people believe that the spirit of the GNU Project is that you should not charge money for distributing copies of software, or that you should charge as little as possible—just enough to cover the cost. This is a misunderstanding.
> Actually, we encourage people who redistribute free software to charge as much as they wish or can. If a license does not permit users to make copies and sell them, it is a nonfree license. If this seems surprising to you, please read on.
Lol, "new"... Iirc, KDE almost self-destroyed by chasing the dream of making tablets; Nokia took half a decade to build a working linux-based OS (and then binned it); same for Intel...
Consumer hardware is hard to pull off, to start with. Then there are tons of components requiring closed-source drivers that don't play well with Linux; you can spend a lot of money to rewrite them, or you can build piles of weak hacks that will crash your OS every few hours. You need deep pockets to get OEMs to pay attention to your needs, rather than the needs of giant manufacturers hungry for their production lines. Managing prices on small runs is extremely hard, so your 1.0 is going to be prohibitively expensive, which means it won't sell, which means you won't have the money to fix all the problems
I think the Framework laptop is pretty much as close to a "Linux" laptop as we're gonna get, at least for the foreseeable future. Shipping computers without Windows licences by default and supporting hackers with plenty of documentation on repairing the hardware and making custom modules seem to be pretty in line with the open source mentality.
Something like 90% of webservers are running Linux. Alma, RedHat, etc are primarily focused on enterprise servers, not consumer devices.
But since you are looking for consumer devices running Linux, I recommend you check out Android, which is running on nearly 3/4 of mobile devices globally.
This is unrelated, as Almalinux is largely a server distro.
But Linux has System76, Tuxedo and Slimbook, also Dell and Framework, though they aren't Linux first.
Alma had previously stated that Oracle would be an upstream source.
"In the immediate term, our plan is to pull from CentOS Stream updates and Oracle Linux updates to ensure security patches continue to be released."
https://almalinux.org/blog/impact-of-rhel-changes/
Rocky has said that they have found "a path forward," but have not divulged it.
https://www.theregister.com/2023/06/28/rocky_linux_rhel_ripp...