> a 1950s workaround for not having enough primary storage to keep all programs and data live at all times Even today you don't have enough primary storage to

> a 1950s workaround for not having enough primary storage to keep all programs and data live at all times Even today you don't have enough primary storage to keep your data. And even then it would require a structure when data outlives the process / application. Most times there are no best solution, but only tradeoffs. Anyone who has done a bit of systems work knows this. And Hierarchical file system was a Ok-ish trade-off to make. Perfect is enemy of good. > MASSIVE mistake: individual resources are neither typed nor tagged. It comes with its own set of tradeoffs. I am a huge proponent of static typing when it comes to PLs. But in a system where multiple actors operate on shared resources, it is easy to get illusioned into a false sense of correctness. Also it imposes some extra complexity in the programming model. I am no experienced systems engineer. But someone here can address it better. > .... entertain the cowboys who built and used it .... You are going beyond HN standards to justify your anger against a particular methodology or people that embrace it in programming. The universally accepted point is that Unix succeeded due to political factors (low cost and easy modification compared to proprietary counterparts), simplicity of the API, and being arguably better than others despite lacking some features people love to lament these days. But in many cases, that simplicity is a desirable thing to have. It is nice to objectively point out faults in systems. But what you did is totally dismissing some people's contributions. It is easy to see some hyped thing and think that's the Next Big Thing(TM) after reading two fanboys preaching on Reddit, while being totally ignorant of tradeoffs.