The cult of Amiga and SGI, or why workstations matter
peter.czanik.hu
peter.czanik.hu
It's a pleasure I respect, but it's not something I'll ever be able to understand because they're longing for platforms that got pruned from the chain of direct causality that led to our current consensus (which I'd define more as EDVAC -> CTSS -> MULTICS/CPM -> SysV/DOS/x86 => Windows/Mac/Linux/BSD/Android/x86/ARM).
My point is that open source projects still maintain all these #ifdefs to support these unobtainable platforms. Because open source is driven by hobbyism and passion. And people are really passionate about the computers they're not allowed to use at their jobs anymore. But all those ifdefs scare and discourage the rest of us.
For example, here's a change I recently wrote to delete all the VAX/OS2/DOS/Amiga code from GNU Make and it ended up being 201,049 lines of deletions. https://github.com/jart/cosmopolitan/commit/10a766ebd07b7340... A lot of what I do with Cosmopolitan Libc is because it breaks my heart how in every single program's codebase we see this same pattern, and I feel like it really ought to be abstracted by the C library, since the root problem is all these projects are depending on 12 different C libraries instead of 1.
I'm sure some of those systems and ones like it make plenty of use out of those #ifdefs though, and it's not just a handful of old fogey enthusiasts cramping everyone elses style. Established systems can't always evolve as fast as the general market.
There's plenty of things "holding open source back", this isn't a significant one of them IMNSHO.
Don't put words in my mouth, I said GNU make is a solved problem.
Make works the way it’s intended to work. Leave it as is.
"You can't have systemd in Debian, what about kFreeBSD" "You can't use Rust until it supports DEC Alpha"
...there are no shortage of examples where open and free software is held back by hyper-niche interests, where our pet twenty and thirty year old, long-dead projects and processor architectures create absurd barriers to improve anything.
Old hardware is always useful.
Sadly I’ve heard it can be rough on older architectures still. I’ve been told, that at least on VAX, for example is not in the best of states because usermode dependencies on Python. From what I was told, Python currently doesn’t have a VAX port due to the architectures floating point design.
There was a fundraiser which I created for that purpose.
For example, in GNU Make's dir.c file. There's a lot of stuff like this:
#ifndef _AMIGA
return dir_file_exists_p (".", name);
#else /* !AMIGA */
return dir_file_exists_p ("", name);
#endif /* AMIGA */
I would propose that we instead say, if you use Amiga, there's great support for it in versions of GNU Make up until x.y.z. So if you love old Amigas, you'll be well served using an older version of GNU Make. I think it's straightforward.
There should be a platform adapter API instead that defines a shared header with function names for these actions, multiple platform-specific implementation files, and only one of them gets compiled.
That way you could simply ignore the existence of "filesys_amiga.c", and then maybe delete it 50 years from now.
(I realize it's probably not realistic to do such major internal surgery on Make at this point.)
⸻
1. It works even on somewhat actively developed code since the likely to require porting parts of the program could be clumped together in a web source file and, once isolated, generally saw few if any changes. I remember maintaining the public domain vms change files for the TeX 2–3/MF 1–2 upgrades and as I recall, even with these significant changes to the programs, no updates for the change files were necessary.²
2. Most of the work that I did back then in maintenance was centered around enhancements to the VMS-specific features. For example, rather than having iniTeX be a special executable, instead, iniTeX features could be enabled/disabled at runtime from a single executable.³ Similarly with debug code.
3. This feature appeared soon after in the web2c port of TeX and friends, but I think that Tom Rokicki might have got the idea from me (or else it was a case of great minds thinking alike in the late 80s).
As they say, those who don't know the past, are bound to repeat it.
It’s old software which has far better and faster replacements like Ninja.
The whole design of Make itself is outdated and inefficient which is why tools like Ninja are much faster.
Also, Ninja by itself is not really a replacement for GNU make. Rather it's a tool one can build such a replacement on, so the comparison is a bit off to start with...
Surely there are more options "keep that until the heat death of the universe" and "remove that the moment its platform is out of production". A more practical metric for free/open software, I think, would be "is there still someone maintaining this software on this platform": every major release (e.g., 5.x -> 6.0) could be a time to do a sanity check, documenting ports that don't have an active maintainer as "deprecated". At the next major release, if nobody's stepped up to maintain it, then it gets removed. (One could argue even that's too draconian, because there may be people still using the port even if it's not maintained.)
amigaos had a major new release less than a year ago so i guess the amiga ifdefs should stay
A good example of source code organisation that does a decent job of separating per-platform concerns, is the Nethack code base.
But stdint.h is from C99, and AFAIK there are non-ancient compilers for non-ancient platforms that still don't fully support C99.
Many C developers in my experience (as recent as 5 years ago) haven't really adapted to C99. This is in part because some platforms (Microsoft, I'm looking at you) resisted adopting it for quite some time and partly because a lot of C development is carried out by older developers who have long given up on keeping up with new developments. And I say that as a dev in my 40s.
I think stdint etc are great, but for some people the start of any 'serious' C codebase still requires a whole load of int and pointer type redefinitions.
Ah, the wonderful world where you pass the dwLength of your lpszName, which is a LPCSTR, as a DWORD.
Isn't this the same process you yourself referenced? There's nothing stopping people from forking and building leaner versions of these programs, but it turns out that projects with those passionate, nostalgic developers are more successful even with the support burden than that same project without them. That backwards-support might be a cost rather than a waste.
i'm misunderstanding what the post had to do with promoting open source
No need to break it for older systems.
That commit 10a766eb you linked to appears to have significantly more than removal of those architectures -- you also appear to have deleted all the tests, documentation, and support for multiple (human) languages. Of the portions of diff which aren't deleted files, many of the deletions seem to be around code reformatting (i.e. they add a line for each line they remove), and removal of includes which your libc doesn't need / support. I do see that you have removed several #ifdef VMS (and similar) stanzas, but the vast bulk of the changes are either removal of, or modifications to, unrelated files.
Although I agree instinctively that we shouldn't expect to run the latest version of Make on the VAX in our basement, this diff doesn't make that argument very well and IMO borders on disingenous.
Or, to put it another way, after looking at your diff, I feel much happier about your hypothetical make-on-Amiga afficionado, because I know that they also care about i18n, documentation, and testing!
It's a long story...
At the time, I was a fairly junior employee doing research in AGD, the advanced graphics division. I saw funny things, which should have led me to resign, but I didn't know better at the time. Starting in the late 90's, SGI was feeling competitive pressure from 3DFx, NVIDIA, 3DLabs, Evans and Sutherland (dying, but big), and they hadn't released a new graphics architecture in years. They were selling Infinite Reality 2's (which were just a clock increase over IR1), and some tired Impact graphics on Octanes. The O2 was long in the tooth. Internally, engineering was working on next gen graphics for both, and they were both dying of creeping featureitis. Nothing ever made a deadline, they kept slipping by months. The high end graphics pipes to replace infinite reality never shipped due to this, and the "VPro" graphics for Octane were fatally broken on a fundamental level, where fixing it would mean going back to the algorithmic drawing board, not just some Verilog tweak, basically, taping out a new chip. Why was it so broken? Because some engineers decided to implement a cool theory and were allowed to do it (no clipping, recursive rasterization, hilbert space memory organization).
At the same time, NVIDIA was shipping the GeForce, 3DFx was dying, and these consumer cards processed many times more triangles than SGI's flagship Infinite Reality 2, which was the size of a refrigerator and pulled kilowatts. SGI kept saying that anti-aliasing is the killer feature of SGI and that this is why we continue to sell into visual simulation and oil and gas sector. The line rendering quality on SGI hardware was far better as well. However, given SGI wasn't able to ship a new graphics system in perhaps 6 years at that point, and NVIDIA was launching a new architecture every two years, the reason to use SGI at big money customers quickly disappeared.
As for Rick Beluzzo, man, the was a buffoon. My first week at SGI was the week he became CEO, and in my very first allhands ever, someone asked something along the lines of, "We are hemmoraging a lot of money, what are you going to do about it"? He replied with, "Yeah, we are, but HP, E&S, etc, are hemmoraging a lot more and they have less in the bank, so we'll pick up their business". I should have quit my first week.
The problem was that when you take some polygons which come close to W=0 after perspective correction, their unclipped coordinates get humongous and you run out of interpolator precision. So, imagine you draw one polygon for the sky, another for the ground, and the damn things Z-fight each other!
SGI even came out with an extension to "hint" to the driver whether you want fast or accurate clipping on Octane. When set to fast, it was fast and wrong. When set to accurate, we did it on the CPU [1]
1 - https://www.khronos.org/registry/OpenGL/extensions/SGIX/SGIX...
3D graphics would have terrible performance without that technique.
The area where companies could do all that and do it successfully kind of ended in the late 90s. IBM survived but nothing can kill them, I assume they suffered too.
What do you think, going back to your first day, if you were CEO could have been done?
I always thought for Sun OpenSource Solaris, embracing x86, being RedHat and eventually Cloud could have been the winning combination.
I'm grateful they had their day, fondly remember IRIX and have gotten many productive years out of SGI hardware, my career would definitely not have taken off the way it did without them, in fact the whole 'webcam/camarades.com/ww.com' saga would have never happened if the SGI Indy did not ship with a camera out of the box.
The book The Innovator's Dilemma describes the process.
Not quite sure. You correctly pointed out SGI (HP, Sun, everyone else in the workstation segment) was suffering with Windows NT eating it from below. To counter that, SGI would need something to compete in price. IRIX always had excellent multiprocessor support and, with transistors getting smaller, adding more CPUs could give it some breathing room without doing any microarchitectural changes. For visualization hardware the same also applies - more dumb hardware with wider buses on a smaller node cost about the same while delivering better performance. To survive, they needed to offer something that's different enough from Windows NT boxes (on x86, MIPS and Alpha back then) while maintaining a better cost/benefit (and compatibility with software already created). I'd focus in low-end entry-level systems that could compete with the puny x86's by way of superior hardware-software integration. The kind of what Apple does, when you open the M1-based Air and it's out of hibernation before the lid is fully opened.
> I always thought for Sun OpenSource Solaris, embracing x86, being RedHat and eventually Cloud could have been the winning combination.
I think embracing x86 was a huge mistake by Sun - it helped legitimize it as a server platform. OpenSolaris was a step in the right direction, however, but their entry level systems were all x86 and, if you are building on x86, why would you want to deploy on much more expensive SPARC hardware?
Sun never even tried to make a workstation based on Niagara (first gen would suck, second gen not so much), and OpenSolaris was too little, too late - by then the ship had sailed and technical workstations were all x86 boxes running Linux.
That kind of exactly what Sun did and likely gave them legs. This might not have made it out of the 90s otherwise.
> I think embracing x86 was a huge mistake by Sun - it helped legitimize it as a server platform.
x86 was simple better on performance. I think it would have happened anyway.
> OpenSolaris was a step in the right direction, however, but their entry level systems were all x86 and, if you are building on x86, why would you want to deploy on much more expensive SPARC hardware?
That's why I am saying they should have dropped Sparc already in the very early 2000s. They waste so much money on machines that were casually owned by x86.
They had two SPARC architectures - the big core, high-performance one and Niagara, the many wimpy core one and Sun never thought about combining both on the same machine, which is more or less what x86 is doing now because they are being forced to do it by Apple and its M1. Sun was there in the early 2000's.
There's no fundamental reason why x86 has to be faster than SPARC, in fact, SPARC machines trounced x86 ones.
Another thing that killed Sun was that it could never decide whether they were Apple or Microsoft - they never decided whether they wanted to make integrated hardware or a become plain software company.
Other then Intel having 100x more money and more architects with better nodes ...
SPARC was already worse by 1998.
Its really only continued to make money because companies couldn't figure out how to scale vertically and rather paid absolutely absurd amounts for these multi-core machines.
Some of the Supercomputer people showed how they could totally destroy Crey/Sun and so on with simple clusters of x86.
Sure had they perfectly executed SPARC and hit on every investment they might have done a lot better, but that just wasn't the reality. Intel just executed much better. SPARC had all kinds of development failure in the 90s and in the late 90s Intel just had better nodes in addition to better architecture.
> Another thing that killed Sun was that it could never decide whether they were Apple or Microsoft - they never decided whether they wanted to make integrated hardware or a become plain software company.
I think they did want to be Apple but they simply were not that god at making products. They were actually better at making software, but then didn't do very well at making products based on that.
The did some good stuff like Fishworks, AMD x86 Servers and so on.
They should really have turned into Open Apple, RedHat and AWS. With OpenSolaris and Zones on x86 costume machines they could have dominated the Cloud space (they even had products going into that direction early in the 2000s).
But I don't remember those. I remember Intergraph did (and they were quite good, but died quickly)
https://www.itprotoday.com/windows-8/sgi-debuts-killer-new-n...
I also was not surprised to see Rick Belluzzo's name in the press release... The devastation that man caused has no parallel in the history of personal computing. It's comparable to what Steven Elop did in the mobile space.
I use to joke Microsoft had perfected the use of executive outplacement as an offensive weapon.
A project I worked on a couple of decades ago had interleaved the bits of the x and y indexes to get that effect “for free”, I imagine a Hilbert curve decode would take quite a bit of silicon.
The slow pace and poor execution of CPU and graphics architectures after ~1997 is crazy to think about. The R10000 kept getting warmed over, same for IR, and VPro, and the O2.
The Onyx4 just being an Origin 350 with ATI FireGL graphics (and running XFree86 on IRIX) was the final sign that they were just milking existing customers rather than delivering anything innovative.
at the peak of nvidia 3dfx war new chips were coming out every 6-9 months
Riva 128 (April 1997) to TNT (June 15, 1998) took 14 months, TNT2 (March 15, 1999) 8 month, GF256 (October 11, 1999) 7 months, GF2 (April 26, 2000) 6 months, | 3dfx dies here |, GF3 (February 27, 2001) 9 months, GF4 (February 6, 2002) 12 months, FX (March 2003) 13 months, etc ...
At least until Oracle, of all companies, acquired Sun...
OpenJDK would have remained an option and other organizations would be more than able to steer the language.
Almost everybody other then Oracle would likely not have closed Solaris development for example.
Whoever would have ownership of Java would not just close it. Java was way to popular and would have continued development no matter where it landed.
It was Oracle that introduced SPARC ADI, the very first sucessful use of hardware memory tagging in commercial UNIXes, which others are still followers.
Yeah, that is why Oracle still does like 80% of the work on OpenJDK, where are those contributors doing language innovation instead of repacking OpenJDK distributions?
And even without that they suck as a company and it sucks to be their costumer for the most part.
Even if they release something open source its often a license that prevents anybody else from doing much with it.
They are pretty much one of the worst tech companies in the world and pretty much most people agree with this.
John Carmack tweeted about buying one a while back. I'm not sure if a DGX on your desk does anything for working with ML at the bleeding edge, though, since those all run on megaclusters of A100s or TPUs.
It always looks like all the low-hanging fruit has already been plucked. So, stop looking for low-hanging fruit.
It's definitely true that the cost of implementing a frame buffer fell well into the affordable range as they were moving to PARC. And politics at PARC made it easy to say you were developing a system for "inexpert document managers." They were definitely exploring new ideas about HCI as PC hardware was emerging. But Larry Tessler was pretty clear that Lisa learned what not to do from looking at the Alto & Star. And the Alto & Star learned what not to do by looking at various bits of ARC software. And Engelbart was adamant his team not repeat the UI/UX mistakes of ITS.
So sure... they were trailblazers, but they had a good idea of where they wanted to go.
And where would that be? Not so obvious. Stick in a random person and they’d have no idea. You could easily say the same thing today. Are you not wanting to make the mistakes of all previous computing and know the direction it should take? If you do, and you’re able to execute and change the direction of computing, you’d be a very rare talent indeed.
Same for Page/Brin, find someone as smart as they were and try starting Google now, I bet it's not gonna go the same way.
Where I am going with all this is that what we're trying to build, the consumer grade hardware to run it won't exist for two more years so we're having to use really beefy workstations in our day-to-day work. Not quite PARC level of built-from-scratch customization, but not exactly cheap consumer grade desktops either.
The closest example today would be people like developers, AI researchers, 3D designers and video editors buying high-end video cards (quite possibly multiple) running in Threadripper systems. They're paying up for GPU power and huge amounts of cores/RAM/IO bandwidth/whatever to either do something that isn't feasible on a lower end system or to complete their work much more quickly.
I'm sure there are analogies for a lot of other industries as well.
Also - there is no cloud, just someone else's computer. Which is why I will never rely on something like a Chromebook, the web or other modern day equivalents of dumb terminals :)
https://daringfireball.net/linked/2019/12/17/sgi-workstation...
> The Octane line’s entry-level product, which comes with a 225-MHz R10000 MIPS processor, 128MB of memory, a 4GB hard drive, and a 20-inch monitor, will fall to $17,995 from $19,995.
Really makes the M1 Ultra look affordable.
Still, sure did stand out in the MIT computer labs!
Whatever I had, I don't recall lack of memory ever being a problem. And the GUI was quite snappy.
No big surprise that the Indy side always filled up first, and that "everyone" soon had XEarth and similar running as backgrounds on the Indys... Of course "everyone" loved SGI and were thoroughly unimpressed with Sun after a semester in those labs.
24x 4.5GHz cores, 96GB memory, 48TB NVMe storage, 2 giant GPUs, etc.
The MSRP on them is ... quite staggering though!
EDIT: Just saw the other comment and I stand corrected.
Note that nvlink is also available on the 3090, which does also have the same bus width as the A6000.
A decked out Mac Pro can reach over $50,000 and it's not even that powerful as your 2x 3090Ti example, but that's the Apple tax for you.
Want to argue that Apple should have more variation in their offerings and price points? Sure - I heartily agree. But blithely tossing out a contextless $50K price tag as being some sort of "tax" is just silly.
LambdaLabs will even sell you a prebuilt around that price with the same specs.
That said, I wouldn’t personally get into a pissing match over x86 Apples. I think their ARM offerings are far more interesting.
You're deluding yourself with your claim. If you would have done 30 seconds of googling, you would have found out that Dell, HP, Lenovo and Puget Systems, all sell workstations that can beat the top spec Mac Pro or can build one yourself for way cheaper than them but as a business you want the support and no headache so it makes sense to buy prebuilts.
So yeah, there's an Apple tax on it.
https://www.imore.com/53000-pc-competition-apples-53000-mac-...
This was always the dumb bit with the "apple wants HOW MUCH for a mac pro!?!?" articles about the "$50k mac"... it had $40k of memory in it alone, and the "comparable" systems he was building maxed out at 256GB theoretical and 128GB actual. That's great if it works, using a lower spec will push costs down on both sides, but it's not comparable.
The trick here is to use a board with 32 dimm sockets -- which requires an oddball formfactor-- but it radically lowers the cost of reaching 2TB.
But your point remains, change your target to 4TB ram (which really isn't an absurd amount of ram) and the astronomical costs come back (unless you go to 96 dimm socket systems, which have their own astronomical costs).
The amount of power you can buy today for under $1000 let alone under $10000 is insane compared to back then. The M1 Ultra is not that expensive compared to mid-range workstations or even high-end PCs of previous eras.
If you look in back-issues of Byte the prices of early PCs with a usable spec are eye-watering, even before correcting for inflation.
Prices didn't start dropping to more accessible levels until the 90s.
Add on web frontends and mail exchangers, and the entire system was slower and had less aggregate RAM and processing power, less (and slower) disk (well SSD in my laptop) than my current $1500 laptop.
From what I've read, Oxide is making racks of servers and has no interest in workstations that an individual would use.
But for video it had two major things going for it: Genlock, allowing cheap passthrough of a video signal and overlaying Amiga graphics on top of the video, and products like the Video Toaster that was initially built around the Amiga.
So you could see Amiga's pop up in video context may years after they were otherwise becoming obsolete because of that.
People also kept Amigas going past their prime for apps like Deluxe Paint.
A PC could certainly replace it by 2000 but if you developed your content in the mid-1980's then Amiga was probably your solution and you needed to keep it going for a while.
(I think this is a subset of your comment rather than an extension but Babylon 5 reference ;)
Even Babylon 5 switched the render farms for seasons 4 and 5.
Not impossible someone would still want to replace individual systems in a render farm rather than upgrading, but given the potential speed gains it'd seem like a poor choice.
The 'workstation' largely died because general off the shelf machines because fast enough to perform those task almost as well. You now see a more open market for the peripherals that help 'specialize' a general purpose computer. Wacom tablets, video capture devices, customized video editing controllers, midi controllers, GPUs, etc
Looking back at what it was capable of though...they were doing 256 colors and sampled audio at a time when x86 was still pushing 16 colors and could only produce generated tones through the speaker built into the case.
There was some really good music on the Amiga, too. Some of my favorites:
Hybris theme: https://youtu.be/Siwd7b0iXOc
Pioneer Plague theme: https://youtu.be/JSLcN6GBzO0?t=17
Treasure Trap theme: https://youtu.be/n5h_Wu7QRpM
And of course, you can't mention Amiga music without also mentioning Space Debris: https://youtu.be/thnXzUFJnfQ
4,096 colors.
A handful of games did use HAM for up to 4096 colours, but mostly for static screens (there's somewhere in the region of half a dozen exceptions total)
Hybris was a gorgeous game too. It was top notch arcade quality graphics back when it came in 1987.
Edit: I'm just going to throw this in here for good measure: the Lotus Turbo Challenge II soundtrack https://www.youtube.com/watch?v=vETonlaTZ4c
I mean, somebody made an instrumental cover of it years and years later, that's how it stuck in some people's minds! https://www.youtube.com/watch?v=b6Ijk17osUc
After nekochan went offline, there isn’t really a central gathering place for SGI fans anymore, but we are out there.
In my home office I have a little mini museum that consists of display of esoteric 90's workstations:
* Apple Quadra 610 running A/UX (Apple's first UNIX)
* NeXT NeXTstation Turbo
* SGI Indigo2 IMPACT10000
* Sun Ultra 2 Elite3D
* UMAX J700 (dual 604e) running BeOS
* HP Visualize C240
All working and all fun to fire up and play around with from time to time. Tracking down software to play with is a challenge at times. Since most of what I want to fiddle around with is proprietary and long since abandoned (Maya, CATIA, NX, etc.). If by some chance we were to end up on a conference call, you'd see them displayed in the background. :-)
* Apollo Domain 4500
* HP 9000
* m86k/25 NeXTstation
* NeXTstation Turbo
* NeXT Cube with NeXTDimension card
* SPARCstation 5
* SGI OEM machine from Control-Data with mips R2000A/R3000
* SGI Indy
* IBM RS6000/320H
* IBM RS6000/250
* Cobalt Qube 2700D
* Sun JavaStation1
* Sun Ray1
* SPARC IPC
* Alpha-Entry-Workstation 533
they are in storage at my grandmothers now, and i don't know if any of them still run. some of these i was using actively as my workstation at home. some where just to explore. as i got more and more into free software, dealing with the nonfree stuff on those machines got less and less appealing. though i was also running linux on machines that were supported.
* HP 9000 712/60
* SUN Ultra 1 Creator (With SunPC DX2)
* Mac Quadra 610
These are still working, albeit waiting for recapping. The Gecko is running NextSTEP for the original id Software DooM map editor and the Ultra and Quadra are on the original OS they came with. Would love to get more SUN and SGI hardware but the prices are getting quite out of hand...
Being graphics geek, I also spent quite some time around the graphics documentation.
For me, one of the biggest mistakes was only making IrisGL available while keeping Inventor for themselves.
To the subject at hand, this is one difference I find with most modern computers, the lack of soul in a vertical integration experience blended between hardware and software.
They were best-in-class for visualization, and when used with Stereographic Crystal Eyes hardware/glasses, 3D was awesome. We also rendered high-quality POV-Ray animations on an O2 in 1996, when the software was barely 5 years old!
My last big computing efforts were on a SGI Origin 2000 (R12000) in 2002, and the allure of that machine was being able to get 32 GB of shared RAM all to myself.
Around 1990 or 2000, I was able to see how some of the big energy companies in Houston were using SGI machines' 3D capabilities.
They'd have rooms about 10 feet square with projectors hanging from the ceiling that would take seismic data and render it on the walls as colorful images of oil deposits and different strata of rocks and gas and water and such. Using a hand controller, the employees could "walk" through the earth to see where the deposits were and plot the best/most efficient route for the drilling pipes to follow.
Pretty much today's VR gaming headset world. Except, without a headset. And this was almost a quarter of a century ago.
I can't imagine what the energy companies are doing now, with their supercomputers and seemingly limitless budgets.
Now you can probably build that out of forza, a decent gaming pc, and some hobbiest electronics.
There was the professor who bought an SGI machine but didn't put enough RAM in it, plugged it into the AC power and Ethernet, couldn't do anything with it, and left it plugged in for a few years with no root password.
There was the demo I attended up at Syracuse where a pair of identical twins from eastern Europe were supposed to show off something but couldn't get it to work, Geoffrey Fox's conclusion was "never buy a gigabyte of cheap RAM" back when a gigabyte was a lot.
When SGI came out with a filesystem for Linux I could never shake the perception that it would be a machine for incinerating your files.
I did development work on the Indy and a much larger 8(!) CPU machine daily for several years. I remember there were some complications related to shared libraries (which, IIRC, were a relatively new feature at the time), but overall I remember those machines working quite well. The Indy was a great daily driver for the time.
We used SGI Indy systems for network administration at the university, and SGI Octanes for niche graphical applications and databases, but they were always considered an expensive luxury for both of those use cases. Nearly every other UNIX system at the university back then was Sun Microsystems.
The best source for hardware ended up being a local university surplus shop where we could get the big SGI monitors for pennies on the dollar.
It was a naive perspective.
I respect that Apple makes good quality hardware, but I wish there was an equivalent that was more developer-friendly. System76 is almost that but not quite.
they all suffered from lack of packagemanagement and old versions of commandline tools. you almost always had to manually install better tools like GNU.
i did use a macbook for some time, but the only reason i managed was that most of my work is on remote servers, so most of the terminals on my mac were running linux anyways. yet, when i switched back to a linux machine as my main workstation i just immediately felt better, and didn't miss the mac at all. and now when i use the mac i really just want to go back to linux.
The media scene on Linux is definitely improving (Blender and Lightworks and Krita have gotten good) but I think it still has awhile before I'm fully able to abandon my Mac setup. Honestly I just wish Darling would improve [2] enough to where I could just run everything I care about within Linux.
[1] I actually did google and apparently there is an OpenToonz Snap package, so I could be wrong on this. I'll need to play with it.
[2] No judgement to the Darling team, I realize it's a difficult project.
The Amigas were something else, though, but every time I ran into one it was getting its lunch eaten by the nearby Mac. Only for a year or two, in TV production environments, did I see an advantage with Amiga.
Now, with both among my collection, the SGI is the one I turn on most frequently (when the power grid can handle it).
To this day I love the on-brand SGI industrial design aesthetic.
Anyways, here's desktop for linux to mimic IRIX 4dwm/motif https://docs.maxxinteractive.com/ if you're into that sort of thing.
The killer apps on the platform were the various proprietary high en graphical and 3D suites. These are much better on modern computers now anyways.
Running Hollywood-level graphical software, perhaps no. But I never tried.
When the area I was living at the time was having periodic power issues I'd check the console any time I got home, and if there was a new log message I knew I'd need to bring all the x86 kit back up once I'd had a coffee or three.
Our desktop workstations in '95-'96 had 16MB. Our servers had 128MB and it was extravagant (and cost way too much - we should have made do with half that or less).
Well, FVWM and URxvt were lighter than MWM and Irix' setup for Winterm.
The simple reality is that Intel had the Wintel monopoly and they had gigantic volume and absurd amounts of money to invest. If you compare the size of teams working on SPARC to what Intel invested its totally clear why they ended up winning.
> The idea that RISC was somehow elegant turned out to be a myth.
No, it didn't. The reality is a bunch of literal students made a processor that outperformed industry cores. Imagine today if a university said 'we made a chip that is faster then i9'.
The early RISC processors with pretty small amount of work very incredibly competitive.
So yes, its was actually amazing and revolutionary and totally changed computing forever.
That this advantage would magically mean 'RISC will be the best thing ever for the rest of history' is pretty crazy demand to make for it to be called revolution.
> code compression properties of CISC continued to benefit x86.
Not actually that much, code density of x86 for 64 bit systems isn't all that amazing. Its certainty not why they won.
Parent is telling you: At any given development cost, you'll end up with a faster CPU if you go RISC.
This is why almost every new ISA to meet success in the last three decades has been RISC.
To make the argument that CISC had anything to do with anything would be, what if in mid-95s Sun, SGI would have released their own CISC ISA. That would have been literally crazy.
> Nobody, literally not one single customer cares how easy or hard it was to design and implement the CPU
The companies who produce them care.
> They only care how much it costs and how fast it goes.
Yes and I explained why x86 won based on that logic so I don't know what you arguing.
There still is a hardware advantage (has nothing to do with sizes, everything to do with complexity), but let's ignore that.
RISC being simpler doesn't just help the hardware. It also helps the software, the whole stack.
Extra complexity needs strong justification. RISC-V takes that idea seriously, and this is why it already has the traction it does, and is going through exponential growth.
Citation needed.
Still, if you're thinking about Intel success, I can tell you there's two factors for it: IBM PC Clones and Intel's monopoly on advanced fab nodes. These were enough to overcompensated for CISC being trash.
>the code compression properties of CISC continued to benefit x86.
x86 had good code density. AMD64 (x86-64) has really bad code density, dramatically worse than RV64GC.
I do remember writing asm for the arm26 (arm2) chip in my Archimedes and that was definitely actual RISC, but obviously these days not so much.
I prefer Unix workstations instead and play retro games on my MiSTER.
https://eab.abime.net/ (English Amiga Board)
You'll be able to get help there much more easily than via Google.