[nycbug-talk] "every bit as good as Linux"
ike at lesmuug.org
Tue Sep 21 10:37:42 EDT 2004
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
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
> 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
> 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)?
I found that url, btw, in the redhat man pages, hier(7) viewable here
The FreeBSD hier(7) has oodles of Posix mention:
> POSIX doesn't say anything about placement of files, and logical
> 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
> should be. (other than the FSH stating that it should be some sort of
> directory) Why? because the linux ldconfig stuff is supposed to take
> care of
>> It seems to me, ironically, that this 'Linux Base Standard' feels a
>> 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
> anyone else. Its not like they're trying to hide something about the
> 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
> 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
> 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
> last time you saw anyone use the former of the latter ?)
> I think POSIX gets a lot more credit than it deserves at times.
> 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
>> 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
> it. If I don't know the ports tree, then clearly I'm going to have a
> figuring out how to deal with things. If someone put me on an IRIX
> 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
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
The precise man page I get when calling up adduser(8) man page on
(Trick question: does anyone notice another problem here, besides the
binary not existing?)
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
>> 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
> have nothing to do with written standardization. (IE: we all use GNU
> 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
More information about the talk