Favorite linux distro

Which Linux distro do you use?

  • Manjaro (arch/systemd)

    Votes: 2 4.7%
  • Mint (ubuntu/systemd)

    Votes: 2 4.7%
  • MX (debian/SysV)

    Votes: 0 0.0%
  • Devuan (Debian/SysV)

    Votes: 4 9.3%
  • Gentoo (Openrc)

    Votes: 3 7.0%
  • Other

    Votes: 32 74.4%
  • Antix

    Votes: 0 0.0%

  • Total voters
    43
Status
Not open for further replies.
I have more and more machines running FreeBSD as it is more efficient to have them updated.

If RHEL support is required it’s AlmaLinux or Rocky these days. But sometimes they won’t boot out-of-the-box so it’s again FreeBSD bhyve running a canned AlmaLinux. ?‍♂️
 
If RHEL support is required it’s AlmaLinux or Rocky these days. But sometimes they won’t boot out-of-the-box so it’s again FreeBSD bhyve running a canned AlmaLinux. ?‍♂️
Why not mageia instead of Rocky or AlmaLinux? mageia does everything possible to stay compatible with Red Hat.

After installing AlmaLinux I quickly noticed that for desktop use it has absurdly few packages available in the default repos. Almost every basic package was missing.

mageia has 28 245 packages in the standard repos and it is also compatible with most RPM packages.

Furthermore, mageia also has better stability than Rocky and AlmaLinux and it usually also has (slightly) higher performance.

Finally, mageia is also more user-friendly than Rocky and AlmaLinux.

I don't really see the point why Rocky and AlmaLinux were brought to life. I understand that they are two successors to the popular CentOS.

But what killer feature did CentOS have that mageia doesn't have? I think the correct answer is that CentOS never had this killer feature.
 
Out of the top of my head I do say:

A) It’s compatibility to RHEL which is a mandatory requirement to get certain software packages under maintenance. CentOS had been a widely excepted substitute for RHEL environment and software vendor did accept it, if maintenance had been required. After the announcement that CentOS got layed off, there had been a few inquiries what else the customer base does favoir. AlmaLinux and Rocky had been the top choice.

B) It’s availability, at least it was with CentOS. AlmaLinux had been available from the start as Rocky wasn’t that available in the beginning, but now pretty much everywhere available as well.

C) Those are server running proprietary software, hence the software vendor determines what distribution is supported, most of the time it’s RHEL or some derivative. Public available repositories are not of any interest.

Regarding mageai, I haven’t seen it before and I looked it up a few secs ago, this is the first time I have actually heard of it. Looks like it’s related to Mandriva which I indeed had tried a decade ago but not in a production environment.

In the end it comes down to what is actually supported by the software vendor. If that is Windows, I do run Windows. ?‍♂️ Ok I don’t, but that’s a different story. ??
 
A) It’s compatibility to RHEL which is a mandatory requirement to get certain software packages under maintenance. CentOS had been a widely excepted substitute for RHEL environment and software vendor did accept it, if maintenance had been required. After the announcement that CentOS got layed off, there had been a few inquiries what else the customer base does favoir. AlmaLinux and Rocky had been the top choice.
Has it ever been shown that third party binary rpm packages work better on AlmaLinux/Rocky than on mageia?
In terms of compatibility, I think mageia will score as well as AlmaLinux and Rocky for 99% of users of the latter systems.

For example, think of advanced RPM applications such as DaVinci Resolve, Wolfram Mathematica, Matlab, Maple, COMSOL, Abaqus, Bitwig, Ansys, CATIA V5, Autodesk Maya, ..
You can also easily use all proprietary Linux browsers on mageia, including more exotic browsers such as Vivaldi.
Printer drivers is the same story. mageia has perfect support for printer drivers in the RPM format. To give a specific example. Brother printer drivers work just as well on mageia as on CentOS or Ubuntu.

You also have the fact that mageia has an alternative to the RPM Fusion repo:

The cases where AlmaLinux/Rocky's 100% RHEL compatibility makes a difference are rare niche cases that have no relevance to most companies.

You've got all those 'engineers' sitting around installing AlmaLinux for 100% compatibility even though it means nothing in the real world. And when trying to install some super basic default app, they find that all the most basic packages are simply not there: https://www.reddit.com/r/AlmaLinux/comments/z2qjwk/help_installing_codecs_and_other_necessary/

It seems to me that AlmaLinux was developed for engineers who lack any kind of ingenuity.
AlmaLinux is really a new low point in the commercial Linux world.
 
Actually the first question in my experience running proprietary software is which distribution do you run, if you encounter an issue. If you use a none supported distribution, you get no support and are on your own. ?‍♂️

This is simply about being supported in any case. Like I said, what ever the software requirement is, it will be full filled or a different product will be chosen to full fill their requirements. Simple business. ?

I don’t doubt that any linux binary can be made executed on any distribution for that matter. It’s just not the core business to make that work. It’s about running that software in the mandatory supported way to ensure minimal exposure to whatever is down the road that could be a potential road block in business terms. ?
 
Exactly.

PS: Regarding those engineers sitting around installing bare metal or any kind of VM. As far as I know nobody does that, as it’s an automated deployment based these days on ansible. Only certain specifics are done manually, but even that is avoided because if you automate it, it’s documented at the same time. Businesses want reliability.?
 
Actually the first question in my experience running proprietary software is which distribution do you run, if you encounter an issue. If you use a none supported distribution, you get no support and are on your own. ?‍♂️
This also makes no difference and is (almost) completely irrelevant.

1. In reality, you actually see that it is often not even clear for many popular software which exact operating system is supported and which is not.
Dymola is only supported as a 64-bit application on Linux. Dymola is distributed as an RPM package. For installation on Debian or Kubuntu systems conversion is required using the alien command.
Is Ubuntu, the most popular of all Linux systems, better supported than mageia in this case? I do not think so.
Is AlmaLinux better supported than mageia? This is also not at all clear.
CATIA is not a niche app, it is one of the most popular 3D apps in the world.
Their support page doesn't even mention RHEL, it seems to me they only tested it on OpenSUSE.

2. Have you ever had a problem with Microsoft and contacted their customer service? What you'll notice is that their English customer service is based in India, and they don't specialize in solving complex problems quickly, but rather in turning customers away. You can go to their customer service in India and ask some more complicated questions and what you will see is that 95% of the individuals in this customer service have very limited skills in solving technical problems with windows.
Are Linux engineers people with simple problems or more complicated problems?
What percentage of companies that produce software have employees who can quickly solve more complex problems with the software? I don't know if you have ever visited those companies, but if you look at the skills of the support teams, you will see that they can do almost nothing, unless they solve simple basic problems that anyone with an above average mind can do themselves.

3. You can ask your questions at communities of popular BSD and Linux distros as well as at commercial software companies. Do you think the answers you get will come faster or slower? Are the answers of higher or lower quality?

'no support and are on your own'
Well this is my experience, it doesn't matter. By nothing I literally mean 0.00000
 
I read above. I think this is poorly focused, it does not target X when it has a problem with application Y, but the owner of Y will only give support if you use system X.
I mean that support from most software companies is inept, which leads to the fact that it (almost always) doesn't matter if you use mageia or CentOS.

This is also not a subjective opinion but rather the naked reality that cannot be denied.

Long ago I myself worked in a support position for a technology company. At that time I had three colleagues and after 8 months I noticed that all three of them made a spelling mistake in the first sentence they had sent to every customer all those months. Two of these three colleagues had 'higher education'.

Most of the support departments of popular tech companies are incompetent in all areas and usually not smart enough to solve complex problems efficiently.

100% RHEL compatibility means nothing in the real world.
 
Uhm. Not sure it really is. Of course, Neither a Linux jail nor the "compat overlay" will actually run "Linux", because strictly speaking, this is only the name of a kernel, and the FreeBSD kernel just implements the Linux syscalls. (That's also a reason the name GNU/Linux was suggested for the "whole OS", as most other base components typically come from the GNU project).

But then, everything "special" about any distribution is outside the kernel anyways. So might indeed be relevant which distribution you use to install a Linux jail, or for "compat". Going with the official Linux ports, you will have something similar to a "minimal" CentOS-7 in /compat/linux.
Yeah, I'm very new to FreeBSD and still don't understand how some things work. I was thinking it was a VM and not a compatibility program. ?
 
I was thinking it was a VM and not a compatibility program. ?
Well, it's neither. It works with a full "Linux" (IMHO indeed better: GNU/Linux) userland, just without Linux itself :cool: If you want to put it that way, the FreeBSD kernel can "impersonate" Linux ?

A VM would be much too heavy-weight for the purpose. Thankfully, FreeBSD is not Microsoft, which indeed needed a VM for its "XP mode" ?
 
What I'm seeing on the Internet is that 'new' Linux distros keep popping up like 'flavor of the day', and then after a short time, the project gets abandoned when the one-developer 'team' realizes that upkeep is more than they bargained for.

I stopped caring a long time ago about which distro I use. For me it's like, if I have a problem I'm trying to solve, I'll pick something up from that heap of distros, try to use it to solve the problem in front of me, but not get too involved with it. Like rummaging for a junk food snack for a quick fix, instead of building a high-end kitchen. ?‍?
 
Has it ever been shown that third party binary rpm packages work better on AlmaLinux/Rocky than on mageia?

Alma / Rocky / CentOS (RIP) are bug-for-bug recompilations of the upstream (RHEL) source / patches. Mageia is not. Nothing against Mageia, but if I'm on the phone with a vendor and say "I'm on Rocky 8.7", that's the end of the part of the discussion about "what OS are you on" -- rather than launching off into "well, we haven't tested on X, can you use RHEL?"

And I get their point; it's hard enough to make something work, let alone make it work on the near-infinite variety of Linux systems out there.

I'm not saying I think it (Alma/Rocky/RHEL) is the best, or even better than, any other particular distrubution or OS.

What it is, however, is well known, widely used, and stable. It is the resurrection of "Nobody ever got fired for buying IBM" (as they, if you missed the news, own RedHat) for better or for worse.
 
Well, it's neither. It works with a full "Linux" (IMHO indeed better: GNU/Linux) userland, just without Linux itself :cool: If you want to put it that way, the FreeBSD kernel can "impersonate" Linux ?

A VM would be much too heavy-weight for the purpose. Thankfully, FreeBSD is not Microsoft, which indeed needed a VM for its "XP mode" ?
So does that mean it's similar to how wine functions but rather than windows executables it works with Linux executables?
 
So does that mean it's similar to how wine functions but rather than windows executables it works with Linux executables?
Actually, yes and no. Both solutions "wrap" the system-API, so far for "yes". But wine does it in user-space, and that's possible because Windows follows a design where "normal" applications never interact with the kernel directly, but use shared libraries (DLLs in windows world) instead, like KRNL32.DLL, USER32.DLL, and so on. So, wine can provide "stubs" for these in user-space and "wrap" them to call functionality of the host OS instead.

Therefore, for the "no" part: In Linux (and also in FreeBSD), the API of the system consists of the "syscalls" directly exposed by the kernel. Wrapping them has to be done in the kernel. And that's exactly what FreeBSD's kernel is doing, if an executable is "branded" as a Linux executable, the Kernel will expose the Linux syscalls to it.

Edit: Of course *most* Linux and FreeBSD executables also don't interact directly with the kernel but use the platform's libc instead, which, among other things, provides standard C and POSIX-conformant APIs and carries out the necessary syscalls. The difference is, on Windows, the syscalls are undocumented by design. On Linux and FreeBSD, they are "public".
 
For me that would be Pop!_OS because that's the only Linux distribution I still use, mostly because I got so used to it using it for many years after switching to it from Windows.
I use it on my laptop and it works great, but every time there's a big update I miss ZFS boot environments and the ability to update the operating system and packages independently.
Too many hours of my life have been wasted with fixing broken dependencies after updating Linux, which is why I switched to FreeBSD on my servers and desktop. :)
 
I thought I should post an actual answer for which Linux distro I like the most but do not use. Fedora, I like the btrfs lvm in the installer. Much like zfs striping, it's super handy. That's about it. :D
 
Let me try to explain why I mentioned it, not to bring it down or up the system, I wrote that since all co workers always came to me for problems they could not solve when systemd is involved. Nothing more or less :)
I am a aware of licenses too, no problem at at.
 
Too many hours of my life have been wasted with fixing broken dependencies after updating Linux, which is why I switched to FreeBSD on my servers and desktop. :)

Yeah. I just recently had a Debian install commit suicide in dependency hell. Nothing would install anymore, making repair impossible.

In FreeBSD you can nuke all packages and still have enough of a system left to bootstrap a new package tree.

If you damage the FreeBSD base system you can untar a release tarball, or rsync one or do `make installworld`, plenty of options. You can't do any of that on Debian, if your package system is shot your base system is, too, and you can't just untar a base system - only operations within the package manager are allowed (but might be impossible).
 
Yeah, i have the same experience. That is i nuked freebsd many times freebsd but i could always recover, like nothing happened.
For instance with many linux distro's this is not possible.
Maybe one exception gentoo-linux. I nuked it and then i just untarred a .tgz in root and everything went fine again.
That's the way i resolve always with freebsd.
Eg. to create a jail i just simply untar a .tgz.
This procedure "of install" is simple and strait-forward. No complications.
[ You can't do something similar on Windows]
 
Yeah, i have the same experience. That is i nuked freebsd many times freebsd but i could always recover, like nothing happened.
For instance with many linux distro's this is not possible.
Maybe one exception gentoo-linux. I nuked it and then i just untarred a .tgz in root and everything went fine again.
That's the way i resolve always with freebsd.
Eg. to create a jail i just simply untar a .tgz.
This procedure "of install" is simple and strait-forward. No complications.
[ You can't do something similar on Windows]

Yeah, until you try the famous line:
Code:
# rm -rf /

Not even FreeBSD can recover from that.

?
 
Yeah. I just recently had a Debian install commit suicide in dependency hell. Nothing would install anymore, making repair impossible.

In FreeBSD you can nuke all packages and still have enough of a system left to bootstrap a new package tree.

If you damage the FreeBSD base system you can untar a release tarball, or rsync one or do `make installworld`, plenty of options. You can't do any of that on Debian, if your package system is shot your base system is, too, and you can't just untar a base system - only operations within the package manager are allowed (but might be impossible).
Lets talk about pkgbase ?
 
Status
Not open for further replies.
Back
Top