5 ms·

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: > Metropol

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. [0] https://docs.monogon.dev/metropolis-v0.1/handbook/index.html https://docs.monogon.dev/metropolis-v0.1/handbook/index.html

kkfx 3y ago
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.
- dingnuts 3y ago
  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. 0: https://nces.ed.gov/pubs2019/2019179/index.asp https://nces.ed.gov/pubs2019/2019179/index.asp
  - kkfx 3y ago
    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.
    - skydhash 3y ago
      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.
      - kkfx 3y ago
        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.
ritonlajoie 3y ago
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 ?
- q3k 3y ago
  It's somewhere in my git stack :). Until I get to publishing it, the proto/gRPC definitions for node management are a good enough start: https://github.com/monogon-dev/monogon/blob/main/metropolis/proto/api/management.proto https://github.com/monogon-dev/monogon/blob/main/metropolis/... And the top level API to actually deploy workloads is plain Kubernetes.
timmg 3y ago
Am I the only one who thinks it would be fun to try/put this on a Raspberry Pi cluster for fun?
- deleted 3y ago
  [deleted]

kkfx 3y ago

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.

dingnuts 3y ago
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. 0: https://nces.ed.gov/pubs2019/2019179/index.asp https://nces.ed.gov/pubs2019/2019179/index.asp
- kkfx 3y ago
  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.
  - skydhash 3y ago
    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.
    - kkfx 3y ago
      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.

ritonlajoie 3y ago

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 ?

q3k 3y ago
It's somewhere in my git stack :). Until I get to publishing it, the proto/gRPC definitions for node management are a good enough start: https://github.com/monogon-dev/monogon/blob/main/metropolis/proto/api/management.proto https://github.com/monogon-dev/monogon/blob/main/metropolis/... And the top level API to actually deploy workloads is plain Kubernetes.

timmg 3y ago

Am I the only one who thinks it would be fun to try/put this on a Raspberry Pi cluster for fun?

deleted 3y ago
[deleted]