Slashdot Mirror
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?
Well, I can tell you why we did. Solaris' care and feeding is just too expensive, and Sun is just too arrogant.
... 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.
:)
;)
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."
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?
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...
This space for rent. Call 1-800-STEAK4U
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.
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:
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).
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.
If you want bleeding-edge stuff, change "stable" to "unstable" everywhere it occurs in your /etc/apt/sources.list and upgrade at will. :)
--
--
We have fought the AC's, and they have won.
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.
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.
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
SPARC is CRAPS backwards. :)
Every once in a while I like to masturbate a new word into my vocabulary, even if I don't know what it means.