Russ Allbery leaves the Debian technical committee
| From: | Russ Allbery <rra-AT-debian.org> | |
| To: | debian-ctte-AT-lists.debian.org | |
| Subject: | Resigning from the Technical Committee | |
| Date: | Sun, 16 Nov 2014 17:34:10 -0800 | |
| Message-ID: | <87k32ufw4t.fsf__37899.5782965378$1416188080$gmane$org@hope.eyrie.org> | |
| Cc: | debian-project-AT-lists.debian.org |
Hello everyone, I resign from the Debian Technical Committee, effective immediately. Doing this immediately is for the sake of clarity and for some of the reasons mentioned below, not to cause problems for anyone. I don't believe any issues are created at this point by an immediate resignation, since there are still six active members, plus Colin's willingness to continue on for a transition period. However, if I'm wrong, please let me know, and I can change the effective date. I'm making this choice for a variety of complicated reasons. I'm going to try to explain them, and hopefully I won't put my foot in my mouth or unintentionally hurt anyone by doing so. I'm going to write a tome in an effort to be clear. Apologies in advance for the giant wall of text. If any part of this doesn't make sense, or if any of it feels like an attack or a reaction to any single person or event, I'm happy to clarify. I would appreciate it if people would ask for clarification rather than making assumptions, as assumptions about other people's motives are one of the things that I find the most demoralizing about the Debian project right now. The short summary of what follows: * TC work and related conversations have become a large part of my work in Debian. This seems conceptually wrong to me. It's also not very fun. * Nearly every TC decision decision is now very fraught, and expressing those decisions, at least in the current framework, requires more skill, care, attention, and caution than I currently have mental or emotional resources to do. I am not doing work that I can be proud of, which means I either need to invest more resources or step down, and I don't have the additional resources at this time to invest. * It's no longer clear to me that my work on the technical committee is actually helping the project as a whole. I believe that means I need to either propose improvements or step down so that someone else who believes in the work can pick it up, and I have not come up with any convincing improvements. In the following, I'm going to say a lot of things about my personal thought processes and decisions. I know it's going to be tempting to read some of these statements as subtle commentary on other people's decisions and actions. Please don't. Where I have specific commentary, I'll make it openly; otherwise, I'm talking about my personal goals and emotions. Other people have different beliefs, goals, and reactions, and that's good and necessary. My decisions aren't their decisions, and having a wide variety of different people with different opinions in the Debian project is absolutely vital to its ongoing health. If anything in this speaks to you, I'm happy for it to be food for thought, but please draw your own conclusions based on your own goals and beliefs, and feel free to discard mine where you don't think they apply. When I was first invited to join the technical committee, nearly six years ago now, I was very active in the project in other ways: working on Lintian, helping to maintain Policy, and maintaining a fairly large number of packages. Since then, due to various changes in my own life, my time to work on Debian has dropped considerably. I've stepped down or become inactive in many of those other areas. Being on the technical committee takes a deceptive amount of time. It's something that I kept, while dropping other work, because normally the time committment is fairly low. However, I badly underestimated the amount of emotional effort and attention that it was going to require, and in a way that's worse than a time committment. At the moment, because my time is more limited, governance discussions constitute the vast majority of the time I spend working on the project. Sometimes, when I can find a good solution that makes everyone involved happy, this is fun. But it's mostly not; it's just work, not something that I do for enjoyment. One of the things I feel passionately about is Debian as a volunteer project, as an opportunity to work on the things that we find fun, exciting, or interesting, in a setting without the normal pressures of external deadlines, bureaucracy, and formal responsibility. But, right now, I'm not doing that myself. TC work over the past year has been difficult, exhausting, and not at all something I could call a relaxing or invigorating hobby. The actual investigation of different init systems was fun and felt productive and worthwhile; everything subsequent, not so much. I'm hoping to shift to working on that I can enjoy wholeheartedly. I'm also not comfortable being part of the governance process when I'm not deeply involved in the work. I think free software governance works best when it's done by people who have ongoing and direct invovlement in the work being governed. This was true for me when I was more active in Policy and Lintian work, and isn't true at the moment. In short, I don't want to be that person who never does anything themselves, but who joins all the conversations to complain about how everything is being done. I can feel that happening, and I want to stop it before it starts. We've made two decisions recently related to systemd, both of which I misjudged. By that, I don't mean the decisions themselves (my feelings on that are more complicated, and I'm not going to get into that here), but the way that they would be received and the ways they could be interpreted. If I'd made either decision knowing that, it would be one thing, but the reaction caught me by surprise in both cases, even though in retrospect I should have recognized the problems. There are other people on the technical committee with more technical expertise and more institutional knowledge. The primary skill that I try to bring to TC discussions is to catch exactly this sort of thing, and to try to apply empathy in line with the values that I care the most about in Debian: maintainer empowerment and the ability of people to work on things that bring them joy. I'm not successfully doing that at the moment. It's clear to me that I need to be doing a lot more work than I'm currently doing in talking to people, understanding their perspective, and getting more social context in order to do this effectively. If I'm not going to do that work, and right now I don't have the additional resources to spend, I need to step down and let someone else take their own approach to the TC role. This is particularly true right now, where every decision the TC makes that has anything remotely to do with systemd is incredibly fraught. It's going to be parsed and examined and dissected, and has to be extremely careful in order to avoid making existing hurt deeper. I don't believe I have the resources to do that work right now. Finally, I've been thinking hard about Debian project governance in the light of Joey's resignation, as I'm sure many of us have been. I've also been thinking hard about many of the subsequent discussions and reactions. As I've mentioned in several recent threads, I think governance of this sort of project is a very hard problem, particularly when the project is deeply divided on many aspects of a particular question. I do still feel like governance is necessary; philosophically, I'm one of the people who believes that any group of people larger than a small team are going to need some sort of governance structure so that disagreements aren't paralyzing. But I think Joey captured my feelings very well in his blog post at <https://joeyh.name/blog/entry/on_leaving/> where he talks about the importance of being able to try out decisions and iterate. I think the agile philosophy got a few things right: find ways to reduce the cost of change, empower individuals to make choices and act on them, and reduce the cost of failure and embrace iteration instead of trying to prevent failure in advance. And I'm increasingly dubious that Debian's decision-making processes as currently used, particularly the technical committee, are compatible with that approach. My largest concern in stepping down from the technical committee is that I'm just avoiding working on something difficult, and thereby making the problem worse. I believe that some governance method is necessary, and given that I have strong feelings about this and keep thinking about it, I should stay and make it better. But it's become clear to me over the past week or so both that I don't have any great alternatives that I feel comfortable advocating, and that I'm exhausted with the discussion. I think project governance is a hard problem, and a worthwhile problem, and I hope that someone with good ideas will step forward and work on that problem. Debian is one of the largest free software projects, and one that faces a large number of hard decisions. If we can do that work well, it would be a valuable contribution to the broader community. But, right now, I don't feel like I'm helping that process, and at times am making it worse. Thank you, all of you, for your trust in me over the past six years as a project representative for technical decisions, and for the wonderful support and encouragement that I've received over the difficult past year. I'm probably going to take a break from discussions and project arguments for a while, and then hopefully will be back to work on more of the day-to-day technical work of the project. I've been giving that involvement a lot of thought as well, but this is a project that I want to stay part of regardless of the outcome of the current GR. I have strong opinions, but I also have great faith in the members of this project and in the project as a community. Sooner or later, this will all be behind us; in the meantime, I'm going to work on enjoying collaborating with all the great people who make Debian what it is, instead of focusing on the disagreements and arguments. -- Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Posted Nov 17, 2014 15:23 UTC (Mon)
by BrucePerens (guest, #2510)
[Link] (279 responses)
Here's another issue brought to a head by systemd. There's a conflict for anyone with a job like being on the TC for an obvious reason: Systemd achieves some powerful and important goals for Linux systems. And at the same time Systemd doesn't play well with others (especially other init systems) and is badly in need of being broken up into separate projects. Debian was able to allow individual developers to make decisions because it's modular. Systemd isn't modular enough to fit the Debian paradigm, at least at present. And the way it's been pushed upon the entire community is deplorable. It's time to put on the brakes. We need to break systemd up into separate projects, resolve the issues that cause the largest objections to it, and make sure it plays with others (again, including other init systems). Oh, and pushing back on the team that pushed it upon us is unfortunately necessary. Until those issues are handled, Debian (and other sensible distributions) should not be based upon systemd.
Posted Nov 17, 2014 15:29 UTC (Mon)
by SEJeff (guest, #51588)
[Link] (39 responses)
*puts on flame retardant pants*
Debian is an amazing ecosystem, but it isn't the first nor the last distribution to adopt systemd. Please stop making this all about systemd. The problem is that politics (which systemd is simply a straw that broke the camel's back) and absolutely unacceptable levels of bile being spewed by certain individuals are wearing down amazing contributors. This isn't about systemd, it is about Debian, please stop making it about the thing you hate.
This is a very sad time for Debian, systemd or no systemd, I hope they make it clear (in the future) that this level of unprofessionalism ala Death Threats and personal attacks are simply unacceptable. Not being an Ubuntu guy for some time, I'm still a HUGE fan of the Ubuntu Code of Conduct. It keeps the community overall quite a bit more friendly and is designed to cut down on person attacks that have caused several exceptional Debian contributors to resign their duties. At a certain size, design by commitee simply falls flat on it's face. As a fan of the unbelievable amount of work Debian and Debian contributors have done for OSS/FLOSS, I've got a huge amount of respect for Debian. It would be sad for everyone to see it divulge into another Gentoo like after Daniel Robbins left.
Posted Nov 17, 2014 15:58 UTC (Mon)
by BrucePerens (guest, #2510)
[Link] (35 responses)
OK. You want the rest? I'd show Ian Jackson the door. I don't know the others well enough to have an opinion. Other than that, my main issues with Debian as it is running today are: 1. Sights set too low. By "The Universal Operating System" I meant just that. Not "The Operating System In a Corner That Is Used As A Base For Ubuntu." and definitely not "We The Developers Only Make It For Ourselves". 2. Leadership or lack thereof. Yes, design by committee has its limits but that is what a project leader is for.
Posted Nov 17, 2014 16:35 UTC (Mon)
by SEJeff (guest, #51588)
[Link] (30 responses)
Posted Nov 17, 2014 17:10 UTC (Mon)
by BrucePerens (guest, #2510)
[Link] (27 responses)
You didn't like the Ian Jackson comment? I can be perfectly in agreement with him from a technical perspective. But I think he's been behind any number of better developers finding the exit rather than spend their days dealing with him. It's unfortunate.
Posted Nov 17, 2014 17:31 UTC (Mon)
by SEJeff (guest, #51588)
[Link] (26 responses)
Posted Nov 17, 2014 17:36 UTC (Mon)
by BrucePerens (guest, #2510)
[Link] (25 responses)
Glad to know we're in agreement on the important things, then. :-) What don't you like about what I said about systemd?
Posted Nov 17, 2014 18:40 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (24 responses)
Whereas systemd was designed from the outset to comply with the Unix philosophy of "do one thing and do it well", namely control all the background processes a modern OS needs.
From what I can make out, when you're running systemd, that is ALL pid 1 does - control (using cgroups) all the processes that get fired off.
The problem is, because it controls everything, it needs fingers in all the pies, hence logind, journald, timed and hostd and all that stuff whatever it's called just fits in neatly. It's not part of systemd the init system, but provides a nice consistent setup, so they're seen as part of systemd when they're not part of the init system, and could easily be replaced IF anybody were prepared to put in the effort. Rather tellingly, hardly anybody has bothered!!!
Oh - and as for systemd breaking your system, I'd like to put systemd on mine - it makes for easy multi-seat support I understand. It would probably also make it easy for me to fix my system (which uses OpenRC) and currently has weirdos with raid (my / partition is working fine, but doesn't exist !?!? ) and nfs has died with "unknown function start#". Those aren't systemd because I'm not running it! (Oh, and don't say "use SysVInit", because I gather NFS is quite the nightmare on a SysVInit system ...)
(
# mount
and then list the device ...
# ls -al /dev/md127
Cheers,
Posted Nov 17, 2014 18:51 UTC (Mon)
by rahvin (guest, #16953)
[Link] (14 responses)
What I'm talking about is Gnome, the oft cited example of systemd dependencies that in fact doesn't actually exist. In fact Gnome would be absolutely happy to have a consolekit replacement they could use as an alternative but the one that had existed died with no active developers and finally had to be abandoned by Gnome because of bitrot. Something that could be easily replaced but would need to be maintained. Even such a small effort was beyond help for more than 2 years and it's the primary example they use.
One thing is for sure, you don't see any of the anti-systemd people offering their help to replace the functionality that's needed. They'd rather try to force others to do it than help themselves.
Posted Nov 17, 2014 19:46 UTC (Mon)
by javispedro (guest, #83660)
[Link] (13 responses)
However,
Wait, what? There are plenty of ConsoleKit alternatives, including ConsoleKit itself (software doesn't wear out, remember?), ConsoleKit2, and the Oracle fork. They all use the same API.
Actually, what I see is GNOME warning they're about to get rid of ConsoleKit support in GDM _every other version_. The only thing that's stopped them from removing it so far is that it seems no one is actually up to the task. Please, just leave it alone; it's about 40 lines code in GDM. We'll try to figure out something when sleep inhibition stops working for a majority of programs. So far, most of them still call the session manager API because the GNOME release cycles are _way too fast_ for them.
Posted Nov 17, 2014 21:36 UTC (Mon)
by rahvin (guest, #16953)
[Link] (11 responses)
Posted Nov 17, 2014 21:44 UTC (Mon)
by mgb (guest, #3226)
[Link]
Posted Nov 17, 2014 23:03 UTC (Mon)
by javispedro (guest, #83660)
[Link]
I know that specially in the FLOSS world breaking stuff is more the norm than the exception, though. I have been bitten too many times by it and I am really dismayed at this.
However, it is Linus' stated goal that kernel -|- user space interfaces should not change much, specially non-experimental ones. There have been some mistakes here and there, but they have a track record that is better than most of the software that runs on the kernel. I fully expect that ConsoleKit will "start damaging things" much later than any other desktop stack component. Say, Bluez :) (sorry! once bitten, twice shy...)
Posted Nov 18, 2014 23:12 UTC (Tue)
by flussence (guest, #85566)
[Link]
Posted Nov 19, 2014 3:18 UTC (Wed)
by tytso (subscriber, #9993)
[Link] (7 responses)
That is, unless it depends on a freedesktop.org or systemd provided IPC interface...... then all bets are off, but that's not the kernel developers' fault, but rather because freedesktop.org and systemd developers don't seem to understand the concept of "if you export a public interface, and people start to depend on it, you must not break them."
Posted Nov 19, 2014 7:40 UTC (Wed)
by peter-b (subscriber, #66996)
[Link] (1 responses)
Hang on, what? They understand it perfectly well! All systemd's public IPC interfaces are versioned and subject to a stability promise. They're pretty enthusiastic about keeping to that stability promise too.
Posted Nov 19, 2014 14:00 UTC (Wed)
by tytso (subscriber, #9993)
[Link]
http://m.memegen.com/u7o1tk.jpg
Just recently there's been discussion about systemd-resolved (which has revived a security bug six years old because it is determined to re-invent the wheel) is going to have a new dbus-based interface, and it's going to urge applications to query DNS via this new dbus interface, and not via the standard BIND interface (either via the libresolv interface or the standard UDP to port 53). So good luck if you need to run any kind of emergency system administration repair while in single user mode, and the systemd-resolved and dbus daemons aren't runnning. And good luck if you try installing the new version of the application and it only supports the new interface.
So my main hope is that application programmers don't fall for the siren song of the systemd developers, and if they want to use the new interfaces, that they have *run-time* fallback to the existing, current interfaces. If there's something magical you can do with new interfaces, fine, maybe you'll have only the same level of functionality as what you have now (which for DNS resolution, I at least don't have any compaints). But what benefit you might have from some incompatible new dbus interface is quite beyond me.
Posted Nov 19, 2014 7:42 UTC (Wed)
by rodgerd (guest, #58896)
[Link] (3 responses)
Well, except when they patch filesystems to default to being more likely to lose data by default, eh?
Posted Nov 19, 2014 13:44 UTC (Wed)
by tytso (subscriber, #9993)
[Link] (2 responses)
Posted Nov 19, 2014 17:58 UTC (Wed)
by nix (subscriber, #2304)
[Link] (1 responses)
Posted Nov 20, 2014 18:16 UTC (Thu)
by deater (subscriber, #11746)
[Link]
I have a list of perf_event ABI breaks, but most of them only broke my test suite and not much actual deployed code so I only did a moderate amount of complaining (none of the changes were reverted).
I've had more problems from the ARM decision to drop bogomips values from /proc/cpuinfo which broke actual useful (though arguably could have been written in other, better, ways) code.
Posted Nov 19, 2014 11:57 UTC (Wed)
by PaXTeam (guest, #24616)
[Link]
has the heap-stack gap crap from Linus been reverted since?
Posted Nov 20, 2014 12:59 UTC (Thu)
by em (subscriber, #91304)
[Link]
Mh, software may not wear, but for sure if nobody maintains it new bugs get discovered and no bug gets fixed, so I can easily sympathize with the Debian GNOME team not wanting to take the blame for ConsoleKit's bugs when a better alternative exists.
ConsoleKit2 is a *very* recent development, but it's nice that someone finally picked up the ball and probably will be considered in the future (AFAIK no stable releases have been done yet, see https://github.com/ConsoleKit2/ConsoleKit2/releases ).
I was not aware of the Oracle fork, but I just don't want to think about what those people who talk about RedHat conspiracies will say when the proposed alternative is Oracle. :/
Posted Nov 17, 2014 19:04 UTC (Mon)
by BrucePerens (guest, #2510)
[Link] (1 responses)
I don't want to get into SysVInit issues, as it's irrelevant to a systemd argument. There are many alternatives to SysVInit. I preferred the way devices worked on OS/9 (The 6809 OS, not MacOS 9. This is going back to the 1980's). The root directory was a presentation of software file interfaces provided by device drivers. All of the disks were subdirectories of the root. There was no /dev and no mount, and no special files as they exist in Unix. We pretty much had everything udev gets you. And all of kernel and user mode fit in a 16-bit address space of a tiny processor without an MMU.
Posted Nov 18, 2014 9:51 UTC (Tue)
by daniels (subscriber, #16193)
[Link]
Posted Nov 17, 2014 22:42 UTC (Mon)
by nix (subscriber, #2304)
[Link] (1 responses)
As for the mounting problem, I'd guess that early userspace (the initramfs / initrd) is running mdadm --assemble --scan (or the analogous piecemeal assemblage that udev does), then mounting the real root and switching to it, and systemd is then not rerunning mdadm to recreate the /dev nodes. IIRC, it expects /dev to on a devtmpfs that is mount --move'd under the real root: perhaps your initrd isn't doing that?
Posted Nov 17, 2014 23:57 UTC (Mon)
by zlynx (guest, #2285)
[Link]
This is one of those things that sysadmins seem to have to learn from experience. I did.
Be very very careful when choosing chkconfig (or whatever SysV thing you use) startup numbers for network daemons. You need to be AFTER network init but ALSO AFTER NFS init and still BEFORE the things that need your daemon.
So, so happy that systemd just lets you declare the units that your unit uses rather than doing "guess a number, any number."
Posted Nov 17, 2014 22:44 UTC (Mon)
by jengelh (guest, #33263)
[Link]
(In case an initramfs is used -) such could happend when /dev from the initramfs does not get mounted into the realroot, just as if you would do
mount /dev/md127 /mnt; chroot /mnt /bin/sh -c "cat /proc/mounts; ls -l /dev/md127"
Posted Nov 18, 2014 0:22 UTC (Tue)
by neilbrown (subscriber, #359)
[Link] (1 responses)
Add:
to an early init script, after udev is running in the "real" root.
Part of the deeper problem is general confusion of device names. "/dev/md127" is not the name of a device. It is the name of a device-special-file, a bit like a symlink which points to the device.
So "mount" tells you that some time ago, the device pointed to by /dev/md127 was mounted on '/', but like any symlink, /dev/md127 might point to something else now, or might not exist.
Posted Nov 18, 2014 20:13 UTC (Tue)
by Wol (subscriber, #4433)
[Link]
Oddly enough, near as dammit the identical grub2 config (with a dud root= parameter) that forces me to manually tell linux that / should be md127, then boots fine (iirc it has a different problem, something to do with grub2-mkconfig, but I can't remember what. I only play with it when I get a new kernel).
Cheers,
Posted Nov 18, 2014 3:14 UTC (Tue)
by ghane (guest, #1805)
[Link] (1 responses)
I am too young to have tutored Ritchie or Pike, but I don't think "all the background processes a modern OS needs" is just "one thing" :-)
Posted Nov 18, 2014 4:07 UTC (Tue)
by bronson (subscriber, #4806)
[Link]
yet...
Posted Nov 18, 2014 8:55 UTC (Tue)
by rvfh (guest, #31018)
[Link] (1 responses)
To be honest, I agree with him here. This is why I am using Kubuntu and not Debian on my laptops/desktops.
Even the Respberry Pis use Raspbian and not plain Debian. What's the difference? I don't know, but it's not Debian.
The only computer using Debian is my NAS, and according to the docs it should not work (DNS 323 rev C).
So indeed, I think Debian is more seen as the base for Ubuntu et al. today than as 'The Universal Operating System'.
Posted Nov 18, 2014 14:42 UTC (Tue)
by mpr22 (subscriber, #60784)
[Link]
Posted Nov 17, 2014 20:32 UTC (Mon)
by tpo (subscriber, #25713)
[Link] (3 responses)
I don't want to criticize the factuality or the merit of your claims.
But the *hate* you are sowing! I just checked db.d.o whether you are a DD. You are not. How relieved I was! Please stay clear of Debian in this state of mind. Debian and the people that are leaving do not need your hate.
Already here half of the postings are from you. It is trolling. I would be hoping you could be a force of creation and not of bitter destructivness.
Please leave, take time out to look in and onto yourself, find peace. This are not your enemies. These are human, sentient beings. Kind of like you.
Posted Nov 17, 2014 22:03 UTC (Mon)
by HelloWorld (guest, #56129)
[Link] (1 responses)
Posted Nov 17, 2014 22:44 UTC (Mon)
by nix (subscriber, #2304)
[Link]
Further conclusions I leave to the reader to draw.
Posted Nov 18, 2014 5:37 UTC (Tue)
by BrucePerens (guest, #2510)
[Link]
What hate? This is called criticism. I reserve hate for much worse things.
Posted Nov 23, 2014 23:55 UTC (Sun)
by Homer (guest, #99947)
[Link] (2 responses)
Posted Nov 24, 2014 9:22 UTC (Mon)
by jezuch (subscriber, #52988)
[Link]
A death threat is *never* a joke. Even if it unambiguously is, it isn't.
This is the other problem with anti-systemd folks (the first being their extreme unwillingness to learn about the thing they criticize): the entire culture is devoid of the sense of perspective.
Posted Nov 24, 2014 17:18 UTC (Mon)
by njs (subscriber, #40338)
[Link]
It would be frankly shocking if these were the only two death threats Lennart's received, given that death threats (usually via private channels!) are absolutely standard operating procedure for the kind of internet rage machine that's set their sights on him. Here's another example of the kinds of people who are showing up to this party -- someone else ranting in the ctte channel about how systemd is a feminist plot that's oppressing him, just like how the feminists took away his basic rights like carrying "useful weaponry" and "marrying little girls": http://ix.io/aMx
Obviously this individual is not representative of everyone who opposes systemd, but claiming that Lennart is *making up* the existence of disgusting attacks is itself a pretty disgusting attack.
Posted Nov 17, 2014 15:38 UTC (Mon)
by wisl (guest, #99817)
[Link] (7 responses)
What is likely and hopefully going to happen is that systemd grows to eventually include a way to install software (hopefully via a new filesystem hierarchy and not packages) which finally replaces all the distributions.
Once distributions are finally abolished, we will have a modern platform where developers will be able to release their own applications in a few minutes to all their users rather than waiting years for distributions to pick them up.
This is of course bad for those in the Debian bureaucracy, which is why Ian Jackson et al are resisting, but good riddance!
Posted Nov 17, 2014 16:14 UTC (Mon)
by gb (subscriber, #58328)
[Link] (1 responses)
Posted Nov 17, 2014 19:07 UTC (Mon)
by BrucePerens (guest, #2510)
[Link]
Posted Nov 17, 2014 19:45 UTC (Mon)
by dlang (guest, #313)
[Link] (1 responses)
And you wonder why people aren't thrilled with this?
If you want to make the ultimate linux distro, go ahead and do so, don't try a sneak takeover over existing distros.
Different distros exist because the people who create and use them have different priorities on what they want. Trying to eliminate the differences between distros is telling the people that their preferences and priorities don't matter.
In some cases, things are the way they are due to historical accidents, and it is very reasonable for distros to cooperate and eliminate differences where they don't matter.
But the systemd vision of a future where systemd can make changes to the fundamental ways that every distro works by just updating systemd (and bundling that update with bugfixes and other changes that make it hard to ignore these policy changes) is not attractive to everyone.
Posted Nov 18, 2014 11:26 UTC (Tue)
by daniels (subscriber, #16193)
[Link]
I'm pretty sure that every distro has noticed by now.
> and it is very reasonable for distros to cooperate and eliminate differences where they don't matter
Like having voluntarily chosen to use systemd.
Posted Nov 17, 2014 20:07 UTC (Mon)
by jb.1234abcd (guest, #95827)
[Link] (2 responses)
Oh, well. There is a light in a tunnel ...
No kidding ...
https://fedorahosted.org/fpc/ticket/467
jb
Posted Nov 17, 2014 21:03 UTC (Mon)
by ebassi (subscriber, #54855)
[Link] (1 responses)
Posted Nov 17, 2014 22:46 UTC (Mon)
by nix (subscriber, #2304)
[Link]
Imagine that. Next you'll be telling me that Tollef's death threats were unjustified or something.
(what *is* it with some people. It's an *init system*, not the secret of life and death.)
Posted Nov 17, 2014 15:50 UTC (Mon)
by niner (subscriber, #26151)
[Link] (14 responses)
Even if systemd opponents have had some real arguments, they lost all credibility by not distancing themselves from those sick individuals that contribute nothing but personal attacks, conspiracy theories, threats and mumbo jumbo about philosophies.
You want to put on brakes? How about putting them on people who hurt others? Hurt people who do actual work? How about making Debian a place where people feel welcome? How about fixing Debian?
Seems much more important to me than meddling with unrelated projects and telling them what to do.
Posted Nov 17, 2014 15:59 UTC (Mon)
by gb (subscriber, #58328)
[Link] (8 responses)
Posted Nov 17, 2014 16:05 UTC (Mon)
by niner (subscriber, #26151)
[Link] (6 responses)
sociopath
So how would you call people that intimidate and threaten other people for nothing else but doing free software work? If this is not a clear indication of antisocial, lack of moral responsibility and social conscience and at times even criminal behavior, than I don't know what is.
Posted Nov 17, 2014 16:19 UTC (Mon)
by gb (subscriber, #58328)
[Link]
Posted Nov 17, 2014 16:26 UTC (Mon)
by gb (subscriber, #58328)
[Link] (4 responses)
Posted Nov 17, 2014 16:42 UTC (Mon)
by niner (subscriber, #26151)
[Link] (3 responses)
I have actually no idea, why you would think, that I have the power to push people out of society. I'm just glad that I don't have this, because I wouldn't want to bear that responsibility.
Luckily, I don't have to. Because those people are not what they are because I call them. I just call them what they are.
Posted Nov 17, 2014 17:06 UTC (Mon)
by gb (subscriber, #58328)
[Link] (2 responses)
Yes, it was you who judged that X is sociopath. And made you judgement publicly available.
-------------
The above was just an example how simple opinion may be turned out to terrible _death threat_ because your opinion is different, and you have no real, technical arguments. And L.P. in my opinion, does exactly that.
Posted Nov 17, 2014 19:01 UTC (Mon)
by niner (subscriber, #26151)
[Link] (1 responses)
What confuses me is your comment about L.P. not having "real, technical arguments". That just doesn't make any sense at all to me.
Posted Nov 17, 2014 22:08 UTC (Mon)
by HelloWorld (guest, #56129)
[Link]
Posted Nov 17, 2014 17:35 UTC (Mon)
by misc (subscriber, #73730)
[Link]
You can add the various threats made by the notorious troll Mikeeusa on Debian-devel and lklm under a fake name ( gregory smith and others ), the youtube video made by the same guy, who then start to push his hate discourse on debianusersforums.org forum ( again under another name, but saying he was banned from debian-user several time and linking his videos, and the videos linked to his soundcloud account ). He was kicked out again after being outed. And he tried to push other to act violently, as you can see on http://www.debianuserforums.org/viewforum.php?f=63 ( look for all post of sgryphon, not sure if you can read them in the banned section without opening a account ). He also tried to explain how he should be able to rape women, because the bible said so.
But as the past have show, this kind of guy do not just stop, he just stop to be public. This one was know since years ( http://geekfeminism.wikia.com/wiki/MikeeUSA ). So yeah, maybe he is behind some kind harassment of the Debian people who where in favor of systemd ( as both Joey, Russ and Tolef were kinda in favor of systemd in the end ). After the post of lennart, a few people from the gamer gate movement have started to label lennart as "social justice warrior", but this didn't result in harassement like the one faced by Zoe Quinn or Anita Sarkisian. But maybe a small part of the group did move there, as the movement start to show its limit after being dispelled again and again.
But of course, you can hide the head in the sand, and pretend this didn't happened either, and all is some kind of operation to force Debian to use systemd. Maybe all of this is about ethics in the packaging.
Posted Nov 17, 2014 16:11 UTC (Mon)
by BrucePerens (guest, #2510)
[Link] (4 responses)
The only threat I've ever received in this community is famous, so I won't repeat it here. There has never been another one. And that is through all of the stuff on Busybox, and many other things I've done in the community. And not one when I worked on the No Code issue for ham radio (which was more contentions than anything to do with systemd). What the heck makes systemd different?
Posted Nov 17, 2014 16:15 UTC (Mon)
by niner (subscriber, #26151)
[Link] (1 responses)
It explains far better than I ever could the mechanics behind the whole systemd shitstorm.
Posted Nov 20, 2014 16:14 UTC (Thu)
by fb (guest, #53265)
[Link]
Posted Nov 17, 2014 17:06 UTC (Mon)
by dakas (guest, #88146)
[Link] (1 responses)
Posted Nov 17, 2014 17:13 UTC (Mon)
by BrucePerens (guest, #2510)
[Link]
I actually got recruited to be their Open Source guru, and said "no thanks", before someone else took it and later quit with much publicity.
Posted Nov 17, 2014 15:53 UTC (Mon)
by tomegun (subscriber, #56697)
[Link] (174 responses)
systemd is developed in one git repositor, and that will not change. However, it is entirely possible to package systemd in modular packages, if that is what a distribution wants. Does this satisfy your concerns? Do you see technical issues with doing this, if so, please let us know so we can work together to sort them out.
What are these issues that cause the largest objections to systemd, and how do you suggest we solve them?
Who are you referring to as "the team that pushed it upon us", is this systemd upstream, or someone else? If you are referring to upstream, how do you feel we pushed systemd on anyone? What should we have done differently? What do you think we should be doing differently going forwards?
Cheers,
Tom
Posted Nov 17, 2014 16:41 UTC (Mon)
by BrucePerens (guest, #2510)
[Link] (173 responses)
Hi Tom, Git is a technical issue and the problems are more policy than technical. I am not sure that it matters much whether it is one repository or many, but it's odd that you start by drawing the line there rather than in other places. Why? I agree that some of technical goals of systemd are important, and difficult to get past people who are used to the Unix way of doing things. Getting the shell out of basic and formulaic system tasks is important. Configuration is an unsolved problem: the vast number of diffferent text file configuration formats is holding us back, while repository implementations so far have been less than impressive. The direction that Reiser was going with this: file-per-parameter, was a good one. Too bad he couldn't stick to programming. I think the major change necessary is to make the big collection of things that currently fit under the systemd flag more ala carte. For example one complaint I see is the format of logging, and that this format isn't optional. We had a logging API before systemd which should have been able to deal with that, at least with extensions. Udev is now part of the project? And there is serious talk about it including a package system? And nobody sees anything wrong with this? One of my biggest achievements with Debian was to hand the "base system" (the collection of packages needed to bring up a system before it could self-host package selection and installation) to multiple maintainers. And it worked, and as far as I know that was the first time anything like it was tried. Systemd sort of reverses that as it is presently structured. Regarding the team pushing it, it's pretty clear that the word "cabal" can be justly applied. No, you don't get to determine the entire architecture of the Linux desktop (or non-desktop) in a relatively small group with little oversight. Not without people eventually deciding to push back. And Lennart "I am so abused" Pottering hasn't been a credit to your project in blaming everyone else. Linus has been pretty clearly unhappy, but I'm surprised he hasn't gone further. He is perfectly capable of rewriting your world in a month, remember git?
Posted Nov 17, 2014 17:10 UTC (Mon)
by daniels (subscriber, #16193)
[Link]
Very classy.
Posted Nov 17, 2014 17:14 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (88 responses)
Let me repeat - we did NOT have a standard logging format or suite of tools that can completely replace journald.
All other systemd components are completely optional. They are basically just separate projects that live in systemd's repository. You can even replace udev with something like a static /dev tree!
> No, you don't get to determine the entire architecture of the Linux desktop (or non-desktop) in a relatively small group with little oversight. Not without people eventually deciding to push back.
Perhaps you want to split its repository just to create more headaches for its developers?
Posted Nov 17, 2014 17:48 UTC (Mon)
by BrucePerens (guest, #2510)
[Link] (73 responses)
I would like to balkanize the entire project. Splitting repositories is not important, but splitting development teams into organizationally separate projects is. I don't think you are going to get to "plays well with others" without doing this.
Posted Nov 17, 2014 17:50 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (51 responses)
Well, that describes Unixes pretty well, it seems.
Posted Nov 17, 2014 17:56 UTC (Mon)
by BrucePerens (guest, #2510)
[Link] (50 responses)
For the sake of modular isolation and the improvement to the global architecture that will come from it. Consider that the Debian base system has individual maintainers (again, it's the first time I know of that this was done). That has been a strength for the project.
Posted Nov 17, 2014 18:01 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (49 responses)
Yeah, a really classy behavior. Utterly characteristic of all those nice Unix wars in 80-s.
Posted Nov 17, 2014 18:33 UTC (Mon)
by rahvin (guest, #16953)
[Link] (48 responses)
Posted Nov 17, 2014 19:15 UTC (Mon)
by javispedro (guest, #83660)
[Link] (47 responses)
For example, one may favor the "status quo", that is: sysvinit + existing Debian init scripts. Maintaining this status quo hardly requires more work. Software doesn't wear out. If the Linux kernel can stop deprecating interfaces ConsoleKit shall keep working for the foreseeable future.
Others may favor using other init systems, such as openrc, initng, etc. There are init systems out there that are more featured than systemd -- and have been for decades.
I don't find Gnome depending more and more on these interfaces bad, specially because it means they can deprecate the messy backends in e.g. gnome-system-tools, and concentrate their efforts on the UI parts. I just don't get why everything from time syncing to motd printing has to depend on a specific init daemon, specially when the g-s-t backends didn't. Or, in fact, when virtually nothing in the entire system depended on the init process, as someone who used to run initng can attest.
Second and also quite importantly, "other people working for me" is exactly what everyone wants. I don't see anything wrong with this. This is the reason there are _users_ of open source at all!
Posted Nov 17, 2014 21:45 UTC (Mon)
by vonbrand (subscriber, #4458)
[Link] (43 responses)
Pray tell where those "init systems out there that are more featured than systemd" have been hiding for those "decades". The crowd who started systemd did look around at the available options (not just Unixy ones, mind you), and found them all lacking one way or the other. I'm a Fedora user, and I do remember the pain of (sort of) migrating to upstart, which in the end never was more than a bit better sysvinit clone in actual use. When systemd came around, things got changed/simplified/streamlined, and dependencies started working as required. Yes, again migration pains. But very much worth it, IMNSHO. I do have my sack full of SysV war stories (both on Solaris and then on Linux), too many and too painful. Good riddance.
Posted Nov 17, 2014 22:22 UTC (Mon)
by johannbg (guest, #65743)
[Link] (1 responses)
In fact I have only seen one distribution actually implement and use upstart and that distribution is Chrome/Chromium OS so Fedora never migrated to upstart it just replaced it's init system [1] and to my account most if not all other distributions did not do any migration or integration work to upstart either so I have hard time understanding what kind of migration pain you are supposed to have experienced because such work never took place.
Distribution just continued to use the existing legacy sysv initscripts.
Posted Nov 17, 2014 23:52 UTC (Mon)
by jspaleta (subscriber, #50639)
[Link]
Upstart was fine a a strict sysv replacement relying on backwards compat with sysv. And if you have a small set of deterministic services to run and can cultivate well groomed job files for those services it works well there. That's why it works fine for the nominal ubuntu desktop case or the ChromeOS case..especially the ChromeOS case as its not a general purpose OS that is going to be running random services really.
But as soon as you started trying to work with the native jobs concept across a general purpose server, it became problematic very quickly. Ubuntu found this out as soon as they started trying to go native for their server use cases. I really do think Steve was being sincere when he said he expected systemd integration to be fragile back in the Feb discussion on the init switch in debian. Based on the fragility of upstart and how much work it took the Ubuntu engineering team to work around its cornercase brokenness I can understand why he would expect any init system switch to result in terrible cornercase problems. Even in the UDS video on systemd transition plans that's still the expressed expectation he has moving forward with systemd in Ubuntu. Hopefully systemd surpasses the low expectations upstart set for him and systemd native units will integrate much more smoothly for Ubuntu server than upstart jobs did and the Ubuntu eng team will finally get on board and learn to love the bomb, err I mean systemd.
You may disagree with this, but I think Fedora's staged approach to both upstart and systemd switch-over was very important. For systemd's case it may look like it was over conservative in hindsight, because systemd native units do work quite well. But I think the staged integration in a distros to date have actually helped to keep the overall integration pain-level down for those distributions. First focus on early boot, then on transitioning services (which I believe you were a big part of, and a hearty thanks for that work), and then logind integration.
In most distros integration of systemd has been primarily "up the stack". Where early boot and sysv compat init handling were worked on first and then native service integration and then logind integration up into the UI late in the integration process after the early boot was stabilized.
I think part of the problem right now with Debian is that the switch to default _looks_ like integration "all over the stack at once." And I think it just going to be a more painful process for them as a result. And Logind's API complicates things a bit as well now. Taking an explicit "up the stack" integration approach in Debain would mean Debian developers would need to choose to hold off on requiring logind until systemd was integrated well lower down in the stack. But I'm really not sure there's enough good will left for that sort of plan to work as a consensus compromise to move things forward in a way that keeps disruption manageable. I think certain ctte member(s) have been so proactive in short-circuiting normal maintainer interactions that its going to be hard for anyone to broker an agreement to focus on systemd integration instead of actively fighting against it.
-jef
Posted Nov 17, 2014 22:24 UTC (Mon)
by javispedro (guest, #83660)
[Link] (40 responses)
Funnily, support for event based startup was introduced as a plugin right after upstart was released. Upstart was seen as the new shiny thing then, for some reason. The main author behind it had made a post arguing how "dependency based startup was bad" -- and virtually every major distro was blindly agreeing and embracing upstart. I was biting my tongue because I hated upstart's "we fake dependencies with start/stop events" model. That model however matched with what (back then) was on Fedora's "future ideas" wiki. I still remember ideas like starting Cups only when the print-jobs-coming-in event fired. Wish I knew were those wiki pages were...
Apart from initng, which basically was designed to have as much features as possible (and was readily ignored because of the complexity it introduced into pid1, despite being much smaller than what systemd is now) , other init systems targeted reliability and small target area, in fact moving most of the process creation and supervision out of pid 1 (e.g. runit, perp, etc.), something systemd authors don't really want to do (for some reason).
I'm sure that you'll find some feature that only systemd implements (e.g. it syncs time via NTP!); however my point is that those systems also did plenty of innovation in the startup area, and that I find no reason to believe systemd is objectively better than any of them.
Posted Nov 17, 2014 23:16 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (38 responses)
Posted Nov 17, 2014 23:29 UTC (Mon)
by javispedro (guest, #83660)
[Link] (37 responses)
- Socket activation, compatible with systemd's, was implemented in a few lines of ruby in https://felipec.wordpress.com/tag/finit/ and does not seem to require any specific functionality only available to pid 1. In fact I could also do an initng module for it. Hm.. There, I already have work for this weekend :D
- Cgroup based process confinement is also implemented in finit above, although I am not sure how complete that implementation is. openRC has a compatible implementation though (it boots and terminates GDM cleanly, at least), which does not run from pid 1 either (though shit happens if you run any other program using cgroups, at least until something like cgmanager appears).
Posted Nov 18, 2014 0:03 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link]
What makes systemd objectively better is that it has actually went through with these ideas and built a coherent system.
Posted Nov 18, 2014 0:42 UTC (Tue)
by jspaleta (subscriber, #50639)
[Link] (3 responses)
I'll quote http://lwn.net/Articles/575793/
"Then, there is the issue of cyclic deps: a good PID 1 knows at any time securely and reliably of each process to which service it belongs. That's easy to do with cgroups. However, if cgroup management is done outside of PID1 in a different process, then PID 1 suddenly becomes a client to that other process, while that other process is also a managed process PID 1 wants to use cgroups to manage for. To start and manage that other daemon that will allow you to deal with cgroups you need cgroups in the first place. And that's just broken."
I'm not convinced that openrc and cgmanager like cgroup management concept done outside of pid=1 covers the implications of being a child of PID=1. Seems like a significant corner-case. I think we are going to find that for these approaches..shit is going to continue to happen...as you put it.
And finit sort of cheats a little with the cgroups stuff making use of autogrouping as configured with the kernel, not really doing the same level of management complexity that systemd or cgmanager does in support of containers or logind sessions. Though I'd love to see finit develop to the point of supporting cgroup manipulation to the point where it could replace systemd-logind. That would be fascinating.
-jef
Posted Nov 18, 2014 11:23 UTC (Tue)
by javispedro (guest, #83660)
[Link]
The traditional counterargument is "i don't see any problem starting cgmanager after init, i don't see much
I still believe you certainly can. I just can't see nothing wrong with doing this sv-style (have a different process for every monitoring group; sending signals to this process controls the entire group; init only knows about the monitoring process). In fact it seems to me it would reduce complexity, and even allow the sv-process to be used by other init systems (including sysvinit -- UNIX way!). This is not helped by the current cgroups interfaces, though.
Posted Nov 23, 2014 10:42 UTC (Sun)
by makomk (guest, #51493)
[Link] (1 responses)
Posted Nov 23, 2014 11:31 UTC (Sun)
by mathstuf (subscriber, #69389)
[Link]
> the only reason Gnome has problems is because they assumed systemd would clean the other ones up, failed to do so themselves, and then broke if the child processes were still running.)
Sounds like a bug to me.
Posted Nov 18, 2014 5:53 UTC (Tue)
by BrucePerens (guest, #2510)
[Link] (30 responses)
What I really miss about Unix is that almost all of the programs were small enough for one person to understand and had few dependencies. If anyone carries this tradition on today, it's the rubyists. It's not only amazing what they do, it's amazing what you can do.
Posted Nov 18, 2014 8:38 UTC (Tue)
by jezuch (subscriber, #52988)
[Link] (23 responses)
I know. My family drove a Trabant for many years. What I really miss about Trabant is almost all parts were simple enough that even a kid like myself could recognize them and understand how they worked. Too bad that we are forced to drive all these bloated, complicated cars of today. Sure, they are much safer, much more efficient etc. but who needs that? Trabant was simple, did one thing and did it well and adhered to the principles of People's Democratic Republic of Germany. The newer cars were forced on us, have in-built infotainment, proximity sensors and other things that we could just as well stitch on our Trabant and which worked just as well before the devilous car companies borged them and integrated them into one, consistent package. Oh, the humanity!!!
More seriously, there were at least two articles and/or presentations about "where the bloat comes from", one I think was by Matthew Garrett, but I couldn't find them. They Explain very nicely that the "bloat" and "complexity" the greybeards like to rant about is actually stuff that's indispensable for one person or another. Your Unix is completely unusable to a person who had the chance to use a modern system. Your nostalgia for the times where "men were men and wrote their own device drivers" is touching, but it's time to bring yourself to the 21st century already.
Posted Nov 18, 2014 8:40 UTC (Tue)
by mjg59 (subscriber, #23239)
[Link] (1 responses)
Posted Nov 18, 2014 11:10 UTC (Tue)
by javispedro (guest, #83660)
[Link] (20 responses)
Isn't that the UNIX spirit? Simple programs?
In fact, it just happens that the gazillion-line init script implemented many features (such as config file checking) that the systemd unit file happily ignores. I don't see this as a bad thing; as a user of alternative init systems I'm already used to this. The traditional init files have gotten a ton of cruft, and the fact that systemd people happily run their systems without missing this functionality proves that no one cares about the functionality implemented by that cruft.
Or maybe in a few years systemd unit files will have absorbed all that complexity in order to "bring them to the 21st century", having grown to ridiculous sizes, and we'll all be waiting for systemd+1.
In general, I think it's correct to complain about complexity and bloat, though. It should be the goal of every software engineer to reduce complexity, not to increase it. We have several strategies to do this. One is adding abstraction layers, which is what for example what systemd unit files do.
I find it dismaying that some of the arguments pointed in this thread boils down to "software is complex just get done with it" and "Linux is monolithic too / Linux sucks too, so why can't systemd be monolithic / suck too?". Everyone does poor software from time to time, yes; since when this has started to become the accepted norm?
Posted Nov 18, 2014 14:27 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (10 responses)
What you miss is that those features are (mis)-implemented over and over again in gazillions of init scripts.
But those features ARE implemented - ONCE - in systemd itself. So if a fault is found it only needs to be fixed ONCE in ONE .c file, not thousands of times across untold variants of hundreds of different init scripts.
Look at that bug in Cyberax's bind script - which is STILL out there across multiple distros (and probably across hundreds of packages which did a blind copy-n-paste from bind's script, or wherever bind got it from ...)
Cheers,
Posted Nov 18, 2014 14:55 UTC (Tue)
by javispedro (guest, #83660)
[Link] (9 responses)
But this is not what I meant; I meant $DAEMON specific functionality such as "config file checking" (e.g. bombing out early if the config file does not exists, etc.). There is indeed a lot of bookkeeping that used to be done in every init script (tmpfiles is a good example) that is now done in a declarative way by systemd; but when you compare Fedora's older 300-line sysvinit scripts to the new 10-line systemd scripts, most of the time is because you're actually dropping functionality.
Posted Nov 18, 2014 18:32 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (8 responses)
For example, you want to run BIND in a chroot? You can do it the hard way with initscripts: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/n...
Or you can add _one_ _line_ to unit file telling systemd to run the daemon in a namespace.
You want to run a daemon in clean environment without access to /home and with limited /dev access? Sure, here are another two lines in the unit file or about 100 more lines in a classic initscript.
Posted Nov 18, 2014 22:27 UTC (Tue)
by javispedro (guest, #83660)
[Link] (7 responses)
> For example, you want to run BIND in a chroot? You can do it the hard way with initscripts: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/n...
OR you can do it the easy way with initscripts:
Yes, it's still 100 lines long. Out of those, around 20 are actually related to setting up the chroot, and could be trivially be simplified in a declarative fashion (either with systemd or by extending openrc with the functionality). Namely, making the temporary dirs, setting up the bind mounts, and copying the usual NIS files into /etc.
The rest of lines are actually extra functionality that a simplified initscript would probably omit, such as checking paths for valid permissions, parsing configuration files to _automagically_ figure out which holes need to be punched in the container/chroot (which systemd unit files do this?), checking whether the configuration files exist, etc. Which kind of proves my point.
> Sure, here are another two lines in the unit file or about 100 more lines in a classic initscript.
Anything else you'd like to add to functions.sh? *
* Yes, I know nothing would be ever added to functions.sh in Gentoo; this is just a device I'm using to explain it. If you want to nitpick, assume $SOURCED_SHELL_SCRIPT.sh.
If initscript and daemon writers are suddenly starting to make all the work necessary for running most services inside containers (which is not "two lines" only; for most services you need to manually specify where the holes are), then all the better; specially so if this work is encouraged by systemd developers. I don't see how this makes systemd better in any objective way, though.
Posted Nov 18, 2014 23:55 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (6 responses)
> Namely, making the temporary dirs, setting up the bind mounts, and copying the usual NIS files into /etc.
> The rest of lines are actually extra functionality that a simplified initscript would probably omit, such as checking paths for valid permissions, parsing configuration files to _automagically_ figure out which holes need to be punched in the container/chroot (which systemd unit files do this?)
> checking whether the configuration files exist, etc. Which kind of proves my point.
The systemd unit in Fedora does it: http://pkgs.fedoraproject.org/cgit/bind.git/tree/named.se...
> Since you used Gentoo as an example, it should be noted that only 4 initscripts actually chroot on their own; containers and chroots are hardly used in Gentoo to confine daemons, but rather SELinux (see hardened Gentoo).
> * Yes, I know nothing would be ever added to functions.sh in Gentoo; this is just a device I'm using to explain it. If you want to nitpick, assume $SOURCED_SHELL_SCRIPT.sh.
Posted Nov 19, 2014 8:33 UTC (Wed)
by javispedro (guest, #83660)
[Link] (5 responses)
Yeah, it is not easy to do in a generic way (you need to know which holes each service requires).
As said, BIND is hardly a good example. The Fedora in it script for it is at least 160 lines long if you include all the non-upstreamed scripts it calls.
Just by moving the two _{,un}mount Bash functions to a common sourced file you'd already shorten the length of both Gentoo and Fedora scripts quite a bit. Doesn't sound like rocket science and doesn't require to code anything new in C.
> Systemd can open the requisite sockets and pass them to BIND. Can your initscripts do this?
> The systemd unit in Fedora does it: http://pkgs.fedoraproject.org/cgit/bind.git/tree/named.se...
The dhcpd script in Gentoo which I also mentioned also parses the config file in order to find out which paths it needs to check whether permissions are OK are or not. The Fedora initscript for dhcpd doesn't do any of this and assumes you've written your sysconfig file carefully.
> So how do you run a BIND with SELinux hardening?
> sysv advocates keep telling that "it's just a script library away" without ever actually trying to do it.
Posted Nov 19, 2014 8:40 UTC (Wed)
by peter-b (subscriber, #66996)
[Link] (3 responses)
How on earth is this relevant to systemd? It's never called if named is running as a systemd service.
>> The systemd unit in Fedora does it: http://pkgs.fedoraproject.org/cgit/bind.git/tree/named.se...
> The Gentoo init script clearly clearly does some checks to warn the user if the configuration is inconsistent e.g. libgost enabled but not built. The Fedora unit file doesn't do it.
Yes it quite clearly does:
> ExecStartPre=/usr/sbin/named-checkconf -z /etc/named.conf
>> So how do you run a BIND with SELinux hardening?
How the heck is that irrelevant?
Posted Nov 19, 2014 9:02 UTC (Wed)
by javispedro (guest, #83660)
[Link] (2 responses)
The Gentoo initscript that has been mentioned above chroots BIND. The equivalent Fedora systemd unit file that also chroots is called chroot-named.service . That service unit file calls setup-named-chroot.sh indirectly via another service file called named-setup-chroot.service . The complexity of this two-initscript monster turns out to be comparable to the original Gentoo script despite losing functionality.
But again and again BIND is a bad example; I don't know of any init system doing great here.
> Yes it quite clearly does
> How the heck is that irrelevant?
Posted Nov 19, 2014 20:32 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
> But again and again BIND is a bad example; I don't know of any init system doing great here.
> What has "how to do SELinux labeling properly" got to do with init systems?
Posted Nov 19, 2014 22:23 UTC (Wed)
by javispedro (guest, #83660)
[Link]
Maybe we need a different example. There are some 3 line initscripts in Gentoo we could use as a starting point.
This feature-by-feature discussion is pointless. The point is that systemd is NOT objectively better than other init systems. It does some great things and it would be stupid to ignore those. Other init systems also DO abstract features, allowing more concise and declarative init scripts, and have done so for years or even a decade. We believe these designs are _subjectively_ more interesting (e.g. shell scripts that can be optionally sourced vs an all-knowing giant daemon that implements all kinds of settings togglable via .ini/.unit files is a _personal_ preference). systemd is, to put it simply, making our work harder by deciding to integrate a bunch of unrelated functionality that is becoming harder and harder to extricate from systemd itself. And all of this for no good reason. We had working NTP clients that did not need to integrate into the init system before. That's the only reason I complain about systemd. But we're trying to improve things.
> Systemd does great. It does not NEED a chroot at all because it can use namespacing.
> If you start BIND by doing "/etc/init.d/named start" then its environment is contaminated with your security labels
Posted Nov 19, 2014 20:42 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link]
> The Gentoo init script clearly clearly does some checks to warn the user if the configuration is inconsistent e.g. libgost enabled but not built. The Fedora unit file doesn't do it.
> Irrelevant.
> Yes, when we try to remove functionality/choice from init scripts, we get flamed (in a bug report or _not_), and therefore we're forced to revert to the complex, buggy, and old init scripts. This is part of what's happening here to systemd developers.
Posted Nov 19, 2014 8:32 UTC (Wed)
by jezuch (subscriber, #52988)
[Link] (8 responses)
I know, I'm a software engineer and before I add something to a program, I refactor it without remorse until adding that thing I was about to add is nice and simple. But still, the inevitable fact is that the solutions are complex because the problems are complex [ignoring pathological cases, of course]. With systemd the complexity is moved to the "engine" so instead of complex solutions for each individual problem we have a complex solution to a common problem so that the individual problems can have a simple solution. I think you can safely call that an "abstraction layer" :)
Posted Nov 19, 2014 18:36 UTC (Wed)
by jb.1234abcd (guest, #95827)
[Link] (7 responses)
Well, the smile is right :-)
I think you should be a bit more sceptical about systemd and its devs.
Now let me explain one more time, in case you and other LWN posters missed it.
These are excerpts of my posts regarding systemd.
You can start with the background on the socket activation:
Then you hit the post that made me respond to you:
So, you have to repeat the same misguided mechanism for handling services
This is problematic on various grounds:
This is an example of how misunderstanding and mistakes made in domains analysis and modeling phases (building abstraction layers) lead to mistakes in programming tools (constructs) selections and implementation phase. It is a domino effect.
By systemd dev's own words, systemd is to be a *core component of an operating system*, an init sys and much, much more (systemd-resolved was already discussed here and alsewhere ..., other systemd-*d goodies will be in due time, I hope).
I think it is time for leadership of Debian project to make some hard
jb
Posted Nov 19, 2014 19:07 UTC (Wed)
by vonbrand (subscriber, #4458)
[Link] (6 responses)
I'd very much prefer having one well-scrutinized and maintained version of the code doing the different dances for daemon use-cases (where they really are different in setting the sockets up) instead of having a gazillion half-baked snippets in all sorts of random packages scattered all over the Internet. Exactly as I don't like the thousand-line "shell libraries" used by several-hundred shell line "service files" duplicating all sort of very tricky code, and the exacting dance forced on daemons to get rid of their inherited environment. Yes, I've tried (on Solaris, Red Hat, and Fedora, and other SysV-ish systems I forget about) to make enough sense of it all to fix some mistery or create my own script. I still shudder. BTW, your argument works exactly the same against having one libc, or any other basic infrastructure code. Even the Linux kernel itself. That systemd isn't packaged up as a library doesn't mean it's purpose isn't offering common code/services to a variety of users in a convenient, safe way.
Posted Nov 19, 2014 19:32 UTC (Wed)
by smurf (subscriber, #17840)
[Link] (5 responses)
NB: … doesn't mean *its purpose …
Posted Nov 21, 2014 12:26 UTC (Fri)
by jezuch (subscriber, #52988)
[Link] (4 responses)
And they're free to do that, and if something breaks with kFreeBSD or HURD, bugs are reported and (supposedly) fixed - even though 99,9% of the project doesn't give a darn about these kernels. So even if sysvinit becomes a HURD of init systems in Debian, I expect that people interested in running it (and I fully expect that there will be *much* more of them than those running HURD) will file bug reports when something breaks and these bugs will be (supposedly) fixed. That's why, in my opinion, so many DDs voted "no GR needed" in the recent GR, and how I would've voted if I was a DD instead of a mere user.
Posted Nov 21, 2014 13:15 UTC (Fri)
by Zack (guest, #37335)
[Link] (3 responses)
Seeing how there's more than 1 developer running it, that's hyperbole. And just because DDs are not running it, that doesn't imply they don't give a damn about it.
It's also not about extending sysvinit's lifespan indefinitely. It's about Jessie+1 (or Jessie+n), when another init is presented (let's say OpenRC) which says: this init works well with and without cgroups enabled , it doesn't depend on kdbus but can make use of it, it runs on all Debian kernels (which OpenRC already does), and it's actually in FreeBSD's ports as a viable alternative. In short: it's the init Debian deserves!
Only to by met with: "So how good is it with DNS resolution?"
Posted Nov 21, 2014 14:18 UTC (Fri)
by smurf (subscriber, #17840)
[Link]
I'd reserve judgment on resolved anyway. It's strictly work in progress at this time. Lennart's grumpiness nonwithstanding, hardening a DNS client implementation is not the very first thing you do when implementing it, so calling "CVE" on it really is out of line.
Anyway, that's not the problem. The problem is that sitting in a hotel room with a VPN tunnel to $HOME active works perfectly EXCEPT FOR DNS (and having more than one tunnel up is strictly worse). The systemd people are the only ones who actually *do* something about this problem. Instead of, say, telling other people that their approach is misguided.
The dbus-based approach may well be wrong, but even if systemd's solution ends up being broken we'll have learned something about the problem and can do better next time, just as systemd learned from upstart's mistakes.
The true fiasco seems to be that it seems to be impossible for some people to write critical comments about anything systemd-ish without derogatory side remarks. No wonder these get ignored. I would, too.
Posted Nov 22, 2014 14:44 UTC (Sat)
by mpr22 (subscriber, #60784)
[Link] (1 responses)
Conveniently, people have actually looked at the task of creating independent reimplementations of "upper" portions of the systemd suite and declared it feasible. After all, from the perspective of programs using systemd-logind or systemd-resolved, those things aren't programs; they're D-Bus interfaces.
Posted Nov 23, 2014 10:54 UTC (Sun)
by makomk (guest, #51493)
[Link]
Posted Nov 18, 2014 12:17 UTC (Tue)
by ebassi (subscriber, #54855)
[Link] (5 responses)
few dependencies? ruby? you mean the ton of gems that go out of sync between themselves and the language, and do so with such frequency that everyone needs to copy them into each deployment and never update anything ever again? what's next? node.js modules being near in spirit to the Unix philosophy, when you need to depend on half of github in terms of half-released, seldomly-tested npm modules? seriously: if I didn't know better, I'd say that you're heavily trolling, instead of just being backed in a corner spouting nonsense because you're simply not informed.
Posted Nov 18, 2014 14:18 UTC (Tue)
by smurf (subscriber, #17840)
[Link] (4 responses)
Node … don't forget node's inability to do sensible dependency management. A trivial project of min has *15* copies of lodash.js installed (mostly the same version, but one is v1 only, so the whole mess cannot be cleaned up). Node is OK for auto-building the static pieces of websites, and great for automated site tests, but I wouldn't let the live Internet touch it. Ever.
Posted Nov 18, 2014 19:07 UTC (Tue)
by rodgerd (guest, #58896)
[Link] (3 responses)
Posted Nov 18, 2014 23:05 UTC (Tue)
by vonbrand (subscriber, #4458)
[Link] (2 responses)
Perl got started mostly as a "home away from home" (i.e., unixy syntax/tools on non-native platforms, or severely crippled Unices).
Posted Nov 19, 2014 0:31 UTC (Wed)
by rodgerd (guest, #58896)
[Link] (1 responses)
"Initially designed as a glue language for the UNIX operating system..."
"...to program shell portably, you have to remember the syntax for each operating system's version of each command, and somehow find the lowest common denominator that (you hope) works everywhere."
Not much to do with a "home away from home on non-Unix systems." Rather a lot to do with smoothing out the pain of working with the army of little untilities that are all about choice.
Posted Nov 19, 2014 17:46 UTC (Wed)
by nix (subscriber, #2304)
[Link]
We are much better off than *that*.
Posted Nov 21, 2014 14:15 UTC (Fri)
by smurf (subscriber, #17840)
[Link]
finit is a nice toy which is certainly fun to play with, but it's still a toy. You don't get proper dependency management (sorry, but my system MUST NOT start postgres until the database is mounted, and it MUST NOT run the application server until the database accepts connections), you don't have coherent logging, you don't get a way to cleanly shut it all down again, you don't have any security features. And so on.
A toy implementation only proves that toy implementations are easy.
Posted Nov 18, 2014 2:11 UTC (Tue)
by jspaleta (subscriber, #50639)
[Link]
And its interesting that initng was packaged from Debian for a few years and then pulled out of the repo. I'm sort of surprised anyone is still using it since it fell out of the deb repo.
-jef
Posted Nov 17, 2014 21:57 UTC (Mon)
by rahvin (guest, #16953)
[Link] (2 responses)
Posted Nov 17, 2014 22:40 UTC (Mon)
by javispedro (guest, #83660)
[Link]
It is Linus's stated goal that the kernel will keep a _stable ABI_. X11 has kept a stable API for _decades_. Most of the software world doesn't break their interfaces every few months, not even Gnome. I don't think my assertion is unreasonable in any way. Do you really expect your software to break every time you update the kernel?
> So the solution is to just stop changing the kernel! How simple. Why don't you post to lkml and tell them to just stop changing things. I'm sure they'll be happy to hear you speak for everyone.
http://en.wikipedia.org/wiki/Linux_kernel_interfaces
> Prove it.
See other replies.
> Why don't you go to the mailing list and ask them? Why not offer your help to make it happen.
I did not start it, but I have helped make it happen (on my distro at least): it's called systemd-shim (/openrc-settingsd). Systemd obviously wants nothing to do with this -- they have this "coreOS" agenda, after all. They haven't been unfriendly, though. And to be honest I cannot blame any specific person for the "quirky" design choices that have led systemd to engulf such diverse functionality.
I feel as if the following broken syllogism had suddenly become accepted as fact: "This stuff has to be done in user space. Systemd is user space. Therefore, this stuff must be implemented in systemd." People who say "wait a second" to the above logic get branded as "anti-systemd trolls".
> I don't want anyone working for me, speak for yourself. I graciously accept their work and support the community of free software because I believe it's the right thing to do and I would never ever suggest that these volunteer developers owe me anything. That is the difference between you and me.
I don't think I explained myself correctly. I do not want to imply that anyone owes me anything, because I am the first one that enjoys the freedom to "just walk away" from development work. Yet, it is clear that I and everyone who uses any software wants people to work for them. Otherwise we wouldn't be using the software at all; everyone would be making their own. Semantics, either way.
Posted Nov 22, 2014 4:18 UTC (Sat)
by zuki (subscriber, #41808)
[Link]
> Why don't you go to the mailing list and ask them?
No need to involve the mailing list, systemd-localed should run just fine stand-alone. Apart from sd_notify() messages which are optional, it does not communicate with PID 1.
Compilation is a separate issue: it can only be compiled as part of the systemd tree. But you are free to throw away the rest.
Posted Nov 17, 2014 17:54 UTC (Mon)
by tomegun (subscriber, #56697)
[Link] (9 responses)
Posted Nov 17, 2014 18:00 UTC (Mon)
by BrucePerens (guest, #2510)
[Link] (8 responses)
It's the entire premise of an entire new universe of APIs provided by a single project upon which the desktop is highly dependent and for which there are no alternatives. I would have you go back and solve one problem at a time and sell one solution at a time to the community. Consider why Linus has been loath to accept patches that change a broad swath of the system rather than a single subsystem.
Posted Nov 17, 2014 18:14 UTC (Mon)
by mezcalero (subscriber, #45103)
[Link] (3 responses)
Lennart
Posted Nov 17, 2014 19:39 UTC (Mon)
by BrucePerens (guest, #2510)
[Link] (2 responses)
But you didn't sell it one problem at a time. And as a result people look at your vast collection of solutions and are loath to accept the whole thing where they might well have taken it a piece at a time.
Posted Nov 17, 2014 19:49 UTC (Mon)
by niner (subscriber, #26151)
[Link]
Why haven't you said so in the first place? Your previous comments on this were thoroughly confusing people into thinking that you were nagging about systemd without reason.
Posted Nov 17, 2014 21:32 UTC (Mon)
by mezcalero (subscriber, #45103)
[Link]
of course we sold it one idea at a time. We posted quite a number of Fedora features over the 4 years, and got them individually agreed to by FESCO (which is Fedora's version of Debian's CTTE more or less). We filed a number of bugs to FPC (the Fedora Packaging Committee) and so on.
We might not have sold systemd and its individual features to Debian one-at-a-time but that's mostly because I am only peripherally involved with Debian. I know the Debian systemd maintainers from conferences, and we trust them enough to give them upstream commit access, and beyond that I did one talk at DebConf in Switzerland, and nothing else. I have not "sold" systemd to Debian at all really, because Debian is not my own project. You will not find any mail of me to the Debian mailing lists.
I of course enjoy if Debian adopts systemd, and I welcome any cooperation with Debian, but it's really not that we dumped things on Debian, but it's Debian which decided to pick it up.
Lennart
Posted Nov 17, 2014 18:47 UTC (Mon)
by Wol (subscriber, #4433)
[Link]
Isn't this, actually, a pretty good description of the linux kernel? After all, it's a lot more than Posix now (and has always preferred engineering soundness over standards silliness :-)
Cheers,
Posted Nov 17, 2014 19:45 UTC (Mon)
by smurf (subscriber, #17840)
[Link]
What exactly is splitting up the systemd git repo into separate pieces going to accomplish, other than satisfy religious beliefs and make coordinated updates (be it extending an API, switching to kdbus, fixing a co-dependent bug) a whole damn lot harder?
Posted Nov 17, 2014 20:43 UTC (Mon)
by tomegun (subscriber, #56697)
[Link]
Adopting systemd does not mean you have to adopt all of its components at the same time. They can be enabled and/or packaged separately, and each one evaluated on its merits.
What am I missing?
Posted Nov 17, 2014 22:53 UTC (Mon)
by nix (subscriber, #2304)
[Link]
Posted Nov 17, 2014 18:04 UTC (Mon)
by mezcalero (subscriber, #45103)
[Link] (10 responses)
Have you ever engaged with the systemd community? I am pretty sure you haven't, at least I never saw your name on any mail to the ML or any bug report.
Lennart
Posted Nov 17, 2014 19:49 UTC (Mon)
by BrucePerens (guest, #2510)
[Link] (9 responses)
Not playing well with others is mostly an issue of the interdependence of the various modules. This might have been OK if they were introduced to distributions one subsystem at a time. That would have taken longer, but IMO would have resulted in improvement. It is natural that when they are all introduced at once they would be taken as a forceful push. Making such a large change in only 4 years is probably too ambitious. Similar changes (like the GNOME 3 debacle) have been met with as much push-back. Over the past two years I have been working on the Whitebox Open Hardware project and Algoram Digital Voice Server, see algoram.com . And FreeDV and codec2, see codec2.org . Thus I have not corresponded with systemd developers. We all have our individual projects.
Posted Nov 17, 2014 21:23 UTC (Mon)
by jwarnica (subscriber, #27492)
[Link] (4 responses)
But it grew organically, and others that have been migrating with it have faced only small, incremental, changes.
Debian has, I suppose, the option to disable most things at compile time "now", and replay this slow growth that everyone else has been doing along the way.
(Which isn't a jab that Debian should have gotten on board back whenever, desirability aside, clearly there is a point where things go from not-stable to stable, and when its best to schedule in even very small changes, let alone big ones to the entire project)
Posted Nov 18, 2014 9:37 UTC (Tue)
by micka (subscriber, #38720)
[Link] (3 responses)
Except "please don't break my computer". It relies on systemd to boot since years, I don't want to rediscover the hard way all the project history ;)
Posted Nov 18, 2014 15:57 UTC (Tue)
by dlang (guest, #313)
[Link] (2 responses)
What people are objecting to is systemd becoming mandatory and loosing the option of not using it.
Posted Nov 18, 2014 17:29 UTC (Tue)
by micka (subscriber, #38720)
[Link] (1 responses)
I was just pointing out (with a failed attempt of light humour) that the base of already installed systemd computer could experience problems if existing functionality was removed (even if it's to be added back later).
Posted Nov 18, 2014 17:57 UTC (Tue)
by dlang (guest, #313)
[Link]
fair enough
> I was just pointing out (with a failed attempt of light humour) that the base of already installed systemd computer could experience problems if existing functionality was removed (even if it's to be added back later).
I don't think anyone is asking for functionality to be removed, just unbundled and made optional
In system design terms, this is also known as graceful degredation. Rather than depending on everything being there and using all the new features or nothing, design the software to use the new stuff, but include fallbacks for if the new stuff isn't around.
cgroups are a great example, they are neat to have, but not having them shouldn't result in systemd not being usable, it should just mean that the isolation that cgroups would provide isn't there.
Yes, this is a bit more effort to create and maintain, but if the systemd people were willing to accept patches to make this stuff optional it would go a long way towards easing people's fears.
The announcement that udev is going to drop it's non-systemd interface is a perfect example of moving in the opposite direction.
Posted Nov 17, 2014 21:46 UTC (Mon)
by mezcalero (subscriber, #45103)
[Link] (2 responses)
Also, and I'd really like to stress that: I was the one who ported gdm to logind. When I did that I carefully made sure to keep the CK code working in parallel. I did it the *friendliest* possibly way: I just added support for our new logind stuff without breaking those who wanted to stick with ConsoleKit. We also repeatedly tried to find a new maintainer for CK, but nobody volunteered (until very recently when somebody took it and named it CK2).
I think you have no idea of what you are talking of. None whatsoever. You are just making the entire flamefest worse.
Lennart
Posted Nov 18, 2014 11:58 UTC (Tue)
by nijhof (subscriber, #4034)
[Link]
Posted Nov 21, 2014 12:16 UTC (Fri)
by jospoortvliet (guest, #33164)
[Link]
Posted Nov 18, 2014 14:54 UTC (Tue)
by judas_iscariote (guest, #47386)
[Link]
Well, you are corresponding with them here and now, by flaming and burning bridges, lying, misrepresenting and asking other people to do what *you* want in the time frame you want.
Posted Nov 18, 2014 10:43 UTC (Tue)
by nim-nim (subscriber, #34454)
[Link] (13 responses)
That's a bit rich. When a service fails systemd still tells you "there is a problem somewhere, go comb the logs, I won't tell you what's broken". Journald has not fixed anything there. What is broken is not the log format, but that systemd changed the way services are launched, so error handling needs to be redone. But it's more rewarding to write a new log facility than trudge through existing services to make them systemd-friendly.
Moreover last I've seen journald still could not cope with partial writes, so any time systemd gets stuck and you have to press reset journald will helpfully bin all the logs. It's too much work to try to rescue the logs files in their wonderful binary format (you have to press reset since the same laptop crowd which is enthusiastic about systemd decided to remove the acpi power binding that used to permit graceful reboots when the console was lost. Some laptops have badly placed power buttons so the "solution" was to make power buttons useless for everyone.)
I don't even try to fix my systems anymore since systemd made them a windows-like blackbox. On one of them, successful booting requires adding rescue to the kernel CLI, log in as admin, exit immediately (type exit, do nothing) because otherwise systemd will forget to launch gdm or any other console. And of course it would be too much to ask for it to display why it is stuck when it is stuck (sysVinit managed it fine, as did /var/log/messages, the last lines before a reboot almost always matched the problem. With systemd? It could be anywhere!)
Or I could write about the way it fails to restore ethernet links when you plug the wire back in (no wifi! no firmware! just respond to the link active event!). But you get a nice gnome notification about it not working (I prefered the old no notification and working system)
The whole thing is tremendendously brittle and only works in perfect conditions (and someone not even then). The emphasis on restarting stuff blindly instead of diagnosing is telling: systemd people prefer working on feature creep rather than trying to untangle the spaghetti boot they've inflicted on everyone.
Or should I write about how systemd ends up in a strange state every time it is updated? The solution? Reboot! The systemd masterminds don't want to deal with live updates so they just declared they are wrong and should not happen.
Anyway that's why systemd is such a sore. The people who write it seem to have decided they are so cool they can't be wrong, that they badly need to replace all the other software they don't agree with (actually, they don't agree with the other software maintainers, easier to replace them with their own partial implementations than work with existing projects), and in the meantime the actual problems systemd created are not worked on, they are handwaved away (just like the audio problems pulse triggered were declared someone else's problem and you had to dump all the affected hardware since it had been rendered useless).
Pity anyone who hits a systemd problem that does not fit in systemd's master plan.
Posted Nov 18, 2014 10:57 UTC (Tue)
by niner (subscriber, #26151)
[Link] (8 responses)
Wrong. Factually wrong. And here's why:
Lennart Poettering 2014-10-08 20:27:49 UTC
Journal files are mostly append-only files. We keep adding to the end as we go, only updating minimal indexes and bookkeeping in the front earlier parts of the files. These files are rotated (rotation = renamed and replaced by a new one) from time to time, based on certain conditions, such as time, file size, and also when we find the files to be corrupted. As soon as they rotate they are entirely read-only, never modified again. When you use a tool like "journalctl" to read the journal files both the active and the rotated files are implicitly merged, so that they appear as a single stream again.
Now, our strategy to rotate-on-corruption is the safest thing we can do, as we make sure that the internal corruption is frozen in time, and not attempted to be "fixed" by a tool, that might end up making things worse. After all, in the case the often-run writing code really fucks something up, then it is not necessarily a good idea to try to make it better by running a tool on it that tries to fix it up again, a tool that is necessarily a lot more complex, and also less tested.
Now, of course, having corrupted files isn't great, and we should make sure the files even when corrupted stay as accessible as possible. Hence: the code that reads the journal files is actually written in a way that tries to make the best of corrupted files, and tries to read of them as much as possible, with the the subset of the file that is still valid. We do this implicitly on every access.
Hence: journalctl implicitly does on read what a theoretical journal file fsck tool would do, but without actually making this persistent. This logic also has a major benefit: as our reader gets better and learns to deal with more types of corruptions you immediately benefit of it, even for old files!
File systems such as ext4 have an fsck tool since they don't have the luxury to just rotate the fs away and fix the structure on read: they have to use the same file system for all future writes, and they thus need to try hard to make the existing data workable again.
I hope this explains the rationale here a bit more.
Posted Nov 18, 2014 11:51 UTC (Tue)
by nim-nim (subscriber, #34454)
[Link] (7 responses)
Posted Nov 18, 2014 11:53 UTC (Tue)
by niner (subscriber, #26151)
[Link]
Posted Nov 18, 2014 12:07 UTC (Tue)
by tomegun (subscriber, #56697)
[Link] (5 responses)
Posted Nov 18, 2014 19:13 UTC (Tue)
by nim-nim (subscriber, #34454)
[Link] (4 responses)
Posted Nov 18, 2014 19:37 UTC (Tue)
by cebewee (guest, #94775)
[Link] (3 responses)
To prevent further corruption, the corrupted file is then moved away and new entries are written to a fresh logfile. When reading the logs, journalctl does on-the-fly fsck, but without ever writing the salvaged parts back to disk.
Posted Nov 18, 2014 19:40 UTC (Tue)
by dlang (guest, #313)
[Link] (2 responses)
If systemd could detect that the message was corrupted as it was writing it, why would it write the corrupted data in the first place?
Posted Nov 18, 2014 20:11 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Nov 22, 2014 4:34 UTC (Sat)
by zuki (subscriber, #41808)
[Link]
And "corruption" is detected when the file is opened for writing. Journald sets a flag in the header, and will unset it before closing the file. So "corruption" often simply means that the file was not closed properly, but there might be nothing wrong apart for the flag. But in this scenario it is safer to rename the file and create a new one. No content is lost either way.
I'll admit that this is not bullet-proof, and there were various bugs where corrupted files would throw journalctl off, but they are getting fixed. Such reports are definitely much less common than they used to be. Anyway, those are bugs in the implementation, nothing fundamental in the design.
Posted Nov 18, 2014 12:40 UTC (Tue)
by smurf (subscriber, #17840)
[Link] (3 responses)
What's more, "systemctl status" shows you which processes of your service are still running, and the last couple of relevant lines from its log.
Oh yes, and it prevents the log from ever filling the whole disk if a process ever runs amok.
Which focus on restarting services are you talking about? Restart=No is the default.
And for the record, I haven't pressed Reset in ages. You might want to add "HandlePowerKey=reboot" to your logind.conf (and/or figure out where the actual bug is which prevents logind from obeying that button) instead of complaining about how good the old days were, which (a) they were not and (b) doesn't help anybody.
Posted Nov 19, 2014 19:40 UTC (Wed)
by nim-nim (subscriber, #34454)
[Link] (2 responses)
As for the rest, since systemd does not seem to extract meaningful entries in "systemctl status" , "run journalctl" means exactly "go comb the logs",(that's the eternal problem of pretending dumlping things in a database without organisation will solve anything). The "run journalctl" message is hardly helpful, except for shifting the problem on the user. It's author didn't even bother to indicate the "very helpful filtering options"
Posted Nov 20, 2014 8:37 UTC (Thu)
by smurf (subscriber, #17840)
[Link] (1 responses)
Posted Nov 22, 2014 4:39 UTC (Sat)
by zuki (subscriber, #41808)
[Link]
Posted Nov 17, 2014 17:33 UTC (Mon)
by Tov (subscriber, #61080)
[Link] (23 responses)
In the light of the original article - it is sad to see this thread regressing into the same type of inflammatory discussion which causes reasonable people to leave.
Thanks
Posted Nov 17, 2014 17:54 UTC (Mon)
by BrucePerens (guest, #2510)
[Link] (22 responses)
Gee, I'm sorry you feel that way. But I should point out that you've not really contributed any argument, while I have at least put forth some. Do you not understand why I think it's a cabal? Do you have an argument that it is not? Regarding Lennart, I don't know if he's actually to blame but he's the representative (at least within the kernel team) for the group and I believe that Linus and others in that team do indeed have reason to be highly incensed. Publicly pushing it back on them as a social issue (rather than his and systemd's policy issue) was not constructive.
Posted Nov 17, 2014 18:11 UTC (Mon)
by Tov (subscriber, #61080)
[Link] (3 responses)
I do not want to participate in your discussion. If I need to argue to you why people are not a "cabal", it is probably time to pause.
The problem here is not systemd itself but the tone of discussion.
Posted Nov 17, 2014 19:15 UTC (Mon)
by BrucePerens (guest, #2510)
[Link] (2 responses)
Every critic of systemd is treated exactly the same.
Posted Nov 17, 2014 20:01 UTC (Mon)
by Tov (subscriber, #61080)
[Link]
Have a nice day.
Posted Nov 18, 2014 15:43 UTC (Tue)
by judas_iscariote (guest, #47386)
[Link]
Posted Nov 17, 2014 18:57 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (15 responses)
Linus "don't break userspace ever" Torvalds
Take time to UNDERSTAND other people. As was pointed out, misunderstandings can arise because one person speaks English and another one speaks American (or some other foreign language) as their native language. aiui Lennart does not speak American as his native language.
And don't forget the bad rap he got over PulseAudio, where he probably made a lot of enemies because OTHER PEOPLE shipped PulseAudio with a broken ALSA/OSS/whatever, and PulseAudio got the flack because other people didn't do their QA properly.
Oh - and which is better documented? SysVInit or systemd? Which is easier to understand? Which is easier to use? Stop complaining when a system, which many people have adopted to make their life easier, makes your favourite anarchic, hard-to-use project obsolete. If you're going to do anything, make your pet project easier to use, and remember the Golden Rule of open source software - He Who Writes The Code, Writes The Rules!
Cheers,
Posted Nov 17, 2014 19:14 UTC (Mon)
by cebewee (guest, #94775)
[Link] (13 responses)
Posted Nov 17, 2014 21:37 UTC (Mon)
by jaa (subscriber, #14170)
[Link] (12 responses)
Posted Nov 17, 2014 22:03 UTC (Mon)
by rahvin (guest, #16953)
[Link] (8 responses)
A Swedish speaking Finn and a Finn speaking Swedish are the same thing in this context.
Posted Nov 17, 2014 23:04 UTC (Mon)
by johannbg (guest, #65743)
[Link] (5 responses)
The former are Finnish half breeds living in Sweden and the latter are Swedish half breeds living in Finland with Linus being categorized as "Finnish Swedes" thus jaa correction comment being correct.
Posted Nov 18, 2014 0:33 UTC (Tue)
by MrWim (subscriber, #47432)
[Link] (2 responses)
> Linus' is a Swedish speaking Finn
Then jaa said:
> He is other way around, Finn speaking Swedish...
They are both right and mean the same thing, but the former is a little more correct. The key is that "Swedish speaking" is an adjective. So the sentence should be parsed as:
Linus is (a (Swedish speaking) Finn).
The opposite would be "a Finnish speaking Swede".
Another way of phrasing it would be "Linus is a Finn who speaks Swedish".
Posted Nov 18, 2014 1:32 UTC (Tue)
by rgmoore (✭ supporter ✭, #75)
[Link] (1 responses)
I would prefer to say that Linus is a member of Finland's Swedish ethic minority. It spells things out a little bit more clearly. Actually, he was a member of Finland's Swedish ethnic minority; now he's a resident and citizen of the USA.
Posted Nov 18, 2014 1:57 UTC (Tue)
by rahvin (guest, #16953)
[Link]
Posted Nov 18, 2014 1:55 UTC (Tue)
by rahvin (guest, #16953)
[Link] (1 responses)
Posted Nov 18, 2014 7:30 UTC (Tue)
by johannbg (guest, #65743)
[Link]
Now let's just be thankful that Linus is not a half breed from Skåne ;)
Posted Nov 18, 2014 20:28 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (1 responses)
But, as a native English speaker, I would say that the connotations (and therefore meaning!) of those two phrases are actually very different in normal use.
A Swedish speaking Finn is a Finn who CAN speak Swedish and weakly implies a Finnish National who cannot or does not speak Finnish from choice (like Linus).
A Finn speaking Swedish implies a Finnish National who is *currently* *speaking* Swedish, and makes no inference express or implied as to the Finn's preferred choice of language.
And as someone pointed out, adding a hyphen to give us a Swedish-speaking Finn changes the meaning yet again, and makes the implication that Swedish is their first language almost explicit.
That's why English is such a hard language to learn well as a furriner - we have so many words, and the differences in meaning are very subtle but also very definite ... (and use the exact same phrase with different nationalities and languages, and the implications probably change :-)
Cheers,
Posted Nov 18, 2014 22:48 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link]
Posted Nov 17, 2014 22:33 UTC (Mon)
by tialaramex (subscriber, #21167)
[Link] (2 responses)
"A Swedish speaking" Finn parses as
So they evaluate the same. The reason they parse this way is that you can't do
A Swedish (speaking Finn)
Because a single individual from Sweden is a Swede (or of course "A Swedish person" or "A person from Sweden") and not "a Swedish".
Posted Nov 18, 2014 2:00 UTC (Tue)
by jwakely (subscriber, #60262)
[Link] (1 responses)
A Swedish-speaking Finn == a Finn who speaks Swedish
A Swede who speaks Finnish == a Finnish-speaking Swede
Completely unambiguous to a native English speaker.
Posted Nov 18, 2014 7:26 UTC (Tue)
by cebewee (guest, #94775)
[Link]
Posted Nov 17, 2014 19:52 UTC (Mon)
by smurf (subscriber, #17840)
[Link]
Also, Lennart was a lot more abrasive and "I'm right, deal with it"ish in the early PulseÁudio days. People project that onto whatever he does WRT systemd because acknowledging anything else goes against their perceptions, and the couple of times when he still is abrasive get remembered. (Almost) nobody has this problem with Linus, who can be a whole lot more vicious than Lennart ever was.
Posted Nov 17, 2014 19:00 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (1 responses)
It's all very well putting forth arguments. But that should be followed by reasoned, logical discussion. And "I hate systemd" (which seems to be the general argument offered) is not logical reasonable discussion.
Cheers,
Posted Nov 17, 2014 21:22 UTC (Mon)
by dlang (guest, #313)
[Link]
If that's all you are seeing, you are not reading very carefully. There are many complaints about systemd, and most of them have to do with the 'political' side of it. This includes what pieces it chooses to make 'mandatory' and all the various things that Bruce and Ted Tso mentioned earlier.
Posted Nov 17, 2014 17:35 UTC (Mon)
by tomegun (subscriber, #56697)
[Link] (20 responses)
I would like to draw the line (at least) at the git repository (or somewhere in that vicinity) precisely for technical reasons. If we were to split the development of systemd over several projects it would entail a huge amount of extra work for us (the developers), at no apparent gain. I could get into the details, but I'm not sure it is necessary as you didn't answer the question: what would you like to have changed and why?
I believe systemd has made some improvements in terms of config-file handling, I'd encourage you to have a look if you haven't (but I guess that is not relevant to the current discussion).
I think it is important to point out that many of the most frequent complaints we see have in fact been dealt with. In particular, you bring up logging, and the logging format _is_ optional: journald can be reduced to merely a bridge between syslog()/stdin/stderr to a syslog daemon (before journald became journald it was called stdio-bridge as all it did was this task, which is still possible today). Note that this improves on the functionality when daemons would use syslog directly, so even if you prefer only using syslog you should still be happy with that.
If you (or anyone else) insist on only using a syslog daemon without the journal as a bridge (and hence losing logging events and functionality as was the case under sysvinit), this _should_ be possible, but maybe a tiny amount of work needs to be done. I never looked into this as it never made any sense to me, but if you are interested I'd be happy to help you (or anyone else) get started.
udev has been part of the project almost since the beginning, yes. udev can however be packaged and run independently of systemd (however, it cannot be _built_ independently as we share a lot of code, but that is a technical detail). Lots of people see a lot of wrong things with this, but I have yet to see any well-researched suggestions for changes on valid technical grounds.
I have not heard any serious talk of including a package system in the code base (but I am of course aware of what you are referring to).
I do not know your work on Debian very well (it was before my time), but based on your description I can agree that systemd appears to be a a reversal of this model. I "grew up" working under the model where every bit of the base system was maintained independently, and in my experience the systemd model has been a huge improvement. Obviously, we probably differ on what is the best model, but I think under either model there should be enough common ground on technical issues to make everyone happy (making everyone happy on philosophical grounds will obviously never happen).
I disagree with your description of how the systemd community works. Firstly, it is relatively large and very diverse (at least in terms of company/distro affiliation, if not in other ways), and we have open and frequent hack-fests and meetings several times a year, and we also have an open and friendly (despite what people will tell you) mailinglist. We work closely with other communities. What we _don't_ do though, is force anyone to use our software or adopt our ideas. We are of course delighted that a lot of distributions have done so, but this was not something we did (or could have) forced or pushed. It is also not correct to say that distros simply adopted our fully formed ideas, it was rather a bidirectional collaborations of people from the various distributions contributing to systemd and then the distributions adopting the result. I still believe the greatest achievements of systemd has been in cross-distribution collaboration.
Rather than people "pushing back" by throwing abuse at systemd developers (up- or downstream) and advocates, why don't they simply trust the decision processes of their respective distributions? In the case of Debian, there is the (as you know) possibility of a GR to overrule the move to systemd as default, but that has not materialised.
I'd be happy to discuss how we can improve on whatever problems you see with systemd, but if you want to work together, please refrain from derogatory comments (directed at Lennart or anyone else).
I am not privy to Torvads' private thought on systemd, but based on his comments during the most recent DebConf he seems pretty happy with systemd... I'd love to see him start an alternative project though, it would surely be interesting.
Cheers,
Tom
Posted Nov 17, 2014 18:03 UTC (Mon)
by andresfreund (subscriber, #69562)
[Link] (9 responses)
Thanks for the considerate response.
> udev has been part of the project almost since the beginning, yes. udev can however be packaged and run independently of systemd (however, it cannot be _built_ independently as we share a lot of code, but that is a technical detail). Lots of people see a lot of wrong things with this, but I have yet to see any well-researched suggestions for changes on valid technical grounds.
What defines 'valid technical grounds'? One of the examples that I think legitimately caused concern about the bundling was the whole discussion about removing firmware loading support and generally the increasingly tight coupling between udev and kernel versions. The comments about Debian's desire to be able to run the old kernel when upgrading from one major version to the the next weren't exactly taken seriously. To me it's quite a reasonable request to be able to fall back to the old kernel during a major version upgrade if the new kernel doesn't boot.
Independent of distribution updates I find the tight coupling between systemd versions and kernel versions bothersome - I sometimes need to boot different kernel versions to verify performance regressions and that is becoming increasingly harder. And virtualization isn't the answer here - for one in the kind of workloads I'm testing the overhead isn't acceptable, for another the overhead of the host system will be visible in the profile. It's also not really helpful to use different distribution versions on different partitions - it's hard enough to sift through kernel changes. If you then add in all the other changes that happen between distribution major version...
There have been workloads that have regressed by more than 50% since .e.g 2.6.32. So, this isn't about peanuts.
Now you might say that everyone is free to weigh in in those discussions - and you'd be right. But rereading relevant threads it also becomes pretty clear that if a couple key people aren't convinced, you'll not have much success arguing. And the consequence of that is the _appearance_ that the power over a significant number of key pieces of a linux system are more or less under the control of a few people. I personally think being a bit more reticent and understand in such discussions would actually help systemd adoption (and a corresponding contributor increase). Even if it means living with unpopular code a while longer.
Posted Nov 17, 2014 21:48 UTC (Mon)
by tomegun (subscriber, #56697)
[Link] (8 responses)
As to your comments, this basically boils down to wanting new userspace to run on (very) old kernels (the converse is currently guaranteed, that new kernels can run on (very) old userspace).
This is in my opinion absolutely a valid request. However, one which I strongly believe we have to politely decline due to the work involved not being proportional to the benefit. I know there is disagreement within the systemd project about precisely how far back we should go in support and I'm probably on the extreme end in believing that "new userspace requires new kernels, end of story".
My (personal) take on this is that problems with newer kernels should be fixed, and if no one has been able to fix the problem within our current window of two years, then whomever needs the problem fixed probably needs to step up (or more likely pay someone to do so). This clearly is very suboptimal (but we are talking about a two-year-old kernel regression here, so clearly something is _very_ suboptimal no matter how you slice it). It basically boils down to some work needing to be done by someone. What we are currently saying is that we'll carry the burden for a couple of years, but beyond that someone else needs to step up.
If your issue is that you want to bisect kernels without changing userspace, I definitely see this problem. I think that in the extreme case of needing some very old kernel where systemd cannot even boot, you may have to recognise that your usecase is so specialised that we cannot support it, and you would be better off just booting with init=/bin/bash and run your regression test from there. At the end of the day, we have to recognise that we are building a general-purpose OS, not a kernel development platform (I'm not trying to be flippant, but I think this is an important distinction to make, which could save us all a lot of grief)...
Lastly, yes, on some fundamental issues you have to convince some core people (like in any open source project, the kernel more than anywhere else I guess). Being occasionally disappointed that your requests are not implemented or your patch not applied is to be expected (but I must say, it is rare). What we should do though, is to be courteous about it, and provide a technical reason for the decision, so that at least you can understand our point of view. Worst case you could then keep downstream patches to implement the features nacked upstream, and if these patches pass the test of time I guess we'll have to reconsider.
Posted Nov 18, 2014 0:52 UTC (Tue)
by andresfreund (subscriber, #69562)
[Link] (4 responses)
> First, note that all your comments would apply equally to udev had it remained a stand-alone project, so this is not related to the udev/systemd bundling.
I don't think that's necessarily true. It's more realistic to contribute/convince the maintainer udev as a separate project, because the project's concerns aren't as wide. And more importantly, it's much more realistic to have a closely following fork that adds back features if it's just tracking udev, without all the other stuff in systemd going on. You can't really just track src/udev and be done with it.
> As to your comments, this basically boils down to wanting new userspace to run on (very) old kernels (the converse is currently guaranteed, that new kernels can run on (very) old userspace).
> Th is is in my opinion absolutely a valid request. However, one which I strongly believe we have to politely decline due to the work involved not being proportional to the benefit. I know there is disagreement within the systemd project about precisely how far back we should go in support and I'm probably on the extreme end in believing that "new userspace requires new kernels, end of story".
I completely understand that there are limits to how far you can go feasibly. But I also think that you shouldn't forget that the systemd developers having an easier life (quite the worthy goal!) might just shift the work to several other people - who somewhat understandably might be grumpy about that. So it's a tradeoff. E.g. in the somewhat frequently cited case of the userspace firmware loading facilities I just can't see the cost/benefit ratio being in favor of removal. There are other requirements where I'd believe that to swing in the other direction (say requiring cgroups).
> My (personal) take on this is that problems with newer kernels should be fixed, and if no one has been able to fix the problem within our current window of two years, then whomever needs the problem fixed probably needs to step up (or more likely pay someone to do so).
Meh. Many of such problems just aren't discovered in that timeframe. There's a fair amount of microbenchmarks that new kernel version can be tested against, but the real world just triggers completely different cases. That happened again and again.
My personal perspective on this might not be the most usual one - I work on postgres, and we'll just not see larger production users migrating to the new kernel in that timeframe. And it's not like many people have a big 8 socket server + good storage lying around for regular testing.
> This clearly is very suboptimal (but we are talking about a two-year-old kernel regression here, so clearly something is _very_ suboptimal no matter how you slice it).
Right. But it happens. And I think the kernel is complex enough and developing fast enough that that's just not entirely preventable. So we need to be able to deal with that.
> It basically boils down to some work needing to be done by someone. What we are currently saying is that we'll carry the burden for a couple of years, but beyond that someone else needs to step up.
Well, "couple of years" being less than two right now. 3.7 was released 2012-12-10, systemd 217 released 2014-10-28 has 3.7 as a prerequisite.
That's lower than the regular release cycle of most distributions that you see outside of developer boxens. Sorry, that's just not sufficient.
> If your issue is that you want to bisect kernels without changing userspace, I definitely see this problem. I think that in the extreme case of needing some very old kernel where systemd cannot even boot, you may have to recognise that your usecase is so specialised that we cannot support it, and you would be better off just booting with init=/bin/bash and run your regression test from there. At the end of the day, we have to recognise that we are building a general-purpose OS, not a kernel development platform (I'm not trying to be flippant, but I think this is an important distinction to make, which could save us all a lot of grief)...
Note that I'm not a kernel developer! I'm primarily a userspace guy. It's simply not just kernel devs that need to do that kind of thing. In fact I (or well, customers of the company I work for) have previously even been asked by RHEL support to downgrade to a older kernel to diagnose problems.
And given the amount of tooling thats getting integrated into/with systemd (sharing the version requirements) it's getting less and less realistic to boot with init=/bin/bash. Bringing up a server with somewhat complex storage without the usual infrastructure takes *significant* amount of time. Not to speak of the complexity of starting all kinds of services - without systemd and its capabilities around.
> Lastly, yes, on some fundamental issues you have to convince some core people (like in any open source project, the kernel more than anywhere else I guess).
Sure, that's fine. But the tone in some of the discussion around e.g. the removal of the userspace firmware loading, wasn't what I'd expect. Neither was the quality of the reasoning in favor of the removal.
Don't forget that outside the Redhat/Fedora world upgrading existing systems without a reinstall is a officially supported thing and has been for a long time.
Posted Nov 18, 2014 9:23 UTC (Tue)
by Thue (guest, #14277)
[Link]
So much of the systemd criticism is so fluffy and just basically obviously purposefully ignorant, it gives systemd critics a bad name. So uniformly so that I sometimes begin do doubt whether I am being unfair in personally categorizing that as unconstructive trolls. Seeing useful criticism like your is a benchmark for return to sanity.
Posted Nov 19, 2014 0:39 UTC (Wed)
by sandsmark (guest, #62172)
[Link]
considering that he is an archlinux developer, I doubt that he will forget that. :-)
Posted Nov 19, 2014 2:05 UTC (Wed)
by tomegun (subscriber, #56697)
[Link]
Nice to hear!
> It's more realistic to contribute/convince the maintainer udev as a separate project, because the project's concerns aren't as wide. And more importantly, it's much more realistic to have a closely following fork that adds back features if it's just tracking udev, without all the other stuff in systemd going on. You can't really just track src/udev and be done with it.
I see where you are coming from, but as someone who has worked quite closely with udev both before and after the merge, I don't think this is the case in this particular instance. Convincing Kay of taking a patch has not become any more or less difficult, and the code is still pretty much separate (and the code that is shared is not really in the 'problem' areas), so tracking src/udev should really get you very far.
> But I also think that you shouldn't forget that the systemd developers having an easier life (quite the worthy goal!) might just shift the work to several other people - who somewhat understandably might be grumpy about that.
Absolutely, there is a trade-off. Most of the time we (as any open source project) happily do work to easy the work of others even when it does not benefit us directly (usually because it "makes sense"). But sometimes, we (as anyone) will say "no, this makes no sense, we shouldn't be doing things this way, we can't test this stuff and there are better solutions out there, if someone wants this problem solved in this particular way they'll have to do the work themselves".
In the case of the firmware loader we have a situation where no systemd developer would ever test it (as we all run on kernels where it is not used any longer), it was known to be buggy with no nice solution in sight, and the proper solution has been in the kernel for some time. On top of all that, a third-party solution could trivially be maintained outside of udev (please ask on the ml if you want hints on how to get started, but basically you just have to copy the sample bash script from the kernel docs and call that from a udev rule).
The cgroup situation is a bit more sticky, as there is no nice way to "make this work" outside of patching systemd itself. Though, as you recognise the work involved on the systemd side is there much larger, so that we don't support it is hopefully more understandable. That said, my suggestion would be to keep a downstream patch if anyone wants this, and if it is shown over time to be viable and useful I guess people may reconsider merging it...
> I think the kernel is complex enough and developing fast enough that that's just not entirely preventable. So we need to be able to deal with that.
That we can agree on. But this is ultimately a debugging problem. I.e., you (or your customer, or your support contractor, or kernel devs) need to figure out what kernel commit broke your setup, so probably need to do a bisect. I agree that this may be painful in specific cases, and we should look at ways to ease that pain.
However, we should not make the mistake of making the bisection problem into a maintenance nightmare. I.e., yes, you may want to boot an old kernel with a new userspace to test something, but you absolutely do not want to work around a kernel bug by deploying new userspace on an old kernel. If you cannot upgrade your production kernel, then don't upgrade your production userspace. If we start pretending that this is in fact possible, we both know that that is exactly what people will be doing (and just leave the kernel regressions to rot), and then come complaining that our old code (which we have long since stopped testing, and probably was known to be semi-broken in the first place) blew up their production machines.
We should not forget that the reason we usually depend on newer kernels is that they provide some API which fixes a problem we had with the old API (security or otherwise), so just keeping support for the old APIs around almost always means keeping known semi-broken code around, and moreover this code would then only end up actually being used by end-users stuck with old kernels, and never by developers or early adopters (as we always use new kernels anyway).
> Don't forget that outside the Redhat/Fedora world upgrading existing systems without a reinstall is a officially supported thing and has been for a long time.
I think this absolutely makes sense (being a rolling-release person myself), but we should not get stuck on the precise mechanism by which this is done today. I.e., I don't think upgrading a running userspace on top of an ancient kernel makes any sense, but there are technical solutions to get around this so that you can still upgrade without a reinstall, but never have to run old kernel + new userspace. ChromeOS/CoreOS does this in one way, systemd comes with upgrade hooks that allows you to do it in a different way, and we are working on a third proposal of how to achieve the same goal. And then there is of course the Arch way: upgrade your system all the time, and then you'll be fine doing it in-place as your kernel will not be ancient, but still an upstream-maintained one.
Thanks for your comments!
Posted Nov 19, 2014 2:29 UTC (Wed)
by rahulsundaram (subscriber, #21946)
[Link]
Don't forget that Fedora has supported the same thing for a long time as well and so has RHEL (via upgradeany on earlier release and with commercial support for the server edition with the latest release).
Posted Nov 18, 2014 11:12 UTC (Tue)
by pabs (subscriber, #43278)
[Link]
Posted Nov 19, 2014 3:41 UTC (Wed)
by viro (subscriber, #7872)
[Link] (1 responses)
Charming. Sadly, it means that result is unfit to be used for maintaining its rather crucial component. Your "very old" is mere couple of years; I run into bisects that go back by several times that once in a month or so. It sure as hell is not enjoyable, but it does happen. Really. And unless your "general-purpose OS" really doesn't care about regressions in the kernel, you are SOL.
The weird part is that one can not use systemd without the kernel, one _can_ use the kernel without systemd and yet you guys go "if what we do screws the kernel developers, tough, let them suffer; it's too special use case to care about"...
Posted Nov 19, 2014 8:42 UTC (Wed)
by tomegun (subscriber, #56697)
[Link]
As to the issue with kernel bisection, there are still a million ways of making that work. I just don't see how we can reasonably solve it upstream (feel free to prove me wrong, but I'm not going to be impressed by 'we are more important than you, and you are screwing us'-kind of whining).
If stock systemd doesn't boot (note that in most cases it will of course boot even on kernels older than the officially supported ones), and you cannot use a simple init=/bin/bash, then there is absolutely nothing wrong with someone (perhaps a systemd dev and a kernel dev in collaboration) maintaining a minimal patchset on top of systemd to create 'systemd-kernel-bisection' which comes with all sorts of fallbacks allowing even the most ancient kernel to boot with 'all' the features switched off.
By having a separate patch-set we don't have to worry about people actually using this in production, and by focussing merely on allowing kernel bisects we can accept the issues related to using known broken/racy APIs, or just offering severely reduced functionality in areas that don't matter to this usecase.
I have a feeling that all this is overkill in the vast number of cases though, based on the fact that we have been working with plenty of kernel developers for years now and I have not even heard this issue mentioned (I have no doubt that the kernel devs in question would be more than capable of maintaining such a patchset, and that they would not hesitate to do so if they saw the need in their own work).
In fact, the only time I hear this brought up by kernel developers are by the ones who are not even using systemd and who apparently already hate it with a vengeance irrespective of this problem. I'm happy to be proven wrong though, so if you (or anyone else) want to work together towards a mutually acceptable solution, I'm all ears.
Posted Nov 17, 2014 18:12 UTC (Mon)
by BrucePerens (guest, #2510)
[Link] (9 responses)
I'm viewing this one statement in the context of my work on Debian, and I see it as the major difference we have. Ian Murdock did all of the base system work himself. I took over from Ian and broke it up, handing pieces to individual developers. Eventually I was not left with even one piece. It did not impose a lot of extra work on anyone. It did enforce both independece and relationships. We had to communicate. We had to put more thought into how things worked together, and to explain it to each other, because the other parties didn't have to listen to each other. Everything did work together amazingly well. I think better than it would have otherwise.
Posted Nov 17, 2014 18:44 UTC (Mon)
by niner (subscriber, #26151)
[Link] (5 responses)
Posted Nov 17, 2014 19:55 UTC (Mon)
by BrucePerens (guest, #2510)
[Link] (4 responses)
Well, you may have internal unity, but you seem to be absolutely surrounded by flames and bickering and negativity. Including on the LKML, not just in Debian. None of it is your fault, huh? You marketed it wrong. I don't think you can fix that now.
Posted Nov 17, 2014 20:16 UTC (Mon)
by niner (subscriber, #26151)
[Link]
None of this is my fault, no. Can't be, since I'm involved neither in Debian, nor in systemd in any way. I am just an observer. And I observe many flames by people who have not even tried to understand systemd or the many technical arguments the systemd developers have brought over and over. Instead, people seem to repeat the same myths and preconceptions over and over. Until maintainers can't stand it anymore and quit working on free software.
I wonder, why someone who has been a part in creating the free software movement suddenly works to destroy it. Seems quite illogical, but I guess that's just human.
Posted Nov 17, 2014 20:57 UTC (Mon)
by tomegun (subscriber, #56697)
[Link] (1 responses)
At this point, all we can really do is to try to listen and learn what we can from our critics. That said, this far into the game most basic things have been said already many times, and for those of us who have been involved since the beginning it does get exasperating having to answer the same, long-debunked "criticism" from people who have only a very superficial knowledge of what we do, the problems we try to solve, and the previous discussions on the same topic.
Posted Nov 18, 2014 11:29 UTC (Tue)
by pabs (subscriber, #43278)
[Link]
I'd also like to point out this recent post from Planet Debian entitled "Enabling Change".
Posted Nov 17, 2014 23:46 UTC (Mon)
by HelloWorld (guest, #56129)
[Link]
> You marketed it wrong. I don't think you can fix that now.
Posted Nov 17, 2014 19:57 UTC (Mon)
by smurf (subscriber, #17840)
[Link]
There is no technical OR social reason why splitting up the systemd repo into N subparts should change anything at all, except create more work for everybody involved.
Posted Nov 17, 2014 21:12 UTC (Mon)
by tomegun (subscriber, #56697)
[Link]
You did not answer any of my questions, so at this point I really can't tell what you are proposing that we do (in concrete terms). It appears to me that you have not really studied the project you are proposing fundamental changes to (but I'd be delighted to be proven wrong).
As to your comparison to your earlier Debian development, I fear the similarities are only superficial (both because the base OS is very different then from now, because Linux itself is, and because systemd is much more modular than you appear to believe), and without further detailed analysis I see absolutely no reason why what worked well for you should be blindly followed by a very different project.
Cheers,
Tom
Posted Nov 17, 2014 21:34 UTC (Mon)
by jwarnica (subscriber, #27492)
[Link]
I'm not quite prepared to grant that the SysV design, itself organically developed, was ever ideal, and it is beyond question today in deep need of reworking. Reimplementing a 1990 design by '97 (or whatever the dates) is an accomplishment, but that doesn't make it an accomplished design.
Posted Nov 17, 2014 18:03 UTC (Mon)
by torquay (guest, #92428)
[Link] (8 responses)
Anything to get away from the current broken way of distributing user facing software is actually a good thing.
Distributing software packages as RPMs/DEBs is all fine and dandy for the base operating system, but completely wrong for user facing apps like Inkscape, Gimp, Firefox, LibreOffice, Transmission, etc. A user should not have to upgrade the entire operating system just to get an updated version of Inkscape et al.
Posted Nov 17, 2014 18:18 UTC (Mon)
by BrucePerens (guest, #2510)
[Link] (7 responses)
Yes, I agree. But the solutions I've seen have each application bring in its entire world of libraries. Which is really inefficient and shifts more load onto the application packager than they really need to have. There isn't really a reason that the current Debian package system could not support new versions of applications within the life of a distribution version. The only reason it does not is that current Debian policy is to do these as major releases. Maybe that's due for a change.
Posted Nov 17, 2014 18:37 UTC (Mon)
by torquay (guest, #92428)
[Link] (5 responses)
The problem with that approach is that it's like putting lipstick on a pig. RPM/DEB packages for user facing software are still getting in the way, because an active maintainer is needed. The package maintainer is a bottleneck and a failure point. Why not get the software directly from the vendor, and cut out the problematic middle man?
This doesn't exclude the vendor from directly putting up the package in an AppStore-like setup. Unlike RPMs and DEBs, you only need one package in an AppStore, in contrast to current mess of 5000 bazillion packages for each separate distro.
To get to an AppStore-like setup in Linux, we need containers, and hence all the underlying plumbing for creating containers (cgroups et al). Do you really want to fork/rewrite all the code already present in systemd for managing cgroups, etc? Why make more work for yourself? Why not instead spend your time for more productive purposes?
If we follow your bizarre anti-systemd stance to its logical conclusion, the Linux kernel should be split up into 1000000 parts, with each part living in a separate source code repo. Each part would then be endlessly forked, because nobody would be able to agree on anything.
Posted Nov 17, 2014 19:25 UTC (Mon)
by BrucePerens (guest, #2510)
[Link] (1 responses)
Because what we is the ultimate expression of not playing well with others. Each application is an island in its own separate userspace with its own copy of everything but the kernel (and not every one stops there, of course there are OS emulations, API "versioning", etc.).
Posted Nov 17, 2014 21:27 UTC (Mon)
by HelloWorld (guest, #56129)
[Link]
Posted Nov 17, 2014 19:32 UTC (Mon)
by lsl (subscriber, #86508)
[Link] (1 responses)
Because not every "vendor" wants to build binary packages[1]. If you look at the Debian repos, the vast majority of software there is distributed in source form only by the respective upstreams.
The problem of wanting to install newer versions on stable distributions is, like Bruce says, mostly a policy issue. There's nothing that actually prevents building the newest Inkscape against an older Debian release. Maybe it's even already available in -backports.
If you really want to distribute binary packages, why not just upload to OBS and let it build packages for all the different distributions?
[1] or, for that matter, is even able to do so without investing lots of work. Do you have a working setup to build and test binaries for all the supported Debian architectures? Sure, there's QEMU but the reliability of its system emulation varies wildly between archs.
If you don't and just provide packages for x86 (the most likely outcome of an "Appstore" model) the distro packagers and builders would still be needed or else the prospect of Debian continuing to be "The Universal Operating System" would fade away fast.
Posted Nov 17, 2014 22:19 UTC (Mon)
by HelloWorld (guest, #56129)
[Link]
Posted Nov 19, 2014 0:03 UTC (Wed)
by flussence (guest, #85566)
[Link]
Because that model doesn't work on any other OS either.
...unless you actually think disease-ridden landfill sites like download.com and Google Play are something desktop Linux should *aspire to*, in which case I find you delusional and tasteless.
Posted Nov 17, 2014 19:42 UTC (Mon)
by SEJeff (guest, #51588)
[Link]
Posted Nov 17, 2014 19:01 UTC (Mon)
by HelloWorld (guest, #56129)
[Link] (26 responses)
No, because it's the Right Thing To Do. Linux never went anywhere on the desktop, and the right conclusion from that is *not* to go on like we always did (i. e. "just build a bunch of components and let distros figure out the integration") but to try something new and different. And the fact that systemd beats the pants off every other init system both in terms of performance and in terms of functionality, all while unifying stuff across distributions and thus making life easier for administrators, users and developers, proves that point.
Posted Nov 17, 2014 19:57 UTC (Mon)
by BrucePerens (guest, #2510)
[Link] (3 responses)
Systemd has little to do with why Open Source desktops (not Linux, that's in Android) have not gained user acceptance. Users don't know what systemd is and don't in general see its features. You will need to blame this one on user-visible phenomena.
Posted Nov 17, 2014 20:08 UTC (Mon)
by HelloWorld (guest, #56129)
[Link] (2 responses)
Posted Nov 17, 2014 20:10 UTC (Mon)
by niner (subscriber, #26151)
[Link] (1 responses)
So there can absolutely be no harm in adopting systemd, since it does not even touch users. Good to hear that from you!
Posted Nov 19, 2014 0:09 UTC (Wed)
by flussence (guest, #85566)
[Link]
Posted Nov 17, 2014 21:28 UTC (Mon)
by mgb (guest, #3226)
[Link] (21 responses)
Linux leads the world on servers. Linux leads the world on mobile. And Linux is the world's leading O/S overall. Linux achieved this success thanks to the Unix philosophy which enables innovation.
The only area where Linux has failed is where FreeDesktop.Org reached beyond their core graphics competencies. D-Bus is like some 1970's mainframe protocol come back from the dead. Systemd is a monolith whose entanglements raise huge barriers to innovation. RIP HAL.
So forget marshaling and use text streams. Design modular. REST wherever possible. Don't use leverage to push bad stuff. Make stuff we want to use.
Posted Nov 17, 2014 22:05 UTC (Mon)
by HelloWorld (guest, #56129)
[Link] (9 responses)
Posted Nov 17, 2014 22:26 UTC (Mon)
by mgb (guest, #3226)
[Link] (8 responses)
Marshaled interfaces are brittle, harder to use, harder to debug, and therefore raise barriers to innovation. Except at the very lowest levels where performance is paramount, marshaled interfaces are counter-productive.
D-Bus is a marshaled interface and one of several bad ideas to come out of FreeDesktop.Org. D-Bus would be far better if it had been a modern design like HTTP or SQL or JSON. Systemd just digs deeper into the D-Bus hole.
Posted Nov 17, 2014 22:34 UTC (Mon)
by rodgerd (guest, #58896)
[Link] (2 responses)
At this point I can only applaud what is clearly a masterclass in trolling.
Posted Nov 17, 2014 22:52 UTC (Mon)
by mgb (guest, #3226)
[Link] (1 responses)
Posted Nov 18, 2014 0:02 UTC (Tue)
by Wol (subscriber, #4433)
[Link]
(Which IS the name of a decent query language, and as its name implies is also a pretty decent approximation to English.)
Cheers,
Posted Nov 17, 2014 23:41 UTC (Mon)
by smurf (subscriber, #17840)
[Link] (3 responses)
Marshalling just means packing up your data somehow. JSON and SQL are just as much a form of marshalling as dbus, it's just that the destination happens to be ASCII (or UTF-8 these days) instead of binary.
With binary formats you don't waste all time encoding and then decoding numbers and strings. And, oh well, you need a program to make sense of a data dump. But if you had ever tried to plow through a multi-level JSON dump, you'd know that you need that anyway.
So, care to enlighten us what you actually think is wrong with dbus?
Posted Nov 18, 2014 0:07 UTC (Tue)
by mgb (guest, #3226)
[Link] (2 responses)
We learned in the 1970's that such pointless optimizations make interfaces brittle, harder to use, harder to debug, and harder to re-implement. They are anti-innovation.
D-Bus is a bad design, like the horrible DB interfaces we had to use before SQL, and like the horrible communication protocols before HTTP and SMTP.
And systemd is still digging as fast as it can in the D-Bus hole.
Posted Nov 18, 2014 1:02 UTC (Tue)
by smurf (subscriber, #17840)
[Link]
I have no idea why you think dbus is brittle or hard to debug. It's a quite reliable self-describing extensible protocol, supports introspection, and has a bus monitor that shows whatever messages get exchanged in a human-readable way. There's a reason it's so widely used and has replaced previous attempts (anybody remember CORBA?).
Sending binary data isn't a pointless optimization. Sending structured data as ASCII is a pointless *pessimization* in this context. It's actually harder to do correctly than doing the same thing in binary, particularly if you want to go beyond "string" and "integer" data types (and maybe JSON's unstructured arrays / hashes).
Posted Nov 18, 2014 1:06 UTC (Tue)
by jspaleta (subscriber, #50639)
[Link]
-jef
Posted Nov 17, 2014 23:50 UTC (Mon)
by HelloWorld (guest, #56129)
[Link]
Posted Nov 17, 2014 22:47 UTC (Mon)
by Tester (guest, #40675)
[Link] (1 responses)
Posted Nov 18, 2014 2:14 UTC (Tue)
by jwakely (subscriber, #60262)
[Link]
Posted Nov 18, 2014 5:51 UTC (Tue)
by rgmoore (✭ supporter ✭, #75)
[Link] (4 responses)
If 70s era designs are so terrible and modern ones are so much better, then why are we being encouraged to stick with a 70s era design for our init (sysvinit) rather than a modern one (systemd)?
Posted Nov 18, 2014 7:53 UTC (Tue)
by mgb (guest, #3226)
[Link] (3 responses)
One of the things we learned is that binary protocols are brittle, harder to use, harder to debug, and harder to re-implement than text stream protocols. That is why, except at the very lowest levels such as TCP, today's successful protocols are text streams.
D-Bus is a throwback to the binary protocols of the 1970's. And systemd made the mistake of relying on D-Bus, thus compounding the problems caused by the monolithic entanglements in systemd's own design. Systemd's designers didn't learn from history and so they are doomed to relive it.
Posted Nov 18, 2014 9:00 UTC (Tue)
by niner (subscriber, #26151)
[Link]
Yes, text protocols have some very nice properties. They are also a security nightmare. Why do you think, we should learn the one lessen, but completely ignore the other?
Posted Nov 18, 2014 12:20 UTC (Tue)
by smurf (subscriber, #17840)
[Link]
You might well remember the lessons of the 70s, but how about the lesson of the 2010s – exactly how old is dbus, and exactly how fragile has it proven to be in actual use lately? So fragile that KDE and Gnome switched to it (remember CORBA and Bonobo), ages ago … no doubt all part of a giant conspiracy to Destroy The UNIX Way As We Know It. :-P
Posted Nov 19, 2014 1:48 UTC (Wed)
by flussence (guest, #85566)
[Link]
I agree with this sentiment, after having wasted an entire day trying to figure out how /dev/initctl works, and discovering the fractal horrors beneath.
Posted Nov 20, 2014 20:45 UTC (Thu)
by ms_43 (subscriber, #99293)
[Link] (3 responses)
That's not the case: Android leads the world on mobile. There is a difference.
I would be interested to hear your argument how exactly Android's success is a vindication of the UNIX philosophy.
Posted Nov 20, 2014 21:00 UTC (Thu)
by jspaleta (subscriber, #50639)
[Link]
"If we can't save Unix philosphy you can be damn sure we'll avenge it"
Posted Nov 20, 2014 21:01 UTC (Thu)
by mgb (guest, #3226)
[Link] (1 responses)
The Unix Philosophy enables innovation.
GNU/Linux enabled Android. However Android itself lacks the Unix Philosophy and therefore despite being wildly successful Android can never be the future of Linux.
Similarly GNU/Linux enabled systemd and systemd may be a successful product in the Gnome/KDE niche but its monolithic entanglement is a barrier to innovation. The future of GNU/Linux is coding around the systemd blockage.
In the future we should expect to see an init with features similar to systemd's core but in an up-to-date portable modular design (and without Upstart's CLA).
Posted Nov 25, 2014 22:02 UTC (Tue)
by nix (subscriber, #2304)
[Link]
If you can't produce substantive evidence, do you mind shutting up about it? It's getting very boring.
Posted Nov 17, 2014 22:11 UTC (Mon)
by HelloWorld (guest, #56129)
[Link]
Posted Nov 18, 2014 2:37 UTC (Tue)
by foom (subscriber, #14868)
[Link]
Well, worse things could happen.
If systemd catalyzes Linus into writing yet another system, clearly superior to systemd, and takes over the world...well...great! I seriously doubt that could happen though -- upstart already played the catalyst/prototype role for systemd. I don't think another new init system at this point would be able to have the show the same kind of obvious superiority over systemd, as git did over its predecessors.
Posted Nov 17, 2014 15:55 UTC (Mon)
by hunger (subscriber, #36242)
[Link] (20 responses)
Since these programs provide the best solution other software now starts to depend on them. So a stack of components is formed.
You are now proposing to replace this nice stack of components by an architecture where none of the components may depend on any other. IIRC the technical term for such an architecture is "a mess":-)
Posted Nov 17, 2014 17:01 UTC (Mon)
by BrucePerens (guest, #2510)
[Link] (19 responses)
When I was a kid, everyone in the United States got their telephone from the phone company. In fact, it was illegal to get your phone from anywhere else. Eventually we learned what was wrong with that, and we broke up the phone company, leading to many benefits both technical and economical. As a side effect, we got the Internet. And Linux. We used to deal with the problem you name through APIs. What is so different about the systemd problem that we no longer can?
Posted Nov 17, 2014 17:14 UTC (Mon)
by daniels (subscriber, #16193)
[Link] (9 responses)
I'm also not sure if upholding the American telephone system as a sparkling example of how everything should be done is intentionally parody or not.
Posted Nov 17, 2014 17:34 UTC (Mon)
by BrucePerens (guest, #2510)
[Link] (8 responses)
I have always been a fan of the minimal GUI servers, for the exact reason you give. I was not happy with how X grew and am not really looking forward to Wayland. Linux is still mainly a kernel and can be built without dbus and udev. But of course microkernels are compelling. Whatever is wrong with the American phone system, it's still much better than having to buy it all from one company. My objections to systemd in its present form are entirely consistent with these things.
Posted Nov 17, 2014 18:09 UTC (Mon)
by daniels (subscriber, #16193)
[Link] (6 responses)
Posted Nov 17, 2014 18:44 UTC (Mon)
by BrucePerens (guest, #2510)
[Link] (5 responses)
I really like the architectural indpendence in rio. It doesn't really know about rendering. It does know (as Wayland does) about window and event management. Windows are files. You can run rio in a window, and it just gives you more windows which are files. Network transparency comes for free. This assumes that you define a file interface for 3D rendering. Which is not an impossible thing. Yes, directly talking to the display device in mapped memory is faster. But it's pretty horrible for system stability. When things crash these days, that's often why.
Posted Nov 17, 2014 18:54 UTC (Mon)
by daniels (subscriber, #16193)
[Link]
Anyway, not that any clients have bashed GPU command rings directly basically ever, but certainly not in the past ten-odd years. You might want to look at the kernel APIs which exist and are used today without userspace ever hitting the ring directly, then note they're extremely device-specific, and wonder how to abstract that away in the kernel.
Short of Linux becoming Plan9 with /dev/opengl, I'm not really sure where to go from there.
Posted Nov 18, 2014 7:54 UTC (Tue)
by roskegg (subscriber, #105)
[Link] (3 responses)
I'd like to see an OS that takes Inferno/Plan9 as the base system for developers, and cherry picks the best UI features from NeXTSTEP and BeOS for the "polished user experience".
I realized today, looking over this discussion, that code bloat isn't my only objection to modern directions. I object to code churn just as much. OpenBSD has been pretty good about code churn.
I really like the Plan9 ethos of "be able to hold the whole design in your head". By cherry picking UI from BeOS and NeXT, I hope the same can be done for the "desktop" experience too. The simplicity of Rio apps is so beautiful. If only there were a few artists to spruce it up the way Ubuntu did to Debian back in the day. I was just about ready to get Aunt Tilly using Ubuntu back in 2007, and suddenly HAL and PulseAudio set things back. I lost trust.
Nice to see someone other than myself mention coupling and cohesion. The systemd guys don't seem to get coupling and cohesion and the Demeter Principle. Or rather, they are trying to re-do the social contract about where and how much coupling and cohesion happen between components. You struck a happy balance in the Debian base system.
Posted Nov 18, 2014 11:45 UTC (Tue)
by daniels (subscriber, #16193)
[Link] (2 responses)
Ah yes, the classic, 'someone has taken different choices to me so they obviously do not understand the problem!'. Because surely it's impossible for reasonable people to arrive at different conclusions, and obviously the systemd developers are much less experienced than you and really need to be taught how to write software.
Posted Nov 18, 2014 12:21 UTC (Tue)
by roskegg (subscriber, #105)
[Link] (1 responses)
Posted Nov 18, 2014 12:42 UTC (Tue)
by daniels (subscriber, #16193)
[Link]
But yes, I'm saying that 'chalk[ing] up any criticism to the misunderstandings of the ignorant and uneducated' is a pretty horrible way to argue, and that's exactly what you're doing. I may massively disagree with the loose-coupling brigade, but I understand where they're coming from and it is a valid point of view.
For reference, the opposite would be: 'oh, these academic idiots just don't understand _real_ software development, and if only they knew what they were talking about, they'd realise loose coupling is a nonsense UML-driven pipe dream that has never succeeded in the real world and won't ever succeed'. But I accept that it's perfectly possible for intelligent people to reach different conclusions on the matter.
Posted Nov 17, 2014 21:16 UTC (Mon)
by HelloWorld (guest, #56129)
[Link]
Posted Nov 17, 2014 17:18 UTC (Mon)
by hunger (subscriber, #36242)
[Link] (5 responses)
Your original post said "We need to break systemd up into separate projects, resolve the issues that cause the largest objections to it, and make sure it plays with others (again, including other init systems)."
Where is the benefit of breaking systemd up into separate projects? Other unixes seem to be fine with having a set of core components developed in one repository, so why should that model not work for Linux?
Making "sure it plays with others" -- including other init systems -- is just making the task impossible. First you need to implement other init systems that actually provide a similar level of features to those that systemd already has. Then you need to define a common set of APIs for all those init system to adhere to. Just check how well KDE and gnome manage to do that.
Posted Nov 18, 2014 16:14 UTC (Tue)
by alankila (guest, #47141)
[Link] (4 responses)
It's not impossible. I think it's just about 3 times harder. As I see it, Open Source is tremendously engineering power starved to begin with, and we can ill afford this 3x penalty.
It would be much simpler and faster to dispense with cooperation and communication as much as possible and just concentrate on doing awesome stuff, tightly coupled. Every once in a while, you get people who find the fast/efficient track and they can do amazing things with about third of the effort of the competition and in a few scant years push world ahead worth decade of normal development effort.
Unfortunately, it tends to run into tremendous push-back, and I like to think that part of it is simple "development panic". Things change too fast, and people feel that they lose control, and then they start to complain very loudly and see that this new huge alien thing has all but encroached them.
This is not intended to be a complete and reasoned perspective on the development, but to highlight an aspect that appears to be rarely properly considered. We pay by the nose for every API and every bit of bad design we workaround and every alternative implementation of a common standard we support.
Posted Nov 18, 2014 17:24 UTC (Tue)
by dlang (guest, #313)
[Link]
Actually, while Open Source can always use more manpower, We tend to be far shorter in reviewing and testing than in engineering.
It's always easier from a programming point of view to not care about existing users and backwards compatibility, but the most successful software cares about them anyway. Without users, why are you writing software?
Posted Nov 18, 2014 17:26 UTC (Tue)
by dlang (guest, #313)
[Link]
How about the idea that people have been around and seen prior iterations of the process and realize that no matter how nice the software seems right now, maintaining it over time requires a lot of that extra effort that the developers weren't willing to expend.
Posted Nov 19, 2014 12:38 UTC (Wed)
by hunger (subscriber, #36242)
[Link] (1 responses)
I seriously doubt that the free software community can agree to something complex as an API for an entire init system. That works if somebody steps ahead and just does something, like the systemd developers did.
Sitting down and discussing the issue and then trying to shoehorn sysv-init and systemd into the same API will never work. So either people fight through the push-back or we stick with sysv-init. That lasted as long as it did because nobody wanted to do the fighting.
Kudos to Lennart for pushing ahead of the status-quo where many have given up before him.
Posted Nov 19, 2014 15:21 UTC (Wed)
by ebassi (subscriber, #54855)
[Link]
we did agree to a protocol, unless I dreamed about this whole specification, and the discussion that led to it. to be fair, my life would be happier if that specification did not exist in the first place, because it has brought nothing but abuse — in terms of user interaction; toolkit API; and actual abuse from developers and users alike. what both KDE and GNOME could not agree on was a new specification to supersede the one that is currently existing, and (mostly, barely) working.
Posted Nov 17, 2014 21:10 UTC (Mon)
by HelloWorld (guest, #56129)
[Link] (2 responses)
Posted Nov 19, 2014 0:24 UTC (Wed)
by flussence (guest, #85566)
[Link] (1 responses)
Posted Nov 19, 2014 0:41 UTC (Wed)
by jspaleta (subscriber, #50639)
[Link]
Bruce brought the concept of legality into the discussion. If someone wants points out the obvious, that the use of an illegal action analogy is ill-fitting I think that's perfectly acceptable criticism.
-jef
Posted Nov 17, 2014 16:21 UTC (Mon)
by mlopezibanez (guest, #66088)
[Link] (5 responses)
Substitute X for "systemd", "feminism in videogames", etc, and you'll see a strange pattern emerging.
Posted Nov 17, 2014 17:03 UTC (Mon)
by BrucePerens (guest, #2510)
[Link] (3 responses)
Bah. Systemd is not, and will never be, a human rights issue.
Posted Nov 17, 2014 17:09 UTC (Mon)
by Rehdon (guest, #45440)
[Link] (1 responses)
Posted Nov 17, 2014 17:23 UTC (Mon)
by BrucePerens (guest, #2510)
[Link]
You could apply the same pattern to anything that is argued vehemently. You could do it on the side of any number of horribly evil things. So, the "pattern" is not some sort of profound observation. Having people live together in harmony with equal rights for all is worth fighting and dying for. Big-endian vs. little-endian number format has been vehemently argued too, but it won't ever be the same.
Posted Nov 17, 2014 17:29 UTC (Mon)
by mlopezibanez (guest, #66088)
[Link]
Posted Nov 17, 2014 17:15 UTC (Mon)
by daniels (subscriber, #16193)
[Link]
Posted Nov 17, 2014 17:32 UTC (Mon)
by joshl (guest, #91369)
[Link] (11 responses)
> We
Who?
> pushing back on the team that pushed it upon us is unfortunately necessary.
In any case, I'd like to make it very clear that, as a Linux user, poisonous rhetoric like this doesn't speak for me. I'd be distraught if it was ever assumed so.
Posted Nov 17, 2014 18:01 UTC (Mon)
by Thue (guest, #14277)
[Link] (5 responses)
If they are not enough productive people for the fork to survive, well, then it wasn't very important in the first place.
A central point of this whole discussion, and the current GR, is whether Debian should force maintainers not interested in sysvinit to maintain sysvinit. BrucePerens complaint seems like more of the same to me. In the other thread he said Debian should not be "We The Developers Only Make It For Ourselves"; apparently the Debian developers should make it for BrucePerens instead.
Posted Nov 17, 2014 19:08 UTC (Mon)
by rahvin (guest, #16953)
[Link] (4 responses)
If they forked as you suggest they would either thrive or die on their own merits and Debian would survive this.
Posted Nov 17, 2014 23:06 UTC (Mon)
by nix (subscriber, #2304)
[Link] (3 responses)
Posted Nov 17, 2014 23:18 UTC (Mon)
by seyman (subscriber, #1172)
[Link]
This is to be expected if you decide to fork a project with considerable human resources 4+ years after its initial release. Being more proactive would have required less effort.
Posted Nov 17, 2014 23:55 UTC (Mon)
by Thue (guest, #14277)
[Link] (1 responses)
Posted Nov 18, 2014 11:50 UTC (Tue)
by pabs (subscriber, #43278)
[Link]
Posted Nov 17, 2014 18:45 UTC (Mon)
by javispedro (guest, #83660)
[Link] (4 responses)
They're also the first non-RPM distribution to adopt it as default (with the glaring exception of Arch/Pacman). So I guess there is something different with Debian (and all of its derivatives).
Just for fun (and because I have popcorn to spare), I wonder what would happen today if someone requested a vote to decide whether to "upgrade" Debian to the RPM package format.
After all, there are few technical reasons to prefer one package format over another these days. And since part of the systemd rhetoric argues "standardization of distributions" to be among systemd's benefits, why not take this to the limit and move to RPM?
(Note I have no personal preference between any specific package format)
Posted Nov 17, 2014 22:05 UTC (Mon)
by vonbrand (subscriber, #4458)
[Link] (2 responses)
What does the RPM/deb divide have to do with this in the slightest? Next you will claim only emacs, not vi, systems have used systemd to date, and it is thus fundamentally at odds with vi...
Posted Nov 17, 2014 22:49 UTC (Mon)
by javispedro (guest, #83660)
[Link] (1 responses)
It's just the first other "highly philosophical, hardly technical" divide that I could think of where Debian was different from the other distros where systemd has been adopted without much ado. Feel free to discuss...
Posted Nov 18, 2014 2:24 UTC (Tue)
by jwakely (subscriber, #60262)
[Link]
Or maybe it's irrelevant.
Posted Nov 18, 2014 2:33 UTC (Tue)
by misc (subscriber, #73730)
[Link]
In fact, Fedora never tried to be everything to everybody, and neither was Arch, Opensuse or Mageia. Each of them didn't had a mandate that attracted people who wanted choice for the sake of choice.
Debian community however attracted this group of people and they are the ones who complain. Coupled along a huge community, you will find some bad apple there, and they were fueled by clickbait journalists who posted unfounded articles ( the harbringer of doom ). It is also a migration that started after Snowden revelations, who in turn pushed crazy conspiracy theories ( see the iguru blog ) in a new light, giving legitimacy to anything in the mind of some people. And then, I guess it just started to roll and fuel itself.
Posted Nov 17, 2014 20:17 UTC (Mon)
by HelloWorld (guest, #56129)
[Link]
Posted Nov 18, 2014 2:03 UTC (Tue)
by bronson (subscriber, #4806)
[Link]
> In short, I don't want to be that person who never does anything themselves, but who joins all the conversations to complain about how everything is being done.
Bruce, right now this sentence describes you perfectly.
Posted Nov 17, 2014 18:36 UTC (Mon)
by jb.1234abcd (guest, #95827)
[Link] (84 responses)
Yes, Sir. I commend you for telling us thru the flowers that ignoring
Here is the latest discovery of systemd's benign behavior:
And here is the copy of the GR again:
Choice 1: Packages may not (in general) require a specific init system
Read the rationale for it again.
jb
Posted Nov 17, 2014 18:48 UTC (Mon)
by torquay (guest, #92428)
[Link] (61 responses)
Yes, because everything is the fault of systemd, and no other software ever got a CVE. Especially not the OpenSSL package, which was very helpfully "improved" by Debian developers. And certainly not the bash shell, which didn't have a bug hiding for many years.
Posted Nov 17, 2014 19:02 UTC (Mon)
by jb.1234abcd (guest, #95827)
[Link]
The real story is here:
"But in fact systemd's aim is to replace core system components like
So replacing core DNS components of Linux in mass setups shows up on the horizon; at least it is attempted. Thats enough reason for us to look at the code."
jb
Posted Nov 17, 2014 19:34 UTC (Mon)
by luto (guest, #39314)
[Link] (59 responses)
I think that the existence of things like systemd-resolved under the systemd umbrella scares people, and quite rightly. Systemd, the PID 1 daemon, is pretty good. Systemd-resolved, the systemd-affiliated (whatever that means) DNS resolver, strikes many people, including me, as something that simply shouldn't exist. Not because systemd should keep its grubby paws off DNS, but because there are good, mature solutions that do the same thing (unbound, for example, and I'd be amazed if systemd-resolved is ever a credible competitor to unbound + dnssec-triggerd), and because DNS has an important set of security issues and mitigations that are well understood by the DNS community and have nothing whatsoever to do with Linux plumbing. One also wonders why systemd-resolved has a D-Bus API, when there are two well-defined standards (the perfectly fine UDP port 53 API and the awful nsswitch API). So perhaps systemd-resolved should be considered an experiment and no one should ever use it. No problem there, except that it's on the same mailing list and shares a git tree with systemd the PID 1 daemon. In fact, it's worse. The systemd 216 release notes start out saying that "systemd-resolved is now a pretty complete caching DNS and LLMNR stub resolver". For me, therein lies the problem. The systemd core developers don't seem to distinguish strongly enough between high-quality pieces of software (systemd as PID 1 or systemd-logind) and things like systemd-resolved that are, at best, experiments.
Posted Nov 17, 2014 20:18 UTC (Mon)
by rahulsundaram (subscriber, #21946)
[Link] (5 responses)
It gets used by other management software including but not limited to cockpit
Posted Nov 17, 2014 22:17 UTC (Mon)
by luto (guest, #39314)
[Link] (4 responses)
But the existence of a program that uses an API that shouldn't exist in the first place is not a justification for the existence of the API. To the contrary: it's a reason to ask what that program is doing using that API.
I fully admit that the glibc resolver is garbage and the nsswitch thing is even worse. That's *fine* -- point any async non-caching DNS library at whatever /etc/resolv.conf says to point at, and, when /etc/resolv.conf says to use 127.0.0.1, it'll use 127.0.0.1 and do exactly the right thing.
Posted Nov 17, 2014 23:53 UTC (Mon)
by rahulsundaram (subscriber, #21946)
[Link] (3 responses)
Posted Nov 18, 2014 0:02 UTC (Tue)
by luto (guest, #39314)
[Link] (2 responses)
Posted Nov 18, 2014 0:10 UTC (Tue)
by rahulsundaram (subscriber, #21946)
[Link] (1 responses)
Posted Nov 18, 2014 0:17 UTC (Tue)
by luto (guest, #39314)
[Link]
It is exactly this attitude that, I think, inspires so much irritation toward systemd. If something is better, great. If something is newer and more desktoppy, that's not a good reason to say "out with the old, in with the new".
I really, really, really hope that ping never starts to use D-Bus on my system.
Posted Nov 17, 2014 21:30 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Replacing resolved with unbound also is an interesting idea.
Posted Nov 17, 2014 22:08 UTC (Mon)
by mezcalero (subscriber, #45103)
[Link] (51 responses)
already from the basic design resolved is very different from unbound. resolved keeps a seperate "scope" for the DNS servers on each interface. A "scope" is a resolver state machine plus a cache. That way, we can neatly separate VPN DNS servers from internet DNS servers, and merge them transparently. That means that with resolved in the mix for the first time you don't lose access to your LAN's DNS names, fully automatically, without any manual hacks. Also, as interfaces come and go their caches do too with this scheme, hence all the cache flushing complexity of dnssec-trigger doesn't exist at all. Then, because we actually implement LLMNR and DNS int he same stack (as well as mDNS very soon), we can transparently merge those protocols too.
unbound is a full DNS server, while resolved has a very clear focus on clients (where "client" actually is 99% of all machines, since only very few really serve DNS...). We want to solve the problems that clients today have with the name service. This is *very* different from what an full DNS server like unbound want to solve.
I hope this explains at least partially the reason for resolved.
Lennart
Posted Nov 17, 2014 22:14 UTC (Mon)
by luto (guest, #39314)
[Link] (46 responses)
It doesn't, however, seem to be really sufficient justification for reimplementing DNS or, worse, for creating a new API for applications to use. DNS over UDP port 53 is a fantastic asynchronous API. Let applications talk to the system resolver using DNS over UDP port 53 on localhost.
Once applications start using the systemd-resolved D-Bus API, then we have a mess. If something else ends up being a better implementation of a client DNS daemon that systemd-resolved (and unbound is, right now, by any sensible measure that includes security as a criterion), then that daemon will need to reimplement the D-Bus API, and that sucks for everyone involved.
Posted Nov 17, 2014 23:36 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (3 responses)
Posted Nov 17, 2014 23:42 UTC (Mon)
by luto (guest, #39314)
[Link] (2 responses)
Posted Nov 18, 2014 0:02 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Posted Nov 18, 2014 0:05 UTC (Tue)
by luto (guest, #39314)
[Link]
What are you suggesting doing? In the scenario you're thinking of, why does D-Bus work, and why does UDP port 53 not work?
Posted Nov 17, 2014 23:38 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (34 responses)
Posted Nov 17, 2014 23:48 UTC (Mon)
by luto (guest, #39314)
[Link] (31 responses)
I think you're entirely misunderstanding what I'm saying. Applications should link a DNS library (glibc if the standard interface is okay and something else if not) and leave DNSSEC validation to the next hop, which should be a trusted daemon on localhost.
Posted Nov 18, 2014 0:09 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (30 responses)
Posted Nov 18, 2014 0:20 UTC (Tue)
by luto (guest, #39314)
[Link] (2 responses)
This is seriously getting ridiculous. DNS works very well to ask for name resolution. If you really want to add a first try using DNS over dgram or seqpacket sockets at /run/dns.socket, fine. But the only justifications I've seen for using D-Bus are that it's "nicer" and "newer". This is absurd.
Posted Nov 18, 2014 0:57 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
And DBUS is nicer because it's a nicer protocol in itself (it has formal service interfaces, for example).
Posted Nov 18, 2014 17:28 UTC (Tue)
by jra (subscriber, #55261)
[Link]
That way gets you nice versioned interfaces, and a protocol so complex you'll *never* be free of CVE's :-).
Posted Nov 18, 2014 22:18 UTC (Tue)
by paulj (subscriber, #341)
[Link] (26 responses)
If you need to add a layer, to interpose for some reason, e.g. for dealing with different locations, using DNS does that for free.
Adding D-Bus just adds an unnecessary protocol layer. Your resolver library now has to implement DNS *and* DBus, *and* it must shuffle data between and correctly glue together 2 quite different domains.
That's a whole lot of added complexity. What does it buy you? The ultimate consumer just gets the same C interface both ways!
Posted Nov 18, 2014 23:56 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (25 responses)
> Adding D-Bus just adds an unnecessary protocol layer. Your resolver library now has to implement DNS *and* DBus, *and* it must shuffle data between and correctly glue together 2 quite different domains.
1) Use the old crappy GAI interface of glibc. It can be left unchanged or eventually moved to a DBUS backend.
2) If you need something fast and asynchronous then you can use something like c-ares but that's a lot of C code that requires some kind of event loop dispatching. Also, c-ares is not standard and you need to depend on it.
3) Use modern DBUS-based interface which you can use through a standard system DBUS library. No need for special code to parse the answer and DBUS can be easily monitored, namespaced or delegated to containers (once kdbus is done).
Personally, I like the option 3, because it allows me to remove some of the cruft and use a standardized type-safe asynchronous interface.
Posted Nov 19, 2014 0:28 UTC (Wed)
by luto (guest, #39314)
[Link] (3 responses)
And the containerization argument seems entirely backwards to me. I think I'm one of about two people who aren't systemd developers who have reviewed the kdbus container-related code, and I know quite a lot about Linux's container technology. Kdbus does not magically work well in containers in its current incarnation.
Aside from any debates over how well kdbus works in containers, if you happen to be in a container that shares the host's network namespace, then UDP port 53 Just Works (tm), whereas dbus or kdbus will require active effort to delegate usefully. If you're in a container that does not share the host network namespace, then you have to figure out what semantics you want regardless of the DNS resolution protocol you use, but a likely answer is that your containers will get IP addresses through DHCP, and DHCP has a standardized mechanism for making DNS work, whereas there is no standard for getting your container to speak dbus to the host.
And how exactly is org.freedesktop.resolve1 more standardized than DNS?
Posted Nov 19, 2014 0:41 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
And DBUS is likely going to be THE interface for interprocess communication on Linux.
> And how exactly is org.freedesktop.resolve1 more standardized than DNS?
Posted Nov 19, 2014 0:43 UTC (Wed)
by dlang (guest, #313)
[Link] (1 responses)
I sure hope not.
Posted Nov 19, 2014 9:30 UTC (Wed)
by smurf (subscriber, #17840)
[Link]
Besides, one might argue that it already is.
Posted Nov 19, 2014 0:36 UTC (Wed)
by dlang (guest, #313)
[Link] (20 responses)
DNS is designed for a hierarchy of resolvers, as such adding one more to the stack makes no difference and is routinely done.
Posted Nov 19, 2014 0:42 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (19 responses)
Posted Nov 19, 2014 0:45 UTC (Wed)
by dlang (guest, #313)
[Link] (18 responses)
I don't expect that the systemd version will satisfy the DNS experts any more than they satisfy the logging experts.
It's easy to do something that works under 'normal' laptop conditions, but it gets much harder to 'do the right thing' in more complex situations (where 'the right thing' may depend on local policies)
Posted Nov 19, 2014 0:55 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (16 responses)
> It's easy to do something that works under 'normal' laptop conditions, but it gets much harder to 'do the right thing' in more complex situations (where 'the right thing' may depend on local policies)
Posted Nov 19, 2014 0:57 UTC (Wed)
by luto (guest, #39314)
[Link] (15 responses)
Does that mean that I shouldn't use client applications that use the dbus API in those conditions? If so, that's more reason to encourage client applications not to use the dbus API.
Posted Nov 19, 2014 1:26 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (14 responses)
Posted Nov 19, 2014 1:41 UTC (Wed)
by luto (guest, #39314)
[Link] (13 responses)
Do you mean a shim D-BUS server that doesn't exist? This is becoming absurdly complicated to prevent some new code from creating a series of regressions.
To restate what I tried to say from the beginning: I have no problem with the systemd project producing a local DNS resolver. I have a problem with systemd encouraging applications to speak to that resolver using D-Bus, and I have a problem with systemd encouraging people to *use* their resolver before it's adequately vetted for resistance to the standard set of well-known DNS security gotchas.
Posted Nov 19, 2014 1:52 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (7 responses)
And using DHCP-provided resolvers is fraught with pathological edge cases. I've seen those nice captive portals in hotels resolving our internal URLs to their captive page, for example.
So there are two proposed solutions:
Right now you can't depend on EITHER of these. In future I'd certainly prefer option 2.
Posted Nov 19, 2014 1:57 UTC (Wed)
by luto (guest, #39314)
[Link] (3 responses)
I think you've misrepresented the dichotomy. Choice 1 is great, and using systemd-resolved probably satisfies it, as does dnssec-triggerd.
If choice 2 is actually intended to satisfy you, you may have meant "mandate a resolved DBUS service" because "make a resolved DBUS service" doesn't actually solve the guaranteed-available DNSSEC-verifying resolver problem. I, and probably many others, think that's a terrible idea.
Also, using DHCP-provided resolvers in a container that point at the container host's resolver doesn't have issues with captive portals. I was suggesting that, not that your laptop should blindly trust DHCP.
Posted Nov 19, 2014 2:11 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
It can even return DNSSEC validation information optionally for each query with possibility to force-ignore it. You can NOT do this even with localhost:53 without reimplementing all the DNSSEC signature chasing machinery.
> Also, using DHCP-provided resolvers in a container that point at the container host's resolver doesn't have issues with captive portals. I was suggesting that, not that your laptop should blindly trust DHCP.
Your options right now:
In future:
Posted Nov 19, 2014 17:56 UTC (Wed)
by nix (subscriber, #2304)
[Link] (1 responses)
Your options right now:
1) Use GAI interface of glibc and hope for the best.
2) Actually, that's it.
Posted Nov 19, 2014 20:22 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link]
I've seen hotel login pages inside applications too many times. This is such a nice attack vector (hosted browser widgets are usually not sandboxed) that I wonder why nobody has tried it yet.
So yes, I definitely prefer to have something newer than gethostbyname().
Posted Nov 19, 2014 5:21 UTC (Wed)
by dlang (guest, #313)
[Link] (2 responses)
you can't get answers via D-BUS, you have to use DNS to get off of the box anyway.
Posted Nov 19, 2014 5:36 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Then we can have a fault handler using DBUS signals and the desktop environment (the correct one!) can subscribe to it and do appropriate actions.
Posted Nov 19, 2014 9:35 UTC (Wed)
by smurf (subscriber, #17840)
[Link]
… which requires dbus anyway, for desktop environment integration.
Posted Nov 21, 2014 0:40 UTC (Fri)
by mezcalero (subscriber, #45103)
[Link] (4 responses)
resolved is about 2 months old, and we have not pushed any distro to adopt it yet. When the time comes I will submit a feature for Fedora. Hence: I really don't see why people would care about resolved right now, especially regarding that bullshit CVE. Some dude at Suse who apparently needed to get his monthly CVE quota up filed that. It's really moronic of him, given that this is not used anywhere, and we are not suggesting that people should, right now.
So, I am explicitly *not* encouraging people to use our resolver right now. And I won't until it speaks mDNS and DNSSEC at least. I will not propose anything to Fedora before it is substantially better than the other options, because I prefer arguing cases I have a clear chance to win.
Please don't make things up, please.
Lennart
Posted Nov 21, 2014 0:50 UTC (Fri)
by rodgerd (guest, #58896)
[Link]
Maybe you should try getting back on the "technical information and facts" and off the "personal nastiness" track.
Posted Nov 21, 2014 1:03 UTC (Fri)
by luto (guest, #39314)
[Link] (2 responses)
In general, I find it hard to understand what the status of all the systemd pieces are wrt readiness from information available in the systemd release announcements. Fedora benefits from your involvement, but I don't know how well this works for other distros. I'm not saying that I have evidence that it's a problem -- I just think that, if I were running a different distribution, I wouldn't know where to look for guidance on what to do with all the things in systemd.
Does resolved have NSS/gai integration right now? I tried to find it and I failed, but that could just mean that I'm bad at using grep.
What I really think we should have is some kind of useful asynchronous interface to NSS or to something NSS-like that everyone can agree on, and I think it should expose some extra information over what is available now.
1. DNSSEC status. This seems to be completely missing from gai AFAICT. It's available over UDP port 53 if you trust the server, and it's available over the dbus interface if you're using it.
2. Does the local resolver have a cache? Clients should just not cache at all if the local resolver caches, because the local resolver should always do a better job.
I don't think that the libc and other low-level API authors will be thrilled to integrate specifically to a DBUS api, since it's not really portable enough, and since there could be any number of reasons why competing local resolver implementations wouldn't implement it (awkward containerization issues being one example). Port 53 to localhost (TCP or UDP) with an nsswitch.conf, gai.conf, or resolv.conf annotation saying that the server is well behaved would be pretty close to good enough, and the BSDs, musl, etc might go for it.
FWIW, I've been thinking about writing a little web-browser-in-a-sandbox for dealing with captive portals. All the kernel bits are available today, no kdbus needed. The only real missing piece is how to tell the sandbox how it's supposed to talk to the lying DNS server, and possibly some fancy NetworkManager feature to stick authentication-needing interfaces into a separate network namespace until they're ready.
It would look kind of like the selinux sandbox, but it would share no code at all. (Also, it would work. The selinux sandbox has, sadly, been completely non-functional for graphical use for months. Grumble.)
If you want to discuss this, feel free to ping me.
Posted Nov 21, 2014 1:27 UTC (Fri)
by jspaleta (subscriber, #50639)
[Link]
I dont have a problem with distro venders building those bits and dropping them on the system disabled by default, but it would be good if admins exploring the systemd functionality had a breadcrumb on system to see as which utilities as considered experimental or not recommended for daily use yet.
-jef
Posted Nov 21, 2014 11:46 UTC (Fri)
by mezcalero (subscriber, #45103)
[Link]
libsystemd contains sd-resolve which is an asynchronous wrapper around gai, done right. Again, we should not bypass NSS, since that's where other NSS modules can plug into.
resolved is the DNS cache, nss-resolve just wraps the bus calls, that's all, it does not cache in the NSS module host process...
Posted Nov 19, 2014 17:54 UTC (Wed)
by nix (subscriber, #2304)
[Link]
Posted Nov 18, 2014 0:06 UTC (Tue)
by smurf (subscriber, #17840)
[Link] (1 responses)
Doesn't change the fact that, sorry, UDP is a terrible protocol. As a client I do not want to deal with timeouts and retransmissions, retrying with TCP when the answer happens to be too large, all the interesting and not-so-interesting flags one can set, the heuristics we need these days to make sure that nobody is spoofing the answer or poisoning the cache, caching, etc.
Also, it's too much useless work. Did you check recently how much crap a client goes through when it resolves an address? open+parse nsswitch, open+parse hosts, perhaps try talking to nscd, open+parse resolvconf, open socket, finally get around to actually asking a server, retransmit to whatever other server is in resolvconf, pick apart the result. Every. Single. Time. And most clients don't do any caching either.
Posted Nov 18, 2014 0:15 UTC (Tue)
by luto (guest, #39314)
[Link]
If you install an nsswitch module that speaks D-Bus, you still have to do all that crap. And if you write a program that bypasses resolv.conf and nsswitch.conf, then you can use exactly the same mechanism to simplify talking to the local port 53 resolver. (And I suspect that libadns, etc already do this.)
Posted Nov 18, 2014 0:20 UTC (Tue)
by mezcalero (subscriber, #45103)
[Link] (6 responses)
DNS is not really that useful as a local protocol. Sure, you can get away with a simple implementation for trivial cases, but it's actually a mess. The problem with large packets (and fallback to TCP/EDNS0) is one issue. Or the problem of international domain names or handling LLMNR and mDNS transparently just becomes madness. And if you then want to add sane support for internationalized domain names to all of that you'll end up going crazy, since classic DNS uses IDNA while mDNS and LLMNR use UTF8 encoding. Or think about link-local addressing: to connect to an ipv6 link-local address you need to know the appropriate scope id (i.e. ifindex), but you cannot reasonably communicate that via DNS. In fact you actually lose the entire context info: if you resolve something and then want to go on from there, it's a good idea to know which interface this is about. Or think about DNSSEC. Sure you can encode validity of the DNSSEC bits in the DNS header, but for apps it's really difficult to figure out when to trust it (or when the trust status is unknown), since the usual resolver APIs won't tell you whether a local DNS server verified it or only a remote one you cannot trust.
Really, DNS is not what you want to use locally. We use D-Bus for this, which allows us to neatly do sandboxing with it. We have a resonably nice DNS API, accessible from pretty much any language, naturally asynchronously, as well as NSS/gai.
You are of course welcome to disagree on these reasons. Just one favour I'd like to ask you for: grant us as much as doing your homework first, and do not automatically imply we were idiots, just because we are not part of what you call the "DNS community". (which is BS btw, as I wrote Avahi is you might remember, and have been doing DNS stuff since a long time due to that...)
Lennart
Posted Nov 18, 2014 0:32 UTC (Tue)
by luto (guest, #39314)
[Link] (5 responses)
The point about the ifindex context stuff is the first reasonable argument argument I've heard from anyone about why DNS is not a perfect protocol for local use. The rest is IMO a bunch of bogus straw men. Let's see:
Maybe it pays to define a new EDNS extension that is only used for local resolvers and conveys the IPv6 scope information. And using a socket with a well-known name would have some benefits, and would integrate into existing client libraries without significant changes. But DNS is inherently cross-platform, these problems need to be solved on all platforms, and I find it hard to believe that enough of the stakeholders (which include browser vendors!) will buy in if the answer is "use D-Bus".
Posted Nov 18, 2014 2:11 UTC (Tue)
by smurf (subscriber, #17840)
[Link] (2 responses)
Dbus has an important advantage: implementing the client side of that API is dead simple. Work required to port the API to another programming language: also (almost) None, pretty much every language already has dbus bindings.
As for the rest: It's one thing to dispute technical arguments. It's quite another to assume bad faith and a hidden agenda, which is what you do when you talk about bunches of bogus strawmen.
Your arguments may or may not be reasonable. Your attitude is not, and you don't exactly improve your chances of convincing anybody that your approach would be better than the one chosen by the systemd people either.
Just sayin'.
Posted Nov 18, 2014 2:21 UTC (Tue)
by luto (guest, #39314)
[Link] (1 responses)
And I can give examples of sandbox and container use cases in which D-Bus, as it works today, is problematic.
Also, I'm pretty sure this is the most technical discussion in this massive thread. I'm disappointed that you're putting my personal attitude into the mix.
Posted Nov 18, 2014 11:18 UTC (Tue)
by smurf (subscriber, #17840)
[Link]
Secondary reason: this is really the wrong forum to do that in.
Posted Nov 21, 2014 0:48 UTC (Fri)
by mezcalero (subscriber, #45103)
[Link] (1 responses)
And no, I will not translate LLMNR and mDNS and DNS in any way. The semantics are too different (mDNS allows long-running queiries that collect responses, you cannot translate that to DNS at all, conceptually). I will not implement such hacks. Also, the whole point of IDNA support in glibc/resolved is to allow apps to pass in host names in their locale/UTF-8, hence transcoding to IDNA is completely off...
Note that firefox is already on the bus. however, i don't think firefox should really talk our bus interfaces. Instead it should go via NSS/gai, to ensure the other NSS modules are honoured too.
Posted Nov 25, 2014 22:05 UTC (Tue)
by nix (subscriber, #2304)
[Link]
Posted Nov 18, 2014 4:49 UTC (Tue)
by foom (subscriber, #14868)
[Link] (3 responses)
Yes, unbound exists. Yes, dnsmasq exists. Yes, dnssec-trigger exists. (Maybe Fedora will even be deploying unbound+dnssec-trigger in F22? At least, that was a plan at one point). But, even if your'e running a distro that has decided to pull such in by default, it still really feels like everything's been stuck together with duct-tape and bailing wire.
Here again, the major value that systemd will provide is not that it'll be the first, or only, to implement some feature or other, but that it will (I expect) take ownership of the WHOLE problem and make sure that we end up with a solution that really works together in a sane way.
The systemd team is not just writing one component and tossing it over the wall, but, has a real desire to own the whole problem, and develop a set of infrastructure that works together as a system. Having a team working on linux userspace like that is really a big deal, and a huge boon.
Thanks.
-- A Debian User, running systemd, and loving it, ever since the first day after a dist-upgrade, when "systemctl status" told me why a non-distro-packaged server wasn't running, despite that the init script had "successfully" started it (FTR: it was because of the perl 5.20 upgrade.)
Posted Nov 18, 2014 11:21 UTC (Tue)
by smurf (subscriber, #17840)
[Link] (1 responses)
Posted Nov 19, 2014 3:36 UTC (Wed)
by foom (subscriber, #14868)
[Link]
(On the other hand, one might either bail OR bale out of a plane, depending on which part of the english speaking world one is in.)
Posted Nov 19, 2014 23:02 UTC (Wed)
by kleptog (subscriber, #1183)
[Link]
Thanks for saying this. It put into words exactly what I was thinking. I look at all the people defending the status quo and then look at the systems I maintain, held together by zillions of incompatible config files and incomprehensible shell scripts, and boggle at how anyone could think that the status quo is *good*.
Functional is the best label I can give the status quo, but it's oh so fragile.
Systemd has the goal to clean this up into something nice. It might not work perfectly the first time and no doubt some mistakes will be made, but damnit, at least someone is working on the problem.
Posted Nov 17, 2014 19:08 UTC (Mon)
by mrshiny (guest, #4266)
[Link]
Talk about throwing the baby out with the bathwater.
You could, you know, just fix the bug instead? Or not use that optional component if it bothers you that much.
Posted Nov 17, 2014 23:59 UTC (Mon)
by Doogie (guest, #59626)
[Link]
Posted Nov 18, 2014 22:10 UTC (Tue)
by paulj (subscriber, #341)
[Link] (19 responses)
I was neutral-leaning-to-favourable on the systemd-as-init thing. However, the steady flow of critical CVEs due to systemd people badly re-implementing ever greater swathes of the Linux/Unix software world and network protocols gives me great pause.
Posted Nov 19, 2014 17:48 UTC (Wed)
by nix (subscriber, #2304)
[Link] (18 responses)
Posted Nov 19, 2014 20:22 UTC (Wed)
by zdzichu (subscriber, #17118)
[Link]
Apart from non-existing "CVE stream" (another act of trolling), please note that systemd-resolved behaviour is not a CVE even. It wasn't deemed CVE-worthy, despite Red Hat pushing for CVE assigment.
Posted Nov 19, 2014 20:31 UTC (Wed)
by paulj (subscriber, #341)
[Link] (16 responses)
journald remote input handling is some scarey code. Direct pointer-twiddling string parsing of network input, with no bounded-buffer abstraction interposed to sanity check buffer access like you might think would be a good idea in this day and age. Real 1990s style network parsing code, but written in 2010+:
http://cgit.freedesktop.org/systemd/systemd/tree/src/jour...
Thankfully not that complex, but still not exactly confidence inspiring.
Posted Nov 25, 2014 21:58 UTC (Tue)
by nix (subscriber, #2304)
[Link] (14 responses)
Posted Nov 26, 2014 8:05 UTC (Wed)
by smurf (subscriber, #17840)
[Link] (13 responses)
Oh yes, and wait for people to complain about Yet Another Unnecessary Dependency. :-/
Posted Dec 1, 2014 18:34 UTC (Mon)
by paulj (subscriber, #341)
[Link] (12 responses)
It's 2014: Non-sandboxed code and, especially, privileged networking code, that parses untrusted input should *NOT* be directly twiddling pointers into buffers based on that input. It should have a parser that tries to separate syntactical parsing/checking from semantic actions, and that parser should access input through some kind of bounds-checking abstraction layer.
Posted Dec 1, 2014 19:24 UTC (Mon)
by smurf (subscriber, #17840)
[Link] (11 responses)
Seriously, I have stared at that code for quite some time and couldn't find an exploit that isn't prevented by an assert() that's already there, so don't dismiss them too quickly.
You might have CPU to burn, to run everything through an abstract parser and a bunch of function calls and allocations or whatever, but not every system has.
Besides, if it was using an abstraction layer, then the complaint would be that it's much too complicated for the simple job of receiving a couple of lines of key+value input.
Anyway: do you have something in mind that'd be useable – or should we write that layer plus parser from scratch, in your esteemed opinion?
Posted Dec 1, 2014 20:08 UTC (Mon)
by mathstuf (subscriber, #69389)
[Link] (3 responses)
Posted Dec 1, 2014 20:22 UTC (Mon)
by raven667 (subscriber, #5198)
[Link] (1 responses)
Posted Dec 4, 2014 18:56 UTC (Thu)
by paulj (subscriber, #341)
[Link]
Posted Dec 2, 2014 5:56 UTC (Tue)
by smurf (subscriber, #17840)
[Link]
Posted Dec 1, 2014 20:44 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (4 responses)
Posted Dec 2, 2014 6:35 UTC (Tue)
by smurf (subscriber, #17840)
[Link] (3 responses)
(F)lex won't work here. Besides its inefficiency, it wants a file descriptor or a complete buffer, so you can't feed it from your event loop; it raises a fatal error when it runs into problems (memory allocation, invalid input …); you can't tell it that there's a maximum line/buffer length; and probably some other problems I didn't see after looking at y.lex.c for less that five minutes.
I'm sure there's some other parser out there which doesn't have some of these limitations, but I'm also quite sure that if you're in a situation where you need to avoid all of them, you get to roll your own.
My personal translation of the original post is "I don't like systemd, so let's find some code to flame away at, assuming a priori that its authors did not want to consider the issues raised, thus concluding that the only reason they did it the way they did is because they're stupid and/or arrogant". An attitude we've seen quite a lot of, lately.
Posted Dec 2, 2014 6:58 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
I'd certainly prefer if systemd was written in something like Rust.
Posted Dec 2, 2014 11:19 UTC (Tue)
by gracinet (guest, #89400)
[Link]
Posted Dec 3, 2014 9:30 UTC (Wed)
by paulj (subscriber, #341)
[Link]
A simple abstraction to allow safe retrieval of input from a buffer, by doing so through functions that can check access against (private) buffer properties that can be checked, rather than direct pointer access, is pretty easy to do. For me, it's important that, at least in this day and age, a C programme uses such an abstraction when parsing untrusted input - *especially* network input!
That a new project either doesn't have such an abstraction, or doesn't require that abstraction be used, but is happy to accept code with direct pointer-twiddling in the parsing of untrusted input, and in a core part of the project, makes me wary of it.
Also, that's a brilliant way of dismissing a technical complaint. So even technical complaints about systemd are to be dismissed as unreasonable? I may have to be more careful from now on in accepting any hearsay about how much unreasonable criticism systemd attracts.
FWIW, I like bits of systemd (the init bit, e.g) but I dislike some bits of its code and project ethos. Longer post here: http://lwn.net/Articles/623842/
Posted Dec 1, 2014 21:22 UTC (Mon)
by zlynx (guest, #2285)
[Link] (1 responses)
assert() is for debugging and development only. It vanishes in release builds. -DNDEBUG is often defined as an extra CFLAG in Gentoo builds for example.
Posted Dec 2, 2014 6:38 UTC (Tue)
by smurf (subscriber, #17840)
[Link]
Posted Nov 26, 2014 4:43 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link]
Posted Nov 17, 2014 19:17 UTC (Mon)
by ballombe (subscriber, #9523)
[Link] (4 responses)
But, for various reason, nobody worked on it, and now we are during the freeze without a technical policy and a transition document.
This leads to the present situation where nobody know what will happen, nobody feel empowered to make a decision, everything need to go to the TC, and FUD is reigning supreme.
This results in a state which is usually described by an English expression involving a domesticated bird who have lost the upper part of its body.
Posted Nov 17, 2014 22:14 UTC (Mon)
by micka (subscriber, #38720)
[Link] (3 responses)
Hum, sorry, I suppose every native english speaker would know that expression. Maybe even I know it but I can't seem to guess.
Could you please be more explicit ?
Posted Nov 17, 2014 22:20 UTC (Mon)
by HelloWorld (guest, #56129)
[Link] (2 responses)
Posted Nov 17, 2014 23:48 UTC (Mon)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
Posted Nov 18, 2014 10:14 UTC (Tue)
by micka (subscriber, #38720)
[Link]
Posted Nov 18, 2014 0:13 UTC (Tue)
by HelloWorld (guest, #56129)
[Link] (1 responses)
Posted Nov 19, 2014 2:20 UTC (Wed)
by flussence (guest, #85566)
[Link]
Posted Nov 18, 2014 13:07 UTC (Tue)
by gb (subscriber, #58328)
[Link] (7 responses)
It's obvious that Linux growing a lot and old - and to this point it only re-implemented old UNIX ideas. And were very successful in that, but Linux simply overgrow UNIX and should step into new land of innovation and creating the new standards. This is very important and unavoidable step, but it's also important to not make a mistake here, equally important to not to spend too much time in discussions like perl6 did.
But from that I see in systemd - that is wrong way to create new standards and wrong standards. Wrong pace. Wrong idea to reinvent wheel in all possible cases. Wrong people in head of it (init system dev, especially on salary must be able to build proper relations with kernel community!). Wrong architecture - high level of the coupling really reduce innovation. Wrong idea to push systemd via users (look, with systemd your boot will be faster! software packages would be magically installed into the system directly from devlopers!). Wrong usage of the social technology (Letter convincing that kernel community is sick).
I am in no way to blame Red Hat - they did to Linux much more than anyone else, and a have a lot of respect, but they are the corporation with huge profit and I am not aware of their decision-making processes. What is the reason they want to lock Linux into systemd? Is that really innovation? Who knows.
I am just ordinary developer who is using Linux for >10 years, so it's possible I am totally wrong, just expressing some ideas =)
Posted Nov 18, 2014 14:27 UTC (Tue)
by johannbg (guest, #65743)
[Link]
Feel free to verify this via gitlog if you are under the assumption that Red Hat somehow dictates,dominates and directs, the direction and or contribution that take place in the systemd community to see how flawed this assumption is.
Posted Nov 18, 2014 16:40 UTC (Tue)
by mezcalero (subscriber, #45103)
[Link] (5 responses)
I also have serious doubts our CEO is bothered too much about systemd, or even knows about it...
Posted Nov 18, 2014 18:31 UTC (Tue)
by gb (subscriber, #58328)
[Link] (4 responses)
Good news is that this cuts off a lot of tricky possibilities, so you guys just sincerely believe that systemd is good thing - and there is a chance that course may be changed due to good will of the individuals.
Bad news is that I expected some corporate behavior from Red Hat. Like planning the Linux development direction ahead. It's dangerous for ship to sail through without any direction and plans for future.
I guess you could also put some light on how decision were made to create systemd and to switch Fedora and then RHEL7 to systemd? Was it just LP stand up and told 'upstart has a lot of stupid limitations, I did systemd let's use it'? Or something else? Could you please - very interesting =)
Posted Nov 18, 2014 18:43 UTC (Tue)
by mjg59 (subscriber, #23239)
[Link]
Posted Nov 19, 2014 17:45 UTC (Wed)
by nix (subscriber, #2304)
[Link]
I don't think so.
RH doesn't *need* to 'corporately' direct where engineering effort goes on this level, thanks. It's working perfectly well without it.
Posted Nov 19, 2014 18:21 UTC (Wed)
by luya (subscriber, #50741)
[Link] (1 responses)
Reading this post should like someone with so much dislike for a free and open source company is blinded by his/her own belief and deliberate ignorance. mjg59 (Matthew Garrett) puts the information about which is publicly available.
https://fedoraproject.org/wiki/Features/systemd Mezcalero (Lennard Poettering) posted his rational about systemd and upstart shortcoming on his blog four years ago.
http://0pointer.de/blog/projects/systemd.html Your homework is to educate yourself and come back posting well informed. Remember this is LWN where majority of false arguments failed against well informed posters.
Posted Nov 19, 2014 20:09 UTC (Wed)
by gb (subscriber, #58328)
[Link]
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
If anybody has any clues about my system, when I do a mount ...
/dev/md127 on / ...
"/dev/md127 not found"
)
Wol
Yet another systemd fiasco
Yet another systemd fiasco
> Gnome would be absolutely happy to have a consolekit replacement they could use as an alternative but the one that had existed died with no active developers and finally had to be abandoned by Gnome because of bitrot.
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
sysvinit and mount
sysvinit and mount
Yet another systemd fiasco
NFS dependencies
Yet another systemd fiasco
Yet another systemd fiasco
udevadm trigger
That will make sure all devices exist in /dev.
The real name of the device is "block device 9,127" though Linux can use the name "md127" in some circumstances
Yet another systemd fiasco
Wol
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
The Pi has an ARMv6+VFP processor. Debian's binaries for "armhf" (hardware floating-point) are compiled for ARMv7 and won't run on the Pi's processor; Raspbian, on the other hand, is compiled for ARMv6+VFP so that it will run on the Pi.
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
The "death threat" (singular) was quite unambiguously a joke.
This is the other problem with systemd (the first being its extreme invasiveness): the entire culture surrounding it is nothing but hyperbole and propaganda.
Re: "Death Threats"
Re: "Death Threats"
Re: "Death Threats"
Yet another systemd fiasco
Yet another systemd fiasco
One ring to rule them all...
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
One Fuehrer, One Volk, One Lied, ...
You underestimate Fedora/RH/systemd devs and their respect for the FHS and
the rest of us !
"With this in mind, I would like the FPC to consider a packaging guideline stating that packages must not, without a specific exception, install non-world-readable files under /usr."
"I disagree with the proposal. The FHS definition of /usr, shareable read-only data, does not imply anything about world-readability."
In the meantime, enjoy your tea ...
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
1. "a person with a psychopathic personality whose behavior is antisocial, often criminal, and who lacks a sense of moral responsibility or social conscience."
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
…or anyone who has a clue about what the f*ck they're talking about.
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
https://www.youtube.com/watch?v=PmTUW-owa2w
Yet another systemd fiasco
Yet another systemd fiasco
The only threat I've ever received in this community is famous, so I won't repeat it here.
Let me guess. A job offer from Microsoft?
Just kidding.
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
So what do you suggest? Modularizing systemd is impossible because it's ALREADY modular.
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
We see systemd assume more and more functions. Functions that at least visibly are not related to init in any visible way. Because of the way systemd is designed, reusing these features while using other init systems becomes _hard_ (e.g. systemd-shim). Why can't e.g. localed be an entirely separate program without any systemd dependencies? That is causing _us_ to do more work.
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
value on a big init or an init daemon confined by a cgroup."
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Socket activation, compatible with systemd's, was implemented in a few lines of ruby in https://felipec.wordpress.com/tag/finit/
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Wol
Yet another systemd fiasco
Other distros and init systems which already rewrote their init scripts already have declarative scripts that would fit in half-a-Tweet (<80 chars).
Yet another systemd fiasco
No, you're not. Systemd doesn't support extended actions like 'reload-check' but otherwise systemd's units are often richer in functionality.
Yet another systemd fiasco
You haven't proved that yet...
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/n...
Since you used Gentoo as an example, it should be noted that only 4 initscripts actually chroot on their own; containers and chroots are hardly used in Gentoo to confine daemons, but rather SELinux (see hardened Gentoo). It's not surprising that functions.sh is lacking wrappers to chroot().
Yet another systemd fiasco
Well, do try to do it. It's not easy as it sounds.
And ALL of that is not necessary for systemd.
Systemd can open the requisite sockets and pass them to BIND. Can your initscripts do this?
No, it doesn't.
So how do you run a BIND with SELinux hardening? What is used to sanitize the environment so that user's labels do not contaminate its environment?
So please, do write such a script. For all the years of systemd flaming, sysv advocates keep telling that "it's just a script library away" without ever actually trying to do it.
Yet another systemd fiasco
> And ALL of that is not necessary for systemd.
Which is exactly why the systemd chrooted BIND script is also a fail:
http://pkgs.fedoraproject.org/cgit/bind.git/tree/setup-na...
I believe we've already gone through this. Yes, systemd has some new features (other init systems have other features); but the simplification of initscripts mostly comes because those initscripts are losing features, not gaining them.
The Gentoo init script clearly clearly does some checks to warn the user if the configuration is inconsistent e.g. libgost enabled but not built. The Fedora unit file doesn't do it.
Irrelevant.
Yes, when we try to remove functionality/choice from init scripts, we get flamed (in a bug report or _not_), and therefore we're forced to revert to the complex, buggy, and old init scripts. This is part of what's happening here to systemd developers.
Yet another systemd fiasco
> Irrelevant.
Yet another systemd fiasco
No. The Gentoo initscript also calls named-checkconf but, in addition, does additional checks, which are the ones I'm talking about.
What has "how to do SELinux labeling properly" got to do with init systems? Fedora/systemd does SELinux too! If you want to discuss whether SELinux is better or not than containers feel free to do so, but I won't participate. It's way too off topic.
Yet another systemd fiasco
That's just a compatibility script for old BIND installations.
Systemd does great. It does not NEED a chroot at all because it can use namespacing. Simply add: ProtectSystem=full and tweak ReadWriteDirectories if required ( http://www.freedesktop.org/software/systemd/man/systemd.e... ).
If you start BIND by doing "/etc/init.d/named start" then its environment is contaminated with your security labels. So many little things that systemd does correctly...
Yet another systemd fiasco
*rolls eyes*. Ok, so it's looking more and more like a bad example, because the systemd unit file that actually chroots BIND, like the Gentoo one you quoted, does not exist?
"HardenedGentoo+OpenRC does great. It does not NEED a chroot at all because it can use SELinux."
Correct. But that's not how you actually invoke initscripts in Gentoo, you just use the openrc wrappers, which do the right thing (google init_run).
Yet another systemd fiasco
> Which is exactly why the systemd chrooted BIND script is also a fail
It's not needed. It's kept for compatibility with older installation.
So does systemd's script.
Irr-elephant? Hey, that'sa that answer. There's a whole lot of irrelephants in the circus.
Yeah, sure.
Yet another systemd fiasco
Yet another systemd fiasco
Now, apparently systemd dev's got it wrong ... kind of backwards !
After all, you said you are a software engineer.
http://lwn.net/Articles/589108/
Posted Mar 6, 2014 14:45 UTC (Thu) by jb.1234abcd
"In a socket-based activation scheme, the creation and
...
sharing (e.g. net or file system availability, etc)."
Posted Mar 10, 2014 6:32 UTC (Mon) by jb.1234abcd
"Well, yes. But it is not the only attribute of a socket,
...
universal (abstract), and then select tools that were primarily created
for it."
dependent on various socket attributes for each type of such a socket-driven service (daemon).
- because there are many service daemons possible (blocking, non-blocking,
connection-oriented, connectionless, asynchronous i/o, etc, it will be
necessary to maintain different source code for socket passing
mechanism in systemd and daemons for each of them.
- it creates source-code level coupling between sys init (systemd
executable) and services (daemons); moving some of this code to
a library will not solve the problem (it would just move the staff
around).
The source-code level dependency is a big no-no; one should avoid it like
a plague. It is a maintenance nightmare.
- it creates functional coupling between sys init and services (daemons)
beyond their config files.
Sys init should treat services as black boxes to prevent any entanglement and avoid problems with maintenance of both. Now any time you want to add even a prototype of a socket-based service daemon you have to write and compile C code for both, service and systemd; in old days it was enough to write shell code for a service.
decisions. Things are already happening, but Mr. Bruce Perens has to follow thru with his unofficial mandate.
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
If anyone carries this tradition on today, it's the rubyists.
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Surprise: We knew that already.
Yet another systemd fiasco
So many wrong things in one post.
Yet another systemd fiasco
Maintaining this status quo hardly requires more work.
Of course, as long as you don't upgrade anything such as the kernel, x/wayland, gnome, etc. In fact if you want such a world why not just stay with wheezy or sid for that matter?
If the Linux kernel can stop deprecating interfaces ConsoleKit shall keep working for the foreseeable future.
So the solution is to just stop changing the kernel! How simple. Why don't you post to lkml and tell them to just stop changing things. I'm sure they'll be happy to hear you speak for everyone.
There are init systems out there that are more featured than systemd
Prove it.
Why can't e.g. localed be an entirely separate program without any systemd dependencies?
Why don't you go to the mailing list and ask them? Why not offer your help to make it happen.
I just don't get why ...
So why not take it to their mailing list and ask them why and offer your help to make sure it doesn't happen. See, not hard at all.
Second and also quite importantly, "other people working for me" is exactly what everyone wants. I don't see anything wrong with this. This is the reason there are _users_ of open source at all!
I don't want anyone working for me, speak for yourself. I graciously accept their work and support the community of free software because I believe it's the right thing to do and I would never ever suggest that these volunteer developers owe me anything. That is the difference between you and me.
Yet another systemd fiasco
( I actually wrote part of that page )
Yet another systemd fiasco
>> systemd dependencies?
> Why not offer your help to make it happen.
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Wol
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
It's the entire premise of an entire new universe of APIs provided by a single project upon which the desktop is highly dependent and for which there are no alternatives.
You mean like X11?
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
The previous poster was suggesting that it would still be possible to replay systemd history one feature at a time.
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
See how well that works out for you,good luck.
Yet another systemd fiasco
> from the core). And it works well where the previous logging systems
> failed us.
Yet another systemd fiasco
Since this bugyilla report is apparently sometimes linked these days as an example how we wouldn't fix a major bug in systemd:
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
> at a later time when the file is read, there can be a large delay and
> therefor a lot of logs lost.
The file is "moved away" (actually renamed) but it is still read. So journald will not write to the file, but the clients (e.g. journalctl) will still look at the renamed file and read as much of it as possible.
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Dear Bruce
Dear Bruce
Dear Bruce
Dear Bruce
Dear Bruce
Dear Bruce
Dear Bruce
and
Lennart "why should we work around other peoples' bugs" Poettering.
Wol
Dear Bruce
Dear Bruce
Dear Bruce
Dear Bruce
Dear Bruce
Dear Bruce
Another way of phrasing it would be "Linus is a Finn who speaks Swedish".
Dear Bruce
Dear Bruce
Dear Bruce
( That's Danish/Swedish mixture )
Dear Bruce
Wol
Dear Bruce
Parsing English (or any natural language) is hard
A (Swedish speaking) Finn
whereas
"A Finn speaking Swedish" parses as
A Finn (speaking Swedish)
Parsing English (or any natural language) is hard
Parsing English (or any natural language) is hard
Dear Bruce
Dear Bruce
Wol
Dear Bruce
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
If we were to split the development of systemd over several projects it would entail a huge amount of extra work for us (the developers), at no apparent gain.
Yet another systemd fiasco
Yet another systemd fiasco
Just without the flames and bickering and negativity.
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yeah, except for the communities who actually *use* the stuff you're constantly bitching about, i. e. OpenSuse, Fedora, Arch, Mageia etc.
If that's your only complaint about systemd then it must be one fine piece of software.
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
And there is serious talk about it including a package system? And nobody sees anything wrong with this?
Yet another systemd fiasco
A user should not have to upgrade the entire operating system just to get an updated version of Inkscape et al.
Yet another systemd fiasco
Yet another systemd fiasco
Why not get the software directly from the vendor, and cut out the problematic middle man?
Yet another systemd fiasco
It's called "loose coupling". It *should* be possible for 3rd parties to distribute their software in binary form and have it run on any distro. You said yourself that free and proprietary software should coexist, and you know perfectly well that most distros aren't going to ship proprietary programs.
Yet another systemd fiasco
Yet another systemd fiasco
They don't do it because they can't, not because they don't want to.
http://www.youtube.com/watch?v=1Mg5_gxNXTo&t=6m48s
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Wol
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
This kind of comment only serves to prove that you have no f*cking clue about what marshalling even means.
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
-- said no one ever.
Yet another systemd fiasco
Yet another systemd fiasco
its monolithic entanglement is a barrier to innovation
You've said this it must be a couple of hundred times now, but have never provided a whit of evidence. I don't think there is any (and I don't much like the amount of stuff systemd is sucking in either).
Yet another systemd fiasco
Wow... just... wow. All that remains to do here is to quote a former german foreign minister:
http://politicalquotes.org/node/57845
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Wayland issues
Wayland issues
Wayland issues
Wayland issues
Wayland issues
Wayland issues
Yet another systemd fiasco
It's a kernel that even the lead developer himself called bloated and that does *way* too much by any objective measure. I know that you understand this perfectly well, and I trust you also know that systemd consists of several dozens of binaries and that the BSDs are all developed in an integrated fashion. So please, take your doublethink somewhere else.
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Did you take a look at KDE/Gnome? They can't agree on really basic things like how to embed a systray icon!
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
People promoting X give up / resign because of the hate.
People against X re-affirm themselves how bad X is because without X people there would have been no "controversy".
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
What I can't comprehend is why the complainers haven't forked yet. Forking exists exactly for cases like this. If "they" fork, then they can work productively towards their vision instead of spending their time bickering about things "forced upon 'us'".
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
Yet another systemd fiasco
We need to break the Ford Focus up into separate projects, resolve the issues that cause the largest objections to it, and make sure it plays with others (again, including horses instead of combustion engines).
Yet another systemd fiasco
Russ Allbery leaves the Debian technical committee
misjudged. By that, I don't mean the decisions themselves (my feelings on
that are more complicated, and I'm not going to get into that here), but
the way that they would be received and the ways they could be
interpreted. If I'd made either decision knowing that, it would be one
thing, but the reaction caught me by surprise in both cases, even though
in retrospect I should have recognized the problems."
resistance to systemd's take-no-prisoners approach to reshaping the ecosystem of free and open software, together with all of participants and contributors, was wrong.
http://news.gmane.org/gmane.comp.security.oss.general
12 Nov 12:15 2014 Sebastian Krahmer
CVE-request: systemd-resolved DNS cache poisoning
https://www.debian.org/vote/2014/vote_003
Today is the last day for Debian devs to vote.
Do it for yourselves and for the rest of us.
Vote Choice 1 !
Russ Allbery leaves the Debian technical committee
CVE-request: systemd-resolved DNS cache poisoning
...
Choice 1: Packages may not (in general) require a specific init system
Read the rationale for it again.
Russ Allbery leaves the Debian technical committee
14 Nov 09:42 2014 Sebastian Krahmer
CVE-request: systemd-resolved DNS cache poisoning
the system-resolver. What other reason could exist, that the proper nsswitch modules are provided as well or that the project itself exists at all?
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
This is a terrible idea. Each application will have to reimplement most of the DNS protocol (not easy!) including signature validation.
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
No it isn't. If you want to do something that is non-trivial socket-to-socket splicing then doing it correctly is a challenge for DNS.
Nope. You have the following scenarios:
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Except that c-ares is incompatible with MY event loop, for example. So it's not that easy.
Its standard is going to be a couple pages of DBUS schema with some comments. It's way easier to use and implement than DNS.
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
>I don't expect that the systemd version will satisfy the DNS experts
Lennart _IS_ a DNS expert and the author of avahi. So?
So don't use it in these conditions. Duh.
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
No, not QED because currently you can't depend on resolver even being available at all!
1) Always mandate a resolver on localhost:53.
2) Make a resolved DBUS service.
Russ Allbery leaves the Debian technical committee
> 1) Always mandate a resolver on localhost:53.
> 2) Make a resolved DBUS service.
Russ Allbery leaves the Debian technical committee
Actually, it does. A resolved service (since it barely exists today) can have DNSSEC state information baked-in in its responses.
Suppose that you're a game developer. You need to resolve the name of your server with a high scores table.
1) Use GAI interface of glibc and hope for the best.
2) Actually, that's it.
1) You use a nice DBUS interface to check that you're really resolving the name of your server by checking that DNSSEC signature is resolved correctly.
Russ Allbery leaves the Debian technical committee
Suppose that you're a game developer. You need to resolve the name of your server with a high scores table.
And then there's what such programs actually do, which is to start a new thread and use glibc's normal blocking non-GAI resolver functions from there. Y'know, it works. Even timeouts from the main thread work (glibc thread cancellation is known buggy but works well enough for this case).
Russ Allbery leaves the Debian technical committee
Not all languages can cleanly cancel a thread (try that in Java and watch for fireworks). And that still does nothing for DNSSEC validation.
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Thanks for resolved work
Thanks for resolved work
Thanks for resolved work
Thanks for resolved work
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
So abstract away
Or rewrite it and submit a patch. I don't know why you'd need a parser for finding a '=' character in a line of input, but what do I know …
So abstract away
So abstract away
So abstract away
So abstract away
So abstract away
So abstract away
So abstract away
So abstract away
So abstract away
So abstract away
So abstract away
It uses assert() for validating the code that validates (and processes) the input.
Any actual input (or other (malloc failing)) problems will result in an error return.
Russ Allbery leaves the Debian technical committee
The Debian TC systemd decision ended with:
Russ Allbery leaves the Debian technical committee
...
==== END OF RESOLUTION ====
Additional discussions regarding the technical policy necessary for
implementing this decision are anticipated and will be carried out via
the normal technical policy procedure.
At the time, there was little doubt such technical policy would be written: after all Russ Albery was the lead policy maintainer and part of the TC and a skilled policy writer. In retrospect it should have been made a precondition for the move to systemd.
Russ Allbery leaves the Debian technical committee
And googling didn't help.
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
I did search on google, but I was misleaded by a wrong assumption. I oversaw poultry and only thought about pets (canaries, parrots).
the saddest part is…
the saddest part is…
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
Russ Allbery leaves the Debian technical committee
guess you could also put some light on how decision were made to create systemd and to switch Fedora and then RHEL7 to systemd? Was it just LP stand up and told 'upstart has a lot of stupid limitations, I did systemd let's use it'? Or something else? Could you please - very interesting =)"
Russ Allbery leaves the Debian technical committee
