Originally posted by Ericg
View Post
Announcement
Collapse
No announcement yet.
Lennart Poettering Takes To Battling Systemd Myths
Collapse
X
-
-
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.
Leave a comment:
-
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
Leave a 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
---
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; 28 January 2013, 03:06 PM.
Leave a comment:
-
Fair enough. Requote:
Originally posted by Ericg View PostThat 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.
Leave a 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
Originally posted by Ericg View PostHere'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.
Leave a comment:
-
Originally posted by funkSTAR View PostToo bad for you. Now STFU and accept your new master.
Leave a comment:
-
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
Leave a comment:
Leave a comment: