[blfs-support] Latest news in GNOME world

Simon Geard delgarde at ihug.co.nz
Wed Nov 14 02:24:09 PST 2012


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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxfromscratch.org/pipermail/blfs-support/attachments/20121114/29a13294/attachment.sig>


More information about the blfs-support mailing list