Is Linux Losing Its SPARC?

flsquirrel asks: "As I spent 5 hours of my Sunday afternoon trying to get some form of Linux to load on my Sparcstation 5, I started to wonder where the support for all these Sun boxes is headed. Redhat has dropped Sparc altogether as a supported platform. Some others like Mandrake have recently picked it up but seem dismally unprepared to tackle the platform. Most distributions ignore the platform completely. So I thought I'd throw this out to the Slashdot community for discussion. Is there any hope of saving Linux on the Sparc? What options do SPARCstation owners have for a reletively up to date distro that isn't in beta or otherwise have bizzar issues stemming from someone just trying to recompile an Intel distro for the Sparc architecture?" One of the great things about Linux is its ability to run on many different architectures. So why is SPARC support beginning to lag? Lack of interest? Lack of resources? Would anyone be interested in contributing the missing necessary resources?

Comments

Re:Why do you want do this?

[Anonymous Coward]

Well, I can tell you why we did. Solaris' care and feeding is just too expensive, and Sun is just too arrogant.

I'll use the first application we moved from Solaris to Linux as my example. It was deployed on a trio of maxed out Enterprise 450s. Each box handled 1/3 of the work load which was handed out to them by another machine. By our figures and the specs of the machines we figured we should have had about half again as much throughput as we did. We called in a support request, worked with their engineering team to understand how our application worked for about two days, then they sent us a small benchmark and directions on how to run it. We did and sent them back the results, they sent out a field tech a couple days latter that said "we figure you're getting about 50% of what you should for your appliction" (mind you we estimated 66%) he adjusted three or four kernel paramaters on each box and rebooted, retested, adjusted again, rebooted, retested. Wham! our performance skyrocketed to about what we expected (98% of our prediction anyway.) We were happy, but curious why we didn't see any mention of these paramaters in any docs? "because they're not public." Turns out the contract we signed to get their help not only had a clause that said they wouldn't reveal the secrets of our application or problem, but that we wouldn't reveal the solution! One of our engineers spent most of a week out searching the internet and several books, looking for those paramaters... she didn't find them anywhere. We paid a five figure price tag for that "service". Ended up with no idea what what the paramaters he changed do, or what they're values meant... future applications would obviously have to go back to them for appropriate tuning.

About a month latter we had finished migrating the application (all three servers) onto a single box running linux (slightly larger box, different architecture) and we got better throughput than we had with the solaris boxen. Our initial port ran about as well as it did on the solaris boxes at first, but a week of reading on the net, and looking at some source code and we had tuned it to the point that it outperformed the sparcs by about 10% with only about 3/4 of the hardware horsepower of the trio combined. Total cost: under a thousand dollars including the time of four engineers and a couple books, plus the results of that experience were 100% retained, we now know enough to tune our own boxes.

About two months after that our local Sun sales rep was in town and the boss brought him down to our lab, he wanted to just check base and see if we were happy with the improved performance. Someone laughed, someone else just pointed him to the three machines on the other side of the lab... even a sales guy could tell they had been "decommisioned". I think the exact phrase that was used was "we'll be recycling them." ... he assumed the project was finished, "oh no, that's part of our ongoing dataflow, it's over there..." the boss chirps up, pointing to a beatup old IBM netfinity on the otherside of the room, with a tux sticker on the front of it, and a sign hanging above it that says "sparcless.blah.blah.blah" and it's list of IP addresses. If those machines are "recycled" in the functional sense rather than the scrap metal sense, they'll be running Linux, just as the netfinity that replaced them was recycled from it past life where it ran OS/2.

Sadly we still have several hundred Solaris boxen scattered throughout the company, and the guys in engineering who negotiated 120 new workstations with him after his little visit to our lab were quite upset with us. That's why I'm posting anonymously... they're vicious and petty when annoyed.

Since then, we've migrated 14 major applications off of Windows, Solaris, HP/UX and VMS... most of them to Linux. (I personally decommisioned the last of our Vaxen... it was fun, a large sledge hammer was used, then it was feed to an industrial crusher. Everyone with an account on the box in the end was given a chunk, makes a nice paper weight. :)

Speaking of annoying an petty, that brings me to Solaris itself. This is another reason why many of us would rather run Linux, the os is simply painfull to use. Granted that given dozens of hours to tweak and configure it, plus a slew of other software, you can build a functional machine that won't drive you crazy... but why should I have to? The last Linux distro I installed had everything configured integrated and functional right off the cd. Vanila CDE off the cd is about equivalent to WFW 3.11. There's also a skills gap, the kid I just interviewed yesterday is comming out of college comfortable with both Windows and Linux. Is he fluent in Linux sysadmin? No. But he knows enough to get around the basics, we'll teach him the rest. Compare that to Solaris... find me a college kid that understands how to re-install a package from the original CD, we're loosing our Solaris experts as they move up in the company, or retire and can't replace them, the ones you can find are all flush with certificates from Sun that are about as meaningfull as an MSCE, and want absurd salaries. I'm sorry, but a piece of paper signed by McNeally that basically means you've successfully installed a scratch copy of Solaris doesn't mean I'm going to pay you as much as the gal that's been here for 12 years and came in at midnight on a saturday last summer to rebuild an entire system from the ground up in 14 hours to replace one that got melted in an office fire... that's pulling parts from storage through OS load up, application installation, data restore, functional checkout and delivery to the shipping doc in 14 hours.

Part of me says: Solaris is dead. Sparc will probably go with it, and since Sun really is a one trick pony so will they. The only use for Linux on Sparc is to salvage a few more years of life out of old boxes after Sun files chapter 11. Then the other part of me looks at the list of applications that have us tied to Solaris and laughs at the idea of getting them all ported over to Linux or one of the other platforms we're consolodating on soon enough. Yes, it's almost a religious issue, but it's not because we all love Linux and want to put it everywhere, it's because we've come to hate slowaris and the arrogant bastards behind it and want it out of our data centers.

You see why I post anonymously? ;)

replies to #81 and #89 in this thread

[TBone]

Both basically say Solaris 8 doesn't run on old systems or is too slow on not as old systems.

Uh...so? Microsoft doesn't support your 25Mhz 486SLC with 4M or ram any more, why should Sun support your old hardware with it's new software? That hardware is almost 10 years old. You still have the option to run Windows 3.1 on your old 486's, run old Solaris on your sun4c and sun4d platforms. In fact, that solution is more viable than M$ platforms, because you have the option to build your own software from source, and not use the binaries that are out for newer versions.

Backward compatibility is nice, but it's gotta stop somewhere...

Slackware

[Jeffrey Baker]

Slackware has a port to SPARC in their -current tree, which will freeze to 7.2 sometime this summer. They also have an working Alpha port.

Why is Support Lagging?

[Jonathan C. Patschke]

Note: By ``Linux'', I mean ``operating systems based on the Linux kernel''. Likewise, I mean ``operating systems based on the Linux kernel for SPARC platforms'' when I say ``S/Linux''.

Well, I realize this is an unpopular opinion for this forum, but, I feel that it's a valid one, as I've run both Linux and Solaris on many, many SPARCstations (everything from a lowly Sun 4/440 through the gamut of SS10/SS20 configurations, on SS1000 servers, and enterprise-class UltraSPARCs), and have had to work with both operatingsystems on a fairly close level day-to-day for the last several years.

To put it gently, Solaris is a far better operating environment than Linux (for most things. Solaris sucks as a workstation, for counterexample), on the SPARC architecture. If you've only seen Solaris on the x86, and are are convinced that it blows, you're entirely correct: Solaris/x86 blows. Solaris/SPARC shines.

For the longest, I ran Linux on my SPARCstation/LX simply because Solaris 2.6 demanded too much hardware. The streamlining that's taken place in the last two releases makes it a valid option again on the older hardware (except for the -old- sun4 and sun4c platforms, which aren't supported).

Really, what it boils down to is the audience. Right now, Linux has very little to offer over Solaris, and is missing a few features that are critical for the majority of people that run the newer SPARC hardware. People like me (ie: Developer/Sysadmin for demanding corporation) don't have the time to hack Linux all day long to get it to work on hardware (we need it to ``just work'', just like the lusers, but for different reasons so we can't offer our expertise with the SPARC platform. Also, since many of us work in high-security environments, we can't open-up our machine to be probed and compiled-against, either.

It's not-at-all that Linux sucks or that it runs awfully on a SPARC (on the contrary, S/Linux blazes (compared to Solaris) on low-end hardware), it's just that Solaris works, and there's no reason to switch away from something that works that well.

Here's why I use Solaris on my systems. If Linux obtained these features, people like me might switch on a few machines (ie: machines that don't have to run certified software configurations (like Oracle) to meet SLAs):

• Solaris actually has a useful single-user mode, where you can update critical system libraries (libc, for instance), apply patches, and recover broken filesystems. To do many of these things in Linux, you need a bootdisc, because almost none of the necessary tools are statically linked.
• There is no decent SPARCv9 optimizing C compiler for Linux.
• Hardware support is also lacking. Granted, I may have to rollback to Solaris 2.6 to use my old SPARCstation IPX, or even 2.5 to use my 4/440 (boatanchor), but it's still Solaris, and administration is largely the same as when I walk over to a E6500, which, last I checked, will not run Linux.
• System partitioning, CPU affinity, and other concurrency features are in their infancy on Linux. Progress is good, but it doesn't compare with Solaris, yet.
• Linux still has to be powered down to add/remove things like CPUs. For big sites, this isn't acceptable.
• /dev/sdwhich-one-it-is-today isn't a problem under Solaris. Device node-names are closely tied to hardware--partition-nodes, especially, and are very predictably named. The last time I ran S/Linux, I couldn't determine any rhyme or reason behind the order in which Linux detected drives--it clearly wasn't based on SCSI ID. The only time I've had anything similar happen in Solaris, is when I had to reinstall a controller card in a disc array--the disc array suddenly has a new serial number, and Solaris detected it as an entirely separate controller (which is desirable behaviour, usually).
• Solaris uses standard SYSV packages. No rpm/deb/tgz stuff to mess with, and the format has remained stable for as long as I can remember (unlike rpm, which just broke compatibility in whatever-the-version-is-that-ships-with-RH7).
• Solstice, for all its flaws, is quite a timesaver (and ass-saver), and it does actually work most of the time. Disksuite and Adminsuite are enormously helpful, and I can't think of anything in the same category under Linux. If the words "Linuxconf" or "control-panel" are in your response, you've never used Solstice fully.
• While not the fault of Linux itself, all the commercial Linux software is targeted to the x86 platform. That means I can't run Oracle or DB/2 or lots of other things on a S/Linux server, unless I run it through Solaris emulation mode (ewww....). In the same vein, I can't get the Veritas Volume Manager for Linux, so I wouldn't want to run most of the commercial applications on it, anyway (at least, not for paying customers).
• Using LD_LIBRARY_PATH instead of /etc/ld.so.conf means that my users can customize their library setups however they want, without me needing to make system-wide changes just to satisfy some broken app that can't figure out how to dlopen() a file in the current directory.

That's not to say that Linux doesn't have its share of practical advantages:

• You never know how much you'd miss /dev/urandom until you don't have it. You have to implement a random-number generator in user-mode if you want one on Solaris. You can run prngd to simulate it, but it's not nearly as convenient as a real /dev/urandom is.
• If you can't afford Sun's compilers, gcc and libtool behave much better on Linux than they do on Solaris.

The fact-of-the-matter is that Solaris is a very, very nice operating system, and those who run it are reluctant to switch just because it does its job so well. And, if you don't have a receptive target-audience, your development project (in this case, S/Linux) doesn't move forward very quickly.

For your average J Random BOFH, it's the same price, too (I really don't need the Linux source for most things). If you need the Solaris source for some site-specific customization, Sun has it available.

In summary, Linux really is a nice OS, but Solaris is a very, very, nice OS, and it's got the full support of the OEM, and is the same price as Linux, and runs the vast majority of the same software. I mean, if you like Linux, you'll still run Linux (and that's a good thing), but if you have no preference, which would you choose?

I mean, let's look at why Linux was a success to begin with. Linus wanted an affordable, professional-grade Uunix-like OS that would run on his 386. If I want an affordabe, professional-grade, Unix-like OS for my SPARCserver 1000, I go to www.sun.com and download Solaris 8.

obligatory debian plug

[Phexro]

go look at debian. debian 2.2 was released with support for 6 architectures, and there should be at least one more for 2.3.

2.2 is a bit out of date (xfree 3.3.6, glibc 2.1.3) but it's very stable. and you can always try life in the fast lane and use the testing or unstable branches.

disclaimer: i'm a debian developer. i'm biased in favor of debian, but only because it's the greatest linux distro ever, while all the others suck rocks.
---

Re:Why do you want do this?

[SpaFF]

Well I personally would want to do this because I have a better understanding of how to maintain a Linux installation as opposed to Solaris. Also, performance wise, Linux smoked Solaris 8 on my Ultra 5. Now this may be because I have no idea how to tweak Solaris, so if you can point me to some material on how to make Solaris' file I/O not suck a big fat one I'd appreciate it.

Debian.

[Vincepb]

I'm pretty sure the Debian Sparc devel tree is pretty active.
Maybe you should give that a try.

Missing the Point

[mcneight]

Most of these posts deal with either
a) Why Linux sux and {*BSD,Solaris,Win2K} rox
b) Why Linux rox and {*BSD,Solaris,Win2K} sux
c) Which distro is best for SPARC

and they all miss the point.

Red Hat was the first to notice it, and perhaps other distro's will eventually, but the fact is that Sun doesn't *like* Linux. They don't appreciate Linux treading on their SPARC/Solaris turf, and they really don't like Linux being chosen over their own software for high-end installations. So, rather than play fair they play dirty. They give away their "tuned, high-performance" software to users with fewer than 8 processors in order to maintain/increase market share. Then, when your computing needs require more than 8 processors, you get to pay up (*cough*M$*cough*). This is happening to *BSD as well. Notice that NetBSD/sparc64 isn't as complete as it could be, and OpenBSD/sparc doesn't even support the UltraSPARC yet.

Consider:
Compaq makes and sells Tru64 Unix, but they actively support Linux for Alpha.
IBM makes and sells AIX, but they actively support Linux for S/390 (and, I believe, their RS/6000 series now).
SGI makes and sells IRIX, but they actively support Linux for MIPS.
HP makes and sells HP/UX, but they actively support Linux for PA-RISC and Itanium (well, at least they are starting to).
Dell sells Windows, but they actively support Linux for x86.
Sun makes and sells Solaris, but they do not actively support Linux. Period.

Go to http://www.sun.com/linux/ and you will see what I'm talking about. On the first page is an article on how to transition from Linux to Solaris. Dig deeper, and you'll find their page on UltraLinux, and at the bottom it says:

Note: Sun Microsystems does not provide support for the Linux operating system, either directly through Sun's Enteprise Services division, or by any indirect means. Linux users who wish to receive commercial support for their Linux systems should contact the vendor of the operating system distribution, or investigate third-party organizations that may help them.

People are complaining about a lack of feature support or completeness in Linux for SPARC, and the truth is that there aren't enough UltraLinux zealots out there to overcome the corporate inertia or the free Solaris bait.

I'm sure Dave Miller can tell you all about the progress made with the Linux/MIPS port while he was working for SGI, and then how far it went after SGI lost interest (and I'm talking about the SGI of 1996-97, not the SGI of today).

And if you are looking for a guide on how to go about making Linux work inspite of a companies best efforts, take a look at the Macintosh versions of the Linux/PPC or Linux/68k ports. Apple never has released detailed hardware developer information for the old 68k hardware, but Linux and *BSD run on them anyway, because of the dedicated volunteers who chose to make it work.

UltraLinux isn't dead, but without Sun (or Fujitsu or some other large SPARC-based entity) showing some interest, then it's all up to a handful of volunteers, and they'll get to it when they get to it (unless you get there first).

Actively Using SPARC Linux - Experiences Of A Geek

[Joel Rowbottom]

Having had various bits of Sun kit pass by me in recent times, I've taken the opportunity to install Linux on each one and try it out as an alternative to Solaris.

Wind back to August 1998 - I tried originally installed Red Hat on an old Axil (that's a Sun clone, in this case of a SparcStation 20). It was an absolute nightmare as there weren't any easily-obtainable bootable CDs, and we ended up netbooting it. The thing panicked repeatedly, and as for compiling kernels we might as well have compiled using pencil and paper for all the good it did.

Now come to the present day. I use the Slackware SPARC port, which in my view is absolutely excellent.

Here's the rundown on what was good (and bad) from each distribution I tried:

• Red Hat: Admittedly not tried it recently, but seemed to suffer from quite a few problems including kernels not compiling. Last tried 2.2.0, I think it was RH6. Install was reasonably trouble-free once we got it netbooting, and installation using the console port was fine.
• SuSE: Ruediger will kill me for this, but I had no ends of problems with it. The console port is not supported very well for installs, so you have to connect a monitor up to it - which for most people won't be accessible. That said, it seemed to work fine once installed and screwed down. Installed via CD, taken from SuSE's website.
• Debian: Mostly my unfamiliarity with Debian let me down here, but I've got a nameserver box running it quite happily now. It's a SS20 with 32M RAM and it ticks along fine, coping quite adequately with huge zonefiles. Installed via CD taken from a local Debian mirror.
• Slackware: A newcomer, but I'm a Slackware whore anyway so I was pretty good with it. Disadvantage is that the ISO just installs the bare essentials, so you have to download the rest of slackware-current and install it later. Big problem in that it didn't detect the basic network card on a SS5, SS10 or SS20 for an NFS install, but seemed to work OK on an Ultra5.

I haven't tried any others, but I'm eagerly awaiting the final Slackware distribution.

Linux on a Sparc copes wonderfully with lots of database transactions and loads of I/O, certainly better than an Intel box will. In my day job we've had really good success running MySQL on a Sparc, but we're now porting to Oracle on Solaris (but only really cos they haven't released it for Sparc Linux!).

On the kernel side...

[davem]

As the creator of the Sparc port I guess I ought to say something. To be honest, I work exclusively these days on the 64-bit port. UltraSparc is enough to take all of my spare time when I'm not working on the networking. And yu will note that at least in Linus's tree, UltraSparc tends to be the most uptodate non-x86 port, I send updates on an almost daily basis to Linus. I tried to keep 32-bit Sparc chugging along but I stopped wanting to give the impression that I could keep up, I simply couldn't do it all. I could have kept trying and doing a half-assed job on both the 64-bit and 32-bit ports. I'd rather concentrate my energy on one port and do a good job.

Forgot about Debian?

[locutus074]

They have an alive-and-kicking Sparc distribution. In fact, I just installed it a week or two ago on a Sparc 10 I recently acquired.

If you want bleeding-edge stuff, change "stable" to "unstable" everywhere it occurs in your /etc/apt/sources.list and upgrade at will. :)

--

What are you talking about?

[marm]

Red Hat may have dropped their SPARC support but there's still plenty to choose from:

Debian has active ports for both SPARC/UltraSPARC with a 32-bit userland and an UltraSPARC port with a 64-bit userland. The 32-bit SPARC port is much more up-to-date and complete, and basically is at parity with Debian-x86. It has a stable, testing and unstable branch just like Debian-x86 and thanks to the clever Debian package management and development tools is kept up-to-date with the main x86 tree automatically. Due to Debian's widely-ported and volunteer nature the SPARC port is likely to be supported for quite some time.

SuSE is also widely ported, and again, has a SPARC port which is essentially at parity with the main x86 version - 7.1.

Slackware also has a SPARC port, but if you are used to Red Hat or Solaris it may be too much of a culture shock with things like its BSD-style initscripts and primitive package management.

All of these are modern, up-to-date distros, which (Debian especially) I prefer to Red Hat.

Try them out. You might like them.

On my Sparcs, I run Solaris

[Hairy_Potter]

Even though I run an old version of Solaris, 2.6, it's still .2 better than the latest Linux, 2.4.

So I suggest Linus take a move from the marketing people and call the next major kernel release 3.0.

Re:On my Sparcs, I run Solaris

[Dancin_Santa]

Win2k has got you all beat by about 1997.4. Though it only beats OSX by MCMXC.

Dancin Santa

Why do you want do this?

[jtotheh]

Why do you want to do this, why would someone prefer Linux to Solaris on SPARC? I'm genuinely curious

Absolutely correct

[catpyss]

I just installed Debian on a SparcStation10 this past Sunday. I run Debian as my home operating system, and noticed no difference between the x86 and SPARC versions. Everything worked the same

I do, however, take issue with the person who asked the question. Merely because Redhat dropped "stable" support (they still offer non-official support) for SPARC doesn't mean it is dead. If I am not mistake SuSE has now added SPARC to their list of supported archs.

The final thing to keep in mind is that SPARC hardware has a much lower userbase than x86. There are much fewer vendors and suppliers. Also, SPARC hardware is very pricey and is usually aimed at corporate dollars.

Still, hopping on Ebay to get an old SS10/20 is a good idea. SPARC's OpenPROM is really, really cool. I installed Debain on mine with no floppy, no CDROM, no keyboard, and no monitor. Try that with x86.
-catpyss

Re:OT: What does SPARC mean

[dhamsaic]

SPARC is CRAPS backwards. :)