4 ms·

There was once a programmer who was attached to the court of the warlord of Wu. The warlord asked the programmer: "Which is easier to design: an accounting pack

There was once a programmer who was attached to the court of the warlord of Wu. The warlord asked the programmer: "Which is easier to design: an accounting package or an operating system?" "An operating system," replied the programmer. The warlord uttered an exclamation of disbelief. "Surely an accounting package is trivial next to the complexity of an operating system," he said. "Not so," said the programmer, "When designing an accounting package, the programmer operates as a mediator between people having different ideas: how it must operate, how its reports must appear, and how it must conform to the tax laws. By contrast, an operating system is not limited by outside appearances. When designing an operating system, the programmer seeks the simplest harmony between machine and ideas. This is why an operating system is easier to design." The warlord of Wu nodded and smiled. "That is all good and well, but which is easier to debug?" The programmer made no reply. – The Tao of Programming, 3.3

jasode 5y ago
>, an operating system is not limited by outside appearances. When designing an operating system, the programmer seeks the simplest harmony between machine and ideas. This is why an operating system is easier to design." I think I understand the intuition behind that... in other words... coding an os kernel seems to have less entropy, less degrees-of-freedom, less subjectivity ... than frontend programming like painting GUI pixels and Javascript-framework-of-the-month. But there's a lot of subjectivity and philosophical debates about low-level os design: - the famous "Worse is Better" essay tries to explain difference between "New Jersey approach" (Bell Labs UNIX) vs MIT approach of error handling in a system routine [1] - famous debate between Linus Torvalds and Andrew S. Tanenbaum about microkernels vs monolithic kernels [2] - David Cutler (designer of VMS & Windows NT) criticizing UNIX i/o architecture[3] - even lower level than o/s is cpu design where some criticize RISC-V not having arithmetic overflow traps in the minimum base specification. And in the 1990s, the RISC (MIPS philosophy) vs CISC (Intel philosophy) was a big debate. [1] https://dreamsongs.com/RiseOfWorseIsBetter.html https://dreamsongs.com/RiseOfWorseIsBetter.html [2] https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_debate https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_deb... [3] https://retrocomputing.stackexchange.com/questions/14150/how-should-we-interpret-dave-cutlers-criticism-of-unix/14151 https://retrocomputing.stackexchange.com/questions/14150/how...
- yup00 5y ago
  Exactly. Dig around in C land and you’ll find 100s of opinions, even more libs and toolkits that came and went out of fashion. Web stacks are “computing” to industry right now. In the 80s and 90s it was OS and database. If low-level had the old economic attention, we’d see the same activity and mess as we did in the 80s and 90s. Everyone has a compiler to tell you about, and a build system DSL that’s just right for your problem! But big corp largely controls that and so a new layer of abstraction was added via web, and we’re seeing a shift now to less UI, and machine driven decision making that just gives us the next step in the recipe. Frankly I don’t mind technology for navigating human society; buying stuff and literal navigation. I still unplug with musical instruments and the forest. The addictive applications we’ve built in technology; games, social and multimedia, got really banal for me a long time ago. If I hear things like “Itsa me, Mario” or something about Halo I recoil at the cringe. I guess I don’t want my psychedelic noise wrapped up in branding and consumerism.
- ekster 5y ago
  Exactly, working at a low level still means that “the programmer operates as a mediator between people having different ideas”. The different people are just hardware builders instead of library writers.
- wincy 5y ago
  TempleOS is the one pure operating system created without any debates. RIP Terry A. Davis.
  - andai 5y ago
    You mean, Terry won all of the debates ;)
  - TchoBeer 5y ago
    The only OS endorsed by the Holy C.
- lliamander 5y ago
  Perhaps another way to describe this intuition is that with operating systems, the developer is also the subject matter expert and the one setting the requirements. When you are the one setting requirements, those requirements are going to seem inherently less arbitrary than requirements set by someone else.
ibeckermayer 5y ago
That seems pretty dumb. There aren’t competing ideas about how an operating system should work?
yosefk 5y ago
BTW it's not obvious that an OS is harder to debug. A logical error in an accounting package can probably often only be found by a checking tool that has the equivalent of all the functionality of the package under test. OS bugs are more likely to have the side effect of violating language invariants (which eg KASan, UBSan and KCSan often detect), or violating protocols (so you can stress-test eg a TCP implementation and detect the bug), or it can violate API invariants (so you can use some API-level stress test like stress-ng to detect the bug.) All of these tools are much less complex than the software under test. I think the warlord of Wu made the comment about debugging before massive automated testing, compiler instrumentation etc were a thing. And I think a similar argument can be made wrt software and hardware-level visibility/tracing mechanisms - again an OS will end up being easier than higher-level software given a good investment in tooling.
username90 5y ago
The accounting package is much easier to design if you have the same level of requirements for them. If the goal is to make a toy product then making an accounting package is trivial while a OS is not. If the goal is to make a product that will get a lot of users then making an OS is almost impossible while plenty of people sell accounting packages. Low level is only easier than high level if you don't intend to sell the low level program but do intend to sell the high level program.
- blake1 5y ago
  Requirements for an accounting system? That’d be hilarious if I wasn’t so traumatized by past experience. Seriously, the tensor product of jurisdictions, clients, strategies, and the various preferences of your rotating bosses—it’s a cascade of requirements that you could never satisfy.
  - username90 5y ago
    Try to write a commercial OS that can compete with IOS, Windows or Linux. I doubt it is much easier, there are so many features people expect from a modern OS. The point is that when you compete with the best in the world in any area then it will be hard to win. Low level code is only easy when low level code isn't an important part of your product. For example backends to web apps, you don't write any low level code for them. The networking is handled via application server frameworks, the data storage is handled via pre packaged database programs so you don't even have to open a file etc. It isn't low level, it is just high level glue code between different libraries. This works just fine since you aren't trying to compete using low level code, so using off the shelf products without almost any code written by you is fine. But when your product requires you to compete using low level code then it is really hard.
robertwt7 5y ago
hahah this is so good. you made my day

jasode 5y ago

>, an operating system is not limited by outside appearances. When designing an operating system, the programmer seeks the simplest harmony between machine and ideas. This is why an operating system is easier to design." I think I understand the intuition behind that... in other words... coding an os kernel seems to have less entropy, less degrees-of-freedom, less subjectivity ... than frontend programming like painting GUI pixels and Javascript-framework-of-the-month. But there's a lot of subjectivity and philosophical debates about low-level os design: - the famous "Worse is Better" essay tries to explain difference between "New Jersey approach" (Bell Labs UNIX) vs MIT approach of error handling in a system routine [1] - famous debate between Linus Torvalds and Andrew S. Tanenbaum about microkernels vs monolithic kernels [2] - David Cutler (designer of VMS & Windows NT) criticizing UNIX i/o architecture[3] - even lower level than o/s is cpu design where some criticize RISC-V not having arithmetic overflow traps in the minimum base specification. And in the 1990s, the RISC (MIPS philosophy) vs CISC (Intel philosophy) was a big debate. [1] https://dreamsongs.com/RiseOfWorseIsBetter.html https://dreamsongs.com/RiseOfWorseIsBetter.html [2] https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_debate https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_deb... [3] https://retrocomputing.stackexchange.com/questions/14150/how-should-we-interpret-dave-cutlers-criticism-of-unix/14151 https://retrocomputing.stackexchange.com/questions/14150/how...

yup00 5y ago
Exactly. Dig around in C land and you’ll find 100s of opinions, even more libs and toolkits that came and went out of fashion. Web stacks are “computing” to industry right now. In the 80s and 90s it was OS and database. If low-level had the old economic attention, we’d see the same activity and mess as we did in the 80s and 90s. Everyone has a compiler to tell you about, and a build system DSL that’s just right for your problem! But big corp largely controls that and so a new layer of abstraction was added via web, and we’re seeing a shift now to less UI, and machine driven decision making that just gives us the next step in the recipe. Frankly I don’t mind technology for navigating human society; buying stuff and literal navigation. I still unplug with musical instruments and the forest. The addictive applications we’ve built in technology; games, social and multimedia, got really banal for me a long time ago. If I hear things like “Itsa me, Mario” or something about Halo I recoil at the cringe. I guess I don’t want my psychedelic noise wrapped up in branding and consumerism.
ekster 5y ago
Exactly, working at a low level still means that “the programmer operates as a mediator between people having different ideas”. The different people are just hardware builders instead of library writers.
wincy 5y ago
TempleOS is the one pure operating system created without any debates. RIP Terry A. Davis.
- andai 5y ago
  You mean, Terry won all of the debates ;)
- TchoBeer 5y ago
  The only OS endorsed by the Holy C.
lliamander 5y ago
Perhaps another way to describe this intuition is that with operating systems, the developer is also the subject matter expert and the one setting the requirements. When you are the one setting requirements, those requirements are going to seem inherently less arbitrary than requirements set by someone else.

ibeckermayer 5y ago

That seems pretty dumb. There aren’t competing ideas about how an operating system should work?

yosefk 5y ago

BTW it's not obvious that an OS is harder to debug. A logical error in an accounting package can probably often only be found by a checking tool that has the equivalent of all the functionality of the package under test. OS bugs are more likely to have the side effect of violating language invariants (which eg KASan, UBSan and KCSan often detect), or violating protocols (so you can stress-test eg a TCP implementation and detect the bug), or it can violate API invariants (so you can use some API-level stress test like stress-ng to detect the bug.) All of these tools are much less complex than the software under test. I think the warlord of Wu made the comment about debugging before massive automated testing, compiler instrumentation etc were a thing. And I think a similar argument can be made wrt software and hardware-level visibility/tracing mechanisms - again an OS will end up being easier than higher-level software given a good investment in tooling.

username90 5y ago

The accounting package is much easier to design if you have the same level of requirements for them. If the goal is to make a toy product then making an accounting package is trivial while a OS is not. If the goal is to make a product that will get a lot of users then making an OS is almost impossible while plenty of people sell accounting packages. Low level is only easier than high level if you don't intend to sell the low level program but do intend to sell the high level program.

blake1 5y ago
Requirements for an accounting system? That’d be hilarious if I wasn’t so traumatized by past experience. Seriously, the tensor product of jurisdictions, clients, strategies, and the various preferences of your rotating bosses—it’s a cascade of requirements that you could never satisfy.
- username90 5y ago
  Try to write a commercial OS that can compete with IOS, Windows or Linux. I doubt it is much easier, there are so many features people expect from a modern OS. The point is that when you compete with the best in the world in any area then it will be hard to win. Low level code is only easy when low level code isn't an important part of your product. For example backends to web apps, you don't write any low level code for them. The networking is handled via application server frameworks, the data storage is handled via pre packaged database programs so you don't even have to open a file etc. It isn't low level, it is just high level glue code between different libraries. This works just fine since you aren't trying to compete using low level code, so using off the shelf products without almost any code written by you is fine. But when your product requires you to compete using low level code then it is really hard.

robertwt7 5y ago

hahah this is so good. you made my day