Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
Sun Microsystems

Sun to run unmodified Linux Binaries 196

Quite a number of people wrote in to address the latest announcement and news from Sun Microsystems. Using a program they are calling lxrun, Solaris will be able to run "unmodified Linux binaries".
This discussion has been archived. No new comments can be posted.

Sun to run unmodified Linux Binaries

Comments Filter:
  • by Anonymous Coward
    So now I can play Minesweeper
    -- on top of WINE
    -- on top of lxrun (or whatever it will be called)
    -- on top of Solaris

  • /* and OS/2 *sucks*. unfriendly quasi win3.1
    user interface, crappy command line, unfriendly buttons for doing even the simplest things. i used it once for a week and hated every minute. and this from a person who *likes* dos. */

    Actually, win3.1 had a quasi OS/2 1.3 interface. I assume that's what you're talking about because with OS/2 2.0, the interface changed completely.

    In fact, the Win95 interface is essentially a half-assed imitation of the OS/2 2.x and later interface.

    The OS/2 command line is quite a bit more powerful than the DOS version by itself, however there are Unix type shells and tools available as well as the venerable 4OS2 enhancements.

    OS/2 was a truly wonderful operating system, but when IBM gave up, I chucked it as well.

  • by Anonymous Coward
    Sun isn't bundling anything. The Solaris x86 port of lxrun has been around for a while. They just contributed some changes and have started demoing it at trade shows.

    This will encourage more people to develop Linux applications since they will have a wider audience. I don't think people will start running Solaris x86 instead of Linux. I've never heard of anyone doing that.

    People who run Solaris typically have good reasons to do so.
  • by Anonymous Coward
    Try the Artistic License. It has no such
    unchecked recursion bugs.
  • by Anonymous Coward
    FreeBSD can run some Linux executables without trouble--about 1/3. Then there is about 1/3 that will run but with problems (odd colors, misplaced text, various error messages). And then there is another 1/3 that won't run at all (VMWare, Green Mountain VHDL, etc.). And in all cases you must twiddle with fragile configuration scripts, set klugey library paths, and tweak wrapper files. So it is misleading to claim that FreeBSD can "run" Linux executables seamlessly. It isn't true. If you have an occasional need to run a Linux executable under FreeBSD then it might only be a minor inconvenience. But if you need to run the full gamut of Linux software, doing it with FreeBSD is an excercise in banging your head against a brick wall. It is better to use Linux for running commercial professional application software.
  • by Anonymous Coward
    Binary compatability is added as a convinience for the situation when a user wants to run the occasional binary from another platform. This usually arises when commercial software is released in binary-only format, and a native version is simply not available (why projects like WINE are started, for instance). It's not intended to be used to run a Linux system under a native FreeBSD system as you're suggesting (or a Windows system under Linux using WINE)

    That's just stupidity.

    If you intend to run your system with the majority of applications compiled natively for Linux, logic implies you'd probably want to *run* Linux. If, however, you intend to run native binaries under FreeBSD like most people do, there is an excellent resource known as the ports collection that will allow you to compile and install most of your favourite open-source Linux apps *natively* for FreeBSD.

  • FreeBSD is not portable. BSD versions have diverged and do not share the exact same set of system calls. There is no binary portability between the various BSD platforms. In order to run an executable for one version of BSD under a different BSD variant, the executable must be passed through a BSD emulation layer similar to the Linux emulators used by the various BSDs. Emulating one BSD under another BSD involves trapping the incompatible system calls and remapping and adjusting them for the host BSD system. And also adjustments must be made for executable format (Zmagic, Qmagic, ELF, and so on). And executables which depend on internal private knowledge of VM and other kernel subsystems will fail even if they can be started.

    But in contrast, Linux executables are completely portable between Linux distributions. All Linux distributions share a common kernel. But all the BSD kernels are different and incompatible without an emulation layer.

  • by Anonymous Coward on Wednesday May 12, 1999 @04:28PM (#1895112)

    1. You have a commodity box intel multiprocessor system.

    2. You need high performance SMP

    3. Better Java x86 support than Linux

    4. Oracle more mature on Solaris x86

    5. Need log-structured file system

    6. Are a fortran or numerical analysis type.

    Now, you could say "why not just buy an UltraSparc", but then again, you can buy a multicpu system for as little as $3k.

    Linux isn't the answer because:

    1) Linux SMP performance still sucks, and it's thread model sucks.

    2) Java support still in its infancy

    3) Oracle8 is barely out of its diapers on Linux

    4) Linux has a shitty default file system (ext2fs) that takes FOREVER to fsck, especially if you have a 72gb RAID, and, its performance sucks.

    5) Linux doesn't have a parallelizing compiler that can even come close to Sun's. Go run a dejanews search on linux, solaris, and linpack. You'll see that the performance difference is as much as 1000% on some of the tougher Linpack benchmarks.

    Basically: You want to use cheap hardware, but don't want to settle for Linux's bottom-rung compiler, SMP, I/O handling, and filesystem.

    Now, if you run Solaris x86 on a single-processor machine than you are a *dummy*
    (yes, performance sucks. Solaris is tuned for SMP, not single-cpu)

  • I could swear I'd seen benchmarks rating it among the fastest filesystems at the time. (In a thread about FreeBSD's filesystem (UFS?) versus ext2. Search on deja-spews for it) This was a couple of years ago, but I don't know that things have changed very dramatically in the meantime.

    - A.P.

    "One World, One Web, One Program" - Microsoft Promotional Ad

  • I haven't seen GNU come out with a 64-bit compiler yet
    which, of course, is because you haven't looked at all - gcc, like Linux, is 64-bit clean; otherwise, the Alpha port wouldn't work (UltraSparc too, but I think they're still using 32-bit there).
  • In the early days of Linux, there was iBCS to get SCO, Solaris and other Intel Unix binaries to run on Linux. I know iBCS hasn't disappeared, but I'm finding it increasing less important). Now SCO and Sun are scrambling to run Linux binaries.

    Today, Linux tools like WINE provide Win32 compatability. One day, Bill Gates and Co. will be scrambling to run Linux binaries.
  • My experience is that ext2 is way faster then solaris' ufs. Especially in high-performance queuing situations.

  • by Eccles ( 932 )
    Having Solaris capable of running Linux binaries, even of apps that will compile under Solaris, means you can have only one version on your file servers if you have both Linux and Solaris clients. It may also reduce administrative headaches in such situations by having administrators only need a single version.
  • Try $3495.00 for a C++ compiler.
  • Visit - it's on the front page.
  • :) That Linus thread in your sig is incredibly funny. I need to read more news...

    Hey, xmame compiles fine on Linux and Solaris, we don't need any of this to play Dig Dug. :)

    I don't see why linux binary compatibility should be such a big thing for Solaris. On SPARCs, the binary-only applications already get ported, so all this sounds like is Sun further giving up their commitment to x86 Solaris, and leaving the market to Linux, while doing a half-assed job of trying to keep their existing customers.

    That's ok, since I run Linux, and I've seen x86 Solaris, I think this is all pretty silly anyhow. However, it's nice to see iBCS going the other way around now, we know we've won in being an accepted Unix, I just didn't know we'd be *the* accepted Unix. :)
  • I have lately had poor luck though. I constantly find it annoying that I have to update glib, gcc, make, etc. all the time. Oh well, it's free.
  • I would imagine most Open Source apps out there will compile to a Solaris x86 target. This seems like it targets an extremely small niche. Anything that uses imake is a pain to get compiled on a solaris machine as a general rule, since it's configured to work with the sun cc. Perhaps if you switch to XFree86, and recompile it yourself with gcc it would do ok, but what a pain. I plan to try this lxrun out soon a system I've got here running solaris x86 for that very reason. ;)

    Solaris x86 being a small niche was probably the driving force behind the port to it.
  • If Linux(x86) binaries can run native on Linux(x86) and, by using Ixrun library interpretation, run natively on FreeBSD,

    FreeBSD does not use the (inferior) system call emulation technique that lxrun uses, rather it supports alternate ABI models based on the individual binary's original platform. This basically translates to as-fast-as-native (or faster, in some cases) performance. In contrast, lxrun depends on signal delivery to notify the wrapper of an attempted system call. This technique is elegant and portable, but imposes a severe performance penalty. It also makes emulating many system functions difficult if there is not a direct native ABI equivalent.

    Don't confuse the FreeBSD (and NetBSD/OpenBSD) ABI emulation with the very much inferior lxrun; the two are quite different animals.

  • MS would want to do it for marketing reasons. NT runs linux apps but linux doesn't run NT apps... Regardless of how useful those apps are or are not it fills some checkboxes in one of those grids that marketing people make. I imagine that it could make an impact when some execs are weighing their NT plans and start asking about all that linux hype... The MS rep quickly says that NT runs all linux apps (probably not, but that never stops anyone) and then goes on to give a jab at linux because it's freeware or something like that and it's not as tested.

    It's a nice cover for them. We are still catching up with them in a lot of ways but we'll be leading pretty soon. Suppose some linux application really takes off as a hit? At least they wouldn't be totally left out in the cold.

  • I'm guessing that it won't be terribly useful for a lot of applications. Probably better than wine but not 100%.

    It's a moral victory though, it means that Sun is worried about binary only linux applications becoming important.

  • by BadlandZ ( 1725 ) on Wednesday May 12, 1999 @02:44PM (#1895127) Journal
    If you really think it's interesting, take a look inside, and feel free to make changes. It's a very very simple shell script, and a dialog front end avaliable. Both are very easy to modify and write, and something that any "beginning UNIX user" should be able to do in a very short time.

    For referance... This is soo far off topic, I think it would be best served delt with in mail (only posted here to point that out to others before incase they are tempted to continue this conversation).

  • by BadlandZ ( 1725 ) on Wednesday May 12, 1999 @02:06PM (#1895128) Journal
    FreeBSD runs Linux Binaries, Solaris runs Linux Binaries, ... others run Linux Binaries.

    For all of you who were waiting for "The Application People" (ISV's) to port to Linux, Keep Waiting. MS Word on Linux? Why? Well, if we port to Linux, we get a Solaris, FreeBSD, etc... market automatically also.

    Remembering all the "I wish product X was avaliable in Linux" stuff over the last year here on SlashDot, well, it may be comming, and it's things like this that will help, and may be needed before that happens.

    I don't honestly know what I think yet, I haven't seen it run yet, and I haven't studied the licence (Mozilla style?) enough yet to comment on it or it's implications... But, I will say, it is likely to cause some more ISV intrest in porting to Linux. (Good, more apps. Bad, more commercial influance, less intrest in Gnome apps, KDE apps, etc... Impact? Unknown).

  • What I would love to see (especially if Sun starts supporting running Sparc Linux binaries on Sparc Solaris) is the ability to mount ext2fs filesystems on Solaris. This would make dual booting much less painful.
  • Sun made Solaris 'free' for non-commercial use nearly a year ago. Page the freesolaris page []. Because they still charge media and international shipping it actually costs $30-50.

    Sun UK used to do it completely free [] (they'd order it for you from the US) but stopped doing it because of excessive demand.

  • It was cheap publicity. Sun didn't write lxrun, it already existed and only needed "improvements" so that it would run on x86 Solaris.

    Sun releases a Linux article, thousands of Linuxers stampede their site, and they get to be even more buzzwordy than before.

    Oh, and lxrun get's some improvements and some industry endorsement. So I suppose it's a win all around. That's the best part of this open source stuff. Even when I am being cynical I have to admit that announcements like this help the Linux community. The fact that they might help Sun as well just makes it a happy place for everyone.
  • by timur ( 2029 ) on Wednesday May 12, 1999 @01:42PM (#1895132)
    Not anytime soon, but probably by early next year, OS/2 will also be able to load and run Linux binaries. Take a look at Project EverBlue []. Currently, it's basically a port of xlib to OS/2, so that you can run recompiled X apps directly on OS/2's desktop. A screenshot can be seen here [].

    Those of you familar with the Win32-OS/2 Project [] (recently renamed to Project Odin), know that it's possible to load and run some Win32 exectuables under OS/2 (most notably Quake II). The next step for Project EverBlue is to create an ELF loader so that OS/2 can load Linux binaries. Then Wine will be ported to OS/2 (via a merge with Odin), and at that point, OS/2 will be able to run ...

    1. DOS apps better than any other OS
    2. 16-bit Windows apps, better than most other versions of Windows can
    3. Most Win32 apps (just like Wine)
    4. All OS/2 apps
    5. Most, if not all, Linux apps

    Combine that with the power of the WorkPlace Shell, and you'll have one kick-ass operating system.

    Timur Tabi
    Remove "nospam_" from email address

  • With modern RAM and disk capacities and the dropping cost of computers, I would much rather have statically linked binaries. Too damn much time is wasted hunting down shared libraries to get something to link. There may be some exceptions to this (e.g. servers), but IMHO, shared libraries are for masochists.
  • by gas ( 2801 )
    Sun hasn't shipped their compiler with their OS for quite some time.

    Sounds dangerous with things like GCC/EGCS around. Or do they have problems with compiling for Solaris???
  • The prices for the current Ultra line are rediculus. (My favorite in the price list is the "multimedia kit": 1500$ for a PCI-based video camera)
    So Solarix x86 is a nice alternative if you want the buzzwords (scalability, reliability) or need software that is only available for Solaris. For example, the Netscape Enterprise server is not available for Linux, and the JavaVMs for Linux are very weak compared to the Solaris versions.
  • Personally, I think this is excellent news for the Solaris and Linux platforms. Right now it only runs on x86, but Sun says they are considering a SPARC port.

    Keep an eye on the lxrun web site [] for more news. There is a download link available. Solaris Central [] will be covering the product as well.
  • SCO uses lxrun to run linux binaries as well, but I have yet to see it actually work.
  • [...] BSDI is doing the exact same thing with their operating system. But OS emulation on the UNIX side isn't anything new. BSDI also has SCO binary compatability, for example.

    BSDI's Linux compatability is done diffrently from their SCO compatability (and diffrently from FreeBSD's as well). I don't know much about lxrun, from skiming the FAQ it looks like it works the same was as FreeBSD's Linux emulation.

    The FreeBSD Linux compat stuff, and the BSD/OS SCO compatability stuff both hook into the syscall interface and do their emulation inside the kernel . Which makes it harder to modify, and fix, and bugs in it will cause the whole system to be less stable.

    The BSD/OS linux emulator works entirely in userland. It is basically a diffrent (the runtime shared linker), which remaps calls to things like write(2), read(2), ioctl(2), and syscall(2). It works quite well for dyanmically linked ELF stuff. It doesn't work for statically linked code, nor for code like Netscape which has inline assembly for system calls (in their case select).

    I don't think one system should be any faster then the other. So the only real issue would be whether the incresed ease of modification is worth giving up a.out support (YES), and static bin support (maybe).

  • Unless of course they are only talking about x86 Solaris.

    They are only talking about x86 Solaris; this item from Sun's Web site [] (linked to by the article) says:

    Lxrun is an open source application that enables you to run Linux applications unmodified with Solaris(TM) applications on the Solaris operating environment
    on Intel platforms.

    (emphasis added by me).

  • Lxrun is under the Mozilla Public License. It's the same program that was developed by SCO a few years back.

    I don't think it would be tremendously difficult to port it to NT.


  • Oh give me a break. I didn't say it should be done, I said it could. I still am not sure it hurts us to have NT users running free software.

    I'm glad I don't have to ask you for cookies :-)


  • I haven't seen GNU come out with a 64-bit compiler yet... Meanwhile although we did pay for Workshop 3.0 and support, we did get the 64-bit Workshop 5.0 as a free (or more accurately, already paid for) upgrade.
  • by Sleepy ( 4551 ) on Wednesday May 12, 1999 @01:10PM (#1895143) Homepage
    Yeah yeah BSD has had this for a while, but the exciting part is the big picture. The various UNIXen will likely stay "fragmented", but if other vendors rally around a common binary that's a big step.

    Sure, you probably have to statically link all yer friggin libraries (I'm reacting to the headline NOT the announcement text), maybe not. I'm sure there will be drawbacks, but it's one less thing for the NT crowd to point at.

    "I may not understand what I'm installing, but that's not my job. I just need to click Next, Next, Finish here so I can walk to the next system and repeat the process" - anonymous NT admin

  • -- Sneaking Atari equipment into the datacenter since 1994.

    Yah, I got my Jaguar in the server room so I can play AvP while trying to dl redhat 6.0 from the Netherlands.. ;)
  • Quite true except that Sun hasn't shipped their compiler with their OS for quite some time. The poor user would have to go and get a binary of the compiler, then set up the compiler to work on their system, and *THEN* compile the code. A lot more painful that just downloading the binary.

  • I gave up on OS/2 a long time ago due to gross mismarketing and mismanagement by IBM.

    I just don't see it gaining much mindshare unless IBM dramatically changes the way it sells and presents OS/2.

    OS/2 users got the short end of the stick and they got shafted by IBM, and it's hard to forget that.

  • The figures I've seen (and I'll distance myself by saying I haven't verified this at all) is that the Sun compilers produce 10-30% faster binaries than the GNU compilers. So that may be one reason to plunk down the $1500 or so for the compiler license from Sun.
  • If Linux(x86) binaries can run native on Linux(x86) and, by using Ixrun library interpretation, run natively on FreeBSD, Solaris(x86) and SCO, could Linux(PPC) binaries that run native on LinuxPPC and MkLinux(PPC) be able to run natively on Darwin(PPC) if a port of Ixrun was available for Darwin(PPC)?

    Would a port of Ixrun to Darwin(PPC) potentially be capable of running Linux(x86) binaries just as a port of Ixrun to Solaris(SPARC) might also be able to?

    Darwin (whether PPC, x86 or whatever) is another BSD 4.4 variant. It's design is a combination of the BSD's and is basically POSIX compliant. Because of it's similarities to the BSD's, would it not be fairly simple to port Ixrun to it? If this is not the case please reply as to why? (Other than "an X-windows system would have to be in place first")

    I realize in order to run Linux(PPC) binaries on Darwin(PPC) it might make more sense just to place a modified Linux kernel right over Mach 3.0. (identically to MkLinux) However, wouldn't a direct port of Ixrun to Darwin(PPC) reduce system load as one would not really have to be running two OSes at once?

    If LinuxPPC, MkLinux and Darwin(PPC) had binary computability I believe Darwin(PPC) would become a very useful freeware OS. A powerful OS with the best mix of FreeBSD, OpenBSD, and NetBSD, with Linux binary support running over a powerful Mach 3.0 microkernel with IPC server capable of clustering far better than any Beowulf set-up sounds good to me.

    Now THAT would be nice ;)

    If only someone could port an X-windows environment to Darwin, all this might come true... :(
  • Since Darwin has a BSD 4.4 environment, would it then be possible to port ABI emulation to it? Does ABI emulation reside as a BSD kernel module? Is it portable to all BSD environments?

    Please direct me to any additional info regarding ABI emulation as it sounds to be the best solution.

    It seems to me that this would be a very useful feature for those wanting to use Darwin to run native Linux (x86 or PPC) binaries. I'm assuming that a port of X11 would also be required???

    Thank you for your post and thanks in advance for any addition help?
  • Asthetic reasons aside, why would somebody want to?

  • First, yes: operating systems do seem to be moving towards running each other's stuff. But no, linux is not The Answer, any more than Windows Was The Answer in the 80's. Let me explain...

    Linux came about because there was a need for something that Microsoft could not reasonably provide - speed and reliability. Linux is not userfriendly, nor does it have a "standard interface". You can marginalize that if you want, or refute it as FUD, but it's true. Work is being done here, however my point is - operating systems are built to spec - to do a specific task. No program can do everything (witness emacs) and still be efficient. Bug free, yes, but not efficient.

    As long as this remains true, there will be a need for more than 1 Unified Operating System.

    Why do you think linux got here in the first place?

  • I am inclined to say "because you can".

    That may work well for hackers and computer enthusiasts such as ourselves, but Sun is doing this for money - cashola, greenbacks. Linux is the trend now, and they feel a need to be part of the "new wave". But for a business, is it realistic to put a bunch of linux binaries under solaris, if you can just get a free linux box and not worry about compatibility issues?

  • by Signal 11 ( 7608 ) on Wednesday May 12, 1999 @01:12PM (#1895153)
    Well, while this is all nice and everything, there's two things worth considering:

    - Most OSS software can be cross-compiled with little/no-effort. Infact, I believe all the GNU tools, and about 2/3rds of the stuff posted to freshmeat can be compiled on a Sun without modification.

    - There's no guarantee that just because the binary /can/ be run, it /will/ run. Case in point: fbset. Solaris doesn't have a frame buffer for it's console.. so this program will likely segfault.

    In short, it's a great idea, but it's usefulness is rather limited - if you have the source, you can be assured of system-level compatibility. All this offers is the chance to watch your program segfault on a *new* platform.

  • Agreed. It would be a "major project" not a port. My guess is that it would simply run sparc linux binaries. There would be *some* advantage for programs without source available since you would not have to depend upon the vendor deciding to compile for your architecture, but that has not been a big problem for Sun. Intercompatability is a good thing...

  • Linux shouldn't be just about beating Microsoft. It should be about freedom of information. If beating Microsoft is your only goal, then you may just as well throw in the towel now. Linux/GNU may beat them someday as a market force, but not if OSS perishes. It's not as if Linux has anything to offer that you can't get in Windows or other OSs. It's advantage is the supporting community and philosophy of sharing. That's it. Don't try to delude us into thinking Linux is meant to succeed just because you happen to support it. Without grounding values, who really cares?
  • It's an open question, but I will say that Linux compatibility systems are good for Linux and bad for competing Unicies. My justification of this position is the example of OS/2 2.0+.

    OS/2 had almost-perfect Win2.x/3.x support. Anyone who wanted to sell to the OS/2 market was faced with the question, "Why don't I just write a Windows version and make sure it runs under Win-OS/2, giving me the chance to develop a single product and sell to both markets?" As a result, OS/2 software was really only worth writing if it used OS/2-only features.

    On the other hand, anyone who was only concerned with the Windows market wrote software that might or might not run reliably under OS/2 (or under Windows, for that matter) -- and people cursed *OS/2* if it didn't, because IBM claimed OS/2 ran Windows programs.

    Substitute "Linux" for "Windows", "Solaris" or "SCO Unix" for "OS/2", and "Sun" or "SCO" for "IBM", and you can see what a victory these emulators could be for Linux -- and what a tragedy they could be, long-term, for competing Unicies.
  • I've had experience of this too.
    The shop I work for isn't really into UNIX development of any flavour, but we do maintain a small solaris box for testing connectivity of our own software.
    When I needed to compile something on it I had a choice - go get a purchase order approved for the Sun compiler, or get gcc.
    Tough choice huh ? :)
    | GodEater |
  • I've used nothing other than gcc under Solaris 2.x, with no worse results than I would get with gcc under Linux. Gcc always performs nicely, doesn't seem to have an portability problems, and has that nice "standard-gcc-interface" thing going on, so I don't have to remember all the command-line switches for foo-cc.

    Although a bit off-topic, I've also used gcc under SunOS 4.1.x (oops... I meant Solaris 1.x ;) ) with much better results than Sun's (K&R-only) cc.

    GNU tools just rock the party that rocks the party. I honestly don't know why people buy C/C++ compilers anymore, except to maybe get the snazzy IDEs that come with them.

    However, I can say that I've never used EGCS on Solaris. Isn't EGCS x86-specific, though? Anyway, I've had problems with inconsistent code generation on Intels, so I just use the tried-and-true gcc. It's never steered me wrong (unless I had an extra paren somewhere).

    The following sentence is true.
    The previous sentence is false.
  • Actually, I have a fair amount of confidence that this can be done with the Windows NT DDK (Device-Driver Development Kit). Windows NT Device drivers aren't written atop the Win32 subsystem that most Win apps are written on. NT drivers are written in NT native mode. Writing atop the NT native librares is akin to writing atop system calls, instead of using the C library routines.

    NT Subsystems (indeed, even the Win32 subsystem) are written on the NT native libraries, which are fairly-well documented (at least, fairly-well compared to the usual standard of cruft seeping out of Microsoft documentation) in the DDK. While NDA-covered stuff from Microsoft would, no doubt, make the job easier, the things that are covered in the DDK docs would, most-likely, be sufficient to write another subsystem.

    If you'll remember back to the day of NT 3.1/3.5, one of Microsoft's biggest advertising bullets was that this sort of thing could be done under NT with (relative) ease. I think it'd be a step backwards (even from a marketroid point-of-view) to make this more difficult in later releases.

    Of course, from there it's just a "small matter of programming". :)

    The following sentence is true.
    The previous sentence is false.
  • You've missed the point completely. I'm not saying that loading Linux apps requires a device driver. It requires loading a subsystem that sits atop the NT kernel.

    OS/2 protected-mode applications that do not rely on the Workplace Shell can run on Windows NT through such a subsystem. Trapping INT requests is not that difficult a matter. You simply install INT handlers (not unlike any OS kernel does) that point to your subsystem which, in turn, calls the NT system calls. The subsystem has almost all the properties of an OS. I mean, Microsoft Word isn't an NT-native application. It's a Win32 application running on a Win32 subsystem on the Windows NT Kernel. Why should Linux apps be so much harder? The Linux API actually has more in-common (in terms of design goals) with the NT native API than the Win32 API does.

    Page faults, etc. magically happen (for the most part), once you trap syscalls, since, by then, you're asking NT for the memory and passing it to the application. Opening files (in fact, IO in general) is handled by NT. That's why the kernel is there.

    Why should I assume that anything is impossible from a computer? Only things that are not computable (refer to the many wonderful examples of things not computable in a Turing machine) are impossible. Speed, that's another issue, but whether things are possible or not isn't.

    I mean, seriously, I can run Nintendo binaries on my NT box, but you think it's impossible to run binaries designed for the same type of hardware, but different OS? You have too little faith in the code, my friend.

    The following sentence is true.
    The previous sentence is false.
  • by Jonathan C. Patschke ( 8016 ) on Wednesday May 12, 1999 @08:46PM (#1895161) Homepage

    I don't see how it would hurt us to have NT have our whole application base. Isn't the whole purpose of OpenSource(TM) to let people use solutions without hassle or reinventing of multiple wheels? I don't think many of the authors of that application base would appreciate a Linux-only (or even Unix-only) mindset towards the application of those solutions.

    While NT can be considered somewhat of a lesser operating system (I'm trying to be nice here), it does have a modicum of a POSIX subsystem, so portability is theoretically doable. Although, the real issue is most-likely that NT's POSIX is to POSIX as NT's OpenGL is to OpenGL (IE: not "pure").

    Seriously, though. What would be wrong if I could run ncftp under NT (I know there's a native version, but I'm thinking examples here)? I run NT on one machine almost full-time (because I have to develop front-ends for lusers (IE: Win95 weenies) who use the Unix server software that my company pays me to write), and I'd love to be able to run Linux binaries.

    To be honest, I think what hurts our application base the most is the elitism that seems to surround GNU/Linux. Were it not for the fact that some people believe see software as solutions that benefit the human race without regard to money or system, we wouldn't even have the GNU system, or many of the works created with it.

    Seriously, how many people do you know that wouldn't even know Unix because they wouldn't have gotten there start in Linux, if everyone still saw software as property rather than a solution? I know I'm one of them.

    I'd like to take this opportunity to thank Richard, Linus, Alan, and everyone else who has not thought along the same lines that the previous poster has. Were it not for you guys, I'd probably be flipping burgers and still running OS/2. *shudder*

    The following sentence is true.
    The previous sentence is false.
  • Everytime I see an article about Sun on Slashdot, no matter how positive, there's always a lot of mudraking going on? Bitter SGI folks? OS envy? Hatred of computing corporations?

    Honestly, I think a big part of it is the last one. There is a general anti-corporate feeling in the community. Now, as with most things, that feeling can be healthy to a degree, but you don't want to overdo it.

    Also, speaking as a Sun shareholder, I think everyone should run out and buy as many SPARCstations as possible. Now if I only had the money to both a) keep my SUNW and b) actually buy a new SPARC for myself.

    PS. I think the term you're looking for is muckraking.

  • What you really want to do is play Miner 2049er
    -- on top of an Apple II emulator
    -- on top of vMac
    -- on top of WINE
    -- on top of lxrun
    -- on top of Solaris
    -- on top of vmware
  • Except for one thing, OS/2 is D.O.A. Don't get me wrong, I've ran that os since like 1992 and then got sick of IBM's *lack* of effective marketing. Personally, I would have hijacked some key people from MS. Another example of good product with uneffective marketing, lack of clout, and MS kicking butt in the advertising market. (and IBM paying a royality for each copy of OS/2 sold to MS..., which must have hurt.)

    Otherwise, OS/2 rocked, but then again I'm happier than hell with Linux! ;)
  • > Sadly enough though there is still no common format across systems that run on the same CPU.

  • What about ELF? Those run unmodified on x86 under FBSD and Linux.

    The original poster must have been smoking crack, because Running binaries on a different arch, and running x86 linux bins on FBSD, are two totally different things. Unless of course they are only talking about x86 Solaris.
  • This clearly shows that in fact, I am smoking crack.

    "I don't compose, I decompose" -Daniel Elfman
  • Solaris doesn't have a framebuffer console??? $ ls -l /dev/fb lrwxrwxrwx 1 root root 58 Mar 16 00:34 /dev/fb -> /devices/iommu@f,e0000000/sbus@f,e0001000/cgsix@2, 0:cgsix0
  • I think the real motivation for Sun supporting this is so Sun sales reps can say, "Yes, and it can run any program Linux can in addition to our vast library of supported applications for Solaris." This isn't about helping the Open Source movement out. This is Sun saying "We can do everything Linux can and more." Seriously. What use is being able to run Linux-native binaries on Sun machines. Basically none. 97% of Linux software is available as source and will compile with cc or gcc on Solaris. I'd say 70% of Linux applications that source isn't available for (distributed as binaries) are available on Solaris. So what is the subtext. MARKETING! This isn't about Linux this is about Sun impressing clueless suits! []
  • >x86 Solaris isn't that big of a hit, and frankly, >I wouldn't be surprised if someone in Sun is
    >looking for a way to justify its existance. If
    >they can sell a suit on, "Have the power of
    >Solaris and the freedom of Linux", so
    > be it. There's nothing wrong about it either,
    >unless you're trolling for Stallman.

    What the Hell is the power of Solaris? Solaris only seems worthwhile on SPARC for me. x86 UNIX-like OS's have been done better. Yes I know its good to maintain the same operating system between the low-end (x86) machines and the big (ultrasparc) servers.

    >A lot of the *in house* code you'll find at
    >various companies isn't so portable. It is a
    >selling point for Linux and a selling point for
    >Sun if they get binary emulation on the SPARC
    >hardware. Then, a scalability argument against
    >Linux could possibly be nullified.

    My guess is code like this would have trouble being run on Scum... perhaps features implimented differently.. or not at all. Remember SysV IPC? Yeah. It is cool... but it would be cooler simply if Solaris became linux compadable itself... implimenting syscalls and features... but I wouldn't use it. (OpenBSD r0x)

    I made bunch of technical errors I bet []
  • I see quite a few but any x86 operating system worth the CD's it comes on needs IDE support. IDE is cheap and fast (with one drive... heh) for lower end boxes that don't need gigs of porn... hot swapable. []

  • This is a good way for Sun to cash in on the Linux wave without embracing Linux itself.

    They are scared of Linux, as are all of the other UNIX Vendors. Sco and Sun are just starting to show their paranoia.
    *************************************** *****
    Superstition is a word the ignorant use to describe their ignorance. -Sifu
  • I don't think so because I think BSD uses a different file system, and while it can read and write ext2 it needs to set up it's root partition in it's file system.
  • As one example, we are using a number of x86 running solaris for undergraduate students here in the stat dept. of university of wisconsin. One reason for that is, the main software used by these students (minitab) is not available for linux. It is available for Windows but we want to avoid that.

    Even then, we possibly are going to install linux in these machines finally. Minitab will be a problem but we may get it installed in public computer labs running NT - after all, we TA's have a hard time getting the students to use unix.

  • So when will we see products that go the other way?


  • The OS/2 Mantra: Resistance is Futile, You will be Emulated.

    Which is nice because the native applications market dried up years ago.


  • I believe that someone does sell a full POSIX subsystem for NT, even including the "UNIX" trademark.
  • No, you don't likely have to statically link the open source libraries. Under NetBSD and FreeBSD, for example, you just download and pkg_add the linux compatability package, which installs all the Linux stuff you need in /emul/linux, and you're set.


  • My experience is that ext2 is way faster then solaris' ufs. Especially in high-performance queuing situations.
    I would be very surprised the Linux FS was not faster than FFS or UFS--the Linux FS writes metadata asynchronously! This gives you a speed boost, though you stand a much greater chance of uncorrectable filesystem corruption if you have a crash. Try mounting the Solaris or FreeBSD or whatever filesystem async next time you do the comparison, and you should see similar speeds.

    In my testing with bonnie on NetBSD (where there are no metadata writes), I find I get filesystem throughput very, very close (a few percent slower) than what I get doing raw I/O to the disk.


  • by joshv ( 13017 )
    I would imagine most Open Source apps out there will compile to a Solaris x86 target. This seems like it targets an extremely small niche.

  • Sun, BSDI, OS/2... This may be good short term news, but in the long term it bodes ill.

    It shows that the corporate mentality is not shifting towards open source, but rather is attempting to pacify the OSS movement by anointing it's BINARY product. Or simply benefiting the end users with more available software - but we can just compile that - so NO.

    This may be a genuine attempt at drawing closer to the OSS developers, to make them feel welcome and included and appreciated. Then to flesh out the good ones, hire them for the shrink-wrap market, and let OSS fall where it may.

    This probably won't be so extreme, but it smells of 'embrace and extend' from here.

    Until the big houses open their source, beware.
  • I actually have first hand experience with this, from dealing with a sun sales rep. Basically they want to sell you their compiler for money. They freely admit that GCC is available and that it works, they just mention that their compiler works better. I don't know if it's true or not but when you are dropping close to $100k for a new system the cost of the compiler isn't a real issue.
  • I imagine it would be tremendously difficult. Look at cygwin. It's been going on for years just to provide source code level compatibility and it still doesn't work perfectly. lxrun works well on SCO and Solaris because the underlying OSes are very similar. Few syscalls need to be emulated. NT's posix subsystem is beyond broken. It would probally be easier to just port the entire linux kernel to NT (minus most of the drivers of course). If you just want bash and sed and utils of that sort, grab cygwin, it really sux under win9x but it works ok on NT.
  • I fully agree that sun isn't doing anything out of goodness. They are a bussiness and they want to make money. If they can make money by supporting linux apps good for them. But linux also wins. It makes linux appear to software companies to be a better platform to port to. Port to linux, automatically get a Solaris, *BSD, SCO port. Also it gives linux some good press.

    Yah sun is looking out for their own rear-end, but so what? They aren't hurting us in the process, so why not?
  • Statically linking binaries probally wouldn't be necisary. Just about every library you need under linux is GPL'd or under some other open source license. It should be really easy to get the libraries to run dynamically linked linux executables. I do agree that this is excellent for the unix platform. Atleast x86 unix. Might help get more commercial apps for x86 unix. Ie, port to linux, automatically get ports to Solaris, SCO, *BSD, etc. World domination is a step closer. I can't wait until people start working on a way to make NT run linux binaries, that's when we know that we've won.
  • Wouldn't this be a good time for Sun to announce that they will start supporting Linux JDK officially now... (and porting from Linux to FreeBSD etc shouldn't require very much effort)

    The volunteers porting it now are doing a good job (I think), but wouldn't it be good to have Linux as an officially supported platform..


  • I hate to burst your bubble, but:

    • The EverBlue project is meaningless. We can port most Unix programs with EMX and XFree86 on OS/2 today. EverBlue is waste of time; it would be easier and better to write a PM-based Xserver (basically, a replacement for PMX).
    • Wine does not run most Win32 apps. Wine can run a few apps, and you can take an app and make it work under Wine (like I did with a very weird Win16 program I have to use--and no, it didn't work under Win-OS/2 for reasons too painful to detail here), but it's not even close to ``Most Win32 apps''.
    • I don't think you realise what's involved with making Linux run under OS/2. I'm working on it, and it's difficult, mostly due to the poor architecture of OS/2. OS/2's lack of any security really hurts too (and please don't point me to SES--it's a joke). OS/2 PM remains shackled by the SIQ bug. There is also absolutely no network support for PM like there is with X11 (other than my yet-to-be-released XCLIENT program). Finally, writing OS/2 drivers is very painful. Linux has a much better driver model.
  • How about renaming Linux:


    which stands for:

    GNGL's not GNU/Linux
  • by redhog ( 15207 )
    Binaries are Evil, and, while making the market larger for companies porting to Linux (And therefor more interresting), it may perhaps chrinken the number of open sourced programs?
  • What is the reason for Linux to exist? There is no One True solution, GUI, API or shell at all, even in the OS. How could you then motivate a One True OS? OSes performs different tasks and are optimized for different operations. That they are able to emulate each other does not say they are the same (I would like to see anyone calling Linux a Windows version, just because of Wine!).
  • No more difficult than running the arcade version
    of Tron on an x86 running Xwindows...
  • Back when I worked in a Solaris shop I would
    go hunting for an easy-to-install distribution
    of a common utility (pick your favorite) and
    would see hundreds of lines in my search that
    all contained "linux" in them somewhere, which
    invariably meant a (to get them going on Solaris)
    a recompile, a failure, a tweak of headers and
    makefiles, a recompile, a less-than-perfect
    install, etc.

    Sun wants to leverage that same code base for
    Solaris users (potentially to stop future user-
    base drain to Linux). The first step (the easy
    one) is to do it for the x86 platform where no
    machine code translation has to be done. Now,
    the next step is to make it work on the Ultras.
    Then you get all the big-$$$ benefits of Solaris
    boxen, with the no-$$$ benefits of open source
    code ready to run on Linux boxen. Sounds like
    a no-brainer to me.
  • Well, aesthetic reasons aside (because the thought
    of running NT under linux is aesthetically
    unappealing...), I am inclined to say "because
    you can".

    This from a guy who saw vmware and immediately
    wanted to know if you can run a vmware inside
    a vmware (and how deeply they can be nested)...
    why? because you can!
  • You ignored the point of my post (i.e., the
    content of the post to which I replied). The
    poster asked why would someone want to port Ixrun
    to NT...

    Clearly Sun (look at their own comments in
    the article) is doing it for money. Wonderful.
    No shocker there. In one of my other posts I
    say why it is a smart move for them.

    Me, personally, I use Linux, I recommend Linux
    (where it fits), and I also recommend Solaris
    to those who need a truly high-end high-$
    enterprise solution. I will be glad when the
    day comes that Sun is a hardware company on
    whose boxen Linux runs better than anything
    else. Hopefully that day will come.


  • This is just FUD. Only modifications to the source
    of GCC are covered by its license (in this case the GPL).

    The output it produces is unencumbered. However if
    you link with libraries covered by the LGPL then
    the source to your program remains unencumbered
    but people using your program have the right to
    the source of the LGPL libraries, usually this is
    never a problem since they are all widely available.
  • Isn't there a legal issue with using gcc?
    I understand not all the code you link with is under the LGPL, so you can't sell your binaries without releasing source.

    That is certainly why our shop won't use gcc, and shells out for lots of Sun compiler licences so more than one person can compile at a time.

    Wonder if anyone has the facts on this, as we may just be being paranoid.
  • Many just download pppd for Solaris x86, and use that. Works well.


  • Solaris x86 workstation: $450 US
    Solaris X86 Server: $695 US

    I believe the difference in costs is due to the different licensing for the server (i.e. you _may_ use it to serve other workstations, etc.) Not too sure as the web site says there's a single-user RTU included.

    I also don't know what the 1 or 2 year subscription prices are, or if these prices include a subscription.
  • by Mr. Piccolo ( 18045 ) on Wednesday May 12, 1999 @02:51PM (#1895200) Homepage
    Don't get me wrong -- lxrun is a nice piece of software, and pretty simple in concept. Since Solaris and Linux both use the ELF executable format, each can _attempt_ to execute the binaries for the other. Unfortunately, other incompatibilities soon scuttle that.

    Lxrun is basically a wrapper for executing Linux binaries. What lxrun does, first of all, is set up the search paths for loading the dynamic libraries that a Linux binary needs instead of trying to use the Solaris libraries.

    However, even with the native libraries, Linux and Solaris have different sets of syscalls. The other part of lxrun's job is to intercept those syscalls and translate them to something that supposedly does the same thing in Solaris. There are still quite a few that are missing, but it seems enough of them work to get all those programs Sun has demonstrated running.

    I find it interesting that they had Quake 2 running because when I tried it, the path names that it searched for its files were all wrong. The same with Quake 3 test (and now it bombs out completely because it searches for stuff in a directory with the CTRL-A character for a name!) It's possible that because I'm using Solaris 2.6 things are different then in Solaris 7, and that causes the errors.

    Finally, there is at least one isssue with the OS itself (at least version 2.6) that causes problems. It seems Solaris can't access memory addresses that PCI cards get mapped to (stuff like 0xf7000000) for whatever reason. Therefore, you wouldn't be able to use VESA framebuffers or the Voodoo driver :~(

    Of course, you need all the Linux libraries required for the programs yoou want to run. And given the GPL, you need to make source available for them too. What I want to know is if Sun is going to distribute the libraries with the OS, or as a separate package.

    lxrun on Solaris does seem like it's been developed for Solaris 7 anyway, though. So some of these problems may be figments of my old OS.

  • I worked at Sun for a while in the resolution center (read: internal helpdesk.) They have x86 widely deployed for laptop users - which tend to be sales types, who would really not be able to handle 'compiling' software. (That was the kind of thing they'd ask us to do for them.) So, that's one more type of user that might be on x86.

    You can also get Solaris x86 for free, if it's not for commercial use. This isn't very widely publicized, and it's not open source, and there's really not much software available that you don't have to compile yourself. Now, that changes somewhat.

    I see this as very useful for someone who, for some reason or another, is tied into Solaris (be it tradition, I Work For Sun, or a key internal application) being able to actually get useful software without having to work very hard.

    And geeks may forget this, but to the average person, a compile is harder than they are willing to attempt, and if it doesn't work out of the box, they have no way to get it to work ever. And we all know how often we need to make minor tweaks to compile software.

    What does this mean for Linux? Well, hopefully it's a step towards wider industry acceptance. Sun is realizing that Linux has a broader application base than Solaris in many respects, and wants in on that. It would be fantastic if we could move towards more binary compatibility across Unix flavors, and if Linux is the standard, great! I may be capable of compiling software, but I'd still rather download it and expect it to work. (One definite _good_ feature of the windows experience. We want to copy everything they do right, rather than be different just to be contrary.)
  • Umm... you didn't look at Sun's site too carefully then... one click away from the lxrun page was this article [] on what was done, and in it, there's info on a read-only ext2fs driver for Solaris x86.
  • Damn! I've seen banner ads for something that claims to do exactly that. I'm pretty sure I've seen them right on Slashdot.

    Even if I'm just inhaling too much magic smoke (Hmmm...the power outlet says 240 monitor should want that sort of voltage, right?), how hard can it be to get Linux binaries running on NT?

    Of course, I have trouble getting anything to run on NT, but some people can get this to work. In all reality, we should just have to implement the Linux ABI as a DLL. Since the Linux ABI is fairly well documented, at least in an RTFS sort of way, this should work. People seem to be getting fairly far getting NT apps to run on Linux with WINE; the reverse hack should be easier as the Linux ABI is better documented than the Win32 ABI.

  • by AtariDatacenter ( 31657 ) on Wednesday May 12, 1999 @01:16PM (#1895218)
    Take a look at this article... BSDI is doing the exact same thing [] with their operating system. But OS emulation on the UNIX side isn't anything new. BSDI also has SCO binary compatability, for example.
  • As it only runs on a very select list of hardware.

    And last time I checked, a single user Solaris x86 licence cost about NZ$1,150 for the desktop and NZ$1,800 for the server.

    About the only reason I can see for using it, is if you already have lots of SPARC servers and want a homogeneous operating environment for your support staff, and can't afford Ultra 5's.

    I guess this means those people can use Netscape and Applixware :)
  • by cmc ( 44956 ) on Wednesday May 12, 1999 @01:01PM (#1895235) Homepage
    FreeBSD has had that for ages and in the form of a kernel module, so you don't _have_ to run it under a special command. That's real binary compatibility.

Earth is a beta site.