"stuff in the {Free,Net,Open}BSD ports collections" is BSD licensed, the "stuff" in the tarballs most often isnt.
If by that assertion you mean that the changes to the ported applications are BSD-licensed, then, even if true, it's not a very interesting assertion - the applications in question are still GPLed.
My kernel compiles with cc not gcc.
On BSD, ccisgcc:
% uname -sr
FreeBSD 3.4-RELEASE
% ls -li/usr/bin/cc/usr/bin/gcc
10848 -r-xr-xr-x 2 root wheel 49680 Dec 19 1999/usr/bin/cc
10848 -r-xr-xr-x 2 root wheel 49680 Dec 19 1999/usr/bin/gcc
Two names, same program.
FreeBSD has a "make" and a "gmake".
So? That's make, not the compiler.
The base system compiles with its own compiler.
Which, as noted, is the GNU C Compiler, even if the command name used to invoke it is cc, not gcc.
Give me any example of BSDL software developed without sponsors.
Almost all ports most of which are probably not GNU.
By "ports" do you mean "stuff in the {Free,Net,Open}BSD ports collections"? If so, have you surveyed, for example, all ~7000 FreeBSD ports to see what licenses they have, and determined that most of them are not GPLed (much less that most of them use the BSDL)?
And then fBSD has its own C compiler
If by "fBSD" you mean "FreeBSD", it doesn't have its own C compiler - or linker, or assembler; it uses GCC, GLD, and GAS. Take a look at/usr/src/gnu.
Not that this changes the argument about commercial contributions back to the OS, but to provide a non-rhetorical answer to what I presume was a rhetorical question:
The kernel support for USB is typically in sys/dev/usb in the source tree. (That's where it is on my FreeBSD 3.4 system; no, that's not a typo for "FreeBSD 4.3".) There may also be user-mode daemons or library routines there as well.
Well, from a historical point of view HP was a test and measurement company. They expanded into the clone market,
Umm, if by "clone market" you mean the market of selling "IBM-compatible PC's", you left out a small step there, i.e. the step where they got into the computer business before there was a "clone market" (heck, before there were "IBM-compatible PC's").
They had a line of 16-bit minicomputers dating back to the 1960's, and other lines of computers such as the HP 3000's, the original 68K-based UNIX boxes, and the PA-RISC boxes (running both UNIX and the MPE OS from the HP 3000's; they used, as I remember, binary-to-binary translation to allow both native 32-bit PA-RISC code and the old stack-based 16-bit HP 3000 code to run on the PA-RISC 3000's).
then the original poster is correct in that using GDK would do absolutely nothing to make the themes match
The original poster is, indeed, correct; it appears that Nat Friedman was confused when he asserted that making Qt use GDK would enable them to share non-pixmap themes - the theming code is in GTK+ (which knows what scrollbars, buttons, etc. are), not in GDK (which doesn't).
(I say "non-pixmap themes" because, if I remember correctly, either Qt can load GTK+ pixmap themes, or KDE includes something that can turn them into Qt themes.)
The idea is that Gdk provides a "draw a raised button-like rectangle here" call. At least I think it does.
No, that's not what GDK provides; it knows nothing about "button-like", for example.
See the GDK 2.x reference. It has calls to draw rectangles, but not "raised button-like rectangle[s]". It's GTK+ that knows all that fancy visual stuff.
Doesn't the use of.so dynamic libraries depend on ELF?
No. The first UNIX to use that particular flavor of dynamic libraries was SunOS 4.0, which used a.out. (NOTE: I said "that particular flavor of dynamic libraries", not "dynamic libraries".)
The BSDs that had dynamic libraries originally used a.out as well; one could think of the a.out that SunOS 4.x and the BSDs used as an "improved a.out on steroids".
The System V Release 4 shared library mechanism was derived from the SunOS 4.x one; some of the things put into ELF (which was the executable image/shareable image/object file/core dump format devised by AT&T for System V Release 4) were done to better support that shared library mechanism. The free UNIXes that use ELF use reimplementations of the SVR4 shared library mechanism.
Systems using the Linux 1.x kernel didn't use a SunOS 4.x-style shared library mechanism, although it might have been possible to implement it if the 1.x kernel supported calls to memory-map files; perhaps 1.x lacked those calls.
The mach microkernel, darwin, Java, Classic support and Carbon... there's more to the OS than NeXT legacy,
Just out of curiosity, why is the Mach microkernel in that list? As I remember, NeXTStEP used it, so, as far as I know, it is part of the NeXT legacy of OS X.
FreeBSD 5.0-CURRENT has ACPI, so, unless they back it out, it'll be in 5.0 when it's released.
I think there's already experimental ACPI support in the Linux 2.4 kernel.
I can't speak for NetBSD or OpenBSD, although a search for "ACPI" on the NetBSD Web site suggests that they're at least looking at the FreeBSD effort.
So, even if this were the Evil Plot by Microsoft to destroy free UNIXes that some people have suggested (I see no evidence that it is), it's only going to work for a while.
It is not related to whether or not network byte order is an abstraction or another name for big-endian as you seem to be asserting.
I am asserting that it is an abstraction that you'd damn well better implement as big-endian if you expect your machines to work on the Internet. Yes, you could, if you controlled all the machines that had to communicate with each other, re-implement it as little-endian, but that hardly makes it an abstraction whose implementation is irrelevant, because, in a huge number of systems, the implementation isn't irrelevant.
(Take a look at RFC 791; it quite explicitly states the byte order you use. It's no abstraction there....)
As for the read/write thing, I would have to say that the C library sort of has the higher-level operations namely fprintf & fscanf. They are meant for ASCII level communication though. Today, if these functions were implemented I would assume that cross-platform data exchange would be a consideration.
I wouldn't. I'd assume that they'd leave cross-platform data exchange to layers above read() and write() - oh, say, the XDR routines in the ONC RPC library, or routines to encode and decode using various encodings of ASN.1, or....
Then it still isn't the only way to allow different computers to communicate with each other over a network. It's the most common way, but there are probably different types of computers communicating using OSI COTP and CLNP, for example, as well.
All your examples can be simplified to simply "both sides agree on a way to send data."
Which means that the only way to allow different computers to communicate with each other over a network is for them to agree on a way to send data. Yes, that's a trivially true statement - but it means that, merely because Microsoft chose a byte order other than the one used for Internet protocols, they didn't eschew "the only way to allow different computers to communicate with each other over a network".
BTW: The IP protocols use network byte order. Network byte order != big endian. It's an abstraction. Just because it happens to be implemented as big endian, does mean that one should not use ntoh? on big endian machines.
The latter clause is true, but network byte order is not an abstraction - if somebody decides to implement it as little-endian, they're not going to be very successful at communicating with the rest of the world.
If [
read() and write()] were rewritten today, they would be knowledgable of such things (i.e. iostreams in C++).
Well, I have to disagree with your assertion; they might well still have had low-level operations, exposed to applications, for reading and writing raw byte streams, in addition to some marshalling/demarshalling operations.
Like they rewrote the code above the HAL to work Big-endian...
Not for Alpha, they didn't - Alpha runs little-endian on NT machines (and OpenVMS machines, and DEC OSF/1, err, umm, Digital UNIX machines, err, umm, Tru64 UNIX machines - I think they ran it big-endian on the T3D and T3E Cray machines, but I don't know of any other big-endian Alpha platforms).
As far as I know, they didn't run the MIPS or PowerPC platforms big-endian, either.
Very true, though I did use the word "port" instead of "recompile".
The port would probably be non-trivial, unless the X applications were written with, say, GNUstep.
I'm not an X hacker, but I would imagine that the APIs for XWindows and Aqua would have similar philosophies. I would assume both would have elements such as "Create_new_window", and "Build_new_menu", and "Get_mouse_click", etc.
I wouldn't necessarily assume that they're similar enough that a port wouldn't require a significant amount of effort.
If you plan to comment on the "cut and paste" issue, please read the X clipboard explanation, in detail, and make sure you fully understand it before commenting.
X - or, at least the X11 Inter-Client Communication Conventions Manual (ICCCM) - does specify a clipboard that works like the MacOS/Windows clipboard. Selecting text does not have to copy to that clipboard; it merely has to set the "primary selection". The middle mouse button can paste the "primary selection". Ctrl+C and Ctrl+X can copy/cut to the clipboard, and Ctrl+V can paste the clipboard even if you've subsequently selected something else (in which case it replaces the selection with what you're pasting).
Motif and GTK+, for example, work that way. Qt 1.x and 2.x, as used by KDE 1.x and 2.x, didn't; Qt 3.x, as used by KDE 3.x, works that way.
The KDE announcement speaks of the primary selection and the real clipboard as both being clipboards; that was, as far as I know, done to avoid "frightening the horses", i.e. to work around the confusion that some people suffer from, thinking that selecting text copies it to "the clipboard". The ICCCM doesn't call them both clipboards (it calls them both selections; for better or worse, that's standard terminology inside the innards of X, but you don't have to call them "selections" when talking to users).
Um, some of us like select-to-copy and middle-click-to-paste.
And some of us like select-to-select, middle-click-to-paste-current-selection, Ctrl-C-to-copy-current-selection-to-clipboard, and Ctrl-V-to-paste-clipboard.
Fortunately, that's all possible with X - Motif and GTK+, for example, have done that for ages, and now Qt 3.0 does it, so KDE 3.0 will do so as well.
(The clipboard is what Ctrl-C copies to. The current selection is what's selected. Don't confuse the two, they are not the same thing in X. See the X clipboard selection for details.)
KDE. Select: Copy first selection to clipboard. Ctrl+C: ignored. Select: Copy second selection to clipboard. Ctrl+V: No change, because second section is replaced with copy of second selection, the first selection being forgotten entirely.
As far as I know, that's Qt behavior that KDE inherits, and is fixed in Qt 3.0 (and will thus be fixed in KDE 3.0).
GNOME. Select: Copy first selection to X clipboard. Ctrl+C: Copy X clipboard to GTK+ clipboard. Select: Copy second selection to clipboard. Ctrl+V: Replace second selection with GTK+ clipboard (which contains the first selection).
No, it's more like
GNOME. Select: make the selected text the primary selection. Ctrl+C: copy primary selection to X clipboard "selection". Select: make the selected text the primary selection. Ctrl+V: replace the primary selection with the X clipboard.
KDE's semantics are the same as the oldskool X method, with Ctrl+V simply sending a button2 at the insertion point. GTK+ and some other toolkits have solved the problem by keeping a second clipboard for ^X ^C ^V.
Actually, as per the X clipboard explanatin, the "second clipboard" (which is actually the only clipboard; the middle mouse button pastes the current selection, not a clipboard) has been a standard part of X - or, at least, of the ICCCM - for ages (that's "ages" as in "dating back to the late 1980's").
Since Windows used to work on DEC Alpha, they must have already addressed that problem.
Since Windows worked in a 32-bit mode on DEC Alpha, they didn't necessarily address much of that problem when they did the Alpha port of Windows NT. It ran with 32-bit long and 32-bit pointers.
x86 stores integer data in a different binary format than other architectures.
A different binary format than some other architectures use. It's not the only processor capable of operating on little-endian data; a number of other processors can run in little-endian mode (most if not all MIPS processors, at least some SPARC V9 processors, Alpha processors, at least some PowerPC processors, at least some PA-RISC processors), and some of them typically run in little-endian mode (Alpha, for example).
One of the amazing things about TCP/IP is that it's designed in such a way as to be oblivous to the underlying architectural implementation. Hence, network byte order.
It's the only way to allow different computers to communicate with each other.
If by "it" you mean "network byte order", no, it is not the only way to allow different computers to communicate with each other over a network.
There are several ways to allow different computers to communicate with each other over a network (or via files). For example:
you can use big-endian (network) byte order for data sent over the wire, even if the machines are little-endian;
you can use little-endian byte order for data sent over the wire, even if the machines are big-endian;
you can "tag" the data with a byte-order indication;
you can send the data over the wire as text.
(There may well be others I haven't listed.)
Each of those is used by some protocol or protocols:
the first of them is used by IP, UDP, TCP, ICMP, and most if not all Internet protocols that don't use text, as well as by ONC RPC;
the second of them is used by SMB/CIFS (works just fine between little-endian PC's and big-endian machines running Samba, for instance);
the third of them is used by DCE RPC and, I have the impression, CORBA;
the fourth of them is used by {F,SM,HT,NN}TP and the like.
I would say though that the whole berkley socket interface is antiquated for handling binary socket data.
It wasn't intended to provide a presentation-layer protocol to allow machines with different data representations to communicate; it was intended to allow you to build that atop it, just as read() and write() (or ReadFile() and WriteFile(), for Win32 folks) don't provide a mechanism for writing out files in a data-representation-independent fashion, but they let you build such mechanisms atop them.
the other aspect to consider is that Mac OS X is POSIX compliant. Many open source apps can be ported (see the other story posted today). I could see how AbiWord, or many other open source Office apps could kill the need for purchasing M$ products.
Of course, the POSIX-compliance would be sufficient only if the office apps aren't graphical apps.:-)
(I.e., there's more to the API used by GUI applications than the "core OS" API. GUI apps from POSIX+X either have to be made to use the native MacOS X GUI APIs, or need to use a toolkit that can hide the native GUI APIs or drawing layer, or need to be run under an X server.
AbiWord, for example, currently appears to require an X server on MacOS X, according to the AbiWord download page.)
It's fine if your application returns numeric error codes. It makes the code a bit simpler so say "if x does y, error=2" than "if x does y, error='user is an idiot'".
HOWEVER, your program should also have an error handling routine and an error database. So, if the program returns error code 2, the error handler looks it up in the database and returns to the user "Error code=2. User is an idiot."
*Poof*, there goes the simplicity from the first paragraph. It'd be simpler for the programmer not to have the error handing routine or error database, but, as it appears we both agree, it'd be wrong, as it'd make life more complicated for the user.
Even better would be to list possible solutions to the error! ("Possible cause: User doesn't know his head from a hole in the ground. Suggested solution: Buy a clue.")
Yes, definitely (at least in cass where a solution can be listed; for example, it's not clear what solutions to "No such file or directory" exist, other than "type the path name correctly" or "make sure the file you want to process actually exists before you try to process it"); that's why, for example, if Ethereal can't open a capture device, it suggests "Please check to make sure you have sufficient permissions, and that you have the proper interface or pipe specified", as the problem is often that somebody's not running it as root on a machine where only root can do capturing.
on the other hand, as others have pointed out, a numeric error code is easy to find on google, regardless of what languages you understand
Yeah, it's really easy to find an error code of 2 on Google if some lamebrained UNIX application reports only numerical error codes. No tons of false hits to dig through, no sirree.... ("Can't open file: error = 2", indeed. Pfui.)
Besides, just because you've found a page with the error code, that doesn't mean you understand the language that page is in.
If you want to give a numeric error code, GIVE A HUMAN-READABLE ERROR MESSAGE WHILE YOU'RE AT IT, so that if you do understand the language you don't have to go to frigging Google (or to some frigging header file) to find out what the hell it means.
Slashdot Mirror
If by that assertion you mean that the changes to the ported applications are BSD-licensed, then, even if true, it's not a very interesting assertion - the applications in question are still GPLed.
On BSD, cc is gcc:
Two names, same program.
So? That's make, not the compiler.
Which, as noted, is the GNU C Compiler, even if the command name used to invoke it is cc, not gcc.
By "ports" do you mean "stuff in the {Free,Net,Open}BSD ports collections"? If so, have you surveyed, for example, all ~7000 FreeBSD ports to see what licenses they have, and determined that most of them are not GPLed (much less that most of them use the BSDL)?
If by "fBSD" you mean "FreeBSD", it doesn't have its own C compiler - or linker, or assembler; it uses GCC, GLD, and GAS. Take a look at /usr/src/gnu.
Not that this changes the argument about commercial contributions back to the OS, but to provide a non-rhetorical answer to what I presume was a rhetorical question:
The kernel support for USB is typically in sys/dev/usb in the source tree. (That's where it is on my FreeBSD 3.4 system; no, that's not a typo for "FreeBSD 4.3".) There may also be user-mode daemons or library routines there as well.
Here's a FreeBSD FireWire implementation under development; the most recent tarball came out 2002-05-30. I don't know what projects, if any, exist for NetBSD or OpenBSD.
Umm, I don't think that's what he meant by RPG.
I think he meant Report Program Generator.
Well, yeah, I wouldn't expect Sherman-Williams to be too happy about Duron in their stores.
Umm, if by "clone market" you mean the market of selling "IBM-compatible PC's", you left out a small step there, i.e. the step where they got into the computer business before there was a "clone market" (heck, before there were "IBM-compatible PC's").
They had a line of 16-bit minicomputers dating back to the 1960's, and other lines of computers such as the HP 3000's, the original 68K-based UNIX boxes, and the PA-RISC boxes (running both UNIX and the MPE OS from the HP 3000's; they used, as I remember, binary-to-binary translation to allow both native 32-bit PA-RISC code and the old stack-based 16-bit HP 3000 code to run on the PA-RISC 3000's).
It is.
The original poster is, indeed, correct; it appears that Nat Friedman was confused when he asserted that making Qt use GDK would enable them to share non-pixmap themes - the theming code is in GTK+ (which knows what scrollbars, buttons, etc. are), not in GDK (which doesn't).
(I say "non-pixmap themes" because, if I remember correctly, either Qt can load GTK+ pixmap themes, or KDE includes something that can turn them into Qt themes.)
No, that's not what GDK provides; it knows nothing about "button-like", for example.
See the GDK 2.x reference. It has calls to draw rectangles, but not "raised button-like rectangle[s]". It's GTK+ that knows all that fancy visual stuff.
No. The first UNIX to use that particular flavor of dynamic libraries was SunOS 4.0, which used a.out. (NOTE: I said "that particular flavor of dynamic libraries", not "dynamic libraries".)
The BSDs that had dynamic libraries originally used a.out as well; one could think of the a.out that SunOS 4.x and the BSDs used as an "improved a.out on steroids".
The System V Release 4 shared library mechanism was derived from the SunOS 4.x one; some of the things put into ELF (which was the executable image/shareable image/object file/core dump format devised by AT&T for System V Release 4) were done to better support that shared library mechanism. The free UNIXes that use ELF use reimplementations of the SVR4 shared library mechanism.
Systems using the Linux 1.x kernel didn't use a SunOS 4.x-style shared library mechanism, although it might have been possible to implement it if the 1.x kernel supported calls to memory-map files; perhaps 1.x lacked those calls.
Just out of curiosity, why is the Mach microkernel in that list? As I remember, NeXTStEP used it, so, as far as I know, it is part of the NeXT legacy of OS X.
Right, it's called mount_smbfs, as another message indicated.
No, mount_smbfs mounts using the FreeBSD SMB-client VFS - no NFS involved.
FreeBSD 5.0-CURRENT has ACPI, so, unless they back it out, it'll be in 5.0 when it's released.
I think there's already experimental ACPI support in the Linux 2.4 kernel.
I can't speak for NetBSD or OpenBSD, although a search for "ACPI" on the NetBSD Web site suggests that they're at least looking at the FreeBSD effort.
So, even if this were the Evil Plot by Microsoft to destroy free UNIXes that some people have suggested (I see no evidence that it is), it's only going to work for a while.
Try this link instead, as it actually works. (The "Preview" button, and the left mouse button, are your friends.)
(BTW, the top-level 802.x page has links to a lot of information about 802.x standards, including a page of links to pages for the working groups for each 802.x standard (I'm amused to find that the 802 standards committee appears to be supersititious - they say 802.13 wasn't used), as well as a link to the Get IEEE 802(TM) page from which you can download, for free, PDFs for 802.x standards that were published 6 or more months ago.
I am asserting that it is an abstraction that you'd damn well better implement as big-endian if you expect your machines to work on the Internet. Yes, you could, if you controlled all the machines that had to communicate with each other, re-implement it as little-endian, but that hardly makes it an abstraction whose implementation is irrelevant, because, in a huge number of systems, the implementation isn't irrelevant.
(Take a look at RFC 791; it quite explicitly states the byte order you use. It's no abstraction there....)
I wouldn't. I'd assume that they'd leave cross-platform data exchange to layers above read() and write() - oh, say, the XDR routines in the ONC RPC library, or routines to encode and decode using various encodings of ASN.1, or....
Then it still isn't the only way to allow different computers to communicate with each other over a network. It's the most common way, but there are probably different types of computers communicating using OSI COTP and CLNP, for example, as well.
Which means that the only way to allow different computers to communicate with each other over a network is for them to agree on a way to send data. Yes, that's a trivially true statement - but it means that, merely because Microsoft chose a byte order other than the one used for Internet protocols, they didn't eschew "the only way to allow different computers to communicate with each other over a network".
The latter clause is true, but network byte order is not an abstraction - if somebody decides to implement it as little-endian, they're not going to be very successful at communicating with the rest of the world.
Well, I have to disagree with your assertion; they might well still have had low-level operations, exposed to applications, for reading and writing raw byte streams, in addition to some marshalling/demarshalling operations.
Not for Alpha, they didn't - Alpha runs little-endian on NT machines (and OpenVMS machines, and DEC OSF/1, err, umm, Digital UNIX machines, err, umm, Tru64 UNIX machines - I think they ran it big-endian on the T3D and T3E Cray machines, but I don't know of any other big-endian Alpha platforms).
As far as I know, they didn't run the MIPS or PowerPC platforms big-endian, either.
The port would probably be non-trivial, unless the X applications were written with, say, GNUstep.
I wouldn't necessarily assume that they're similar enough that a port wouldn't require a significant amount of effort.
If you plan to comment on the "cut and paste" issue, please read the X clipboard explanation, in detail, and make sure you fully understand it before commenting.
X - or, at least the X11 Inter-Client Communication Conventions Manual (ICCCM) - does specify a clipboard that works like the MacOS/Windows clipboard. Selecting text does not have to copy to that clipboard; it merely has to set the "primary selection". The middle mouse button can paste the "primary selection". Ctrl+C and Ctrl+X can copy/cut to the clipboard, and Ctrl+V can paste the clipboard even if you've subsequently selected something else (in which case it replaces the selection with what you're pasting).
Motif and GTK+, for example, work that way. Qt 1.x and 2.x, as used by KDE 1.x and 2.x, didn't; Qt 3.x, as used by KDE 3.x, works that way.
The KDE announcement speaks of the primary selection and the real clipboard as both being clipboards; that was, as far as I know, done to avoid "frightening the horses", i.e. to work around the confusion that some people suffer from, thinking that selecting text copies it to "the clipboard". The ICCCM doesn't call them both clipboards (it calls them both selections; for better or worse, that's standard terminology inside the innards of X, but you don't have to call them "selections" when talking to users).
And some of us like select-to-select, middle-click-to-paste-current-selection, Ctrl-C-to-copy-current-selection-to-clipboard, and Ctrl-V-to-paste-clipboard.
Fortunately, that's all possible with X - Motif and GTK+, for example, have done that for ages, and now Qt 3.0 does it, so KDE 3.0 will do so as well.
(The clipboard is what Ctrl-C copies to. The current selection is what's selected. Don't confuse the two, they are not the same thing in X. See the X clipboard selection for details.)
As far as I know, that's Qt behavior that KDE inherits, and is fixed in Qt 3.0 (and will thus be fixed in KDE 3.0).
No, it's more like
See the X clipboard explanation for details.
Actually, as per the X clipboard explanatin, the "second clipboard" (which is actually the only clipboard; the middle mouse button pastes the current selection, not a clipboard) has been a standard part of X - or, at least, of the ICCCM - for ages (that's "ages" as in "dating back to the late 1980's").
Since Windows worked in a 32-bit mode on DEC Alpha, they didn't necessarily address much of that problem when they did the Alpha port of Windows NT. It ran with 32-bit long and 32-bit pointers.
A different binary format than some other architectures use. It's not the only processor capable of operating on little-endian data; a number of other processors can run in little-endian mode (most if not all MIPS processors, at least some SPARC V9 processors, Alpha processors, at least some PowerPC processors, at least some PA-RISC processors), and some of them typically run in little-endian mode (Alpha, for example).
If by "it" you mean "network byte order", no, it is not the only way to allow different computers to communicate with each other over a network.
There are several ways to allow different computers to communicate with each other over a network (or via files). For example:
(There may well be others I haven't listed.)
Each of those is used by some protocol or protocols:
It wasn't intended to provide a presentation-layer protocol to allow machines with different data representations to communicate; it was intended to allow you to build that atop it, just as read() and write() (or ReadFile() and WriteFile(), for Win32 folks) don't provide a mechanism for writing out files in a data-representation-independent fashion, but they let you build such mechanisms atop them.
Of course, the POSIX-compliance would be sufficient only if the office apps aren't graphical apps. :-)
(I.e., there's more to the API used by GUI applications than the "core OS" API. GUI apps from POSIX+X either have to be made to use the native MacOS X GUI APIs, or need to use a toolkit that can hide the native GUI APIs or drawing layer, or need to be run under an X server.
AbiWord, for example, currently appears to require an X server on MacOS X, according to the AbiWord download page.)
*Poof*, there goes the simplicity from the first paragraph. It'd be simpler for the programmer not to have the error handing routine or error database, but, as it appears we both agree, it'd be wrong, as it'd make life more complicated for the user.
Yes, definitely (at least in cass where a solution can be listed; for example, it's not clear what solutions to "No such file or directory" exist, other than "type the path name correctly" or "make sure the file you want to process actually exists before you try to process it"); that's why, for example, if Ethereal can't open a capture device, it suggests "Please check to make sure you have sufficient permissions, and that you have the proper interface or pipe specified", as the problem is often that somebody's not running it as root on a machine where only root can do capturing.
Yeah, it's really easy to find an error code of 2 on Google if some lamebrained UNIX application reports only numerical error codes. No tons of false hits to dig through, no sirree.... ("Can't open file: error = 2", indeed. Pfui.)
Besides, just because you've found a page with the error code, that doesn't mean you understand the language that page is in.
If you want to give a numeric error code, GIVE A HUMAN-READABLE ERROR MESSAGE WHILE YOU'RE AT IT, so that if you do understand the language you don't have to go to frigging Google (or to some frigging header file) to find out what the hell it means.