6 ms·
Making a transparent distributed operating system in the mid-late 80s and 90s as a Unix replacement was total over-engineering and over-complexity that never ha
by throwawaylinux 4y ago
Making a transparent distributed operating system in the mid-late 80s and 90s as a Unix replacement was total over-engineering and over-complexity that never had any real demand or advantage. Therefore it is a great example, you just refuse to acknowledge that. Comparing it with actual real world operating systems of the time is misleading and does not refute the second system syndrome, because a lot of complexity in those came about from making them work in in real systems which Plan9 did not need. The fact is there was significant effort and complexity put into making it distributed, and that would not be required if it did not have this unnecessary capability.
You're grasping at straws a bit here, I would have expected you to defend your argument a bit better. First you try to justify the distributed capabilities of Plan 9 by saying it's now used in kubernetes 30 years on, and when I point out that's not transparent at the OS layer then you just change to not accepting it is a complexity at all.
Anyway the argument is pointless to continue. Plan 9 was a commercial failure and brought little new to systems design. It was a warmed over Unix with over-engineered distributed systems concepts that had been built up since the 50s and 60s and weren't new. At least contemporaries like OS/400 were attempting to bring something new even if they did not ultimately succeed (although OS/400 itself was far more of a commercial success than Plan9 of course).
- lproven 4y agoYour replies are increasingly baffling to me. I don't think you understand what I am saying at all, nor do you seem to understand the meanings of the phrases you are throwing about. > Making a transparent distributed OS [...] was total over-engineering That is not what "over-engineering" means. > over-complexity It is LESS COMPLEX. This is not a tricky or difficult concept. > Therefore it is a great example, you just refuse to acknowledge that. It's not a good example because you don't understand the term you are trying to use. > First you try to justify the distributed capabilities of Plan 9 by saying it's now used in kubernetes 30 years on, No, I did not say that, or mean that, or imply that. You seem to be having real problems with comprehension here. > when I point out that's not transparent at the OS layer You did nt point that out or even attempt to, but you did not understand what I wrote, so :shrug:. > Plan 9 was a commercial failure Agreed. > and brought little new to systems design. Totally disagree. > It was a warmed over Unix with over-engineered distributed systems concepts that had been built up since the 50s and 60s and weren't new. Now I think you don't understand Plan 9 either. I would love to see some citations of the "existing distributed systems concepts" you claim. Agreed re OS/400, though.
- throwawaylinux 4y agoI think you just weirdly don't know what over engineering means. It absolutely means adding things to a system that aren't necesary, even if you personally think they are simple or elegant or great or should be included. That's half the reason why over-engineering happens in the first place is because engineers let their desires or passion override rational analysis. That's really one of the primary psychological drivers behind second system syndrome actually, is that designers will latch on to their pet ideas or theories in the mistaken belief that the success of their first product validated them. Everything is a file is a great example. Everything is a file is not what made unix so successful, and yet they over engineered all their network APIs into the file and mount interfaces unnecessarily. It's not that it wasn't neat or a fun toy, but it's just an over engineering of an already solved problem in an incompatible way that offered no compelling real world advantage. > It is LESS COMPLEX. This is not a tricky or difficult concept. It was MORE COMPLEX than it could have been. Also not tricky or difficult. > No, I did not say that, or mean that, or imply that. You definitely did. > Totally disagree. What useful things did it bring to systems design? And I gave some examples of existing distributed systems. Lots of material on those you can read up on if you weren't aware of them.
- lproven 4y agoNo. No to every line of this. You cannot simply re-interpret existing terms as you wish. You do not get to saty "well clearly bigger can really mean smaller, and more complex can sometimes mean less complex, and therefore this smaller thing is therefore an example of how things get bigger over time." The statement is ridiculous and your attemps to defend it are just getting increasingly absurd the more you flail around angrily trying to make your meaning fit. When Lewis Carroll put these words in his character's mouth, he was mocking what you are doing: “When I use a word,’ Humpty Dumpty said in rather a scornful tone, ‘it means just what I choose it to mean — neither more nor less.’ ’The question is,’ said Alice, ‘whether you can make words mean so many different things.’ ’The question is,’ said Humpty Dumpty, ‘which is to be master — that’s all.” https://www.goodreads.com/quotes/12608-when-i-use-a-word-humpty-dumpty-said-in-rather https://www.goodreads.com/quotes/12608-when-i-use-a-word-hum...