Announcement

Collapse
No announcement yet.

Lennart Poettering Takes To Battling Systemd Myths

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

  • #61
    Originally posted by danielbot View Post
    It should not be a goal at all. Having the udev maintainer and systemd maintainer be the same person is a recipe for disaster.
    It is not the goal of the Linux kernel community to abolish Udev. Systemd developers only can make some interesting offers in this regard.
    Untenable situation in my opinion. Obviously, the temptation to leverage udev to accelerate the demise of systemd competitors must be strong, and chances are, irresistable.
    How about then the last turmoil about udev and firmware?

    The result was doing some more directly in the kernel. Thus to minimize the complexity of Udev once more. Shouldn't it be the other way round if they conspire by utilizing Udev to promote Systemd:
    They should instead widen the use of Udev and its complexity just to make us more dependend ...

    Comment


    • #62
      Message to all the idiots

      Ok neckbeardos so Lennart busted all your myths. Too bad for you. Now STFU and accept your new master. Systemds adoption has reached critical mass by now and in a short while only a few sys'd refuseniks will remain and die out like the dinosaurs.

      Comment


      • #63
        Originally posted by ChrisXY View Post
        He didn't push pulseaudio down everyones throat. Ubuntu decided to be an early adopter and packaged a less than ideal config and so it became the quasi-standard way too early.

        Also, if someone creates multiple projects which end up being picked up for the default configuration of most bigger distributions because it works better than the alternatives chances are, you're not more intelligent than him.
        You've apparently never visited any major distro's bugzilla.....

        Comment


        • #64
          Originally posted by funkSTAR View Post
          Systemds adoption has reached critical mass by now
          Any numbers on that? As far as I know, Ubuntu is still by far the most used distro.

          Comment


          • #65
            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

            Comment


            • #66
              Originally posted by funkSTAR View Post
              Too bad for you. Now STFU and accept your new master.
              This is the new face of Linux development, folks.

              Comment


              • #67
                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
                im just gonna quote myself from the new systemd thread...

                Originally posted by Ericg View Post
                Here's the problem I have with people saying that. "systemd" isn't just 1 binary. Its about 20. When you say "systemd" now youre actually talking about a collection a binaries, a suite of binaries designed by 1 team with the purpose of providing low-level functionality for a linux-based system. It isn't one giant binary doing 20 things. Its 20 binaries with the expressed and explicit purpose of working together with the other binaries of the suite.

                Comment


                • #68
                  Originally posted by Ericg View Post
                  im just gonna quote myself from the new systemd thread...
                  and pingufunkybeat brings it to the point:
                  And this wouldn't be a problem if they weren't moving towards ONLY working together with other binaries of the same suite.

                  Comment


                  • #69
                    Fair enough. Requote:

                    Originally posted by Ericg View Post
                    That varies depending on what you're talking about. Journal and syslog work fine together. Systemd's timejobs and cron work fine together (only two I think of that provide direct competition). inetd was replaced by $service.socket files, which i think is fairly logical since its still process management. loginctl is the official successor to consolekit, so thats their fault for giving up on their project *shrugs* If you can think of more, go ahead and post them, more than happy to go through them all one by one and we can figure out EXACTLY what systemd "works with" vs has a "scorched earth" policy about.

                    Comment


                    • #70
                      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
                      From your link this list:
                      ---
                      1 Small is beautiful.
                      2 Make each program do one thing well.
                      3 Build a prototype as soon as possible.
                      4 Choose portability over efficiency.
                      5 Store data in flat text files.
                      6 Use software leverage to your advantage.
                      7 Use shell scripts to increase leverage and portability.
                      8 Avoid captive user interfaces.
                      9 Make every program a filter.
                      ---
                      1. systemd < sysv-init,cron,syslog,xinit,dbus
                      2. systemd has a little extra bin for each of above
                      4. portability was an unsolved issue in unix ancient times when every instance of a mainframe computer had its incompatibility in every aspect - unix philosophy was just an unsuccessful attempt of the big players to overcome their own problem. This issue is solved since decades. In times there are billions but not only a handful of computers the efficiency is most important!
                      5. Database theory is prior and more important: store every data once! This is not effectivly possible using text files. Despite this fact: Every text file is a binary in times of multi-cultural Unicode.
                      7. Systemd shell scripts are known as unit files in an extra simple language better fitting its purpose
                      8. I never saw a gui of systemd.
                      Last edited by ulenrich; 01-28-2013, 02:06 PM.

                      Comment


                      • #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.

                        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:

                                http://www.linuxfromscratch.org/lfs/...er06/udev.html

                                and the Makefile contained in this tarball.

                                http://anduin.linuxfromscratch.org/s...-197-2.tar.bz2

                                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

                                Working...
                                X