Solaris 10 [LWN.net]

November 17, 2004

This article was contributed by Joe 'Zonker' Brockmeier.

As the release date for Solaris 10 nears, Sun Microsystems has been powering up the hype machine accordingly, and trying to convince the world that Solaris 10 is the best OS ever. According to Sun, Solaris 10 will offer more than 600 new, "breakthrough" features. That's a few too many for this article, but we'll take a look at some of the most notable features that are slated for inclusion in Solaris 10.

One interesting feature is Solaris Dynamic Tracing (DTrace). DTrace is a system for troubleshooting problems in real time, by allowing admins and developers to observe and tune system behavior.

Another feature that Sun is touting is Solaris Containers. Containers are essentially virtual machines, which allow an admin to create "private execution environments" on a machine, to isolate applications from one another and essentially create multiple hosts on a single server. This is, of course, nothing new to Linux users who have already discovered User-Mode Linux or any of the other virtualization solutions available for Linux.

Solaris 10 also comes with a new file system, ZFS. This is a 128-bit file system that offers far greater capacity than the current UFS, and 64-bit checksums for data stored on the filesystem. ZFS works with "virtual storage pools," and is supposed to greatly reduce the difficulty of administering file systems. According to Sun's website:

For example, with Solaris ZFS, to add mirrored file systems for three users and then add more disks, the number of tasks is reduced from 28 to 5. And the time taken to perform this function has been reduced from 40 minutes to 10 seconds, so administrators can spend more time solving business problems, rather than managing storage.

The TCP/IP stack gets special attention in Solaris 10. Sun has rewritten its networking stack, and claims that delivers a 50-percent or better speed boost for "many networked applications." Solaris 10 also includes built-in kernel support for the Stream Control Transmission Protocol (SCTP) and Session Initiation Protocol (SIP) in an effort to make Solaris 10 attractive for VoIP deployments.

Despite the slew of new features, Sun has fallen into an unenviable position with Solaris: Having to go to customers with a emulation technology to run their existing programs. When Linux was the underdog, much was made of the ability to run Solaris and other *nix binaries on Linux, as a way to allow companies to move their existing applications to Linux. With Solaris 10, Sun is promising a Linux Application Environment (LAE) to run Linux binaries on Solaris 10 on x86 systems.

Pricing for Solaris 10 has changed as well. Sun is, literally, giving it away. Sun is giving a "right-to-use" (RTU) license and security updates for Solaris 10 at no charge. Customers who want to utilize support or have access to all Solaris 10 updates and fixes start at $120 per year for a 1-4 CPU machine.

The company is also making much of binary compatibility with Solaris 10 -- promising customers that older Solaris applications will be able to run unchanged on Solaris 10.

Perhaps the most interesting feature for Solaris 10 is the licensing, if we ever find out what it is. According to Sun's executives, Solaris 10 will be open source. However, the company has not yet announced a license, whether the license will be OSI-compliant or exactly how much of Solaris 10 will be under this open source license. Further, assuming that the license is open enough to encourage contribution, Sun hasn't set out any information about accepting contributions from the community.

A more ominous possibility exists: Sun could release its code under a license which is not only non-free, but which creates problems for any free software developers who look at that code. If Sun's fortunes continue to decline, there is a definite possibility that the company could look to litigation for its salvation. This possibility should be kept in mind by anybody who contemplates going anywhere near the Solaris code.

Obviously, Sun is trying to regain some of the ground that it has lost with Linux. It seems unlikely, at least to this writer, that Sun will make much headway in regaining lost customers with Solaris 10. While Solaris 10 offers some undeniably useful and interesting features, it's fairly obvious that most organizations do not choose operating systems on features alone.

Sun lacks the momentum that Linux has gained over the past few years. Companies that have already invested time and money into migrating to Linux are less likely to spend additional time and money evaluating Solaris 10 if Linux is meeting their needs. Companies that are already utilizing Linux are unlikely to even bother evaluating Solaris 10 unless Linux does not meet their needs.

Also, Sun's LAE won't be available in the first release of Solaris 10, meaning that organizations that are willing to consider migrating from Linux to Solaris will have to hold off until Sun releases LAE in an update to Solaris 10. This puts Sun even farther in the hole with regards to losing customers to Linux.

If the Solaris 10 license is GPL-compatible, many of Solaris 10's interesting features will no doubt find their way into Linux. It seems unlikely that Sun would choose that path. On the other hand, if Sun chooses a less friendly open source license, it will have a tough time creating a community that will drive Solaris development or adoption in the same way that the GPL has driven Linux. Either way, Sun seems set to lose with its open source ploy.

Solaris 10 looks to be a fine operating system, but it may very well be too little and too late to help Sun regain its market share.

(Log in to post comments)

Inaccuracy and further comment

Posted Nov 18, 2004 4:57 UTC (Thu) by paulj (subscriber, #341) [Link]

Another feature that Sun is touting is Solaris Containers. ... This is, of course, nothing new to Linux users who have already discovered User-Mode Linux or any of the other virtualization solutions available for Linux.

Solaris Containers are not comparable to UML. From a technical standpoint, UML has the overhead of running a full kernel in userspace (and, typically, using PTRACE to trap the processes it runs, which can slow). Solaris Containers is a single-kernel, very low overhead solution, the Linux Vserver project is probably closer in concept.

From an administrative POV, Solaris containers are quite integrated with the rest of Solaris. When you boot Solaris, your zones boot automatically, if you upgrade the 'global' zone, you can if you wish have zones automatically upgraded too. The level of integration with the system as a whole is possibly the most immediately noticeable advantage to Solaris containers.

The company is also making much of binary compatibility with Solaris 10 -- promising customers that older Solaris applications will be able to run unchanged on Solaris 10.

AIUI, Sun has always made much of binary compatibility for Solaris userspace. This hasnt changed for Solaris 10, AIUI.

According to Sun's executives, Solaris 10 will be open source. However, the company has not yet announced a license, whether the license will be OSI-compliant

I believe top Sun executives, and others, have already on more than one occassion that Solaris will be released under an OSI compliant licence, and that they are talking to OSI about this.

This paragraph is utter FUD, sorry. Firstly, no one should ever look at code without being aware of the licencing implications, regardless of what that code is. Secondly, as above, the publically stated intent is that Solaris will be released under an OSI-approved licence.

Many of Solaris' interesting features are already in Linux. From a kernel POV, things like the slab cache were described by Sun engineers in USENIX papers many many years ago. Sun made RPC and NFS freely available specifications many many years ago. Sun are a supporting member of and active contributor to X.org (eg X input stuff most recently, that I can yhink of). From a system POV, if you run a Linux desktop you'll likely be using open-source applications which Sun contributed to the development of, or even made possible in the first place (GNOME, OpenOffice). etc.. And of course, Sun's engineering staff often are involved in and contribute to a variety of standards bodies.

Like it or not, Sun are an important contributor to the Unix ecosystem. "They wont embrace Linux, the evil b?$tards!!" or "They settled their lawsuit with M$, the b?$tards!!", imho are not a good reasons to not like them, even sillier reasons to spread FUD for. Competition and cross-polination is good, and its exactly what makes Unix (inc Linux) in its totality the healthy ecosystem it is today, and to that end Sun at least deserve some credit.

LWN is a high-quality read. Its sad to see it publish an article which, IMHO, is so devoid of the usual high-quality technical analysis and objective reporting which we've come to expect from LWN. The (scant) technical details given are in parts wrong, or at least show the author has done little technical research for this article, and the rest of the article is sprinkled with idle speculation if not outright FUD.

NB: I'm a (Linux and Free software loving) Sun employee, who absolutely does not speak for Sun in this post. Opinions are my own, and I held the above (general opinion at least) before ever joining Sun.

Inaccuracy and further comment

Posted Nov 18, 2004 9:13 UTC (Thu) by jhs (guest, #12429) [Link]

Agreed. This article seemed a little more guided by philosophical or emotional motives than technical motives.

> Sun lacks the momentum that Linux has gained

Sun still has an *enormous* global deployment much larger in scope and importance than Linux deployments. In almost every medium-to-large company in the world, Sun is there, to various degrees. The same cannot yet be said about Linux. Indeed, it is Sun, not Linux, that has the momentum.

The author probably meant that Linux-the-OS has much more potential than Solaris, which is at this point pretty apparent.

Inaccuracy and further comment

Posted Nov 18, 2004 23:14 UTC (Thu) by edgewood (subscriber, #1123) [Link]

In physics, momentum is the product of mass and velocity. So the installed base of Solaris, its "mass", is indeed crucial to the question of whether Solaris has more momentum. But just as crucial is its "velocity". How big is the Solaris installed base compared to last year? Probably about the same size. Compared to five years ago? It might have been bigger then, at the height of the dot.com boom.

Linux's installed base is indeed smaller, but it's bigger this year than it was last year, and huge compared to what it was five years ago. That "velocity" can give it the higher momentum, and I think it does.

Momentum

Posted Nov 19, 2004 19:23 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

You seem to be taking rate of growth as velocity. That ruins the analogy, because in physics, velocity isn't the rate at which the mass in increasing.

I don't see any way to break down OS momentum into analogies of mass and velocity.

But I don't think rate of growth is any part of an OS' momentum. Momentum is the tendency of a moving object to keep moving. An object with great momentum doesn't speed up or get larger. It just doesn't come to rest easily.

I see Solaris as having great momentum. Longtime users give an OS momentum. I can't tell how much momentum Linux has. New users are often easily switched to something else.

Momentum

Posted Nov 20, 2004 7:23 UTC (Sat) by hppnq (guest, #14462) [Link]

Now, black holes and OSes, there's an analogy. ;-)

Inaccuracy and further comment

Posted Nov 18, 2004 18:17 UTC (Thu) by larryr (guest, #4030) [Link]

While I could agree it is debatable whether Sun as a company is in a tenuous position, I think from a technical point of view Solaris is without question an outstanding achievement, and Solaris 10 is arguably the most advanced operating system for business/mission critical operations.

What I would hope to see in editorials on LWN is recognition and celebration of the technical excellence of Solaris as a whole and of its several features and aspects which are arguably better than in any comparable operating system.

Larry

Inaccuracy and further comment

Posted Nov 20, 2004 3:59 UTC (Sat) by paulj (subscriber, #341) [Link]

I dont think Sun is in a tenous position, it has a large customer base, a large and skilled engineering staff (NB: I'm obviously quite biased in saying that ;) ) and it has (from what I know of *public* Sun financial information) cash reserves. What Sun possibly does have to do is adapt to new market conditions (eg the commoditisation of core OS functionality by Linux and the rise of open source). Adapting to new conditions is something every company has to do to, and I think Sun can do it, I dont see why not.

As for Solaris 10 being the most advanced OS, or Solaris 10 versus Linux on a technical basis, well when i saw the article headline of "Solaris 10" i thought "great, now i'll get an informed, technical, objective, 3rd party view of Solaris 10 and how it stacks up" - I didnt get that, that's what disappoints me.

And btw, my job at Sun involves working on Free Software (least it has to date).

Inaccuracy and further comment

Posted Nov 20, 2004 7:30 UTC (Sat) by hppnq (guest, #14462) [Link]

Paul, you're on a Linux site, so any non-Linux OS review is here for a specific reason. Maybe you should read the article like that, to me it sounds like we've been reading different articles. Also, don't forget that you are probably much more informed than the average public, which might skew your perception.

Inaccuracy and further comment

Posted Nov 20, 2004 7:35 UTC (Sat) by hppnq (guest, #14462) [Link]

What I would hope to see is an objective review of Solaris' features, and I think we got that. What you want is here: all new and self healing.

Solaris 10

Posted Nov 18, 2004 8:51 UTC (Thu) by vmlinuz (guest, #24) [Link]

Since you ask so nicely :-)

Yes, Solaris df now has the -h switch.

No, Solaris tar does not have the z switch, but GNU tar is installed on every Solaris system - and has been for a while - by default. Unfortunately, it's hidden away in /usr/sfw/bin along with lots and lots of other goodies such as, say, mozilla...

Solaris 10

Posted Nov 19, 2004 0:36 UTC (Fri) by gallir (guest, #5735) [Link]

And, where is the kernel? I looked for it in /usr/sfw/boot/vmlinuz*
but couldn't find it. Perhaps is vmlinux instead?

GPL Solaris benefits Sun

Posted Nov 18, 2004 15:06 UTC (Thu) by cajal (subscriber, #4167) [Link]

"If Sun release Solaris under the GPL then many of the interesting features in Linux will find their
way into Solaris."

GPL Solaris benefits Sun

Posted Nov 18, 2004 18:29 UTC (Thu) by jonabbey (subscriber, #2736) [Link]

What features would those be? Solaris already does anything Linux can do. The only real benefit would be porting drivers for x86 hardware from Linux to Solaris, but Sun could already port drives from *BSD if they wanted. No small benefit, that. Linux is far and away better at x86 hardware support than anything but Windows.

GPL Solaris benefits Sun

Posted Nov 19, 2004 19:22 UTC (Fri) by erwbgy (subscriber, #4104) [Link]

Indeed. Sun's Java Desktop runs on Linux for a reason.

GPL Solaris benefits Sun

Posted Nov 19, 2004 0:53 UTC (Fri) by foo (guest, #1117) [Link]

Linux can run on dozens of platforms, while Solaris
only runs on two or three. This matters a lot here
in embedded-land.

Give Sun their due.

Posted Nov 20, 2004 7:45 UTC (Sat) by hppnq (guest, #14462) [Link]

The thing is, with Open Source you don't need trace toolkits as much as with proprietary systems. Lacking support in the Linux world often means: no one asked for it.

source availablility has nothing to do with tracing

Posted Nov 21, 2004 0:48 UTC (Sun) by cajal (subscriber, #4167) [Link]

That's just silly. DTrace (and tracing toolkits in general) having nothing to do with source availablity. They're used to debug and profile individual applications and even entire systems.

Consider these two questions which a sysadmin might be asked in a typical day:

* What processes are causing so much swapping?

* What processes are generating disk I/O?

Without tracing toolkits, these questions can be difficult, if not impossible to answer. With DTrace, each takes a 5-line script:

What processes are causing so much swapping


#!/usr/bin/dtrace -s

vminfo:::pgin

{

        @[pid, execname] = count();

}

This will give you a histogram of what processes are causing pageins.

What processes are generating disk I/O?


#!/usr/sbin/dtrace -s

io:::start

{

        @[execname, uid] = sum(args[0]->b_bcount);

}

That'll give you a histogram of disk I/O broken down by process name and uid.

Even if you had all the source to the OS, you couldn't answer these questions without an appropriate tool. DTrace is one such tool. It can, of course, do a lot more. For a nice overview, I highly suggest this blog entry by Bryan Cantrill, one of DTrace's developers.

source availablility has nothing to do with tracing

Posted Nov 22, 2004 21:14 UTC (Mon) by hppnq (guest, #14462) [Link]

I was replying to the "Linux appears behind" remark of the top poster, not soliciting for a Solaris marketing speech. You apparently didn't quite understand what I meant, so I'll try to make it clearer.

Of course source code inspection and the use of trace toolkits are not equivalent. At best they complement each other (see for instance the collaboration between Ingo Molnar and the people testing his -RT patches), but there are also classes of real world problems in which either one will prove to be completely useless. Trace toolkits do tend to look more like a hammer than a couple of C files, so some problems might develop an uncanny resemblance to a nail if you're not careful -- well, that's my opinion, YMMV.

The fact that the Linux kernel does not have the tracing capabilities that DTrace offers is attributable to a number of factors; one of them is undoubtedly the fact that inspection of code is both the ultimate and probably the most common thing to do in the Open Source world.

As for the marketing mumbo jumbo: from what I've seen, DTrace looks quite okay but nothing out of the ordinary. All examples of its use I have seen so far are trivial to do using other tools, but I imagine much more elaborated tracing a la AIX's trace facility is possible, so more power to you.

source availablility has nothing to do with tracing

Posted Nov 22, 2004 23:25 UTC (Mon) by cajal (subscriber, #4167) [Link]

I fail to see how two technical examples constitute a "marketing speech," and I think it's funny that you try to claim that I'm to blame since your entire post was two sentences.

I never claimed that tracing toolkits were the be-all and end-all of debugging. They're a very useful tool for a lot of things, but for other things a debugger is more appropriate. I don't think that Sun (or anyone else) is claiming that DTrace is the *only* tool you need for all computer problems. They are making a big deal about it, but their enthusiasm is justifiable - DTrace is an incredible tool, and they've spent years developing it.

I'm not sure what to make of your claim that "inspection of code is both the ultimate and probably the most common thing to do in the Open Source world." If you actually read my reply, instead of merely dismissing it as "marketing," you'd see that no amount of source code inspection would give you that answer. You dismiss DTrace as "nothing out of the ordinary" -- I diagree strongly. Have you read the Usenix paper on DTrace's design? Do you realize that it's dynamically inserting probe points into a live kernel, and doing so safely? It's data analysis tools are very powerful and easy to use. If you can write a shell or Perl script, you can use DTrace. It's a big step forward for sysadmins, developers and systems programmers. AIX trace is certainly useful, but very different from DTrace. AIX trace activates several static tracing primitives and generates huge output files. DTrace only actives the probes the user specifies and can filter data at the source, greatly reducing the need for post-processing. See this entry on Sun Forums where there some good back-and-forth about AIX trace -vs- DTrace. The Dynamic Tracing Guide is also very useful - it has lots of good examples of how to use DTrace.

source availablility has nothing to do with tracing

Posted Nov 23, 2004 0:41 UTC (Tue) by hppnq (guest, #14462) [Link]

I never claimed that tracing toolkits were the be-all and end-all of debugging.

And I never said you did.

I've had this kind of discussion with you before and I must say I hesitated for quite a while before adding my previous comment, since it seems like everytime I say something about Sun here you seem to develop an urge to drown me in Ten Interesting Things To Do With DTrace Or Whatever. And your continuous misinterpretation of my comments is not believable anymore.

This could have been a normal, technical discussion but you'll hopefully forgive me for not wanting to continue it.

source availablility has nothing to do with tracing

Posted Nov 23, 2004 3:08 UTC (Tue) by cajal (subscriber, #4167) [Link]

"I must say I hesitated for quite a while before adding my previous comment, since it seems like everytime I say something about Sun here you seem to develop an urge to drown me in Ten Interesting Things To Do With DTrace Or Whatever"

Rubbish. In this thread, you've been insuinating that open-source projects don't need tracing toolkits so much because developers can inspect the code:

"...that inspection of code is both the ultimate and probably the most common thing to do in the Open Source world."

What I'm trying to get across is that tracing toolkits in general, and DTrace in particular, are useful for things beyond debugging code. They've also useful to sysadmins trying to track down performance problems, which is why I listed the examples I did.

And, for the record, I included the source specifically to keep it technical and not a marketing speech.

source availablility has nothing to do with tracing

Posted Nov 23, 2004 4:03 UTC (Tue) by hppnq (guest, #14462) [Link]

Sigh.

Not only does it make little sense to accuse me of insinuating something with an almost literal quote of my own words, it really takes the edge off of your razor sharp logic.

*plonk*

source availablility has nothing to do with tracing

Posted Nov 23, 2004 4:10 UTC (Tue) by cajal (subscriber, #4167) [Link]

Do you actually read my replies, or just post attacks? Do you actually have anything to contribute to this thread, or do you just have to have the last word?

source availablility has nothing to do with tracing

Posted Nov 25, 2004 1:44 UTC (Thu) by roelofs (guest, #2599) [Link]

As a disinterested third party with no ties to either combatant (nor to Sun), I have to side with cajal here. His initial comment was to the point and technical: he provided two explicit examples of how a sysadmin could use DTrace to trivially discover two types of manifestly useful information. hppnq, on the other hand, characterized those examples as mere "marketing speech" (or "marketing mumbo jumbo") and claimed that they're "trivial to do using other tools" yet somehow failed to provide a single example of those other tools.

And speaking as a former sysadmin with some very minor kernel-hacking experience, I think I can safely say that inspection of code is not "the most common thing to do" for that category of user. Not only is knowledge of kernel internals fairly rare among sysadmins (at least in my experience, which I think is pretty typical), I've never yet met one who wasn't swamped with work. Five-line script vs. unknown hours poring over kernel source...hmmm. Tough call.

Anyway, consider this a gentle plea to get back to useful technical interchange rather than continued personal attacks. And thank you, cajal, for a pair of instructive examples that conveyed far more relevant info than any marketing spiel I've ever seen. (Not that I go out of my way to see a lot of marketing spiels...)

Greg

source availablility has nothing to do with tracing

Posted Nov 25, 2004 8:05 UTC (Thu) by hppnq (guest, #14462) [Link]

Greg, what I originally meant to say is very, very simple. On a proprietary system you have to resort to trace toolkits or debuggers to be able to look inside your software. With Open Source you don't. That would help explain why Linux does not have a trace toolkit.

tracing does not (necessarily) have anything to do with source availablility

Posted Nov 25, 2004 16:44 UTC (Thu) by josephrjustice (subscriber, #26250) [Link]

It's true that, on a proprietary ^H^H...^H closed source system (unless one is among the blessed elite), a person needs to resort to trace toolkits, debuggers, etc to be able to look inside the guts of software.

It's also true that, on an Open Source / Free(Libre) Software system, one does not _need_ to resort to trace toolkits, debuggers, etc. After all, it is (in theory) possible to look at the source code, in combination with FULL and COMPLETE knowledge of all information leading to the current state of a running process (which, note, depending on the issue being investigated could include needing to have knowledge of the exact runtime history of this process and other processes on the system, information about the layout of files on disk, knowledge of the specifications of the hardware, knowing about any compiler bugs, knowing about any hardware bugs (e.g. divergences from the hardware specification), knowledge of the phase of the moon (e.g. did a random cosmic ray cause a bit to flip in memory causing a run-time error), etc), and be able to deduce exactly how the problematic process got to be the way it is. You know, the old "Let the human pretend sie is a Von Neumann machine" thing.

However, just because this is _possible_ for open source systems does not mean it is _practical_, or that this is always what people _should_ do even if other options are available to them.

I don't use Solaris (other than as a person with a Unix shell account with an ISP that uses Solaris on its shell systems). I'm certainly not an avowed Sun Microsystems booster (tho, neither am I a dedicated detractor of them either). However, it does seem from this particular conversational thread, and other pages linked to from it, that there are, apparently, some _potential_ advantages and uses of this DTrace tool which you are overlooking or dismissing, and which at least some people might find of value if similar functionality (either DTrace itself or a work-alike) was available for Linux. This, despite the fact that source is available for Linux.

And, I think you'd have to agree this (some people finding DTrace, etc to be potentially valuable) is true even if such functionality is not, in principle, absolutely _necessary_ for Open Source / Free(Libre) Software systems.

Joseph, still does all _his_ arithmetic using Peano Numbers, because integers are unnecessary

tracing does not (necessarily) have anything to do with source availablility

Posted Nov 26, 2004 6:09 UTC (Fri) by hppnq (guest, #14462) [Link]

Precisely! This, of course, is what I have been trying to say all along. ;-) Thanks Joseph.

tracing does not (necessarily) have anything to do with source availablility

Posted Nov 29, 2004 5:07 UTC (Mon) by Negation (guest, #26304) [Link]

Since all the participants are much too nice, let me say, "Sir, you are an idiot."

source availablility has nothing to do with tracing

Posted Jan 20, 2005 17:40 UTC (Thu) by htd (guest, #27388) [Link]

Your answer neatly illuminates one of the biggest issues that Linux suffers from.

Developer vs deployer/manager.

If you are a developer then having access to the source code may well be a way of sidestepping the need for sophisticated trace/debug facilites (may well because kernel engineering isn't every developers cup of tea).

However if you are a deployer/manager of these systems then having access to source isn't remotely the answer, you probably have neither the skills not the time or inclination (how many corporations have a VP of kernel engineering).

If Linux is to suceed then the people who deploy and manage Linux based systems need to be in the majority and the OS needs to address their issues and not simply what developers want or can get away with.

Solaris 10

Posted Nov 18, 2004 17:25 UTC (Thu) by iabervon (subscriber, #722) [Link]

The real question is whether Oracle will go back to recommending Solaris instead of Linux. This sort of thing seems to me like the critical issue, because big companies don't buy operating systems; they buy servers. And they ask the suppliers of the software they want to run to provide the needed functionality what system to buy.

What would be LAE for?

Posted Nov 20, 2004 11:37 UTC (Sat) by bockman (guest, #3650) [Link]

Why would Solaris (or any other Unix OS) need a linux compatibility layer? I don't see any reason for that. Open-source software can be compiled natively on Solaris, and precompiled packets for Solaris are often available on the Net (I believe Sun itselfs on request provides a CD with some pre-compiled OSS). Proprietary server software, like Oracle, is supported on Solaris, which still runs a large part of today servers.

So, what am I missing?

What would be LAE for?

Posted Nov 20, 2004 23:16 UTC (Sat) by cajal (subscriber, #4167) [Link]

There are several binary-only Linux apps which a user may want to run on Solaris/x86. And speaking as a Blastwave maintainer, it's not always trivial to recompile Linux appss for Solaris -- quite a few open source packages require GNU tar to expand, GNU autoconf to configure and GNU make, gcc, GNU ld and glibc to compile. Even then, there are some that use Llinux-specific syscalls.