I've noticed that Sun ships an intel version of Solaris right now and i'm assuming that they'll upgrade it to merced.
Yes, they're doing an IA-64 port.
does sun sell intel machines in addition to their sparc products?
No - their last x86 machine was the Sun386i (which wasn't PC-compatible, it was more of a Sun with an 80386 and 80387); Solaris for Intel is something you put on a PC you get from somebody other than Sun.
Re:And Windows NT is turning 11 next month...
on
Linux Turns 8
·
· Score: 1
There we no design decisions made in the Linux kernel. All the design was done already.
The API design was; the design of the implementation wasn't - they may well have adopted published ideas about UNIX kernels, but NT's I/O subsystem adopted ideas from VMS. (No, I'm not saying NT ripped off code from VMS; I have no reason to believe it includes VMS code.)
Whereas the UNIX API has been around forever, yet all of the applications avaiable for it are difficult to use, inflexible, powerless,
E.g., Internet Explorer 5?:-)
(If you're going to say "all", make sure you mean it.)
and have arcane misdesigns such as case sensitivity.
If you're referring to case sensitivity for file names, that's the fault of the OS, not of the applications, unless you're arguing that they should all have included code to work around the OS's case-sensitivity. (No, I am not defending case sensitivity here, nor do I plan to defend it.)
...and that 32-bit support didn't come in until 1990 with OS/2 2.0. By then, I'm sure someone (SCO?) was selling a i386 Unix.
Heck, Sun had a port of SunOS 4.0 to the Compaq Deskpro 386, or whatever it was called - they didn't sell it, though, as they were just using the Compaq as a development mule for the Sun386i; the latter was definitely not a PC-compatible machine (Sun-style boot monitor rather than a BIOS, for one thing). I don't think the port included SunView, and I've no idea whether it would've run on anybody else's PC. (In any case, it doesn't count very much, as Sun never sold 4.0[.x] on PCs.)
I'm not sure when the first Solaris 2.x release for x86 came out, but I think it might've been after 1990.
SCO Unix (SV-based, I think), or SCO Xenix (originally V7-based, I think, with System N stuff added on)?
as did Sequent
Did Dynix run on PC's, or just on Sequent's machines (which were, as far as I know, not "IBM-compatible PCs", even if they did use 386's as processors)?
and Burroughs (Unisys)
If you're thinking of BTOS, wasn't that actually Convergent Technology's CTOS, or something based on CTOS?
If so, did that run on PC's, or just on Convergent's x86 machine (which I also thought weren't PC-compatible, although they - or Burroughs or Unisys, depending on whether they bought Convergent before or after the merger - may later have made it run on PCs)?
I believe the BSD API is sufficiently different from the SYSV/Linux (not quite the same thing) API that one side or the other would have to either change their entire API (yeah, right, hell will go through several cycles of freazing/thawing before that happens), or provide some sort of compatability layer, possibly through dynamic linking.
The APIs are quite similar - UNIX-flavored OSes don't have immense differences between their APIs, these days, and at least some of the differences (e.g., signal()) can be dealt with by using shiny new POSIX replacements that work the same (or, at least, should work the same) on all of them.
For example, read() is read(), getpwnam() is getpwnam(), etc. - neither OS would have to completely change those for compatibility.
The application binary interfaces might be different, e.g. the layout of a stat structure might be different, which is why there's a compatibility layer.
Once upon a time, there was a GNOME style guide, but I can't find it on the GNOME developer's site; however, an AltaVista search for "GNOME style guide" turned up some links to what I presume is said old GNOME style guide - or maybe I searched for something else, because those links didn't show up in my latest search. Instead, I found a message from Frederico Mena Quintero, from March 1999, saying
The current style guide is in gnome-libs/devel-docs/suggestions.txt.
(I think the IBM CUA spec may have influenced Motif and its style guide; given that GTK+'s look and feel somewhat resembles that of Motif, and that Qt offers a Motif L&F as one of its options, and that I think it may also have influenced Windows' style and style guide, which has, in turn, influenced the styles of various UNIX GUI projects, it may be that the CUA has already contributed....)
I don't know to what extent the GUA guides owe a debt to the Mac human interface guidelines. Then again, I just threw that last sentence in to provide an excuse for a link to another on-line style guide....
But MS claims that fragmentation is within a group of OS's that all seemingly exist for the same function. IE, the server market. According Microsoft, if I write a program and it doesn't compile under a different OS, then that OS is fragmented.
I don't think they say a single OS - i.e., a single set of CD's that come in a box from vendor XXX - is fragmented.
As far as I know, what they're saying is that "UNIX", in the sense of "all the various OSes offering a UNIX-compatible API", is fragmented, in that you may have to do porting work to move an application between Solaris, HP-UX, Linux, AIX, etc. (because the application may, for example, use stuff beyond the "UNIX-compatible" part of the API, i.e. extensions present in vendor A's OS but not present in vendor B's OS or present in vendor B's OS but with a different API).
If so, they're right. (But, then again, as you note, the same applies to the set of OSes offering a "Win32-compatible API", if, for example, there are APIs present in Windows 98 but not present in NT 4.0.)
However, as you don't have, say, OS/2 from IBM and a mostly-compatible-but-not-exactly-the-same OS/2 from the other company that was involved in OS/2 development, OS/2 isn't "fragmented" - something can be "fragmented" only if there are multiple fragments, and there aren't multiple flavors of OS/2 out there, as far as I know.
Neither Windows nor OS/2 claim to be "UNIX-compatible", so the fact that Windows OT and OS/2 don't offer POSIX.1 compatibility doesn't render them "fragmented" (and the limited POSIX.1 compatibility in NT is sufficiently limited that I, at least, don't consider it one of the fragments of fragmented UNIX; if you add Interix, maybe).
OS/2 was the first 32bit, multi-tasking, OS out there.
True only if you further qualify "first 32-bit multi-tasking OS"; 32-bit machines supporting multitasking OSes existed long before the 80386 came out.
It might have been the first 32-bit multi-tasking OS for "IBM-compatible PCs" - did it, in fact, come out before, say, System V/386? If not, then you might have to further qualify it as "the first 32-bit multi-tasking OS that might've become mass-market" (feel free to insert debate here about whether a PC UNIX, back then, was likely to become mass-market).
There is the drawback that OS/2 is fragmented on the source-code level, as well as the binary level, just like Windows (ie, no POSIX.1 compatibility)
In what way does that constitute "fragmentation"? I'd consider OS/2 "fragmented" only if there were multiple versions that weren't fully binary-compatible and weren't fully source-compatible (other than "not all applications built on/built for/written for release N run on Release N-1")
...if Linux and FreeBSD are the same in Userland as we've been hearing.
I'm not sure who's saying they're "the same in userland", but their userlands aren't the same code - the GNU stuff in userland may be the same in some BSD and some Linux distribution, but the C library in *BSD isn'tGNU "libc", and there are many non-GNU utilities in *BSD as well (the window system is probably similar, as most Linux distributions and the BSDs, with the possible exception of the commercial BSD/OS, use XFree86).
Re:Does the WTO know about this?
on
CALEA update
·
· Score: 1
This sounds like a subsidy to Nortel, plus laws which close off the market for router equipment to non-US vendors.
why not attack Cygnus for holding back source code to the GNUPro tools that are available as binaries only?
Because the only stuff from Cygnus available as binaries only isn't GPLed? The GNUPro FAQ claims that "As part of our commitment to Open Sourceware, Cygnus provides source code with all releases of the GNUPro Toolkit." (Note that "provides source code with all releases" doesn't necessarily imply "makes the source code available from our FTP site"; they don't have to make the source conveniently available, they just have to make it available to those to whom they've distributed the binaries - and can't prohibit those to whom they've distributed the binaries from further redistributing binaries or source to GPLed programs).
After all, Linux is under the GPL, not the BSD license.
If the people doing the IA-64 port are not considered to be "copying" or "distributing" amongst themselves the modified Linux kernel, GNU libc, etc. they're doing for the port, then the GPL doesn't oblige them to make the source available to others, nor does it mean they can't stop any of those people from "distributing" the programs or the source to the programs to others.
The impression I have from what I've seen is that the NDA will end when Intel releases all the details of IA-64 (unless I've missed something, they haven't released the full details, just those details that would be used by application developers).
The AS/400s are all RS6000s inside now. Every one, with only the microcode different.
The PowerPC AS/400s do, indeed, have POWER-family architecture processors, just as RS/6000's do - but if having a POWER-family architecture processor is sufficient to make an AS/400 "an RS/6000 inside now", it's also sufficient to make an AS/400 a Power Macintosh inside now....
However, the PowerPC processors in those AS/400s have, according to Frank Soltis' Inside the AS/400, some stuff not in all PowerPC processors, e.g. a tagged mode wherein pointers and non-pointers are tagged differently. I think I've heard a claim that the RS64 PowerPC processor is the same processor as one of the AS/400 processors, but run with tagged mode turned off; however.
Is all the other stuff in the AS/400's, e.g. support chips, I/O subsystem, etc. the same as on the RS/6000's?
Perhaps even more fitting for the "Genetic engineering boosts mouse intelligence" story, given that "Algernon" in Flowers for Algernon was the mouse on which they'd done the initial intelligence-boosting experiments, before trying them on the narrator of Flowers for Algernon.
...unless you buy the Qt Professional edition, which lets you do commercial X11 apps and Windows apps. The QPL doesn't change that; it just changes the terms for the Free Edition.
It is merely the word "horsepower" translated into french.
Yes, but is a French "ch".74 kW? I had the impression that German "pferdestarken" weren't equal to US/UK "horsepower" (although the BMW Germany technical data page for the car in question just lists kilowatts, so maybe pS aren't used any more).
As far as the OS/390, heh, Unix-like OS? As long has you don't mind submitting your "Unix" command, wait 2 days for it to reach the begining of the batch queue, then going to the datacenter to pick out the print job for your "ls" command.
This may or may not actually mean anything more than "few people didn't think Solaris was UNIX, but people tended not to think of OS/3xx as UNIX, given that using its Time Sharing Option was, once upon a time, likened by one UNIXer to 'kicking a dead whale down the beach', so IBM had more incentive to get OS/390 through certification."
Of course, there are options being contemplated that would presumably use ASCII ("Well, the radio's exploded, what's on the mainframe then?" "Looks like a penguin...." The kernel "usually boots to the point of mounting the boot ramdisk, and trying to start/bin/sh", but "bombs because umm, diferent reason every time"; a glibc port has also been started. I wonder what hardware they're using....).
Now let's get nice and dirty. Solaris is up to what, 2.7? After being SunOS 4.1.13. (Not sure on version number here, feel free to correct.)
Sure, no problem, always happy to correct. SunOS is up to 5.7, that being the OS component of The Operating Environment Almost Known As Solaris 2.7 (the marketoons apparently decided that, as they were probably not going to rev the major version number any time soon, to turn the minor version number into a major version number); the highest version that the 4.x releases went up to was 4.1.4 (not 4.1.14, or 4.1.13).
And still has bugs. Just recently IBM released OS/390 Version 2, Release 8. A followup to Version 2, Release 7.
...and probably still has bugs, although it may well have fewer than Solaris.
What exactly does a comparison of version numbers prove, especially given that OS/3xx has had more than 2 versions - remember, it dates back to the early '60's, although, by now, it may be like the old axe that's had its head replaced three times, and its handle replaced twice, but it's still "the same axe", i.e. I don't know how much code from the first release of OS/360 remains in OS/390 Version 2, Release 8 (probably only a small portion, if any)? (Note that there's probably been a lot of code replaced in SunOS, too - the step from 4.x to 5.x involved tossing out the old code base and switching to SVR4.0, and then changing a lot of stuff in the SVR4.0 code base; I don't know how much SunOS 5.0 code remains.)
And, in any case, OS/390 isn't AIX and doesn't run on an RS/6000, and OS/400 isn't AIX, either, and also doesn't run on an RS/6000, so the merits of those OSes only indirectly reflects on the merits of IBM (which may well be large enough that the fact that product A might be Really Nifty doesn't necessarily imply that product B is also Really Nifty).
IBM *invented* the mainframe
Define "mainframe". Are you asserting that IBM sold computers before, say, Univac did (if so, could I see references, please?), or that the first computer worthy of the name "mainframe" was an IBM?
I believe that precise definition (OS equals kernel-mode code) is used in _Operating Systems: Design and Implementation_, by Andrew S. Tanenbaum.
...although, in Modern Operating Systems, he uses a similar definition and then later discusses Amoeba, which does a lot of what he considers "operating system" stuff in servers, although I didn't see anything in a quick look that indicated whether all those servers ran in kernel mode or not. One might consider a server process with special privileges, with which unprivileged code communicates via messages as "privileged code" even if it doesn't run in kernel mode, though.
On the other hand, the MIT Exokernel is a small kernel that "concentrates solely on securely multiplexing the raw hardware", with "library operating systems" running in userland (but in the context of the process requesting services from the OS) implementing "traditional operating system abstractions" such as file systems and networking stacks.
I.e., the APIs of modern systems tend to be implemented with several layers of abstraction; the layer of abstraction that's implemented by code with special privileges often implements only a part of the API, and may not implement any of it directly. Even in a "traditional" UNIX-flavored system such as a Linux distribution, in which a lot of the API is implemented by kernel code (plus a system call stub wrapper), enough of the API isn't that credit is due the implementors of the rest of the API as well.
(Alas, I don't have my copy of Inside the AS/400 at work, so I can't check how much of OS/400 runs in kernel mode, but the system software on the AS/400 is another interesting piece of software, with an architecture fairly different from the "conventional" architecture one gets exposed to with UNIX-flavored systems, Windows OT, Windows NT, VMS, etc..)
Is as also expected that the software will run on FreeBSD as well as on Linux.
so it's "for Linux", but not exclusively for Linux.
In fact, that page seems to indicate that it's not even exclusively for Linux and FreeBSD, as it says
The aim of the project is to develop tools and drivers for Nokia mobile phones for Linux, BSD and other Unixes/operating systems.
so, whilst "The development sources are currently targeted towards Linux systems", that doesn't mean it's a Linux-only project, it may just mean the developers currently have only Linux boxes, or haven't cleaned up non-portable code yet, or haven't written for other OSes versions of whatever OS-dependent code exists, or something such as that.
and since when do applications have to be distribution specific ? I want a standard method of doing it - distro/architecture/wm independent.
In the Debian system, at least, it appears that applications - in the sense of "the actual application code" - don't install menu items, a script in the package run by the package installation code installs the menu items.
Thus, the application doesn't have to be distribution-specific...
...only the installation script does.
If applications are distributed as both RPMs and Debian packages, that's not an issue.
However, if it's possible to just ram an RPM through Alien and install it on a Debian system, one could possibly argue that it'd be nice not to have to distribute applications as both RPMs and Debian packages, in which case a non-distribution-specific menu-installation scheme would be required.
(And, yes, such a scheme - one at least as independent of which window manager or desktop you're running as Debian's - sounds as if it'd be a good idea.)
b. Adding an app to the K-Menu can be accomplished by picking up an icon for the app, and dropping it onto the menu. It just doesn't get any easier than that.
I infer from "like a shell script call from an RPM" that the original poster wanted a standard way to automatically add an item to the K menu when an application is installed, not a way for a user to manually add an application to the K menu.
From a quick look at the "Configuration file handling section" of the Debian Packaging Manual, Debian also has a mechanism to run scripts during the installation of a package (it seems to talk about creating configuration files, but I don't know if that means it's incapable of editing existing configuration files), and the *BSD package facility also has such a mechanism, so a feature such as this doesn't depend on using RPM.
Then again, Debian also appears to have a mechanism to let you add items to all "well-behaved" window managers/desktops, as shown in the Debian Menu System documentation, which it appears the script run when a package is installed could use; I don't know if KDE is "well-behaved" in that sense, i.e. whether Debian packages for KDE include scripts for/etc/menu-methods.
Or kilowatts; for example, this page on the BMW 320Ci at BMW France lists the engine's power both in "ch" ("chevaux", presumably, although I don't know what relationship "ch" has to "horsepower") and kW.
Slashdot Mirror
Yes, they're doing an IA-64 port.
No - their last x86 machine was the Sun386i (which wasn't PC-compatible, it was more of a Sun with an 80386 and 80387); Solaris for Intel is something you put on a PC you get from somebody other than Sun.
The API design was; the design of the implementation wasn't - they may well have adopted published ideas about UNIX kernels, but NT's I/O subsystem adopted ideas from VMS. (No, I'm not saying NT ripped off code from VMS; I have no reason to believe it includes VMS code.)
E.g., Internet Explorer 5? :-)
(If you're going to say "all", make sure you mean it.)
If you're referring to case sensitivity for file names, that's the fault of the OS, not of the applications, unless you're arguing that they should all have included code to work around the OS's case-sensitivity. (No, I am not defending case sensitivity here, nor do I plan to defend it.)
Heck, Sun had a port of SunOS 4.0 to the Compaq Deskpro 386, or whatever it was called - they didn't sell it, though, as they were just using the Compaq as a development mule for the Sun386i; the latter was definitely not a PC-compatible machine (Sun-style boot monitor rather than a BIOS, for one thing). I don't think the port included SunView, and I've no idea whether it would've run on anybody else's PC. (In any case, it doesn't count very much, as Sun never sold 4.0[.x] on PCs.)
I'm not sure when the first Solaris 2.x release for x86 came out, but I think it might've been after 1990.
SCO Unix (SV-based, I think), or SCO Xenix (originally V7-based, I think, with System N stuff added on)?
Did Dynix run on PC's, or just on Sequent's machines (which were, as far as I know, not "IBM-compatible PCs", even if they did use 386's as processors)?
If you're thinking of BTOS, wasn't that actually Convergent Technology's CTOS, or something based on CTOS?
If so, did that run on PC's, or just on Convergent's x86 machine (which I also thought weren't PC-compatible, although they - or Burroughs or Unisys, depending on whether they bought Convergent before or after the merger - may later have made it run on PCs)?
The APIs are quite similar - UNIX-flavored OSes don't have immense differences between their APIs, these days, and at least some of the differences (e.g., signal()) can be dealt with by using shiny new POSIX replacements that work the same (or, at least, should work the same) on all of them.
For example, read() is read(), getpwnam() is getpwnam(), etc. - neither OS would have to completely change those for compatibility.
The application binary interfaces might be different, e.g. the layout of a stat structure might be different, which is why there's a compatibility layer.
presumably meaning in the GNOME source tree.
There's also a page on the KDE developer's site with links to KDE style guide information.
(I think the IBM CUA spec may have influenced Motif and its style guide; given that GTK+'s look and feel somewhat resembles that of Motif, and that Qt offers a Motif L&F as one of its options, and that I think it may also have influenced Windows' style and style guide, which has, in turn, influenced the styles of various UNIX GUI projects, it may be that the CUA has already contributed....)
I don't know to what extent the GUA guides owe a debt to the Mac human interface guidelines. Then again, I just threw that last sentence in to provide an excuse for a link to another on-line style guide....
I don't think they say a single OS - i.e., a single set of CD's that come in a box from vendor XXX - is fragmented.
As far as I know, what they're saying is that "UNIX", in the sense of "all the various OSes offering a UNIX-compatible API", is fragmented, in that you may have to do porting work to move an application between Solaris, HP-UX, Linux, AIX, etc. (because the application may, for example, use stuff beyond the "UNIX-compatible" part of the API, i.e. extensions present in vendor A's OS but not present in vendor B's OS or present in vendor B's OS but with a different API).
If so, they're right. (But, then again, as you note, the same applies to the set of OSes offering a "Win32-compatible API", if, for example, there are APIs present in Windows 98 but not present in NT 4.0.)
However, as you don't have, say, OS/2 from IBM and a mostly-compatible-but-not-exactly-the-same OS/2 from the other company that was involved in OS/2 development, OS/2 isn't "fragmented" - something can be "fragmented" only if there are multiple fragments, and there aren't multiple flavors of OS/2 out there, as far as I know.
Neither Windows nor OS/2 claim to be "UNIX-compatible", so the fact that Windows OT and OS/2 don't offer POSIX.1 compatibility doesn't render them "fragmented" (and the limited POSIX.1 compatibility in NT is sufficiently limited that I, at least, don't consider it one of the fragments of fragmented UNIX; if you add Interix, maybe).
Heck, IBM had such an OS back in the 60's; its name even began with "OS/". :-)
(Yeah, System/360's, although they had 32-bit registers, ignored the upper 8 bits of a pointer - but I think the 68000 may have done the same.)
(Yes, other mainframe makers had multi-tasking OSes back then as well, but many of them were 36-bit or 48-bit OSes....)
Presumably the poster mean "first 32-bit multi-tasking OS for 'IBM-compatible PCs'".
True only if you further qualify "first 32-bit multi-tasking OS"; 32-bit machines supporting multitasking OSes existed long before the 80386 came out.
It might have been the first 32-bit multi-tasking OS for "IBM-compatible PCs" - did it, in fact, come out before, say, System V/386? If not, then you might have to further qualify it as "the first 32-bit multi-tasking OS that might've become mass-market" (feel free to insert debate here about whether a PC UNIX, back then, was likely to become mass-market).
In what way does that constitute "fragmentation"? I'd consider OS/2 "fragmented" only if there were multiple versions that weren't fully binary-compatible and weren't fully source-compatible (other than "not all applications built on/built for/written for release N run on Release N-1")
I'm not sure who's saying they're "the same in userland", but their userlands aren't the same code - the GNU stuff in userland may be the same in some BSD and some Linux distribution, but the C library in *BSD isn'tGNU "libc", and there are many non-GNU utilities in *BSD as well (the window system is probably similar, as most Linux distributions and the BSDs, with the possible exception of the commercial BSD/OS, use XFree86).
Nortel Networks are a "non-US vendor", as the "About Us" page on their website indicates (note the location of their corporate headquarters).
Because the only stuff from Cygnus available as binaries only isn't GPLed? The GNUPro FAQ claims that "As part of our commitment to Open Sourceware, Cygnus provides source code with all releases of the GNUPro Toolkit." (Note that "provides source code with all releases" doesn't necessarily imply "makes the source code available from our FTP site"; they don't have to make the source conveniently available, they just have to make it available to those to whom they've distributed the binaries - and can't prohibit those to whom they've distributed the binaries from further redistributing binaries or source to GPLed programs).
If the people doing the IA-64 port are not considered to be "copying" or "distributing" amongst themselves the modified Linux kernel, GNU libc, etc. they're doing for the port, then the GPL doesn't oblige them to make the source available to others, nor does it mean they can't stop any of those people from "distributing" the programs or the source to the programs to others.
The impression I have from what I've seen is that the NDA will end when Intel releases all the details of IA-64 (unless I've missed something, they haven't released the full details, just those details that would be used by application developers).
The PowerPC AS/400s do, indeed, have POWER-family architecture processors, just as RS/6000's do - but if having a POWER-family architecture processor is sufficient to make an AS/400 "an RS/6000 inside now", it's also sufficient to make an AS/400 a Power Macintosh inside now....
However, the PowerPC processors in those AS/400s have, according to Frank Soltis' Inside the AS/400, some stuff not in all PowerPC processors, e.g. a tagged mode wherein pointers and non-pointers are tagged differently. I think I've heard a claim that the RS64 PowerPC processor is the same processor as one of the AS/400 processors, but run with tagged mode turned off; however.
Is all the other stuff in the AS/400's, e.g. support chips, I/O subsystem, etc. the same as on the RS/6000's?
Perhaps even more fitting for the "Genetic engineering boosts mouse intelligence" story, given that "Algernon" in Flowers for Algernon was the mouse on which they'd done the initial intelligence-boosting experiments, before trying them on the narrator of Flowers for Algernon.
I'm not. I'm aware of the old gross vs. net horsepower difference, but the "PS vs. HP" stuff I was thinking of was after 1971.
...unless you buy the Qt Professional edition, which lets you do commercial X11 apps and Windows apps. The QPL doesn't change that; it just changes the terms for the Free Edition.
Yes, but is a French "ch" .74 kW? I had the impression that German "pferdestarken" weren't equal to US/UK "horsepower" (although the BMW Germany technical data page for the car in question just lists kilowatts, so maybe pS aren't used any more).
OS/390 got its UNIX 95 certification before Solaris 2.6/SPARC got its UNIX 95 certification.
This may or may not actually mean anything more than "few people didn't think Solaris was UNIX, but people tended not to think of OS/3xx as UNIX, given that using its Time Sharing Option was, once upon a time, likened by one UNIXer to 'kicking a dead whale down the beach', so IBM had more incentive to get OS/390 through certification."
But, yes, it does have a UNIX-compatible environment, although it's not compatible at the character-set level (i.e., it uses EBCDIC, not ASCII...).
Of course, there are options being contemplated that would presumably use ASCII ("Well, the radio's exploded, what's on the mainframe then?" "Looks like a penguin...." The kernel "usually boots to the point of mounting the boot ramdisk, and trying to start /bin/sh", but "bombs because umm, diferent reason every time"; a glibc port has also been started. I wonder what hardware they're using....).
Sure, no problem, always happy to correct. SunOS is up to 5.7, that being the OS component of The Operating Environment Almost Known As Solaris 2.7 (the marketoons apparently decided that, as they were probably not going to rev the major version number any time soon, to turn the minor version number into a major version number); the highest version that the 4.x releases went up to was 4.1.4 (not 4.1.14, or 4.1.13).
...and probably still has bugs, although it may well have fewer than Solaris.
What exactly does a comparison of version numbers prove, especially given that OS/3xx has had more than 2 versions - remember, it dates back to the early '60's, although, by now, it may be like the old axe that's had its head replaced three times, and its handle replaced twice, but it's still "the same axe", i.e. I don't know how much code from the first release of OS/360 remains in OS/390 Version 2, Release 8 (probably only a small portion, if any)? (Note that there's probably been a lot of code replaced in SunOS, too - the step from 4.x to 5.x involved tossing out the old code base and switching to SVR4.0, and then changing a lot of stuff in the SVR4.0 code base; I don't know how much SunOS 5.0 code remains.)
And, in any case, OS/390 isn't AIX and doesn't run on an RS/6000, and OS/400 isn't AIX, either, and also doesn't run on an RS/6000, so the merits of those OSes only indirectly reflects on the merits of IBM (which may well be large enough that the fact that product A might be Really Nifty doesn't necessarily imply that product B is also Really Nifty).
Define "mainframe". Are you asserting that IBM sold computers before, say, Univac did (if so, could I see references, please?), or that the first computer worthy of the name "mainframe" was an IBM?
...although, in Modern Operating Systems, he uses a similar definition and then later discusses Amoeba, which does a lot of what he considers "operating system" stuff in servers, although I didn't see anything in a quick look that indicated whether all those servers ran in kernel mode or not. One might consider a server process with special privileges, with which unprivileged code communicates via messages as "privileged code" even if it doesn't run in kernel mode, though.
On the other hand, the MIT Exokernel is a small kernel that "concentrates solely on securely multiplexing the raw hardware", with "library operating systems" running in userland (but in the context of the process requesting services from the OS) implementing "traditional operating system abstractions" such as file systems and networking stacks.
I.e., the APIs of modern systems tend to be implemented with several layers of abstraction; the layer of abstraction that's implemented by code with special privileges often implements only a part of the API, and may not implement any of it directly. Even in a "traditional" UNIX-flavored system such as a Linux distribution, in which a lot of the API is implemented by kernel code (plus a system call stub wrapper), enough of the API isn't that credit is due the implementors of the rest of the API as well.
(Alas, I don't have my copy of Inside the AS/400 at work, so I can't check how much of OS/400 runs in kernel mode, but the system software on the AS/400 is another interesting piece of software, with an architecture fairly different from the "conventional" architecture one gets exposed to with UNIX-flavored systems, Windows OT, Windows NT, VMS, etc..)
...and I noticed that the gnokii project home page says
so it's "for Linux", but not exclusively for Linux.
In fact, that page seems to indicate that it's not even exclusively for Linux and FreeBSD, as it says
so, whilst "The development sources are currently targeted towards Linux systems", that doesn't mean it's a Linux-only project, it may just mean the developers currently have only Linux boxes, or haven't cleaned up non-portable code yet, or haven't written for other OSes versions of whatever OS-dependent code exists, or something such as that.
In the Debian system, at least, it appears that applications - in the sense of "the actual application code" - don't install menu items, a script in the package run by the package installation code installs the menu items.
Thus, the application doesn't have to be distribution-specific...
...only the installation script does.
If applications are distributed as both RPMs and Debian packages, that's not an issue.
However, if it's possible to just ram an RPM through Alien and install it on a Debian system, one could possibly argue that it'd be nice not to have to distribute applications as both RPMs and Debian packages, in which case a non-distribution-specific menu-installation scheme would be required.
(And, yes, such a scheme - one at least as independent of which window manager or desktop you're running as Debian's - sounds as if it'd be a good idea.)
I infer from "like a shell script call from an RPM" that the original poster wanted a standard way to automatically add an item to the K menu when an application is installed, not a way for a user to manually add an application to the K menu.
From a quick look at the "Configuration file handling section" of the Debian Packaging Manual, Debian also has a mechanism to run scripts during the installation of a package (it seems to talk about creating configuration files, but I don't know if that means it's incapable of editing existing configuration files), and the *BSD package facility also has such a mechanism, so a feature such as this doesn't depend on using RPM.
Then again, Debian also appears to have a mechanism to let you add items to all "well-behaved" window managers/desktops, as shown in the Debian Menu System documentation, which it appears the script run when a package is installed could use; I don't know if KDE is "well-behaved" in that sense, i.e. whether Debian packages for KDE include scripts for /etc/menu-methods.
Or kilowatts; for example, this page on the BMW 320Ci at BMW France lists the engine's power both in "ch" ("chevaux", presumably, although I don't know what relationship "ch" has to "horsepower") and kW.