In comp.os.linux.advocacy, Roy Schestowitz
<newsgroups@xxxxxxxxxxxxxxx>
wrote
on Mon, 22 Jan 2007 17:03:01 +0000
<1698283.hOLQWRn6rR@xxxxxxxxxxxxxxx>:
> Seven ways Solaris can beat Linux
>
> ,----[ Quote ]
> | 1. Raise Solaris' profile.
The article mentions using "high-profile" customers which
would be using Solaris in mission-critical applications
(and willing to discuss it). A Super Bowl ad is an
interesting idea, though I'm not sure how effective such
ads really are.
> | 2. License OpenSolaris under the Gnu GPL (General Public License).
That would be nice. :-)
> | 3. Ship a complete, gorgeous desktop system.
I dunno about "gorgeous" but I think Sun was shipping complete desktops
at one point.
> | 4. Come up with a killer app.
And that would be ... ?
> | 5. Offer hardware support that's second to none.
OK.
> | 6. Become the OS of choice for developers.
A goal, certainly. I'd like to see more GUI development
capability in Eclipse -- Netbeans and JBuilder had the
ability to preview and edit properties in forms, while
generating code -- and the examples for the plugins are
problematic.
> | 7. Virtualization all the way.
Gaaah. People should realize that they're *already*
running on a virtual machine, and have been since the 186
timeframe (though the 486 popularized the concept with the
"V86"). In fact, they've been doing so since *before*
the 186, since systems such as VM/CMS (IBM) and VMS (DEC/VAX)
have had virtualization capability since the early 80's.
But let's just look at the 80x86 platform, shall we?
Basically, in order to issue a system call, one has to run
an illegal instruction -- INT. That causes a (I think)
call trap, which the kernel interprets.
Sounds damned virtual to me. :-) Of course most
application developers won't go to quite that level,
preferring the glibc open(), the Portable IO's fopen(),
the Standard Template Libraries std::[io]fstream, or Java's
java.io.File[Input/Output]Stream to the INT 0x80 interface
that Linux/x86 actually uses -- all making applications
more portable. (I don't know what Windows uses although
Andrew Schullman mentions INT 21H, a holdover from DOS,
among other things.)
The article does clarify this issue by mentioning VMWare.
However, I also remember solutions such as ibcs2 (I
don't remember whether that's FreeBSD/x86 executables on
Linux/x86 or vice versa).
Ideally, a Solaris system would be able to "run" any of
the following:
- Linux-based executables for the x86
- Linux-based executables for the SPARC
- Solaris-based executables for the native system, either x86 or SPARC
depending on hardware
- FreeBSD-based executables for x86 and SPARC
- Intel PE executables with Microsoft Windows [XP?] extensions,
using WinE or equivalent
- Java .JAR files with Main-Class: specification
Linux can handle most of these with various combinations of
WinE, Java, and kernel tweaking.
> `----
>
> http://www.linuxworld.com.au/index.php/id;937418947;fp;2;fpid;3
>
> The author has a history of bashing Linux.
Too bad for him. :-)
>
> The following news is relevant here. It's pretty much official now.
>
> Major Intel, Sun deal to be announced Monday
>
> ,----[ Quote ]
> | The deal will not cut out AMD from the equation, but it looks as
> | if the smaller chip company will have to do more if it wants to
> | keep Sun on board.
> `----
>
> http://www.theinquirer.net/default.aspx?article=37089
Yes, that made the radio news here, too. An interesting issue
considering that Sun is already offering Opteron-based hardware.
--
#191, ewill3@xxxxxxxxxxxxx
Useless C++ Programming Idea #104392:
for(int i = 0; i < 1000000; i++) sleep(0);
--
Posted via a free Usenet account from http://www.teranews.com
|
|
