[HN Gopher] War of the workstations: How the lowest bidders shap...
___________________________________________________________________
War of the workstations: How the lowest bidders shaped today's tech
landscape
Author : lproven
Score : 78 points
Date : 2023-12-25 16:38 UTC (6 hours ago)
(HTM) web link (www.theregister.com)
(TXT) w3m dump (www.theregister.com)
| kens wrote:
| This is a very interesting article on computer history. There's a
| lot that I disagree with, though...
| lproven wrote:
| Like I said above -- please do read my earlier comments -- I'd
| love to hear what, and why.
| tyingq wrote:
| There's a lot that rings true here, but the article keeps noting
| that the IBM PC won partially because it was cheap. That's only
| true versus the examples the authors cite. In the business space,
| it was pretty expensive when compared to, for example, business
| oriented Z80/CPM platforms. And it was very expensive compared to
| the variety of home 8-bit choices. There were a lot of different
| markets/niches at the time, and things changed quickly, so it's
| hard to distill the history into soundbites about what happened
| and why.
| lproven wrote:
| Not quite.
|
| Firstly, re predecessors:
|
| DOS was a _lot_ more capable than CP /M-80 and any 8-bit
| systems. It displaced them for much the same reasons x86-64
| displaced x86-32: it became affordable to have lots of RAM. In
| the early 1980s, 8080/Z80 couldn't handle >64kB without clunky
| paging. Some 25Y later, x86-32 couldn't handle >4GB without
| clunky paging, in much the same way.
|
| Secondly, re the PC's cheapness. I'd argue the PC was cheap for
| a business machine, but it's not simply that the PC _hardware_
| was cheap, but the bigger point that the _bundle_ of the cheap
| machine _and the cheap OS_ is what won out.
|
| The PC launched with 3 OSes: PC DOS, the UCSD p-System (a self-
| hosted Pascal IDE based on a JVM-like environment), and DR's
| CP/M-86.
|
| MS-DOS was about 1/4 of the price of the other offerings.
|
| DR had an amazing comeback planned: it added the multitasking
| of MP/M to CP/M-86, creating Concurrent CP/M, then bolted on
| MS-DOS emulation, to create a multitasking OS that could run
| _and multitask_ MS-DOS apps _on a 286_ : Concurrent DOS (CDOS
| for short).
|
| It also had a multitasking version of the GEM GUI called X/GEM.
|
| This is something even the later OS/2 1.x couldn't do, and of
| course OS/2 1.0 didn't have a GUI at all.
|
| But CDOS/286 depended on a feature of the development versions
| of the 80286 which Intel removed from the final shipping
| version. So, when IBM launched the first 286 PC, CDOS didn't
| work.
|
| Intel put the hardware feature back but it was too late: the OS
| had been killed at birth -- it didn't work on shipping 286 kit.
| Only native apps multitask.
|
| DR had a fallback plan: it promoted CDOS as a realtime OS and
| made a living for years afterwards, but the big product to
| outdo DOS, which originated as a clone of DR's CP/M anyway, was
| thwarted.
|
| So it's not just "the PC was cheap", no. It's bigger than that.
|
| It's:
|
| * On the business desktop, the PC was cheap, _and_ the dominant
| PC OS was cheap, and the PC was built from open COTS parts and
| ran a COTS OS so was cheap to clone.
|
| * In academia and research, UNIX on mostly-COTS hardware killed
| off elaborate proprietary OSes on proprietary hardware. While
| PCs used x86, ST-506 and then ESDI and then IDE disks, ISA slot
| cards, etc., workstations used fancy 32-bit CPUs on fancy buses
| like NuBUS, VMEbus, and so on, with SCSI storage... and later
| moved to RISC chips with fancy buses and SCSI.
|
| This killed off proprietary non-open non-standard OSes such as
| VMS, Apollo DomainOS, and other exotica.
|
| Meanwhile, in business, DOS killed DR and the p-System and all
| the eight-bits.
|
| Later, Windows killed all the 16-bit GUI machines, except the
| Mac, which only survived by self-destroying and becoming a Unix
| machine.
| akira2501 wrote:
| > ISA slot cards
|
| This was actually bigger than I think people remember. IBM
| gave away all the information on their bus standard
| immediately. They clearly understood they had to create a
| robust third party add on market for the PC and this would be
| key to driving the platform. They were not wrong.
| FirmwareBurner wrote:
| They were not wrong in terms of what had to be done to make
| the OC platform the dominant one, except they didn't get to
| profit from the PC business for too long. The openness
| "mistake" is what Apple fought to avoid.
| toyg wrote:
| And Apple almost died because of that opposition to
| openness. They only returned to profitability once they
| promised to be as open as everyone else: having intel
| processors and a standard Unix userland.
|
| (They then got filthy rich by effectively pivoting to
| portable computing, a world where openness and
| standardization were never essential.)
| radicalbyte wrote:
| I'd argue that the Mac only survived because of the anti-
| trust case against Microsoft which meant that MS needed (on
| paper) competition so bailed them out.,
| giantrobot wrote:
| > In the early 1980s, 8080/Z80 couldn't handle >64kB without
| clunky paging. Some 25Y later, x86-32 couldn't handle >4GB
| without clunky paging, in much the same way.
|
| This isn't analogous. At the time x86-64 was introduced
| virtually no one had memory limitation issues. PAE allowed
| the _systems_ to have more than 4GB of RAM even if individual
| processes on 32-bit OSes were limited to 4GB. Even today you
| 'd be hard pressed to find normal user workloads running into
| 4GB RAM limitations.
|
| That's not to say larger memory spaces aren't useful and
| aren't used. It's just not the same as some very basic task
| hitting limitations of only 64K of RAM.
| snakeyjake wrote:
| LISP fetishism must be resisted every time it appears.
|
| Programmers who learn LISP and think they have become enlightened
| are no different than drunks who ramble on about how it is
| impossible to know if the colors they see are the same as the
| colors you see.
| Phiwise_ wrote:
| It's a strange sort of Lisp fetishism that wants to bring back
| Smalltalk instead of Lisp.
| lproven wrote:
| Exactly! :-)
| lproven wrote:
| I'm not a Lisp fetishist and I personally find it nearly as
| unreadable as Perl and APL.
|
| The article is in fact expressing my admiration of Dylan, if
| you look more closely, and Smalltalk and other things of that
| ilk.
|
| Lisp was a tremendously important step... _In 1959._ They
| should have continued with the planned Lisp-2, but they didn
| 't, and sadly, McCarthy is dead now.
|
| In its absence, Dylan is about the best candidate for a Lisp-2
| we have.
| selimnairb wrote:
| So computers should've stayed expensive and inaccessible to most
| people. Yeah, that's how markets grow.
| lproven wrote:
| That is not only not right, that is not even wrong.
|
| It's not even a misinterpretation of what I was saying. It's
| like taking the first letter of each line, spell checking it
| until it reads as English somehow, and disagreeing with the
| result!
|
| I am saying we shouldn't have done it the cheap way. We should
| have done it the best way when it was visible what was the
| better but more expensive way.
|
| Because that is what we must do know, but it's going to be much
| harder and much more expensive now because we need to replace
| 30+ years of accumulated useless cruft, _while staying
| interoperable with it throughout_.
| Phiwise_ wrote:
| Glad to see you're still fighting the good fight on this one,
| lproven. If anyone finds this interesting, Liam has three great
| fosdem lectures out introducing this topic from the perspective
| of business software dev, hardware tech, and open source. I found
| the first after reading The Unix-Haters Handbook, and as much as
| I like its style Proven's videos are broader and up-to-date, so
| much better for learning:
|
| The Circuit Less Traveled:
| https://news.ycombinator.com/item?id=16309195
|
| Generation Gaps; a heretical history of computing:
| https://news.ycombinator.com/item?id=22265615
|
| Starting Over; a FOSS propisal for a new type of OS for a new
| type of computer: https://news.ycombinator.com/item?id=26066762
|
| I also coincidentally found what might be the only good video
| about the Apple Newton on the internet today (although with the
| state of google search it's impossible to know outside of
| youtube). It makes a great supplement to the discussion of
| breaking the mold of OS conventions:
| https://www.youtube.com/watch?v=5kxRi34PqWo
|
| The channel also has full interviews used in the dicumentary. I
| haven't seen the newest one, but it's two hours with a Mac and
| Newton architect so it's probably great:
| https://www.youtube.com/watch?v=KsaGx0loR3M
| lproven wrote:
| Oh, thank you! :-) That was a very pleasant Newtonmas surprise
| to read! :-D
|
| Yes, the core of this article was adapted -- with my editors'
| full knowledge and agreement, of course -- from one of my
| FOSDEM talks. I plan to return with some more of the talk --
| and some new stuff! -- in later pieces.
|
| Sadly, the FOSDEM organisers did not accept my proposal for a
| talk this year. Ah well.
| e-dant wrote:
| I wonder if there's room for a theory of convergent evolution, in
| software and languages, towards something that is generally
| appreciated.
|
| Maybe there will always be camps arguing for one thing or
| another, but together and over the longest term, do they all pull
| in one general direction?
|
| I'm not so sure I agree with most of the article. The perspective
| is valuable.
| lproven wrote:
| > towards something that is generally appreciated.
|
| I think it's simpler than that.
|
| It's convergence to the lowest common denominator. The simplest
| implementation of the simplest thing that does the job, in the
| simplest easiest language that is capable of it.
|
| But because "simple" can be taken to extremes of very clever
| but abstruse tools that only near-genius level minds can use
| effectively, and those folks do not work well together, what
| ends up cheap _at first_ is the simple _easy_ thing that is
| simple and easy to get working.
|
| Lisp might be arguably simpler in a theoretical sense but for a
| lot of ordinary folks it's just too weird and too hard.
|
| APL is "simple" inasmuch as a hundred lines of nested loops can
| be written as one line of a dozen hieroglyphics that does the
| same task in one operation... but there are only a few hundred
| people on the planet that can read it.
|
| C is a simple tool for simple computers but you can pick it up
| and learn how to use it with just a book and some time.
|
| It's fiddly and hard to do anything clever which means
| programmer must do grug brain stuff.
|
| https://grugbrain.dev/
|
| And that means others can follow it, and work with it, and that
| means teams scale. Not very well but a bit. So companies can
| hire rooms full of grugs and make it work.
|
| Result, fairly simple dumb tool beats clever fancy more capable
| tool.
|
| Result, people who like the dumb tool have strength of numbers
| and they mock the speccy nerdy weirdos who like the weird tool.
|
| Which is fine until you end up with a million programs built
| from a million lines of C each and a million techies trying to
| get them to work together.
|
| Then you end up with an industry that makes billions of dollars
| a month, selling billions of lines of code that nobody
| understands, and hundreds of thousands of people trying to prop
| it up and keep it working.
|
| By that point it becomes clear that you should have employed a
| dozen geniuses to do it in a few thousand lines of the weird
| nerdy tool. You'd have ended up with something smaller and
| simpler and easier to maintain, and even the paycheques of the
| dozen geniuses would be less than the paycheques of a thousand
| grug brain developers.
|
| But it's too late. The geniuses retired or went off to grow
| bonsai or something. All that's left is people who only know
| the grug brained methods.
|
| It is easy to believe it's some kind of elegant evolution of
| the best possible solution... but it's not really. It's lots
| and lots of the cheapest _worst_ solution until everything else
| dies out.
|
| That is what I am trying to get at here.
|
| But I am always learning and I try hard to be open minded. If
| you have specific point by point rebuttals, I'd love to read
| them!
| dist-epoch wrote:
| Most likely, just like all phones now are big black rectangles.
|
| There are also orders of magnitude more programmers now, so the
| style of programming changed. Think classical music (few
| listeners) versus popular music (lots of listeners).
| jauntywundrkind wrote:
| > _The story about evolution is totally wrong. What really
| happened is that, time after time, each generation of computers
| developed until it was very capable and sophisticated, and then
| it was totally replaced by a new generation of relatively simple,
| stupid ones. Then those were improved, usually completely
| ignoring all the lessons learned in the previous generation,
| until the new generation gets replaced in turn by something
| smaller, cheaper, and far more stupid._
|
| Beautifully said. But for the last couple decades not even that
| is true. It's just been more and more of the same OSes, doing
| basically the same things. What it means to develop a native app
| is pretty fundamentally unchanged since Windows 3.11 or ISX days.
|
| Software has changed, but only neo-mainframes. All the groupware
| and multi-tenant and scale-out software systems the author
| decries as lost? Rebuilt as online systems, powered by
| communicative capitalism and vast data-keeps ("the cloud").
|
| > _We run the much-upgraded descendants of the simplest,
| stupidest, and most boring computer that anyone could get to
| market. They were the easiest to build and to get working._
|
| Unsaid here is I think where we _really_ got on the fixed path,
| is what begat honogenization. Everyone else seemed to have been
| competing to build better hardware+software+peripheral systems
| against everyone else (with some close alliances here and there).
|
| 1989 changed everything. The EISA bus _was_ the reformation of a
| thousand different competing computing industries into a vaster
| cohesive competitive ecosystem, via the Gang of Nine.
| https://en.wikipedia.org/wiki/Extended_Industry_Standard_Arc... .
| This commodified what used to be closed systems. Everyone either
| adapted to the homogenized common systems, or, one by one, the
| DECs and Suns and every other computer maker folded or got sold
| off.
|
| The business model, to me, defines what happened. Giving up on
| being proprietary, giving up on controlling "your" ecosystem was
| the hinge point. Computing was boutique and special systems,
| competing on unique and distinct features and capabilities. With
| the rise of interchangable computing parts it transitioned to a
| more collaborative & much more competitive system. Distinction
| carried the risk of being too far afield, of your stuff not being
| compatible with the others. You had to play in the big tent.
| Versus all the other upstarts playing against you. Meanwhile the
| legacy featureful unique & distinct business-model players never
| could get enough market share to survive, could certainly never
| compete downmarket, and slowly has positions eroded up and up
| market until those last upmarket places collapsed too.
|
| The love of lisp here has many of the same pitfalls. Sure it's an
| elegant modifiable system, one that can be shaped like a bonsai
| tree into distinct and beautiful forms. And I hope we see the
| rise, I hope very much, that we make software soft again, that
| big overarching ideas of cohesive computing where OS and apps and
| user's will blend together in dynamic fashion rise again. But the
| peril is disjointedness. The peril is a lack of cohesion, where
| different users have vastly different bespoke systems and
| commonality is lost.
|
| I'm tempted to stop here while I've said little that feels
| controversial. Putting in anything people dont want to hear risks
| the greater message, which is that the new ways could arise via
| many many means. But, I do think: the brightest most malleable
| most user controlled system we have is the web. Userscripts are
| very powerful, and they grant us power over disjointed chaotic
| industrial systems, which have no desire to let the user shape
| anything. I believe that, with a little effort, with tools
| already available like web components, we can build very
| sympathetic forms of computing. HTML like LISP can make visible
| and make manifest all the components pieces of computing, can be
| an S-expr like system, as we see with modern front-end-derived
| router technology for example. The whole web might not be
| terraformed in our lifetimee, we might not dislodge the
| contemporary industrial web practices to make all the web
| excellent, but I think many stable wonderful media forms that
| spread and interoperate can take root here, I think they already
| resemble the alive system of the gods the author so nicely speaks
| to. I too speak, for malleable systems everywhere (not mine but
| https://malleable.systems ), and for the web as one conduit to
| bring us closer to the gods.
| facialwipe wrote:
| After reading 30% of the article, it became clear to me that the
| author has probably never created a GitHub account.
| lproven wrote:
| You didn't look very hard.
|
| https://github.com/lproven
| ashton314 wrote:
| The description of Lisp machines sounds a lot like running Emacs
| in a way. Is Emacs... just a Lisp machine emulator?!
|
| (There is a _lot_ I dislike about Emacs Lisp; there is a lot of
| power in it though. :)
| marcosdumay wrote:
| It's a Lisp interpreter that happens to come with a text
| editor. I guess you can replace the text editing default skin,
| but I never tried it.
| amadeuspagel wrote:
| Is this "Worse is Better", but in the snarky and obnoxious style
| of The Register?
| LeoPanthera wrote:
| The answer to this is _in the article_.
| msh wrote:
| I think the author confused lowest bidder with producing
| something people could afford. For all their weaknesses micro's
| could be purchased by normal people. You could not produce a lisp
| machine or alto equalent in the 80' that it was possible to
| afford for regular people.
| BaculumMeumEst wrote:
| > Software built with tweezers and glue is not robust, no matter
| how many layers you add. It's terribly fragile, and needs armies
| of workers constantly fixing its millions of cracks and holes.
|
| Dude, come on. I really don't think anyone who actually worked on
| a medium to large Lisp codebase would write something like this.
| di4na wrote:
| One thing i think forgotten here, which actually is in the Worse
| is Better talk. But people tend to miss it.
|
| These ST and Lisps systems failed at another aspect. Reuse. The
| biggest change of the past 2 decades in software engineering
| compared to previous generations is the amount of reuse. It is
| tremendous.
|
| It is hard to talk of cause and effects here, but mostly this is
| due to the Internet. At this point, the vast majority of code
| running on any proprietary system is... Open source
| infrastructural packages.
|
| This condition a lot of the current ecosystem. You can only reuse
| code on systems in which said code runs well. As such, the Linux
| "stability" combined with x86 won, same as C and friends because
| of the tooling that made the code "portable".
|
| Yes i know. It is far from magically portable, but it is far more
| than full machine living image SmallTalk or Lisp like.
|
| As such, these "living code" are fundamentally evolutionary
| deadend. They are amazing but they cannot easily move to
| different machines and sharing parts of them is hard to separate
| from the rest of the living organism.
|
| On top of this, a lot of the elements to make this kind of
| machine works does necessitate deep in depth expertise. As the
| piece shows, the Newton is a pale copy of the goal because they
| did not have that knowledge in house nor the time (or money) to
| create it.
|
| Same thing all over the stack. A good efficient logger need deep
| expertise. Same for a good localization library. Same for a good
| set of graphic servers. Same for audio servers. Same for a http
| parser or a network library. A good regexp engine is knowledge
| knows by less than 10 people in the world probably.
|
| Once you realise that, you realise that at scale reuse is the
| only realistic way forward for software so ubiquitous as it is
| today. And that is how we got the current FOSS ecosystem, not
| because the code is better but because it would need too many
| licences to be manageable without breaking the bank in numbers of
| lawyers.
|
| Same thing for the Worse is Better. It works because it provides
| extension points and can adapt. Something the Lisp and SmallTalk
| machines fundamentally failed to provide. And that is something
| Richard Gabriel focuses on far more than the whole New Jersey
| schtick in his talk.
| 6stringmerc wrote:
| This is one angle of the history and I do think it is a useful
| and accurate representation for what it describes.
|
| My critique: This lacks context regarding the _still ongoing
| conflict_ between terminals and functional workstations. Time and
| again there is a back and forth in the computing realm. Case in
| point - I was selling SaaS deployments of what had been
| traditionally an On-Premises large cost platform.
|
| Who gets control is, to me, fundamentally a more significant
| angle on the history and future of computing. Again, will AI be
| on your phone or via network sends to a Host? Cost is a factor
| but I believe quite downstream from how these decisions are truly
| reached at the time.
___________________________________________________________________
(page generated 2023-12-25 23:00 UTC)