Systemd Lands Support For "XBOOTLDR" Extended Boot Loader

[pal666]

does systemd already come with a built-in Linux kernel replacement?

well, it comes with whole distro, unless you want to build it manually

[pal666]

Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".

btw, this explains why gnu is not unix

[ssokolow]

btw, this explains why gnu is not unix

You're not alone in that viewpoint.

Conversely, McIlroy has criticized modern Linux as having software bloat, remarking that, "adoring admirers have fed Linux goodies to a disheartening state of obesity."^[8] He contrasts this with the earlier approach taken at Bell Labs when developing and revising Research Unix:^[9]

Everything was small... and my heart sinks for Linux when I see the size of it. [...] The manual page, which really used to be a manual page, is now a small volume, with a thousand options... We used to sit around in the Unix Room saying, 'What can we throw out? Why is there this option?' It's often because there is some deficiency in the basic design — you didn't really hit the right design point. Instead of adding an option, think about what was forcing you to add that option.

[Filiprino]

I am tired of these half-baked "features" of SystemD.
I'll keep GRUB which is much more flexible and compatible. Not to mention its automation level. Thanks.

[dwagner]

Desktop systems. You know, Linux isn't used only on servers.

Sure, I currently run Linux for my desktop systems, too. And yet, I see no reason why I would want to reboot them more often than critical kernel bugs needing a patch.

[Grogan]

I don't like Grub2 autoconfig... in distros that use grub, after the initial install I set grub.cfg chattr +i and manually edit it. I'm not having package manager scripts calling grub-mkconfig and messing with that important file (including stanzas for other OS kernels) every time there are updates. I don't use the distro kernels anyway though and tend to disable those updates. I simplify it and rip out all the video probing junk etc. too and set text and console mode for the boot menu (I really don't need a high res menu, with tiny text at the top and initial scrolling delays).

So I have no objection to a more unified boot loader. I don't really like SystemD (conceptually) but this makes sense.

(I really prefer LILO but I'm done fighting the distros)

[starshipeleven]

Sure, I currently run Linux for my desktop systems, too. And yet, I see no reason why I would want to reboot them more often than critical kernel bugs needing a patch.

I turn off all things I don't need. I don't see why I should leave stuff running for no purpose. It's a waste and a danger.

Booting up is fast enough even without systemd that I can power up stuff on demand.

Only systems I'd be annoyed to shut down are FreeBSDs. God they take many minutes to boot, and they have like 2 services and network interfaces. Seriously what the fuck.

[starshipeleven]

You're not alone in that viewpoint.

Conversely, McIlroy has criticized modern Linux as having software bloat, remarking that, "adoring admirers have fed Linux goodies to a disheartening state of obesity."^[8] He contrasts this with the earlier approach taken at Bell Labs when developing and revising Research Unix:^[9]

Everything was small... and my heart sinks for Linux when I see the size of it. [...] The manual page, which really used to be a manual page, is now a small volume, with a thousand options... We used to sit around in the Unix Room saying, 'What can we throw out? Why is there this option?' It's often because there is some deficiency in the basic design — you didn't really hit the right design point. Instead of adding an option, think about what was forcing you to add that option.

When a project is used to run on many wildly different systems, and catering to many different usecases, then it's normal for it to have millions of different options.

Actually adjusting the basic design to accommodate all possible usecases will yeld a massively bloated base as you will have to account for all possibilities at once, that requires more time and resource and in some cases is not practical or even not possible.

Maybe their Research Unix is a beatiful piece of art where everything is lean and mean, as they are the sole developers and the sole ones deciding the usecases.
But Linux is on a much different scale.

[ssokolow]

When a project is used to run on many wildly different systems, and catering to many different usecases, then it's normal for it to have millions of different options.

Actually adjusting the basic design to accommodate all possible usecases will yeld a massively bloated base as you will have to account for all possibilities at once, that requires more time and resource and in some cases is not practical or even not possible.

Maybe their Research Unix is a beatiful piece of art where everything is lean and mean, as they are the sole developers and the sole ones deciding the usecases.
But Linux is on a much different scale.

I think the point was "Think of programs as functions. If you have too many arguments, you need to refactor. If splitting the function into lots of little functions is painful, maybe you need to rethink your programming system."

(Hence my observation that, if Research UNIX had continued, we'd probably be feeding something like JSON through shell pipelines today, with some minimum amount of support for structured data which preserves a distinction between the various primitive data types.)

[starshipeleven]

(Hence my observation that, if Research UNIX had continued, we'd probably be feeding something like JSON through shell pipelines today, with some minimum amount of support for structured data which preserves a distinction between the various primitive data types.)

I'm not sure I follow. Even if UNIX became the wet dream of Veteran Unix Admins like that, it would have still died the same death in the Unix Wars, because of the same (political/commercial) reasons, the fragmented ecosystem, the raging NIH and all that.
It wasn't a software issue. It died well before it could have become a software issue.

If UNIX actually started to become as big as Linux they would have to implement a similar option system, or fuck off and implode.