5 ms·

That "lucky" is conflating two things: UNIX winning and UNIX surviving. The second part is not chance based, imho. So open question is weather any of the contem

That "lucky" is conflating two things: UNIX winning and UNIX surviving. The second part is not chance based, imho. So open question is weather any of the contemporary "state of the art" approaches would not have run into design issues that become manifest at internet scale utility. Naturally the original gophers must think UNIX overall made the right choice ignoring SoTA.

pjmlp 5y ago
When the option is between free beer or paying tons of money for Xerox, DEC and IBM alternatives, it is hardly based on merit.
- eternalban 5y ago
  That's granted. That's selection step 1. Then UNIX cum Linux approach eats the world for a couple of decades, pulling its weight. If it was inherently flawed, if SoTA approaches were addressing inherent issues, then it would have failed selection steps 2..n. And we would have long ago bitten the bullet to replace the "lucky" legacy. So, yes, the lucky contender has issues, has warts, can certainly benefit from x, y and z, but as is, it continues to be viable at scale and that is not "luck". Second, we simply don't know, considering all aspects including human resources and engineering economics, whether Xerox, DEC, or IBM's alternatives would have fared better than UNIX. I'm open to learning why/how if this is a shut case in your opinion.
  - pjmlp 5y ago
    I bet if UNIX was sold with the same market prices as Xerox, DEC, or IBM's alternatives, it would have been a footnote on the history of OSes, like many others since the mid-1950's.
    - eternalban 5y ago
      You elicit my first ever OMG. Yes, granted! :) But that's just mechanics of computing history. That was the lucky break. But it wasn't 'garbage' getting lucky. It wasn't some lame specimen that survived a battle that killed off titans of a species. It was and remains a contender. And, to the point, its authors determined (certainly influenced by not being or as SoTA aware as academic CS lights) that a compelling 80% solution with a [simple] versatile conceptual model can work and it has. Same story goes for Go the language. Of course it is like PLT reto with bolt-ons, but like it or not, it is a viable approach to building software and systems.

pjmlp 5y ago

When the option is between free beer or paying tons of money for Xerox, DEC and IBM alternatives, it is hardly based on merit.

eternalban 5y ago
That's granted. That's selection step 1. Then UNIX cum Linux approach eats the world for a couple of decades, pulling its weight. If it was inherently flawed, if SoTA approaches were addressing inherent issues, then it would have failed selection steps 2..n. And we would have long ago bitten the bullet to replace the "lucky" legacy. So, yes, the lucky contender has issues, has warts, can certainly benefit from x, y and z, but as is, it continues to be viable at scale and that is not "luck". Second, we simply don't know, considering all aspects including human resources and engineering economics, whether Xerox, DEC, or IBM's alternatives would have fared better than UNIX. I'm open to learning why/how if this is a shut case in your opinion.
- pjmlp 5y ago
  I bet if UNIX was sold with the same market prices as Xerox, DEC, or IBM's alternatives, it would have been a footnote on the history of OSes, like many others since the mid-1950's.
  - eternalban 5y ago
    You elicit my first ever OMG. Yes, granted! :) But that's just mechanics of computing history. That was the lucky break. But it wasn't 'garbage' getting lucky. It wasn't some lame specimen that survived a battle that killed off titans of a species. It was and remains a contender. And, to the point, its authors determined (certainly influenced by not being or as SoTA aware as academic CS lights) that a compelling 80% solution with a [simple] versatile conceptual model can work and it has. Same story goes for Go the language. Of course it is like PLT reto with bolt-ons, but like it or not, it is a viable approach to building software and systems.