[penguicon-general] A couple of thoughts about programming

[Rob Landley]

On Sunday 29 April 2007 11:58 am, Robert Meier wrote:

> > POSIX became largely irrelevant to Linux because the spec isn't freely 
> > available.  (You have to pay for it.)
> 
> I believe the above is unfortunately widely accepted FUD,

Oh please don't call FUD on the computer historian.  Not without citing 
references. :)

Quoting from a footnote in The Art of Unix Programming, here:

http://www.faqs.org/docs/artu/ch17s02.html#ftn.id2999397

> One Linux distributor, Lasermoon in Great Britain, did achieve POSIX.1 FIPS
> 151-2 certification — and went out of business, because potential customers
> didn't care.  

Here's memorials to their (circa 1996) enthusiasm for their certification:

http://www.linuxjournal.com/article/131
http://www.ukuug.org/newsletter/linux-newsletter/linux%40uk21/posix.shtml

> that misleadingly implies unavailability of practical interoperability in
> the linux/unix community.

Linux is compatible with other Linux.  BSD and Solaris and such are 
interoperable via emulating Linux.

I researched this fairly extensively while rebutting SCO's first amended 
complaint (Halloween 9).  This is from my rebuttal to paragraph 43:

> The 86Open Project was an effort to define a common binary executable format
> to allow the same programs to run without modification on all the various
> x86 Unix variants. The first meeting of the group took place at SCO's
> corporate headquarters, on August 22, 1997. Shortly thereafter, a SCO
> developer named Michael Davidson wrote the utility lxrun, which allowed
> Linux utilities to run on OpenServer and UnixWare. Davidson made lxrun an
> open-source project, which allowed Sun to port lxrun to Solaris, and on July
> 25, 1999 the 86Open group declared victory and dissolved, with the Linux
> executable format now being the lingua franca of the x86 Unix world.        

The links in that paragraph are:

http://www.telly.org/86open/
http://www.ugcs.caltech.edu/~steven/lxrun/
http://wwws.sun.com/software/linux/compatibility/lxrun/

You can also learn there about the Linux Kernel Personality for UnixWare (not 
that anyone cares anymore).

The response to Paragraph 47 tells you about the Intel Binary Compatability 
Standard (ibcs2) along with lots more links, some of which might be stale by 
now since I did all this research in 2003, but archive.org is your friend.

Attempts to unify the fractured Unix market along the lines of standards were 
so common they were a RUNNING JOKE.  The following is almost 20 years old:

http://www.gshotts.com/HUMOR/unixland.htm


> > >        POSIX (write once, run aix, hp-ux, linux, sunOS, SGI, ...)
> You can read the lastest 2004 specification online with a free (i.e. 0.00 
USD)
> registration (only an email required)
>     http://www.unix.org/single_unix_specification/
>     http://www.unix-systems.org/version3/online.html 

Hello, I mentioned SUSv3 in my original email.  Would you bother to read the 
darn thing before going all huffy about it?

It's a relevant standard to Linux because it's freely available online.  It 
contains much of Posix (although it's not always an exact match, no matter 
what they say).  I spent three years using the online version of that spec to 
implement BusyBox against, although that was just a first pass because you 
then had to go see what gnu extensions people were actually using and 
reproduce those too, which I did.

Try to build the Linux kernel with a posix-only "make".  I dare you.  Try to 
find a Linux implementation of sccs.

Linux cares about posix compliance, but it's by no means a primary goal, and 
Linus Torvalds himself has expressed it in so many words:
  http://lwn.net/2000/0330/a/linus.html

> or purchase on CD (or as a bookshelf of hardcopy)
> for ~240 USD (less than the same size bookshelf of O'Reilly books).

Any spec I have to spend $240 on is not a spec I care about.

> You can purchase the 1991 specification on CD
>     http://www.opengroup.org/bookstore/catalog/t912.htm
> for 19.95 USD (less than Penguicon admission).
>
> I personally have no objection to paying the IEEE, Open Group or O'Reilly
> for their effort and publications.

If you're required to pay a gatekeeper for access to it, it isn't a standard.  
(Same way if you have to pay to see a copy of the law, it's not a law.)

I am not required to pay for SUSv3, and so I care.

> > > It's been subsumed by SUSv3, which you can find at 
> > > http://www.opengroup.org/onlinepubs/009695399/
> 
> <AFAIK>
> SUSv3 is a publication of the IEEE 1003 and other standards required by 
POSIX.
> SUSv3 does not subsume/replace POSIX anymore than "Learning Perl"
> (the camel book) subsumes/replaces perl.

SUSv3 is relevant.  POSIX is not.  There is overlap between then.  So what?

> ~2hr research (http://www.uspto.gov/) will show that POSIX is a trademark
> (1792095) like linux (1916230).  Commercial use of the POSIX trademark
> indicates certified compliance with FIPS-189, IEEE Std 1003 (a.k.a.
> ISO/IEC 9945), and several other standards.

I'm aware of this, and they are DEEPLY IRRELEVANT.  Both Windows NT and IBM's 
OS/360 got Posix certification.

http://www.opengroup.org/csq/view.mhtml?RID=ibm%2FXU1%2F2
http://www.microsoft.com/technet/archive/ntwrkstn/reskit/poscomp.mspx?mfr=true

Means nothing.

> The Open Group publishes the full POSIX spec, including IEEE Std 1003,
> and other standards as the Single Unix Specification, analagous to the
> as yet unreached target of the linux documentation project.

The Linux Documentation Project is a collection point for third-party 
documentation.  Possibly they meant the Linux Standards Base?  Ask 
Lamont "Piggy" Yarrol about the history of _that_ little fiasco... :)

> > >        rpm spec (wrapping tarballs with dependencies, and pushbutton 
build)
> > rpm is cpio based, deb is the one that's tar based.
> > (I believe ipkg, portage, and slackware are also tar based).
> 
> A source rpm is a cpio file which includes
>   o original unaltered package files (tarball, .zip, ...)
>   o patch files to copy-and-alter the original package files
>   o .spec file, macro processor input to produce shell scripts

Or you could just provide a tarball of source code, which works on Ubuntu and 
Gentoo and Debian and Slackware and Mepis and Linspire and so on.  These 
days, RPM is an increasingly specialized package format usable on a minority 
of systems.  (I note that Red Hat paid to have it be the only package manager 
mentioned in the Linux Standard Base, but see the above mention of why the 
LSB failed, which is a rant of its own.  And ask Garrett the uClibc++ guy 
about the LSB C++ standard, which is HILARIOUSLY bad...)

There's a reason RPM was unmaintained for a few years: lack of interest.

http://lwn.net/Articles/196523/

Admittedly that article embarassed Red hat into doing something about it...

> In typical unix do-things-reversibly fashion,
> a package developed as a tarball(, .zip, ...), can be wrapped as a source 
rpm,
> and a source rpm can yield the original tarball(, .zip, ...).
> 
> In typical unix textual fashion (like apache config files),
> the .spec file, is human readable,
> yet computer-automated description of build, test, relocate details.

You seem to be unaware I spent a year working at a company whose core product 
was TSRPM, the TimeSys RPM wrapper, that cross-compiled Fedora to various 
platforms Red Hat was uninterested in supporting because Red Hat sold the 
embedded division it got from Cygnus to concentrate on the enterprise market.

[fast-forwarding through the commercial...]
> rpm supports (but does not enforce by default) installations that are
> completely reversible (even when installation fails),

Remember when Eric Raymond hosed his system doing an RPM update a few months 
ago?  The first system I hosed doing an RPM update was Red Hat 6.0.  
Your "completely reversible" totally ignores shared libraries.

I once managed to corrupt my rpm database _without_root_access_.  (Still dunno 
how I did that one, but I did.  That was circa Red Hat 8, I think.)  Cathy 
just mentioned rpmq eating 100% cpu on her box.

But mostly, I don't deal with it anymore.  Eric's household was literally the 
last one I knew using Red Hat/Fedora outside of an "enterprise" context since 
2005.  (I'm sure there are others, I just don't know them.  And I'm not 
counting people who work for Red Hat.)

> As distros and package managers evolve, I believe many linux users
> would want to learn the features (and failings) of several package managers
> so the user can choose what's best for the user, without archive and distro
> package manager restrictions.

If you want to do a survey of package management systems, that's one thing.  
But RPM hasn't been "the default Linux package management system" since Red 
Hat 9 had 50% market share among Linux installs.  (Hint: Fedora is now 
actually in fourth place on the metrics I've seen.)

Rob