Announcement

Collapse
No announcement yet.

Linux Kernel Developers Fed Up With Ridiculous Bugs In Systemd

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

  • #71
    Originally posted by prodigy_ View Post
    O'rly?
    Ya'rly.

    Originally posted by prodigy_ View Post
    The saddest part is that I got more or less the same reply from three people and it's painfully obvious that none of you even tested your "solution".
    There may be something painfully obvious here, but it's not the thing you're claiming.

    Comment


    • #72
      Originally posted by Scias View Post
      Not only you can still use grep and all the other beloved tools you want with journalctl's output, but journalctl gives the ability to quickly filter specific fields without needing to spend a night on grep and regex patterns.
      No, you only have to spend a night figuring out the journalctl syntax.

      Comment


      • #73
        Originally posted by nslay View Post
        A tangent thought: /proc sure is great for scripting, but I'm still dumbfounded that native applications have to parse strings to get system information on Linux. Even the awful Windows API got it right here ... It's really awkward to see someone declare a character buffer or string, open a file, read the file into a buffer and then use <string> or <cstring> operations to get the information ... I mean, frankly, it's really stupid and the format of these files isn't always straightforward or even documented. Some of them are just space delimited numbers with no obvious meaning - I wouldn't even call that human-readable - at least a struct can have named members and comments.
        Nobody is forcing you to parse procfs in your application code - if you don't like it you can use (or write) a user space library eg.
        Python API for Linux /proc. Contribute to pmuller/procfs development by creating an account on GitHub.

        Comment


        • #74
          I like Gentoo, and I'm very happy to see that reason is winning and now systemd is on equal footing with OpenRC there. It probably won't ever be the default, yes ? but neither is OpenRC, because Gentoo doesn't have defaults I also have two Gentoo systems I maintain, both use systemd, one of them uses Btrfs with Snapper. So I'm happy that not all Gentoo developers are like ryao...

          Comment


          • #75
            Originally posted by prodigy_ View Post
            The saddest part is that I got more or less the same reply from three people and it's painfully obvious that none of you even tested your "solution".
            Just tested it: Works fine. Any more things to complain?

            Comment


            • #76
              Originally posted by schmidtbag View Post
              y'know what I'd really like to see? systemd get divided among separate packages. No need to fork the project, just simply split it. There should be a systemd-core, which contains only the necessities of an init system (basically the same thing as sysvinit, with a few other things here and there like parallelization) and then separate packages that include these other bloat features that some people may sincerely care about or want, but aren't vital to the infrastructure of the OS. This should be much easier to maintain and make everyone happy. I don't think anyone would dislike systemd if it were designed like this.
              well 2 facts first

              1.) systemd arch full install in x86_64 is less than 20mb, for arm is lot smaller. so i don't see size been a problem specially since any toolkit you use is prolly 20 times bigger
              2.) systemd only start PID1 by default(your definition of init system)and journald for logging everything else start and stop ondemand from c/c++/DBUS/etc API, so it doesnt use memory or CPU at all unless is really needed

              now the answer will be people won't like it for one simple reason, you break standarization and add an extra step to verify that all submodules are installed in runtime, just to save 10mb tops of hardrive space is just plain crazy

              Comment


              • #77
                Originally posted by TAXI View Post
                Just tested it: Works fine. Any more things to complain?
                Ditto. I have never touched the journal before, but it worked just fine.

                Comment


                • #78
                  Originally posted by mhogomchungu View Post
                  It comes from a unix philosophy[1] and Most if not all of them are well documented[2]

                  [1] http://en.wikipedia.org/wiki/Everything_is_a_file

                  [2] https://www.kernel.org/doc/Documenta...stems/proc.txt
                  That doesn't make it any less lame in my opinion. The stupid part is parsing strings for system information and that is not part of the Unix philosophy.

                  Comment


                  • #79
                    Originally posted by prodigy_ View Post
                    Disabling components at the level where init operates means you'll have your own distro to maintain. So you either accept the wholesale deal or switch to another distro that doesn't use systemd. Having alternatives is little comfort when you can't really use them because their role is hijacked by the init system.
                    That is the case with many core libraries. That is why we have distros in the first place, instead of just random collections of binaries that you can pick and choose from.

                    Comment


                    • #80
                      Originally posted by nslay View Post
                      The stupid part is parsing strings for system information and that is not part of the Unix philosophy.
                      It is:
                      Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.

                      Comment

                      Working...
                      X