Announcement

Collapse
No announcement yet.

Lennart Poettering Takes To Battling Systemd Myths

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

  • #16
    Originally posted by boast View Post
    Then someone should pick up HAL again and not use udev if it bothers them.
    Nobody wants to go back to HAL.
    We were all happy with udev and it worked really nice.

    But now they're trying to force systemd to be a dependency of udev I heard.
    And they develop it in the same branch and stuff.

    Comment


    • #17
      Originally posted by uid313 View Post
      But now they're trying to force systemd to be a dependency of udev I heard.
      And they develop it in the same branch and stuff.
      Read literally any of my posts in this thread

      Comment


      • #18
        Originally posted by Ericg View Post
        He said he'd EVENTUALLY remove support for non-systemd. People always forget the "EVENTUALLY." Once people started freaking out he clarified that it was not a short-term goal by any means and would only happen once systemd was THE standard in the linux ecosystem and there WERE no competitors TO support.
        You are right in that the udev takeover did not mean immediate breakage for non-systemd systems, but you will also understand that maintainers of such systems do not like sitting on a ticking bomb at the mercy of a hostile developer, right?

        Comment


        • #19
          Originally posted by pingufunkybeat View Post
          You are right in that the udev takeover did not mean immediate breakage for non-systemd systems, but you will also understand that maintainers of such systems do not like sitting on a ticking bomb at the mercy of a hostile developer, right?
          Of course not, but Lennart also clarified afterwards that support for non-systemd+udev would only end once once there werent any real non-systemd systems left.

          Major distros who are using SysV?

          Gentoo, Slackware, Debian (Im leaving RHEL + its clones out of this because RHEL7 uses systemd)

          Major distros using Upstart?

          Ubuntu, (+derivatives, but basically Ubuntu.)

          Everyone else? systemd



          Debian wants to be able to swap out kernels so theyre stuck with sysV. If and when systemd removes non-systemd support from udev they'll probably switch to eudev.

          Gentoo lets you swap out components anyway. The users who want to use systemd will use mainline udev. The users who dont want systemd will use eudev.

          Slackware.... who the hell knows what those guys will do.

          Ubuntu...I really hope will adopt systemd but I'm not holding my breath. They're basically in the same boat as debian/gentoo. If they dont want to use systemd they'll use eudev, if they do want to use systemd then its a non-issue.

          Comment


          • #20
            Originally posted by Ericg View Post
            1) lennart's quote about eventually removing non-systemd support which got blown WAY out of proportion.
            Udev is officially promoted as an userspace part of the Linux kernel. Anybody using Linux, therefore, has to use udev, or needs to otherwise replace it with something equivalent, which is both (a) not supported and (b) nearly impossible to do while maintaining feature parity with the official udev implementation, especially considering that udev is constantly changing together with the kernel.

            If you tie systemd to udev, you're effectively forcing everybody who uses the Linux kernel to use systemd. Since there is a non-empty set of people who are interested in running Linux without running systemd (full disclosure: I'm one of them), it was no surprise that when udev and systemd were merged some voices were heard of people fearing that they would be pushed into using systemd.
            On that occasion udev and systemd developers reassured everybody thay "nothing would change", as it was merely a matter of "sharing code". It turned out that no, in fact things would change, as udev changed in an incompatible way when it was merged; another change was that now you have to build the full systemd package in order to obtain the udev binary (which also changes name into "systemd-udev", and gets moved to another location upon installation) and manually rip it out of the built package. Building the systemd package has many more requirements than udev, and some of them can't be cleanly cross-compiled (just one of them: Python). Not to mention the fact that installing udev changed from a matter of "configure / make / make install" into a much more complicated job. Patches to allow udev to be built separately from systemd were rejected.

            The blog post says that people are free not to use systemd because "free software isn't Mafia" ; well, the reader will decide what kind of behaviour it is to push people into using systemd by making their life noticeably harder if they don't.

            Anyway, after we discovered that, unlike was promised, things would indeed change for non-systemd users of udev, we finally got an official announcement by the systemd lead developer stating that they dislike having to support non-systemd users, and that they look forward to the day when they'll get rid of the "inconvenience".

            Now, it doesn't matter if his dreams of Linux domination will become true in 2013, in 2014 or in 2020. This statement is of extreme importance now, because:
            (1) the use of udev is for all practical purposes required in order to fully make use of the Linux kernel;
            (2) the udev maintainers are claiming that they are working to stop supporting udev without systemd in a somewhat unspecified future (and, as anyone can see, in the meantime they are already behaving as if non-systemd users of udev were second-class citizens, and are publicly stating it in order for it to be well known);
            from (1) and (2) we get that non-systemd users are friendly advised to either stop using the Linux kernel, or prepare themselves to develop and maintain an alternative to udev. Or, much more conveniently, switch to systemd.

            You can still build udev solo,
            No you can't. Try to do it and tell me your experience.

            you can still use it without systemd.
            You still can, but it's a pain in the ass, which it wasn't before the udev-systemd merger, and most importantly, it's a use case with an expiration date. Which is unacceptable.

            Please forgive me for this rant in a systemd thread, but hearing people say that non-systemd users of Linus exaggerate or are paranoid when they say that they're being pushed into using systemd, means having insult added to the injury to me.

            Comment


            • #21
              heavy obstacle is belief

              The really heavy obstacles in our world are beliefs:

              RANT! Someone is trying to turn Linux into Windows! They're trying to turn it into "Just Works (TM)", ...
              , this a long time Gentoo advocate at:
              https://forums.gentoo.org/viewtopic-...6.html#7229136

              Therfore true Linux/Unix is: It has to just NOT work!
              Otherwise it is a conspiracy ....

              Comment


              • #22
                Originally posted by Ericg View Post
                Debian wants to be able to swap out kernels so theyre stuck with sysV. If and when systemd removes non-systemd support from udev they'll probably switch to eudev.

                Gentoo lets you swap out components anyway. The users who want to use systemd will use mainline udev. The users who dont want systemd will use eudev.
                As a note Gentoo also supports other kernels like BSD. It also supports prefixes (mostly) and a number of other crazy setups. so add gentoo to debian in the first comment.

                Is there a supported way to build and install only udev? how about only systemd? only journal? On a gentoo system all three will be seperate compiles and installs. Having to always build all three will make it take longer to install, require more disk space, and generally be annoying.


                On to systemd questions; Can I write my own init file in plaintext with gvim for systemd? Is there documentation on how to build these. I like the well documented gentoo setup for this reason. It's very easy to write one if i want to, and I have in the past.

                Comment


                • #23
                  Originally posted by ulenrich View Post
                  The really heavy obstacles in our world are beliefs:

                  , this a long time Gentoo advocate at:
                  https://forums.gentoo.org/viewtopic-...6.html#7229136

                  Therfore true Linux/Unix is: It has to just NOT work!
                  Otherwise it is a conspiracy ....
                  May be you shouldn't rip that quote out of context, so that you can present the actual meaning, which is quite different from your conclusion:
                  Oddly enough the clueless noob who doesn't configure anything will be better off, because he/she won't have things like "config_eth0=..." sitting anywhere to become stale.

                  RANT! Someone is trying to turn Linux into Windows! They're trying to turn it into "Just Works (TM)", except when it doesn't, then abandon all hope, because we're removed, hidden, obscured, or obfuscated the knobs that allow you to make it work. Your choices are to be a complete clueless noob, or to become a near-developer - the self-educated hacker is out of luck.

                  Comment


                  • #24
                    Originally posted by cynyr View Post
                    Is there a supported way to build and install only udev? how about only systemd? only journal? On a gentoo system all three will be seperate compiles and installs. Having to always build all three will make it take longer to install, require more disk space, and generally be annoying.
                    Building stock systemd pulls in hard dependencies on udev, and journal and by default pulls in some of the things I mentioned in an earlier post, along with others. The only things you HAVE to build when you build systemd is systemd, udev and journal, all else is optional. (Hostname / timezone / hardware clock / cron / etc)

                    Journal depends on systemd so they cannot be decoupled.
                    Udev CAN be decoupled from systemd the only weird thing is you have to pull in all of the systemd sources to do it since they are in the same tree. So you get ALL of the systemd sources but when you actually compile it, you can tell it "I only want udev to be compiled" and when its done, you'll only have udev.*


                    Originally posted by cynyr View Post
                    On to systemd questions; Can I write my own init file in plaintext with gvim for systemd? Is there documentation on how to build these. I like the well documented gentoo setup for this reason. It's very easy to write one if i want to, and I have in the past.
                    I'm ASSUMING (Correct me if im wrong) when you say "init file" you mean the files that typically resided in /etc/init.d/ or gentoo equiv, correct? (Arch's equiv was /etc/rc.d/)

                    in the systemd world those are called ".service" files. And yes they are written in plaintext.

                    The defaults (distro package provided ones) are stored in /usr/lib/systemd/system/
                    If you want to modify or override anything provided by the distro then you place them /etc/systemd/systemctl and they will take priority over the ones in /usr/lib. Packages supply their own .service files, systemd does not provide them itself.

                    the Arch wiki has a great section where some non-default .service files are done for programs that dont have a native systemd service file: https://wiki.archlinux.org/index.php/Systemd/Services

                    Below this is a shortrun through an example .service file since I got the impression you hadnt looked at one before. if you have, sorry >_> but its a good read for anyone else who has not since they are so simple.

                    [Unit]
                    Description=Adsuck daemon
                    After=network.target

                    [Service]
                    Type=forking
                    ExecStart=/usr/sbin/adsuck -l 127.0.0.1 -c /var/adsuck -f /resolv.conf /hosts -r /filter
                    ExecStartPost=/bin/sh -c "echo 'nameserver 127.0.0.1' > /etc/resolv.conf"
                    ExecStop=/bin/kill $MAINPID
                    ExecStopPost=/bin/sh -c "cp /var/adsuck/resolv.conf /etc/resolv.conf"
                    ExecReload=/bin/kill -HUP $MAINPID ; /bin/kill -USR1 $MAINPID

                    [Install]
                    WantedBy=multi-user.target
                    Description: is what appears when someone looks at the daemon through systemctl (systemctl status adsuck)
                    After: Tells systemd to only start this after the network has been started (not necessarily established, but just the daemon responsible for the network has been successfully start
                    Type: tells systemd what to watch for. in the sysV world a process can be lost if it double-forks, thereby seperating it from its parent process. In the systemd world that isnt allowed. They can still fork as many times as they want, but systemd will always know where it is and what its process tree (including parent) looks like
                    ExecStart: tells systemd what command to run when the service file is passed "start" (systemctl start adsuck)
                    ExecStartPost: tells systemd what commands to run AFTER the service has been successfully started.
                    ExecStop: tells systemd what commands to run when the service is passed the "stop" command (systemctl stop adsuck)
                    ExecStopPost: tells systemd what commands to run when the service reports a clean exit. Eg: cleanup commands.
                    ExecReload: tells systemd what to do in the event the service wants to be stopped and then restarted immediately (systemctl restart adsuck)
                    WantedBy: tells systemd what level in the init tree this should go into. Systemd has a concept of runlevels, they jsut aren't called that.

                    single-user.target is runlevel 1 from sysV
                    mutli-user.target is runlevel 3 from sysV
                    graphical.target is runlevel 5 from sysV
                    reboot.target is runlevel 7(?) from sysV

                    Graphical.target pulls in anything linked against multi-user.target which in turn pulls in anything linked against single-user.target. The rule of thing is lowest level necessary. Adsuck is a network daemon and doesnt have or atleast does not require a GUI, therefore it goes against multi-user.target. But kdm or gdm DO require a gui so they go against graphical.target


                    And so ends what was probably my longest post on these forums, ever XD

                    Comment


                    • #25
                      Originally posted by Ericg View Post
                      Journal depends on systemd so they cannot be decoupled.
                      Udev CAN be decoupled from systemd the only weird thing is you have to pull in all of the systemd sources to do it since they are in the same tree. So you get ALL of the systemd sources but when you actually compile it, you can tell it "I only want udev to be compiled" and when its done, you'll only have udev.*
                      Is this supported such as "./configure --only-udev && make && make install"? If not it makes it a huge pain to get just one part.

                      Originally posted by Ericg View Post
                      I'm ASSUMING (Correct me if im wrong) when you say "init file" you mean the files that typically resided in /etc/init.d/ or gentoo equiv, correct? (Arch's equiv was /etc/rc.d/)
                      Yep that is what I mean.

                      Originally posted by Ericg View Post
                      The defaults (distro package provided ones) are stored in /usr/lib/systemd/system/
                      If you want to modify or override anything provided by the distro then you place them /etc/systemd/systemctl and they will take priority over the ones in /usr/lib. Packages supply their own .service files, systemd does not provide them itself.

                      the Arch wiki has a great section where some non-default .service files are done for programs that dont have a native systemd service file: https://wiki.archlinux.org/index.php/Systemd/Services

                      Below this is a shortrun through an example .service file since I got the impression you hadnt looked at one before. if you have, sorry >_> but its a good read for anyone else who has not since they are so simple.
                      Nope I haven't looked at them at all, all my computers boot great (mostly) right now, and mucking with semi-supported inits isn't all that interesting on live systems, and low priority for playing with in a VM.

                      One of the things I really like in gentoo is the pre_up and post_up functions for the networking init scripts. This allows things like setting up ssh tunnels when not on a particular wifi network, or setting link speeds before trying to get an IP address (to work around a busted network card I had at one point). It looks like execstartpost exists, and I'll assume that a execstartpre also does.

                      poking around arch's wiki for systemd I stumbled into another question, is there a way to read the log for a computer that I have a non-bootable system on? Normally I'd yank the HDD and mount the drive, and read /var/log/messages however I like. even if there was some minor corruption of that file it's likely something could still be read.

                      TBH I have a bit of knee jerk reaction to LPs stuff and have a tenancy to let it settle out for a while before I even try it out. For the most part it seems like LP lifted some of the things I like from openRC and added a few more interesting looking things the inherent directive or .path services for example. However a lot of the stuff sunning on my server seems like I would need to write .service files for at this point in time, like mediatomb and lighttpd. Though those may be provided by systemd itself.

                      Maybe one of these day I'll get around to playing with it in a VM.
                      Last edited by cynyr; 01-26-2013, 10:59 PM.

                      Comment


                      • #26
                        Originally posted by cynyr View Post
                        Is this supported such as "./configure --only-udev && make && make install"? If not it makes it a huge pain to get just one part.
                        Don't know the exact command for it off the top of my head, just remember that there IS a way.

                        Originally posted by cynyr View Post
                        Nope I haven't looked at them at all, all my computers boot great (mostly) right now, and mucking with semi-supported inits isn't all that interesting on live systems, and low priority for playing with in a VM.
                        Semi-supported is a bit of jump. Especially considering you can pass "init=/sbin/systemd" as a kernel parameter at boot and if you hate it / it breaks something you can get back to OpenRC by just removing that parameter. I run systemd on every linux install I have (whether via Fedora or through my home server & laptop--both running Arch) and everything works flawlessly.

                        Originally posted by cynyr View Post
                        One of the things I really like in gentoo is the pre_up and post_up functions for the networking init scripts. This allows things like setting up ssh tunnels when not on a particular wifi network, or setting link speeds before trying to get an IP address (to work around a busted network card I had at one point). It looks like execstartpost exists, and I'll assume that a execstartpre also does.
                        Most likely, the systemd documentation has a listing of every single configuration option .service files support, and they are adding more all the time.

                        Originally posted by cynyr View Post
                        poking around arch's wiki for systemd I stumbled into another question, is there a way to read the log for a computer that I have a non-bootable system on? Normally I'd yank the HDD and mount the drive, and read /var/log/messages however I like. even if there was some minor corruption of that file it's likely something could still be read.
                        Unsure, I know there's a way to export journal's binary logs into a plaintext format. But I am unsure (off the top of my head) if theres a way to have an external journal binary read a mounted system's journals. But as I've said before in this thread: journal doesnt take exclusive access to logs. I've got syslog-ng and journal both running on this laptop simultaneously. If for some reason journal's logs get screwed over, or they arent enough, I can just cd into /var/log and read the plaintext ones that syslog caught.

                        Logging in systemd goes process does a log event -> passes it to systemd -> systemd passes the information from the process (plus meta information from systemd, like the pid and user and stuff like that) to journal -> journal creates its own log -> systemd then repasses the log event to syslog (if its available, eg: installed and running) -> syslog does traditional log.

                        Originally posted by cynyr View Post
                        TBH I have a bit of knee jerk reaction to LPs stuff and have a tenancy to let it settle out for a while before I even try it out. For the most part it seems like LP lifted some of the things I like from openRC and added a few more interesting looking things the inherent directive or .path services for example. However a lot of the stuff sunning on my server seems like I would need to write .service files for at this point in time, like mediatomb and lighttpd. Though those may be provided by systemd itself.
                        I had a bit of a reaction to LP's stuff at first too but nothing's perfect. Pulse had its problems, but they got fixed. NetworkManager wasn't perfect (still missing Bridging support though I think thats coming in the next version, or atleast the groundwork is), and systemd once upon a time would fail to boot every once and awhile. Bugs were found. Bugs were fixed. Projects improved. I can very confidently say now that on all of my arch machines, with varying hardware, I have zero second-thoughts about installing systemd + Pulseaudio + Networkmanager + Avahi. They just ARE the standard to me now because I know they DO work.

                        Btw, out of curiosity I just installed lighttpd and mediatomb on this laptop from Arch's repos. lighttpd came with a .service file, Mediatomb did not. Just so ya know. And Arch typically doesnt add files to packages. Even during the initial move to systemd all additional .service files were kept in a seperate package, they weren't added into the specific applications files so that means lighttpd is shipping a .service file as part of upstream.

                        MOST programs DO ship .service files now because RHEL 7 (and by extension CentOS) will be systemd, Arch is systemd, Fedora is systemd.

                        Systemd can also parse init.d/rc.d scripts so theres that OR you could set it up where the .service file for your app actually just calls your custom written rc.d/init.d script. Make a script for mediatomb, drop it in /etc/init.d/ then just whip up a quick mediatomb.service file, drop it in /etc/systemd/system. have:

                        ExecStart=/etc/init.d/mediatomb start
                        ExecStop=/etc/init.d/mediatomb stop

                        this way you dont have to really mix and match init systems. a quick "systemctl enable mediatomb" will tell it to start on boot. and a "systemctl start mediatomb" will run ExecStart. Because its in /etc/systemd/system you dont have to worry about it ever being overwritten. The only problem would be if mediatomb did ever ship a default .service file, yours would automatically override it because they have the same name. So you might want to make it be "my-mediatomb.service" or something like that.

                        Comment


                        • #27
                          "systemd is linux only" "its not our fault bsd devs dont make it work on bsd!"

                          well, proves the point lol.

                          also systemd's biggest dep is indeed, dbus.

                          likewise, compared to shell scripts the flexibility goes down and the complexity goes up.. obviously, there isn't much you can do about that.

                          Comment


                          • #28
                            Originally posted by balouba View Post
                            likewise, compared to shell scripts the flexibility goes down and the complexity goes up.. obviously, there isn't much you can do about that.
                            Yeah, try doing the same what systemd does using shell scripts. Shell scripts are a complex nightmare. They're also slow as hell and don't even tell me about their "flexibility" - try using the same scripts on few distros.

                            Comment


                            • #29
                              Originally posted by Pawlerson View Post
                              Yeah, try doing the same what systemd does using shell scripts. Shell scripts are a complex nightmare. They're also slow as hell and don't even tell me about their "flexibility" - try using the same scripts on few distros.
                              Yes, while I've found init scripts to be conceptually easy to grasp, everything I've read about implementing and maintaining them hints at it being very complex and error-prone.

                              Comment


                              • #30
                                Originally posted by balouba View Post
                                "systemd is linux only" "its not our fault bsd devs dont make it work on bsd!"

                                well, proves the point lol.

                                also systemd's biggest dep is indeed, dbus.

                                likewise, compared to shell scripts the flexibility goes down and the complexity goes up.. obviously, there isn't much you can do about that.
                                This


                                SystemD is to shell scripts what the Windows registry is to plain text configs.

                                Comment

                                Working...
                                X