Announcement

Collapse
No announcement yet.

Systemd Starts Doing NTP/Timezones, Unified Cgroup Hierarchy

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

  • Systemd Starts Doing NTP/Timezones, Unified Cgroup Hierarchy

    Phoronix: Systemd Starts Doing NTP/Timezones, Unified Cgroup Hierarchy

    Systemd developers plan to release systemd 226 next week and with this release will come new features...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    I've got nothing against the project itself doing the job of almost everything... - but why not make it a *bit* more modular? Systemd just as a project with submodules that are released in 'one cycle' and developed close together - yet useable without each other?

    My 'dream' would be it being similar to the GNU Core Utils:
    Different programs that are definitely useable without each other - but still 'one'.

    Especially when it comes to networking one also needs to think of security and minimal layouts. I'm not really knowing much about systemd-networkd *exactly* works but it seems to be a DHCP server too - likely also other network-related stuff.
    What if there's a security-critical bug in it? Update ALL of systemd?

    Again, I don't know much about systemd but there come also problems and doubts with it all being 'one thing' and not 'one project'.


    Also non-binary logs should be defaults, at least have both activated as sane default... ;-)

    Comment


    • #3
      STOP criticizing !
      One day, there will be no more LINUX, ONLY Systemd, all praise LP !


      :")

      Comment


      • #4
        Well, as the pro-systemd people say, don't like it, don't use it or make you're own.

        I just make sure to use distro's without it and try to help support them if I can.

        Comment


        • #5
          Originally posted by larkey View Post
          I've got nothing against the project itself doing the job of almost everything... - but why not make it a *bit* more modular? Systemd just as a project with submodules that are released in 'one cycle' and developed close together - yet useable without each other?

          My 'dream' would be it being similar to the GNU Core Utils:
          Different programs that are definitely useable without each other - but still 'one'.

          Especially when it comes to networking one also needs to think of security and minimal layouts. I'm not really knowing much about systemd-networkd *exactly* works but it seems to be a DHCP server too - likely also other network-related stuff.
          What if there's a security-critical bug in it? Update ALL of systemd?

          Again, I don't know much about systemd but there come also problems and doubts with it all being 'one thing' and not 'one project'.


          Also non-binary logs should be defaults, at least have both activated as sane default... ;-)
          System-d is very modular and made of many different components, updated independently.

          However, to provide higher level system functionalities in order to create actual value for users (which should be the ultimate goal), some components will inevitably depend on others, and that's a good thing.
          Last edited by wagaf; 05 September 2015, 12:53 PM.

          Comment


          • #6
            Originally posted by wagaf View Post

            System-d is very modular and made of many different components, updated independently.

            However, to provide higher level system functionalities in order to create actual value for users (which should be the ultimate goal), some components will inevitably depend on others, and that's a good thing.

            That's for sure, but - at least to me - it seems to be maybe seperated sources but the end-product is saved as one. If you install systemd you have gummmiboot too. And a networkmanager. Aand a startup-analyzer. And whatnot. That ain't modular ;-)
            I think one could still try to make it more modular - ofc. there will be dependencies, but not that you need to have gummi/systemd-boot for a init-system, or other way around. It's more difficult to maintain for sure - but systemd ain't a small project, they should really well be able to do that.

            Comment


            • #7
              Originally posted by larkey View Post


              That's for sure, but - at least to me - it seems to be maybe seperated sources but the end-product is saved as one. If you install systemd you have gummmiboot too. And a networkmanager. Aand a startup-analyzer. And whatnot. That ain't modular ;-)
              I think one could still try to make it more modular - ofc. there will be dependencies, but not that you need to have gummi/systemd-boot for a init-system, or other way around. It's more difficult to maintain for sure - but systemd ain't a small project, they should really well be able to do that.
              You can do that right now, they're called compile time switches, and you can cut systemd down to almost just the service manager (it's not an init system even though it replaces the init system) itself

              Comment


              • #8
                Originally posted by larkey View Post


                That's for sure, but - at least to me - it seems to be maybe seperated sources but the end-product is saved as one. If you install systemd you have gummmiboot too. And a networkmanager. Aand a startup-analyzer. And whatnot. That ain't modular ;-)
                I think one could still try to make it more modular - ofc. there will be dependencies, but not that you need to have gummi/systemd-boot for a init-system, or other way around. It's more difficult to maintain for sure - but systemd ain't a small project, they should really well be able to do that.
                systemd comes as a whole on your system because your distribution's maintainers have decided to do so, not because this would be somehow inherent to systemd itself. systemd allows, as Luke_Wolf already posted, to specify which components you want and which not at compile time. As it seems, many distributions that deploy packages in binary form have chosen to go for the solution that gives their users the most options without having to recompile, read: compiling in everything and the kitchen sink. If you want to have it more modular you either have to convince the maintainers of your distribution to switch to such a scheme, or you have to switch distributions that have already such a scheme. Or, of course, do it yourself and compile systemd how you see fit.

                Comment


                • #9
                  And thinking forward, what features systemd may have for 3.0, a new re-implementation of the Linux kernel? They have already changed half of the ecosystem. So I can proudly say... Can I borrow your dvd of Fedora systemd?

                  Jokes apart, they have been doing some things that were needed long ago. My only 2 worries about the project are:
                  1. Project becomes so large that will be not maintainable or difficult for new devs to get involved in the code base.
                  2. Systemd development halts and due to dependency on it and it's module became a pain to go back or develop alternatives.

                  Comment


                  • #10
                    I know next to nothing about systemd, and I guess there's some truth to the for/against criticism. That said, I still like what systemd is doing, because apparently it *just works*, and might motivate some other developers to fix & modernize their outdated modular equivalents. Because lets be honest; lot's of things in Linux Land are fundamentally broken. And systemd seems to prove that. It's only the way it is implemented which is what ppl don't seem to like.

                    Progress - deal with it!

                    Comment

                    Working...
                    X