3 ms·

These days mere mortals have access to enough information about brokenness of operating systems, filesystems, disks, raids to make better decisions, than sqlite

These days mere mortals have access to enough information about brokenness of operating systems, filesystems, disks, raids to make better decisions, than sqlite ever did. I even suggest to go purely log structured and completely get rid of random writes to save people some time. Also these days I disagree about perfect APIs, they are not realistically achievable. It's a mistake to think there will be no mistakes. For example, another common mistake people make is in event loops, when they assume kernels are going to report descriptors as readable or writable correctly all the time for correct descriptors. These are all mistakes that come from the assumption that other people don't make mistakes, instead of treating lower levels as black boxes and not relying on promises. So, while it sounds like a nice idea to have yet another API to fix broken promises, it's not. A good library can fix broken promises. A bad library still won't realize it's relying on broken promises.

josephg 9y ago
I recommend log structured too, although probably for different reasons ( https://twitter.com/josephgentle/status/978616782607998977 https://twitter.com/josephgentle/status/978616782607998977 ) > It's a mistake to think there will be no mistakes. Its more programming philosophy at this point, but I disagree with this. There's lots of assumptions we 100% rely on for modern software. Things like ADD / MUL working correctly in our CPUs, TCP delivering packets in the order they were sent, correctness in our programming languages, the correctness of cryptographic primitives and the safety of operations like constant-time comparisons. Database transactions. Malloc. GC. Etc etc. Actually I would say that "it works all the time" is the norm in computing. Its so pervasive and great that when things work all the time we don't even need to think about them or understand them at all. Not like "it works almost all the time". Things that only work most of the time we have to think about constantly. "Does my page still render correctly in all browsers?", etc. Its easy to find examples of API promises being violated because these problems take up all our time. But this is no way to do engineering. In aggregate its almost always far slower than just spending the time to fix the bugs themselves. And fixing the actual issue will usually take less code, and run faster than making a pile of abstractions around the bug. An example of this: A few years ago I worked at a startup where we had a search indexer. The indexer wasn't architected well, and it kept having issues and leaving stale data around. So we kept needing to invest engineering time into fixing small search issues. Patching around it was a constant low level time sink for years. A few years later I was asked to implement search at a different company. I used the lessons I learned at the startup to do it right this time. And the code I wrote has been almost untouched to this day. Now, the interesting part is that at both companies management thought the amount of time we were allocating toward search seemed normal. But the second approach was objectively better. At the startup it would have taken less time overall to fix the indexer's bugs (or rewrite it) than we spent patching around it and dealing with its brokenness. Which is to say, sometimes better is better.
- zzzcpan 9y ago
  This is some kind of anti-resilience philosophy. If you assume things work correctly all the time, you are going to have disasters and downtime, long debugging sessions and hard to find bugs when things break, because the system is not architected to survive incorrect assumptions.
  - josephg 9y ago
    How resilient is your software against, say, malloc returning invalid ranges? Against compiler bugs? I’m saying that when there are compiler bugs the right solution isn’t to blame the user for not having resilient enough code. The right answer is to fix the bug in the compiler. Likewise when basically everybody uses your API incorrectly, don't blame all the users. Instead fix the actual problem in the kernel. Or if you want, consider it as simple math - we get better returns on time spent solving the problem in the kernel than we do solving the problem in user space of every application. I've heard some facebook devs talk about the concept of DX: developer experience. DX is something we should be optimizing for when writing APIs. Currently the DX of writing correct file handling code is awful. The functions don't do what you want, they're implemented inconsistently and they're poorly documented. If the only place you're allowed to write code is your application, then you're right. Make it as robust as you can. But we're programmers and linux is opensource. We should just fix the problem.

josephg 9y ago

I recommend log structured too, although probably for different reasons ( https://twitter.com/josephgentle/status/978616782607998977 https://twitter.com/josephgentle/status/978616782607998977 ) > It's a mistake to think there will be no mistakes. Its more programming philosophy at this point, but I disagree with this. There's lots of assumptions we 100% rely on for modern software. Things like ADD / MUL working correctly in our CPUs, TCP delivering packets in the order they were sent, correctness in our programming languages, the correctness of cryptographic primitives and the safety of operations like constant-time comparisons. Database transactions. Malloc. GC. Etc etc. Actually I would say that "it works all the time" is the norm in computing. Its so pervasive and great that when things work all the time we don't even need to think about them or understand them at all. Not like "it works almost all the time". Things that only work most of the time we have to think about constantly. "Does my page still render correctly in all browsers?", etc. Its easy to find examples of API promises being violated because these problems take up all our time. But this is no way to do engineering. In aggregate its almost always far slower than just spending the time to fix the bugs themselves. And fixing the actual issue will usually take less code, and run faster than making a pile of abstractions around the bug. An example of this: A few years ago I worked at a startup where we had a search indexer. The indexer wasn't architected well, and it kept having issues and leaving stale data around. So we kept needing to invest engineering time into fixing small search issues. Patching around it was a constant low level time sink for years. A few years later I was asked to implement search at a different company. I used the lessons I learned at the startup to do it right this time. And the code I wrote has been almost untouched to this day. Now, the interesting part is that at both companies management thought the amount of time we were allocating toward search seemed normal. But the second approach was objectively better. At the startup it would have taken less time overall to fix the indexer's bugs (or rewrite it) than we spent patching around it and dealing with its brokenness. Which is to say, sometimes better is better.

zzzcpan 9y ago
This is some kind of anti-resilience philosophy. If you assume things work correctly all the time, you are going to have disasters and downtime, long debugging sessions and hard to find bugs when things break, because the system is not architected to survive incorrect assumptions.
- josephg 9y ago
  How resilient is your software against, say, malloc returning invalid ranges? Against compiler bugs? I’m saying that when there are compiler bugs the right solution isn’t to blame the user for not having resilient enough code. The right answer is to fix the bug in the compiler. Likewise when basically everybody uses your API incorrectly, don't blame all the users. Instead fix the actual problem in the kernel. Or if you want, consider it as simple math - we get better returns on time spent solving the problem in the kernel than we do solving the problem in user space of every application. I've heard some facebook devs talk about the concept of DX: developer experience. DX is something we should be optimizing for when writing APIs. Currently the DX of writing correct file handling code is awful. The functions don't do what you want, they're implemented inconsistently and they're poorly documented. If the only place you're allowed to write code is your application, then you're right. Make it as robust as you can. But we're programmers and linux is opensource. We should just fix the problem.