Announcement

Collapse
No announcement yet.

Systemd Lands Support For "XBOOTLDR" Extended Boot Loader

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

  • #61
    Originally posted by Shiba View Post
    I'll just call that a systemd plugin, so our views on modularity won't be triggered.
    why would you call bootloader spec "systemd plugin"? did systemd bite you when you was a child?
    Originally posted by Shiba View Post
    I just saw this only works with UEFI though, so for me the problem solved itself since I don't have a UEFI PC.
    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" ?

    Comment


    • #62
      Originally posted by rene View Post
      does systemd already come with a built-in Linux kernel replacement?
      well, it comes with whole distro, unless you want to build it manually

      Comment


      • #63
        Originally posted by ssokolow View Post
        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

        Comment


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

          Comment


          • #65
            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.

            Comment


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

              Comment


              • #67
                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)

                Comment


                • #68
                  Originally posted by dwagner View Post
                  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.

                  Comment


                  • #69
                    Originally posted by ssokolow View Post

                    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.

                    Comment


                    • #70
                      Originally posted by starshipeleven View Post
                      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.)
                      Last edited by ssokolow; 03-04-2019, 07:26 AM.

                      Comment

                      Working...
                      X