Recent Features
| |||||||||||||
Interview with Lennart Poettering (LinuxFR.org)Interview with Lennart Poettering (LinuxFR.org)Posted Jul 6, 2011 14:42 UTC (Wed) by tialaramex (subscriber, #21167)In reply to: Interview with Lennart Poettering (LinuxFR.org) by nix Parent article: Interview with Lennart Poettering (LinuxFR.org)
Well perhaps at some point Debian faces a cross roads, is it a collection of programs that run on any arbitrary operating system kernel a Debian Developer happens to take a fancy to, or is it a Linux distribution.
I won't predict how that debate would go, there's no guessing with Debian.
I thought Lennart's suggestion (Debian is welcome to make all its packages work equally well with both, that's just lots of extra work for little reward) was remarkably even handed.
The BSD reaction to all this is frustratingly reminiscent of talking to old-school UNIX® people in the mid-1990s. No reason, that they saw, for their beloved system to adopt these new-fangled ideas from that not-even-really compatible Linux upstart. And now where are all those UNIX® systems? Sadly a lot of them are now Windows.
(Log in to post comments)
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 15:58 UTC (Wed) by raven667 (subscriber, #5198) [Link]
More of them are RedHat
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 16:08 UTC (Wed) by iabervon (subscriber, #722) [Link]
Actually, I think the most sensible thing to do would be to come up with a way to make init run systemd service units. One big advantage of systemd's format is that it is amenable to being parsed, rather than just executed with arguments; since it can examine what's supposed to be done, a wrapper using a systemd service unit (as the only service-specific part) ought to be able to work about as well as a custom init script. (The main lack being when there is some service-specific method that works for identifying children, which systemd would not need due to using cgroups, and which would therefore not be included in the unit.)
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 16:18 UTC (Wed) by nevets (subscriber, #11875) [Link]
This cgroups thing is what bothers me the most about systemd. It now makes my system require it. If I want to boot a kernel that does not support cgroups or just an older kernel, now my system wont even work. This alone is the one thing keeping me away from systemd.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 17:25 UTC (Wed) by tuna (guest, #44480) [Link]
What is it that you are planning to do with systemd?
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 17:33 UTC (Wed) by nevets (subscriber, #11875) [Link]
Install it.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 17:49 UTC (Wed) by zdzichu (subscriber, #17118) [Link]
So you will be relieved that cgroups aren't hard dependencies anymore. Systemd will complain and breakage can occur, but you can run some older kernels. But why would you like to not enable cgroups?
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 17:51 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
because cgroups have a significant amount of overhead on the system right now, so unless I am doing something that needs cgroups, I don't enable them in the kernels that I compile (even the new ones)
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 18:34 UTC (Wed) by SEJeff (subscriber, #51588) [Link]
Just out of curiosity, can you link to any benchmarks or whatnot on the overhead of cgroups? I'm not saying they don't impact things, but am curious if this has actually be quantified using some synthetic benchmarks or whatnot.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 19:02 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
I think there have been a number of discussions recently (on the kernel list and on LWN that have talked about the overhead of cgroups (in part because they are bolted on rather than fully integrated.
I could be remembering things incorrectly.
but in any case, as a standard security best practice, if I don't need a feature I don't enable it. This also makes my systems more reliable as there is less code compiled in.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 22:38 UTC (Wed) by mezcalero (subscriber, #45103) [Link]
systemd requires only the grouping part of cgroup, i.e. no controllers. The impact of some controllers might be high, but the basic grouping logic is barely measurable.
The people who complain the loudest tend to mix up cgroups with its controllers. I'd prefer if people could make the distinction there. But hey, if people were well informed they probably wouldn't whine that loud. Educated whining?
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 19:30 UTC (Wed) by michich (subscriber, #17902) [Link]
systemd wants a kernel with CONFIG_CGROUPS=y, but it does not care if you have the cgroups-aware scheduler (CONFIG_GROUP_SCHED) or any of the subsystems or resource controllers (they all have distinct kernel config options). I don't think the overhead from CONFIG_CGROUPS alone is significant.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 20:31 UTC (Wed) by tuna (guest, #44480) [Link]
Well, systemd needs cgroups :)
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 20:33 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
so that sounds like a reason to not use systemd to me.
especially if it's only requirement is that the kernel configure them, but that they don't actually do anything.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 20:46 UTC (Wed) by raven667 (subscriber, #5198) [Link]
They do do something, the main thing systemd uses them for, which is to identify which processes are related to one another by name and to differentiate between multiple identical processes which belong to different named services.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 20:53 UTC (Wed) by nevets (subscriber, #11875) [Link]
And that limits me to what kernels I can boot. As a kernel developer, I may not be the focus of Lennart's users, but it totally eliminates me from ever testing his work. If systemd requires that all my kernels must have CGROUPS enabled, then I can't use it. My job requires that I test various configurations, and !CGROUPS is one of them.
Cgroups are still rather new and hasn't matured yet to be something that I would push as a must have for a distro. There is a lot that I do not agree with Lennart, but its OK as long as I am not forced to use it. I'll stick to Fedora 13 for a long time (and Debian on my own computers).
I'm getting a strong feeling that I will soon be having a custom install on all my boxes (no systemd and no gnome3). Well, I may have one box (or partition) that has systemd for testing why it broke.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 7, 2011 10:20 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
As has been pointed several times, systemd doesn't require cgroups and will still boot just fine without it. It won't have all the features that take advantage of cgroups but that is expected.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 7, 2011 11:56 UTC (Thu) by michich (subscriber, #17902) [Link]
I wouldn't say it runs just fine. It runs crippled. The only reason it does not crash immediately is to allow a kernel developer to see if his modified kernel still boots. Please don't use it for more than that. You would not get a good impression of systemd.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 7, 2011 9:07 UTC (Thu) by Karellen (subscriber, #67644) [Link]
Agreed. I've thought it might be interesting to try to write a systemd-unit-file to init-shell-script "compiler".
Some systemd features won't necessarily be available, and the scripts might only work reliably for well-behaved daemons; but then, those features aren't available in current init scripts, and init scripts only work correctly with well-behaved daemons anyway.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 18:50 UTC (Wed) by trasz (guest, #45786) [Link]
Note that most of the commercial UNIX systems went away because they were bound to the hardware architectures that went away.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 19:12 UTC (Wed) by nevets (subscriber, #11875) [Link]
Exactly. The reason Linux and Windows did so well was because they ran on $5,000 server quality PCs, whereas IIRC SunOS ran on a $20,000 workstation, and AIX on a $60,000 workstation. The takeover of Linux and windows was more because of the ability to run on cheaper hardware than being a better OS.
I contracted at IBM Federal Systems when it was sold to Loral, and the first thing we did was dump the AIX systems for Sun, because of the price. Not because Sun was better than AIX. I personally thought AIX was better than Sun, but not worth that much of a price difference.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 19:54 UTC (Wed) by dmarti (subscriber, #11625) [Link]
There were lots of "PC Unix" OS products out there, with hardware requirements pretty close to those of decent Linux servers.
http://www.catb.org/~esr/faqs/clone-unix-guide.txt
Most of them sank without a splash pretty quickly once you could get stable, supported Linux.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 7, 2011 5:02 UTC (Thu) by martinfick (subscriber, #4455) [Link]
One of those was even called Solaris. :)
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 7, 2011 11:52 UTC (Thu) by nevets (subscriber, #11875) [Link]
I remember them trying out SCO's PC Unix, but it had lots of issues, and could not handle what was needed. Eventually, they switched most of the Unix boxes over to Windows (not Linux).
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 7, 2011 13:26 UTC (Thu) by pabs (subscriber, #43278) [Link]
Personally I'd like to see Debian GNU/Any happen one day:
http://hadrons.org/~guillem/debian/ports/gnu-any/debian-g...
One architecture, install and set of packages, reboot into any kernel you prefer and glibc will handle it for you. Obviously there will be things that bypass glibc or hard-code sysfs paths so it wouldn't be perfect, but it would be interesting.
|
|||||||||||||