Announcement

Collapse
No announcement yet.

Systemd Lands Support For "XBOOTLDR" Extended Boot Loader

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Systemd Lands Support For "XBOOTLDR" Extended Boot Loader

    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
    replied
    Finally! I've been waiting for this XBOOTLDR support. Time to change to systemD. I hope it won't mess up.

    Leave a comment:


  • Shiba
    replied
    Originally posted by pal666 View Post
    i have allergy to idiots
    Must be difficult to live around yourself then.

    Originally posted by pal666 View Post
    that was crystal clear
    People don't live in your small head, you should learn to explain yourself.

    Leave a comment:


  • pal666
    replied
    Originally posted by Filiprino View Post
    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)

    Leave a comment:


  • pal666
    replied
    Originally posted by Shiba View Post
    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
    Originally posted by Shiba View Post
    I have no idea
    that was crystal clear

    Leave a comment:


  • ssokolow
    replied
    Originally posted by starshipeleven View Post
    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.

    Leave a comment:


  • Shiba
    replied
    Originally posted by pal666 View Post
    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.

    Originally posted by pal666 View Post
    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.

    Originally posted by pal666 View Post
    no, i'm forbidding you to even read specs without systemd
    Found another one who can't read quotes.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by ssokolow View Post
    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.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by starshipeleven View Post
    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.
    Last edited by ssokolow; 03-05-2019, 07:02 AM.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by ssokolow View Post
    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.

    Leave a comment:

Working...
X