Originally posted by ulenrich
View Post
Announcement
Collapse
No announcement yet.
Lennart Poettering Takes To Battling Systemd Myths
Collapse
X
-
Originally posted by peppepz View PostUdev 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.
Originally posted by peppepz View Postespecially considering that udev is constantly changing together with the kernel.
Originally posted by peppepz View PostIf you tie systemd to udev, you're effectively forcing everybody who uses the Linux kernel to use systemd.
Originally posted by peppepz View PostSince 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.
Originally posted by peppepz View PostOn 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;
Originally posted by peppepz View Postanother 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.
Originally posted by peppepz View PostBuilding the systemd package has many more requirements than udev, and some of them can't be cleanly cross-compiled (just one of them: Python).
Originally posted by peppepz View PostNot 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.
Originally posted by peppepz View PostAnyway, 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".
Originally posted by peppepz View PostNow, 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;
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
Comment
-
Originally posted by cynyr View Postpoking 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.
Originally posted by cynyr View PostHowever 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.
Comment
-
Originally posted by Ericg View PostCron: 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.
Comment
-
Originally posted by cynyr View PostIs this supported such as "./configure --only-udev && make && make install"? If not it makes it a huge pain to get just one part.
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
-
Originally posted by log0 View PostI think one of the sources of discontent with systemd might be this http://www.pappp.net/?p=969
NOT UNIX way of doing things
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
-
Originally posted by tomegun View PostAndroid 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.
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".
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)
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).
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.
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.
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.
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.
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.
Comment
-
Originally posted by peppepz View PostGreat 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!
Originally posted by peppepz View PostAnd yet currently it's the only alternative I'd have should udev be integrated into systemd when everybody.
Originally posted by peppepz View PostI 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.
Originally posted by peppepz View PostAre 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.
Originally posted by peppepz View PostI'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?
Originally posted by peppepz View PostYou're actually confirming my concerns. Especially with the last sentence, where you go as far as delineating a difference between light and dark.
Originally posted by peppepz View PostWhen 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 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
-
Originally posted by tomegun View PostSystemd 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
-
Systemd Is Monolithic
Systemd Is About Speed
Systemd Is Complex
Systemd Is Linux-only & Not Nice To BSDs
Systemd Is Not Portable For No Reason
So those criticizing systemd shown just STFU
Seriously
Comment
Comment