[nycbug-talk] "every bit as good as Linux"

[Isaac Levy]

Sunny, as usual, your right on the ball with this one, and as much as I  
stick to my guns on a few sticky issues below, you've got me to  
actually sit down and take a good look at the LSB.

For everyone on-list here, this is the project, and it's totally worth  
a look-see:
http://www.linuxbase.org/


On Sep 21, 2004, at 9:18 AM, Sunny Dubey wrote:

> On Tuesday 21 September 2004 02:53, Isaac Levy wrote:
>> Hi all,
>>
>> Can someone say POSIX?  Or um, Berkeley Software Distribution?
>
> I think its important to realize that POSIX and the LSB exist to  
> compliment
> each other.  After all, the Open Group is behind both POSIX/SUS and  
> LSB, heh
>
> POSIX conformance demands some really nitty gritty low level stuff  
> that just
> about any OS can conform too (I think Windows NT4 was POSIX).  When  
> reading
> LSB, you'll realize it aims for something higher.

That's precisely what I was looking for- a reason not to disregard LSB.  
  Now this doesn't sound like such a bad idea after all- but how does  
LSB it differ from the Filesystem Hierarchy Standard (FHS)?

http://www.pathname.com/fhs/

I found that url, btw, in the redhat man pages, hier(7) viewable here  
as well:

http://www.freebsd.org/cgi/man.cgi? 
query=hier&apropos=0&sektion=0&manpath=Red+Hat+Linux%2Fi386+9&format=htm 
l

The FreeBSD hier(7) has oodles of Posix mention:

http://www.freebsd.org/cgi/man.cgi? 
query=hier&apropos=0&sektion=0&manpath=FreeBSD+5.2.1- 
RELEASE&format=html

>
> POSIX doesn't say anything about placement of files, and logical  
> filesystem
> structure.  LSB does.  LSB demands FSH.  And FSH states things like:
>
> 1 - no binaries in /etc
> 2 - /usr/local must never be touched by the package management system
> 3 - /opt must exist
> 4 - etc etc etc
>
> You'll notice that the LSB is somewhat way-ward itself.  IE: it  
> demands that
> libX11 be called, libX11.so.6.  But it doesn't specify where that  
> library
> should be. (other than the FSH stating that it should be some sort of  
> /lib/
> directory)  Why? because the linux ldconfig stuff is supposed to take  
> care of
> that.

hrm.

>
>>
>> It seems to me, ironically, that this 'Linux Base Standard' feels a  
>> lot
>> like what BSD was before it was a full-blown OS... folks, this has all
>> happened before.
>
> And if you read the LSB, they clearly credit the Regents of Cali first  
> before
> anyone else.  Its not like they're trying to hide something about the  
> roots
> of many of their ideas.
>
> [...]

This I did not read, and now I will go read it.  I stand corrected, I  
hope the author of that bloody article does too.

>
>> Everything just compiles, and works together as it should-
>> because of the ANCIENT adherence to POSIX guidelines, (yes, even when
>> it hurts sometimes).
>
> I think POSIX is largely technical and doesn't really deal with many  
> of the
> conventions UNIX has come to adopt over the years.
>
> when you run GNU autoconf, you'll notice that the /usr/local* material  
> is
> looked at first before the system standard of / or /usr.  But why?   
> Last I
> checked POSIX doesn't talk about path precedence ideologies.  But in  
> the
> world of BSD, and Linux we've come accustomed to such, and this sort of
> computing logic has become ingrained into our heads.
>
> (POSIX demands "tput clear" instead of just regular "clear".  When was  
> the
> last time you saw anyone use the former of the latter ?)
>
> I think POSIX gets a lot more credit than it deserves at times.   
> Especially
> UNIX design wise.

Well, I don't know that I can agree with that, I've seen some fairly  
awful low-level decisions that were consciously working outside of  
POSIX- some stuff having to do with socket handlers etc...
/me shudders and has flash-backs to midnight debugging on crashing  
servers

>
> [...]
>
>> Most of the rest of that time on Linux is tracking down a missing
>> library in userland for a given distro, installing things which are
>> common to one Linux- and not another,
>
> there is nothing intrinsically specific to linux about this.  If I  
> don't know
> the package management system of my OS, then I'm doomed to ignorantly  
> hate
> it.  If I don't know the ports tree, then clearly I'm going to have a  
> problem
> figuring out how to deal with things.  If someone put me on an IRIX  
> machine
> and told me to upgrade the C library, I'd probably walk out the door
> instantly.  (pete OTOH may love such a challenge, heh)

Well, I sortof see what you mean, but for production boxes, (and also  
the boxes I use for my own fun), I really don't like ANY package  
management system- not Ports or Packages, cvsup, even darwinports- I  
prefer a minimal server OS, build apps cleanly and stock from source  
code.
Across the BSD's this works well, across Linuxes this does not.

>
>> and the joys of de-activating or
>> de-installing daemons, which are often hacked beyond sane
>> configurability, conflicting with something I'm needing to install.
>> All of this, with some of the most poorly maintained and most
>> inconsistent man pages in the UNIX world.
>
> thats FUD too.

Perhaps strongly stated, but not FUD.  You know me man, I'm not a  
religious *NIX user- I'm just stating some facts here,

Top of my head: man pages for things Like Apache on Mandrake- do they  
say one bloody word about the Apache2 proxying Apache1.x to make their  
'Enterprise Server'?  Or RedHat, do the man pages say a word about the  
fact that the adduser(8)  program DOES NOT EXIST by default, and one  
should be using redhat-config-users?  That info is buried nicely on the  
RedHat site- once one figures out what they're looking for.  I'll stop  
and just state that I have not experienced this level of trouble in  
BSD, ever.

The precise man page I get when calling up adduser(8) man page on  
RedHat:
(Trick question: does anyone notice another problem here, besides the  
binary not existing?)
http://www.freebsd.org/cgi/man.cgi? 
query=useradd&apropos=0&sektion=0&manpath=Red+Hat+Linux%2Fi386+9&format= 
html


It's nothing personal against Linux, I mean clients of mine use it, (so  
I do to), and I'd LOVE it all to be better.  Perhaps in 20 years I'll  
be saying the same thing about some other OS, and pointing to Linux as  
a mature model- but right now, this is the way it is.

>
>> All of that is a waste of time I could spend making interesting or
>> useful things, while eating away at my client's ROI.  In english, my
>> client pays more and gets less- and I'm bored off my rocker with the
>> tedium.
>>
>> I'm not trying to outwardly slam Linux here, as there are some really
>> amazing ideas and code in there, but portability definitely isn't one
>> of it's strong points.
>
> much of it applies to BSDs as well.  We all run the same libraries,  
> the same
> apps, the same everything.  And as stated before, many of our  
> conventions
> have nothing to do with written standardization.  (IE: we all use GNU  
> tar
> over POSIX's ustar, or even their PAX)

Ok- understandable- but again, no.  I could dig through old client  
notes for inconsistencies that bit me, but to be straight, it's all  
esoteric stuff that is a problem when compiling from source.  I've  
found that loads of Linux packages take for granted one lib or another  
that they package WITH a given ported app, and one thing gets built  
thinking it exists, another finds it not to exist- again, a problem  
I've never had in the same way on any BSD, compiling things from  
source.  I don't know what else to say here except I wail and gnash my  
teeth.

Rocket-
.ike