So drop them. There are other desktops that are faster, simpler, more stable, and aren't hard-coded to make Linux worse. Has everyone forgotten the design principles that made Linux good in the first place? Tightly coupling your software into other software is simply bad design. At some point you need to eat the cost of a looser abstraction to make your system less fragile, easier to reason about, and more compatible.
I believe maintaining the base book is the most important part, BLFS has some really good hints but a very significant amount of packages have few differences, collecting these in a separate hints file or similar would help a bit, at least for things that don't hard-depend on systemd like gnome.
I remember LFS from way back in the day.
What do we all think the overlap between LFS users and Gnome or KDE users is? I think it's pretty small.
I'm honestly worried about the forces pushing systemd in Linux spoiling the BSD ecosystem. And I'm worried that the BSDs do not have enough people to forge alternatives and will have to go along with the systemdification of everything. sigh
*Note, I ended up on Cachy, which is systemd, so I'm not some pure virtue signaler. I'm a dirty hypocrite :P
''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. Yes, systemd provides a lot of capabilities, but we will be losing some things I consider important.
However, the decision needs to be made.''
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.
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.
Systemd is basically the Windowsfication of Linux. I'm always surprised by the people that champion it who also used to shit on Windows with the registry or whatever.
Cognitive dissonance is a hell of a thing.
LFS should stick to academic pedagogy, instead of trying to compete in the Linux Distro space.
What I don't understand is how this has happened. I didn't care either way but everybody who did seemed to really fucking hate systemd. Then how come it became the default in so many distributions, with so much opposition from the community?
Most modern programmers don't learn COBOL60 or Commodore BASIC. Modern mathematician very rarely study writings of Euler or Gauss; even 50 years old math books may be hard to grasp for modern students.
I agree that using a simpler tool for educational purpose is useful, but since SysVinit is obsoleted almost everywhere, it made sense to drop it. LFS could have chosen a simpler init than the domain standard, like runit or s6-init.
Sysv at least gave you a peak under the covers when you used it, and while it may have given people headaches and lacked some functionality, was IMHO simple to understand. Of course the entire spaghetti of scripts was hard to understand in terms of making sense of all the dependencies, but it felt a lot less like magic than systemd does.
Systemd, by construction, is a set of Unix-replacing daemons. An ideal embedded system setup is kernel, systemd, and the containers it runs (even without podman). This makes sense, especially given the Red Hat's line of business, but it has little relation to the Unix design, or to learning how to do things from scratch.
I needed a way to avoid going to campus and fight for a DG/UX terminal.
It had nothing to do with FOSS fighting.
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.
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.
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.
Design-wise, I think having users modify service on/off state *and* systemd itself modify those states is a terrible design, which leads to stuff turning back on when you turn it off, or things turning off despite you wanting them on, etc. (also mentioned higher up)
FWIW after making puteron I found dinit https://github.com/davmac314/dinit which has a very similar design, so presumably they hit similar issues.
#!/sbin/openrc-run
command="/usr/bin/rsync"
command_args="--daemon ${RSYNC_OPTS}"
pidfile="/var/run/${SVCNAME}.pid"
depend() {
use net
}
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).
Seriously, I would not ever go back to a house of cards of bash and shell scripts of an init system. systemd solves actual problems and gets shit done, with a level of consistency that cannot be achieved by LEGO-like wet-dreams of UNIX worshippers. My favorite example is systemd-resolve and systemd-network that actually communicate together to indicate which DNS server is available on which network interface and with which search domains, to gasp do proper DNS routing.
Am I happy with all of systemd? Not always, it has a tendency to break networking after an upgrade with reexec. I'm still not convinced about homed. But oh my, you don't have to look further than actually solving problems to explain its success.
On a related note, X11 was never good and there's a whole chapter in the UNIX-HATERS Handbook explaining why.
Oh, and usually people shit on windows for many reasons, but some of the very core features of the OS are robust and the Linux crowd could take a hint. Like, you know, the notion of service at the OS-level and not some random bash script that nohup'd a binary. Oh wait, that's what does Windows, MacOS and Linux with systemd.
I used the SVR4 packaging system from heirloom-pkgtools (using this of a Claude port of V4 unix to x86_64 as well at the moment) for fun, and compiled up CDE on top of this to boot. I wanted to see what Linux would look like if you dressed it up as much like SVR4 as possible. I liked the result actually. It was kind of like what Sun might have done if they dumped their own kernel and switched to Linux instead.
Originally it used SysVinit, and I started working getting systemd to work with it (because after several years I've come to appreciate it) - but that's the point I stopped working on Headrat - I realised if I wasn't adding SVR4 stuff and was removing it instead, it wouldn't be SVR4 enough.
I don't know how I feel about it - after all I could do an LFS straight out of my head these days without referring to the LFS docs - but I do feel there is something lost when as a Linux community, we try to shove the baggage under the rug and pretend that things like SysV init didn't play a massive part in Linux's rise throughout the 90's and 00's.
History is important, even if we don't like the code today and have more capable tools. But I guess SysV init is deader than dead at this point.
There is still interesting code patches here and there, and interesting info on brain damaged SDKs (gcc, glibc, etc).
Most of the time I remove the SDK itself, basically I write a linear and brutal shell script with fine grained control on the compiler/linker. I do push down to nearly remove completely the compiler driver (a spectacular failure) namely CPP->C->ASM->O.
I would like to move away from ELF too for a modern file format for dynamic libs and executable, but the "geniuses" using complex computer languages (mostly c++) for critical open source components make that a massive pain (runtime, ELF relocation requiring obsolete infrastructure, etc).
Lots of pearl clutching in here about it, tho
I believe it's `systemctl list-unit-files` to see all the config that's executed, included by the distro, and then if you want to see the whole hierarchy `systemd-analyze dot | dot -Tpng -o stuff.png`
To me, seems much easier to understand what's actually going on, and one of the benefits of config as data rather than config as scripts.
FreeBSD has a general utility that does this for you, daemon(8): https://man.freebsd.org/cgi/man.cgi?query=daemon&sektion=8
https://github.com/openbsd/src/blob/master/etc/rc.d/watchdog...
It's not a perfect equivalence, of course, SystemD diverges more from other UNIXes than GNU does.
I will soon be releasing a distro that is free of systemd, wayland, dbus, and other troublesome software. It is built starting from LFS in 2019, and now consists of over 1,500 packages, cross compiling to x86-32/64, powerpc32/64, and others if I had hardware to test. It's built entirely from shell scripts which are clean, organized, and easy to read.
I need help to get the system ready for release in 60-90 days. In particular, I need a fast build system, as my current 12+ year old workstation is too slow. Alpha/beta testers are welcome too. Anyone who wants to help in some way or hear more details, please get in touch:
domain: killthe.net
user: dave
UNIX design was so great that its authors did two other operating systems trying to make UNIX done right.
One of the few times I agree with Rob Pike,
> We really are using a 1970s era operating system well past its sell-by date. We get a lot done, and we have fun, but let's face it, the fundamental design of Unix is older than many of the readers of Slashdot, while lots of different, great ideas about computing and networks have been developed in the last 30 years. Using Unix is the computing equivalent of listening only to music by David Cassidy.
If the project is even split in different parts that you need to understand... already makes the point.
They actually did, but they made the mistake of packaging only the bare basics with it, and hiding it away as much as they could: https://en.wikipedia.org/wiki/Windows_Services_for_UNIX
The American government added some obscure law that forced POSIX compatibility on operating systems for certain grants, so Microsoft made their business OS POSIX-compliant.
In theory, nothing stopped you from downloading and installing up-to-date versions of common UNIX tools. Had Microsoft had the necessary foresight, they could've killed deverlopers' dependency on tools like Cygwin and Git Bash and Linux entirely for many pieces of software, but they were too busy trying to make Win32 the standard ABI.
Funnily enough, Win32 became the standard for proprietary software on Linux (thanks to Wine+Proton) while many Unix/Linux-based tools became the norm for development, even on Windows (git, Qt). How different things could've been!
For example, not all distros ship and use systemd-resolved by default, to choose from your list.
I think the *BSD are also good, at least from an educational standpoint, with their relative simplicity and low system requirements. Since there is a lot of integration making a from scratch distro might take less material, but it could be supplemented with more in depth/sysadmin exploration.
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.
It apparently uses SysVInit
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.
I dislike overloading systemd with tools that are not related to running services but systemd does the "run services" (and auxiliary stuff like "make sure mount service uses is up before it is started" or "restart it if it dies" and hundred other things that are very service or use-case specific) very, very well and I used maybe 4 different alternatives across last 20 years
If you only learn about sysvinit and stop there, you are missing large parts of how a modern Linux distro boots and manages services.
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.
There is a difference of opinion. Freedesktop wants to "stabilize" X11. That does mean that they do not want to evolve Xorg. However, it does not mean that you cannot keep using it or that they are going to take it away. In fact, it is still being maintained and will be for a long time.
You can interpret the rejecting of patches and banning of developers as political. However others see the rejection and banning as protecting the stablity that is the goal.
If your goal is for Xorg to evolve and not to stabalize (fair), you may prefer Xlibre as a project.
Phoenix looks pretty cool too.
KDE Plasma and GNOME are trying to kill X11. Or, at least, they do not want to maintain support for it in their projecs. And COSMIC did not bother to add support for X11 at all. That will probably be the trend on desktop Linux.
Someone should probably save the required source package versions (and patches) before they disappear though
I'm not a systemD fan but SysV is not without its quirks and weirdness and foot guns
In X11/Xorg's case, a common example would be environments built off different window managers, panels, launchers, etc. In theory nothing prevents Wayland to have something similar but in practice 17 years after its initial release, there isn't anything like that (or at least nothing that people do use).
At least in my mind, the Unix philosophy isn't some sort of dogma, just something to try and strive for and a base (like X11) that enables others to do that doesn't go against it from the perspective of the system as a whole.
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
What a horrific thought.
> 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 desktop these days without Sysd.
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.
So when it comes to projects that teach the fundamentals of GNU/Linux, such as LFS, overwhelming the user with a large amount of user space complexity is counterproductive to that goal. I would argue that having GNOME and KDE in BLFS is largely unnecessary and distracting as well, but systemd is core to this issue. There are many other simpler alternatives to all of this software that would be more conducive to learning. Users can continue their journey with any mainstream distro if they want to get familiar with other tooling. LFS is not the right framework for building a distribution, nor should it cover all software in the ecosystem.
https://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem
When Windows Services for UNIX came to be, it was already too late to matter, it wasn't really from Microsoft, and came with its own set of problems.
I am speaking from when Linux was still in baby steps, and basic stuff like ELF had just been added with the kernel version 1.0.9, in 1995.
Things could be even more different, had Microsoft kept Xenix, which was my introduction to UNIX, and one of Bill Gates darlings, actually.
https://www.theregister.com/2002/03/20/bills_vision_for_the_...
"The Future of Xenix"
https://archive.org/details/Unix_World_Vol02_10.pdf/page/n21...
I have had both ruin days for me. In particular the "hold down" when it detects service flapping has caused issues in both.
I use runit now. It's been rock solid on dozens of systems for more than a decade.
I need my system to work!
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.
The two projects are complete opposites except in one way, they replace older stuff.
Your link is irrelevant. It points to OpenBSD which uses rc, not sysv. The 3 lines of this rc startup script use a file of 400 lines of shell with commands that don't exist in SysVinit.
With sysv, the difficulty depended on the local tools because the launching scripts could not be shared across Linux distributions. Debian used the compiled helper `start-stop-daemon` while Redhat did not.
With sysv, some sysadmin tasks require external tools. Try to write a launching script with a smart autorestart in case of crash. Make it work even when the daemon forks. Do not assume that the daemon writes its initial PID anywhere. IIRC, to get this feature, we had to drop sysv for runit, two decades ago. Now it's just 2 lines in a systemd unit.
I haven't done LFS since my tweens (and I'm almost 30 now), but I remember the sysvinit portion amounted to, past building and installing the init binary, downloading and extracting a bunch of shell scripts into the target directory and following some instructions for creating the right symlinks.
Obviously, you can go and check out the init scripts (or any other individual part of LFS) as closely as you wish, and it is easier to "see" than systemd. But I strongly protest that sysvinit is either "Linux" (in that it constitutes a critical part of "understanding Linux" nor that it's really that understandable.
But setting aside all of that, and even setting aside the practical reasons given (maintenance burden), when the majority of "Linux" in the wild is based on systemd, if one wanted to do "Linux From Scratch" and get an idea of how an OS like Debian or Fedora works, you would want to build and install systemd from source.
What makes you decide that these are troublesome software's? Systemd is usually argued that it is monolithic and breaks the Unix paradigm.
But then you are going for X over Wayland? X is a monolithic application that breaks the Unix paradigms.
Are you just picking things because they are old, or is there a reason you decided to go with this setup?
Mr Pike has indeed constructed a better OS than Unix; too bad AT&T neither knew how to achieve viral popularity, nor why Free Software (as in GPL) is going to dominate the world. By about 1995, it was already too late. (Something similar happened to Inferno vs Java.)
Still, the Unix principles of modularity, composability, doing one thing well, and unified interfaces are widely considered very sane, and adopted.
To make an analogy: another part of LFS is building a compiler toolchain. You don't need to understand GCC internals to know how to do that.
We need both.
The whole point of sysv is the components are too small and too simple to make it possible for "showstoppers". Each component, including init, does so little that there is no room for it to do something wrong that you as the end user at run-time don't have the final power to both diagnose and address. And to do so in a approximately infinite different ways that the original authors never had to try to think up and account for ahead of time.
You have god power to see into the workings, and modify them, 50 years later in some crazy new context that the original authors never imagined. Which is exactly why they did it that way, not by accident nor because it was cave man times and they would invent fancier wheels later.
You're tired of hearing complaints? People still complain because the problem did not go away. I'm tired of still having to live with the fact that all the major distros bought in to this crap and by now a lot of individual packages don't even pretend to support any other option, and my choices are now to eat this crap or go off and live in some totally unsupported hut in the wilderness.
You can just go on suffering the intolerable boring complaints as far as I'm concerned until you grow some consideration for anyone else to earn some for yourself.
Like clockwork, we'd have a SystemD edge case cause a production-down incident at a (single!) customer site once per year. Inevitably, we'd burn anywhere from a half day to a week attempting to figure out WTF, and end up in some Github Issue where Systemd Project heavyweights go "Wow. Yeah, that looks bad. Maybe we should document it. Or fix it? IDK." and they'd do neither.
The project is full of accidental complexity that its maintainers can't be bothered to fix when unplanned interactions cause problems and are brought to their attention. I certainly don't blame them; that sort of work is only interesting to a very specific sort of personality, and that sort of personality doesn't tend to thrive in a typical software company.
I can also absolutely say that I've never had a showstopping problem with OpenRC in the nearly twenty-five years I've been using it. It's remarkable how reliable it is.
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.
The only other page that covers it is how to compile it and it install it (make configure, make, make install essentially- with a bunch of flags).
It kind of touches upon a few commands that will let you know what its doing and how to get it started, but from this page you don't learn much about how it works.
In fact, one of my takeaways from LFS was that I already kind of knew how a linux system starts... and what I really wanted to learn was how the devices are discovered and configured upon startup to be used, and that is pretty much all done in the black box that is SystemD.
This system has many powerful features like built in ccache/distcc support for the build, support for building in QEMU, etc. Eventually it will be fully sandboxed.
There is a heavy emphasis on Doing Things Right according to an old school way of thinking. Everything is kept as simple as possible, yet as full featured as is practical. A major goal is to have everything documented and explained, starting with the shell scripts which build the system step by step in an easy to follow manner.
No package manager currently, though a simple one is in the works which is integrated into the build scripts. It's not really needed. You just build a complete system with all packages you want installed in a single run, with your own configuration pre-loaded. This gets compressed to a tarball. Then to install, create a partition, extract the tarball, edit a few files, install the bootloader, set passwords, and go.
I for one will not be strong armed into systemd or any other tech. If KDE makes it impossible for me to run without systemd, it goes into the trash bin. I will just install Trinity (KDE3) and be done with it. (Gnome deserves no consideration whatsoever.)
Both can devolve into empire building. We need both to be transparent and open.
Though it seems to be sneaking in through application space on a WinNT foundation
Also Linux is trailing here Solaris, OS X, Aix,...
See, this is why when I refer to the Systemd Project, I spell it as "SystemD", and when I'm referring to systemd(1), I spell it "systemd". I understand that some folks who only wish to shit on the Systemd Project also spell it that way, but I ain't one of them.
> systemd-init is a small slice of the code in the systemd repository.
Given the context:
Yes, systemd provides a lot of capabilities, but we will be losing some things I consider important.
It has some really nice tools and features that Grub lacks (i.e. it has tooling for checking the state of things like secure boot and analysing the security risks of your boot configuration), but every mainstream Linux OS I've used still relies on tools like Grub to boot.
I have some gripes with systemd-boot's limitations (notably, the insistence on an unthemed, white-on-black menu system that's not exactly enticing to Linux newcomers) but it's hard to deny its merits. Grub is tied together with a spider web of scripts calling each other, loading modules, generating code that is then executed again, and one mistake in one script can cause the bootloader config four scripts down the line to fail, leaving the system unbootable; the concise configuration file for systemd-boot makes for a much better bootloader configuration system in my opinion.
Do you have a reference? Not that I don't believe you, but I hated this behaviour from Poettering (although he seemed to more often blame the user) and we should totally raise up issue like this. It's a mature product that shouldn't have sharp edges any more.
(I recommend staying far away from "X11libre" also, for the same reason, with no further comment.)
Monolithic stuff is OK too, where it makes sense. The kernel is monolithic. ZFS is monolithic.
(Yes, this system has ZFS support. The module is built in to the kernel. In time it will support booting from ZFS also, when I finish the initrd code.)
There is a clear, solid reason for everything this system is or does. I'm not a contrarian or a purist, just someone with opinions gained from long experience who is not happy with the direction mainstream Linux is headed. My system is a zen garden of bliss compared to buggy garbage like Ubuntu.
Really, it's like someone added a turbo button. Ubuntu and friends are so bloated, laggy, and slow. I regularly use this system on 15-20+ year old hardware. The default window manager is Enlightenment e16. It's snappy and responsive everywhere.
KDE, Xfce, etc are supported also and are noticeably peppier than on mainstream distros, just due to the lack of bloat, gazillions of daemons running in the background, etc. Out of the box, nothing runs by default. You enable only what you want.
Another inviolable principle is that no application is allowed to originate or receive network traffic unless the user specifically requests it. There is ZERO network activity going on in the background. None of this steady stream of who knows what contacting who knows where that goes on with other systems. No auto update etc. No internet required or used during the system build. Python module installs do not consult the central repository or download anything. Meson or cmake does not download anything. Etc. All that's patched out and disabled.
It's a distro that is meant to be forked. It's very easily done. It's a blank slate, a vanilla Linux system with subtle and tasteful improvements that is the ideal starting point to customize to your exact specifications. If you want to add in systemd and wayland, fine, I don't care, it's your system and you can build it according to your desires. People can use this platform to build their own custom OS and save themselves a ton of work vs. starting completely from scratch.
It's a system that can be audited. Everything is built with shell scripts, starting with source archives and patches that are applied during the build process. It's all inspectable and the process can be understood step by step.
It's a way to hit the ground running with a full featured, working system, while learning in the process. This distro will teach you what LFS would teach you, but with less of a "sheer cliff face" learning curve, letting you focus more on higher aspects of building the system while still learning the low level details in time.
The build is actually overall simpler than LFS despite being way more featured, with things like Ada support. (Yes, it has GNAT.) I just found a way to do it better, and kept iterating countless times to simplify and improve to the max.
Existing systems did not satisfy my requirements or standards of quality, so I just had to create a new one.
The system uses GTK2 wherever possible, or GTK3 when not. I will either port everything to GTK2 later or create some kind of shim library. Help wanted here. Porting back to GTK2 isn't hard, I just don't have time to work on any of that at the moment.
UNIX is only an OS with some good ideas, and also plenty of bad ones.
No reason to stick with it ad eternum as some kind of holy scriptures.
GPL is on its way out, a good example is that all Linux competitors in the embedded space, including Linux Foundation's Zephyr, none of them has adopted GPL.
GPL based software is now a minority, almost everything uses licenses that businesses rather reach for.
The attitude that you don't need to learn what is inside the magic black box is exactly the kind of thing LFS is pushing against. UNIX traditionally was a "worse is better" system, where its seen as better design to have a simple system that you can understand the internals of even if that simplicity leads to bugs. Simple systems that fit the needs of the users can evolve into complex systems that fit the needs of users. But you (arguably) can't start with a complex system that people don't use and get users.
If anyone hasn't read the full Worse Is Better article before, its your lucky day:
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.
Hindsight is an interesting thing. Makes mistakes more visible while making Chesterton's Fences invisible.
We shouldn't forget these. These fences are there for the reasons. Yes, fences can be revised, but shall not be ignored.
FreeBSD came before Linux (as 386BSD), and is also active used by the industry. How much code did Sony or Raytheon shared back to FreeBSD? (LLVM is not FreeBSD proper.)
But of course that would destroy the narrative.
Leave it at what? How is Wayland not honest about it's intentions? It is completely transparent about the motivation behind the project. Whether you agree with the motivations is different, and thats fine to disagree with a project.
However there hasn't been a scenario where Wayland haven't been honest.
Yes, I am ignoring your side comments about systemd because I was asking about Wayland, and mixing the two together implies that you are just complaining about the new, rather than technical/architectural reasons.
(Plus I have to ask as "killthe.net" doesn't come up with anything)
I understand not wanting to shift from something that is wholly explainable to something that isn't, but it's not the end of the world.
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?
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%.
Which is why I asked "learn about what stuff". I think if the goal is to learn about "Unix" or OS design/ideas, you're better off with a leaner, "pedagogical" OS, like xv6. If the goal is to piece together an OS and really understand each piece, I don't think you really want sysvinit. You want something closer to an /etc/rc.local that just kicks off a few daemons and hopes for the best.
You can argue that sysvinit makes a better "compromise" between usability and clarity, and I'd entertain that idea, but then I think dinit is far easier to understand than sysvinit. And of course, at that point you can shave yaks till you fill the bike shed with wool.
Realistically, as much as people may hate it, if you have to pick a single init to standardize on for clarity and "building an entire Linux distro from the ground up, understanding how every piece fits together", systemd is the most rational choice. It's the most representative of the ecosystem, and requires the least "extra layers" to make the "desktop layer" work.
Weird. If I weren't a sicko and had OBS Studio installed on my multipurpose box [0] I'd not have dbus installed on it.
dbus is generally optional; not that many packages require it. [1]
[0] Two of its several purposes are video transcoding and file serving.
[1] This is another area where Gentoo Linux is (sadly) one of the absolute best Linux distros out there.
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 <strike>inconvenient to implement</strike> unsupported. E_NOTABUG", expecting PRs is expecting way too much.
But frankly if goal is to learn people about how Linux works, having SysV there is opposite to that goal
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-mnemonics-del...
http://killthe.net/patches/gtk-3.24.43-file-chooser-tweaks.p...
http://killthe.net/patches/gtk-3.24.43-remove-dead-key-under...
http://killthe.net/patches/gtk-3.24.43-restore-old-context-m...
http://killthe.net/patches/gtk-3.24.43-set-default-settings....
http://killthe.net/patches/gtk-3.24.43-show-alternating-row-...
Note that GTK 3.24.43 is the last version of GTK3.
My system is full of patches like this to tweak, improve, and adjust things. The point is to get off the "upgrade" treadmill and focus on making things work right.
We’ve already had NT + Linux userland; that was WSLv1.
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).
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.
Like systemd authors do! Hard-code the list of them in the kernel, including support for fuse and sshfs. Everything else is pure blasphemy and should be avoided.
Me? I'd have an explicit setting in the mount unit file, with defaults inferred from the device type. I would also make sure to not just randomly add landmines, like systemd-update-done.service. It has an unusual dependency requirements, it runs before the network filesystems but after the local filesystems.
I bet you didn't know about it? It's a service that runs _once_ after a system update. So the effect is that your system _sometimes_ fails to boot.
> systemd has .mount units which are way more configurable than /etc/fstab lines
It's literally the inverse. As in, /etc/fstab has _more_ options than native mount units. No, I'm not joking.
Look at this man page: https://www.freedesktop.org/software/systemd/man/latest/syst... The options with "x-systemd." prefix are available for fstab.
Look for the string: "Note that this option can only be used in /etc/fstab, and will be ignored when part of the Options= setting in a unit file."
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.
The "can only be used in /etc/fstab" systemd settings are essentially workarounds to do those things via fstab (and workaround fstab related issues) rather than depend on other systemd facilities (c.f. systemd-gpt-auto-generator). From a "what can you do in /etc/fstab without knowing systemd is working behind the scenes" point of view, then yes, systemd units are vastly more configurable.
I recently did a deep dive on my laptop because I was curious about an oddity - the /sys file to change my screen backlight (aside, why /sys and not /dev anyway?) was writable only by root - yet any desktop shell running as my user had no problem reacting to brightness hotkeys. I wondered, how did this privilege escalation work? Where was the policy, and what property of my user account granted it the right to do this?
It turns out the answer is that the desktop shells are firing off a dbus request to org.freedesktop.login1, which is caught by systemd-logind - or elogind in my case, since I do not care for systemd. A login manager seemed an odd place for screen brightness privilege escalation, but hey if it works whatever - it seemed like logind functioned as a sort of miscellaneous grab bag of vaguely console-related stuff. Generally speaking, it consults polkit rules to determine whether a user is allowed to do a thing.
Not screen brightness, though. No polkit rules. Nothing in pkaction. logind was unilaterally consenting to change the brightness on my behalf. And on what grounds? It wasn't documented anywhere so I had to check the source code, where I found a slew of hardcoded criteria that mostly revolve around physical presence at the machine. Want to change screen brightness over ssh? Oh but why would you ever want to do that? Hope you have root access, you weirdo.
I removed elogind. A few odds and ends broke. But nobody tells me what to do with my machine.
Some of these User Agents have to be fake. Android 6.0.1 with Chrome 144, really? lol
Theoretical or aesthetic advantages are no guarantee that the software in question will actually be superior in practice.
This fella would like to have a word with you:
Pretty much what I was thinking of. My understanding from reading some commentary in this area is the Linux implementation is yet a little botched due to how it handles waiting threads.
If you'd like to be an alpha/beta/release tester of this system, hit me up via email please. I'll start with an initial closed alpha release here in a month or so, if there's interest.
Now for the donation drive: I have plenty of time and a stable situation to work on this system, but the one drawback is I have little funds--and unfortunately my workstation is getting pretty long in the tooth. (AMD FX. It's been a good system, but I'm getting Left Behind here.) The main thing holding me back is compile speed, especially doing work on Chromium and WebKit. It's 12+ hour compile times for either of those, with the latest C++ standards they're using. The system as a whole builds in about 48 hours on my computer.
So I'm hoping to bump into an "angel investor" who either has some old Xeon (Broadwell or newer?) hardware laying around they would donate, something with lots of cores and memory, or who can make a cash donation for me to buy the gear I'm looking at on Ebay. $400-500 is enough for a nice 5x upgrade. It amazes me how cheap this stuff is. We're talking $5000+ hardware when it was new, for peanuts. Still quite powerful.
(A better video card would be great too, if you're feeling generous. Mine is a GTX570. I'd love to have a GTX7xx or newer, or equivalent AMD. That's more of a want than a need however.)
I'm very interested in ppc64 gear too. I want this system to have first-class PPC support. Anyone got an old POWER8 or POWER9 system laying around, or 32-bit stuff? I've got this system building OK in Qemu for ppc64le but it is SLOW, as you can imagine. Like 5 seconds per line in configure scripts, lol.
If anyone out there is in a position where they can help this project in some way, email me please! Thank you.
You'd think so, but the Github Issue linked by GP shows that the machinery is unreliable:
In practice, adding `_netdev` does not always force systemd to [consider the mount unit a network mount], in some instances even showing *both* local and remote ordering. ... This can ultimately result in dependency cycles during shutdown which should not have been there - and were not there - when the units were first loaded.
Given that SystemD can't reliably handle explicit use of _netdev, I'd say it has no hope of reliably doing any sort of "just works" inference.
Accessibility should be something that the system fully supports. There is speech synthesis and other useful bits installed so far. Maybe someone would like to work on this project. Email me if interested.
So, I'm not going to test your distro or switch from my Gentoo. I like Gentoo a lot, most of all because it's so very-very easy to patch any official package. Just put the patch in /etc/portage/patches/<package> and that's it. It gets automatically applied on the next install.
I'm using a Phenom II x6 1100 on a Gigabyte 880G. Firefox compiles in about 3-4 hours I think, not really sure. I do all Gentoo updates over night and it's usually ready in the morning. I can't say about Chromium or webkit - never used them - but 12h seems waaay too long.
If you like Gentoo, more power to you! It's not for me.
This isn't just another run of the mill distro. It's like nothing else that's out there.
I forgot to mention that I have PaleMoon on the system also, and it compiles in a much more reasonable time. Like two hours or so, I think.
Chromium and WebKit are ginormous, and worse, they are compiled with the latest C++ standards which are slow as hell to compile. Nothing wrong with my system, it just takes forever to compile this giant bloated crap.
Look of the size of the Chromium source code archives these days. It's fucking outrageous. 15 compressed gb (and growing rapidly!) of third party code vendored inside third party code vendored inside third party code, three or possibly even four levels deep! ("Yo Dawg...") Let's just have 5 complete copies of the LLVM suite in random places in there, because why not? Google has lost its marbles.
Yeah, I'm working to fix Chromium's little red wagon too. I'm on version 3 of my custom Chromium design. The binary of version 2 was slimmed down to 186 mb in size (compare to Google's version), with a 300 mb source tree (same here) when I quit on it to start version 3. This one is going to be the best yet.