The saddest script I ever wrote

Off topic: Page starts with "snail text" logo and ends with quirky upside down link "What's snail text?". Sure, I'll bite. I press the link, and get subscription form without any explanation what I would be subscribing to. And then in bottom of page there's a second bait, "What's snail text?". What indeed. It is launching soon. And it has a twitter account. So that is known. Maybe one day we'll find out more.

Actually most problems here already described well in Docker docs:

- https://docs.docker.com/storage/bind-mounts/#configure-mount...

Due to it is being VM, contents are synced between host and VM. It takes time and damages IOPS greatly. Eg. Even running ~100MB Jar takes minutes...

Side note that vim uses `swap` files `.$FILE.swp` when you write out, it removes the original file renames the temporary one to original one. So essentially inode or reference is different thats why it triggers sync with VM.

Ed probably writes files in-place.

Docker now uses inotify equalivent (fswatch?) on macOS, which is pretty much reliable than polling. Ofc if your app did not close file with exclusive read-write-lock, docker cannot do anything about it.

> One day about a year ago, I started using ed in place of vi

This is a choice that I feel would benefit from some kind of explenation

> because I would not be thwarted by crappy software

Oh mate, I don't think that's the issue here! This is like breaking your host OS and then making it pantomime it's own replacement so you can pretend you still have a working OS!

We had something kind of similar for a large e-commerce project. Docker was loading the site super slow with a mapped drive so we had the brilliant idea to rsync the files from OSX into the container using a file watcher. This meant the page loads were faster , but it could take even longer for the watcher to diff the changes and sync them back up to the container. Pretty annoying.

At some point, the container got optimized to not need the sync anymore for acceptable load times. Nobody is sure what we changed to help that out. ️

NixOS fixes the issue the author was using docker for. systems with explicit well managed state make development much less of a hell.

I'm sure the author tried some debugging but it's a bit sad not to see any in the post, instead their workaround is simply presented.

I would assume the root of the difference in behavior comes down to calling fsync when editing files on such a mount.

In lieu of having macOS's userland source I grepped through through copies of ed's source from GNU and OpenBSD. I don't see any calls to fsync. Whereas Vim by default does. Note most instances of vi are actually a link to Vim/a minimal version of Vim. Normally I'd test this with with some quick tracing but it appears I've not configured SIP to allow DTrace on my machine and I can't be bothered to reboot right now.

Didn't follow that, but invoking csh is indeed very, very sad.

Problems like these drive me absolutely mad, but I have the nasty tendency to waste huge amounts of time trying to track down the underlying issue. Sometimes this works and I can fix the problem; other times I figure it out, learn something new, and file a bug report or write a workaround with the new knowledge, but all too often I spend hours with little to show for it, give up far later than I should have, and have the papered-over issue in the back of my mind forevermore.

This is... beautiful.

I wonder though, how different are the file edited with ed and the one edited with vi. Maybe ed fails to update the "date modified" under these conditions?