There is no firm release date for GCC 3 at this time (Jan 2000), nor has a decision been made whether the next major release of gcc will still be 2.x, or 3.0.
I have a windows box just to play games and run my scanner, I don't use it for any real work.
Just out of curiosity, would SANE be sufficient to handle your scanner under FreeBSD (or any other flavor of UNIX, including Linux, free or not), or does SANE have no driver for it or are there also Windows applications you need?
(There's also WINE, for some Windows applications, although I think they may still warn that it's alpha code and not everything will necessarily work.
BSD Unixes are mostly ports. They started as a System X release, then some bright folks at Berekely add some extra stuff (like TCP/IP) and pretty soon there was BSD.
System {III,V} didn't exist when they did the first BSD; the first Berkeley Software Distribution was a collection of software to put atop the Sixth Edition (and possibly also the Seventh Edition) of the UNIX from Bell Labs Research. 3BSD and 4BSD were based on the 32V UNIX from Research, which was essentially a Seventh Edition port to the VAX; the Berkeley folk added demand paging (and other stuff, such as job control, and a TTY driver more pleasant for the user, and ex and vi, and curses, and so on), and, in 4.2BSD, added the BSD file system (file names > 14 characters, symlinks, bigger block size, different allocation policies) and their TCP/IP stack (although that was far from the first TCP/IP stack for UNIX).
That's why BSD looks less System V-ish than most other flavors of UNIX these days, including most Linux distributions (although I have the impression some distributions - Slackware? - might have a BSD-ish rather than an SV-ish init), although, over time, BSD has grown to look more SV-ish (Paul Vixie's cron is SV-flavored rather than the V7-flavored cron that BSD used to have, and various other system calls, other API routines, commands, etc. have flowed into BSD), just as SV has grown more BSDish (symlinks, BSD-style socket calls standard, and various other system calls, other API routines, commands, etc. have flowed into SVR4).
I have yet to see cut/copy/paste shortcuts implemented consistently among apps and desktops in X. The KDE apps usually use Ctrl-X/Ctrl-C/Ctrl-V, but Netscape uses Alt-C/Alt-V/Alt-P. Other programs use other things, if they support it at all.
GTK+ apps also tend to use Ctrl-{X,C,V}, bless their soul (GTK+ itself uses them in its widgets).
The rationale for Netscape's choice may have been some noise about supporting Emacs keybindings, but it drives me nuts; I'll have to see if I can bludgeon it into going with ^X/^C/^V by tweaking my.Xdefaults file.
Then again, it also irritates me that Quicken 2000 appears not to use ^X/^C/^V either - and that's not an X app, it's a Windows app. At least the other Windows apps that I've used are better behaved than that.
At the same time, it makes me nuts when I highlight something, want to paste it into something else, and have to spend time figuring out how to do it.
...which isn't helped by Qt's apparent insistence on using the X primary selection, rather than the X clipboard selection, as its clipboard.
At least middle-mouse-button paste-current-selection tends to work most places, at least if you aren't trying to replace a selected chunk of text with another chunk of text (as doing the latter means you have to select something other than that which you're trying to copy...).
I run all manners of i686 builds for various software (including Mozilla) on my K6-450.
Yes, "optimized for" doesn't necessarily imply "only runs on"; "optimized for" might just mean "instructions scheduled for", "instructions that run fast on used and instructions that don't run fast on not used", etc.; it'd be "only runs on" if it used instructions available only on the processor family in question, e.g. the conditional moves on P6 processors.
Oh, and don't let the fact that he works for M$ sway you, I'm fairly convinced no one listens to him there.:)
Besides, that should perhaps be "worked for"; he works for Cooper Interaction Design (although, as the name of the company suggests, "works for" probably understates the case:-)). The book says that he was the designer of the visual programming interface for Visual Basic - but don't let that sway you, either; in About Face, he's perfectly willing to thump Microsoft for things he considers bogus (such as excessively-deep cascading menu on, for example, the Start bar; of course, excessively-deep cascading menus are hardly unique to Windows).
but since aqua is supposed to have some open-source parts
It is? The "core OS" (Darwin) may be open source (or will be open source if they release a Darwin that's the same as the core of MacOS X), but, as far as I know, none of the GUI stuff is going to be open source, either in whole or in part.
This way US could become communistic without anybody noticing it. Or did you notice it?
No, I didn't, actually. When did the state take over the means of production? (Not that it runs all the means of production in China these days, although there's still a lot of state-run industry.)
(Censorship can be practiced by states that aren't "communist", you know....)
Re:AIX vs Solaris vs Linux?
on
Free Solaris 8
·
· Score: 2
Solaris was originally BSD based starting in 1981-2.
Well, it was called "Sun UNIX 4.2BSD" or something such as that in the early days.
Sometime later, Sun incoporated System V APIs and renamed SunOS to Solaris.
Those were two separate actions. The SV APIs first started showing up in SunOS 3.2 (or "Sun UNIX 4.2BSD Release 3.2" or whatever), although in 3.0 the Bourne shell, make, and a few other utilities switched to the SV source base although they were tweaked for compatibility with the older V7/BSD versions), and 4.0 went further. The "Solaris" name didn't show up until SunOS 4.1.1 (OS component of Solaris 1.0) and SunOS 5.0 (OS component of Solaris 2.0).
The switch to the SVR4 code base wasn't until SunOS 5.0; a bunch of SV code went into the kernel and userland over time before that, but it wasn't a wholesale replacement of everything.
Re:What's up with Sun's attitude toward Linux?
on
Free Solaris 8
·
· Score: 2
But really morons like that shouldn't be allowed to do interviews because that's the kinda shit that has given so many people a bad impression of Sun.
Zander's the president and Chief Operating Office, so you can't exactly "not allow him to do interviews".
The attitude towards Linux shown by Sun executives does remind me of Scooter^H^H^H^H^H^H^HScott McNealy's attitude towards Motif, in the days of the OPEN LOOK/Motif Wars, mockery and all; it'll be interesting to see if they end up caving in the way they eventually did on Motif.
Sun Skipped versions when they ditched SunOS, and decided to go with one product, which ultimatly became Solaris 7.
The version skipping to which the original poster referred was the jump from Solaris 2.6 to Solaris 7.
When the AT&T/Sun deal started, there was no notion of "Solaris", unless it was being discussed by marketoons and other types and not told to those of us in engineering at Sun. I suspect the notion of "Solaris" may have stemmed, at least in part, from the fact that SunOS 1.0 (well, "Sun UNIX 4.2BSD Release 1.0", or whatever it was called back then) through SunOS 4.0[.x] had SunView (a non-networked window system in which the low-level drawing library with which GUI applications were linked would do ioctls to lock regions of the screen and would draw on them directly) as the bundled window system, and the OpenWindows X11/NeWS-based window system was a separate product. I think they decided to bundle them together, and came up with the name "Solaris" for SunOS + OpenWindows.
The very first SunOS 5.x release came out as part of Solaris 2.0, but SunOS 4.x releases had previously come out without being part of a "Solaris" release, so people were less likely to think of 4.1.x-based systems as being "Solaris 1" than to think of 5.x-based systems as "Solaris 2".
As for the jump to Solaris 7, presumably the idea was that (as others have noted) they weren't exactly going to do a Solaris 3.x any time soon, so they got rid of the leading "2." and just went with "7". The OS component of Solaris 7 is still SunOS 5.7, however.... The marketoons probably contributed to this as well, on the theory that the new version would make a bigger splash with a new and different number, blah blah blah blah blah.
Re:Who really benefits...
on
Free Solaris 8
·
· Score: 2
With all these free OSes flying around, we need common standards to make sure that the free exchange of data can continue. Things like XML and other open file formats are crucial.
Yes - in order to keep "Open Systems" open, you need common network protocols, common data formats, etc., and published ones so that anybody with sufficient resources can implement them.
The Linux ELF binary format is supported by both BeOS and Solaris via an emulation layer
Presumably you mean "both BeOS and Solaris can run Linux ELF binaries via an emulation layer"; the "Linux" part, rather than the "ELF" part, is what needs an emulation layer on Solaris - ELF was originally developed by AT&T for System V Release 4, and Solaris, as an SVR4-based system, had support for it before Linux did.
but that's only a start. It would be nice to have the same apps work across multiple OSes.
In what way does the ability to run Linux binaries on those OSes not "have the same apps work across multiple OSes"?
Re:What are the Differences?
on
Free Solaris 8
·
· Score: 2
Sun began when BSD (renamed SunOS by an infant Sun Microsystems)
Depends on when you think infancy ends; SunOS 4.0 was, as I remember, the first release where we called it "SunOS" rather than "Sun UNIX 4.2BSD" (mainly because we figured AT&T might go on one of their rampages against using UNIX for anything that wasn't vanilla unmodified AT&T System V Consider It Standard). It came out somewhere around 1987, at which point Sun was four years old - and had already gone through three major releases of the OS (1.0, 2.0, and 3.0).
4.0 was a heck of a lot more than just BSD; it included a completely new VM system (supported memory-mapped files, isolated the code that dealt with the MMU in a "HAT layer" (for "Hardware Address Translation")) and a dynamic-linking mechanism, built atop mmap(), from which the SVR4 mechanism was derived (the dynamic-linking mechanisms in Linux and {Free,Net,Open}BSD are based on the Sun/SVR4 mechanism). It also included a number of System V-isms (in the kernel as well as userland), and a STREAMS-based tty subsystem.
SVR4 was the result of a deal between AT&T and Sun; the theory was, at the time, that
Sun had to have a UNIX that was Genuine System V in order to break into the business world (yes, there was a Sun manager who claimed exactly that, in a meeting I was in; when I asked whether HP would replace the kernel in HP-UX - which I think was BSD-derived, although it had been made SV-compatible and given a largely SV userland - with System V Consider It Standard, he assured me that they were going to do that, although an HP person - admittedly, an engineer, so maybe he was too deep in the trenches to know what the generals were thinking - said he knew nothing of any such plans, and, well, HP was, in any case, one of the founders of the OSF - so much for going completely with SV);
Sun plus AT&T could join together and make SPARC+SVR4 the replacement for x86+DOS/Windows (AT&T was going to make SPARC-based machines, but they never got to the product stage)
(I remember Bill Joy stating, at a Sun OS group beer bust, something about how having multiple hardware platforms wasn't necessarily a good idea, and maybe it was time to settle on one platform, by which I rather suspect he meant SPARC. I think my response was something on the order of "the one platform may not end up being yours".)
The intent was to merge the features of SunOS 4.x (both the BSD features not already in System V, and the Sun features such as the new VM system and the dynamic linking mechanism) with System V to produce the One True UNIX. (There were also plans to do, as I remember, an exotic object-oriented blah blah blah operating system as The One True UNIX: The Next Generation, but those plans came to naught.)
Well, shall we say, much of the rest of the UNIX world wasn't exactly delighted by this, hence the OSF, which was going to do their own UNIX (OSF/1, eventually adopted as a mainstream UNIX by the following main members of the OSF: Digital Equipment Corporation, Digital Equipment Corporation, Digital Equipment Corporation, and, err, umm, Digital Equipment Corporation, although I think Intel used a version of OSF/1 in one of their Paragon i860-based supercomputers).
It might be interesting to make a list of the goals of the AT&T/Sun deal, and of the OSF, that either never saw the light of day, or eventually failed (for whatever reason), e.g. OPEN LOOK, OSF/1 as the UNIX for all the OSF members, World Domination By SPARC/SVR4, etc..
For example, the streams interface is, in some ways, superior to the way Linux kernel modules work.
You're comparing apples and frying pans here, in a sense. STREAMS is orthogonal to loadable kernel modules - you can have an OS without LKMs that supports STREAMS (SVR3, SunOS 4.0[.x], older SVR4s), you can have an OS with LKMs that supports STREAMS (SunOS 4.1[.x], SunOS 5.x, probably later versions of SVR4 - and, if you include the Linux STREAMS stuff that I think exists, Linux), and you can have OSes with or without LKMs that don't support STREAMS.
LKMs are a mechanism for adding code to the kernel, and removing code from the kernel, at run time; STREAMS is a mechanism for gluing together modules that process sequential streams of data (e.g. serial ports, networks, etc.). STREAMS modules can be LKMs (some if not all are LKMs in Solaris).
The idea of STREAMS (and of Dennis Ritchie's original version (well, that paper is actually on additional stuff in Ninth Edition UNIX, but it briefly describes the original streams stuff in the Eighth Edition), which inspired the System V version is interesting; the implementations have, shall we say, had their problems (I have the impression that STREAMS buffer allocators can be slow - that may have caused some of the problems with the STREAMS based tty subsystem I did for SunOS 4.0 - and that getting STREAMS to work well on an MP system took rather a lot of work, and several Solaris releases, on Sun's part).
I use Solaris at work, and I can honestly say that it occasionally makes me want to look into W2K (then the head trauma wears off).
I primarily use Solaris at work, with some Digital UNIX and some Linux, and I can honestly say that
it's a UNIX, like the other OSes I mention, and like the FreeBSD that's the main OS I run at home;
it occasionally annoys me, but I could probably say that about just about every OS I use and have ever used - I think you pretty much have to pick the annoyances that annoy you the least (or, as I like to put it, "all software sucks - you just have to pick the software that sucks least in the areas you care about the most").
Re:AIX vs Solaris vs Linux?
on
Free Solaris 8
·
· Score: 2
AIX sucked. It just flat out it sucked. It was a result of AT&T and Sun hopping in bed together and IBM/DEC/HP had to do something.
The RS/6000 version of AIX antedated the AT&T/Sun deal; it wasn't a consequence of that deal. I have the impression that OSF/1 picked up a bunch of (userland?) things from AIX, OSF/1 being the "something" that the OSF did, although only Digital, of the three OSF heavies you mention, adopted it - IBM stuck with AIX and HP stuck with HP-UX.
I don't know the full parentage of RS/6000 AIX; I think the first AIX (IBM's used the name for several different UNIXes, including one for their mainframes and one for PC's and one for the RT PC) may have been a PC UNIX done in part by Interactive Systems.
Interactive did a UNIX - for IBM, as I remember - called "IN/ix", or something such as that, for PCs, and when I say "PCs" I mean "desktop boxes with Intel 8088 processors in them (yes, that meant that an application could, if it tried, stomp on anything in memory).
I think they were then involved of the development of a fancier PC UNIX, called the Advanced Interactive eXecutive or something lame such as that, whence "AIX"; I think at least some AIXisms may have come from stuff Interactive did prior to that in other UNIXes they'd done.
...In their defense, they may actually have a use for cubane.com.
...but not necessarily one related to cubane, unless they're trying to imply that their software has truly explosive power - the domain is taken by "Cubane Software" (but they don't have a Web site at www.cubane.com yet).
(actually, I understand that AS/400 machine code is abstracted from the object code of programs, though probably not in quite the same way as how Transmeta did things
Correct. Compilers for the AS/400 (and its System/38 predecessor) for the languages in which applications are written generate code for a virtual machine with a very CISCy instruction set; low-level OS code translates that to the native instruction set. (That long antedates Transmeta; as indicated, it dates back to the System/38, which I think came out in the late '70's; IBM needed no technology from Transmeta to do that - binary-to-binary translation is hardly a Transmeta invention.)
It isn't done in exactly the same fashion, in that, on S/38's and AS/400's, the low-level OS code is written in languages that compile (or, for some code, assemble) into the native machine's instruction set, unlike Crusoe, where the only native code that's run is the translation software and the output of the translation software. Also, I don't think the translation on AS/400 is done as dynamically; I think programs are translated in their entirety the first time they're run, and the executable code for the entire program is kept around.
It seems that what Transmeta has done is to take the ideas developed for JIT compilers and apply them all to hardware.
"Apply them all to hardware" in what sense? The binary-to-binary translators for Crusoe chips are software; they just happen to be running on hardware that offers some assistance, but the translation itself isn't done by hardware (and happens at a layer below even the lowest-level OS code; as far as the OS is concerned, all the way down to the lowest level, the chip looks like an x86).
wouldn't they have to liscence the instruction set from apple?
Only if Apple (who didn't invent the PowerPC instruction set; it's a derivative of the IBM POWER instruction set) have some form of intellectual-property rights for the instruction set.
If there are any such rights owned by Somerset, Apple might also have some say in licensing it.
and even if they did give TM the specs so TM could write a code morphing layer to run PPC apps
"The specs", in the sense of the instruction set specifications for PowerPC, are publicly available, although if the chip+software is intended to look like a particular PowerPC chip (I think the MMUs may differ, e.g. may have software TLB reload on some processors and hardware TLB reload on others), they'd need that spec as well (I think the specs for various PowerPC chips are also publicly available).
also ars said the northbridge and the SD-DRAM (that right?) moduals were all intergrated on die so wouldn't that mean you need to change all of that stuff if you wanted to run a different arcitecture. after all PPC doesn't run on x86 core logic sets
If somebody wanted to clone not only some PowerPC CPU but a support chip set for it, so that they could run OSes such as MacOS unmodified, that stuff might have to be changed...
...but that's just cloning a Mac, which Apple isn't allowing even if you use existing PowerPC chips.
Of course, there is the possibility that Apple would want to use a Transmeta chip in a Powerbook, say, in which case the Apple licensing issues go away.
Apple are unlikely to be the ones to block such a Code Morphing(TM)(R)(LSMFT) layer; they don't, as far as I know, have a problem with people building non-Mac-compatible PowerPC machines, and they already have, as far as I know, the tools to block people from building Mac clones.
What would "a Crusoe version" of a platform be? Something built to run on a particular Crusoe chip (the two chips Transmeta have mentioned apparently do not have the same instruction set)? Or something built for some instruction set implemented atop various Crusoe chips (with different translators)?
Low power is nice, but the G4 does a gigaflop on 4 watts.
...but doesn't run Windows. If the market for low-power machines that run Windows (or other OSes not available for mobile machines with other types of processors) is sufficiently large, and if other x86 processor vendors don't get (as others have said) "good enough" power consumption, and if a lower-power CPU makes enough of a difference if the other components have the same power consumption no matter what processor is used, then they might have a chance. Time will tell.
As for the ability to run multiple instruction sets on the same machine, that may be of interest, at least for some OSes, only if you can run in a "virtual machine" environment, so you can run Windows and MacOS on the same machine, unless Transmeta relase to the vendors of one or the other of those OSes enough information to let them use the instruction-set switching directly and those OS vendors are willing to modify their OS to be able to run applications for other processors/OSes without just running the entire other OS inside a virtual machine.
Slashdot Mirror
The current "egcs version", for what it's worth, is called GCC 2.95.2. Does it say in the 2.95.2 distribution that 2.95.2 is considered experimental? This announcement for GCC 2.95 says:
Assuming the next major release is even called 3.0; this entry in the GCC FAQ says:Just out of curiosity, would SANE be sufficient to handle your scanner under FreeBSD (or any other flavor of UNIX, including Linux, free or not), or does SANE have no driver for it or are there also Windows applications you need?
(There's also WINE, for some Windows applications, although I think they may still warn that it's alpha code and not everything will necessarily work.
System {III,V} didn't exist when they did the first BSD; the first Berkeley Software Distribution was a collection of software to put atop the Sixth Edition (and possibly also the Seventh Edition) of the UNIX from Bell Labs Research. 3BSD and 4BSD were based on the 32V UNIX from Research, which was essentially a Seventh Edition port to the VAX; the Berkeley folk added demand paging (and other stuff, such as job control, and a TTY driver more pleasant for the user, and ex and vi, and curses, and so on), and, in 4.2BSD, added the BSD file system (file names > 14 characters, symlinks, bigger block size, different allocation policies) and their TCP/IP stack (although that was far from the first TCP/IP stack for UNIX).
That's why BSD looks less System V-ish than most other flavors of UNIX these days, including most Linux distributions (although I have the impression some distributions - Slackware? - might have a BSD-ish rather than an SV-ish init), although, over time, BSD has grown to look more SV-ish (Paul Vixie's cron is SV-flavored rather than the V7-flavored cron that BSD used to have, and various other system calls, other API routines, commands, etc. have flowed into BSD), just as SV has grown more BSDish (symlinks, BSD-style socket calls standard, and various other system calls, other API routines, commands, etc. have flowed into SVR4).
GTK+ apps also tend to use Ctrl-{X,C,V}, bless their soul (GTK+ itself uses them in its widgets).
The rationale for Netscape's choice may have been some noise about supporting Emacs keybindings, but it drives me nuts; I'll have to see if I can bludgeon it into going with ^X/^C/^V by tweaking my .Xdefaults file.
Then again, it also irritates me that Quicken 2000 appears not to use ^X/^C/^V either - and that's not an X app, it's a Windows app. At least the other Windows apps that I've used are better behaved than that.
...which isn't helped by Qt's apparent insistence on using the X primary selection, rather than the X clipboard selection, as its clipboard.
At least middle-mouse-button paste-current-selection tends to work most places, at least if you aren't trying to replace a selected chunk of text with another chunk of text (as doing the latter means you have to select something other than that which you're trying to copy...).
Should Slashdot's motto be changed from "News for Nerds. Stuff that matters." to "YHBT. YHL. HAND."?
Yes, "optimized for" doesn't necessarily imply "only runs on"; "optimized for" might just mean "instructions scheduled for", "instructions that run fast on used and instructions that don't run fast on not used", etc.; it'd be "only runs on" if it used instructions available only on the processor family in question, e.g. the conditional moves on P6 processors.
Besides, that should perhaps be "worked for"; he works for Cooper Interaction Design (although, as the name of the company suggests, "works for" probably understates the case :-)). The book says that he was the designer of the visual programming interface for Visual Basic - but don't let that sway you, either; in About Face, he's perfectly willing to thump Microsoft for things he considers bogus (such as excessively-deep cascading menu on, for example, the Start bar; of course, excessively-deep cascading menus are hardly unique to Windows).
It is? The "core OS" (Darwin) may be open source (or will be open source if they release a Darwin that's the same as the core of MacOS X), but, as far as I know, none of the GUI stuff is going to be open source, either in whole or in part.
No, I didn't, actually. When did the state take over the means of production? (Not that it runs all the means of production in China these days, although there's still a lot of state-run industry.)
(Censorship can be practiced by states that aren't "communist", you know....)
I think that's a common trick - put competitor's names in the meta tags.
Sorry about that; not intended to be posted to this thread. Please moderate it and this reply to -1, Offtopic.
Don't Ever Antagonize The Horn.
Well, it was called "Sun UNIX 4.2BSD" or something such as that in the early days.
Those were two separate actions. The SV APIs first started showing up in SunOS 3.2 (or "Sun UNIX 4.2BSD Release 3.2" or whatever), although in 3.0 the Bourne shell, make, and a few other utilities switched to the SV source base although they were tweaked for compatibility with the older V7/BSD versions), and 4.0 went further. The "Solaris" name didn't show up until SunOS 4.1.1 (OS component of Solaris 1.0) and SunOS 5.0 (OS component of Solaris 2.0).
The switch to the SVR4 code base wasn't until SunOS 5.0; a bunch of SV code went into the kernel and userland over time before that, but it wasn't a wholesale replacement of everything.
Zander's the president and Chief Operating Office, so you can't exactly "not allow him to do interviews".
The attitude towards Linux shown by Sun executives does remind me of Scooter^H^H^H^H^H^H^HScott McNealy's attitude towards Motif, in the days of the OPEN LOOK/Motif Wars, mockery and all; it'll be interesting to see if they end up caving in the way they eventually did on Motif.
The version skipping to which the original poster referred was the jump from Solaris 2.6 to Solaris 7.
When the AT&T/Sun deal started, there was no notion of "Solaris", unless it was being discussed by marketoons and other types and not told to those of us in engineering at Sun. I suspect the notion of "Solaris" may have stemmed, at least in part, from the fact that SunOS 1.0 (well, "Sun UNIX 4.2BSD Release 1.0", or whatever it was called back then) through SunOS 4.0[.x] had SunView (a non-networked window system in which the low-level drawing library with which GUI applications were linked would do ioctls to lock regions of the screen and would draw on them directly) as the bundled window system, and the OpenWindows X11/NeWS-based window system was a separate product. I think they decided to bundle them together, and came up with the name "Solaris" for SunOS + OpenWindows.
The very first SunOS 5.x release came out as part of Solaris 2.0, but SunOS 4.x releases had previously come out without being part of a "Solaris" release, so people were less likely to think of 4.1.x-based systems as being "Solaris 1" than to think of 5.x-based systems as "Solaris 2".
As for the jump to Solaris 7, presumably the idea was that (as others have noted) they weren't exactly going to do a Solaris 3.x any time soon, so they got rid of the leading "2." and just went with "7". The OS component of Solaris 7 is still SunOS 5.7, however.... The marketoons probably contributed to this as well, on the theory that the new version would make a bigger splash with a new and different number, blah blah blah blah blah.
Yes - in order to keep "Open Systems" open, you need common network protocols, common data formats, etc., and published ones so that anybody with sufficient resources can implement them.
Presumably you mean "both BeOS and Solaris can run Linux ELF binaries via an emulation layer"; the "Linux" part, rather than the "ELF" part, is what needs an emulation layer on Solaris - ELF was originally developed by AT&T for System V Release 4, and Solaris, as an SVR4-based system, had support for it before Linux did.
In what way does the ability to run Linux binaries on those OSes not "have the same apps work across multiple OSes"?
Depends on when you think infancy ends; SunOS 4.0 was, as I remember, the first release where we called it "SunOS" rather than "Sun UNIX 4.2BSD" (mainly because we figured AT&T might go on one of their rampages against using UNIX for anything that wasn't vanilla unmodified AT&T System V Consider It Standard). It came out somewhere around 1987, at which point Sun was four years old - and had already gone through three major releases of the OS (1.0, 2.0, and 3.0).
4.0 was a heck of a lot more than just BSD; it included a completely new VM system (supported memory-mapped files, isolated the code that dealt with the MMU in a "HAT layer" (for "Hardware Address Translation")) and a dynamic-linking mechanism, built atop mmap(), from which the SVR4 mechanism was derived (the dynamic-linking mechanisms in Linux and {Free,Net,Open}BSD are based on the Sun/SVR4 mechanism). It also included a number of System V-isms (in the kernel as well as userland), and a STREAMS-based tty subsystem.
SVR4 was the result of a deal between AT&T and Sun; the theory was, at the time, that
(I remember Bill Joy stating, at a Sun OS group beer bust, something about how having multiple hardware platforms wasn't necessarily a good idea, and maybe it was time to settle on one platform, by which I rather suspect he meant SPARC. I think my response was something on the order of "the one platform may not end up being yours".)
The intent was to merge the features of SunOS 4.x (both the BSD features not already in System V, and the Sun features such as the new VM system and the dynamic linking mechanism) with System V to produce the One True UNIX. (There were also plans to do, as I remember, an exotic object-oriented blah blah blah operating system as The One True UNIX: The Next Generation, but those plans came to naught.)
Well, shall we say, much of the rest of the UNIX world wasn't exactly delighted by this, hence the OSF, which was going to do their own UNIX (OSF/1, eventually adopted as a mainstream UNIX by the following main members of the OSF: Digital Equipment Corporation, Digital Equipment Corporation, Digital Equipment Corporation, and, err, umm, Digital Equipment Corporation, although I think Intel used a version of OSF/1 in one of their Paragon i860-based supercomputers).
It might be interesting to make a list of the goals of the AT&T/Sun deal, and of the OSF, that either never saw the light of day, or eventually failed (for whatever reason), e.g. OPEN LOOK, OSF/1 as the UNIX for all the OSF members, World Domination By SPARC/SVR4, etc..
You're comparing apples and frying pans here, in a sense. STREAMS is orthogonal to loadable kernel modules - you can have an OS without LKMs that supports STREAMS (SVR3, SunOS 4.0[.x], older SVR4s), you can have an OS with LKMs that supports STREAMS (SunOS 4.1[.x], SunOS 5.x, probably later versions of SVR4 - and, if you include the Linux STREAMS stuff that I think exists, Linux), and you can have OSes with or without LKMs that don't support STREAMS.
LKMs are a mechanism for adding code to the kernel, and removing code from the kernel, at run time; STREAMS is a mechanism for gluing together modules that process sequential streams of data (e.g. serial ports, networks, etc.). STREAMS modules can be LKMs (some if not all are LKMs in Solaris).
The idea of STREAMS (and of Dennis Ritchie's original version (well, that paper is actually on additional stuff in Ninth Edition UNIX, but it briefly describes the original streams stuff in the Eighth Edition), which inspired the System V version is interesting; the implementations have, shall we say, had their problems (I have the impression that STREAMS buffer allocators can be slow - that may have caused some of the problems with the STREAMS based tty subsystem I did for SunOS 4.0 - and that getting STREAMS to work well on an MP system took rather a lot of work, and several Solaris releases, on Sun's part).
I primarily use Solaris at work, with some Digital UNIX and some Linux, and I can honestly say that
The RS/6000 version of AIX antedated the AT&T/Sun deal; it wasn't a consequence of that deal. I have the impression that OSF/1 picked up a bunch of (userland?) things from AIX, OSF/1 being the "something" that the OSF did, although only Digital, of the three OSF heavies you mention, adopted it - IBM stuck with AIX and HP stuck with HP-UX.
I don't know the full parentage of RS/6000 AIX; I think the first AIX (IBM's used the name for several different UNIXes, including one for their mainframes and one for PC's and one for the RT PC) may have been a PC UNIX done in part by Interactive Systems.
Interactive did a UNIX - for IBM, as I remember - called "IN/ix", or something such as that, for PCs, and when I say "PCs" I mean "desktop boxes with Intel 8088 processors in them (yes, that meant that an application could, if it tried, stomp on anything in memory).
I think they were then involved of the development of a fancier PC UNIX, called the Advanced Interactive eXecutive or something lame such as that, whence "AIX"; I think at least some AIXisms may have come from stuff Interactive did prior to that in other UNIXes they'd done.
Well, more like 7 years ago; the first FreeBSD came out in late 1993.
The AT&T lawsuit might have contributed to that, at least in part.
...but not necessarily one related to cubane, unless they're trying to imply that their software has truly explosive power - the domain is taken by "Cubane Software" (but they don't have a Web site at www.cubane.com yet).
Correct. Compilers for the AS/400 (and its System/38 predecessor) for the languages in which applications are written generate code for a virtual machine with a very CISCy instruction set; low-level OS code translates that to the native instruction set. (That long antedates Transmeta; as indicated, it dates back to the System/38, which I think came out in the late '70's; IBM needed no technology from Transmeta to do that - binary-to-binary translation is hardly a Transmeta invention.)
It isn't done in exactly the same fashion, in that, on S/38's and AS/400's, the low-level OS code is written in languages that compile (or, for some code, assemble) into the native machine's instruction set, unlike Crusoe, where the only native code that's run is the translation software and the output of the translation software. Also, I don't think the translation on AS/400 is done as dynamically; I think programs are translated in their entirety the first time they're run, and the executable code for the entire program is kept around.
"Apply them all to hardware" in what sense? The binary-to-binary translators for Crusoe chips are software; they just happen to be running on hardware that offers some assistance, but the translation itself isn't done by hardware (and happens at a layer below even the lowest-level OS code; as far as the OS is concerned, all the way down to the lowest level, the chip looks like an x86).
Only if Apple (who didn't invent the PowerPC instruction set; it's a derivative of the IBM POWER instruction set) have some form of intellectual-property rights for the instruction set.
If there are any such rights owned by Somerset, Apple might also have some say in licensing it.
"The specs", in the sense of the instruction set specifications for PowerPC, are publicly available, although if the chip+software is intended to look like a particular PowerPC chip (I think the MMUs may differ, e.g. may have software TLB reload on some processors and hardware TLB reload on others), they'd need that spec as well (I think the specs for various PowerPC chips are also publicly available).
If somebody wanted to clone not only some PowerPC CPU but a support chip set for it, so that they could run OSes such as MacOS unmodified, that stuff might have to be changed...
...but that's just cloning a Mac, which Apple isn't allowing even if you use existing PowerPC chips.
Of course, there is the possibility that Apple would want to use a Transmeta chip in a Powerbook, say, in which case the Apple licensing issues go away.
Apple are unlikely to be the ones to block such a Code Morphing(TM)(R)(LSMFT) layer; they don't, as far as I know, have a problem with people building non-Mac-compatible PowerPC machines, and they already have, as far as I know, the tools to block people from building Mac clones.
What would "a Crusoe version" of a platform be? Something built to run on a particular Crusoe chip (the two chips Transmeta have mentioned apparently do not have the same instruction set)? Or something built for some instruction set implemented atop various Crusoe chips (with different translators)?
...but doesn't run Windows. If the market for low-power machines that run Windows (or other OSes not available for mobile machines with other types of processors) is sufficiently large, and if other x86 processor vendors don't get (as others have said) "good enough" power consumption, and if a lower-power CPU makes enough of a difference if the other components have the same power consumption no matter what processor is used, then they might have a chance. Time will tell.
As for the ability to run multiple instruction sets on the same machine, that may be of interest, at least for some OSes, only if you can run in a "virtual machine" environment, so you can run Windows and MacOS on the same machine, unless Transmeta relase to the vendors of one or the other of those OSes enough information to let them use the instruction-set switching directly and those OS vendors are willing to modify their OS to be able to run applications for other processors/OSes without just running the entire other OS inside a virtual machine.
Umm, I'm not sure why it's an "interesting rumor" that BeOS is running on systems built with a chip that, as Transmeta says, is "Fully x86 compatible" and "is compatible with the complete range of x86-based operating systems", given that BeOS comes in a version that's "x86-based".