Monogon: A Linux userland in pure Go
github.com
github.com
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
Python popularity, Notebook UIs, WebApps vs widget-based GUIs, this project... are all small examples of the same issue.
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.
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.
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.
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.
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/...
And the top level API to actually deploy workloads is plain Kubernetes.
We didn't expect to go public with our project for a few more months, which is why the end-user documentation is still very bare, sorry! But fixing that is something we're prioritizing over the next few quarters.
But I guess the cat's out of the bag, so I might as well stay around and answer any questions that pop up. We've also quickly set up a public Matrix room, which was long overdue: https://app.element.io/#/room/#monogon-os-community:matrix.o...
Monogon OS implements the layers underneath Kubernetes and gVisor - it's the operating system which runs on your nodes/machines and which comes together to form a cluster.
How do you handle Ingress and network policies? How do you handle multiple clusters on a single physical machine (if I read the docs correctly) for ingress?
Bring your favourite Ingress controller. We support NodePort services, with plans for a LoadBalancer Service controller given the right network topology (a la MetalLB - either BGP to TOR switches to announce /32 / /128s, or maybe ARP/NDP-based annoucements for simpler deployments).
We don't support colocating multiple Kubernetes clusters on a single machine, or even within a single Monogon OS cluster. If you want multiple Kubernetes clusters, run multiple Monogon OS clusters.
See this: https://www.talos.dev/v1.6/introduction/getting-started/#mod...
The first time you send the machine config, you have to use the --insecure flag to avoid verifying its TLS cert. More concerning, there seems to be no way for you to authenticate yourself to the new machine. Anyone (most likely an automated scanner) could come in and make it theirs at this point.
Is there a solution for that?
You can also generate a custom installation medium or cloud image that pulls config from your trusted machines if you cannot use out-of-band provisioning.
You can also securely use the insecure maintenance mode when there is a firewall in front of the machine, which prevents access by non-administrator clients to the API ports on IP level.
I'm not a fan of Talos booting into insecure maintenance mode without config w/o prompting for at least a PIN displayed on-screen, but the problem you're describing in no way prevents production use.
As others have mentioned, you do need a bit of DIY boootstrapping for PKI. Hopefully we can make our setup portable enough to open source soon.
[^1]: https://gokrazy.org/
It's fine if you want a dull language that your junior devs will find hard to shoot themselves in the foot with. It's like a safer C.
I can write a program while drunk or high and I know that I'll get 99% there, on the other hand python, js and C++ let me write basically whatever and it even let me run it.
Of course it has enumerations. It has had them from the get-go. After all, enums are a workaround to help deal with the shortcomings of a basic type system. You're bound to find them anywhere you find a basic type system, which certainly describes Go.
In fairness, there does seem to be some confusion floating around about the difference between enums and sum types, with some mistakenly calling sum types enums. Indeed, Go does not have sum types. This is what languages with more advanced type systems are bound to provide instead. Enums are pointless when you have a more expressive type system.
> Error handling requires lots of boilerplate.
What patterns are you seeing in other languages when it comes to error handling without the boilerplate?
Certainly there are other languages that provide shortcuts when not handling errors, but that's something else entirely.
If err != nil after every fallible function call pales in comparison to being able to choose your own error handling such as automatic bubbling or wrapping that you can do in other languages. Go gives you two options: explicit handle or implicit ignore. There is no other option. The if statements clog up code unnecessarily. Rust does a great job of error handling, but I’d argue that almost every other language including Java does errors better than Go.
You’re thinking of sum types, or at least something like what Pascal has which is a variant on sum types only with support for integer tags.
That’s not a property of enumeration. Enumeration is simply about numbering. Literally the dictionary definition.
Maybe you’re thinking of the new definition that has recently emerged from confused Rust users that’s just another name for sum types? That’s actually sum types, not enumeration, though.
Letting an error bubble up isn’t handling it. Still interested in seeing what other languages are doing to eliminate the boilerplate when handling errors. For some reason you forgot to speak to it…
However it is absolutely fantastic at what it's intended for, providing a single build system across a large multilingual codebase, and building/running quickly, with extras for running tests, etc.
What am I looking at?
A sqlc compiler? Why not use sqlite, which is proven beyond doubt?
A POSIX.2 userland in Go would not be unwelcomed in any way.