[lsb-discuss] Thinking about future LSB features

Anthony W. Youngman wol at thewolery.demon.co.uk
Fri Feb 13 14:07:36 PST 2009

In message 
<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 mailing list