Really nicely written and quite thought-provoking. I think about when I die, will anyone be able to use or maintain any of the software I've written? Updates and patches are something so entwined with software that I doubt much of my code would be worth using if it suddenly froze.
It puts a beautiful spotlight on OSS communities and what they do to keep software alive through refactoring, iteration, patching. Also, on well-written documentation— perhaps that's even more important than the code for longterm maintenence and value. A good thesis that encourages someone to write it again, and better?
That's true. Even then, though, you're dealing with backwards-compatibility support as the system updates. A compiled binary might run well for the systems it was compiled for, but what about longer timelines (a decade)? Will the newest system be able to easily run that compiled binary? Not always... and there's always the possibility it might include vulnerabilities that weren't discovered until later.
I was reading about terminal text editors (em, en, vi, vim, neovim, etc.), and it's interesting how some of the software that "lasts" is more like Theseus' Ship. All the original components replaced over time, but the core concepts last.
> I was reading about terminal text editors (em, en, vi, vim, neovim, etc.), and it's interesting how some of the software that "lasts" is more like Theseus' Ship. All the original components replaced over time, but the core concepts last.
There's probably a lesson about interfaces here. The thing itself is able to last and adapt if you're able to replace the components, and the components can be replaced if the interfaces between them are stable (or at least knowable, so you can change them and know what you're changing). A couple of the examples I can think of that try to do this are Linux and Clojure. Both have improved and added a ton over the years, but they've always focused on maintaining stable interfaces.
The problem of what happens when the author is unable to keep working on the source code has come up a LOT in the .NET space. One author (of both books and OSS) has even written up [0] the pro-active steps he's taken for when "The Emnuggerance" (as Pratchett called it) takes his abilities.
I've been using dotter for 5+ years and it's been an amazing tool. Doesn't go all in like NixOS, but lets you get close to that functionality by allowing templating to reuse a single dotfile repo across different systems. I also like how you can easily conditionally select configurations and scripts to load depending on environment.
I went from using Windows 95 as a kid to macOS as a professional software engineer. Now, and in between, I've explored a number of unique Linux distros, desktop environments, and window managers. I wanted to share my experience and my love of all things Linux.
LazyVim wasn't even around when I first tried Neovim. Knowing what I know now, this would definitely be my distro of choice. The maintainer, Folke, is an incredible programmer and has made many of the most popular plugins used by the community.
I started from Vim and ended up migrating my dotfiles to Lua. I was really glad when I bit the bullet because I was able to keep most of my favorite functionality but start using more of the modern Lua-base plugins. Lazy.nvim is a really great package manager— super simple.
I ended up stealing some LSP config from AstroNvim or another Nvim "distro". I've never tried committing to one of those prebuilds though. I was always hacking at my own configs. I do like to skim some of the code though because they are generally implementing much better design patterns. I'm sure that the community will do a better job than me with Lua 9/10...
The obsessive dotfile management does help to give you a deep understanding of your editor though— I will say that.
reply