On 10/20/2013 04:55 AM, Samuli Suominen wrote: > > On 20/10/13 12:24, Daniel Campbell wrote: >> On 10/20/2013 02:37 AM, Samuli Suominen wrote: >>> On 20/10/13 09:34, Daniel Campbell wrote: >>>> On 10/19/2013 06:35 PM, Volker Armin Hemmann wrote: >>>>> Am 19.10.2013 17:02, schrieb Daniel Campbell: >>>>>> On 10/17/2013 11:27 PM, Mark David Dumlao wrote: >>>>>>> https://www.linux.com/news/featured-blogs/200-libby-clark/733595-all-about-the-linux-kernel-cgroups-redesign >>>>>>> >>>>>>> Not sure if I read that just right... but since nobody is doing cgroup >>>>>>> management besides systemd, in practice the cgroups implementation in >>>>>>> Linux wasn't very consistent. So since systemd is doing it, their work >>>>>>> is helping shape the kernel's cgroups api? >>>>>>> >>>>>>> Interesting... >>>>>>> >>>>>> >From my perspective it looks like systemd developers are trying to push >>>>>> their ideas into the kernel, almost like they intend to merge systemd >>>>>> *with* the kernel. >>>>> from what I read in the article cgroups are a mess and are cleaned up >>>>> anyway. The only real user of cgroups at the moment is systemd. >>>>> Others are welcome to make use of cgroups too. But in the current state >>>>> nobody blames them for not jumping in. >>>> No complaints here in improving something, but consider the source is >>>> all I'm saying. >>>> >>>>>> If systemd is the only implementation of cgroups and >>>>>> their developers are working on cgroup support in the kernel, it spells >>>>>> calamity given their history of evangelism and zealotry. >>>>> well, going over some old ml threads on fedora mailing lists all I could >>>>> find was that Poettering and Sievers DID listen and DID make changes if >>>>> the demand was high enough. >>>>> >>>>> Sure, I dislike systemd. Sure what happened with udev was a dick move. >>>>> But their 'zealotry' is a lot less developed than the zealotry of those >>>>> who exploded about using an 'init-thingy' in the future. >>>>> >>>> I'd say their zealotry is less loud and more persistent. Their way is >>>> best, UNIX (and its philosophy) is outmoded, people are thinking 30 >>>> years behind where we are, etc etc etc. Those who have separate /usr and >>>> blame systemd for pushing them to use an initramfs aren't seeing the >>>> real problem (upstreams not putting things where they belong, FHS no >>>> longer *really* being worked on, generally just the filesystem being >>>> played with like a toy) >>>> >>>>>> I truly wish I understood why a single userland program and its >>>>>> developers are being given the keys to an entire subsystem of the >>>>>> kernel. >>>>> they aren't. >>>> Of the people who have committed to the cgroup subsystem of the kernel, >>>> how many are not members of the systemd, GNOME, or Red Hat projects? >>>> I'll let that speak for itself. >>>> >>>>>> Their changes to udev have proven to be a headache for users, >>>>> yes? which ones? >>>> Persistent NIC naming, for starters. The former maintainer's idea to >>>> merge with systemd (which was influenced by Mr. Poettering in the first >>>> place) when the two are completely separate pieces of software that do >>>> two completely different jobs, and various other troubles with udev > >>>> 175 that one can Google for and find tons of results. >>> I can't find anything that would be true. Can you point out some? >>> A lot of FUD[1] and outright lies coming from people, who, for example, >>> don't like systemd. >>> >>> [1] http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt >>> >>> I know for a fact udev-208 is a full replacement for udev-171 in terms >>> that both work on same kernels, same libcs, and so forth. That's why >>> 171 is no longer in Portage, because it's completely useless from users >>> (and developers) point of view. >>> >>> Adjusting some configs and enabling some kernel options that have been >>> around for a long time is just part of normal maintenance process, >>> that's what we have admins for. >>> >> Do you know the design consequences of opt-in versus opt-out? I'll keep >> this short: When evolving a codebase, new behavior for core parts of the >> system should not be pushed or forced on users. If you must, keep the >> old behavior around as a default and allow users to try the new thing by >> explicitly opting in. The new naming in whichever udev started the mess >> did it the exact opposite (and wrong) way. > > > It's not forced upon you. You received a news item that had instructions > on howto assign names you want, like lan0, internet1, wireless3, and so > forth. > And it also described howto turn off udev from completely renaming the > devices, to keep kernel assigned names. > What they did was they dropped the *broken* feature called 'persistent > rule_generator' which never worked correctly, and in > race conditions still flipped eth0 <-> eth1 around -- that was a > *security* flaw that *needed* to go. > It would have gone even without providing the alternative of providing > biosdevname -like new name optionality to the users. > Kernel and kernel drivers are designed in a way it's not supported to > flip in-place kernel names and udev tried to workaround that. > > https://www.kernel.org/doc/htmldocs/device-drivers/API-device-rename.html >
Like I mentioned in a prior e-mail, the change didn't affect me when it was pushed, and doesn't affect me now. I did recently have to reinstall Gentoo, however (note, going from testing to stable isn't fun ;p), and noticed it when I found Gentoo ships with systemd-udev instead of eudev. I got the new naming and had to do some work to go back to what should be normal behavior. My `kernel` line remains with that switch in effect, but I'm not sure if eudev requires that flag to keep default behavior. Had udev's defaults been left alone, I wouldn't have had to go through any trouble to migrate back to eudev beyond the unmerge and emerge that's expected as part of a switch. That's where the design flaw rears its ugly head. I could see opposition to my view if I was trying to do something that the software simply wasn't designed to do, like cook my breakfast for me. Regardless, I was speaking purely from a design perspective; I succeeded in solving the problem (mostly) on my own, so no issues there. Perhaps the next time I need to install Gentoo, I'll find a way to get eudev on there before even the first proper boot and avoid the problem altogether. >> >> While editing and updating configs is a normal part of system >> maintenance, turning a system on its head and screwing it out of network >> accessibility until the new default is reversed (by means of a `kernel` >> line in GRUB, requiring a reboot) is straight-up wrong design. > > Again, that's why you received a warning beforehand in form of portage > news item, portage news postinst message, > and a updated gentoo handbook plus gentoo wiki. There was no such > breakage as you described, unless you were > stupid enough (sorry, no offense intended) to upgrade something related > in the boot process without reading the relavent > information. I'm pleased to know news was issued and rescind my statement on that. Most likely, I skimmed the item, saw "udev", and moved onto the next item, since I knew it didn't apply to my system. That was quite a while ago, wasn't it? > >> Conversely, keeping old behavior, even for systems that *do* have >> multiple NICs, will at least be functional (for one of the NICs, anyway) >> until they set the option to get their expected behavior sorted out. >> Multi-NIC systems are less common than single-NIC systems, and that >> alone should've been enough motivation to leave old behavior as default, >> with the new behavior a simple config switch away. >> >> The way the new behavior was introduced may have led users of single-NIC >> systems to believe that the old way was broken, when as demonstrated >> through past use, works *just fine* for single-NIC machines. It was > > And when those single network adapter users enable one of many virtual > drivers that create eth*, or attach removable > network device that creates eth* the bug would have been brought up. > So no, it was never safe to use in-place in-kernel renaming even on > single NIC systems. Perhaps it's because I never used virtual network devices, but I never had any issue out of default kernel names. As a NIC setup gets more complex, I agree that something more robust should be used. I don't agree that enps* or whatever are the way to do it, but that's bikeshed. > >> *multi-NIC* use that wasn't as predictive and needed the fix, not >> *single*. It's basically using poor design/defaults decisions to smear >> existing technology dishonestly. Technical propaganda, so to speak. >> >> My beef with that decision is separate from my disdain for the decision >> to merge it with systemd, which is only mildly related to why I dislike >> systemd, but that's irrelevant. >> >> As for FUD, I see no reason to get personal. If you insist, we can take >> a look at which Gentoo package(s) you maintain that are related to the >> topic and ask ourselves if you are any less biased. >> > > If you are hinting I'm someway favouring systemd, or udev for that > matter, you couldn't be more wrong. I use OpenRC, and I maintain > ConsoleKit/udev > out of necessity (because someone has to). I deal with facts, I have no > favouritism to any direction. > In contrast, I also maintain a bunch of software that allows people to > *skip* whole freedesktop.org stack (ConsoleKit, PolicyKit and so forth) > like pmount, > pmount-gui and such for minimal systems. > So you maintain them, but don't necessarily follow or agree with their goals/sentiments/designs? Does that ever create problems for you when trying to test systemd/udev on revbumps and whatnot? Do systemd proponents wonder why you don't use what you maintain? Honestly curious; I assumed that if you maintain something, you use it. Perhaps I was wrong. >> --- >> >> Getting back to the original topic, cgroups sound like a pretty neat >> idea that other init systems could benefit from. If the systemd guys are >> willing to work on that subsystem for themselves, are they also >> interested in seeing what other init systems would want from cgroups? >> Certainly there's more room for development and/or standardization on an >> API instead of a single project having all the influence. I think their >> presence and activity with cgroups could be beneficial if policed by >> another init system project that's not trying to infect every Linux distro. >> >> tldr version: opt-out design is bad, the accusation of FUD is moot since >> you maintain udev for Gentoo, and I think work on cgroups (by systemd >> people) could be good if they're not the only people working on it and >> calling the shots. >> > > There is nothing stopping from sane patches entering the Linux tree that > would go in favour of OpenRC cgroups support, it's just that there are > almost no people working on it. > Like I said, code matters, complaining doesn't. > Okay, let's say the systemd guys start work on the cgroup subsystem, things are moving along well, systemd support is basically done, works well, etc. Someone goes in to try and get support for their init system as well, and their code does something more than the systemd guys or it's something they disagree with. Argument ensues, and because the systemd guys started the work first and decided on things without outside influence, they block the other init system from improving cgroups for their particular needs. My suggestion for them to not work on it alone is to prevent the above situation from happening. Arguments over implementations happen all the time, and given how aggressive systemd/udev changes have been pushed, what's stopping them from preventing other init systems from taking advantage of cgroups? If they make the changes in the cgroups kernel code and other init systems use cgroups but cannot change the cgroup kernel code (because their patches were rejected, for example), then systemd effectively controls other init systems; at least when they choose to use cgroups. I wish I could say the odds of it happening were very low, but I'm not really sure. What have they done to earn trust?
