Announcement

Collapse
No announcement yet.

Systemd 198 Brings "Many Big Changes"

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

  • #46
    Apparently, you don't need it. His point is you can have systemd be as simple as init and log management, or you could have the whole she-bang.

    If you have only the base, then it's not bloated at all. The executable may be a little bigger than your typical init, but it also removes much of the duplicate code that you would find in init scripts and simplifies debugging the boot process (because it's only one process now, and then the service, rather than init, all the scripts, and the service itself).

    The rest may not be necessary, depending on your specific use-case. In most cases, distributions will make an appropriate choice about what components you will need, however if you have a very specific use-case, you may have to make some of those decisions for yourself (I imagine you chose not to use systemd on your gentoo system). If you are able and inclined, you can install another init or use some alternative to one of the many components that systemd replaces. Otherwise, the documentation is there for you to look at if you need it, and I'm sure someone would be willing to help if you asked on a relevant IRC channel or forum.

    I am required to look at documentation before doing any kind of work, sometimes that's just how it is. But I'm being paid for that work, so I don't mind learning a thing or two while I'm at it.

    I'm curious to know what distribution you're using for your thinclient servers.

    Comment


    • #47
      Originally posted by duby229 View Post
      Then what is the point? If you have to disable everything for it to simply be as functional, and still more complex, then why? Give me a good reason why I would need a more complex system that I have to disable the majority of to use...

      I just don't understand why I need it. Systemd is part of the problem. Eliminating it fixes part of the problem.

      EDIT: I have to step out of this conversation because now I'm just repeating myself.
      Seriously duby, I was really going with ya up until this post. "Disable everything to make it functional"? Are you one of the gentoo guys who goes through and disables every single option the kernel that you dont use / dont know what it is just so its as tiny as possible? Systemd is completly and fully functional whether you pass it every "--disable" flag you can at compile time, or whether you let it compile everything it does by default.

      The only POSSIBLE way your post makes sense is with this line: "If you have to disable everything for it to b e simply as functional and yet still more complex" Are you saying you want systemd to do everything sysV does and nothing else? If so, thats the problem here, lemme try an analogy.

      Did you ever have a manager that you had to report to that didn't give a fuck about his job or getting the job done? Just kind of let everyone do their own thing and if 1 or 2 people wanted to work, that was fine, good for them, but he really didnt care either way? Thats sysV. Then along comes the systemd style manager, he's the one that makes sure everyone is doing exactly what they are supposed to be doing, no one's goofing off or wasting time. Everyone kind of hates him because he's actually supervising and not just chilling, but at the sametime: Hey what a miracle, things are actually getting done now!

      Comment


      • #48
        I many other ways do I need to say it? It's bloatware... It doesnt -need- to do just about anything that it does. It is a workaround for a problem that is being addressed in a really bad manner. In addition it tries to be everything for everyone. Where is the line going to be drawn?

        What it needs to do is manage services. Anything more than that should be a different project and should be a service. This bullshit integration crap is nothing more than an excuse. It wouldnt need to be modular (which it does poorly, and which LP has publicly stated is temporary) if all these additional functionalities were split out and maintained separately under individual projects and were themselves managed as independent services.

        EDIT: When is systemd going to go fetch my email for me? When is it going to synchronize my phone for me? When is it going to -be- the firewall. When is it going to render opengl for the gpu drivers... etc, etc... Where is the line in the sand going to be drawn?
        Last edited by duby229; 03-08-2013, 06:56 PM.

        Comment


        • #49
          Alright, I'll run with that.

          It manages services. Services need to make logs, it manages the services' logs. Services need to communicate, it manages the services' communication. Services need to run a certain amount of time, with a limited amount of resources, it manages the time and resources that the services are allowed. Some services need to be isolated from other services, it manages that isolation. Some services need to know the system name and various other system details, it provides that information to those services. I could go on...

          There are, of course, certain things that you could argue that it doesn't need to do. You could argue that it doesn't need to manage desktop sessions, and I wouldn't be that inclined to disagree with you. I'm sure there are others, but that doesn't mean the whole thing is a heap.

          You could similarly argue that the whole Linux kernel is bloated and does a lot of things it doesn't need to or shouldn't. Maybe it should be a micro-kernel, with everything implemented in user-space? But that's not what we were given, and unless you or I learn to write programs which work better, more efficiently, and with less bloat than systemd and Linux, we're going to have to stick with what we've got, or use something else, or help solve bugs in what we do use. (Edit: This last sentence is part of my job too, except not with software)
          Last edited by Nobu; 03-08-2013, 07:11 PM.

          Comment


          • #50
            Originally posted by duby229 View Post
            I many other ways do I need to say it? It's bloatware... It doesnt -need- to do just about anything that it does. It is a workaround for a problem that is being addressed in a really bad manner. In addition it tries to be everything for everyone. Where is the line going to be drawn?

            What it needs to do is manage services. Anything more than that should be a different project and should be a service. This bullshit integration crap is nothing more than an excuse. It wouldnt need to be modular (which it does poorly, and which LP has publicly stated is temporary) if all these additional functionalities were split out and maintained separately under individual projects and were themselves managed as independent services.
            Systemd manages the lifetime of the machine. bottom line. Its the userspace mirror to the kernel.

            It handles poweron and poweroff and suspend (three major states of the machine.) Sysv did too. (Not suspend, but sysv was thought of long before 'sleeping' was a thing). Why should systemd do it? Because when you go to sleep you're effectively killing everything. All services need to be made sure they are starting and stopping appropriately on wake up / sleep respectively. Replaces acpid in that regard (Seriously, why did we need a tiiiiiiiiny little daemon just to handle lid open, lid close, and power button push?)

            It handles what xinetd used to do because sysV didn't want. Well, what did xinetd do? it started services...but wasn't that sysV's job? well yeah, but sysV didnt want to do it.

            It, more specifically the journal, handles logging. Why does it handle logging? Because the services themselves dont. Do you really want every service putting its own logs in different places, of varying quality? systemd starts the service, if the service is killed, or segfaults, systemd needs to know so it can restart it, or atleast flag the service for review.

            It handles resource management. Why does it handle resource management? Because under sysV you could get away from your parent process by double-forking. Systemd though has a very tight chain on processes and no amount of forking will ever get a process way from its parent process, or out of its cgroup. Could this be split off into another project? Yeah, it could. But systemd was the first one to go "Hmmm...we could do this..." so it does. The upside is since systemd does it, then resource limits can just be put into the services unit files. What does that do? It means the resource limitations of a service are right there with the services unit file, not off in some other directory. Its a "This goes with this" relationship.

            All of the things I listed above-- why does it do them? Easy: force uniformity FINALLY. If you want all the upsides and benefits of systemd, then the distros also have to go "Okay, yeah, all these random bullshit changes we've been making all these years...probably not necessary." If those things were in seperate projects, then the distro could just choose to not adopt that project or convince the developer to join their project and thereby strong arm him into making the changes for THEIR distro's style the new default for everyone else.

            Comment


            • #51
              Originally posted by duby229 View Post
              EDIT: When is systemd going to go fetch my email for me? When is it going to synchronize my phone for me? When is it going to -be- the firewall. When is it going to render opengl for the gpu drivers... etc, etc... Where is the line in the sand going to be drawn?
              Everything systemd does is related to service management in some way.

              When is it going to fetch your email for you? Never. But it will start the service that will.
              When will it sync your phone? Never, but it will start the service that will. When is it gonna be the firewall? Never, but it will start the service that will.
              When will it render the opengl for the gpu drivers? Never..its not hardware o.O

              Comment


              • #52
                Originally posted by Ericg View Post
                Everything systemd does is related to service management in some way.
                Well that's not quite true anymore with the addition of kernel-install and bootctl in 189 (of course those are separate from the systemd process itself). Both of those deal with booting the system though.

                There's this interesting snippet on /r/linux:

                Release 198 i stats:
                644 commits
                in 2 months
                by 49 authors
                from 7 distros (afaik, by doing author->distro)
                -phomes

                It's interesting how systemd-bootchart has evolved since it was merged. Before it was hosted separately it was only developed by Auke Kok. Now after being part of systemd for few months it has had commits from eight or so developers. I think that shows why it makes sense to bundle some of this software together even if it isn't absolutely necessary.

                Now I just can't wait for Arch Linux to complete their work on pushing systemd to initframs.

                Comment


                • #53
                  Originally posted by Ericg View Post
                  When is it gonna be the firewall? Never, but it will start the service that will.
                  Code:
                  systemctl start firewalld
                  systemctl enable firewalld

                  Comment


                  • #54
                    Originally posted by duby229 View Post
                    I many other ways do I need to say it? It's bloatware... It doesnt -need- to do just about anything that it does. It is a workaround for a problem that is being addressed in a really bad manner. In addition it tries to be everything for everyone. Where is the line going to be drawn?
                    People have explained to you all the benefits in great detail many times. I also did that.

                    Bad manner: explain. Seems again like your 'it is buggy claim'. According to Fedora Bugzilla, systemd is not buggy. According to Mageia Bugzilla, systemd is not buggy.

                    Back up your claims. Don't repeat things that have been refuted or replied to.

                    You keep repeatedly asking why people are defending systemd. Read the comments already! Jeez!

                    Comment

                    Working...
                    X