Systemd Lands Support For "XBOOTLDR" Extended Boot Loader

[phoronix]

Phoronix: Systemd Lands Support For "XBOOTLDR" Extended Boot Loader

Systemd has just merged support for the "Extended Boot Loader" partition, a.k.a. "XBOOTLDR", that is their bootloader specification they hope will allow Linux distribution vendors to better support dual/multi-boot setups...

http://www.phoronix.com/scan.php?pag...Lands-XBOOTLDR

[pandesanctum]

Finally! I've been waiting for this XBOOTLDR support. Time to change to systemD. I hope it won't mess up.

[Shiba]

i have allergy to idiots

Must be difficult to live around yourself then.

that was crystal clear

People don't live in your small head, you should learn to explain yourself.

[pal666]

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.

i wonder what is percentage of clueless systemd haters who are unable to both read and spell. hello dummies, nobody was proposing to replace software (grub) with spec (subj)

[pal666]

What are you butthurt about? A plugin is an optional component working on the runtime of something else, it seems to fit quite well.

i have allergy to idiots. spec is for humans, plugin is for computers

I have no idea

that was crystal clear

[ssokolow]

I didn't claim your post was the red herring. It's his statement that, if referred to commandline is completely irrelevant red herring.

Applications has never and will never chose that stupidity because using a library or just duplicating the functionality is so much better for performance, or so much easier to implement if they don't need to bother about the outside world.

No amount of fapping over minimalist design or perfectly single-purpose pieces of a puzzle will change the fact that calling and starting up dozens of tiny applications for each kind of little task your main application must do is going to murder latency and performance.

So you're saying that Windows applications will never use COM, Linux desktop applications will prefer named pipes or loopback sockets over D-Bus, and MacOS apps will prefer the low-level Mach ports API over CFMessagePort and the like? Those are all successful examples of the OS providing higher-level APIs to applications and that's what this would be.

[Shiba]

why would you call bootloader spec "systemd plugin"? did systemd bite you when you was a child?

What are you butthurt about? A plugin is an optional component working on the runtime of something else, it seems to fit quite well.

are you seeing dead people too? what happens to your brain when your eyes hover over "is text based, very simple and suitable for a variety of firmware, architecture and image types" ?

I have no idea what you are ranting about.

no, i'm forbidding you to even read specs without systemd

Found another one who can't read quotes.

[starshipeleven]

It's not a red herring at all. It's exactly what McIlroy was getting at with his dismay at the size of manpages.

Using something JSON-like for the standard interchange format pipelines use is the shell equivalent to what Plan 9 did to continue perfecting the "everything is a file" principle.

I didn't claim your post was the red herring. It's his statement that, if referred to commandline is completely irrelevant red herring.

Applications has never and will never chose that stupidity because using a library or just duplicating the functionality is so much better for performance, or so much easier to implement if they don't need to bother about the outside world.

No amount of fapping over minimalist design or perfectly single-purpose pieces of a puzzle will change the fact that calling and starting up dozens of tiny applications for each kind of little task your main application must do is going to murder latency and performance.

[ssokolow]

That's quite frankly a red herring. Correct but irrelevant. Shell and scripts are not really what the payload application will use (as they run like crap), so making a whole infrastructure to unify that is a waste of resources, just implementing the same functions in the few applications that actually need it is going to be all you really need.

Payload applications even on Unix servers weren't using command line and parsing text output, they were making kernel or library calls.
All the code reuse was done by using libraries, not by making a frankenstein of applications playing ping-pong with text streams.

It's not a red herring at all. It's exactly what McIlroy was getting at with his dismay at the size of manpages.

Using something JSON-like for the standard interchange format pipelines use is the shell equivalent to what Plan 9 did to continue perfecting the "everything is a file" principle.

Conversely, one could argue that passing argc and argv to main() is an innovation similar to JSON-like shell pipelines, except that we take it for granted. Compare Windows where, for legacy reasons, a simple, unparsed command-line string is passed from parent to child when spawning a process and both quoting and parsing are implemented in libc.

I'm having trouble tracking down the specific post, but Raymond Chen wrote about that inability to guarantee that two programs will interpret command-line quoting the same way on his blog, The Old New Thing.

The legacy reason is that DOS's Program Segment Prefix structure, via which the command-line is passed, was intentionally made similar to CP/M's Zero Page for easy application porting (Source: Page 108 of The MS-DOS Encyclopedia by Microsoft Press) and then, when the allowable length of command lines was extended from 127 bytes to 32768 bytes, they kept the "serialize to string, then re-parse" design.

[starshipeleven]

The point is that GNU ls having --sort is at odds with the UNIX philosophy because the proper solution is to make shell pipelines richer so the sort command can sort the listing without having to cripple the flexibility of the output format.

That's quite frankly a red herring. Correct but irrelevant. Shell and scripts are not really what the payload application will use (as they run like crap), so making a whole infrastructure to unify that is a waste of resources, just implementing the same functions in the few applications that actually need it is going to be all you really need.

Payload applications even on Unix servers weren't using command line and parsing text output, they were making kernel or library calls.
All the code reuse was done by using libraries, not by making a frankenstein of applications playing ping-pong with text streams.