Remix.run Logo
antonyh 5 hours ago

All I want is init scripts and X11, but the horizons are shrinking. I've already compromised with systemd, and I don't like it. I see BSD in my future, or at least a linux distro from the list here https://nosystemd.org/ - probably Gentoo. Nothing to stop me, absolutely nothing at all. I just need a few days free to backup/wipe/reinstall/reconfigure/restore_data and I'll be good. Better make that a few weeks. Maybe on my next machine build. It's not easy, but I build machines for long term use.

As for Linux from Scratch - This is something that's been on my radar, but without the part I'm truly interested in (learning more about SysV) then I'm less inclined to bother. I don't buy the reason of Gnome/KDE - isn't LfS all about the basics of the distro than building a fully fledged system? If it's the foundation for the other courses, but it still feels weak that it's so guided by a future GUI requirement for systemd when it's talking about building web servers and the like in a 500Mb or less as the motivation.

hparadiz 4 hours ago | parent | next [-]

OpenRC on Gentoo works great. I have a full bleeding edge Wayland KDE Plasma with Pipewire setup that I game on.

OpenRC recently added user "units" aka services running as a user after a session start. Something that many new GUI user space applications rely on for various things.

There are growing pains. https://bugs.gentoo.org/936123

Especially when upstream hard requires systemd. More annoying when there's no real reason for it.

But there is a way forward and I highly recommend people try to build software to work without systemd before assuming it's always there.

tokyobreakfast 4 hours ago | parent | prev | next [-]

I wonder if the impetus behind the (terrible) monolithic design of systemd was to force standardization across distros. The choice was more political than technical.

If different choices were available for init, DNS resolver, service control manager, volume manager, etc... we would adversely contribute to the schizo distro landscape the people holding the money bags are actively trying to get away from.

With systemd it's an all-or-nothing deal. You get the good with the bad, but all distros shit the bed in the same, deterministic way.

Not even Windows does this. There is no "systemd" equivalent. Yes, Windows ships as a single OS—as do the BSDs—but all the components were developed separately.

If all they wanted was a service control manager, there were many (better) options already in existence they could have used.

bryanlarsen 4 hours ago | parent [-]

systemd is not a monolith, and distros make different choices on what portions of systemd they which to ship and enable by default.

For example, not all distros ship and use systemd-resolved by default, to choose from your list.

bsimpson 4 hours ago | parent [-]

systemd-boot competes with grub

bryanlarsen 26 minutes ago | parent | next [-]

Even better example, I don't think systemd-boot is broadly adopted yet although there are certainly some distributions that use it.

5G_activated 3 hours ago | parent | prev [-]

and grub is a rotting pile while systemd-boot is a simple boot entry multiplexer that rides off the kernel's capability of being run as an EFI executable, it just happens to live in systemd's tree. not a good example

fragmede 3 hours ago | parent [-]

It's a pretty good example of why people think systemd is bloated and does too much. It's a simple boot entry multiplexer. Does it need to live in systemd's tree?

bryanlarsen 2 hours ago | parent | next [-]

Nobody complains about a very wide variety of only vaguely related utilities being in the Gnu coreutils tree.

Foxboron an hour ago | parent [-]

Nor the 20 or so odd reimplementations of various filesystem drivers and LUKS encryption in the grub2 tree.

But, who is counting?

5G_activated an hour ago | parent | prev [-]

so its a marketing problem, irregardless of whether it's in systemd's tree because the systemd maintainers want to maintain it in-tree

razighter777 4 hours ago | parent | prev | next [-]

What practical problems do you run into with systemd?

All the compliants I see tend to be philisophical criticism of systemd being "not unixy" or "monolithic".

But there's a reason it's being adopted: it does it's job well. It's a pleasure being able to manage timers, socket activations, sandboxing, and resource slices, all of which suck to configure on script based init systems.

People complain in website comment sections how "bloated" systemd is, while typing into reddit webpage that loads megabytes of JS crap.

Meanwhile a default systemd build with libraries is about 1.8MB. That's peanuts.

Systemd is leaps and bounds in front of other init systems, with robust tooling and documentation, and despite misconceptions it actually quite modular, with almost all features gated with options. It gives a consistent interface for linux across distributions, and provides a familar predictible tools for administators.

cyberax 3 hours ago | parent [-]

Ohh... I have sooooo many issues with systemd. The core systemd is fine, and the ideas behind it are sound.

But it lacks any consistency. It's not a cohesive project with a vision, it's a collection of tools without any overarching idea. This is reflected in its documentation, it's an OK reference manual, but go on and try to build a full picture of system startup.

To give you concrete examples:

1. Systemd has mount units, that you would expect to behave like regular units but for mounts. Except that they don't. You can specify the service retry/restart policy for regular units, including start/stop timeouts, but not for mounts.

2. Except that you can, but only if you use the /etc/fstab compat.

3. Except that you can not, if systemd thinks that your mounts are "local". How does it determine if mounts are local? By checking its mount device.

4. Systemd has separate behaviors for network and local filesystems.

5. One fun example of above, there's a unit that fires up after each system update. It inserts itself _before_ the network startup. Except that in my case, the /dev/sda is actually an iSCSI device and so it's remote. So systemd deadlocks, but only after a system update. FUN!!!

6. How does systemd recognize network filesystems? Why, it has a pre-configured list of them: https://github.com/systemd/systemd/blob/4c6afaab193fcdcb1f5a... Yes, you read it correctly. A low-level mount code has special case for sshfs, that it detects by string-matching.

7. But you can override it, right? Nope. This list is complete and authoritative. Nobody would ever need fuse.s3fs . And if you do, see figure 1.

I can go on for a looooong time.

nomel 3 hours ago | parent [-]

5 and 6 sounds like good candidates for a bug reports/PR, if there's not already some "right" way to do it.

cyberax 3 hours ago | parent [-]

They're already reported. And ignored. Have you _seen_ the systemd issue backlog?

The iSCSI loop issue: https://github.com/systemd/systemd/issues/34164 It keeps popping up again and again and is summarily ignored.

The remote FS detection also came up multiple times, and the maintainers don't care.

nomel 3 hours ago | parent [-]

> and the maintainers don't care.

I'm not sure that's fair. I think better proof of this would be a rejected PR rather than a neglected bug report.

This is Linux, after all. Problems found with specific hardware are almost always solved by people with that hardware, not the maintainers, who are usually busy with the 99%.

cyberax 2 hours ago | parent [-]

The problem here is more fundamental.

Lennart refused to make all the /etc/fstab options available in regular mount units. And yes, there was an issue, no I'm too tired to look for it. The wording was pretty much: "Give up, and gtfo, this is not going to happen. Just because."

I'm convinced that systemd can't be fixed by its current team of maintainers. They are just... untidy.

I don't know about you, but if I end up writing low-level code that _needs_ to know whether the mounted file system is "remote", I won't do that by comparing against a hard-coded list of filesystems inside PID0. Or by using wild heuristics ("if it's on a block device, then it's local").

I would put these heuristics in a helper tool that populates the default values for mount units. Then allow users to override them as needed. With a separate inspector tool to flag possible loops.

Fwirt 4 hours ago | parent | prev | next [-]

Try Alpine? It's not designed to be a "desktop" OS but it functions well as one. I find it easy enough to wrap my head around the whole thing, and it uses OpenRC by default.

cmrdporcupine 5 hours ago | parent | prev | next [-]

Almost wonder if this kind of thing will be an impetus for GNU Hurd to get more momentum. I saw an update recently that they're now finally properly supporting 64bit and sounds like there's active dev going on there again.

It apparently uses SysVInit

cf100clunk 4 hours ago | parent | next [-]

Others have been reminding us of the *BSD init systems, and I remind that SysVinit is not going away from Linux while projects like Devuan and others continue. GNU Hurd is another other-than-systemd learning opportunity.

antonyh 4 hours ago | parent | prev | next [-]

I've heard of Hurd, but never felt tempted to try it. That could be an interesting option.

raggi 4 hours ago | parent [-]

hurd init is a lot like systemd architecturally, it just gets to use kernel provided ipc rather than having to manage its own. if your objection to systemd is its architecture you don't want anything to do with hurd.

tokyobreakfast 4 hours ago | parent | prev | next [-]

Did they finally add USB support?

frumplestlatz 4 hours ago | parent | prev [-]

I would somewhat doubt it; the negative aspects of Mach’s design are a technical albatross around the neck of any kernel.

Apple has had to invest reams of engineering effort in mitigating Mach’s performance and security issues in XNU; systemd dissatisfaction alone seems unlikely to shift the needle towards Hurd.

josteink 4 hours ago | parent | prev | next [-]

> All I want is init scripts and X11, but the horizons are shrinking. I've already compromised with systemd, and I don't like it. I see BSD in my future

Freedesktop wants to kill X11 and are working continuously on that, to the point if rejecting patches and banning developers.

Popular desktop environments are increasingly depending on Linux-only things. KDE has officially removed support for FreeBSD in Plasma login manager (because of logind dependency).

Gnome 50 plans to obsolete X11 completely.

If you want that simple, bright future of yours, you’ll have to fight/work for it.

Timon3 3 hours ago | parent [-]

> Freedesktop wants to kill X11 and are working continuously on that, to the point if rejecting patches and banning developers.

Are you referring to the developer of Xlibre, who submitted multiple broken patches & kept breaking ABI compatibility for little to no reason[0]? Or someone else?

[0]: see discussion & linked issues in the announcement https://news.ycombinator.com/item?id=44199502

josteink 2 hours ago | parent [-]

I’m talking about that developer, yes. And I’m sure there’s more to the story than just ABI compatibility.

He wanted X11 to thrive. Freedesktop however has a goal for Wayland ultimately to replace X11, right? X11 should die. This is not hyperbole. It’s a stated goal.

So I think there’s more to the story than the simplified ABI aspect often mentioned here on HN.

Also Gnome killing X11 support is real.

So is KDE backing down on BSD-support.

These are facts, not opinions.

its_ubuntu2 4 hours ago | parent | prev [-]

[flagged]

cf100clunk 4 hours ago | parent [-]

I see this was your first HN contribution and you didn't post any links, so maybe that's what they were thinking?

its_ubuntu2 4 hours ago | parent [-]

Links? To what? "First contribution"? I'm not new around here.

(If anyone is wondering what he's referring to--I said that I was mystified why my post would be immediately downvoted.)

Let's try again, much shorter this time:

I am releasing a distro soon that is right up your alley. SEE MY PROFILE for info.