Live data from Hacker News

Linux From Scratch ends SysVinit support

lists.linuxfromscratch.org

151–160 of 416 posts

Re: Linux From Scratch ends SysVinit support

#151
post #72

Earlier quoted context omitted.

If we look on LFS for its academic merit, I'm saddened that key historical elements of Unix/Linux design are being left behind, much like closing down a wing of a laboratory or museum and telling students that they'll need to whip up their own material to fill in those gaps.

From the announcement, it saddens them too: > As a personal note, I do not like this decision. To me LFS is about learning how a system works. Understanding the boot process is a big part of that. systemd is about 1678 "C" files plus many data files. System V is "22" C files plus about 50 short bash scripts and data files. However the reasoning they provide makes sense.. It's hard to build a Linux system with a deskt…

> It's hard to build a Linux system with a desktop these days without Sysd.

Most Gentoo Linux desktop users disagree. In fact, OpenRC is the default in that distro.

Having said that, I do expect that Gentoo has more manpower available than LFS.

Re: Linux From Scratch ends SysVinit support

#152
post #89

Earlier quoted context omitted.

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

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.

OK, think it through...

How do we determine that a specific instance of a filesystem mount is "remote", or even requires a "network"? Consider that the network endpoint might be localhost, a netlink/unix/other socket, or, say, an IP address of the virtual host (practically guaranteed to be there and not truly "remote").

systemd has .mount units which are way more configurable than /etc/fstab lines, so they'd let you, as the administrator, describe the network dependency for that specific instance.

But what if all we have is the filesystem type (e.g. if someone used mount or /etc/fstab)?

Linux doesn't tell us that the filesystem type is a network filesystem. Linux doesn't tell us that the specific mount request for that filesystem type will depend on the "network". Linux doesn't tell us that the specific mount request for that filesystem type will require true network connectivity beyond the machine itself.

So, before/without investing in a long-winded and potentially controversial improvement to Linux, we're stuck with heuristics. And systemd's chosen heuristic is pretty reasonable - match against a list of filesystem types that probably require network connectivity.

If you think that's stupid, how would you solve it?

Re: Linux From Scratch ends SysVinit support

#153
post #58

SysV init was the overengineered cousin to BSD init and I never liked it. Easily my least favorite of all init systems I've worked with over the last 30 years. On the flip side, daemontools or maybe runit were my favorites. Lots of good options for init/supervision tooling over the years and SysV was not among them.

SysV was this weird blind spot for many years. I remember installing daemontools on the OpenBSD server my office ran on because it was nicer to work with, and thinking that the Linux world would switch to avoid losing that particular feature war with Windows.

Gentoo Linux has been using OpenRC for at least as long as I've been using it (~25 years). It's unfortunate that OpenRC was unable to summon the manpower to do the spot-additions required for it to win the political war way back when Debian was looking to move from straight SysV init.

Re: Linux From Scratch ends SysVinit support

#154
post #110

Earlier quoted context omitted.

I'm running Gentoo without dbus and I'm stuck at gtk 3.24.34. I would love to see those patches. Your site appears to be down.

It's just HTTP only (no SSL) and there's nothing there. ... until now! Here's some nice GTK3 patches for you: http://killthe.net/patches/gtk-3.24.43-allow-disabling-atk-b... http://killthe.net/patches/gtk-3.24.43-allow-transparent-win... http://killthe.net/patches/gtk-3.24.43-allow-wheel-scrolling... http://killthe.net/patches/gtk-3.24.43-appearance-tweaks-and... http://killthe.net/patches/gtk-3.24.43-disable-mnemoni…

Thanks for your work! Getting off the "upgrade" treadmill really resonates with me.

Re: Linux From Scratch ends SysVinit support

#155
post #113

Earlier quoted context omitted.

I have been saying for years that Microsoft would eventually deprecate WinNT and switch Windows over to a Linux foundation. Things seem to be slowly but continually moving in that direction.

Makes no sense to dump a superior kernel and executive for Linux. The Win32 layer is the issue, not the underbelly.

I’ve had more hard crashes and BSODs on Windows than any other OS. And I use Linux & Mac more than Windows. Not sure how it’s superior.

Re: Linux From Scratch ends SysVinit support

#156
Sadly is Linux is no longer what is used to be for my generation that cut their teeth having to patch kernels for basic hardware support.

Linux is now effectively systemd/linux, and is attempting to become flatpak/systemd/linux through various corporate sponsored initiatives. The only thing worse, in my eyes, are people who distribute things as docker containers.

The Linux distro as such is becoming an anachronism. There’s no real place to innovate without the inertia of choices made by external projects being enforced on you.

I think it’s a generational change. My generation had Microsoft to contend with, and so sought certain freedoms, but this generation has walled gardens and AI to contend with, so freedom à la Microsoft seems okay and so Linux is being Windows-ified, while Windows itself becomes its own abomination.

Re: Linux From Scratch ends SysVinit support

#157
post #27

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 o…

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…

To pile on, a minimal OpenRC service file is just as complicated as a minimal SystemD service file; that is, they're both almost-exclusively composed of key-value pairs. For instance, this is the service file for the 'rsyncd' service [0]:

  #!/sbin/openrc-run
  
  command="/usr/bin/rsync"
  command_args="--daemon ${RSYNC_OPTS}"
  pidfile="/var/run/${SVCNAME}.pid"
  
  depend() {
   use net
  }
Like SystemD, OpenRC provides pre/post start/stop hooks that you can use to call out to other programs.

Unlike SystemD if you need to make nontrivial decisions at service-status-management time, you have the option of putting your scripts or calls to other programs inline, rather than hoping that SystemD gives you the hooks you need in the places you need them and passes in the data you require. [1]

[0] And if 'rsyncd' was supervised with 'supervise-daemon', you wouldn't need to specify the location of the pidfile.

[1] As a trivial example, you can dynamically depend on other services depending on system configuration (as PostgreSQL does). As a less-trivial example, you can check for and warn the administrator about common service misconfigurations with the same mechanism that provides service startup and status information (as several services do).

Re: Linux From Scratch ends SysVinit support

#158
post #108

Earlier quoted context omitted.

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.

> 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%.

> I think better proof of this would be a rejected PR rather than a neglected bug report.

I understand the sentiment you're expressing here, and it's often a reasonable one.

However, when every sharp edge case I've encountered with SystemD (both professionally and personally) ends either in a open Github Issue whose discussion from the project maintainers ends up being "Wow. That's tricky. I'm not sure whether or not that behavior is correct. Maybe we should do something about this or document this so other folks know about it." (and then nothing happens, not even the documentation) or a closed Github Issue with "Sorry, your usecase is inconvenient to implement unsupported. E_NOTABUG", expecting PRs is expecting way too much.

Re: Linux From Scratch ends SysVinit support

#159
post #24

Earlier quoted context omitted.

I don't have a dog in this fight but I find it funny that the anti-systemd crowd hates it because it doesn't "follow the Unix philosophy", but they tend to also hate Wayland which does and moves away from a clunky monolith (Xorg)

This one bothers me too. Systemd and Xorg are very similar in many ways. I do not know how you hate Systemd and love Xorg unless your real problem is just change. And, while I like Wayland, I think that liking the Wayland architecture should have you disliking Systemd. But that is just me.

I'm in the same boat. Systemd is an unpricipled mess and ships some quite shoddy replacements for pre-existing components. Wayland is super clean, it just takes for-everrr to add the features that users (and developers) expect. It could seriously have been done over 10 years ago not by heroic development effort, but by not being pathologically obstructive about features.

The two projects are complete opposites except in one way, they replace older stuff.

Re: Linux From Scratch ends SysVinit support

#160
post #152

Earlier quoted context omitted.

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.

OK, think it through... How do we determine that a specific instance of a filesystem mount is "remote", or even requires a "network"? Consider that the network endpoint might be localhost, a netlink/unix/other socket, or, say, an IP address of the virtual host (practically guaranteed to be there and not truly "remote"). systemd has .mount units which are way more configurable than /etc/fstab lines, so they'd let you,…

> How do we determine that a specific instance of a filesystem mount is "remote", or even requires a "network"?

The '_netdev' option works a treat on sane systems. From mount(8):

       _netdev
           The filesystem resides on a device that requires network access
           (used to prevent the system from attempting to mount these
           filesystems until the network has been enabled on the system).
It should work on SystemD and is documented to in systemd.mount

  Mount units referring to local and network file systems are distinguished by their file system type specification. In some cases this is not sufficient (for example network block device based mounts, such as iSCSI), in which case _netdev may be added to the mount option string of the unit, which forces systemd to consider the mount unit a network mount.
but -surprise surprise- it doesn't reliably work as documented because SystemD is full of accidental complexity.
Post reply on HN