> [...] This kind of harassment is something I hear about often from many maintainers of projects on SourceHut. It breaks my heart and I feel helpless to do anything about it.
I most certainly can't provide an answer here but doesn't the medium (IRC, mailing lists, forums, etc) facilitate this toxic environment too? People whose sole intent is to manufacture a narrative in order to harass someone, or their project(s), are a lot more comfortable doing so online. They are guaranteed a wide audience, lots of views and publicity which in turn maximizes the damage. Rarely do I encounter this behavior in workplace meetings, conferences or venues that require physical attendance.
I never became comfortable with neither the scope of systemd as a project, nor the ever expanding set of skills required to effectively use it. I was tempted to use the word mastering, but that would make the goal seem even more elusive, especially since with every new version one's knowledge would have to expand to cover its new features. 10 years later, it still looks to me like the project with a solution for everything in the IT industry, following trends, trying to cover all the bases. Always new things to learn, always the goalpost moving further and further.
You don’t have to “master” it, but just understanding the basics of what is a service file will make your everyday life much better if you are working with systemd-managed systemd.
Also, don’t get bogged down by systemd-* services, they are related but are usually not part of systemd at all.
> [..] majority of readers or Docker users have never ever heard of FreeBSD Jails [..]
I would argue that said users have never heard of UNSHARE(1) either, although Linux pretty much wipes the floor with anything else when it comes to containers. You can use UNSHARE(1) to create your container, extract a base image of your preferred distribution, configure it and start an instance. Heck, you can even create and package a shell script that does all the above for you. Nobody does that on Linux even though UNSHARE(1) (and friends) are very much finished products. They are not the products people want, that is, application specific containerization solutions like Docker, or something that can be easily deployed at scale in a reproducible and compliant way.
Thanks for that. I was building containers pre docker but didn't know about unshare. I'm going to play around with this.
I've heard of jails but haven't used BSD enough to ever use them. (And I'm not old enough to have ever mucked with zones. My Solaris boat anchors were just toys for a teen collector.)
> The systemd debacle is what led me down a rabbit hole toward the BSD's.
Like most, you could have simply moved to a distribution without systemd. Unlike Linux, the BSDs offer less choice when it comes to both init, service supervision and service management options. It is also evidenced in the comparison table in the OP. If anything the debacle resulted in creating more awareness and leaving people open to more choice.
That said, adopting one monolith instead of another sounds more like a knee jerk reaction than anything else.
> The proof in the pudding for me is to look at the running processes of a default system between BSD and Linux with systemd. Yikes.
This only scratches the surface. Daemons running under systemd have their PIDs supervised instead of using unreliable hacks like pidfiles. This is one of the reasons why systemd is preferred in large deployments and professional environments.
> Like most, you could have simply moved to a distribution without systemd. Unlike Linux, the BSDs offer less choice when it comes to both init, service supervision and service management options. It is also evidenced in the comparison table in the OP. If anything the debacle resulted in creating more awareness and leaving people open to more choice.
systemd had the opposite effect of giving people more choice. Before systemd every major distro ran it's own init service. Often they were variants of init.d but sometimes they might vary quite significantly. Debain, Ubuntu, Suse, Arch, Slackware and Gentoo -- they all had different inits. One of the reasons systemd was push so heavily was to standardise things across the different distros. Now the only distros still offering anything different are either those that are also gradually falling out of favour due to the changes in user trend; or newer distros that are only a minor blip in the Linux community anyway and unlikely to ever grow beyond that.
The exception here being dockerised Linux eg Alpine. But they fill a different use case.
> This only scratches the surface. Daemons running under systemd have their PIDs supervised instead of using unreliable hacks like pidfiles. This is one of the reasons why systemd is preferred in large deployments and professional environments.
Honestly, I'd take pidfiles over binary log files any day of the week. However you're right that systemd does bring some good ideas to the table (if it didn't, nobody would have adopted it). My issue with systemd is that it's needlessly hard to separate the wheat from the chaff. I know systemd isn't the monolith people often describe it as...but even so, it sure feels like it's an all or nothing deal at times.
BSDs aren't a "monolith", but the system and tools are developed together and parts can be replaced wholesale if you choose to do so.
Also, there's what, Gentoo and GUIX that don't use systemd? Gentoo still prefers building all source on the system which is a non-starter for most, and GUIX I didn't think was ready for a daily-driver role yet.
The most popular non-systemd distro I hear about is Void linux, which is a rolling release style distro that's pretty comparable to(though not based on) Arch.
As a tangent because you brought up distro's and difficulty, I know Arch has a reputation with some as being too difficult for regular skilled users, but as a regular skill level user myself, I find that the Arch/Void style rolling release paradigm of doing stuff makes things easier for noobs like me, not harder.
Once you get past the initial hurdle that is the first hour or two of install and setup(which you can do just by copying youtube tutorial instructions line by line) then everything after that is much simpler.
For me, I find that the majority of everyday linux problems all boil down to trying to install or update some kind of software. Either software you already have has a bugfix or feature you want in the newest update, or you have some new software you want to install. And because developers like new shiny things, often times the newest version of whatever has a dependency of some other new shiny thing.
Installing new software in a fixed release distro often quickly gets too hairy for me, but in Arch I can almost always a simple install directly from the main or user repositories. This has so far eliminated 95% of everyday problems for me defying the usual narrative I hear of it being "harder" to use for normal Joe's like me.
> For me, I find that the majority of everyday linux problems all boil down to trying to install or update some kind of software. Either software you already have has a bugfix or feature you want in the newest update, or you have some new software you want to install.
And yet the Linux Desktop community insists on sticking with the package manager/repo model that makes stuff like this such a pain. Worse, it's actively hostile to the concept of portable applications in general.
Devuan [1] and MX Linux [2] (Debian-like), Artix (Arch-like) [3], and Void [4] are four other systemd-free distros off the top of my head. There will be others.
Google still can't figure out how to get IPv6 working for containers on GCP, I swear that whole platform is a readheaded stepchild made to check a box.
OVH & DigitalOcean have both adpoted IPv6 as a first class feature on their VMs, Google is the only holdout that doesn't offer any IPv6 support on VMs among the major providers.
I'll probably be downvoted into oblivion for this, but this is a per peeve of mine. Your use of the expression doesn't make sense.
The expression is highlighting that you need to observe a negative in order to determine whether a rule is true. For example, if I make the statement: "Only birds have wings", then any observation of a non-bird without wings are exceptions to the rule that proves said rule.
The observation of a bat is indeed an exception to the rule, but it does not prove it. In fact, it does the opposite. It disproves it.
They didn't make their argument on choice, so your argument rings hollow:
Don't get me wrong, systemd actually adds a lot of needed functionality, but I really feel like it is a major philosophical branch away from the conventional Unix thinking of 'make a tool that does one thing really well'.
Your argument wasn't on choice, but on practicality: you weren't choosing something different because of the abstract value of choice.
The person replying to you had an argument based around choice: the practicality of the solution was ignored in favor of an abstract concept of choice, rather than practical benefit.
(I'm saying the person arguing with you was arguing against something you weren't arguing for.)
> Sorry if this sounds overly critical but I find it inethical to use the Chinese clones of Apple products.
Unlike most, not everyone is inclined to pay for the privilege of closed source, proprietary walled gardens (like those from Apple). People, especially those who believe in open source and free software ideals, consider the above practice unethical, which is probably why they don't buy Chinese made Apple laptops. Those users are largely in favor of sharing technological innovations for the benefit of everyone, instead of guarding them for a select few. So, no it is not unethical because, in the end, it doesn't harm the end user.
> musl appeals to me because I’m Australian and a sucker for an underdog it has a clean code base, permissive licensing, and is not a GNU project.
Although this is as good a reason as any, especially if someone is (politically) biased against the GNU project, I fail to see how and why the x86_64-musl target appeals to the OP in the first place. It ships a standard GNU userland, it uses GCC and GNU {core,bin}utils to (cross)compile most packages and GNU bash is a standard requirement for the build toolchain. Without the above, Void cannot exist.
A core property of the Voidlinux / musl-libc combination that goes unmentioned, is that one can easily leverage xbps-src as a native cross compilation toolchain to seamlessly (no porting/patching) generate static binaries for foreign architectures. As an example, one can generate static binaries for GNU tar and just use them on an android (bionic) device.
Finally, Void-linux ships with the xbps-uunshare utility as standard and allows a regular user to launch an unprivileged container with any distribution (like debian, ubuntu, etc). This way, the OP can enjoy the full gamut of software available on those glibc systems without the need to install and/or dual boot Windows.
> At least on 12-stable (idk if it made it into a 12.x-release) EVDEV_SUPPORT is enabled out of the box
The GENERIC kernel configuration for FreeBSD-12.x-release does not support EVDEV out of the box. It is there however for both 12 stable and of course head.
Given the financial positions involved they could easily afford to (market cap order of 30 vs 200 billion USD, Intel free cash flow per quarter of 5-15 billion). Regulatory authorities probably wouldn't let them, but that is another argument to make.
I most certainly can't provide an answer here but doesn't the medium (IRC, mailing lists, forums, etc) facilitate this toxic environment too? People whose sole intent is to manufacture a narrative in order to harass someone, or their project(s), are a lot more comfortable doing so online. They are guaranteed a wide audience, lots of views and publicity which in turn maximizes the damage. Rarely do I encounter this behavior in workplace meetings, conferences or venues that require physical attendance.