Announcement

Collapse
No announcement yet.

Lennart Poettering Takes To Battling Systemd Myths

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

  • #71
    Originally posted by ulenrich View Post
    8. I never saw a gui of systemd.
    There's a gui available, not mandatory, for handling starting/stopping/status of services.
    All opinions are my own not those of my employer if you know who they are.

    Comment


    • #72
      Originally posted by peppepz View Post
      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.
      Android is a good example of a Linux system which does not use udev. Busybox (with mdev) is another (albeit much more minor one), so it is not true that you MUST use udev.

      Originally posted by peppepz View Post
      especially considering that udev is constantly changing together with the kernel.
      It is not true that "udev is constantly changing together with the kernel". Your platform needs accept4() support and support for devtmpfs, but that's about it (any of the LTS kernels should be fine, some of the oldest ones might require some trivial backporting).

      Originally posted by peppepz View Post
      If you tie systemd to udev, you're effectively forcing everybody who uses the Linux kernel to use systemd.
      You inverted an implication there... systemd is tied to udev, not the other way around, so your argument does not work...

      Originally posted by peppepz View Post
      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.
      The concern is understandable. However, you should by now have been told repeatedly that 1) non-systemd support for udev will continue as long as non-systemd uses exist (and they do, Martin Pitt of Canonical/Ubuntu fame has commit access to systemd-ubev for crying out load) 2) if ever udev becomes dependent on systemd creating a fork would be trivial (don't look to eudev as an example, what they are doing is crazy and creating a lot more trouble/bugs/work for themselves than necessary).

      Originally posted by peppepz View Post
      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;
      That's news to me. Udev works just fine without systemd. We supported that for some time in Arch Linux without problems and we still support udev without systemd in our initramfs.

      Originally posted by peppepz View Post
      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.
      You do not have to build all of systemd to build udev. With the correct packaging script building only the necessary is trivial. That said, the simplest approach is probably to just flip the right ./configure switches to avoid building almost all of systemd.

      Originally posted by peppepz View Post
      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).
      If by 'many' you mean 'two', then you are correct: libcap and dbus. python (and everything else) is an optional dependency, which you would obviously disable in your setting.

      Originally posted by peppepz View Post
      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.
      We installed udev separately from systemd in Arch for a short period of time. It was just a matter of deleting some stuff and moving some stuff, I don't see what the fuss is about. If you prefer to have patch against the Makefile to make this even more trivial, that would be an obvious thing for your distro to carry if they don't wish to use systemd. The patch would be extremely trivial... Only reason I never wrote this (would take 5 minutes) is that my distro uses systemd so there is no point.

      Originally posted by peppepz View Post
      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".
      You are misreading this statement, and it has been explained repeatedly. They (we) are looking forward to the day when there is no longer a need for non-systemd udev. Meaning the day that everyone has seen the light and switched to systemd. As long as Debian/Ubuntu are not using systemd by default you have nothing to worry about.

      Originally posted by peppepz View Post
      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;
      Not true. See above.

      Originally posted by peppepz View Post
      (2) the udev maintainers are claiming that they are working to stop supporting udev without systemd in a somewhat unspecified future
      A gross misrepresentation, and absolutely not true.

      Comment


      • #73
        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.
        Sure, you can mount your harddrive on another system and use "journalctl -D /my_harddrive/var/log/journal". Or if you don't like that you can keep using (r)syslog(-ng) and you'll get your logs in /var/log/messages as before.

        Originally posted by cynyr View Post
        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.
        Systemd does not ship any .service files itself. Either the package will ship with one from upstream, or your distro probably does it for you (in Arch we have converted all our rc scripts to .service files, Fedora has done the same, and I'm pretty sure most of Debian has also been converted).

        Comment


        • #74
          Originally posted by Ericg View Post
          Cron: This is one that I don't really see the point of, but as long as you can still run your own cron daemon if you want to, i dont really care lol.
          Actually, that's probably the easiest to understand. At the most fundamental level, systemd is about starting other programs, whether it be on-demand, or part of system boot. And since that's all cron does too, why run two daemons that do much the same thing, when adding time-based triggers to systemd is simple enough and allows one of them to be dropped?

          Comment


          • #75
            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.
            Not out of the box, unfortunately, but several projects have patched it to obtain a standalone-build. For example, see:



            and the Makefile contained in this tarball.



            It would be much more convenient if it supported a --only-udev build, but my understanding from the LFS developers was that a) upstream weren't interested, and b) this standalone Makefile was actually easier than patching the systemd build files. Certainly, udev is one of those packages that doesn't benefit much from using an autotools build, since it's not intended to be portable, nor does it have a set of complex dependencies to check for.

            Comment


            • #76
              Originally posted by log0 View Post
              I think one of the sources of discontent with systemd might be this http://www.pappp.net/?p=969

              NOT UNIX way of doing things
              Some people get very hung up on the whole "UNIX way of doing things" argument. They need to remember that what they're talking about is nothing more than a traditional set of design principles - not holy law carved into stone tablets. And they're *good* design principles, no question - but they're not the only way of doing things, nor always the right way (as the article you link to notes). E.g storing data is flat text files is nice (and systemd does so for config files), but you'd be crazy to apply that principle to a multi-terabyte relational database. And "portability over efficiency" is only relevant for things where portability is useful, and where the benefits of portability are worth the loss of efficiency - it's a balancing act, not an inviolable mantra.

              Most importantly at all, those design principles are something you're supposed to think about, not just follow automatically without appreciation of what you're gaining (and losing) by doing so.

              Comment


              • #77
                Originally posted by tomegun View Post
                Android is a good example of a Linux system which does not use udev. Busybox (with mdev) is another (albeit much more minor one), so it is not true that you MUST use udev.
                In the world of ideas, it's possible to use Linux without udev. If you're a billionaire company such as Google, you can pay people to develop and maintain a udev replacement, and track the kernel development in order to implement the necessary changes every time they're required.

                Or, if you run Linux on an embedded board that is controlled through a serial port, you can be fine with mdev.

                But in reality, if what you use is the plain desktop Linux, then you need udev and libudev even for basic tasks such as starting the X server.

                It is not true that "udev is constantly changing together with the kernel".
                It gets updated when drivers get merged into / updated / removed from the kernel and this reflects into udev rules. Also libudev changes frequently and userspace needs the new APIs.

                The concern is understandable. However, you should by now have been told repeatedly that 1) non-systemd support for udev will continue as long as non-systemd uses exist (and they do, Martin Pitt of Canonical/Ubuntu fame has commit access to systemd-ubev for crying out load)
                Great news! Then certainly before long all those non-systemd developers that contribute to systemd-udev, and decide and shape its future, will give us a Makefile target for us to build and install udev separately from systemd. I'm looking forward to that moment, I hope it won't take long!

                if ever udev becomes dependent on systemd creating a fork would be trivial (don't look to eudev as an example, what they are doing is crazy and creating a lot more trouble/bugs/work for themselves than necessary).
                And yet currently it's the only alternative I'd have should udev be integrated into systemd when everybody "sees the light" (besides switching to Android or BusyBox as you've suggested above). So I hope they'll fix the problems they have; I'm certain that systemd-udev developers will help them and encourage them, in the spirit of open source collaboration.

                That's news to me. Udev works just fine without systemd. We supported that for some time in Arch Linux without problems and we still support udev without systemd in our initramfs.
                I never said that it does not work without systemd. I said that it does not build without systemd, which is a rather big change, while they said there would be no change, and that it changed the way it works in a way that broke my system, for example by changing the name and position of the main udev binary.

                You do not have to build all of systemd to build udev. With the correct packaging script building only the necessary is trivial. That said, the simplest approach is probably to just flip the right ./configure switches to avoid building almost all of systemd.
                Are there such switches? The last version I've built, 191, didn't have them, so I had to build the whole systemd and then guess what files I had to take out from it. I'm happy to know that now they're in place, I'll download and install 197 as soon as I have time.

                If by 'many' you mean 'two', then you are correct: libcap and dbus. python (and everything else) is an optional dependency, which you would obviously disable in your setting.
                Python was hardcoded in the makefiles the last time I built udev. I know because I was cross-compiling it, like I had always done when udev was a standalone package, and could no longer do it because of Python. Again, I'm happy to know that this changed, it will save me a lot of time.

                It was just a matter of deleting some stuff and moving some stuff, I don't see what the fuss is about. If you prefer to have patch against the Makefile to make this even more trivial, that would be an obvious thing for your distro to carry if they don't wish to use systemd. The patch would be extremely trivial... Only reason I never wrote this (would take 5 minutes) is that my distro uses systemd so there is no point.
                I'm no distribution maintainer. It takes me a lot more than 5 minutes to study, dissect and rebuild a package that is essential to boot and keep my system running, and repeat this operation every time a new systemd release is out. If such a patch would be "extremely trivial", then why a patch that does exactly this was never accepted upstream?

                You are misreading this statement, and it has been explained repeatedly. They (we) are looking forward to the day when there is no longer a need for non-systemd udev. Meaning the day that everyone has seen the light and switched to systemd.
                You're actually confirming my concerns. Especially with the last sentence, where you go as far as delineating a difference between light and dark.

                As long as Debian/Ubuntu are not using systemd by default you have nothing to worry about.
                When I said that people are planning "to stop supporting udev without systemd in a somewhat unspecified future", you told me that it was "a gross misrepresentation, and absolutely not true". But to me "as soon as Ubuntu starts shipping systemd by default" is the same as "in a somewhat unspecified future", because I don't work at Ubuntu and have completely no idea about their future plans.

                Comment


                • #78
                  Originally posted by peppepz View Post
                  Great news! Then certainly before long all those non-systemd developers that contribute to systemd-udev, and decide and shape its future, will give us a Makefile target for us to build and install udev separately from systemd. I'm looking forward to that moment, I hope it won't take long!
                  The discussion has been had, and the consensus seems to be that the buildsystem builds systemd. If you switch off 'everything' in ./configure, you will basically just have to compile systemd, journald and udevd. From a point of view of compile-time this is not a big issue, the only possible issue is if you for some reason absolutely don't want libdbus as a build-dep. In that case I suggest you look at the Makefile by LFS, they do this nicely.

                  Originally posted by peppepz View Post
                  And yet currently it's the only alternative I'd have should udev be integrated into systemd when everybody.
                  Nah, if that were to happen I'm sure someone who knows what they are doing would step up and make a proper and maintainable fork.

                  Originally posted by peppepz View Post
                  I never said that it does not work without systemd. I said that it does not build without systemd, which is a rather big change, while they said there would be no change, and that it changed the way it works in a way that broke my system, for example by changing the name and position of the main udev binary.
                  This is really not a big problem, just use a custom Makefile.

                  Originally posted by peppepz View Post
                  Are there such switches? The last version I've built, 191, didn't have them, so I had to build the whole systemd and then guess what files I had to take out from it. I'm happy to know that now they're in place, I'll download and install 197 as soon as I have time.
                  I believe the only things you cannot switch off are systemd, journald and udevd (i.e., systemd and its hard dependencies).

                  Originally posted by peppepz View Post
                  I'm no distribution maintainer. It takes me a lot more than 5 minutes to study, dissect and rebuild a package that is essential to boot and keep my system running, and repeat this operation every time a new systemd release is out. If such a patch would be "extremely trivial", then why a patch that does exactly this was never accepted upstream?
                  A patch to JUST build udev is simple. However, for it to make any sense upstream you should not make it a special-case, but allow to also build any other subset of the binaries, which becomes a mess (apparently, I didn't look closely at the patch, except to count the number of lines).

                  Originally posted by peppepz View Post
                  You're actually confirming my concerns. Especially with the last sentence, where you go as far as delineating a difference between light and dark.
                  Sorry, I should remember not to use humor/sarcasm on the internet. Maybe I should have said that we are all looking forward to the day where systemd has become a de-facto standard on linux, so we can focus our energy purely on systemd-systems.

                  Originally posted by peppepz View Post
                  When I said that people are planning "to stop supporting udev without systemd in a somewhat unspecified future", you told me that it was "a gross misrepresentation, and absolutely not true". But to me "as soon as Ubuntu starts shipping systemd by default" is the same as "in a somewhat unspecified future", because I don't work at Ubuntu and have completely no idea about their future plans.
                  I was merely saying that it would at least not happen as long as Ubuntu does not ship it. Didn't say it would then happen immediately, if at all.

                  I see systemd's trajectory something along the lines of udev's: it started out as something people 'would never allow on their systems', before it slowly became a de-facto standard to the point that most clients (e.g. X, or various init systems) now no longer care about the non-udev usecase. Once systemd has reached this same status, I suppose it would become relevant to discuss whether or not udev should also drop the non-systemd usecase. I believe this has more to do with what the ecosystem userspace apps does (when they start hard-depending on systemd) and less to do with what default init-systems distros use.

                  Comment


                  • #79
                    Originally posted by tomegun View Post
                    Systemd does not ship any .service files itself. Either the package will ship with one from upstream, or your distro probably does it for you (in Arch we have converted all our rc scripts to .service files, Fedora has done the same, and I'm pretty sure most of Debian has also been converted).
                    And as distros standardize on systemd, it'll become more and more common for upstream packages to ship their own service files, since they no longer need to worry about maintaining init scripts for a dozen different distros...

                    Comment


                    • #80
                      Systemd Is Monolithic
                      Your moms are Monolithic (to BSD users/devs)

                      Systemd Is About Speed
                      Cause systemd is so well designed and simple unlike BSD init. Systemd is simple, small and fast so those guys saying under wise should grow up or get lost.

                      Systemd Is Complex
                      Bullshit

                      Systemd Is Linux-only & Not Nice To BSDs
                      Good, BSDs hold back open-source projects. They always have to waste effort porting their software to pathetic BSDs. Much better forgetting about them and make software that takes advantage of superior Linux specific features. BSD users should just crawl into a hole and die cause their OS is 20 years behind and they do nothing but hold linux back.

                      Systemd Is Not Portable For No Reason
                      That's irrelavent, systemd was made for linux and LINUX ONLY. If BSD don't like it, they can go screw themselves. Just ask GNOME, XFCE and KDE devs about how annoying the existence of BSD is. They'll tell you that BSD only makes up 0.01% of the users of their software and that they could make their DEs better without BSD to worry about.

                      So those criticizing systemd shown just STFU

                      Seriously

                      Comment

                      Working...
                      X