How can we conciliate malleability and some form of stability for user config and extensions?
I think #Emacs itself is the gold standard here: long deprecation periods and clear documentation. (Third-party Emacs packages are often not doing as good a job these days!)
In #Guix we’re discussing a deprecation policy to serve both as a guideline for contributors and as a “contract” with users: https://issues.guix.gnu.org/72840
The latter is important: users should know that they can trust Guix to not change overnight without prior warning, that scripts, manifests, OS configs, etc. won’t break unexpectedly.
If you’re a Guix person, now’s the time to make your voice heard!
I’m a big fan of malleable and extensible software packages à la Emacs; I think they’re the way to provide practical freedom to users, when licenses provide freedom “de jure” only.
That one can gradually discover the code and fiddle with it blurs the user/developer distinction and reduces the dependency of one group on another.
As a user, there are times when I’m in the mood for fiddling with the code I use, and others when I just want to get other things done.
I recently had my config “broken” by changes in a new version EXWM, the Emacs window manager.
It’s a situation where malleability gets in the way and could encourage some to turn to rigid solutions where they can hope to be an undisturbed “end user”, at the cost of decreased autonomy.
Which reminded me of one thing: C is a terrible language, but because it’s terrible, it has led to the development of amazing tools to work around its weaknesses.
I’m saying this because I debugged the damn thing with Valgrind + GDB (Valgrind implements the “remote” protocol of GDB so you can GDB into a process running under Valgrind), an impressive combo.
Starting from a few days ago, Software Heritage records nar SHA256 hashes of directories, meaning that #Guix can now query content by hash without further ado: https://issues.guix.gnu.org/68741
That’s a great step forward, fixing an impedance mismatch between Guix and SWH.
@donkeyblam The “small package” thing is nice in a way (lowers barrier to entry, facilitates code reuse), but it also leads to fragmentation and encourages “developer selfishness”: you pick what you need without regard for the bigger picture.
It’s this approach that led to the ‘left-pad’ catastrophe in npm.
@donkeyblam In a nutshell: (1) there’s practically only whole-program compilation (you pull in the source of the program and that of all its dependencies and Cargo builds everything together), which might be nice for whole-program optimizations but makes it hard to update just one bit as you’d do with shared libraries, and (2) there’s this profusion of small packages, each requiring specific versions of its dependencies, so you end up carrying multiple versions of each package.