[lsb-discuss] Thinking about future LSB features
Anthony W. Youngman
wol at thewolery.demon.co.uk
Fri Feb 13 14:07:36 PST 2009
<FE028D69955796489B510CE43DBBE8031933B3EC at rrsmsx503.amr.corp.intel.com>,
"Wichmann, Mats D" <mats.d.wichmann at intel.com> writes
>lsb-discuss-bounces at lists.linux-foundation.org wrote:
>> I second this strongly.
>> I do not care about performance issues, just having a tone of
>> files that
>> the user has to look at each time they visit their home directory.
>> And some nice rules about how to use that space so that config files
>> owners are easy to track down and also play nice with others...
>> Put a comment at the beginning of config files with the
>> application name
>> in it, full path if possible.
>> Put a unique numner on the end of config files, that way multiple
>> versions of an app can coexist easily and two apps with similar names
>> can have config files that do not crash.
>this seems a reasonable topic for FHS if it can be gotten going
>again, but it would require an understanding that work could be
>done on proposals that aren't current practice on distributions.
>I guess a LOT of buyin would be needed to migrate to such a new
>scheme, and don't know if it's possible with so much history
>behind the current stuff, but I'm not saying don't talk about it...
That's why I said that the location of the user-specific files was to be
specified in the global file ...
In other words "if the global file doesn't say, assume it's in ~. If you
want LSB conformance then you have to specify it. If you specify it, the
default has to be ~/.etc".
That way, you don't break anything, but you force buy-in for anything
And as I said with all the lsb/rpm kerfuffle in packaging, I think the
LSB should *not* be standardising what is already done. That way lies
irrelevance. We should be trying to *L*E*A*D*. That doesn't mean being a
dictator (that wouldn't work with Linux, anyway), but we should be
"doing a Linus". In other words, we should be saying "we think this is
the way to go. Any objections, anyone?" If it sparks a heated
discussion, good. If it sparks a chorus of "hear, hear"s, good. If it
sparks a groan of "Oh my $DEITY no!", then good.
(As far as the distros are concerned, I look at it as "they should be
monitoring what we're doing. If they can't be bothered to monitor, they
can't moan when they get blindsided. And if they are monitoring, then
good - they'll make the proposals better". Either way, the distros will
get the LSB they deserve. The same is true for ISVs.)
But we shouldn't be chasing the consensus tail lights. We should be
driving the consensus forward - "if no-one objects, then it's going
in!". At the end of the day, today's problem is not herding cats. Most
of the major contributors to Linux are corporate employees today - and
corporations are sheep. They want leadership. THE LSB SHOULD LEAD! The
best generals lead from the front, but they notice when the men stop
following. That's what we should be doing.
Anthony W. Youngman - anthony at thewolery.demon.co.uk
More information about the lsb-discuss