Slashdot Mirror
Linux Apps On Solaris
querencia writes "Sun has announced that Solaris 10 will comply with the Linux Standard Base specification, thus allowing Linux apps to run unchanged on Solaris. This isn't emulation -- they claim that it is 'kernel-integrated and supported as an operating system feature.' While I appreciate the benefits of the Solaris OS, I've considered them on the losing end of the battle until now. Will the power of Linux apps put Solaris back into the running?" Update: 08/04 15:50 GMT by J : At OSCON, Sun reaffirmed that Solaris 10 will be open-sourced. They said it would be one of the OSI licenses, not sure which yet; that this was approved at the highest levels of the company; and (with the expected "we're just guessing" language), it could happen as soon as year's end.
You can think of this support for Linux apps on Solaris as the same way Wine works. It provides a layer of support by implementing the needed APIs without having to deal with a total emulation enviroment.
Free Unix? Free Windows. http://www.reactos.com
This only works on Solaris x86 machines, which has always been the ugly Solaris step-child.
This seems to me to be a little desperate. Sun seems to be saying that Linux has won, at least in terms of software support.
You've never heard of CSW?
What is blastwave.org?
blastwave.org is a collective effort to create a set of binary packages of free software, that can be automatically installed to a Solaris computer (sparc or x86 based) over the network.
We (CSW) don't provide "Linux apps", but we natively compile and package software for Solaris.
Will the power of Linux apps put Solaris back into the running?
The power of free software compiled natively for my SPARC has returned Solaris to being my primary desktop. (Now if only I could afford a Blade 2500....)
Its pretty sad when a commercial OS ships a debugger with their system but no compiler.
According to the .plan of the ID software CEO there will be a Linux version soon:
Mac and Linux: Unfortunately I don't have dates for either of these. However, Linux binaries will be available very soon after the PC game hits store shelves. There are no plans for boxed Linux games. More remains to be done for the OSX version of DOOM 3 and that will take some time. We won't release the OSX version until it's just as polished as the PC version. The date for OSX DOOM 3 remains "when it's done", but I can confirm that it's definitely coming.
dtrace, zones, zfs, Sun support, source compatibility with Solaris SPARC, better stability (IMHO), and some people just prefer it. And it's not very expenive, if you pay at all.
AC comments get piped to
How about getting someone who knows what they're doing to come in to compile it for you? Apache, PHP and all their dependencies shouldn't take more than half a day for any decent admin to build from source. And they can use Sun's great compilers (soon to be available for Linux) instead of gcc.
its not the point - the benefit will be that you can take an allready working linux application binaries and throw them down on Solaris x86 and just run it - no porting or tidying up crappy code.
You dont waste time and resources porting the app, you can generally use the same hardware and but you do it under Solaris geting the advantages of that OS (dtrace, ZFS, zones, support etc).
I think the main benifit will be that once application providers are able to see that their app can run under Solaris and people use it, they might be interested in actually doing a Solaris port which with the Solaris source code compatibility you can then just compile for SPARC, opening up more markets.
What complexity of getting php to work??
./configure --enable-so
./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-mysql /usr/local/lib/php.ini
.php .phtml
/usr/local/apache2/bin/apachectl start
If you can't run:
rpm -Uvh php-4.3.8-2.1.i386.rpm then it's hard?
and
rpm -Uvh apache2-2.0.47-1.7.2.i386.rpm
then it's HARD???
Try this:
1) Visit Apache's Web Site
2) Download httpd-2.0.50.tar.gz
3) Build Apache:
1. gzip -d httpd-2_0_NN.tar.gz
2. tar xvf httpd-2_0_NN.tar
3. gunzip php-NN.tar.gz
4. tar -xvf php-NN.tar
5. cd httpd-2_0_NN
6.
7. make
8. make install
4) Visit the PHP Web Site
5) Download php-4.3.8.tar.gz
1. gtar zxvf php-4.3.8.tar.gz
2.
3. make
4. make install
5. cp php.ini-dist
6) Configure httpd.conf
AddType application/x-httpd-php
7) Start Apache
-=Linsys=-
http://www.intrusionsec.com
I'd be willing to say that Dell, IBM, and HP have as good as, if not better support for their hardware and Red Hat and Novell completely support their products.
Zones? I see you haven't done a lot of research. Linux has had equivilent features since early 2.4 by way of the grsecurity project.
What hefty price tag are you talking about??
Soalris 10:
$99 (One-year subscription) - Commercial Use
FREE - NON Commercial
Soalris 9: New Sun Computer Systems. The end user is authorized to use the latest version of the Solaris Operating System (or any other version still commercially offered by Sun) with the new Sun computer system and system board purchased from Sun or an authorized reseller."
And if it's for development, or educational use it's FREE as well.
"
-=Linsys=-
http://www.intrusionsec.com
Sun never threatened to buy Novell. It was essentially a random musing in a blog post by Schwartz that got blown way out of proportion.
Mmmm.. but the vast majority of syscalls made on a Linux system are made by glibc. They'd have to tweak the syscall interface in glibc for Solaris, but an adapted glibc would still be one of the defining features for Linux API compatibility.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
And they can use Sun's great compilers (soon to be available for Linux) instead of gcc.
No, Sun is only releasing the Sun Studio 9 IDE for Linux, not the Sun compilers. SS9 will use GCC under Linux.
Actually, many system calls aren't wrapped by glibc. To use those, you must #include and use the syscall macros, which use assembly, which includes the interrupt.
And statically-linked binaries DO count, because if your implementation can't run static binaries, it's not binary compatibility.
Besides.. The syscalls do not match one-to-one anyway. There are a lot of small incompatibilities between Linux and Sun syscalls. And then, Linux has Linux-only syscalls, Sun has Sun-only syscalls, etc.
Done (or at least getting there). Next time you're on a Solaris box, look in /usr/sfw/bin. Solaris now ships with bash (in /usr/bin) and GNU tar, grep, wget, texinfo, gs, ncftp (OK, not GNU but still usefull), and mozilla.
- Old Man of the Mountain ---- "I want to disturb my neighbor"
Unfortunately, while Java is powerful there are still many lower level things that you cannot do in Java. A primary example of this is low level networking protcols. Something as simple as ping cannot be written in Java because it does not implement ICMP (ok except for UDP error messages). Recompling C code isn't really the answer to portability either and we all know that many things do not always recompile due to differences in OS implementation (ex. BPF in BSD vs. raw socket in linux). So if you're an admin without much time to spare binary compatiblity is really nice. If it was easy to just recompile or use Java or Perl then why does BSD have a linux compatability?
The ultimage gnutastic gnuventure: compiling GNUCash under Solaris. Not only is GNUCash a GNOME app, it's a GNOME 1.4 app, and libtool just barfs all over the place with doubly-listed libraries and unfound libraries. Bleh. There's a reason why pre-compiled GNUCash versions for Solaris seem to be stuck at 1.6. I did finally manage to get version 1.6.x compiled, but even then the graphing features segfaulted.
-- "Makes Little Debbie look like a pile of puke!" - Moe Szyslak
In the x86 world things are quite different. Having been a desktop-oriented architecture for a long time, the main x86 chips (Opteron/Pentium IV) are pretty much the best these days at executing single-threaded stuff (see spec.org if you don't believe me). Multiprocessing was more of an "after-thought" than an initial requirement. Consequently, you can easily get 4-way SMPs for x86s, but not more than that (Sun AFAIK scales considerably better).
This reflects on x86 OSes as well. There's not that much need to do well on more than 8 execution contexts (4way SMP x2 - hyperthreading), and consequently having an operating system that scales better won't have that much of an impact on x86. Sure, in the "big iron" category things will be different, but not for the dominant architecture
The Raven
You're missing a key point here, I believe.
There are cases where people need Sun, and Sun apps. Lots of Geophysical apps run only on Solaris/Sparc right now. However, people might also want Linux apps, so making them available on the already mandatory Sun gear will keep some people gruntled.
Ultimately, you're right--if Linux compatibility is wanted, Linux is generally going to be the best solution in a vacuum. However if Linux compatibility is wanted on top of other requirements, then a compromise like this is better than having two machines on your desk.
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban