On Tue, 2012-11-13 at 10:47 -0600, Bruce Dubbs wrote: > I believe that cgroups is primarily implemented in the kernel. My > problem is that when is type 'mount' from the command line, I get many > more cgroups than mounted file systems. That's an implementation detail > that is an irritant and could probably be fixed in util-linux. > > On a single user or limited function server (e.g. lamp), there is little > need to track the processes started by a service. If those systems are > removed from the set of all Linux systems, how many are left? Being an > advocate of LFS, I am not in favor of one-size-fits-all.
Ok, but what's the actual downside? Apart from the irritation of the mount command producing a bunch of noise, in what way is one-size *not* fitting all in this case? Because that's the thing I find missing from most of the arguments against it - actual concrete reasons why systemd is wrong for them. Most arguments are either philosphical (quoting Unix design principals), or just deranged ranting (hate its, hates it, want precious sysvinit). > > Not related to systemd, I have the same problem with bash_completion. > First, the files are in /etc/bash_completion.d when they should be in > /lib/bash_completion.d. Second, they are stored in the environment. > Running 'set' results in 10000 lines of output instead of the 80-100 > lines or so expected. Fortunately it's easy to not source the > bash_completion files. Yeah, I agree completely on that one, which is why I don't install bash_completion on LFS, and avoid sourcing anything in /etc when using a distro. I love the completion functionality and have a number of custom rules for it, but I don't find that there's much of value in the bash_completion package. > I agree that ad hominem attacks are not called for. The problem is that > changes are being forced on users that affect the way they work. The > decision is being taken away from the user. The alternative, of course, > is LFS or similar. > > My problem is that distros allow Gnome or KDE or Xfce or other window > environments. Why can't they allow a choice in boot systems? Ultimately? Because choices aren't free. It's easy for an end user to demand the ability to change something, but someone actually has to support it. Someone has to code support for that choice, someone has to test that the system works for all possible values for that choice - and worse, for all possible interactions of that choice with other choices. And speaking as a developer who works on large complicated systems, my experience is that a large proportion of bugs can ultimately be traced to unexpected interactions between two or more options, some obscure permutation of settings that nobody ever tested. From that point of view, you don't want to allow any option that isn't absolutely necessary - those options add complexity, and complexity leads to bugs. Now, I know that's not a view that an end user may subscribe to, but it *is* how developers see things. And developers, funnily enough, are the people doing the development. Simon.
signature.asc
Description: This is a digitally signed message part
-- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
