Slashdot Mirror
Debian Drops SPARC Platform Support
jones_supa writes: SPARC isn't exactly a highly-used architecture anymore, so the Debian operating system is dropping support for the platform, according to Joerg Jaspert last week in the "debian-sparc" mailing list. He noted that this does not block a later comeback as "sparc64." Following that announcement, a new post today tells us that SPARC support was just removed from the unstable, experimental and jessie-updates channels.
I think the first version of Debian I'd ever used was Hamm on an old Sparcstation IPC.
Your hair look like poop, Bob! - Wanker.
I had a Sun Netra T1 200 for a bit over 10 years that ran Debian on Sparc. The hardware was reliable, the Debian as an OS worked well enough, less of a headache than Solaris IMHO. Occasionally had some weird kernel related quirks, but I generally just kept it tracking Debian sid.
I think it was just a matter of time that the Debian sparc port went away, the surplus of old sparc boxes has gone away more than anything. I'm not sure anyone used Debian on sparc for anything serious(read business use), though.
Posting to cancel a 'Troll' mod that I posted to the wrong comment by mistake. And may the AC who posted shit about gay black people, die very slowly in a fire
.
'The Economy' is a giant Ponzi scheme whose most pitiable suckers are the youngest among us and the yet-unborn.
I sorta liked SPARC. My assembly language class in college covered MIPS and SPARC programming, and while MIPS was simpler, the SPARC ISA was much more interesting.
While Cell failed as a platform, the concept itself had merit, and the concept of pairing high-performance and low-performance processors can be found in the HPC market today (like Intel's Phi or GPGPU) and in the mobile market (like ARM's big.LITTLE architecture).
Ah, but there's still a lot of old 32-bit x86 stuff out there, so the barrier to entry is extremely low. We still have 32-bit machines in-production, albeit they're the oldest ones still being used, but there are probably several thousand still running.
Dropping Sparc unfortunately makes sense. Hardware was already exotic and somewhat uncommon when it was new and still supported, and is now even more rare and given its proprietary nature, more likely to simply be permanently removed if it breaks. It's also no entry-level friendly; a kid wanting to play with Linux 'just to see' can go to the Goodwill and buy an old x86 box for $20 and friends can help make things work.
Do not look into laser with remaining eye.
my SparcCLASSIC works just fine for slashdot and arpanet mail, you insensitive CLOD!
Good people go to bed earlier.
For more than just a couple of us here, I suspect, there was a time when "Sparc," "UNIX," "graphics," "Internet," and "science" were all nearly synonymous terms.
Simpler times. Boy did that hardware last and last and last in comparison to the hardware of today.
Well, I suppose it can finally no longer be said that the Sparcstation 10 I keep here just for old times' sake can still run "current Linux distributions." But it's still fun to pull it out for people, show them hundreds of megabytes of RAM, 1152x900 24-bit graphics, gigabytes of storage, multiple ethernet channels, and multiple processors, running Firefox happily, and tell them it dates to 1992, when high-end PCs were shipping with mayyybe 16-32GB RAM, a single 486 processor, 640x480x16 graphics, a few dozen megabytes of storage, and no networking.
It helps people to get a handle on how it was possible to develop the internet and do so much of the science that came out of that period—and why even though I don't know every latest hot language, the late '80s/early '90s computer science program that I went to (entirely UNIX-based, all homework done using the CLI, vi, and gcc, emphasis on theory, classic data structures, and variously networked/parallelized environments, with labs of Sparc and 88k hardware all on a massive campus network) seems to have prepared me for today's real-world needs better than the programs they went to, with lots of Dell boxes running Windows-based Java IDEs.
STOP . AMERICA . NOW
It's because of systemd. Soon debian will drop linux and support only systemd.
I'm not sure I've heard anyone suggest ARM is superior. It happens to be fulfilling a good niche as an architecture that provides decent performance per watt. But you're not seeing anyone wanting to use it in areas where power isn't a concern.
I suspect ARM will eventually be the architecture that's supplanted, not ix86 or ix86-64. Intel's getting good at producing low power ix86 family CPUs - I have one in my tablet, and the mobile space isn't really wedded to any architecture, but the desktop space is.
You are not alone. This is not normal. None of this is normal.
Debian was the last *working* linux for sparc32 platforms
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
used that abbreviation that it just doesn't roll off the fingers any longer.
STOP . AMERICA . NOW
The 386 box that I installed Linux on my first time around was 4MB (4x1MB 30-pin SIMMs). 4MB! I mean, holy god, that's tiny. It seemed sooooo big compared to the 640kb of 8-bit PCs, and yet it's basically the same order of magnitude. Not even enough to load a single JPG snapshot from a camera phone these days.
STOP . AMERICA . NOW
(a few years ago it was Cell - WTF happened there?)
In brief, compilers didn't do a good job automatically optimizing for the vector units, and it was not worth it for most people to do it manually. A few scientific groups experimented with it, but I think most of them have gone to GPUs or just plain old supercomputers.
"First they came for the slanderers and i said nothing."
We've got ~20 of them. Those SuperClusters really DO kick some ass though ... when you get random users calling up saying "I don't know what you guys did but we've never had performance like this in 20 years" - yeah, color me impressed.
Isn't cheap, but a ton cheaper than second system effect.
[...] and is now even more rare and given its proprietary nature [...]
I never got this: SPARC is probably the least least proprietary architecture out there.
First, anyone can license (www.sparc.org) and sell SPARC CPUs, just like you can license ARM. Try going to Intel and trying to license their latest architectures. They even use OpenBoot for their "BIOS" / firmware, which was available to anyone as IEEE 1275.
Second, you can buy SPARC servers (see above) from at least two vendors (Oracle and Fujitsu), and run Solaris (or anything else) on them.
You can even get GPL licensed HDL for some of the earlier T-series processors: https://lwn.net/Articles/243874/
what consumers had access to by walking into a retail computer dealership (there were many independent white box makers at the time) and saying "give me your best."
You're probably right about me underestimating the graphics, though it's hard to remember back that far. I'm thinking 800x600 was much more common. If you could get 1024x768, it was usually interlaced (i.e. "auto-headache") and rare if I remember correctly to be able to get with 24-bit color—S3's first 16-bit capable chips didn't come out until late-1991, if I remember correctly, though I could be off.
SCSI was possible, but almost unheard of as stock, you either had to buy an add-on card and deal with driver/compatibility questions or one of the ESDISCSI bridge boards or similar. Same thing with ethernet, token, or any other dedicated networking hardware and stack. Most systems shipped with a dial-up "faxmodem" at the time, and users were stuck using Winsock on Windows 3.1. It was nontrivial to get it working. Most of the time, there was no real "networking" or "networking" support in the delivered hardware/software platform; faxmodems were largely used for dumb point-to-point connections using dial-up terminal emulator software.
And in the PC space, the higher-end you went, the less you were able to actually use the hardware for anything typical. Unless you were a corporate buyer, you bought your base platform as a whitebox, then added specialized hardware matched with specialized software in a kind of 1:1 correspondence—if you needed to perform task X, you'd buy hardware Y and software Z, and they'd essentially be useful only for task X, or maybe for task X1, X2, and X3, but certainly not much else—the same is even true for memory itself. Don't forget this is pre-Windows95, when most everyone was using Win16 on DOS. We can discuss OS/2, etc., but that again starts to get into the realm of purpose-specific and exotic computing in the PC space. There were, as I understand, a few verrry exotic 486 multiprocessors produced, but I've never even heard of a manufacturer and make/model for these—only the rumor that it was possible—so I doubt they ever made it into sales channels of any kind. My suspicion (correct me if I'm wrong) was that they were engineered for particular clients and particular roles by just one or two orgnaizations, and delivered in very small quantities; I'm not aware of any PC software in 1992 timeframe that was even multiprocessor-aware, or any standard to which it could have been coded. The Pentium processor wasn't introduced until '93 and the Pentium Pro with GTL+ and SMP capabilities didn't arrive until 1995. Even in 1995, most everything was either Win16 or 8- or 16-bit code backward compatible to the PC/XT or earlier, and would remain that way until around the Win98 era.
The UNIX platforms were standardized around SCSI, ethernet, big memory access, high-resolution graphics, and multiprocessing and presented an integrated environment in which a regular developer with a readily available compiler could take advantage of it all without particularly unusual or exotic (for that space) tactics.
STOP . AMERICA . NOW
The standard desktop at the company I work for used to be a Sun Ultra 5, and when the company imploded I picked an Ultra 5 with a fast processor (400 MHz), put some more memory in it, took it home and put Debian on it. It worked fine. Entirely decent interactive performance, like a fast Pentium 2. Not a box for video editing or other high-CPU/bandwidth activities, but fine otherwise.
I was amused to note that it wasn't a Windows box, so it was immune to Windows attacks. It wasn't an x86 box, so it was immune to x86 attacks. I guess I amuse easily. :-)
We had a pile of 32 bit SparcStations. We (literally) couldn't give them away.
...laura
Sounds like a missed opportunity for open-source: the hardware companies making Cell should have invested in compiler engineers to make really good compilers for It (or just add onto gcc), and open-source all the work. Then lots of people would have wanted to use Cell processors because of the performance.
Making a nice product, and then making closed, proprietary tools that are needed to best use that product, isn't a winning business strategy. Give away the tools free so people are interested in trying out and using your product, and then it gets designed into high-volume parts.
There's a Goodwill next to one of the hardware stores that I shop at regularly, so I'm in there fairly often. There's always lots of otherwise-obsolete computer stuff in there. Never had a problem finding something useful.
Do not look into laser with remaining eye.
For certain applications that is a true statement about "nothing better/faster/stronger" than Sparc. The top TPC-C benchmark is by Oracle's T5-8 server, for example. Maybe your project's biggest problem is your attitude.
I'd take that bet. Don't forget how much faster the ARM chips are. For example the A7 is twice the speed of the A6 which is almost 3x the speed of the A5. Admittedly the A8 is only a 20% speed burst but that's not bad relative to x86 especially for an off year. We'll find out over the next decade plus: can you make ARM faster more easily than you can x86 more efficient? But I'd bet on ARM.
Videogame programmer here. It wasn't really a compiler optimization issue. There's no compiler on the planet that can perform high-level optimizations like that.
The real problem was that those vector units (SPEs) were highly specialized computational devices, best suited for churning through relatively simple, parallel tasks with a high volume of sequential data (e.g. media streams). Videogames, unfortunately, are loaded with tasks that require access to complex data sets and/or require lots of context switches, neither of which the SPEs can handle well. Ultimately, the SPEs, while powerful in specialized roles, often had problems compensating for the slightly less powerful CPU or graphics hardware, despite requiring many times the work to optimize the game for that hardware, and all that just to get similar performance to the Xbox 360's more general-purpose hardware.
In short, the Cell processor was immensely powerful for its time in highly specialized situations, but it wasn't very well suited to the typical tasks and loads seen in a videogame. It was an idea that sounds great in theory, but didn't work so well in actual practice.
Irony: Agile development has too much intertia to be abandoned now.
How retarded is that?
Most SUNs I work on are SPARC, actually all SUNs I have worked with during the last 15 years where SPARCs.
Did they run Linux? Debian? No! Obviously they ran Sun Solaris. And still do. But I guess there are plenty of shops that abuse big iron to run plenty of virtual machines.
The Debian stance might make sense (for them). Their explanation does not, though.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Sparc includes "sparc64", for which there is a shitton of hardware still out there. That people actively use. Removing "sparc32" I could understand, but all of SPARC?!? Yet mips, powerpc, and s390 are still there.
This decision makes sense, since Debian is so dominant on Intel boxes that they can't afford resources to support SPARC - even though the port already exists and it's simply a matter of migrating the same incremental changes that are there on Lintel to SPARC.
So much for the claim Linux fans make of the OS being 'everywhere' - here is a UNIX only CPU: no version of Windows ever ran on it, only UNIX-like OSs, such as SunOS, Solaris, Linux and *BSD.
You are thinking of GNU software. As Eric Raymond pointed out, the more that Open Source software is used - whether by business or by freeloaders, the more useful it ends up being, as a lot of modifications & improvements are made over time to make it address all that diverse usage
MIPS and PowerPC are still huge in embedded. MIPS is used on a huge number of cheap routers and a lot of these are in dire need of a better OS than they ship with (and many of them ship with a hacked-up Linux). PowerPC is mostly big in automotive, but IBM still sells machines and is willing to keep funding a lot of the software support. The same goes for S/390: a big part of IBM's sales pitch there is that you can spin up Linux VMs on it easily and run the OS that you're used to. SPARC these days basically means Oracle appliances. You don't buy a SPARC machine if you want to run Linux, you buy one if you want to do the vertical integration thing with Oracle (i.e. Oracle arranges you vertically with your head downwards and shakes until all of the money is integrated with their wallet).
I am TheRaven on Soylent News
I think you have some of those the wrong way around: The A7 is about 20% faster than the A8 (it's an A8 that's had the decoder replaced with one that's compatible with the A15 and been left with the engineering group with the most OCD to optimise for a year or so).
I am TheRaven on Soylent News
Sounds like a missed opportunity for open-source
If you remember the manufacturers of the most widely available machine with Cell kicked open source in the teeth. When Sony stopped the PS3 running Linux where was the incentive to develop open source software for the Cell?
Watch this Heartland Institute video
Videogame programmer here. It wasn't really a compiler optimization issue. There's no compiler on the planet that can perform high-level optimizations like that.
Compiler engineer here. The vectorisation for the Cell wasn't the hard part, it was the data management. Autovectorisation and even autoparallelisation are done by some compilers (the Sun compiler suite was doing both before the Cell was introduced), and can be aided by OpenMP or similar annotations. If the Cell SPUs had been cache-coherent and had direct access to DRAM, then there's a good chance that a bit of investment in the compiler would have given a big speedup. The problem of deciding when to DMA data to and from the SPUs and where you need to add explicit synchronisation into the PPU was much, much harder. I've worked on a related problem in the context of automatic offload to GPUs and it turns out to be non-computable in most nontrivial cases (it depends heavily on accurate alias analysis).
I am TheRaven on Soylent News
Have you been watching Intel's product releases? Intel decided a couple of years ago that they weren't going to let ARM have the low-power server market and completely retooled their product line, starting with the avoton server line (C2xxx) and following up with the D-15xx family. (Remember how AMD keeps talking about interest from data centers? D-1540 retail availability has been tight for months because some major datacenter providers have bought essentially *all* of them...) Watching how fast Intel was able to change course and deliver products that beat the ARM *roadmap* in that timeframe (let alone delivered products) made me abandon hopes that ARM might have a serious presence in the server market. Intel just has too much R&D money & process tech for any existing competitor to go toe-to-toe with them in a segment they decide to invest in.
I haven't been following it. The D-1540 seems like a nice offering. Smartphones are now 1/2 of the entire consumer electronics industry. I wouldn't underestimate the money going into ARM.
As far as ARM in server where I think ARM is likely to expand to first would be laptop. HP Chromebook 11 for example already uses this processor. Then it moves up market taking over some mainstream laptops. I could easily see for by end of decade for Apple's laptop lineup:
ARM for Macbook (OSX or a variant of iOS)
Intel for Macbook Pro (OSX)
Apple's the bulk of all profits.
I was just using published benchmarks. What I've heard is that 20nm helped a bit, the GPU helped a lot. I hadn't heard anything about a decoder problem. So I meant what I wrote but I'm willing to be educated.
Yes, ARM is used in a lot of phones. A phone chip is very different than a server chip. The question is whether any ARM vendor has the money to do *general purpose server* R&D in competition with intel. So far, everyone who has tried has either crashed & burned or provided fairly disappointing results. What they have going for them is power efficiency, which matters in embedded solutions (think raspberry pi & smaller) but isn't that compelling on full size laptops, desktops, or servers--saving a few watts over an intel solution doesn't matter when the screen, memory, and communications consume more power than the CPU. (Side note--intel has a material advantage here by integrating some of the power-hungry components like 10GBE on silicon that's one or two generations ahead in terms of process compared to the ARM competition.) ARM seems firmly in the region of diminishing returns--they can't consume less than 0, so there just isn't that much more to cut. Intel has room to improve, and with the money they can throw at things, they will--to the extent that makes sense. In most applications single thread performance is still more relevant than a very high number of cores. So intel's current strategy is to be reasonably power efficient, integrate components in a compelling fashion, but not sacrifice too much single thread performance. So with D-1540 you get integrated 10GBE, integrated SATA, integrated DDR4, & 8 fairly powerful cores. The ARM vision is to deliver 48 slower cores, for a total package that's a little more power efficient and roughly on-par performance-wise for embarassingly parallel applications (of which there are few). Given how many distinct architectures intel has delivered over the past few years, I'm pretty confident that, if high-scaling applications actually materialize, intel will be able to crank out a new SKU faster than any ARM vendor will be able to explit the niche, bascially by scaling up avoton. (The successor to that architecture, denverton, is due out at the end of this year, probably with 16 cores & integrated 10GBE on a 14nm process.)
I'm thinking of ARM as a classic disruptive technology: https://upload.wikimedia.org/w...
i) ARM comes in first and takes customers who have requirements that x86 couldn't possibly satisfy: done
ii) ARM takes those customers who could be on x86 but gain tremendously from ARM: done
iii) ARM takes the least profitable least demanding customers from x86: happening with Chrome books -- in progress
iv) ARM takes over people core to x86 (laptops): not happening yet
v) ARM takes over more demanding users x86 desktop, server... : not close
-- this results in x86 becoming a niche product for the most demanding users
vi) ARM takes over the most demanding users extincting x86: not close
I'm saying I can see step iii becoming step iv. Of course ARM this year is not ready for step (v). But that's different than what the situation might look like 10 or 15 years out. If neither Windows nor Linux were tuned for x86 as the primary platform its dominance in server would be in more danger. If ARM vendors were moving $100b+ / yr in CPUs (double Intel's entire revenue) the server would be in more danger....
There's no problem with the decoder. The A8 is an older chip. The A7 is an updated version of the A8 (smaller, more power efficient due to various tweaks and extended to support a newer version of the instruction set so that it can be used in big.LITTLE configurations with the A15. Oh, and with SMP support, which the A8 lacked, though the A9 had). The A8 is not faster than the A7.
I am TheRaven on Soylent News
But the main reason they can sell anything in step iii is that intel doesn't care about those customers. It's not clear that ARM vendors are actually making much money on those products, and if intel cut its profit margin (i.e., if they cared enough about that particular market to actually go after it) then the ARM products would be economically untenable. There simply isn't a fundamental advantage there for the ARM vendors to take advantage of: their advantage is cost, and that's because intel has *decided* not to lower prices that much. Again, ARM's marginal power advantage simply doesn't matter on a typical laptop because the CPU isn't the most power-hungry part. (Unless you're crunching numbers, but then you probably want to have a faster chip even if it uses more power.) Even on phones the advantage of ARM is less about power consumption than the fact that you can configure an ARM SOC any way you want it--while intel has basically no interest in licensing its most advanced IP so that OEMs can build custom SOCs. The limitations of that strategy are clear--ARM hardware is basically disposable once the initial OS becomes obsolete, because nobody cares about engineering updates for old products--and I just don't see custom SOC being a driver for laptops/desktops/servers. Those markets demand more standardized hardware, and that brings us back to ARM competing toe-to-toe with intel. For the niches where hardware coprocessors really matter, intel has phi for HPC and quickassist for crypto/compression/DSP/etc.
Around here you can find old x86 boxes for free on Craigslist. CRT monitors are also plentiful; flat panels occasionally show up.
Of course if the dominant player cut their margins they can preserve their position with their least profitable, least demanding customer. That's always the case with disruption from below. Microsoft did precisely that with netbooks almost a decade ago where they allowed netbooks to:
a) drive down the price of OEM Windows ....
b) not allow them to raise the specs for years and thus made the XP -> Vista upgrade less advantageous while often equally painful.
c) by forcing Microsoft to focus down market created a bigger opening for Apple at the top of the market.
Absolutely if Intel choose to go after the ARM business they could. But Intel just turned Apple down on a fabrication deal. Intel wants their margins more than they want marketshare. Intel's least demand, lowest margin customers are ARM's high margin most demanding customers. That's how ARM slowly moves upmarket. That's how disruption from below works.
As for SOC for laptops. Here we disagree. The x86 market today has standardized hardware. Intel, Microsoft and Western Digital created a hardware / software standard that's lasted for a generation. But that hardware / software standard doesn't need to hold, and obviously wouldn't be holding if x86 is being replaced. I can easily imagine a future generation of SOC for systems with keyboards as much as they are useful in today's tablets. That doesn't mean today's SOCs are good enough, today's SOCs are barely good enough for Chromebooks. We know that the bottom rungs of laptop users were able to replace some or most of their usage with the current generation of iOS/Android tablets, if we picture SOCs 3x as functional...
" Intel's least demand, lowest margin customers are ARM's high margin most demanding customers"
This is where I think you're wrong. The phones & the tablets are where the money is, the chromebooks are an uninteresting sideshow for the ARM vendors just as much as for Intel. There's no way they're making the same money on $200 netbooks as they are on $700 phones. They're also not putting any R&D into that segment, it just happens to move along with cobbled-together parts. It's not a path to anything.
"I can easily imagine a future generation of SOC for systems with keyboards as much as they are useful in today's tablets."
You seem to misunderstand. Of course systems are getting more integrated--the question is whether consumers are interested in buying a server whose hardware is completely different than the server they bought six months ago, which needs completely different core drivers, can't boot the same kernel, etc. It's not in the consumer's interest to have that degree of vendor customization in the desktop and server markets. I already pointed out that Intel actually derives a competitive advantage from standardized SOCs: their competitors have to be better engineered just to overcome intel's process advtantage. E.g., you need to have a singificantly better 28nm 10GBE implementation to be more power efficient than intel's 14nm implementation. Is that likely? Can the ARM server vendor outperform intel's CPU, and outperform intel's best in class networking, and outperform intel's fairly solid storage controllers, and outperform intel's pcie controllers, and outperform intel's memory controllers, etc.? That's a lot of R&D, and none of the competitors have that kind of head count.
Don't get me wrong--I'd love to see ARM as a strong competition to intel in the server space. But watching how fast intel has pivoted, how quickly and reliably they deliver on new tech, and how slow and underwhelming the ARM vendors have been, I just don't see it as likely.
Server I think is trickier. Let me throw out a hypothetical for say 2028.
Samsung releases a 1024 core SOC which is cool enough it can be used in a blade. Intel is using 16 core Xeons that require a full 1U. The Samsung cores are say each 1/2 as fast as the Intel cores. Everything needs to be custom compiled for the hardware but Samsung has their own fully supported distribution which supports cloud foundry, open stack... The complexity of the x86 makes Intel emulating these designs impossible.
Now that I think could do it.
Sure, if we imagine that vendor X comes up with something implausibly advanced (scaling software to 1024 cores is hard, which is why single thread performance still matters), and intel actually goes backwards (you can buy a 32 core intel blade today) instead of developing new tech, then sure, vendor X can win.
Though nobody would buy it if it were tied to a single-vendor version of linux. BTDT, it sucks.
Yep, I agree. It's all about the data access, as I mentioned. When I said "there's no compiler on the planet" etc, I was talking about high-level optimizations, which tends to involve a lot of code and data restructuring at a fundamental level. It's a much simpler task by comparison to auto-parallelize/auto-vectorize loops, etc.
If the Cell SPUs had been cache-coherent and had direct access to DRAM
But that's a pretty big "if" there, as the SPUs didn't perform well under circumstances in which compiler-level micro-optimizations would normally work, as the overhead of the DMA transfers / context switches would tend to cancel out any potential gains. The reality for PS3 developers was that everything had to be excruciatingly hand-optimized for the peculiarities of that architecture.
Now, the relative similarity and simplicity of the PS4/Xbone are a blessing in comparison, because optimizations tend to work equally well on both platforms.
Irony: Agile development has too much intertia to be abandoned now.
But that's a pretty big "if" there
Oh, I agree - you'd have added a lot of hardware complexity and probably more than you'd be able to fit if you wanted to keep 7 of them in the thermal envelope of the Cell.
I am TheRaven on Soylent News
OK adjust to 2048 vs 128. The point was that you are saying as long as x86 is a far better fit for servers it will be used for servers. Well of course. The question is what happens as the ARM economy gets larger than the x86 economy and the advantages of ARM design techniques come to dominate. Obviously I can't see what's likely many years in the future so I don't know what that will look like. For laptop it is obvious that SOC / power drive the change. Lighter and thinner. Beyond that is gets opaque.
However the economics are daunting. With ARM selling 10-20x or more as many chips per year...
They're selling more chips for less profit--Intel still has them trounced in terms of the R&D budget regardless of how many units they ship. All you have as an argument is "ARM is better so eventually it will actually be better", but the instruction set frankly just doesn't matter very much.
Note that Intel is a fairly large ARM vendor, and had other RISC products in the past. They still design & build such chips for embedded controllers, so it's not like they don't know how to do it, but if they thought that was the best path forward for general purpose CPUs they probably wouldn't have sold that tech off to Marvell.
How about this : the 2048 core ARM server appears as a collection of 256 8-core systems that appear virtually independent (such systems already exist : 16 core ARM that's a collection of four quad core on one die, with massive on-chip buses and on-die I/O and goodies but otherwise it's four CPU that are shared-nothing between them)
The Intel system appears as a single machine with 128 cores.
Intel wins, mostly.
Actually, what happened is that Dell partnered with Goodwill to recycle any old computer that was donated to the store. While this isn't all bad, as I'm sure that Goodwill gets a fair amount of stuff that's basically junk, it also means that any newer/good hardware that gets donated also ends up getting scrapped. So the end result is that Dell has managed to eliminate one source of inexpensive used computers out there.
Though your best bet would be to just ask around, check craigslist, or keep an eye on some local dumpsters. I'm sure you could find an old P4 or even some early 64-bit hardware for free without too much trouble.