It looks like they're second to Intel, at least by LF's metric. That said driver code tends to be take up a lot of space compared to other areas. Just look at the mass of AMD template garbage here: https://github.com/torvalds/linux/tree/master/drivers/gpu/dr...
One example is virtualization: the virtio stack is maintained by Red Hat (afaik). This is a huge driver behind the “democratization” of virtualization in general, allowing users and small companies to access performant virt without selling a kidney to VMware.
Also, Red Hat contributes to or maintains all of the components involved in OpenShift and OpenStack (one of which is virtio!).
Red Hat primarily contributes code to the kernel and various OSS projects, paid for by the clients on enterprise contracts. A paying client needs something and it gets done. Then the rest of us get to benefit by receiving the code for free. It’s a beautiful model.
If you look at lists of top contributors, Red Hat (along with the usual suspects in enterprise) are consistently at the top.
For example:
- Red Hat Identity Management -> FreeIPA (i.e. Active Directory for Linux)
- Red Hat Satellite -> The Foreman + Katello
- Ansible ... Ansible.
- Red Hat OpenShift -> OKD
- And more I'm not going to list.Not really comparable to the experiences i have running keycloak where the upstream documentation is complete or freeipa where it’s identical to idm and you can just use the redhat docs. Those are both excellent pieces of software we are lucky to have.
Back in the day when the boxes were on display in brick-and-mortar stores, SuSE was a great way to get up and running with Linux.
It's a rock-solid distro, and if I had a use for enterprise support, I'd probably look into SLES as a pretty serious contender.
The breadth of what they're doing seems unparalleled, i.e. they have rolling release (Tumbleweed), delayed rolling release (Slowroll) which is pretty unique in and of itself, point release (Leap), and then both Tumbleweed and Leap are available in immutable form as well (MicroOS, and Leap Micro respectively), and all of the aforementioned with a broad choice of desktops or as server-focused minimal environments with an impressively small footprint without making unreasonable tradeoffs. ...if you multiply out all of those choices it gives you, it turns into quite a hairy ball of combinatorics, but they're doing a decent job supporting it all.
As far as graphical tools for system administration go, YaST is one of the most powerful and they are currently investing in properly replacing it, now that its 20-year history makes for an out-of-date appearance. I tried their new Agama installer just today, and was very pleased with the direction they're taking.
...so, not quite sure what you're getting at with your "Back in the day..." I, too, remember the days of going to a brick-and-mortar store to buy Linux as a box set, and it was between RedHat and SuSE. Since then, I think they've lost mindshare because other options became numerous and turned up the loudness, but I think they've been quiety doing a pretty decent job all this time and are still beloved by those who care to pay attention.
SUSE has always been pretty big in Europe but never was that prominent in North America except for IBM mainframes, which Red Hat chipped away at over time. (For a period, SUSE supported some mainframe features that Red Hat didn't--probably in part because some Red Hat engineering leadership was at least privately dismissive of the whole idea of running Linux on mainframes.)
It is the Microsoft of the Linux world.
Tbh it feels like NixOS is convenient in a large part because of systemd and all the other crap you have to wire together for a usable (read compatible) Linux desktop. Better to have a fat programming language, runtime and collection of packages which exposes one declarative interface.
Much of this issue is caused by the integrate-this-grab-bag-of-tools-someone-made approach to system design, which of course also has upsides. Redhat seems to be really helping with amplifying the downsides by providing the money to make a few mediocre tools absurdly big tho.
systemd.services.rclone-photos-sync = {
serviceConfig.Type = "oneshot";
path = [ pkgs.rclone ];
script = ''
rclone \
--config ${config.sops.secrets."rclone.conf".path} \
--bwlimit 20M --transfers 16 \
sync /mnt/photos/originals/ photos:
'';
unitConfig = {
RequiresMountsFor = "/mnt/photos";
};
};
systemd.timers.rclone-photos-sync = {
timerConfig = {
# Every 2 hours.
OnCalendar = "00/2:00:00";
# 5 minute jitter.
RandomizedDelaySec = "5m";
# Last run is persisted across reboots.
Persistent = true;
Unit = "rclone-photos-sync.service";
};
partOf = [ "rclone-photos-sync.service" ];
wantedBy = [ "timers.target" ];
};
I agree the systemd interface is rather simple (just translate nix expression to config file). But NixOS is a behemoth; Completely change the way how every package is built, introduce a functional programming language and filesystem standard to somehow merge everything together, and then declare approximately every package to ever exist in this new language + add a boatloat of extra utilities and infra.
An OS is first of all is a set of primitives to accomplish other things. What classic worse-is-better Unix does really well is do just enough to make you able to get on with whatever those things are. Write some C program to gather some simulation data, pipe its output to awk or gnuplot to slice it. Maybe automate some of that workflow with a script or two.
Current tools can do a bit more and can do it nicer or more rigorously sometimes, but you loose the brutal simplicity of a bunch of tools all communicating with the same conventions and interfaces. Instead you get a bunch of big systems all with their own conventions and poor interop. You've got Systemd and the other Redhat-isms with their custom formats and bad CLI interfaces. You've got every programming language with it's own n package managers. A bunch of useful stuff sure, but encased in a bunch of reinvented infrastructure and conventions.
--config ${config.sops.secrets."rclone.conf".path} \
Secret management would likely come in NixOS in the future, but in the mean time you can add either use https://github.com/Mic92/sops-nix or https://github.com/ryantm/agenix to make it possible to manage files which have content that should not be public.
Other package managers also provide some abstraction over the packages, and would likely see the same systemd configuration abstracted the same way in post-install scripts. Yet, the encrypted file for `rclone.conf` would come as a static path in `/etc`.
You could resume NixOS as having moved the post-install script logic before the installation, yet this tiny detail gives you additional abilities to mix the post-install scripts and assert consistency ahead of making changes to the system.
This, despite the fact that Rocky, Alma, Oracle Enterprise Linux, etc exist because of the hard work and money spent by Red Hat.
And what are those companies doing to fix this issue you claim Red Hat causes? Nothing. Because they like money, especially when all you have to do is rebuild and put your name on other people’s hard work.
And what exactly is incomprehensible? What exactly is it that they’re doing to the Linux desktop that make it so that people can’t fix their own problems? Isn’t the whole selling point of Rocky and Alma by most integrators is that it’s so easy you don’t need red hat to support it?
So I'm not being critical. Yes, Red Hat employees do contribute to projects that are most relevant to the desktop even if doing so is not generally really the focus of their day jobs. And, no, other companies almost certainly haven't done more.
To some extent Valve. They have to, since the Steam Deck's desktop experience depends on the "Linux desktop" being a good experience.
Red Hat also has a nasty habit of pushing their decisions onto the other distributions; e.g.
- systemd
- pulseaudio (this one was more Fedora IIRC)
- Wayland
- Pipewire (which, to be fair, wasn't terrible by the time I tried it)
I guess Debian, SUSE, Canonical, etc get that email from Red Hat just go along with it. We better make the switch, we don’t want our ::checks notes:: competitor made at us.
FF to last year, I was working with OpenGL (in linux), I thought "I will add sound" boy... I was smashed by the zoo of APIs, subsystems one on top of another, lousy documentation... Audio, which for me was WAY easier as video, suddenly was way more complicated. From the userland POV, last year I also wanted to make a kind of BT speaker with a raspeberry pi, and also was terrible experience.
So, I don't know... maybe I should give a try to pipewire, at the time I was done after fighting with alsa and pulseaudio, the first problem I killed it.