Well not the Lisp userland many of us dreamed of but a very interesting project nonetheless.
The handbook[0] is a bit more clearer about the goals:
> Metropolis is a cluster operating system, meaning its goal is to run on a fleet of machines (be it physical or virtual) and pool their resources together into a unified API for operations and developer teams.
> A self-contained operating system: Metropolis is a full software stack, including the Linux kernel, userspace code, Kubernetes distribution and cluster management system. In contrast to traditional cluster administration, there are no puzzles to put together from a dozen vendors. The entire stack is tested as a single deployable unit.
> Eliminates state: Metropolis nodes don't have a traditional read-write filesystem, all of their state is contained on a separate partition with clear per-component ownership of data. All node configuration is managed declaratively on a per-node basis, and all cluster operations are all done by gRPC API.
Seems like they a specific use case in mind which will help keep the scope in check. Definitely looking forward to learn more about he project.
Also golang is a pretty good choice for such a project because it doesn't even have a libc dependency and calls the Kernel directly. So you can indeed have a very pure userland in a garbage collected language.
This looks interesting. However I can't find any documentation on how to program for it ? Where is their documentation about how we use this "unified API" which pools resources between nodes ?
IMVHO it's just another demonstration we need code and production together, we need end user programming and most try to deny that, while all tend to, a very small step at a time.
Python popularity, Notebook UIs, WebApps vs widget-based GUIs, this project... are all small examples of the same issue.
Is the end user you refer to a highly technical person? Because 1 in 5 Americans do not have the literacy skills to "complete tasks that require comparing and contrasting information, paraphrasing, or making low-level inferences"[0] so if you're describing end user software as something usable by everyone, expecting users to become programmers is simply an unrealistic expectation. The below average person is simply not smart enough to learn a DSL to get something done, and software should be accessible to everyone, even those who weren't lucky in the IQ lottery.
Well, "my" end-user is someone who have studied "computer science" a bit at school or to work, since he/she use computers every days, like he/she drive a car, so it's not acceptable he/she master computer usage less at level of mastery inferior to the one he/she master his/her car.
I know very well how illiterate so many people are, but that's not something to be justified but to be corrected. I imaging you do not want a bus driver who can barely make the bus move on the road piloting the bus you are on, why it's normal for you that let's say a tax administration employee is just able to click around while dealing with your taxes?
I've made a small experiment few years ago: with the help of some friend we have introduced for their very first time few kids to a desktop, a NixOS one running Emacs/EXWM. In 2 years at 6-8 years old, they was able to deal with emails, create some nicely formatted documents and doing basic math and so on with it. Two of them was presented a classic modern desktop: they became unable to do practically anything. It's a VERY small experiment of course, but to me it's enough to prove that people can learn if they are pushed toward a certain direction.
People can learn. I believe most programmers (who build side-projects) fall on the curious side. They explore stuff and thus discover software capabilities. Most people use software for a specific task, and learn only what is required. Making a software usable does not means making it a minimalist art project. It means making it consistent both in time (do not shuffle stuff around) and space (do not put things together randomly).
Learning how to type a letter in a word processor can be done in a day. But learning something like Microsoft Word should take a training. Just like you should buy a book about git or bash if you’re serious about learning them. Let the user figures it out is the wrong direction. As well as reducing the software capabilities (for potential power user) in order to reduce cognitive load for untrained users.
It's not that, it's another point: efficiency vs assembly line. Humans are not build to be robots, they are build to evolve.
If we learn a classic desktop paradigm computer system at school, while we learn all the basic and less basic cultural stuff we learn at school to became Citizens, we can profit from this knowledge for life. We can choose to dig deeper or not, but we have something useful for our entire life.
If we learn the modern desktop paradigm we never evolve. We are not Citizens, we are workers in an assembly line and upon any change from the factory owner our acquired knowledge goes to the bin.
I hope to have successfully described the point in my poor English. To give a simple example, I track my bills (well, like many, nothing special), I've crafted a bit of automation (org-mode notes + BeanCount + a bit of py automation), it took two/three days, MUCH more than most users do with modern tools, BUT thereafter anything goes nearly autonomously so I've spent 2/3 days + few seconds looking at my org-agenda regularly vs few minutes to start than keep spending few minutes all the time. In the short term the classic model is not good, in the middle term it's equivalent but demand more intellectual work, in the long term outshine the modern one so much that's like comparing a runner by feet against one on a jet in a speed race. Actually the effort spent in automating my bills notes it's also useful (at least in some parts) to automated other stuff, a bit at a time, an evolutionary step at a time I've built and keep up my PIM, again all the effort put pay back and I've gained valuable knowledge from doing that. The modern approach seems cheaper at first but it's much more expensive in the long run and gives little to no valuable knowledge at all.
The same model apply to any other aspects of our life, one to remain in economics the "ownership model" vs the "rent model", owning a home seems to be much, much more complex than rent one, it demand much more resources, much more computations and projection up front etc BUT it pay back much more thereafter. The rented home is just a regular expense that pile up year after year and at the end you have nothing. The owned home in most cases (essentially all, with insurances) have a final value, normally a big enough one to pay back the capex + opex of the time passed.
Since we are not made to live a single life but to evolve, doing better things a generation after another, passing knowledge and anything we can to newer generation, the modern paradigm is the slave paradigm, he/she produce a new generation that have no benefit from the old one, get nothing, leave nothing in the end. The classic is the human model, where we build families, passing what we have built and the accumulated knowledge, improving a generation after another.
I completely agree with you. I'm in the process moving from SaaS to a more personal computing space (selhosting, file-based app,…). I believe the dumbing down of user interfaces to sell an idea of "It just works" (magically) is a net negative. It also reduces the capabilities of the general population because there's no longer the idea of expertise (as expertise is not allowed). Maintaining a Arch Linux installation is not as easy as using MacOS but it removes the veneer of magic. And I think it's necessary knowledge if we need further improvement in the personal computing space. Just like C has its foot-guns, but learning it gives you a stabler foundation knowledge on how software works. It may not be for everyone, but removing the possibility is harmful for someone.
Allow me to suggest NixOS instead of Arch, for the same automation reason: NixOS meant a single (normally split in few) file(s) that describe your desired config, nixos-install/nixos-rebuild makes the system for you, so at any point in time if something break you just roll back to the previous build, not need to "emergency fix" something or have a test system aside. It's not a "distro war" but what I call a natural outcome of taking notes: in the same org-mode notes I keep my bills, my mails (ol-notmuch), my files (org-attach-ed and linked), a fully searchable "knowledge base" with just ripgrep, no recoll (xapian) or other indexers needed, but also my NixOS config, zsh config, ... and so on. Again the same automation (well, org-babel-tangle + little stuff) works for anything. The same documentation model works for anything. It's long to start, many things to learn, but it pay back much thereafter.
In my case while migrating toward a local approach I've tried some tools, like the idea of using Zotero for a bit anything, bookmarks, docs, ... it works, but it's not integrable with other tools like ALL modern apps, so I've put most in org-mode, bookmarks included, with Buku + ebuku to manage the SQLite DB from Emacs, org attaching stuff is slower than the Zotero connector but much more flexible, "Copy as Org-Mode" (FF extension) it's not as quick as Zotero notes, but the flexibility of one tool for anything is extreme, a thing we lost loosing the classic desktop model and today we can rediscover but still suffering the lack of development and the rest of the world heading in totally different directions.
Every piece of software doesn't need to be for everyone. Designing interfaces for the lowest common denominator throws away a lot of ideas that may make some people more productive to benefit people who won't be.
The handbook[0] is a bit more clearer about the goals:
> Metropolis is a cluster operating system, meaning its goal is to run on a fleet of machines (be it physical or virtual) and pool their resources together into a unified API for operations and developer teams.
> A self-contained operating system: Metropolis is a full software stack, including the Linux kernel, userspace code, Kubernetes distribution and cluster management system. In contrast to traditional cluster administration, there are no puzzles to put together from a dozen vendors. The entire stack is tested as a single deployable unit.
> Eliminates state: Metropolis nodes don't have a traditional read-write filesystem, all of their state is contained on a separate partition with clear per-component ownership of data. All node configuration is managed declaratively on a per-node basis, and all cluster operations are all done by gRPC API.
Seems like they a specific use case in mind which will help keep the scope in check. Definitely looking forward to learn more about he project.
Also golang is a pretty good choice for such a project because it doesn't even have a libc dependency and calls the Kernel directly. So you can indeed have a very pure userland in a garbage collected language.
[0] https://docs.monogon.dev/metropolis-v0.1/handbook/index.html