Why Corporate Owned Linux Distributions are a Bad Idea

When it comes to Linux Distros, each are either managed by their community or by a company. With recent news, it becomes clearer than ever that those managed by a company should be avoided. With a recent history of being untrustworthy, Red Hat is on the list to steer clear of – but they’re not the only example. With histories of misleading claims (with some being downright lies) it’s time to leave corporate-owned Linux distributions behind. Here’s why.

YouTube player

Relevant Articles

Notable Replies

  1. Very well stated. This is EXACTLY how I feel.

    After the CentOS 7 fiasco, I decided right then and there…for the community, BY THE COMMUNITY for me.

    I moved my hypervisor and all of my VMs from CentOS 7 to Debian and have never looked back.

    Personally, for my desktop/laptops, Arch works well for me.

    YMMV

  2. I was burnt by the CentOS 8 fiasco back then. And there weren’t any alternatives available yet, so I was forced to switch to Oracle Linux 8. The UEK was not too bad, but I cringed so hard that this was the only option.

    I’ve lost trust in Ubuntu back when they dropped Unity 8 and the Linux Phones, around 2017. It left a taste so bad in my mouth that I completely dropped the distro for myself. I used it at work here and there, but even there, if I could use CentOS or Fedora, I did (and they worked great).

    With all of this uncertainty, I’m unsure what to do next. I’m already running a community maintained distro, but the packages aren’t very up to date, despite it being a rolling release. If I had more knowledge on compiling stuff and fixing code and dependency, I would contribute and maintain packages, but it seems, at least for server use, it might not cut it (despite it having a lot of server programs, like monitoring software and such).

    On one hand, Debian seems like a pretty clear cut. It’s the biggest community maintained distro, it’s used and supported by large software stack developers, both companies and communities, like Proxmox, OpenNebula, TrueNAS Scale, OpenMediaVault, FreedomBox and so on. On the other hand, it’s not without its drama, like back in the systemd debacle, where runit (which was officially supported by Debian back then anyway) was not even considered as an option and the project got split to Devuan. But as of the past almost a decade, Debian wasn’t too bad.

    Devuan is another good choice, but I never tried it personally and I don’t know what software might require a dependency on it (I am currently testing OpenNebula on Alma Linux 8, but I might try Devuan and see if systemd is made as a hard dependency - if not, I can just write my own service scripts).

    Gentoo is an old time favorite and with computers being this fast today, compiling is made easy. The problem is optimizing the compilation, which takes a lot of knowledge to pull off (very useful knowledge, if I say so myself). But also, because computers are so fast, optimizing the compiled software might also not be entirely necessary (some would view it as a downside in time spent optimizing and compiling).

    Alpine is minimal and secure, making it as another really solid base for servers. The problem is you won’t find a lot of support for it. If software is not in the community repo, tough luck, go compile stuff yourself and maintain them manually (or make your own compile template file for apk). But for what it is, Alpine is awesome IMO.

    Lastly, the one which seems to have the most teeth would be NixOS. The paradigm is so different and the packages never break your system and the OS is replicable with a single file, it’s just too good.

    If we could have NixOS on an Alpine (or similar) minimal base and the same support as Debian, it would be a no-brainer, but as it stands, NixOS is still among the best distros one can pick, if the learning curve can be overcome.

    I’m pretty excited for Devuan Daedalus. Aside from Linux stuff, FreeBSD, NetBSD, OpenBSD and DragonflyBSD shouldn’t be excluded, but the problem with those is drivers most of the time (which isn’t a problem if you run them as VMs). Other than that, containers are typically better on Linux (OCI and Linux containers), but FreeBSD jails should also suffice.


    It’s hard for me to take a decision. I’m already working on getting nixos to work on one of my sbcs, but I wonder how much I’ll make use of it after deployment.

  3. Is it even legal for Redhat to stop releasing the source code? I thought the entire GNU/Linux (GPL) terms was that the source code must be available. It seems to me that if this isn’t the case, then anyone can do anything with Linux, and not adhere to the GPL terms. Can anyone explain to me why they “most likely” can do this? Is it because the GPL license isn’t really legally binding anyway? Thanks.

  4. Putting the code behind a paywall isn’t even the main problem. The main problem is that the service subscription comes with terms of agreement which prevent you from redistributing the code.

    It’s not that they prevent you from doing so, it’s that if you try to redistribute it, your subscription service will get terminated. This is deliberate so that you can’t share it without losing support. They can’t retaliate if you share, but if you want to keep being supported, you have to not redistribute.

    This is not illegal, because the contract is for support service.

Continue the discussion at community.learnlinux.tv

Participants

Avatar for system Avatar for Mr_McBride Avatar for ameinild Avatar for ThatGuyB