LeFantome

joined 1 year ago
[–] LeFantome@programming.dev 26 points 7 months ago

EndeavourOS has its own repos and uses them to good effect to add small but important quality of life improvements to Arch.

EOS also had the very good sense to not reinvent the wheel and reimplement the best thing about Arch ( the large, high-quality package library ).

LMDE ( Mint on Debian ) is another distro that gets this right.

[–] LeFantome@programming.dev 2 points 7 months ago* (last edited 7 months ago) (1 children)
[–] LeFantome@programming.dev 3 points 7 months ago

Those packages are not going to be any more stable when you get them. Just older.

When you get the bug fixes happening now, it will be long after Arch and EOS did.

My impression is that EndeavourOS is more stable than Manjaro after using both extensively.

Anyway, I agree as a general principle that we should stop telling people to switch distros to solve specific technical problems.

That said, you do not have to wipe everything to move from Manjaro to EOS. I have done it on multiple machines. Perhaps their suggestion was to fix your problem in place.

[–] LeFantome@programming.dev 1 points 7 months ago* (last edited 7 months ago)

First, you can run proprietary software on free software. So, running free software does not preclude license monitoring. It is also possible that certain licenses are not allowed even if they are approved by the FSF or OSI.

The goal more broadly is enforcing corporate policies around risk or whatever else needs to be enforced.

It may be that you HAVE to use certain kinds of software ( VPN was mentioned ). Perhaps you are NOT allowed to use certain software on work computers ( torrents and Steam clients come to mind ) or visit some kinds of websites.

The other risk that a company may want to monitor is ensuring software is up to date ( open source or not ). Stale software can have vulnerabilities that become attack vectors for the bad guys.

Finally there is access control, privileged access, and auditing. There may be systems or data that employees are not allowed to access or are only allowed to access under certain conditions.

I am not advocating anything here but it is totally normal for corporate IT to be tasked with limiting corporate risk and creating an auditable history of compliance. These are the kinds of tools and policies they use.

[–] LeFantome@programming.dev 2 points 7 months ago

That would not convince me. First, Red Hat contributes an enormous amount of code and infrastructure to the Open Source world. RHEL ships with a relatively small set of packages and Red Hat is the largest contributor to many of them—certainly many important ones.

More important though is that, for individual projects and code, Red Hat is a regular member of the community. They use code, they contribute code, they distribute all their code for free. When Red Hat creates new projects, they almost always choose the GPL as the license. Their contributions to Open Source projects are available to everyone. They are an unusually staunch Open Source supporter.

When it comes to distributions, Red Hat created the Fedora Project with the express intention of creating a mainstream Linux distro that was explicitly community led and committed to Open Source. The fact that Fedora does not want to ship non-free codecs is an example of the dedication to free software that is by design and part of the Red Hat plan.

Red Hat also runs CentOS Stream which is also Free Software in the licensing sense. CentOS is available to everybody for free. In my mind CentOS is not really a “community” distribution though as its purpose is explicitly to prepare software for selection into RHEL. So, Red Hat is a staunch gatekeeper and the way they manage the project is weighted heavily towards their own interests. It is still completely public and free though. Anybody can do whatever they want with it ( like AlmaLinux does ). This is again, all by design.

Both Fedora and CentOS are explicitly PUBLIC projects. The entire distro, not just the individual projects and packages, is available for free. Red Hat “distributes” these to the world which has particular implications for some of the licenses.

All of the above is 100% Open Source and represents more activity and investment than pretty much any other Linux company. It is an awful lot to ignore by the “Red Hat is proprietary now” crowd. It is a lot for me to ignore when deciding if “leech” is a word applicable to Red Hat.

I am not a Red Hat customer or even user by the way. I used them quite a bit many years ago. I have not used any RPM based distro in quite a while.

Red Hat of course also makes RHEL. RHEL is not a public Linux distribution. Red Hat only “distributes” RHEL to customers. You can be a customer for free ( as in beer ) but you are still a customer and you have to agree to that before Red Hat will distribute anything to you. The reason that I stress this of course is that Red Hat’s legal obligations around RHEL specifically are to their customers and not to the world—not to the public or any self-proclaimed “community” that is not a customer. When I say legal obligations, I am including software licenses which of course includes the GPL.

Red Hat makes 100% of the RHEL code available to their customers of course. This is not just GPL software where they have to but everything, including all the MIT, BSD, and Apache licensed stuff.

There is essentially no software available in RHEL that is not also available in CentOS. There is A LOT more software available in Fedora. People are not interested in RHEL to get access to the software or its capabilities. It is one of the most limited distros as a software library. People that want RHEL specifically want “the distribution”.

What does that mean? RHEL is not just a list of packages. It is a very specific expressions of those packages. It is specific versions. It is specific sets of patches and back ports. It is a substantial body of documentation detailing the behaviour of those specific packages. It is, most importantly, the commitment that Red Hat makes around those packages. Red Hat makes a series of promises. They can do this because of the substantial amount of time and investment they make into testing and profiling those packages—not just individually but as a complete distribution. Perhaps one of the most important promises is that Red Hat promises to maintain and support those packages for many years including timely security updates.

Only a small part of the value of RHEL is “the software”. The software is available from many sources, including in other ways from Red Hat. People wanting RHEL clones want access to all that other stuff that is not software. That is why they have to be “bug-for-bug” clones.

The exact recipe to build each package in RHEL is not meant to be public information. In my view, there is nothing wrong with that.

Can a Red Hat customer distribute the software they get from Red Hat? Yes. The various licenses allow them to do that. They cannot distribute images, logos, docs, and other trademarked stuff of course. But they can distribute the software. They can do that and Red Hat will not stop them ( or at least I am not aware of them ever trying ). Of course, if a customer distributes the exact builds of software they get from Red Hat, Red Hat no longer considers them a customer and will stop distributing FUTURE versions of RHEL to them. Actually, I am not even sure they have done that to anybody. They reserve the right to though. And that, threatening to not distributing their future efforts, is what has upset everybody so much. That is what makes them a leech, or unethical, or evil, or proprietary.

I am not convinced.

[–] LeFantome@programming.dev 46 points 7 months ago

The reason this is a first is because AlmaLinux recently decided to stop being a bug for bug clone of RHEL. Good for them. As this shows, they are now actually free to add value.

Rocky Linux cannot ship this patch unless RHEL does. Rocky cannot contribute anything by definition.

[–] LeFantome@programming.dev 2 points 7 months ago

The distro that comes to mind is LMDE ( Linux Mint on Debian ). The Mint team adds some polish, a better out-of-the-box experience, and some nice desktop tools ( productivity ). In addition, Mint will keep the desktop environment ( Cinnamon ) up to date which counters probably the biggest issue with Debian which is that the software versions get old.

I use EndeavourOS ( a version of Arch ) because, for me, having up to date packages led to higher productivity and greater stability. When I used Ubuntu, Debian, Fedora, or others, I was adding 3rd-party repos, PPAs, and compiling stuff outside the package manager. This always led to a mess over time.

These days, the choice of distro matters less as these problems can be handled other ways. Flatpak allows you to install newer GUI apps ( either newer versions or stuff missing from your repos ). This does not work for command-line stuff or the desktop itself. So, Flatpak compliments LMDE which keeps the desktop up-to-date.

A problem I had with distros like Debian and RHEL was that the dev tools get too out of date. These days, that is easily countered by something like Distrobox. Sandboxing the dev environment has other advantages and, if you muck it up it does not impact your system overall. Multiple dev environments can be handy too as the toolchains favoured by different languages can conflict. If you are not familiar with Distrobox, it uses containers ( like Docker ) but it feels like a much better integrated extension of the host system.

If you use Distrobox, you really do not have to use Flatpak if you do not want to. You can essentially layer on the package selection of any other distro on top of your base system.

I have considered this setup myself, Debian as a base with Distrobox on top to access the Arch packages repos and the AUR. LMDE would make sense for me for the same reasons I have to you. Probably the only reason I have not pulled the trigger yet is that, around the time I had this idea, VanillaOS announced their switch to Debian. Vanilla looks like they had much the same idea but are building it into the core concept of the distro. It has not really stabilized yet though.

[–] LeFantome@programming.dev 1 points 7 months ago (1 children)

Manjaro is a terrible recommendation for stability

[–] LeFantome@programming.dev 2 points 7 months ago

Unless you need to use software that only targets RHEL, I would not use AlmaLinux as a desktop. The desktop itself will get very stale. Apps can be upgraded with Flatpaks but the DE and dev packages are harder.

[–] LeFantome@programming.dev 19 points 8 months ago* (last edited 8 months ago) (2 children)

I am really curious to see what happens with GIMP when they finally release 3.0 ( before May hopefully ).

3.0 will introduce CMYK, non-destructive editing, and other pro-level features. So it will be interesting to see if more people suddenly find that it is a viable Photoshop alternative.

Even more interesting potentially is that nee features can actually ship. It has literally been years now that new ideas get lost in dev versions that nobody uses. Going forward, improvements can be added to stable releases that people will actually use. It could be a game changer for the project.

[–] LeFantome@programming.dev 28 points 8 months ago

Nobody should use OpenOffice. It is just an an ancient version of LibreOffice at this point.

The name OpenOffice is much better. Many people every year probably get pulled into OpenOffice without realizing what it is. I hate that Apache is just sitting on that codes and pretending it is still active.

Some people say that OnlyOffice has the best Microsoft Office interoperability. If LibreOffice is not good enough, maybe give OnlyOffice a try.

[–] LeFantome@programming.dev 13 points 8 months ago (5 children)

Honestly EndeavourOS is Arch once it is installed. As I have said before, EOS is more of an alternative installer with sensible defaults. 99.9% of the packages installed will be from the Arch repos or the AUR. Even the kernel is vanilla Arch.

I can install Arch. If I am bringing up a new system, I almost always reach for EOS instead. EOS has switched to KDE as the default DE. I still prefer XFCE myself.

view more: ‹ prev next ›