Poettering: Why systemd?
systemd is also a big opportunity for Linux standardization. Since it standardizes many interfaces of the system that previously have been differing on every distribution, on every implementation, adopting it helps to work against the balkanization of the Linux interfaces. Choosing systemd means redefining more closely what the Linux platform is about. This improves the lifes of programmers, users and administrators alike." (Thanks to Paul Wise).
Posted Apr 29, 2011 13:17 UTC (Fri)
by AlexHudson (guest, #41828)
[Link] (28 responses)
Posted May 4, 2011 14:45 UTC (Wed)
by blahdong (guest, #74701)
[Link] (27 responses)
http://monolight.cc/2011/05/the-systemd-fallacy/
Posted May 4, 2011 14:55 UTC (Wed)
by rahulsundaram (subscriber, #21946)
[Link] (22 responses)
Posted May 4, 2011 18:21 UTC (Wed)
by jubal (subscriber, #67202)
[Link] (21 responses)
Would you make the minimal effort and look at the the site, you'd find that the author is not anonymous.
Would you actually read the article, and not only the first sentence, you'd realise that you just attacked a straw man.
Sadly, it seems you did neither.
Posted May 4, 2011 18:24 UTC (Wed)
by rahulsundaram (subscriber, #21946)
[Link] (20 responses)
Posted May 4, 2011 18:32 UTC (Wed)
by vriesk (guest, #71607)
[Link] (9 responses)
Posted May 4, 2011 19:09 UTC (Wed)
by rahulsundaram (subscriber, #21946)
[Link] (8 responses)
What kind of incoherent statement is that and where are you getting it from? I read it entirely and don't find any merit in any of the claims like I said. I have already highlighted the fact that systemd is of benefit to servers despite the author's claim. Even Lennart's sysadmin series covers a a number of them. If you want one more, systemd uses cgroups to keep track of all processes spawned by a service and can kill all of them when a service is stopped. The blog suggests directly using cgroups for this purpose and forgoing the useful integration altogether. That makes no sense to me.
Posted May 4, 2011 21:09 UTC (Wed)
by tgr1 (guest, #74710)
[Link] (7 responses)
thanks for your input. I'm the author of that post and I'm by no means anonymous - my name is right there on the site.
Generally, you have two (or more) tools to easily manage cgroups: mkdir and echo. Obviously, changes made that way can't be made permanent without shell scripts executed during the boot process. There is no reason not to use cgroups-related settings in SysV, OpenRC or other existing boot scripts. And you also have libcgroup utils.
However, cgroups support code integrated into PID 1 is the least of systemd's issues. It's not the only redundant feature, unfortunately.
Anyway, I welcome the point of view of a Fedora contributor. I do understand why these arguments seem to have no merit for you. Remember I explicitly stated that systemd may be useful to desktop and embedded vendors.
OTOH, I still fail to see any real benefits of systemd to servers. Nothing that can't be achieved with readily available dedicated tools - without bloating init.
Streamlining the boot process is a cool thing to do, but not at the cost of abandoning the simplicity of classic script-based boot processes. Unix and POSIX are not dogmas, nor are they sacred. Questioning and/or modifying these standards in an evolutionary process is one thing, but throwing away a huge part of them in one go is a bit worrisome to say the least.
Posted May 4, 2011 21:32 UTC (Wed)
by rahulsundaram (subscriber, #21946)
[Link] (6 responses)
Sure, cgroups has a bunch of disparate utilities to manage it. However arguing that it makes systemd integration redundant or bloat just doesn't make sense. When you start a service and want to kill all the processes, do you think mkdir and echo is easier than systemctl kill? Honestly? I guess my memories of managing rouge cgi scripts in hosted environments gives me a different perspective here.
My viewpoints here are not merely as a Fedora contributor but someone who started out as a system admin managing thousands of servers over several years professionally.
You argue on one hand that Red Hat is pushing this and simultaneously also want to argue that it is not useful for servers. For one, systemd was started as a part time project of Lennart with participation from Kay (Novell) and Red Hat has a lot more interest in the server than desktops or embedded systems to say the least.
It is not clear to me that you even tested systemd at all other than just reading blog posts and forming opinions. The question really is not whether on can do without systemd on the servers. That can certainly be done but is systemd making it easier or convenient for system admins to manage servers? Does it make features that makes it better?
Th current ad-hoc and distribution specific shell scripts that one has to put up with to manage booting and daemons are nowhere near simple or straight forward. The simplicity of the .desktop style unit files is a huge plus for systemd as evident from
https://lwn.net/Articles/401593/
Posted May 4, 2011 23:01 UTC (Wed)
by tgr1 (guest, #74710)
[Link] (5 responses)
Now, you're attacking a straw man. You know full well you don't kill cgroup-managed rogue CGI scripts with mkdir and echo - you do that with kill, ps, cat, awk, whatever you like. Killing all tasks within a cgroup is as easy as "xargs < /sys/fs/cgroups/cgroup1/tasks kill". Or you can get more specific and only kill those rogue CGIs but not httpd. You can kill them in parallel with xargs, etc. cgroups already track tasks for you if the original parent was moved to a cgroup at startup - even after the parent is gone. Honestly - you can do this conveniently without systemd.
We have yet to see what Red Hat does - as I already mentioned here, we have 2-3 years until the next major RHEL release. It's hard to speculate.
Regarding your question: I did test systemd.
The whole point is that to me (and a lot of Linux ops folks out there) systemd will ultimately make it harder, not easier to manage servers. Obviously, everybody's entitled to their own opinion - and seeing the recent popularity of systemd we may all be actively using it in a few years.
The "ad-hoc" (site-specific) and distribution-specific scripts are easy to read and, more importantly, flexible, the scripts being written in a simple imperative language. .service files may be _shorter_, but they're nowhere near shell scripts when it comes to functionality. That's one of my major points: if you need to change something deep in the startup/shutdown process, you don't have to modify systemd or daemon code and recompile. Plus you need explicit support from the daemons if you want them to be fully compatible with systemd. Of course, a lot of 3rd party vendors will probably be unwilling to support systemd, so you will end up with shell scripts anyway.
Posted May 4, 2011 23:20 UTC (Wed)
by rahulsundaram (subscriber, #21946)
[Link] (4 responses)
You can do this *more* conveniently with systemd *and* it is a compile time option. I am already using it and it well worth the integration as far as I am concerned.
"We have yet to see what Red Hat does - as I already mentioned here, we have 2-3 years until the next major RHEL release. It's hard to speculate."
No speculation necessary. Look at the entire history of major Fedora features sponsored by Red Hat and name one which hasn't landed up in the subsequent RHEL. Hint: There isn't one. I can wager a bit that it will land up EL 7 or even earlier.
"The whole point is that to me (and a lot of Linux ops folks out there) systemd will ultimately make it harder, not easier to manage servers"
This seems to be just handwaving. Who are those unnamed Linux ops out there and how is it making it harder for them, exactly?
"The "ad-hoc" (site-specific) and distribution-specific scripts are easy to read"
If you can read say a 100 lines (do remember to count all the include files) better than say 11 lines, sure.
"if you need to change something deep in the startup/shutdown process, you don't have to modify systemd or daemon code and recompile."
Fedora 15 uses systemd by default and noone has presented a single case where it is required to recompile anything. You are just making things up here.
"Plus you need explicit support from the daemons if you want them to be fully compatible with systemd"
No. A few daemons like rsyslog needs a tiny patch and they are all upstream already. Rest of them are already full compatible. systemd is compatible with sysvinit scripts and hence if third party software doesn't get modified, no big deal. Yeah, you might end up with some shell scripts in some cases. So what? This makes the whole contention that systemd is eliminating your precious shell scripts pretty pointless. You can't have it both ways.
Posted May 5, 2011 8:50 UTC (Thu)
by aniou (guest, #74708)
[Link] (2 responses)
Posted May 5, 2011 9:57 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link] (1 responses)
http://0pointer.de/blog/projects/the-new-configuration-fi...
If you are so against it anyway, feel free to use another init system.
Posted Feb 11, 2014 1:02 UTC (Tue)
by gvy (guest, #11981)
[Link]
> If you are so against it anyway, feel free to use another init system.
Posted May 11, 2011 19:52 UTC (Wed)
by nix (subscriber, #2304)
[Link]
Posted May 4, 2011 19:25 UTC (Wed)
by aniou (guest, #74708)
[Link] (9 responses)
From my POV systemd is created and maintained by developers who doesn't understood and doesn't care about sysadmins work. See following thread: http://lists.freedesktop.org/archives/systemd-devel/2011-... - "shell scripts used for glue things together. Bueh! It's unclean, it's impure, all daemons should works in one way, OUR WAY".
Posted May 4, 2011 19:43 UTC (Wed)
by rahulsundaram (subscriber, #21946)
[Link] (4 responses)
https://lwn.net/Articles/441431/
I have explicitly highlighted two items already. systemd services can call shell scripts just fine if one needs it. Anyone who has bothered to try it out in a system instead of just reading blog posts can figure this out.
ExecStart=/bin/myfavshellscript
Posted May 4, 2011 21:04 UTC (Wed)
by aniou (guest, #74708)
[Link] (3 responses)
Posted May 4, 2011 21:06 UTC (Wed)
by rahulsundaram (subscriber, #21946)
[Link] (2 responses)
Posted May 4, 2011 21:22 UTC (Wed)
by aniou (guest, #74708)
[Link] (1 responses)
It isn't nice.
Posted May 4, 2011 21:35 UTC (Wed)
by rahulsundaram (subscriber, #21946)
[Link]
Posted May 4, 2011 20:42 UTC (Wed)
by anselm (subscriber, #2796)
[Link] (3 responses)
I just read that thread and nobody seems to actually say that (or anything to that effect) there.
Posted May 4, 2011 21:05 UTC (Wed)
by aniou (guest, #74708)
[Link] (2 responses)
Posted May 4, 2011 21:31 UTC (Wed)
by anselm (subscriber, #2796)
[Link] (1 responses)
No. I think there is a considerable difference between what Lennart said in that posting (»In my opinion, a database server should be able to take care of its own version upgrades on databases and not push that into distribution-specific shell code«) and what you claim he said (»Shell scripts are stupid and I am right about everything«). In fact, I happen to think that Lennart has a point. Anyway, there are probably lots of things worth criticising about systemd that actually exist. Personally I would suggest that if you must diss Lennart and systemd it would be a much more profitable use of everybody's time to address these instead of inventing your own fictional ones.
Posted May 5, 2011 8:23 UTC (Thu)
by aniou (guest, #74708)
[Link]
Yes, of course, with simple installation, on single machine, witch typical scenarios it's doesn't matter - is databases created from script or by daemon. But uni*xes strength comes from diversity and - again - flexibility. Users and operators probably never deals with non-standard installs, but admins - yes.
Lennart's rants about separate /usr or /var ("Go to Slackware 1.0 then"), surprises with DoS via /run/user (and their "workaround", blah: http://lists.freedesktop.org/archives/systemd-devel/2011-...) clearly shows me that he isn't a sysadmin and don't care about different needs. But he has vision. This isn't enough for reliability and flexibility.
PS. that wasn't fictional case, I took it from official mailing-list.
Posted May 4, 2011 19:53 UTC (Wed)
by njs (subscriber, #40338)
[Link] (3 responses)
Posted May 4, 2011 21:19 UTC (Wed)
by tgr1 (guest, #74710)
[Link] (2 responses)
you seem to have misunderstood the post. I explained the ideas behind every single argument. Yet you're making some unsubstantiated claims yourself - let's go over them. Again: cgroups can be easily used without systemd or other PID 1 support - that's it. If the section on dependencies seems confused to you, I really have nothing to add other than a suggestion that you read up on System V init - and/or state what exactly is confused. automounter: did you ever see it fail on a live (server) system - not on a workstation you can just happily reboot? Well, I did. Red Hat and servers: obviously, having just released RHEL 6, they have 2-3 years until the next major release. I guess we have to wait and see what they decide. Nowhere did I claim RH is pushing systemd down anyone's throat.
Posted May 5, 2011 2:25 UTC (Thu)
by njs (subscriber, #40338)
[Link] (1 responses)
Yes, but they cannot be easily used to reliably manage all the various daemons etc. on your system without substantial integration effort to make sure that everything ends up in its own cgroup, new tools to manage those cgroups and match them up with the relevant daemons, etc. That's what systemd provides. You can't just say that some software is useless because the new features it provides are based on an already existing kernel API and other software could also potentially be written to provide those same features.
> If the section on dependencies seems confused to you
I understand System V init, but I can't understand what that paragraph in your blog post is saying. AFAICT, you don't like systemd because (1) you think dependencies are important, and (2) serial is just as good as parallel because only end-to-end speed matters. Systemd, of course, provides a much richer (and more reliable, etc.) way of managing dependencies than previous systems, and the whole point of parallel is that it improves end-to-end speed. So I can't reconcile your argument with how any of the stuff being talked about actually works.
> automounter: did you ever see it fail on a live (server) system
Sure, but I've seen tons of things fail on live systems. Hard drives, database servers, network drivers, you name it. There's definitely an interesting discussion to be had here, about the current reliability of the Linux autofs implementation and about its long term prospects for robustness (i.e., after Fedora and SuSE and everyone start pounding on it much more heavily and fixing bugs in the process). But just saying "I have seen this thing fail once and also I am a Serious Person who manages Serious Servers, not like you effete desktop users" is not an argument.
> Nowhere did I claim RH is pushing systemd down anyone's throat
You said that despite systemd's obvious brokenness, it would still be an "arduous fight" to keep it off our systems, because of "Red Hats financial backing".
Posted May 11, 2011 20:02 UTC (Wed)
by nix (subscriber, #2304)
[Link]
1) it failed because of a kernel bug causing the automounter to fail where mount(8) of that filesystem would succeed. Such bugs are not common, and the right solution is simply to fix it. Kernel bugs could have arbitrarily horrible effects: merely breaking the automounter seems like quite a minor one. And the rest of the system still works.
2) it failed because mount(8) of that filesystem failed (perhaps it is an infinitely-hanging NFS mount and you forgot to tell it to time out faster). This would have hung a conventional serial boot completely, leaving you out in the cold. With systemd, the rest of the system still works.
systemd seems like an improvement to me here.
Posted Apr 29, 2011 13:20 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Apr 29, 2011 14:02 UTC (Fri)
by welinder (guest, #4699)
[Link] (84 responses)
sysvinit does't handle swap? bah!
If you can't trust that the other guys are remotely fairly evaluated
Posted Apr 29, 2011 14:14 UTC (Fri)
by lkundrak (subscriber, #43452)
[Link]
Posted Apr 29, 2011 14:16 UTC (Fri)
by handock (guest, #73633)
[Link] (78 responses)
I have tested systemd for a few days and discovered that the (small) gain is not worth the pain. You end up constantly fighting against its design decisions.
The whole kitchen sink approach of systemd goes straight against the UNIX philosophy. (That's why I use minit as my init system. It's small, fast and reliable)
Posted Apr 29, 2011 15:08 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Apr 29, 2011 17:18 UTC (Fri)
by AndreE (guest, #60148)
[Link] (31 responses)
Or maybe they are referencing the UNIX haters handbook which describes the UNIX philosophy as "good enough".
Posted Apr 30, 2011 7:01 UTC (Sat)
by jcm (subscriber, #18262)
[Link] (30 responses)
Posted Apr 30, 2011 9:06 UTC (Sat)
by khim (subscriber, #9252)
[Link]
Sorry, but this is just soooo wrong. Unix design implies that init should do much more. It must manage all orphaned tasks - for they become childs of init if their parent dies. The fact that most init systems don't bother just means they are inherently broken. SystemD is not perfect, but it least it TRIES to do what it's SUPPOSED to do. Most other init systems just refuse to do the work.
Posted Apr 30, 2011 9:18 UTC (Sat)
by mpr22 (subscriber, #60784)
[Link]
Posted Apr 30, 2011 10:41 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (27 responses)
Correct?
Posted Apr 30, 2011 11:55 UTC (Sat)
by HelloWorld (guest, #56129)
[Link]
Posted Apr 30, 2011 18:42 UTC (Sat)
by jcm (subscriber, #18262)
[Link] (23 responses)
And is UNIX philosophy a trump card to me? Absolutely. It got us this far and making billions of dollars.
Jon.
Posted Apr 30, 2011 18:49 UTC (Sat)
by jcm (subscriber, #18262)
[Link] (18 responses)
There needs to be a slow train departing from a station somewhere around here. On board the train will be those who care more about "fit and polish" than throwing away well established protocol and tradition.
Jon.
Posted Apr 30, 2011 19:01 UTC (Sat)
by mpr22 (subscriber, #60784)
[Link]
Posted Apr 30, 2011 21:38 UTC (Sat)
by khim (subscriber, #9252)
[Link]
Funny, I think it's majority already. And their arrogance is justified. Where are "standard-compliant" technologies like CDE, Motif or STREAMS? Or how about ISO-standard document format? Gone. They are not exactly extinct, but nobody cares about them. No. They are dismissed when they are not used. C++ standard, for example, is not exactly small - but GCC tracks it religiously because users care about it. When nobody else cares... why the developers should care? Who will benefit if LibreOffice will ever implement ISO/IEC 29500-1:2008? If anything they should implement standard de-facto implemented by MS Office - and this quite different story. No problem. Switch to OpenBSD or FreeBSD. These guys are polishing everything to unimaginable degree. Not in a sense "make it actually useful", but in a sense "make everything right" (according to some kind of "right" - different in each case).
Posted May 2, 2011 6:32 UTC (Mon)
by Cato (guest, #7643)
[Link] (15 responses)
- CUPS won't start reliably due to Upstart, so I have to put a "cups restart" into /etc/rc.local to be sure. Oh the irony, the next-gen replacement for init is forcing me to put hacks in... http://ubuntuforums.org/showpost.php?p=9440474&postco...
- Kernel mode setting doesn't work at all on Intel GMA3100 for recovery mode login with framebuffer (though X does work). This is a very common GPU included in many motherboards (G33 chipset) and worked flawlessly in 8.04.
- keyboard mapping was completely messed up due to an old xmodmap config file being left behind
- there's a still undiagnosed problem where the system hangs (100% CPU, can't run any commands after many minutes)
This is a vanilla Ubuntu system with only standard packages like Firefox and Thunderbird installed, and has run 8.04 very reliably for three years now. Hardware was chosen to be commonly used and reliable, as it's used by an elderly relative who lives some way away.
I've spent a long time fixing these and other issues after the 8.04 upgrade, and I've been using Linux for 10+ years and Unix for much longer.
My point is that if desktop Linux is so badly "finished" in an LTS release that has had *one year* for serious bugs to be fixed, what hope is there for ordinary mortals to adopt it? This isn't an Ubuntu flame, as I'm not sure other distros are any better, unless perhaps they are much slower to adopt new technologies.
I know that Upstart/Systemd and (to some extent) kernel mode setting have advantages, but I'm not convinced that, without real investment in detailed regression testing across a wide range of hardware, Linux distros are really able to deliver this new technology to end users who are not Linux experts.
Posted May 2, 2011 8:27 UTC (Mon)
by jrn (subscriber, #64214)
[Link] (14 responses)
I don't know --- have you tried other distro (or other Ubuntu release) livecds? If you are used to Ubuntu LTS and prefer to stick with it, have you tried reporting bugs?
Kernel mode-setting in particular is something where you'll probably find a more up-to-date graphics stack (or one old enough to precede kernel mode-setting altogether) works better. Finding the right fixes to backport to an old graphics stack can be hard, unless there are active users with the same hardware reporting bugs.
Posted May 2, 2011 9:36 UTC (Mon)
by Cato (guest, #7643)
[Link] (13 responses)
Sounds like KMS probably shouldn't be in an LTS release at all... however, 18 months since its introduction in Ubuntu 9.10 should be enough to stabilise it on an older Intel GPU which has had open source drivers forever.
Of course I should do some bug reports but the sheer number of issues I've had, and seriousness of some of them, make it hard to spend the time logging bugs.
Posted May 2, 2011 14:23 UTC (Mon)
by bazsi (guest, #63084)
[Link] (12 responses)
And I'm not that reinstall if there's a problem kind of guy, but finding obsolete files scattered in .d directories to fix problems takes an immense amount of time.
When I realized the root cause (obsolete packages leaving .d files around), I started to feel they are not such a good idea after all, or at least dpkg/apt should support them better.
Posted May 2, 2011 15:08 UTC (Mon)
by nybble41 (subscriber, #55106)
[Link] (10 responses)
I agree that the package manager could support such files better. Perhaps there could be a separate directory for configuration files belonging to removed packages pending reinstallation or purge, where they wouldn't interfere with the rest of the system.
Posted May 2, 2011 21:05 UTC (Mon)
by bazsi (guest, #63084)
[Link] (9 responses)
And that's when the battle starts to find out why a function doesn't work.
Posted May 2, 2011 21:41 UTC (Mon)
by nybble41 (subscriber, #55106)
[Link] (7 responses)
$ dpkg -l | awk '/^rc /{print $2;}' > pkg-list
Posted May 3, 2011 6:43 UTC (Tue)
by Cato (guest, #7643)
[Link] (4 responses)
Obsolete config files are an issue, but only 1 of the 4 problems I encountered was due to an old config file - the rest are just new features not working properly.
Hence I'm more interested in discussion of why Upstart and KMS are not finished and working well over 18+ months after Ubuntu adopted them and 12 months after use in an LTS release.
Posted May 11, 2011 19:06 UTC (Wed)
by nix (subscriber, #2304)
[Link] (3 responses)
KMS won't be finished for ages. The job is just too huge.
Posted May 12, 2011 6:04 UTC (Thu)
by Cato (guest, #7643)
[Link] (2 responses)
Apart from the technical elegance, why did the Linux community decide to make the kernel and even typical recovery boot processes dependent on the GPU, which as you say is very complex, fast changing and under-documented?
I have still not managed to get recovery boot working on Lucid, all thanks to some combination of KMS and framebuffer devices - I've tried many boot strings and made some progress, but I gave up after many hours. On this Intel GMA3100 hardware, which should be well supported, KMS has made things much worse than the previous Ubuntu LTS.
Posted May 12, 2011 10:48 UTC (Thu)
by nix (subscriber, #2304)
[Link] (1 responses)
There was no choice about making the kernel boot process 'dependent on the GPU', if by that you mean using KMS to display the boot process, because the time is coming (and it is not terribly far away) when text-mode support will disappear from these cards. So it's graphics or nothing, and the only non-conflicting way for the kernel and X to display stuff on the screen is KMS, at least if you want to retain any acceleration at all in X.
There was a choice: go KMS, or have almost no improvements in X graphics for the foreseeable future. (Actually it would probably go backwards because the userspace modesetting drivers are not pleasant to maintain.)
Posted May 18, 2011 13:26 UTC (Wed)
by Cato (guest, #7643)
[Link]
The 10.04 LTS upgrade has been a disaster, the person using has said she wants to stop using Ubuntu as a result. Hopefully going to a more recent Ubuntu (maybe 10.10) will fix the Intel KMS problems.
Can anyone recommend a good Ubuntu or similar distro version (Mint, Mepis, Debian, with reasonably quick security updates) that has KMS working well on Intel GMA3100 or similar, without random freezes? I don't want to try getting a newer Xorg and kernel working on 10.04, as the idea of this PC is to be low maintenance and reliable for the next 2-3 years.
Posted May 3, 2011 15:07 UTC (Tue)
by jzbiciak (guest, #5246)
[Link] (1 responses)
Posted May 5, 2011 16:32 UTC (Thu)
by Thalience (subscriber, #4217)
[Link]
Posted May 2, 2011 22:16 UTC (Mon)
by Tobu (subscriber, #24111)
[Link]
Posted May 2, 2011 16:12 UTC (Mon)
by Cato (guest, #7643)
[Link]
Posted Apr 30, 2011 20:22 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
The only popular Unix flavors: iOS/OSX and Android do not give a **** about the Unix philosophy. So yeah, I'll take sound and elegant solutions versus nebulous 'Unix philosophy' any time of day.
Besides, the exact same debate was previously held on: D-BUS, hal, udev and package management systems (what?!? how can we surrender our ability to move files around to the package manager!?!?!?! ah, these were the days).
You might also consider that YOU are in the minority which tries to retard the progress.
Posted May 1, 2011 4:24 UTC (Sun)
by clint (subscriber, #7076)
[Link] (1 responses)
And if I care about having control over a working system, I won't run broken crap like that.
Posted May 1, 2011 5:38 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link]
And Android runtime by itself is quite configurable and flexible.
Posted May 1, 2011 1:02 UTC (Sun)
by HelloWorld (guest, #56129)
[Link]
> UNIX philosophy is not wrong just because it's old
> A happy compromise is to extend what's there and re-invent only when really, truly necessary.
Posted May 8, 2011 6:34 UTC (Sun)
by rlarkin (guest, #74787)
[Link] (1 responses)
From all these talks I figured out that the Unix philosophy is:
1) Everything was already invented and perfect 40 years ago.
2) Everything else must be implemented using shell scripts and pipes.
Posted May 8, 2011 9:29 UTC (Sun)
by anselm (subscriber, #2796)
[Link]
System V init may have been conceptually simple at some point, but in 2011 it is basically a complicated artefact held together by Band-Aid and string. Many Linux distributions have seen the need to pile stuff on top of it (insserv, chkconfig, update-rc.d,
) in order to make it address their requirements. It may be a good thing that they can customise it, but one might be forgiven for thinking that if it apparently needs to be customised through non-standard, distribution-specific tools to be usable, there may be problems in the underlying concept.
Systemd is still quite new and any predictions of what it will or will not be able do once it is »done« are very probably premature. It does promise a way of organising system startup (which System V init does, too) and system operation (which System V init doesn't) in a unified fashion without actually excluding shell scripts and pipes, so it should at least be given the benefit of doubt until it has proved itself.
The funny thing is, when System V init was new, many proponents of the »traditional« method (one large shell script initialised everything) dissed it for being an overengineered, unnecessary mess, and now suddenly it is the embodiment of the »Unix philosophy«?
Posted Apr 29, 2011 19:26 UTC (Fri)
by intgr (subscriber, #39733)
[Link]
> I have tested systemd for a few days and discovered that the (small) gain is not
Making those statements, with no explanation or examples of the pain and (bad?) design decisions is unlikely to convince many people. What does minit do better?
As someone who has written init scripts for RHEL SysV, Debian SysV (start-stop-daemon), Gentoo OpenRC, Ubuntu Upstart and Arch Linux SysV, I have to say that systemd is the best documented AND behaves the most predictably. I haven't tried minit, but I find those qualities much more important than minimalism.
Posted Apr 29, 2011 20:14 UTC (Fri)
by mezcalero (subscriber, #45103)
[Link] (25 responses)
Posted Apr 29, 2011 20:51 UTC (Fri)
by handock (guest, #73633)
[Link] (24 responses)
Everything is dumped into dmesg by default. Why?
The kexec path is hardcoded to /sbin/kexec while it lives under /usr/sbin/ on my system.
Just looking at the huge list when you run "mount" gives me the craps.
There was no sane way to start fcron reliable on my system.
Posted Apr 29, 2011 21:46 UTC (Fri)
by intgr (subscriber, #39733)
[Link] (2 responses)
It's only dumped into dmesg until your syslog daemon starts and takes over /dev/log. Because early-boot messages ARE important system events. Without this feature, you would lose all messages before the syslog daemon starts.
> The kexec path is hardcoded to /sbin/kexec while it lives under /usr/sbin/ on my system.
Correct me if I'm wrong, but I think kexec is invoked after all file systems other than root have been unmounted. Since /usr can potentially be a separate file system, kexec should not be there.
> There was no sane way to start fcron reliable on my system.
systemd launches daemons from a cleaner environment than a typical SysV script (doesn't leak user's environment to the daemon). Some daemons are known to crash when HOME is unset. You could try adding Environment=HOME=/var/empty
Posted Apr 30, 2011 5:24 UTC (Sat)
by Duncan (guest, #6647)
[Link] (1 responses)
[Not a systemd user and likely won't be for awhile, as I'm quite happy on Gentoo and openrc. But I like to stay informed, and if systemd becomes a standard as intended, who knows what might happen 2-7 years down the line?]
I believe the point is the /hardcoded/ bit. Just because /usr /can/ potentially be on a separate fs doesn't mean it /is/, and hardcoding /any/ locations, other than perhaps the location of an initial config file due to the chicken/egg problem of needing the config to find it, is something I'd consider a misfeature.
Now if that's mistaken and the location is only the necessarily and reasonably hardcoded default, with a documented config option to place it elsewhere...
Meanwhile, one thing I've not seen in any of the reviews, etc, yet, possibly because I've frankly not been interested enough to go read the main articles referred to in coverage like this, is how well systemd might operate as a secondary initsys, responsible for a few daemons that ship with decent systemd init configs by default, but not for initialization of the entire system. Does it have a mode that allows that, without the admin having to worry about it unpredictably trying to takeover something it wasn't configured to handle on that system and without being more trouble than it's worth to setup?
Because if it handles that well, I could see it gradually taking over over on a system or distribution, one daemon at a time over a period of years, until there's little reason not to simply dump the previous system and let systemd handle it all. But if it can't handle something like that and switching to it has to be a flag-day event... it's certainly much less likely to get any reasonable consideration here for quite some time.
Posted May 2, 2011 21:03 UTC (Mon)
by vonbrand (subscriber, #4458)
[Link]
As it stands here today (Fedora to become 15 on x86_64), systemd will fall back on sysvinit's scripts if there isn't native configuration (there are still a few of those left; reengineering a sane init script into a systemd unit is an half hour of work, tops), and running sysvinit's scripts will in turn fall forward to run systemd's daemon control when required. There are some services that still use the old ways, and that works fine. Some fingers are still used to run the scripts for daemon control, also works fine. There is no "flag day" involved.
Posted Apr 30, 2011 1:17 UTC (Sat)
by mezcalero (subscriber, #45103)
[Link] (14 responses)
Do you find it better if they go to /dev/null like they used to go?
Note that those messages go to kmsg only as long as no full rsyslog is up, i.e. we provide logging already during the first moments of early boot. Which is a fantastic feature, which has not been available anywhere before. Since rsyslog as first thing after boot dumps kmsg to disk you end up with a complete set of log files from the earliest moment of bootup. Starting with F16 you will be able to use "dmesk -k" btw to limit the output to kernel generated messages, to get a more traditional dmesg output. You can even make "dmesg" an alias for this, in case you say that early boot msgs are evil shit and you never want to know details about stuff that went wrong during early boot.
> The kexec path is hardcoded to /sbin/kexec while it lives under /usr/sbin/ on my system.
Then your OS is broken. /usr/bin is not available during late shutdown, hence placing kexec there is just wrong.
> Just looking at the huge list when you run "mount" gives me the craps.
Mount points are just mount points. If you really have an issue with kernel file systems, then ffs complain to the kernel folks, not us. We just make them available to userspace.
> There was no sane way to start fcron reliable on my system.
Uh? It's a service like any other. Just place a tiny .service file or sysv script for it in the right dir, and it will just work. If it doesn't file a bug. If it just hangs, file a bug against fcron.
Really, try harder.
Posted Apr 30, 2011 6:15 UTC (Sat)
by handock (guest, #73633)
[Link] (6 responses)
They didn't.
>> The kexec path is hardcoded to /sbin/kexec while it lives under /usr/sbin/ on my system.
>Then your OS is broken. /usr/bin is not available during late shutdown, hence placing kexec there is just wrong.
No. It just highlights the problem with systemd. In any other init system
The other possibility (and apparently your favorite) is to force every Linux
> Mount points are just mount points. If you really have an issue with kernel file systems, then ffs complain to the kernel folks, not us. We just make them available to userspace.
No. Nobody forces you to mount every available kernel fs by default.
> Uh? It's a service like any other. Just place a tiny .service file or sysv script for it in the right dir, and it will just work. If it doesn't file a bug. If it just hangs, file a bug against fcron.
Just guess what I did? I've tried many different tiny .service files and they
Posted Apr 30, 2011 10:42 UTC (Sat)
by khim (subscriber, #9252)
[Link] (1 responses)
Problem? It's a feature! Right - and this is the problem. Yup. But think about it: why systemd refuses to support /var/run? Is it really impossible to do? No - it's not that hard. But it does not give you any advantages and creates few problems (as was discussed before). SystemD does. This means developers of third-party software can finally stop thinking about cases where someone decided to not mount something. Balance between configurability (which allows you to solve real problems) and uniformity (which allows you to not lose much time stydying pointless differences) is important - and right now Linux is skewed heavility to the "too much configurability" side. Systemd is trying to fix that balance, but as usual people are affected differently: sysadmins usually favor configurability (since it makes it possible to patch problems when needed), IVSs favor uniformity (since it makes development and testing easier). So far I see curses from sysadmins and praises from developers so it's obvious that systemd does things right: Linux has more then enough sysadmins and way to few ISVs today.
Posted Apr 30, 2011 19:47 UTC (Sat)
by drag (guest, #31333)
[Link]
Personally I'd rather have something that reliably works only one way versus something that doesn't work in a bunch of different ways. The problem with a lot of this 'Linux scripting/mentality mentality - oh I can fix it' is that you end up with a shitload of choices that are broken in different manners.
You have to choose which parts of your system you would like broken in order to find a combination of non-broken functionality that will specifically suite your purposes.
It's like:
Welcome to Linux! The UBER OS.
Congrats, you chose A. Lets hope you don't buy a new USB drive and expect to use it without su'ng to root!
Choice 2:
Congrats! You choose B. I see that your probably not using a laptop, good thing too because now all your power management stuff is broken since you chose A in the first question! Yay!
Posted Apr 30, 2011 13:22 UTC (Sat)
by mezcalero (subscriber, #45103)
[Link] (2 responses)
Ah, right. So your distro is spawning a /dev/log syslog as one of the first things at boot? Can you point me to which one that is?
> No. It just highlights the problem with systemd. In any other init system
Yeah, thing is we don't really support broken setups with systemd. Sorry for that. Also, we already made clear that we want to standardize behaviour of Linux, and that includes that we ensure that people fix their broken OSes and for example move kexec to away from a broken path to the right path.
> (And BTW calling external
That refers to the fact that we have "systemctl kexec" and thelike.
> The other possibility (and apparently your favorite) is to force every Linux
Hmm, I am not forcing anybody. You can adopt systemd if you wish. I make an offer with systemd, you don't have to take it, it's free software. Note however, that *all* big distros have commited to the /var/run to /run move, including Ubuntu, regardless if they want to do systemd or not. So, complain to them, too, not just to me. Ever thought that maybe if everybody loves /run this might be the right thing and you are just misinformed?
> No. Nobody forces you to mount every available kernel fs by default.
No, but they aren't any useful if they aren't mounted. Note btw, that we actually don't mount them all, to optimize things. We just place automount points in /proc/sys/fs/binfmt_misc and similar places, which are backed by the real fs only on demand, causing the loading of the backing kmod only when needed.
Posted Apr 30, 2011 13:24 UTC (Sat)
by mezcalero (subscriber, #45103)
[Link] (1 responses)
> Hmm, I am not forcing anybody. You can adopt systemd if you wish. I make an offer with systemd, you don't have to take it, it's free software. Note however, that *all* big distros have commited to the /var/run to /run move, including Ubuntu, regardless if they want to do systemd or not. So, complain to them, too, not just to me. Ever thought that maybe if everybody loves /run this might be the right thing and you are just misinformed?
Oh, and BTW. If your really hate those mount points so much, you can remove them. Just mask their units by linking them to /dev/null in /etc/systemd/system/.
We just ship good defaults, that's all.
Posted May 11, 2011 18:36 UTC (Wed)
by nix (subscriber, #2304)
[Link]
;}
Posted Apr 30, 2011 13:56 UTC (Sat)
by intgr (subscriber, #39733)
[Link]
And with systemd you can make a symlink from /sbin/kexec to /usr/sbin/kexec, if you really insist.
Editing shell scripts never was the *right* solution to most problems -- when the upstream script changes and overwrites your changes, you're back in square one again. Generally by the time this happens, you've long ago forgotten about your duct tape solution, so you have to solve it again.
Posted Apr 30, 2011 12:36 UTC (Sat)
by mp (subscriber, #5615)
[Link] (3 responses)
> Then your OS is broken. /usr/bin is not available during late shutdown, hence placing kexec there is just wrong.
But is it really? Separate /usr/ is broken anyway.
Posted Apr 30, 2011 23:29 UTC (Sat)
by HenrikH (subscriber, #31152)
[Link] (2 responses)
Posted May 1, 2011 10:52 UTC (Sun)
by mp (subscriber, #5615)
[Link] (1 responses)
Posted May 2, 2011 21:20 UTC (Mon)
by HenrikH (subscriber, #31152)
[Link]
Posted May 2, 2011 7:24 UTC (Mon)
by ebiederm (subscriber, #35028)
[Link] (2 responses)
> Then your OS is broken. /usr/bin is not available during late shutdown, hence placing kexec there is just wrong.
Wow. If this is true than systemd has a bug here. The only reason kexec -e is called the distribution shutdown scripts is because the patch to /sbin/reboot never made it into sysvinit. All kexec -e really does is a single system call.
Systemd has incorrect hard coded paths to avoid a single system call???
Wow.
Posted May 2, 2011 9:42 UTC (Mon)
by michich (guest, #17902)
[Link]
Posted May 2, 2011 15:55 UTC (Mon)
by mezcalero (subscriber, #45103)
[Link]
Posted May 2, 2011 9:01 UTC (Mon)
by johannbg (guest, #65743)
[Link] (5 responses)
The old sysv init and native systemd service files ( which I just converted just to test this ) start and stop cleanly on F15 host running systemd which indicates that the problem resides elsewhere either specific to your system and or what's being shipped with your distro of choosing.
Here are the native systemd service files for fcron which should work on any distro using systemd ( note that relevant paths might need to be adjusted and or any distro specific startup option for the daemon )
To test this..
# vim /lib/systemd/system/fcron.service
[Unit]
[Service]
[Install]
# vim /lib/systemd/system/fcron_watch_config.service
[Service]
[Install]
Then run systemd daemon-reload to let systemd pick up the native systemd service files.
And to start stop restart and see the status of the service
systemctl start/restart/stop/status fcron.service or fcron_watch_config.service
To enable/disable the service at boot up run
systemctl enable/disable fcron.service or fcron_watch_config.service
I'll leave it up as an exercise for the readers to take a look at the relevant fcron sysv scripts that get shipped with their distro and compare it to these native systemd service files which I provided here to reach an informal decision of which one is more complicated and or harder to understand.
Posted May 2, 2011 9:46 UTC (Mon)
by nicooo (guest, #69134)
[Link] (4 responses)
Posted May 2, 2011 12:46 UTC (Mon)
by johannbg (guest, #65743)
[Link] (3 responses)
Requires=$foo.target $bar.service
or
Wants= $foo.target $bar.service
or
BindTo= $foo.target $bar.service
see systemd.unit man page for details.
Posted May 2, 2011 22:49 UTC (Mon)
by nicooo (guest, #69134)
[Link] (2 responses)
I would have:
If one user has cronie, another dcron and another fcron, how would this work?
Posted May 3, 2011 1:32 UTC (Tue)
by phess (subscriber, #74656)
[Link] (1 responses)
"If one user has cronie, another dcron and another fcron, how would this work?"
Then I guess you should use cron as a target:
mkdir /etc/systemd/system/cron.target
Then add "Wants=cron.target" to your cron daemon's unit file.
After that, your other unit files should only mention cron.target instead of any of {cronie,fcron,vixie-cron}.service.
Posted May 4, 2011 1:40 UTC (Wed)
by phess (subscriber, #74656)
[Link]
'Wants=cron.target'
Posted Apr 29, 2011 20:20 UTC (Fri)
by mezcalero (subscriber, #45103)
[Link] (6 responses)
Also, systemd is modular, you have individual components dealing with different things. That's so Unix, that it can't get any more Unixish.
Of course, if you think Unix philosophy means balkanization, complexity, smorgasbord, and being antiquated, then true, systemd is not Unixish at all.
Posted Apr 29, 2011 21:10 UTC (Fri)
by viro (subscriber, #7872)
[Link] (5 responses)
Posted Apr 29, 2011 21:15 UTC (Fri)
by mpr22 (subscriber, #60784)
[Link]
Posted Apr 30, 2011 1:20 UTC (Sat)
by mezcalero (subscriber, #45103)
[Link] (3 responses)
Posted Apr 30, 2011 1:44 UTC (Sat)
by viro (subscriber, #7872)
[Link] (2 responses)
Posted Apr 30, 2011 10:15 UTC (Sat)
by khim (subscriber, #9252)
[Link]
Well, it worked for devfs because few major distributions relied on it (as I can recall the only distribution which required the use of devfs was Gentoo... and it was not all that major). If systemd will be adopted widely enough cgroups will be kept around in one form or another. In the worst case it'll be just a fork which real distributions use and another one which is mainstream and which noone uses. Yup. Why do you think users need a fix? As far as they are concerned the thing works. If (and when) you decide to rip "that abortion" out they will have a problem - or you will do. It depends on number of users, really. Upstream linux kernel is pretty much irrelevant for most users already (because there are more Android and embedded users then desktop users - and these kernels often diverge from upstream quite severely), I fail to see why sky will fall on earth if server and desktop will go this way too.
Posted Apr 30, 2011 13:08 UTC (Sat)
by adobriyan (subscriber, #30858)
[Link]
What wrong with it?
Posted Apr 30, 2011 6:58 UTC (Sat)
by jcm (subscriber, #18262)
[Link] (9 responses)
Posted Apr 30, 2011 8:47 UTC (Sat)
by james (subscriber, #1325)
[Link] (1 responses)
Since the early eighties, there has been very little wheel-reinvention in Unix text-mode utilities: since CDE stopped being actively developed, there has been very little wheel-reinvention in Unix graphics.
As a result, commercial Unix has offered consistent platforms for at least fifteen years.
But you wouldn't want to actually use commercial Unix on the desktop, would you? Not without all the GNU and Gnome/KDE re-invented wheels.
Posted Apr 30, 2011 20:07 UTC (Sat)
by drag (guest, #31333)
[Link]
And as a result nobody in their right mind would want to use a Unix GUI for anything.
Linux is the closest you can get to a decent GUI for a Unix system using traditional protocols. And the only reason it's as good as it is because of massive changes in how it works and a large number of extensions. Virtually nobody programs their applications in the same manner as they did 15 years ago.
Meanwhile the most popular Unix-for-GUI users is obviously OS X and they succeeded where Unix failed by completely abandoning X Windows right off the bat. For Unix geeks they can still get X Windows via xdarwin.
TDLR:
The vast majority of people would rather pay their application developers to rewrite their applications from scratch rather then be forced to use X Windows on a real Unix system.
Posted Apr 30, 2011 9:34 UTC (Sat)
by khim (subscriber, #9252)
[Link]
I want to disappoint you: you'll never beat the record this way. Try harder. Here is first sentence: Here is another: You managed to put contradictions on adjacent sentences, but real pros can do it in adjacent words! Jokes aside: one serious inconsistency between different distributions was always the init system. Even when both distributions used similar piles of scripts to manage daemons they never were identical. It was usually impossible to create a single script to use on Debian and RedHat. You can not simultaneously ask to "offer a consistent platform third parties can program against" and say "sysvinit worked just fine". Because it didn't. I care less about advanced SystemD features, but I really like how it makes it very hard to paper over many problems. The fact that you can not easily ask SystemD to use /var/run is good one: this means ISV can rely on the fact that /run will always be there. My only fear is that people will push Lennart hard to add all these pointless "configurability" features, eventually they'll added and history will repeat itself. P.S. It's funny how often people complain that "inconsistent platform is killing linux" but then turn around and complain that "I can not reintroduce this particular inconsistency I like". Pick one way or anyther! If you want consistent platform - then SystemD hardcoded paths and automounted filesystems should be fine. If you want to tweak your system as much as you want - then you can just ignore SystemD and live without ISVs attention.
Posted Apr 30, 2011 13:43 UTC (Sat)
by mezcalero (subscriber, #45103)
[Link] (5 responses)
There are very few professions where the tools for working have not changed in the last 30 years, by the introduction of the computer (you seem to be appalled by any improvements on top of UNIX, so basically want to stick with 30y old technology). But I think you might be able to find a job opening as sheep herder in Scotland or so, which still works basically the same as 200 years ago. There, things won't be so damn fast as in the computer industry. And if you are lucky then cell phone reception won't be available in the Scottish highlands, and you don't have to see how everything progresses and you don't.
Posted May 1, 2011 23:24 UTC (Sun)
by dgm (subscriber, #49227)
[Link] (4 responses)
What's wrong with pointing that 1) systemd is just another init system, and an incompatible (as in needing to rewrite stuff) one, and 2) Many people don't need or want it?
Are you going to send everyone that disagrees with you to skin sheep to Scotland?
Posted May 2, 2011 0:41 UTC (Mon)
by HelloWorld (guest, #56129)
[Link] (3 responses)
Posted May 2, 2011 15:34 UTC (Mon)
by dgm (subscriber, #49227)
[Link] (2 responses)
In fairness, I sounds like what we will gain will offset the effort, but for the moment I'm skeptical. Specially after reading how Pottering disregards portability. Systemd is Linux-only by design.
Posted May 2, 2011 20:00 UTC (Mon)
by HelloWorld (guest, #56129)
[Link] (1 responses)
While this may be a weakness, it is not an incompatibility: stuff that used to work still works the way it used to, so it's not incompatible. Also, it's not entirely true. Daemons supporting inetd don't need to be patched. See Poetterings systemd talk, around minute 13. A bit later on he also mentions that it would have been possible to avoid the need for patching the daemons by adding features to the kernel to support this feature, but it would have been to hard/messy, so they decided that modifying the individual daemons is easier.
Posted May 5, 2011 16:12 UTC (Thu)
by Quazatron (guest, #4368)
[Link]
Posted Apr 30, 2011 12:48 UTC (Sat)
by neilbrown (subscriber, #359)
[Link]
Maybe the aspect of "Unix philosophy" that is embodied in init scripts and horribly violated by systemd is to take a moderately good idea and to push it beyond its competence (as I believe was done with signals).
In this case the good idea is shell scripts. The "shell" is an incredibly useful language for doing a certain class of tasks, and an incredibly horrible language from any language-theoretic stand point. Correspondingly shell scripts are incredibly useful, but definitely the wrong way to try to create large maintainable systems.
Shell scripts are particularly good for quick prototypes. The "spell" command is a good example. It was originally a small shell script (cat $1 | tr -s '\011 ' '\012' | sort | uniq | comm -13 - /usr/dict/words) which then grew into a larger shell script which then became an unmanageably large shell script, which then became a compiled C program (was 'ispell' the first, or was there an earlier one?).
Shell scripts were an obvious and correct way to prototype the start-up of services at boot time, but surely we have reached the point where we can move on from the prototype??
From a completely different perspective, as the upstream maintainer for mdadm and (previously) nfs-utils, one of the biggest frustrations is/was that every distro has different init scripts for starting these services so it is very hard to provide support or fix bugs for issues that relate to the boot sequence. In particular there are very important ordering requirements for starting the various NFS related daemons. If you get some of them wrong you will hardly ever notice - until something breaks strangely in a rare-but-possibly situation (e.g. server restarts while client holds a lock). There was no way I could ensure that every distro got this right. The best I could do was document it as carefully as possible.
With systemd this becomes possible. I don't actually know if systemd starts NFS services, and I don't know if it gets it "right". But that is not the point. The point is that it is one standard tool - with the *right* concepts (like socket-based-dependencies) - which I could add the support to if needed, and could fix the support in if it were broken and then every distro that used systemd would get the fix.
I'm convinced that /etc/rc and then /etc/rc.local and then /etc/rcNN.d/ were the right things to do. But we have learnt useful stuff at each step and it really is time to move on - to grow up you might say.
Posted Apr 29, 2011 14:18 UTC (Fri)
by sztanpet (subscriber, #60731)
[Link]
Posted Apr 29, 2011 20:13 UTC (Fri)
by mezcalero (subscriber, #45103)
[Link] (1 responses)
And dude, of course this is biased, and I said so in one of the first paragraphs. It's my blog after all, not LWN or any other press product which should try to be neutral. I mean, are you really expecting me not point out the points I really believe in?
Posted Apr 30, 2011 14:15 UTC (Sat)
by welinder (guest, #4699)
[Link]
In other words, sysvinit handles swap via its plugin system,
Don't get me wrong, I think systemd shows a lot of promise. But your
Posted Apr 30, 2011 6:55 UTC (Sat)
by jcm (subscriber, #18262)
[Link]
Jon.
Posted Apr 29, 2011 14:10 UTC (Fri)
by gmaxwell (guest, #30048)
[Link] (12 responses)
I don't think that word means what he thinks it means.
Posted Apr 29, 2011 14:45 UTC (Fri)
by AlexHudson (guest, #41828)
[Link]
Posted Apr 29, 2011 15:32 UTC (Fri)
by Lennie (subscriber, #49641)
[Link] (10 responses)
Standardization is not on my mind.
Standardization on Linux maybe, but not on *BSD, Solaris and so on.
Even if Debian would want to adopt it, how will they handle other kernels/ports ? Like Hurd and kFreeBSD.
Posted Apr 30, 2011 9:40 UTC (Sat)
by khim (subscriber, #9252)
[Link] (9 responses)
Well if you work in server space then "*BSD, Solaris and so on" have some meaning. But on desktop... The typical approach is: "We want to be truly cross-platform. We've got Windows and Mac covered. Now the question: should we even think about Linux or not?". People answer "yes" more and more - and this is good thing, but I'm not sure we'll ever see the time where "*BSD, Solaris and so on" will be even considered.
Posted Apr 30, 2011 9:49 UTC (Sat)
by Lennie (subscriber, #49641)
[Link] (8 responses)
Posted Apr 30, 2011 10:48 UTC (Sat)
by khim (subscriber, #9252)
[Link] (7 responses)
It's not aimed on server and embedded. It's useful there, sure, but it's not the goal. AFAICS the goal is to bring standardization to distributions and make life of ISVs easier. If the server and embedded with adopt systemd - that's good, too, but this is not a big deal. It'll have [nice] side-effect of reducing number of differences beween desktop, server and embedded and [not so nice] effect of further marginalization of other *nix'es, but this is not the goal.
Posted Apr 30, 2011 13:09 UTC (Sat)
by mezcalero (subscriber, #45103)
[Link] (6 responses)
Posted Apr 30, 2011 15:52 UTC (Sat)
by khim (subscriber, #9252)
[Link] (5 responses)
Direct cite from the article: Well, busybox and Android pretty much cover most of the embedded development nowadays so it's kind of hard to consider your efforts seriously WRT mobile and embedded if you just ignore them. Of course systemd is GPLed so I think there are no hope for unification. The most we can realistically expect is few ideas (and may be config files) borrowed from systemd and planted in Android...
Posted Apr 30, 2011 20:11 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
Posted Apr 30, 2011 20:56 UTC (Sat)
by khim (subscriber, #9252)
[Link] (1 responses)
That's why I said "it's useful there, sure, but it's not the goal". You can use systemd for embedded system with busybox and may be possible to adjust it to make it usable with Android too - but the article is pretty clear that these were non-goals when systemd was developed. If these are non-goals then you can not seriously say it was developed with embedded in mind. The fact that Linux is usable in embedded environment is kind of accident and the same is true for systemd. Let's hope systemd will not repeat the story of linux itself (where bunch of embedded guys created bunch of incompatible forks and it took eons to clean this mess up... and it's still not entirely cleared).
Posted May 1, 2011 16:11 UTC (Sun)
by martinfick (subscriber, #4455)
[Link]
Posted May 1, 2011 0:01 UTC (Sun)
by mezcalero (subscriber, #45103)
[Link]
Posted May 4, 2011 12:52 UTC (Wed)
by vonbrand (subscriber, #4458)
[Link]
And not so far back, embedded meant "software runs on the bare iron, just starts from DOS" (if there was some operating system at all involved, that is). Don't judge by what is dictated by today's limitations.
Posted Apr 29, 2011 15:41 UTC (Fri)
by MisterIO (guest, #36192)
[Link] (8 responses)
Posted Apr 29, 2011 19:12 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link] (4 responses)
ll /etc/mtab
lrwxrwxrwx. 1 root root 12 Apr 25 11:32 /etc/mtab -> /proc/mounts
Posted Apr 30, 2011 3:01 UTC (Sat)
by MisterIO (guest, #36192)
[Link]
Posted Apr 30, 2011 5:57 UTC (Sat)
by gurulabs (subscriber, #10753)
[Link] (2 responses)
The need for a txt file on Linux was because /proc/mounts didn't record all the mount options just the basic ones. Now that /proc/mounts keeps track of ALL mount options, /etc/mtab can be a symlink.
Posted Apr 30, 2011 8:12 UTC (Sat)
by MisterIO (guest, #36192)
[Link] (1 responses)
None of these are actually useful to me(and most likely to the majority of people out there) and some of them are kind of hilarious(rootfs / , wow, this one is really useful)!
Posted May 11, 2011 18:29 UTC (Wed)
by nix (subscriber, #2304)
[Link]
Posted Apr 30, 2011 16:23 UTC (Sat)
by obi (guest, #5784)
[Link]
I've got some other issues with it on Debian, like it not supporting Debian's crypttab options properly (using scripts for smartcards, usb sticks, and decrypt_derived). But I expect suitable alternatives to appear soon enough.
Posted May 1, 2011 12:41 UTC (Sun)
by Eckhart (guest, #74500)
[Link] (1 responses)
v25: it is in experimental for a reason.
Posted May 3, 2011 13:16 UTC (Tue)
by MisterIO (guest, #36192)
[Link]
Posted Apr 29, 2011 15:46 UTC (Fri)
by Banis (guest, #59011)
[Link] (2 responses)
Posted Apr 29, 2011 19:35 UTC (Fri)
by martinfick (subscriber, #4455)
[Link]
Posted Apr 29, 2011 20:08 UTC (Fri)
by mezcalero (subscriber, #45103)
[Link]
Also, I made clear that it's one of the creators of systems writing this and that you should take it with a grain of salt hence, in one of the first paragraphs.
Posted Apr 29, 2011 16:24 UTC (Fri)
by david.a.wheeler (subscriber, #72896)
[Link] (57 responses)
I think systemd has a lot going for it, but this isn't a fair comparison. For example, this comparison is missing these rows:
Poettering: Why systemd?
Poettering: Why systemd?
I encourage you to read article with opinions about systemd design flaws:
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd? (and kill off other implementations, period!)
You clearly underestimated Department of Redhat, our smart one.
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
"shell scripts used for glue things together. Bueh! It's unclean, it's impure, all daemons should works in one way, OUR WAY".
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
category. Untrustworthy advertisement even.
the whole thing becomes pointless. It makes me wonder what is being
hidden.
Poettering: Why systemd?
(FWIW I share the opinion expressed, and find systemd awesome too)
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Sorry, but no...
Perhaps you expect your *init* system to do more than it should? To me, it should start and stop tasks when I ask it to, and that's pretty much it.
I respect the Unix philosophy. I also respect other software design philosophies, and sometimes these come into conflict. I do not hold the Unix philosophy in such high esteem that I will treat it as a trump card in such a conflict.
Poettering: Why systemd?
Poettering: Why systemd?
1) Everything was already invented and perfect 40 years ago.
2) Everything else must be implemented using shell scripts and pipes.
Poettering: Why systemd?
That's pretty much how I feel about it too when people keep whining about how something violates the "Unix philosophy".
Poettering: Why systemd?
Poettering: Why systemd?
There exist conservative FLOSS platforms for those who want them.
Poettering: Why systemd?
Poettering: Why systemd?
Oh, and to add to that, there is today a huge sense of arrogance from a growing minority that they know better (this isn't targeted at systemd, it's a general problem) than everyone else and standards be damned.
Everything is too readily dismissed as old and out of date, and standards are dismissed just because they might be hundreds or thousands of pages long, or not updated in a few years.
There needs to be a slow train departing from a station somewhere around here. On board the train will be those who care more about "fit and polish" than throwing away well established protocol and tradition.
Why isn't desktop Linux "finished"?
Why isn't desktop Linux "finished"?
Why isn't desktop Linux "finished"?
Why isn't desktop Linux "finished"?
Why isn't desktop Linux "finished"?
Why isn't desktop Linux "finished"?
Why isn't desktop Linux "finished"?
$ $VISUAL pkg-list # review packages to be purged
# dpkg -P `<pkg-list`
Why isn't desktop Linux "finished"?
Why isn't desktop Linux "finished"?
Why isn't desktop Linux "finished"?
Why isn't desktop Linux "finished"?
desktop Linux is now much less stable for many graphics cards than it was a few years ago
Is it? I thought that before I tried KMS, and, y'know, I haven't had a single problem on the three Radeon cards and two Intel that I've tried. (I haven't tried nvidia because I actively avoid them and all their works.)
I'm not that the minor benefits of KMS are worth the apparent years of instability.
The 'minor' benefits include support for any version of OpenGL above 1.5, which is ancient; the possibility to see kernel panics even when X is running (I don't know if this works yet but at least it is possible); much more reliable suspend/resume; and the ability to actually use most of the card's capabilities (it's not a framebuffer anymore, it's a massively parallel computer with an address space partially disjoint from the CPU's, and there is no hope of userspace modesetting modelling any of that).
Why isn't desktop Linux "finished"?
Why isn't desktop Linux "finished"?
Why isn't desktop Linux "finished"?
Why isn't desktop Linux "finished"?
aptitude purge \~c purges leftover conffiles and data (don't do it for a database though), and install/remove/upgrade commands take a --purge-unused flag that purges while uninstalling.
Why isn't desktop Linux "finished"?
Poettering: Why systemd?
Poettering: Why systemd?
It's too bad no one wants GNU on mobile devices.
Poettering: Why systemd?
Poettering: Why systemd?
Solved problems aren't interesting. But there are tons of problems that sysvinit didn't solve and systemd does.
No, it's wrong because computers, their environment and their users nowadays bear no resemblance to what they were like when Unix was invented.
Besides, most people who bullshit about the so-called "Unix philosophy" only have *very* vague ideas about what it is.
People did just fine before computers even existed, therefore nothing in computing is strictly necessary. The question is what is sensible and worthwhile. Having an init daemon that is able to kill all processes belonging to a service sounds sensible to me. So does getting rid of unix shell scripting whereever possible
Poettering: Why systemd?
Almost correct. Almost everything was invented 40 years ago, reaching perfection until about 10 years ago. About 5 years ago Red Hat went on a hiring spree, hiring inexperienced kids from all over the place, and *their* choices are making things worse. And it's not that everything else must be implemented using shell scripts and pipes, it's that for most things shell scripts and pipes are the best choice. Not understanding why this is true doesn't make it less true.
I want my OS and the applications in it to bend to MY use case (meaning the people I support get exactly what they want). Neither you or Lennart Poettering or anyone else knows precisely what that use case is. I have the intelligence and imagination to do that provided I'm working with a sensible Linux distribution. Consider that #3 in your list.
There are people in the world who lack intelligence and imagination and would prefer that *all of us* be forced to choose from the same short list of checkboxes because that levels the field for them. And there are people with the hubris to think that they know what those choices should be. Typically this will be someone with no real OPS experience or experience in one or two environments at most.
Old joke: Manager goes to a Windows admin with a problem, the admin looks in the knowledge base (some screen shots), gives the manager 4 options. Next the manager presents the same problem to his Linux admin who responds "Well, how do you want it to work?" The Unix Philosophy (and shells and pipes) that you denigrate is what makes that possible. Systemd will make this more difficult.
Poettering: Why systemd?
The Unix Philosophy (and shells and pipes) that you denigrate is what makes that possible. Systemd will make this more difficult.
Poettering: Why systemd?
> worth the pain. You end up constantly fighting against its design decisions.
Poettering: Why systemd?
Poettering: Why systemd?
dmesg is for important system events and not for redundant application
messages.
I would have to hand disable most of the default mount points.
(Just because there's a fancy new kernel feature doesn't mean you have to enable it by default)
(I've tried everything possible, but it would just start and then hang and not execute any cron jobs)
Poettering: Why systemd?
Poettering: Why systemd?
> Correct me if I'm wrong, but I think kexec is invoked after all file systems other than root have been unmounted. Since /usr can potentially be a separate file system, kexec should not be there.
Poettering: Why systemd?
Meanwhile, one thing I've not seen in any of the reviews, etc, yet, possibly because I've frankly not been interested enough to go read the main articles referred to in coverage like this, is how well systemd might operate as a secondary initsys, responsible for a few daemons that ship with decent systemd init configs by default, but not for initialization of the entire system. Does it have a mode that allows that, without the admin having to worry about it unpredictably trying to takeover something it wasn't configured to handle on that system and without being more trouble than it's worth to setup?
Poettering: Why systemd?
Poettering: Why systemd?
I could just edit a small shell script and change the path. In systemd
I have to edit a C file and recompile and link. (And BTW calling external
programs from C is not the same as your advertisement suggestion:
"Built-in kexec support". And this goes for a lot of items on your list)
user to place kexec in /sbin, similar to your brilliant idea to move /var/run to /run
just because you cannot handle a simple /var mount-point in systemd.
all didn't work. And fcron doesn't have a problem with any other init system.
Hmm... This is pretty typical :-)
It just highlights the problem with systemd.
In any other init system I could just edit a small shell script and change the path.
The other possibility (and apparently your favorite) is to force every Linux user to place kexec in /sbin, similar to your brilliant idea to move /var/run to /run just because you cannot handle a simple /var mount-point in systemd.
No. Nobody forces you to mount every available kernel fs by default.
Hmm... This is pretty typical :-)
Please make choice 1, You can Choose:
A) I want a system that boots fast
B) Oh I can choose a system that will detect my hardware properly
A) I can choose a system that won't puke and cause my system to hang in case I boot it up with no network
OR
B) Tie my system into LDAP for user synchronization.
Poettering: Why systemd?
> I could just edit a small shell script and change the path. In systemd
> I have to edit a C file and recompile and link.
> programs from C is not the same as your advertisement suggestion:
> "Built-in kexec support". And this goes for a lot of items on your list)
> user to place kexec in /sbin, similar to your brilliant idea to move /var/run to /run
> just because you cannot handle a simple /var mount-point in systemd.
Poettering: Why systemd?
> > user to place kexec in /sbin, similar to your brilliant idea to move /var/run to /run
> > just because you cannot handle a simple /var mount-point in systemd.
Poettering: Why systemd?
Poettering: Why systemd?
> No. It just highlights the problem with systemd. In any other init system
I could just edit a small shell script and change the path.
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
(I've tried everything possible, but it would just start and then hang and not execute any cron jobs)
Description=Fcron an periodical command scheduler.
After=syslog.target
Type=forking
PIDFile=/var/run/fcron.pid
ExecStart=/usr/sbin/fcron -b
ExecReload=/bin/kill -HUP $MAINPID
WantedBy=multi-user.target
[Unit]
Description=Vixie cron configuration files script checker for fcron.
After=syslog.target
Type=forking
PIDFile=/var/run/fcron_watch_config.pid
ExecStart=/usr/sbin/daemon_fcron_watch_config
WantedBy=multi-user.target
If something requires cron (but fcron isn't set to start by default), how would systemd know that it should start fcron?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
service-that-needs-to-run-daily.service
[Unit]
Wants=multi-user.target cron.service
Poettering: Why systemd?
Poettering: Why systemd?
Where my previous comment says:
please read
'WantedBy=cron.target'
Poettering: Why systemd?
Poettering: Why systemd?
Relying on things that turn out to be steaming crocks sounds pretty Unixy too.
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
We'll see :-)
For values of fix including "rip the FPOS out"? Worked for devfs, eventually...
_You_ want to use the damn thing; I'm perfectly fine configuring it out for all my boxen. IOW, you need to fix that abortion more than I do. Any additional questions?
Poettering: Why systemd?
Poettering: Why systemd?
I'm not sure your comment paints Unix in a good light.
Poettering: Why systemd?
Poettering: Why systemd?
Hmm...
This constant wheel re-invention in the Linux space does ultimately have to stop if we're going to settle down and offer a consistent platform third parties can program against.
Not to pick on systemd too much, but I cannot recall thinking to myself, "gee, if only my init system weren't so crap". Actually, sysvinit worked just fine, thank you
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
No, I mean that to gain something from (and thus justify) changing to systemd you need to rewrite the server's code. Otherwise, what's the point? The optimum thing would have been some automatic mechanism. I don't know if that would have been possible. Maybe I'm too demanding?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
typically (==always) in the form of shell scripts.
article makes it look like something for sale in a airline magazine.
You know, the extensible paint brush that makes it easy to paint your
bathroom ceiling while sipping tea in the swimming pool.
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
There are different worlds...
There are different worlds...
It tries to standardize linux distributions...
It tries to standardize linux distributions...
Android is pretty big part of embedded world today
Unless you run Android (which is a completely different beast anyway), you'll almost definitely run one of these three init systems on your Linux kernel. (OK, or busybox, but then you are basically not running any init system at all.)
Android is pretty big part of embedded world today
That's why I said what I said.
That's why I said what I said.
Android is pretty big part of embedded world today
Android is pretty big part of embedded world today
Well, busybox and Android pretty much cover most of the embedded development nowadays so it's kind of hard to consider your efforts seriously WRT mobile and embedded if you just ignore them.
Poettering: Why systemd?
In Fedora it works well, but it dirties /etc/mtab!
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
For example, the first lines of /etc/mtab in Fedora now are:
rootfs / etc
/proc /proc etc
/sys /sys etc
udev /dev
then a lot of cgroup, systemd-1, devpts, tmpfs, selinuxfs
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Like I said, it doesn't start dbus, that in turn may be caused by some other problem somewhere else, I don't know.
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Missed some rows
sysvinit Upstart systemd
Works on FreeBSD? Yes Yes? No
Works on Debian GNU/kFreeBSD? Yes Yes? No
Works on OpenBSD? Yes Yes? No
Works on NetBSD? Yes Yes? No
Works on OpenSolaris? Yes Yes? No
...
Well, you get the point. Systemd is so tied to Linux's extensions that it can't even *run* without a Linux kernel. Lennart Poettering has argued why that's okay, and for many that may be fine. I think systemd is pretty cool in a lot of ways. But if you want an init system that works everywhere, systemd is *NOT* it.
Posted Apr 29, 2011 16:41 UTC (Fri)
by Sho (subscriber, #8956)
[Link]
Posted Apr 29, 2011 16:43 UTC (Fri)
by mpr22 (subscriber, #60784)
[Link]
Posted Apr 29, 2011 17:11 UTC (Fri)
by AndreE (guest, #60148)
[Link] (9 responses)
Posted Apr 29, 2011 17:30 UTC (Fri)
by david.a.wheeler (subscriber, #72896)
[Link] (8 responses)
While the name is historically "Linux Weekly News", LWN has been more generally about free software for a very long time. "What is this LWN thing?" says that "LWN.net aims to be the premier news and information source for the free software community". Not just for Linux.
I didn't say it was a sticking point, I said it was an attribute that matters to some, and it's important to note this as a weakness. It's NOT true that absolutely all "current free software graphics technology" is only supported on Linux; last I checked, FreeBSD, NetBSD, and others have GUIs. Sure, there's lots of recent goodness that is Linux-specific, but that doesn't mean there's an absence of anything else.
Since Linux is the majority FLOSS kernel, you could argue that FLOSS no point of FLOSS programs supporting anything else. You could also argue that "standards and portability no longer matter now that we have FLOSS" - i.e., you could claim that open standards were useful when there was no FLOSS, but FLOSS now fills the role of an "executable specification" and specs simply aren't relevant any more. But a lot of people do NOT agree with such arguments; unportable infrastructure like systemd is a BIG problem with this group, and it's important to note that as a downside.
Posted Apr 29, 2011 17:35 UTC (Fri)
by jonabbey (guest, #2736)
[Link]
Posted Apr 29, 2011 17:48 UTC (Fri)
by david.a.wheeler (subscriber, #72896)
[Link]
Posted Apr 30, 2011 2:18 UTC (Sat)
by AndreE (guest, #60148)
[Link] (5 responses)
In kernel graphics drivers don't exist on the BSDs, so none of the X graphics driver improvements and support in the last 3 years can be utilised by these systems. That means no open source ATI drivers, no open source nouveu drivers, and being stuck using vesa or vga for any recent cards.
Yes, these systems have GUIs, but then again, these systems also have their own init systems.
If you are so against systemd for not being supported on other systems, you must be against the changes in X over the last three years.
Posted May 1, 2011 3:55 UTC (Sun)
by VelvetElvis (guest, #69142)
[Link] (4 responses)
Posted May 1, 2011 9:32 UTC (Sun)
by mpr22 (subscriber, #60784)
[Link] (2 responses)
Posted May 1, 2011 11:13 UTC (Sun)
by HelloWorld (guest, #56129)
[Link]
Posted May 2, 2011 10:30 UTC (Mon)
by nicooo (guest, #69134)
[Link]
Posted May 2, 2011 8:55 UTC (Mon)
by AndreE (guest, #60148)
[Link]
Posted Apr 29, 2011 17:54 UTC (Fri)
by mezcalero (subscriber, #45103)
[Link] (34 responses)
Posted Apr 29, 2011 18:00 UTC (Fri)
by dlang (guest, #313)
[Link] (33 responses)
Posted Apr 29, 2011 18:17 UTC (Fri)
by martinfick (subscriber, #4455)
[Link] (30 responses)
Posted Apr 29, 2011 18:55 UTC (Fri)
by dlang (guest, #313)
[Link] (29 responses)
there are a few things based on distros choosing to put files in different places (which systemd won't fix), but most of it is just different ways of solving the same problem.
there's a lot of third-party software available that includes the init files, and that software has no problems using the same scripts on many different distros (they just decide where to put their stuff and don't care if it's where the distro maintainers would put it)
I expect the same type of thing to start happening with the systemd config within a year or two of it becoming the default.
Posted Apr 29, 2011 19:08 UTC (Fri)
by martinfick (subscriber, #4455)
[Link] (19 responses)
> there are a few things based on distros choosing to put files in different places (which systemd won't fix), but most of it is just different ways of solving the same problem.
So tell me again where is the advantage of having "different ways of solving the same problem"?
> I expect the same type of thing to start happening with the systemd config within a year or two of it becoming the default.
If the differences are the only thing that will likely cause them to have different config files, then I would say that systemd has done an excellent job! The differences, the policies, are exactly the things that should be configured in these files, not the mechanisms!
To paraphrase your statement, "the shell scripts are a small amount of different policy and large amount of mechanism (all implemented differently)." Finally, with systemd, the policy is abstracted and obvious and the mechanism can be the same, (more common code and likely way better tested in the long run)!
Posted Apr 29, 2011 21:20 UTC (Fri)
by dlang (guest, #313)
[Link] (18 responses)
>And this is an advantage of not using systemd?
it's not an advantage, it's reality, and it will be reality with systemd as well, just give it a little bit of time
> So tell me again where is the advantage of having "different ways of solving the same problem"?
if we didn't allow for different ways of solvign the same problem, nobody would ever be able to find a better way (and systemd for example could not even be attempted because the OS wouldn't work with it)
you are taking advantage of the fact that the system allows you to solve things in a new way to create systemd, but then claiming that the freedom to do so isn't important for anyone else.
Posted Apr 29, 2011 21:46 UTC (Fri)
by martinfick (subscriber, #4455)
[Link] (17 responses)
Who said anything about not allowing different ways? The freedom to do so is great. Does that mean it should be done differently without a good reason? Systemd attempts to unify different ways when it makes sense and when there is no good reason for them to be different. In most of these cases it makes sense, if not, why would the different distros agree to switch? Likely because they agree with the proposed way that systemd solves these problems.
No to mention that most of these old ways are likely broken! Many of them are nasty old hacks because there isn't a good common solution implemented anywhere. For example, do you really think that keeping track of pids in files is a better way to kill a daemon than using cgroups? Such a mehtod is fraught with potential miss kills, I am shocked that enterprise distros allow such behavior... "oops, just killed the company database server when I meant to kill my homebrewed monitoring script". Today, most distro scripts are likely knowingly broken. Do you think the average homebrewed script even has a chance of being only half as broken as a distro script? I suspect that systemd makes writing an unbroken homebrewed startup config possible and likely.
Posted Apr 30, 2011 0:22 UTC (Sat)
by nicooo (guest, #69134)
[Link] (16 responses)
> I am shocked that enterprise distros allow such behavior
Posted Apr 30, 2011 8:16 UTC (Sat)
by rahulsundaram (subscriber, #21946)
[Link]
Posted Apr 30, 2011 9:51 UTC (Sat)
by khim (subscriber, #9252)
[Link]
Wow. Talk about ignorance! There are many things which worked for Unix till it got serious competition. Then it lost first desktop, then server and not the bettle for enterprise is in full swing. I fail to see how "it worked for enterprise unix" can be used as justification. Sure it did - because there was no alternative. Some things "enterprise unix" does are still better then what the Linux does, but the list shrinks over time... and usaged of pid files to manage daemons instead of cgroups is not one of them.
Posted Apr 30, 2011 11:29 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (13 responses)
Various 'enterprise' Unixes had workarounds since forever. Like ability to 'lock' PID of a process (so it won't be reused). Or locking PID for several minutes after getpid() calls (so "ps | grep ... | xargs kill" won't kill some innocent process).
Posted May 3, 2011 1:21 UTC (Tue)
by wahern (subscriber, #37304)
[Link] (11 responses)
The easiest and cleanest general purpose solution would be to extend the PID namespace to 64-bits, or maybe even 128-bits. Problem solved. This is a common solution for when maintaining and communicating a consistent global state is not practically feasible, which is the case with the historical paradigm of process management on Unix.
I don't know why this has never been done. The existing 16-bit namespace is ridiculous. There should be a kernel compile-time option to increase the pid_t width. Then over the course of several years broken applications that make unwarranted assumptions about pid_t could be fixed. The vast majority of issues are probably with printf formatting; people usually cast pid_t to (int). If PIDs were chosen at random (as on OpenBSD) than the 31- or 32-bits shown would actually be useful, much like Git's truncated hash identifiers. So even most broken apps would only be half broken.
I realize it's a *huge* change, but its simple and straight-forward, the consequences are mostly foreseeable, and with open source software readily addressed by even casual C programmers. GCC could be instrumented to track pid_t conversions, and in a matter of weeks I bet Debian's build system would uncover the vast majority of issues. All of a sudden one of the most ugly Unix warts--that is, fundamentally broken in the context of common usage--disappears.
Posted May 3, 2011 9:10 UTC (Tue)
by leighbb (subscriber, #1205)
[Link] (1 responses)
sysctl -w kernel.pid_max=4194304
Not as much as you were after but bigger than you thought :-)
Posted May 3, 2011 13:13 UTC (Tue)
by wahern (subscriber, #37304)
[Link]
Posted May 3, 2011 15:03 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (8 responses)
And larger PID lengths are way too clumsy for humans. That's definitely NOT a good engineering.
Besides, even with 128-bit PID length you'll still have problems with double-forked processes (which are reparented to init).
systemd nicely solves these problems.
Posted May 3, 2011 18:17 UTC (Tue)
by wahern (subscriber, #37304)
[Link] (7 responses)
It's really only an unresolvable issue when you have errant, buggy processes. Otherwise, a sophisticated daemon should have a domain socket which takes control messages. But I'm presuming that process management means being able to handle processes that aren't well behaved.
Posted May 3, 2011 18:21 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (6 responses)
>Although I'm not familiar with cgroup usage, I think that there's still a race in adding a fresh process to a cgroup, so even systemd could benefit from a larger PID space.
Nope. cgroups work on kernel level and so they use proper locking, so PIDs won't be able to leak. Also, one can easily protect processes in a cgroup from an accidental kill (in fact, cgroups can be used as a complete lightweight virtualization solution).
Posted May 4, 2011 5:03 UTC (Wed)
by wahern (subscriber, #37304)
[Link] (5 responses)
cgroup inheritance I can understand. A process forked from a process already assigned to a particular cgroup atomically inherits membership in the cgroup, just as it would atomically inherit a session id and process group id. But now, say, I want to reassign that process to a different cgroup PID. It seems like there's the same problem as above. What am I missing?
Posted May 4, 2011 5:44 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
You need to somehow have a unique process handle, which PID is definitely not. On Linux it can be done using the /proc/PID/ directory. The sequence would be:
Of course, it's better to create a process directly in the required group in the first place.
Posted May 4, 2011 8:26 UTC (Wed)
by wahern (subscriber, #37304)
[Link]
My proposal was to make PID a unique quasi-handle the same way random UUIDs are unique.
Posted May 4, 2011 19:31 UTC (Wed)
by njs (subscriber, #40338)
[Link] (2 responses)
In the above scheme, if you're the one who's spawning this new process that you want to end up in a cgroup, then you can do
That's race-free.
Posted May 4, 2011 21:08 UTC (Wed)
by wahern (subscriber, #37304)
[Link] (1 responses)
Of course, "who cares" is a valid reply; we've been living with it for 40 years. But that response challenges the value added by systemd's reliance on esoteric Linux subsystems. For example, when we talk about how a service manager is so much better than a race-prone PID file, nobody ever considers that the race condition is easily avoided by not using root. If you create a user per daemon--_www, _ftp, etc--then even if you read a stale PID and signal the wrong process, as long as you're sending the signal with a service-delegated UID then it will never be delivered.
I never brought it up before because it's arguably not very elegant. I'm loath to defend PID files. But if we're going to replace them with something, I'd like it to be generic and tailored to the specific issue, rather than lauding some supposed panacean init replacement.
The past decade in Linux-land has seen a parade of sophisticated daemon services intended to patch over some clunky Unix interface (device management, process management, etc, etc). They each require application developers to change from portable POSIX patterns to using some new API or library or protocol. But they come and go like the wind. Worthy solutions tend to be so obviously beneficial that all the free unices eagerly adopt or mimic them.
Posted May 5, 2011 1:06 UTC (Thu)
by njs (subscriber, #40338)
[Link]
IIUC, when systemd starts a service, that service gets stuck (reliably, and race-freely) into its own cgroup, from which it cannot escape. Then you can kill it or whatever reliably, even if it's badly behaved (spawning children that double-fork and end up as orphans, forking to a new PID every 100 ms, whatever you like).
If you're trying to go after a process that was started outside of a cgroup, then this doesn't work so well, but not much does. That process that keeps switching PIDs as quickly as possible can't easily be killed even if you have a collision-free PID space.
Posted May 4, 2011 21:28 UTC (Wed)
by mjthayer (guest, #39183)
[Link]
> Various 'enterprise' Unixes had workarounds since forever.
A workaround I implemented a while ago for "normal" Unixes was for the daemon to place an advisory lock on its pidfile. It only works on filesystems with that feature of course, but by checking that the file is locked before issuing your kill command you greatly reduce the race window.
Posted Apr 29, 2011 19:57 UTC (Fri)
by mezcalero (subscriber, #45103)
[Link] (8 responses)
I think you have little experience with actually writing sysv init scripts. Making them portable between distributions is irrationally hard, and even LSB headers, which were supposed to improve the situation just made it worse. Most (all?) upstream software I have seen which ships init scripts has different init script implementations for the different distributions.
And no, I see no reason that distros will differ too much on the systemd unit files. Why I come to that conclusion? Well, we have stuff like .desktop files or D-Bus service activation files, and they do not differ between distributions. They are the same everywhere. And they have been around for quite some time now already. With systemd we make service descriptions as easy and portable as .desktop files and D-Bus service files, and thus I see little reason to believe that the distros will try to divert too much from upstream.
Posted Apr 29, 2011 21:22 UTC (Fri)
by dlang (guest, #313)
[Link] (1 responses)
someone who comes along and states that we should ignore anything that's not a linux box (and then in practice limits it further by eliminating the entire embedded space) understands the issues better.
Posted Apr 30, 2011 13:47 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Apr 29, 2011 22:44 UTC (Fri)
by dskoll (subscriber, #1630)
[Link] (5 responses)
Most (all?) upstream software I have seen which ships init scripts has different init script implementations for the different distributions.
We use the same init script across all our Linux distros (and even on the BSDs) for our commercial product.
That being said, our product is largely written in Perl, so we wrote the init script in Perl too. That might make some recoil in horror, but it simplifies our life quite a bit, and since you need Perl to run our product anyway... :)
Posted Apr 29, 2011 23:06 UTC (Fri)
by jspaleta (subscriber, #50639)
[Link] (4 responses)
Do you have any conditional logic in your perl based init script which fires depending on the environment your script ends up running under?
I don't think he was claiming that it is impossible, I believe the claim is one of pragmatic realities of the accumulating differences across distributions makes a strawman out of any argument about assuming perfect portable initscripts commonly found in the wild.
-jef
Posted Apr 29, 2011 23:19 UTC (Fri)
by dlang (guest, #313)
[Link]
the distro maintainers don't like them, but the software is unconditionally put in one place, no matter what OS it is (frequently under /opt) and the init scripts start and stop the application without any problems.
this isn't just for trivial apps either, all it takes is a decision that you don't care what the 'normal' thing for this particular platform is, (frequently on the basis that the platform is just there to support the application, which is commonly valid) and you don't have to worry very much about the variations between platforms.
Posted Apr 30, 2011 2:59 UTC (Sat)
by dskoll (subscriber, #1630)
[Link] (2 responses)
Do you believe that the care and effort you put into the portability of your init script is typical or atypical?
Oh, hey, I'm all for systemd. I think it's a great idea. It won't help us on non-Linux platforms, though. (At least not for a while...)
Do you have any conditional logic in your perl based init script which fires depending on the environment your script ends up running under?
Nope. The Perl stuff is used so we can have pluggable components to start different executables depending on what's installed and on how the particular node is configured. It also rationalizes PATH handling, but there's no platform-specific code.
Posted Apr 30, 2011 19:49 UTC (Sat)
by rvfh (guest, #31018)
[Link] (1 responses)
Posted May 1, 2011 6:40 UTC (Sun)
by dskoll (subscriber, #1630)
[Link]
Question is: how will this work with systemd?
I can't imagine there will be any problems. To the outside world, our script looks like a normal sysvinit script:
script start
script stop
etc...
Posted Apr 29, 2011 18:37 UTC (Fri)
by aleXXX (subscriber, #2742)
[Link]
Alex
Posted Apr 29, 2011 20:04 UTC (Fri)
by mezcalero (subscriber, #45103)
[Link]
In fact you can turn this all around and claim that systemd improves portability here -- the portability between various Linux distributions for upstream packages: because they can just hook themselves into the boot in a single unified way, that is the same on all distros (which have adopted systemd).
So if you say that systemd was worse with portability I say it actually drastically improves it.
Posted May 1, 2011 2:51 UTC (Sun)
by drag (guest, #31333)
[Link] (8 responses)
It seems to me that in these type of articles people are ready to harp about compatibility of dead and dying OSes, but completely ignore the portability to systems that people actually use.
Out of that chart you posted only FreeBSD and OpenBSD really matter. And those use their own init systems already. If anybody was going to spend the time to port them over to a new init system lets just hope that they choose something that is actually a improvement like Launchd.
GNU/kFreeBSD is a toy OS. Like Haiku or ReactOS it's all nice and interesting in it's own way, but it's not relevant and nobody actually uses it besides a tiny amount of people.
OpenSolaris is dead. It may thrash around for a few more years and it may exit out of the 'Dead Like Hurd' category and move back up into 'Toy OS like Haiku', but it's not going to amount to anything.
Portability doesn't mean the same thing now that it did 20 years ago. I wish people would stop pretending that it does.
Posted May 1, 2011 18:02 UTC (Sun)
by dskoll (subscriber, #1630)
[Link] (7 responses)
If it doesn't run on Windows it's NOT portable.
If it doesn't run on OS X then it's NOT portable.
Many Linux developers care only about UNIX-like systems. Windows is certainly not UNIX-like, and OS X is getting less and less UNIX-like with each release.
Bottom line: Windows and OS X aren't even on many Linux/UNIX developers' radars. They simply don't matter. (Sure, maybe in the mass market they're important, but in the little niche of UNIX/Linux software in which I'm content to work and play, Windows and Mac OS X are completely irrelevant.)
Posted May 1, 2011 18:19 UTC (Sun)
by HelloWorld (guest, #56129)
[Link] (6 responses)
Posted May 1, 2011 18:25 UTC (Sun)
by rahulsundaram (subscriber, #21946)
[Link]
Posted May 1, 2011 21:22 UTC (Sun)
by anselm (subscriber, #2796)
[Link] (3 responses)
That means it supports the usual system calls and command line utilities so you can get basic stuff to run on it. It doesn't vouch for the underlying philosophy.
Even Windows NT used to be POSIX certified, way back when, and nobody would have confused that with a real Unix.
Posted May 2, 2011 13:32 UTC (Mon)
by HelloWorld (guest, #56129)
[Link] (2 responses)
The so-called "Unix philosophy" most of the time boils down to dogmatism and retrogressiveness, so I honestly couldn't care less about it. Cyberax summed it up pretty well here.
Unlike the people bullshitting about the "Unix philosophy", people like the Mac OS X developers and Lennart Poettering actually have visions about where they want the system to go, and they're not afraid to point out the suckiness of traditional system components like X11 or sysvinit. And this is the reason why Linux and Mac OS X thrive, while nobody gives a fuck about traditional Unix systems and their "philosophy" anymore.
Posted May 2, 2011 14:40 UTC (Mon)
by anselm (subscriber, #2796)
[Link] (1 responses)
I would recommend you take a look at
the Wikipedia page on »Unix philosophy«. That should disabuse you of that particular notion.
Note that there is nothing on that page that says »Don't go for better solutions to existing problems.« And with all philosophies, this stuff is not meant to encourage one to stop thinking on one's own. That way lies blind fanaticism.
Posted May 2, 2011 15:19 UTC (Mon)
by mpr22 (subscriber, #60784)
[Link]
Posted May 1, 2011 21:22 UTC (Sun)
by dskoll (subscriber, #1630)
[Link]
Exactly! You've finally figured out who is and who isn't relevant in the UNIX world.
Posted May 5, 2011 20:12 UTC (Thu)
by zuzzurro (subscriber, #61118)
[Link]
Posted Apr 29, 2011 17:10 UTC (Fri)
by jonabbey (guest, #2736)
[Link]
It sure took some time to get used to having something as essential to Linux as init change after all this time, though.
Posted Apr 29, 2011 23:25 UTC (Fri)
by fest3er (guest, #60379)
[Link]
Posted May 2, 2011 6:44 UTC (Mon)
by PaulWay (guest, #45600)
[Link] (13 responses)
"Hey, this is my system, I set it up just so, I've gotten used to all its little quirks and eccentricities, so it must be correct and a Good Thing. We hand-coded our start-up ordering and fixed things by hacking the init scripts and we liked it! I've seen those young turks come along and tell everyone how devfs was going to cure our ills and that kind of gim-crackery. Now some young hotshot who doesn't even have a beard comes along and tells me all that is wrong? Well, golly gee, that just goes against my principles! How am I supposed to learn some new-fangled thing over which I can't exercise complete control in the only way I know how?
"And he comes in here telling us all he's sorted everything out and he's shown all these red boxes against my favourite SysV init system! How dare he! The role of telling people exclusively how they should be doing things is mine, I tell you, mine! Just look at the fact that he claims to solve everything and work perfectly - he must be wrong, only my code does that! He'd better leave off or I'll find whatever standards suit me and shove them up his nose!"
Sorry, ladies and gentlemen, but it just looks like a "Mine's Better" competition at this point. A lot of the arguments are devolving down to 'well your example sucks' and hyperbole, which is never a good sign.
None of the 'advantages' of SysV init have been things I've enjoyed working with for the last 20 years I've been working with Unix systems. I'm sure we'll find out the problems with systemd in the long run, and I'm sure there are things it won't be able to solve, but I do think it's a lot better designed and a lot more comprehensive than SysV.
Have fun,
Paul
Posted May 3, 2011 11:11 UTC (Tue)
by sorpigal (guest, #36106)
[Link] (6 responses)
I like everything about systemd except: (1) it's not simple to understand and therefore I don't understand it and therefore it's worse than sysvinit. (2) It advocates a level of non-negotiable integration between daemons and the init system which effectively entrenches systemd (or something so equivalent that a redesign later becomes extremely non-trivial) as the only possible init system. (3) Its author appears fanatical more than pragmatic. (4) Its configuration files are unpleasantly ugly. (5) It cannot be the universal init system because its author specifically opposes the existence of operating systems which are not Linux, or thinks that they do not deserve support by any daemon which also runs under Linux.
If systemd is good then we should use it for all OSes, or at least all Unix-like systems. If it's not good for that then it's not good.
Posted May 3, 2011 11:31 UTC (Tue)
by mpr22 (subscriber, #60784)
[Link] (2 responses)
Posted May 3, 2011 15:35 UTC (Tue)
by dlang (guest, #313)
[Link] (1 responses)
it's not even that everyone is demanding that he code all such fallbacks into systemd, it's that he has made it clear that he considers any such fallback to be a waste of time and therefor nobody else would bother to submit any patches.
there's a huge difference between being apathetic about non-linux systems (i.e. you don't care about them) and being hostile (i.e. considering that nobody else should care about them either)
apathy is just fine as long as you are willing to accept patches and support from people who do care about such systems.
Posted May 3, 2011 15:50 UTC (Tue)
by rahulsundaram (subscriber, #21946)
[Link]
Posted May 3, 2011 11:41 UTC (Tue)
by rahulsundaram (subscriber, #21946)
[Link]
Have you run a system with systemd at all? Because it has several different binaries to do different things
1) sysvinit was simple in its core but it left a lot of important features outside to bash scripting and every distro had its own convoluted slightly different mess. systemd integrates and standardizes all this
2) not sure what this means
3) not sure what this means either
4) ini file format is way way more simpler than copy pasting boiler plate shell scripts.
An important aspect is that unlike sysvinit, systemd comes with extensive documentation. This is a major advantage that ends up reducing complexity in the practical sense
Posted May 3, 2011 14:18 UTC (Tue)
by mjthayer (guest, #39183)
[Link] (1 responses)
Regarding the cgroups dependency though - wouldn't it be better to rewrite the daemons that systemd starts to have a "do not daemonise" option, so that all their children just stay in one process group or at least one session, and to keep the cgroups thing as a backup option for the recalcitrant ones? "Roll your own" daemonising seems to me the sort of hack that systemd is trying to make unnecessary.
Posted May 4, 2011 21:39 UTC (Wed)
by mjthayer (guest, #39183)
[Link]
Posted May 3, 2011 14:34 UTC (Tue)
by rgmoore (✭ supporter ✭, #75)
[Link] (5 responses)
Shorter: Everything should be standardized, but not if it requires me to change.
Posted May 3, 2011 14:58 UTC (Tue)
by rahulsundaram (subscriber, #21946)
[Link] (4 responses)
Posted May 3, 2011 15:32 UTC (Tue)
by cry_regarder (subscriber, #50545)
[Link]
Posted May 3, 2011 21:33 UTC (Tue)
by rgmoore (✭ supporter ✭, #75)
[Link] (2 responses)
Sorry, I seem to be using a form you're not familiar with. The "Shorter:" means I'm summarizing the previous poster's point. In this case, I'm suggesting that the complainers are only in favor of standardization as long as it doesn't force them to change. I agree that this is an unreasonable position. Since I think increased standardization is a good idea, this means people will have to accept some change.
I guess the situation with systemd reminds me of two other situations I've encountered. One was a disagreement between a mechanic and an engineer about cars. The mechanic liked carburetors because he was confident he could fix a carburetor if it ever broke; the engineer preferred fuel injectors because they were much less likely to break in the first place. It seems to me that the supporters of SysV with traditional scripts are like the mechanic; they like that they know how to modify the scripts but ignore that many of their hacks would be unnecessary with a better designed system.
The other is something that the Gnome maintainers commented about their decision to eliminate many configuration options. They said that many requests for new configuration options were really requests to fix bugs, but that the people requesting the "not broken" option didn't realize that the behavior they were describing shouldn't have been happening in the first place. I suspect, though I'm not sure, that many of the configuration tweaks that supporters of the current system are talking about are really bug fixes. They're asking that we maintain their ability to patch other people's breakage rather than move to a system that isn't so broken to start with.
Posted May 3, 2011 21:38 UTC (Tue)
by dlang (guest, #313)
[Link] (1 responses)
a lot of the people who are disagreeing with you think that different people may want slightly different things.
Posted May 3, 2011 21:43 UTC (Tue)
by rahulsundaram (subscriber, #21946)
[Link]
Posted May 2, 2011 21:41 UTC (Mon)
by piggy (guest, #18693)
[Link] (1 responses)
Posted May 2, 2011 22:06 UTC (Mon)
by mpr22 (subscriber, #60784)
[Link]
Posted May 5, 2011 20:31 UTC (Thu)
by zuzzurro (subscriber, #61118)
[Link] (2 responses)
Don't you guys hate the way systemctl runs your $PAGER by default without you asking for it? Gee, I hate that... If i want to type systemctl | less, I will just do it, for $DEITY's sake. The default of running it is just backwards.
Posted May 5, 2011 20:44 UTC (Thu)
by anselm (subscriber, #2796)
[Link] (1 responses)
Yes, that's a complete and utter outrage. Totally, totally against the spirit of Unix. Unbearable. Sickening. This Poettering guy must be a perfect moron anyone with the least inkling of what is proper knows that all right-minded people just detest the same feature in »man foo«.
Posted May 5, 2011 23:18 UTC (Thu)
by zuzzurro (subscriber, #61118)
[Link]
Missed some rows
A valid point. Anyone likely to care is also likely to be well aware of it already, of course.
Missed some rows
Missed some rows
It matters to some
It matters to some
It matters to some
It matters to some
It matters to some
Systemd is available in Debian GNU/Linux unstable.
It matters to some
It matters to some
I think the issue is that it can't be the default init system unless it also runs on those systems.
It matters to some
It matters to some
Upstart is linux-only too. And i seriously doubt sysvinit in the version that is usually used is actually that portable, resp. is actually realistically used by anybody on those OSes, except maybe debian kfreebsd. I think requesting portability to other kernels for a lowlevel OS component like an init system is not valid in any way. You are trying to create the impression that this was relevant for upstart or sysvinit, but it never was. And it is neither for systemd.
Missed some rows
Missed some rows
Missed some rows
Missed some rows
Missed some rows
And this is an advantage of not using systemd?
Missed some rows
Missed some rows
Missed some rows
Which ones? I only know of F15.
It worked for enterprise unix.
Missed some rows
Oh, yeah.
It worked for enterprise unix.
Missed some rows
Missed some rows
Missed some rows
Missed some rows
Missed some rows
Missed some rows
Missed some rows
Missed some rows
Missed some rows
1) Change current directory to /proc/PID
2) Look around and check that this PID is still the correct one. That's safe because if the process its /proc/PID directory becomes empty - and stays that way.
3) Write to /proc/PID/cgroup.
Missed some rows
Missed some rows
1) fork
2) the child adds itself to the desired cgroup
3) the child calls exec()
Missed some rows
Missed some rows
Missed some rows
Missed some rows
Missed some rows
Missed some rows
Missed some rows
Missed some rows
Missed some rows
Missed some rows
Managing programs startup using a perl script
Managing programs startup using a perl script
Missed some rows
Great :-)
Missed some rows
Missed some rows
If it doesn't run on OS X then it's NOT portable.
Missed some rows
Missed some rows
Missed some rows
Missed some rows
Missed some rows
Missed some rows
The so-called "Unix philosophy" most of the time boils down to dogmatism and retrogressiveness, [
]
Having looked at that, I really fail to be persuaded that systemd violates Unix philosophy even half as severely as most of the Lennartware-haters say it does.
Missed some rows
Missed some rows
Missed some rows
If people like it, people will port it, one way or the other.
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
So if the BSDs, or AIX, or Solaris, reject a kernel feature, we should never be able to take advantage of it in init?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
[...]
> Regarding the cgroups dependency though - wouldn't it be better [...] to keep the cgroups thing as a backup option for the recalcitrant ones?
Rahul answered that replying to a different posting a little bit up - cgroups is now indeed compile-time optional.
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
The PAM integration is for systemd's user session management.
Poettering: Why systemd?
Poettering: Why systemd?
Poettering: Why systemd?
Don't you guys hate the way systemctl runs your $PAGER by default without you asking for it? Gee, I hate that...
Poettering: Why systemd?