On 10/23/2013 05:51 PM, Steven J. Long wrote: > Daniel Campbell wrote: >> 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. > > Good luck with that argument; you have to bear in mind Gentoo devs are > mostly fresh out of Uni (or still in it.) They're not very experienced iow, > as a rule, apart from in Gentoo ebuilds and making the tree work together, > which is all we ask of them. Oh and usually Java from Uni; they typically > have a snobbery about shell as well (and doesn't it show) which is quite > amusing when one considers their implementation language. > > (No this is not to the topic per se: it's a wider point that I had to > repeat to someone recently, who apparently found the insight very useful. > So I put it out there for other users, or those to come. > > I have zero interest in arguing the toss with anyone: you're welcome to > your opinion, that's mine. You ain't gonna change it, so don't bother > trying. Feel free to rant amongst yourselves. ;) I know you said you won't argue about it, and that's fine. I'm not sure how fair it is to broadly denigrate the Gentoo devs, though. There are so many, with varying levels of experience, specialty, and education, that it would be difficult to put them into a neat label box. Among all the distributions out there that run Linux as the kernel, I think Gentoo is probably the most compatible in terms of choices. They do a good job of making sure OpenRC, sysv, systemd, runit, and others are possible on Gentoo. Perhaps you know more about some of the devs than I, though. I'm just a user who aspires to become an official developer to learn more about it.
> > The point is that this is actually why Gentoo is a very good place for a > "developer" to cut hir teeth: they learn from the other users when they > install, and usually come up through the forums, where if you've ever > been to OTW, the difference between a personal attack and criticism of > someone's work is blatantly obvious. Further they have to run any major > design ideas past that same experienced user-base, who had the rough > edges knocked off ages ago, and simply want it to work for everyone. > > They don't always see it like that, ofc, but I for one remember thinking > much dumber things. [1] Well, the udev behavior I was discussing isn't really the fault of Gentoo devs. It was just the default for udev, as shipped by upstream. My guess is the devs decided to opt for the default so those who planned on using the new behavior (and/or GNOME 3.8) wouldn't have to do additional configuration... at the expense of everyone else having to if they wanted to retain the net.ifnames behavior. They were screwed no matter what, really. Had the systemd/udev guys not created the new behavior, Gentoo's devs wouldn't have had to make a decision that they knew wouldn't please everyone. > >> 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 >> *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. > > Even more amusing when you consider that the original race that was so > terrible it justified breaking the machines of those it was supposedly > in aid of, as well as those of people who had zero use for it, yet were > apparently the target market, was in fact implemented by the same set > of "early userspace experts" who put themselves forward as such 5 years > previously. > > I personally have no words to describe such a situation beyond "idiocy". Pretty much agreed. Self-proclaiming as an expert has such an air of egotism it's hard to take it seriously. > >> 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? > > This is actually what I posted about: I know qnikst already implemented > a large chunk of functionality in openrc and was concerned about the > "proposed changes" mainly because as usual it was a grand statement of > intent, with little in the way of coherent content. But we're spitting in > the wind: you can't expect amateurs who've backed themselves into a > corner, full of ego-attachment to their "work", to ever admit it's crap, > or that they fscked-up. Certainly not based on the record of this team. Agreed. To this day, "PulseAudio" is still synonymous with "my sound doesn't work" for some people, even though Mr. Poettering no longer works on it (to my knowledge). I actually think some of the ideas in both PA and systemd have merit, but the implementations are so far off base or so ambitious that it becomes an all-or-nothing decision instead of the usual "micromanaging" or "piecemeal" package choosing that most of us (I assume) are accustomed to. So instead of making one decision at a time, choosing a package of Poettering's means you're committing to more than one decision. His aren't the only packages like it; one could run the same argument for other projects that try to do a bit too much for one package. > >> 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. > > Yes one would think before embarking on such a venture they'd at least > take a look at other things that also run on Linux in the same domain, such > as s6, runit or openrc. But no, systemd is allowed to take them over, but > no consideration can be given to those use-cases, because "this is only > about cgroups." It's orthogonal, maan. > > You're not alone; careful though as you just get labelled a "hater" even > when you've tried your damndest to collaborate with the "other side" (who > are the only ones even interested in "sides") only to come up against > groupthink, double-speak, and monkeys flinging poo. > > "You're not with us so you *must* be against us!" > > "No. We just do not care." > > "Ah you is haterz." > > "Bye then; enjoy the kool-aid." > > [1] http://www.iusedtobelieve.com/ > To be fair, I lack the experience and knowledge in the problem domain to collaborate with whoever plans on hacking cgroups. I'm just concerned that other init systems may become locked out of cgroup functionality until/unless they use an API that requires them to adopt a software architecture/design similar to systemd's. It's dangerous, to me, to let ambitious people work on core parts of a large project. They can't be trusted to remain neutral to all userland software that may depend on it. Nice link, btw. :)
