I might be able in the future to get the tiger I want, without drawing it myself. There are some famous painters who create works solely in their name but have apprentice artists do the actual painting. Not entirely unlike creative directors in general, I suppose.
I think it's the exact opposite of what you're saying. The maintainers sound like they're only considering the technical cost (and judging it not worth it) instead of factoring in the political consequences of keeping the same naming. I actually really respect those who value the technical over the political, but in a large-scale, public-facing project, some politics must be played.
It seems to me like you're viewing the playing of politics as a no-brainer, which is a very different mindset from a Linux contributor. I don't think people get into kernel maintenance to play politics.
The ones playing political games dressing them up as technical ones are the worst:
“My approach is technically correct and I won’t change it even though it causes issues down the line”. I’ve seen this a lot in the Gnome/Wayland world.
> I don't think people get into kernel maintenance to play politics.
I’m not a kernel developer and the projects I’ve worked on haven’t even been that big, but even there it was necessary to cater to multiple stakeholders and consider multiple viewpoints. I’d go as far as saying that software development in general gets pretty political pretty quickly, as soon as you depend on somebody else’s work or somebody else depends on yours. Every decision will impact somebody and different options will do so differently - these are political considerations.
I can’t imagine this being less of an issue in the kernel.
No, I'm not saying the politics is a no brainer. I'm saying there is a logical barrier to the project succeeding, and it is the name. Other people refuse to work with it using the current name, people who would make it a much more useful product. Deciding it's not a TECHNICAL problem is an emotional decision, because you're not reframing it from what it is, a barrier to success, to something it's not, a non-issue. They're deciding not to engage with the hard problem.
I've checked out stow, chezmoi, yadm, and others over the years, but I originally started off by rolling my own dotfiles setup with a Git repo about 6 years ago: https://github.com/jaminthorns/environment
I don't really recommend it to others, since there's all these great tools that have the features you need (per-machine config, secrets, templating), but I get a deep satisfaction from the fact that I understand every part of this setup from top to bottom. It only has the functionality I need, and I know it doesn't depend on anything that might become unmaintained since it's just POSIX shell scripts.
Even still, I might eventually make the jump to something like chezmoi or nix if I'm not able to implement something I need easily, but that hasn't happened yet.
> don't really recommend it to others, since there's all these great tools that have the features you need
I thought about using any one of those tools but happily chose shell scripts and symlinks instead. It hasn't let me down in almost a decade with https://github.com/nickjj/dotfriedrice and would highly recommend this approach.
It's basically a 2,500 line shell script to fully automate setting up a system from scratch in a general purpose / opinionated but customizable way that works on Arch Linux, Debian, Ubuntu, macOS and supports WSL 2 in Windows. I have it running on multiple systems, no need to even fork it since it uses patterns suitable for making changes in git ignored files and also has a config file for certain things.
When it comes to setting up a complete desktop environment or even just terminal based tools, dotfiles IMO are more than config files. There's install scripts, packages, system level configs, running commands, OS specific differences and more. It's really nice to be able to run 1 command and have a fresh system ready to go in about 10 minutes.
Shell script is probably my favorite language at this point.
Haha, I'll elaborate on that a bit. I don't recommend rolling your own setup to most people that I encourage to version their dotfiles. The vast majority of the developers I've met don't have any type of dotfiles setup, so I wouldn't want to recommend something I know would take significantly more work or overwhelm them. If they're going from no versioning to something, that's a huge improvement, and it's nice to get a lot of the advanced features for free.
But, for the people who value the "toolbench" of their craft, investing in it over time, and having it grow with them long-term, I will absolutely proselytize the reasons I've stayed with my custom-built setup. You're clearly one of those people, thanks for sharing. :)
I moved from custom POSIX shell scripts to chezmoi due to the complexity of handling lots of random environments. It really simplified getting up and running on disparate server environments.
The last few years I've rarely had to switch machines, so maybe chezmoi is overkill now, but it works well, so I'm in no rush to simplify again just for the sake of it (and who knows if I'll need chezmoi's features for real again in the future).
This article pre-supposes that the primary way AI agents will do tasks for users will be through through usage of desktop applications instead of documented APIs. While desktop app usage could be very important during a transition period of agent-computer use, I think it makes far more sense that agents will standardize on the protocols that are already being developed, like MCP. An explicitly documented API will always be better for a machine to use than clicking around and navigating an interface for humans.
Maybe you should interrogate that temptation to reach for physical interfaces? It sounds like you're ignoring your own psychology and shaping yourself to the machines around you instead of thinking of how the machines could be shaped to you.
Not that I haven't done exactly the same thing as you, I never keep paper around and my handwriting has gotten terrible. I'm saying this to myself and others as well.
I think that's perfectly understandable. File systems require the user to remember a hierarchy in their head (even if there are tools like breadcrumbs to help you out), and many people aren't willing or aren't able to hold an arbitrarily complex structure like that in their head. A name is a flat piece of information, no extra structure to imagine.
I worked with a professor one time that used floppies for all his files (after they had been surpassed by thumbdrives) because each floppy was essentially a single folder, and he could wrap his head around that conceptually.
Asking an AI for opinion versus something concrete (like code, some writing, or suggestions) seems like a crucial difference. I've experimented with crossing that line, but I've always recognized the agency I'd be losing if I did, because it essentially requires a leap of faith, and I don't (and might never) have trust in the objectivity of LLMs.
It sounds like you made that leap of faith and regretted it, but thankfully pivoted to something grounded in reality. Thanks for sharing your experience.
