@rml The link is catching, and fun to read, but in the end one should compare Emacs against Plan9, for judging the real difference between the two paradigms.
Plan9 supports a real Unix-philosohpy, and in fact one can express complex workflows in it, with minimal effort. It is all composable.
But sadly, Emacs and Unix (Linux, FreeBSD and so on) are two real technologies, while Plan9 (and forks) are far from being mainstream.
I looked the first paragraph of each chapter to see if there were any good criticism of Unix, back when I wrote that article "Emacs fulfills Unix," but most of the criticisms were irrelevant to modern Unix/Linux systems.
Really the reason I wrote the article was that I was tired of people, many who I respect and I think are very intelligent, using the Unix philosophy as a reason to dismiss Emacs a mere editor with too much bloat.
This blog post (not written by me) did a pretty good critique of the Unix Haters Handbook, I mostly agree with it.
@ramin_hal9001@rml@screwtape we can be pedantic and say that Emacs technically follows the Unix philosophy because at its core it's just an Emacs Lisp interpreter (so it does one thing and it does it well... err, Guile is better at that) that so happens to have an editor... and IRC... and, most importantly, M-x tetris and M-x butterfly
> "we can be pedantic and say that Emacs technically follows the Unix philosophy because at its core it's just an Emacs Lisp interpreter"
Yes, exactly.
And the Unix philosophy is poorly defined. Do we avoid Linux because it is a monolithic kernel? Do we avoid Blender or Gimp because it provides lots of features? Where do you draw the line between one tool and another?
@ramin_hal9001@rml@screwtape oh, also: people don't use systemd because it doesn't respect the UNIX philosophy (even though it's split into like a couple dozen of individual programs), but they're fine with Linux (which you can't divide into the sum of its components) and I sure as hell don't see Mach, QNX, L4, HelenOS or even Microsoft's Midori get any more popular (QNX is the outlier only because of the automotive industry)
Ambient authority is a major problem in the majority of monolithic kernels (not strictly speaking by nature, it's quite possible to implement them with adequate isolation/modularity and/or with capability addressing, just barely anyone doe sit).
@tychosoft@lispi314@a13cui@ramin_hal9001@screwtape while I never got to experience real-time deterministic behavior, I did get to experience the #Hurd, which I'm convinced is the right direction for a daily drive microkernel OS, just built on the wrong foundations (Mach, which iirc poses major hurdles for 64bit, the main issue holding the project back)
@tychosoft@rml@lispi314@a13cui@ramin_hal9001
I guess I asked because of unix's "cute" style (well, Crufty And Inelegant style) @amszmidt
What's your perspective on GNU hurd and or a powerful lisp like alternative for modern operating systems?
@screwtape@tychosoft@rml@lispi314@a13cui@ramin_hal9001 UNIX as such is an abomination. The Hurd tries to solve parts of the problem, but it does not go far enough .. It is sorta like Plan9. It is putting lipstick on a pig.
What I really miss in Fossil is a staging area. Usually I work on multiple mini-tasks in a project and need to commit only a selection of my changes, mostly even line by line. Git does that really well.
This poll does not make sense. Fossil is the only rational choice for haters, because: case A) if you are an hater against the cancel culture, you had to vote for Fossil, because no commit can be cancelled from it; case B) if you are a woke who likes starting hating campaign, you need a RCS like Fossil were history cannot be rewritten, so you have the luxury to blame trunk for a bug fixed ten years ago;
@a13cui@ramin_hal9001@surabax@amszmidt@screwtape@tychosoft@lispi314 whats that? I want to try Pijul because it applies a lot of theory I'm interested in, and seems like a rare opportunity to get to try something out that is so cutting edge and can only really be gauged by its use with others
@rml@ramin_hal9001@surabax@amszmidt@screwtape@tychosoft@lispi314 I can only talk about Fossil since 1. that's the one I care about and 2. it's written in Tcl (which is one of the why I am choosing it, I'm clearly biased in that regard, but it is a strong advantage nonetheless).
On a serious note, it's pretty similar to Git in concept, it's even a distributed CVS like it. It's all self-contained, a self-hosting system that not only tracks changes but integrates ticketing and bug tracking, wikis, documentation, and live discussion for a project. An important distinction is that everything I listed above in Fossil uses SQLite (I mean, it was specifically made by the creator of SQLite for SQLite) to store changes and can run off a standalone executable with very little memory consumption and a footprint of 8MB iirc. It being backed up by SQLite instead of traversing the file system means queries about changes, such as examining all the changes to a given file over time, or detailed graphs about a project's progress, can be computed quickly, as they amount to SQL queries.
You can reasonably sync Git and Fossil projects, but obviously Fossil-specific things such as a project's wiki doesn't sync, at least not automatically. I think that Fossil is more suitable to small, intimate teams (which would actually work better for our use case). Fossil can still work in a decentralized fashion, but most remote changes are automatically synced with a main repository, instead of being separately developed over time and then reconciled.
@a13cui@ramin_hal9001@surabax@amszmidt@screwtape@tychosoft@lispi314 yeah, I like fossil, it's certainly the best DVCS of the past decades. but Pijul has the novel property of commutative patches, where patches can be applied in whatever order, apparently eliminating much of the worst aspects of merge conflicts, which sounds like it can lead to new creative ways to collaborate, not having to worry about merge order sounds quite huge honestly.
> "so we should all imitate databases using file systems?"
It would be nice if the operating system gave you more control over how blocks are stored on a persistent medium, instead of imposing the directory tree structure on everything.
For example, if you use Guix or Nix, it's stupid to have to encode the hash of the file into the filename. We should just be able to write the hash directly into the block next to the inode number, and keep the file name as the file name. I believe ZFS does this under the hood, but the API to it is probably not exposed so you are forced to use it as a filesystem.
Add comment