Announcement
Collapse
No announcement yet.
Systemd Lands Support For "XBOOTLDR" Extended Boot Loader
Collapse
X
-
Finally! I've been waiting for this XBOOTLDR support. Time to change to systemD. I hope it won't mess up.
-
Originally posted by Filiprino View PostI 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.
Leave a comment:
-
Originally posted by Shiba View PostWhat 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 Shiba View PostI have no idea
Leave a comment:
-
Originally posted by starshipeleven View PostI 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.
- 2 likes
Leave a comment:
-
Originally posted by pal666 View Postwhy would you call bootloader spec "systemd plugin"? did systemd bite you when you was a child?
Originally posted by pal666 View Postare 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" ?
Originally posted by pal666 View Postno, i'm forbidding you to even read specs without systemd
Leave a comment:
-
Originally posted by ssokolow View PostIt'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.
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.
- 1 like
Leave a comment:
-
Originally posted by starshipeleven View PostThat'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.
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; 05 March 2019, 07:02 AM.
- 1 like
Leave a comment:
-
Originally posted by ssokolow View PostThe 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.
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.
- 1 like
Leave a comment:
-
Originally posted by hotaru View Post
systemd-boot doesn't need new entries for kernel updates, though? I use it on my Arch Linux systems that get kernel updates at least once a week and I haven't had to touch the systemd-boot entries since I first set it up months ago.
Leave a comment:
Leave a comment: