11–20 of 170 posts
I think mindset plays a role as well. Back in the day, there was a restraint on adding features, at least when they would make the logic more complicated for only a tiny or imagined benefit. Part of that was memory/storage limitations. But I think the pursuit of an abstract idea of elegance was equally important. After all, these systems were primarily written for other computer people. This idea is completely gone f…
It was essentially a "time-sharing" system that multiplexes interactive sessions of multiple users on teletype terminals. The "shell" handles such a session by waiting for user input on the terminal, interpreting it and starting external programs as a sub-hierarchy of user processes. On a teletype terminal, you couldn't even have a cursor-oriented editor like vi, but had to rely on line-oriented editors like ed and s…
In a way it became the complete opposite of how it started. At first one OS for many users, ea with many processes. Now, with containers, micro services etc. we have an OS per service/process. Still the original abstractions work surprisingly well though makes it me wonder how a complete redesign of would look like aimed at modern usage.
Answer: smaller target to cover! Modern Linux has most code in device drivers to support so many different devices. Then, it supports many targets for other subsystems, like file systems. The original Unix provided one implementation for each subsystem. They relentlessly simplified the problem they were solving to make it doable.
* unit testing
* framework boiler plate
* testing pragmas
* mockups
It was essentially a "time-sharing" system that multiplexes interactive sessions of multiple users on teletype terminals. The "shell" handles such a session by waiting for user input on the terminal, interpreting it and starting external programs as a sub-hierarchy of user processes. On a teletype terminal, you couldn't even have a cursor-oriented editor like vi, but had to rely on line-oriented editors like ed and s…
In a way it became the complete opposite of how it started. At first one OS for many users, ea with many processes. Now, with containers, micro services etc. we have an OS per service/process. Still the original abstractions work surprisingly well though makes it me wonder how a complete redesign of would look like aimed at modern usage.
Answer: smaller target to cover! Modern Linux has most code in device drivers to support so many different devices. Then, it supports many targets for other subsystems, like file systems. The original Unix provided one implementation for each subsystem. They relentlessly simplified the problem they were solving to make it doable.
With virtual memory and demand paging, memory management (done efficiently) becomes a much harder problem, too.
I think mindset plays a role as well. Back in the day, there was a restraint on adding features, at least when they would make the logic more complicated for only a tiny or imagined benefit. Part of that was memory/storage limitations. But I think the pursuit of an abstract idea of elegance was equally important. After all, these systems were primarily written for other computer people. This idea is completely gone f…
Features are, like it or no, where the value is.
Earlier quoted context omitted.
In a way it became the complete opposite of how it started. At first one OS for many users, ea with many processes. Now, with containers, micro services etc. we have an OS per service/process. Still the original abstractions work surprisingly well though makes it me wonder how a complete redesign of would look like aimed at modern usage.
But the question is why did we arrive at containers and one OS per "microservice"? Has memory-to-IO bandwidth, scalability requirements, or whatever really changed (like in orders of magnitude) to warrant always-async programming models, even though these measurably destroy process isolation and worsen developer efficiency? After almost 50 years of progress? Or is it the case that containers are more convenient for c…
Earlier quoted context omitted.
Features are, like it or no, where the value is.
Especially the features we don't consider. Try replacing your "ls" command with the one found in the original Unix, sure it's 90% smaller, or more, but I guarantee that it doesn't do colors.
I think mindset plays a role as well. Back in the day, there was a restraint on adding features, at least when they would make the logic more complicated for only a tiny or imagined benefit. Part of that was memory/storage limitations. But I think the pursuit of an abstract idea of elegance was equally important. After all, these systems were primarily written for other computer people. This idea is completely gone f…
Features are, like it or no, where the value is.
I see the other way around. Additional features are people's special cases and hobby-horses, and unlikely to be used by other people. BUT each new feature/interface/etc adds the potential for (and really of) more bugs.
Perhaps it should be "features are where the security holes are"? :)