Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Filesystem devs should aim to make “badly written” app code “just work” (2009)

lwn.net

Post reply on HN
Print view View original

11–20 of 117 posts

Re: Filesystem devs should aim to make “badly written” app code “just work” (2009)

#11

Post by slimsag »

sophiebits wrote: post #9
slimsag wrote: post #3

Suggestion: I think the title should be: > Linus: Theory and practice sometimes clash. And when that happens, theory loses. Every single time. His point seems to be more about accepting reality and allowing the practice (which in this case is theoretically "badly written" code) to "just work". As the title stands now: > Linus: People should aim to make "badly written" code "just work" One might incorrectly assume Lin…

Or perhaps “Filesystems should aim…”. Which is what he actually seemed to mean.

Yeah, that seems a bit more precise!

Re: Filesystem devs should aim to make “badly written” app code “just work” (2009)

#12

Post by pcr910303 »

pdonis wrote: post #8

The thread title omits a crucial word: "Filesystem" (as in "filesystem people", not just "people"). The point he is making is that filesystems are supposed to be utterly reliable; applications should not have to take extreme precautions to avoid having the filesystem lose their data. And the fact that practically nobody actually takes any precautions, let alone extreme ones, is strong evidence that programmers do in…

I personally thought that this opinion is applicable to not only file systems but all ‘base’ systems that can be built upon. Hence the omission of the ‘filesystem’ word.

But if most people think that this doesn’t apply outside of FS, I have the will to change the title :-)

Re: Filesystem devs should aim to make “badly written” app code “just work” (2009)

#13

Post by reitzensteinm »

pcr910303 wrote: post #12
pdonis wrote: post #8

The thread title omits a crucial word: "Filesystem" (as in "filesystem people", not just "people"). The point he is making is that filesystems are supposed to be utterly reliable; applications should not have to take extreme precautions to avoid having the filesystem lose their data. And the fact that practically nobody actually takes any precautions, let alone extreme ones, is strong evidence that programmers do in…

I personally thought that this opinion is applicable to not only file systems but all ‘base’ systems that can be built upon. Hence the omission of the ‘filesystem’ word. But if most people think that this doesn’t apply outside of FS, I have the will to change the title :-)

It applies broadly to people building APIs, but your title reads as though Linus is giving general coding advice, saying not to be fussy about code quality but focus on correctness. At least one comment here is replying to that notion.

Re: Filesystem devs should aim to make “badly written” app code “just work” (2009)

#14

Post by perl4ever »

mehrdadn wrote: post #4

Quite a bizarre read considering Linux's decision to e.g. overcommit memory makes 100% correctly written code break nondeterministically...

It seems to me that a basic requirement for not being an idiot is that you recognize hard problems as being hard, and I see a lot of supposedly smart people declaring hard problems are easy because they're just ignoring tradeoffs or aspects of an approach that undermine it.

I'd think "everybody" knows, certainly I would expect Linus to know, about Postel's law and the subtle ways it ends up causing problems. Whenever you make things easy or difficult, you shape the evolution of how people do those things. There's no simple universal answer to "do we make things easy or difficult". Or "do we blame the user or the toolmaker?"

I don't really understand the psychology of going around arguing one side of an insoluble problem, observing that others are totally convinced of the other side, and occasionally flipping sides, but never acknowledging the meta-problem of integrating both or deciding when to apply each.

Re: Filesystem devs should aim to make “badly written” app code “just work” (2009)

#18

Post by peterwwillis »

justinator wrote: post #2

Told you: Perl is built by the gods.

Perl has subtle complexity just like everything else. But it also has taint mode, which depending on the way you squint is either a great example of "security that just works", or a great example of "you must use X method to get good security".

Re: Filesystem devs should aim to make “badly written” app code “just work” (2009)

#20

Post by RcouF1uZ4gsC »

> The undeniable FACT that people don't tend to check errors from close() should, for example, mean that delayed allocation must still track disk full conditions, for example. If your filesystem returns ENOSPC at close() rather than at write(), you just lost error coverage for disk full cases from 90% of all apps. It's that simple.

Most programmers abstraction of a computer system is synchronous and consistent. If you make the simple synchronous cases do the wrong thing, like write returning success on disk full when a write did not happen, you are going to break people’s code.

This also explains why when you when you choose a database, a relational DB with strong consistency and linearizability should be your default. Going for eventually consistent in the database layer and expecting the application logic to deal with it will lead to grief in many, many cases.

Post reply on HN