🚀 go-pugleaf

In <6akhoq$7d8$1@news.cs.tu-berlin.de> js@cs.tu-berlin.de (Joerg Schilling) writes:

>In article <6ahlmj$amk$2@janis.virago.org.au>,
>Rachel Polanskis <r.polanskis@nepean.uws.edu.au,grove@zeta.org.au> wrote:
>>A good Linux programmer is a portable UNIX programmer.

Linux is a dream to program compared to some of the stuff I've had to
work on (e.g. SysIII, SysV, SunOS 4.x). While I believe Rachel's coming
down too hard on Linux "reinventing the wheel" I also believe it's
important for programmers to understand the _standard_ - the interface
between the programming language and the system.

So read POSIX.1, POSIX.you-name-it and various other specifications
until you understand what's important therein.

>But these programmers are rare. At least if they learnd UNIX with Linux.

The man pages in sections 2 and 3 are pretty good. For example, look at
this fragment from open(2):

CONFORMING TO
       SVID, AT&T, POSIX, X/OPEN, BSD 4.3

Now look at this fragment from setfsuid(2):

CONFORMING TO
       setfsuid is Linux specific.

With suitable documentation it isn't hard to learn what is Linux-specific
and what is Unix, even if you only have Linux man pages for your docs.

>Linux documentation and the Linux include file system makes it hard to become
>a good programmer by only seeing Linux code. Most programs that have been
>developped on Linux are hard to port to other UNIX flavours.

Nah. Using "the source" and then writing applications is the wrong way.
The right way is to read the man pages before writing code, and only
use "the source" if you think you found a kernel bug (really unlikely) or
you just can't figure out why your program behaves as it does.

Linux is no different to any implementation of Unix in that it has hundreds
of files under /usr/include which can be included anytime, but which should
usually not be.

Nick.
-- 
Zeta Internet                           Fax: +61-2-9233-6545 Voice: 9837-1397
G.P.O. Box 3400, Sydney NSW 1043        http://www.zeta.org.au/