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.
Which do I use regularly? Well, none ...

But if I must use Linux , I opt for either Debian or Devuan. Because they IMHO still come with the best stability and admin/maintenance tooling.
 
We are mostly a Windows Server shop but if we need to set up a Linux server I always choose Debian. In the event Debian is not an option (for example their package maintainer for Guacamole is lazy) I skip the rest of the Linux distros and use FreeBSD.
 
None, don't do linux at all (except for openwrt on router, but that's different story).

Oh, you're lucky when you can avoid it completely :D

My current exceptions are:
  • A VM running Devuan to host the controller software for my Wifi access points. Although it's written in Java, it has OS detection and platform-specific code (and obfuscated byte-code so no easy way to patch ...). So, probably no way to ever eliminate that :(
  • My VPS running Debian, currently used mainly as a nameserver and email gateway. The hoster can't run FreeBSD. Evaluating options to either eliminate the need for it completely or move it to a hoster that supports FreeBSD 😉
 
I tried and compared EndevourosOS vs Manjaro. And in my setup Manjaro was faster. (why i don't know ???).
[Offcourse i removed pulseaudio, and disabled wpa_supplicant & bluetooth]
 
FYI.

The Linux Fashion. Hi ARM!

I haven't had any issues with Manjaro. I use kernel 6.2, and I'm very satisfied. I used Ubuntu before, but Ubuntu boots slowly with my disk(about 2~3 minutes), so I replace it with Manjaro. I haven't tried Arch yet, so no comment.
BTW, in my experience, Linux is more stable than BSD. I use external disks. Linux works well, suspend also works. But I can't make it work with BSD. BSDs occasionally stuck to death with my external disks.
 
Slackware should be on that list. No longer a Slackware user, but it was the one distro that pointed me to FreeBSD. To each, his own.
 
Alpine Linux - simple fast and small/lightweight distro (musl instead of glibc). Very good for containers (docker) or lightweight servers.
 
I ditched macOS a couple of years ago for home use. Sold my nine year old iMac for a third of the price I had bought it for. I couldn't afford a new Mac, and every non-Apple user told me I could pick up a regular PC for a fraction of the cost...

I wasn't prepared to become a Windows user, haven't used it at home since around 2005, and work use has always been basically using Windows as a way to PuTTY into *nix boxen.

So I installed Linux. Ubuntu to begin with because of it's apparently good support for ZFS - it was pretty awful, mostly because it just got in the way so much - almost every management operation created a ZFS snapshot, making it hard to actually know what snapshot I might want to rollback to at a glance...

I switched to Manjaro shortly after and stuck with it for a couple of years, but packages suck - I had a bunch of packages I depended on that just disappeared, and loads more that were renamed. I had my audio recording setup mangled after some package/OS upgrades and generally became not very comfortable with system.

A few months ago I switched to nixOS. Despite the learning curve, I quite like the way the system functions, but it ditches the traditional file structure, and I think simple scripting might require some hoop jumping. Installation of nixOS coincided with having a kid, so I've not had proper time to become comfortable with it yet...

I'd have loved to have run FreeBSD, but the tools I use for audio recording/editing are not made for FreeBSD (reaper and linvst are the main ones), and they aren't something I want to accidentally break even a few days before I have a recording. Plus I'm not sure how stable/easy Steam is - I know there is a thread or two here, but I've not kept up to speed with the developments - it's pretty stable on the few Linux distros I've tried in the past few years.
Maybe one day I'll be tempted to get it all working on FreeBSD.
 
I've been a Debian guy since the late 90's. I've recently become enthralled with FreeBSD. However, I have a laptop that I needed to use for some Ham Radio type things and was having difficulties convincing the software to play nice. On a whim for something new I tried Garuda Linux. It's similar but different to Manjaro. Kind of a gentle intro to Arch. I've found I really like it and put it on a repurposed old iMac as well. So, my two now are FreeBSD, and Garuda Linux (Arch).
 
FreeBSD is very stable. Even more than Linux. But maybe there is an USB issue with external disks.
Just do this:
Code:
# cd /usr/ports/sysutils/fusefs-ntfs/
# make && make install
echo 'kld_list=/boot/modules/fusefs.ko' >> /etc/rc.conf

And make sure your USB stick is properly seated.

I had zero issues after that. 😋

Back to the topic of this thread: I do use DD-WRT on my Asus 1900 AC router, but that's it. Other than that, it's one Windows machine, and 3 FreeBSD machines, no Linux. I wrote about my Linux complaints elsewhere on these Forums and in Discord, but my main frustration is that every distro does it slightly different. When I do my research on how to accomplish a specific task like network config (or just about any other task), I sometimes stumble onto info for one distro, only to discover that it doesn't work for my installation. I'm done spending hours on research for simple tasks that should be standard stuff.
 
FYI.

The Linux Fashion. Hi ARM!
I think every year, 3 to 4 times, I end up with a small/medium issue with Arch that requires me to check carefully how to solve it. Once it was the sudden loss of bluetooth after an upgrade, which was fixed within a few days. In the meantime, if you needed bluetooth, you had to downgrade one package. While not overly complicated, I would not expect a beginner to do that – they just want their system to work.
This, in a nutshell, is why I don't use Linux as a daily driver anymore. Thanks to Murphy, it always broke when I was in a rush and had no time to troubleshoot. Freebsd has never done this to me. Yes I know it's possible to screw yourself, especially when you mix ports and packages, but the solution is simple - don't do that.

You could humorously point out that Bluetooth doesn't work in Freebsd at all, but to me that's part of the point. Once things start working, they keep working. No half-ass semi-engineered systems that'll be replaced with something somewhat less half-assed next year. Oh, you'll have to spend hours re-installing and re-configuring to get back to where you were with the old half-assedness, too.

I'm trying Void for gaming cause I want to kick my 30-year Windows addiction. I started treating Windows installs as semi-disposable some years ago. I don't do anything I can't stand to lose in them. This is so you can take the Ripley approach, nuke the install from orbit, and start over fresh. I'm doing the same with Void.

So far I'm very impressed with Void. Boots to a command line in 8 seconds with 0 effort taken to optimize it. It also feels very snappy. However, getting to an almost-equivalent Openbox desktop like I have in Freebsd was a science project. Also, the story on sound in Linux right now is just nuts.
 
Android. On my phone, all the time. It's a whole OS without GNU bits and systemd, properly sandboxed and has good support for proprietary (including paid) apps. Besides, libc/libm has lots of FreeBSD code.

Why settle for something only slightly better than FreeBSD?
 
Kali, daily at work. I am a web app pen tester so use some of the tools in Kali. Kali is really WAY too much for my purposes because I really only use nmap, curl and sqlmap but it's what they give us so it's fine. At home I have both FreeBSD and Debian VMs. FreeBSD serves as my "Kali" and I have some tools installed on it; Debian is my test bed for things like proxy chains.
 
Well it happens that poll options do not correspond with user base here.
How come you didn't put RHEL and derivatives as an option? :)

I have a RPI4 around which may or may not have a Linux distro on its sdcard at any moment. I may have any number of dormant or active Linux VMs that I may have used for something particular. I don't have Linux installation at home, and I prefer RHEL derivatives for my area of work which is enterprise. The runtime is orchestrated docker images anyway. Systemd is a done story. RHEL gives me any my team(s) a stable ecostystem regardless of the underlying technology of the project to be developed. It also allows my company certification of systems and compliance with government regulation, while infrastructure people have 1 system base to support with everything they need such as package proxies, domain, and so on.

If you wish to work with Linux commercially there is no going around systemd. If you do not wish to use Linux privately, it makes no sense learning the third service framework. Systemd is not bad for most users. It is a bad design breaking philosophy but it's an easy tool for most of the people. It's like 6-7 lines of config to boot up a Java based service and swallow its logs.

Ubuntu is something I feel dirty working at, always, since day 1 of Ubuntu it felt like a toy that could break at any moment.
 
If you wish to work with Linux commercially there is no going around systemd. If you do not wish to use Linux privately, it makes no sense learning the third service framework. Systemd is not bad for most users. It is a bad design breaking philosophy but it's an easy tool for most of the people. It's like 6-7 lines of config to boot up a Java based service and swallow its logs.
Two things in this paragraph I don't fully agree with:
  • You don't necessarily have to learn yet another framework just to avoid systemd. Sysvinit is still an option. Of course, that one is kind of crappy as well, but at least it's crap you most likely already know :cool:
  • Systemd is easy, well, yes, as long as you don't need something "more special" (like e.g. running multiple instances of one service, BTDT) and nothing goes wrong (in my experience, it doesn't exactly make debugging easy). And then, there are design decisions that make failing in very weird ways more likely. My personal pet peeve, the standard mode of operation just launches some process and as long as it keeps running, the service is considered "up", no feedback whatsoever, not taking into account that many services take some time to be fully "up".
 
I ran some 30 headless Debian machines at the job. Worked out well I must state but I hate how all the trained people ended up fighting systemd to be honest. Privately I ran RH5.1, Slackware xyz, Debian, Manjaro and some other distro's. Currently on Freebsd. The machine's on the job might have been switched to RHEL for all I know.
 
I hate how all the trained people ended up fighting systemd to be honest.
Sorry if that's not perfectly on-topic, but this is an issue since systemd was more or less "forced" upon the GNU/Linux ecosystem, most likely by corporate interest. Since then, and it's been MANY years, the topic was never really "settled", and probably never will be. That's what you get forcing something many don't agree with.

Now, how could that happen? My very personal opinion: The GPL has its share. My line of thought is: Companies are interested in open-source platforms to build their own solutions upon. Now if they want to build something based on GNU/Linux, they're confronted with the GPL. They can choose to change things, but then they are often obliged to also publish all of their own code, which is often not a viable option. So, what happened: They reach deep inside the projects, to change them "from inside" in a way to suit their needs, for their products. I don't say that's how systemd was "pushed", but it could be pushed because these structures already existed.

With a BSD license, there's no need to build up such structures, you're not obliged to share your "derivative work". There's still an incentive to push your changes of course (after all, fewer local changes lead to easier maintenance), but there's no incentive to build up structures reaching deep into a project to put you into a position where you can, uhm, "force-push".
 
Status
Not open for further replies.
Back
Top