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

61–70 of 117 posts

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

#61

Post by eyelidlessness »

zer00eyz wrote: post #56
eyelidlessness wrote: post #50

Earlier quoted context omitted.

I agree completely don't do magic, keep it clean and simple. I disagree with leave the thing you replaced commented. It's not just that you can find it "in the repo", it's that things drift over time. Prose comments have that reputation but code in comments that isn't being maintained drift even further. No one even has any intention of maintaining commented code except if it happens to hit find and replace, and even…

> code in comments that isn't being maintained drift even further. This is also true of "its in the repo" and that doesn't get hit by "find and replace". I don't think it should be done for EVERY case, rather the cases where clarity is replaced with something that is ambiguous but meets another need. Performance hacks are notorious for being "ugly" and "magical" and having a readable companion piece would make sense.…

To add to my earlier response: if I needed to achieve the performance critical cleverness required solution and felt it needed a human readable code sidekick, I would include both as real running code alongside each other, both of which running the same set of tests, and both of which required to be run by whatever CI/automated tests are used by the project. Comments are for humans to read, not machines.

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

#62

Post by [deleted] »

diminoten wrote: post #37
capdeck wrote: post #10

Is there a point though, when badly written code becomes so hard to maintain and improve, that people would just avoid doing that altogether? The reason "badly written" works for Open Source is that if code is useful - there will be someone in the future who will refactor it. In proprietary setting that only happens when the fate of the company itself (or a large chunk of the business) is at stake. Otherwise stagnati…

It's easy to pretend that "badly written" code is intentional or desirable, because then when we write it, we can excuse ourselves by saying, "BUT IT WORKS!" That's why this idea is popular, and your comment is controversial. You're taking away a crutch that many of our peers cling desperately to as a way to justify their shortcuts and poor decision making.

[deleted]

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

#63

Post by ianai »

Animats wrote: post #59

I'd argue that UNIX-type file systems should offer several types of files: * Unit files. When you create a file and write it, it's not visible for other opens until you close it. If you open a file with O_CREAT|O_WRONLY|O_TRUNC, you create a new file, which replaces the old one on close. In the event of a program or system crash, or exiting via "abort" without closing first, the old file remains. So there's always on…

How about sandboxed files? Ie can be assigned to a process - full acl per process/application binary. Maybe even checksum the binary before loading to ram and granting access.

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

#64

Post by Lammy »

ianai wrote: post #60

Slightly OT: is there any new emerging tech for Linux file systems that aren’t ext4/xfs/zfs? I was surprised the other day by those being the options for / on centos.

Btrfs was included as experimental in CentOS 6 and 7, but removed for CentOS 8.

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

#66

Post by [deleted] »

dooglius wrote: post #44
peterwwillis wrote: post #25

Earlier quoted context omitted.

I think the difference between "don't implement workarounds" and "use overcommit" is that the kernel can try to be clever, but userland should not have to be clever. The kernel is supposed to just make things work for userland. I think that's why overcommit exists. It's generally not easy to re-design all userland applications to deal with difficult memory management problems in a complex system, but it is easy to ju…

The problem is that userland has to be really clever because of overcommit... that's what the whole thread is about! The reason people want complex things like fsync and barriers is that the OOM killer has normalized the bad idea that applications should behave well when suddenly SIGKILL'd, and this is way harder than looking at the return value from malloc. When a program I write has elevated permissions, which fort…

[deleted]

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

#67

Post by newnewpdro »

I feel like Linus is basically just arguing in favor of the principle of least surprise.

There are definitely some serious pitfalls when it comes to unix file io, just look at for how long we lived with postgres and its broken assumptions surrounding fsync behavior on linux.

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

#68

Post by rodgerd »

newnewpdro wrote: post #67

I feel like Linus is basically just arguing in favor of the principle of least surprise. There are definitely some serious pitfalls when it comes to unix file io, just look at for how long we lived with postgres and its broken assumptions surrounding fsync behavior on linux.

> how long we lived with postgres and its broken assumptions surrounding fsync behavior on linux.

You mean its assumption that the API wasn't lying about the integrity of the data it claimed to be writing? Very broken indeed.

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

#69

Post by wmf »

ianai wrote: post #60

Slightly OT: is there any new emerging tech for Linux file systems that aren’t ext4/xfs/zfs? I was surprised the other day by those being the options for / on centos.

bcachefs looks pretty cool but who knows how long it will take to get upstream.

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

#70

Post by deeblering4 »

jiggawatts wrote: post #43
bvinc wrote: post #29

I think he's got a point. As a developer I find myself in a different scenario. I'm usually trying to find out what exactly the 100% guaranteed way to do something is. Instead, I find incomplete documentation and different people with different opinions on what the guarantees are, and most people writing bad code that they assume will usually work. Just modifying a file in an atomic way requires a complicated dance o…

I do, but it's not a popular opinion. POSIX, and by extension, the classic 1960s-1980s era UNIX way of doing things just needs die a long overdue death. This stuff was designed at a time when every CPU instruction mattered, everything was optimised to death for frugality, and commands were abbreviated from "copy" to "cp" because ermahgerd two bytes is a huge saving! That mentality got us Y2K. This is an era where lat…

With respect that wasn’t solely a design mentality. Resource limitations were a factor as well.
Post reply on HN