Mason installs LSP servers (and other tooling if desired). So if you're managing your LSP servers elsewhere (distro package manager, etc), it's probably not doing much.
Mason was always just a package manager for LSP servers. It used to be you needed the nvim-lspconfig plugin to properly configure LSP servers to work with neovim; to help with that there was the mason-lspconfig plugin that basically mapped LSP servers (as installed by mason) to nvim-lspconfig LSP configurations to make it all Just Work.
Now nvim-lspconfig and mason-lspconfig are no longer required thanks to the `vim.lsp.config`/`vim.lsp.enable` setup so you don't need them unless you want the little bit of automagic setup. Mason you can retain if you find it easier to install LSP servers through it, otherwise you can drop that too. Personally I manage my LSP tooling through distro/mise and replaced the lspconfig plugins with just a few autocommands and manually grabbing the config files from nvim-lspconfig git repo as needed.
Linux distros that are updated with full system snapshots instead of package by package, similar to Android. The key difference is most of / is mounted read-only[0] and is only changed by distribution provided updates so you and the distro team always know exactly what's running.
> What are the advantages to the alternatives?
Greater control and stability since its essentially always running in a supported configuration. Easy roll-backs to a previous update if something goes wrong. You always know exactly what your system is running if you want to keep it in sync across machines (more useful in a server setting).
> What other projects are similar
Kalpa is a "sibling" project to AeonOS, which is atomic OpenSUSE but with Gnome (and other changes, which I'll get to). There's also the Fedora Atomic line of Fedora Kinoite and Silverblue (KDE and Gnome respectively), U-Blue, Bazzite, SteamOS, and more. I think most major distro lines have an Atomic variant at this point.
> What is the motivation for this project in particular?
For Kalpa specifically, it's to offer a KDE alternative to AeonOS. Originally there was just AeonOS, which was OpenSUSE MicroOS (an atomic version of OpenSUSE Tumbleweed) with GNOME installed. Aeon has diverged greatly from MicroOS though and I think it no longer uses it as an upstream. AeonOS also refused to support KDE[1], so Kalpa was created. Kalpa still uses MicroOS as its upstream and I'm not sure if there's any plans to change that.
> Most importantly, why should I want to use it?
I use it on my personal laptop because it lets me have all the benefits of a rolling distro (up to date packages) without the stability concerns. Updates apply automatically in the background and I know when I reboot I'll always have a working system available to me.
[0] /etc is mounted as an overlay FS so you can still make changes to it. /var, /usr/local, and /srv are also still user-writable. I think /mnt is too but I forget off hand.
[1] Aeon is generally anti-customization and does its best to only offer one way of doing things. This is to prevent configuration drift and reduce the maintenance burden per snapshot. GNOME also has a more regular release cadence, which makes it much easier to integrate than KDE (or so I've been told..)
Would the A/B filesystem approach à la Android be a good way to distribute Linux with ZFS-on-root without all the angst from DKMS modules versioning?
[Maybe unrelated, but just occurred to me (some horror stories have prevented me from trying ZFS-on-boot in linux after Ubuntu botched it with their Zsys “adventure”).]
If i understand the intention of a zfs root combined with an a/b approach — it feels like this btrfs root and immutable gives you the same benefits but with better mainline support.
> Would the A/B filesystem approach à la Android be a good way to distribute Linux with ZFS-on-root without all the angst from DKMS modules versioning?
This is exactly what Valve's Steam OS 3 does. (Except it uses Btrfs for the two root partitions, not ZFS.)
It's closer to the "sealed system volume" model that macOS uses. The core OS filesystem isn't (normally) writable, although you can finagle it to add drivers and such.
Kalpa is great and hits way above its alpha status; I've been running it on my laptop for months now with zero issues. It's been really nice to not have to worry about updates, just gotta reboot it every now and then and most things just work.
I can't think of anything that doesn't just work in that it's broken in some way. There are things that are different. I've been using MicroOS with Plasma for at least 4 years now on my personal machine and my work laptop. At some point they changed the name to Kalpa. There were some times in there where things were broken and it needed to roll back and pause automatic updates for a few days, but otherwise it functions just as expected.
A couple of annoyances exist. For example IDEs want to use the system's shell, so you have to make a custom entry to use your distrobox. Tools like python, node, tofu, etc are installed in a distrobox and then exported with `distrobox-export -b $(which $BINARY)` so that you can call them from the IDE.
For me, it's worth those few rough edges. When I install an OS for non-technical people who just need a web browser, I install Kalpa. It looks close enough to Windows to be easy to use, and it's never broken in a way I can't explain over the phone or a text how to fix.
It even passed the wife test in our house. It took a few years of marriage to convince her that her laptop shouldn't take 30 minutes to boot and open Chrome. She let me switch her over to Kalpa (it may have still been called MicroOS Desktop then) a few years back. That old laptop is still kicking and fast enough for her needs. Had she stuck with Windows, it'd be a brick now because of the requirements for upgrading to W10 and 11.
This is satire right? The real lesson we learned is to actually learn how you infrastructure works and don't blindly run destructive commands in prod, AI or otherwise right?
Matrix/Element has video rooms as a Lab function and for a while it had voice rooms too. Not sure what happened to them, but either way with MatrixRTC coming out the technical underpinnings are all there, clients just need to put it all together.
Someone mentioned (I believe?) after talking to Element/Matrix at FOSSDEM this year that the organization has been struggling a lot to get this going. Apparently issues with thier project organization forking and funding the last few years has made one of thier primary contributors, who already had fully functional and working video/voice, all but give up on the project because the upstream forming means it's now forked from a commercial/defunct version of the original code(?)
Steam Group Chats are sort of there; no video chat but text chats and drop-in voice chats like Discord. On the other hand they're basically ephemeral, with messages disappearing from history at some given point.
I also can't figure out a way to access them outside of the Steam client and in DOTA where I believe they're tied to the in-game guild system.
Outside of Dota, it's called "Group Chats" (below your friends list) and it looks very similar to a basic Discord interface. You may have to join a dota guild in order to see it, although everyone in my guild just uses discord.
>> It assumes people in very different places for 1,000+ years did the same thing and had the same views
> But that was true, wasn't it? The Dark Ages started when Christianity spread through most of Europe. And really completely ended only when the Reformation fractured it.
1. Political, economic, cultural, and even religious systems would vary drastically by place and time in Europe. The lifestyle and thoughts of an English peasent in 600CE would be drastically different from the lifestyle of a Spanish or Frankish one, and would differ even more so between 600CE and 900CE.
2. The "Dark Ages" traditionally started when Rome fell in 476CE, long before Christianity had spread outside of traditional Roman lands.
3. The Reformation didn't start until the 16th century, long after the Dark Ages are considered to have ended. Generously you could say it started with the Hussites in the 1400s but that's still skipping over the Renaissance entirely which is the absolute latest end for the Dark Ages since the whole point of it as a historical context is "rediscovering" the Classical works.
> 1. Political, economic, cultural, and even religious systems would vary drastically by place and time in Europe.
This is a non-answer. Yes, political systems were different. The ARE still different.
But during the Dark Ages, there were NO places in Europe where science or scholarship really flourished.
> 2. The "Dark Ages" traditionally started when Rome fell in 476CE, long before Christianity had spread outside of traditional Roman lands.
It should have started around the time of the move of the Roman capital to Constantinople. By the time of the fall of Rome, the Darkening had been in full swing.
If you want a precise date, I propose the date of murder of Hypatia in 415 AD.
It was probably the 540s and the subsequent century or so.
> there were NO places in Europe where science or scholarship really flourished.
If you define ~800 AD as the end of the dark ages then yes. By Charlemagne’s time that had already changes.
It wasn’t exactly flourishing in Gaul, and Germany during the Roman times either. Those regions had arguably surpassed their Roman peak by the end of the dark ages.
And of course science and scholarship were preserved in Constantinople during the entire period (of course they had some very dark moments too)
> But during the Dark Ages, there were NO places in Europe where science or scholarship really flourished.
Ireland is often cited as one such place, thanks to early Christian monasteries. The Carolingian Renaissance was significant in Central Europe, and there were important cultural developments in Slavic lands, though perhaps not involving 'science' as such.
> But during the Dark Ages, there were NO places in Europe where science or scholarship really flourished.
That seems different from what you originally argued but either way, that's also not really accurate. I'm going to assume you're referring to "Western Europe" here since you're clearly aware of Eastern Roman/Byzantine empire still existing, but that still leaves Al-Andalus, the Carolingian Renaissance, agricultural advancements like the three-field system, wheelbarrows, multiple types of milling technology, and during the latter end you start getting advanced compasses, bells, mechnical watches, and other metallurgy.
Where all of these done in one or two specific places? No, continuing to ignore Byzantium here, but there was a still a variety of advancements happening all the time without which the Renaissance couldn't have happened.
> It should have started around the time of the move of the Roman capital to Constantinople. By the time of the fall of Rome, the Darkening had been in full swing.
I mean, you can think that but that's not how or what the term "The Dark Ages" usually refers to. It sounds like you have your own constructed time period in mind and I'm not interested in discussing something I'm not aware of.
> If you want a precise date, I propose the date of murder of Hypatia in 415 AD.
The biggest problem with the `systemctl daemon-reload (--user)` workflow to register quadlets with systemd is it hides any generation errors in journald instead of giving immediate feedback. It's a real pain in the ass, and I say this from a place of love.
Quadlets are just a systemd generator: all `daemon-reload` is doing is running `podman-system-generator` which looks at the Quadlet files and turns them into systemd unit files with a big honking `podman run --rm --blah container:tag` as the `ExecStart` property. There's nothing else to it, no daemons or what not
If you ever feel like bothering to give it another shot check journalctl to see if there's any generator errors. Or run the generator directly: on my OpenSUSE box it's at `/usr/lib/systemd/system-generators/podman-system-generator` , Run it with `--dry-run` to just output to stdout and `--user` to get user quadlets.
Mason was always just a package manager for LSP servers. It used to be you needed the nvim-lspconfig plugin to properly configure LSP servers to work with neovim; to help with that there was the mason-lspconfig plugin that basically mapped LSP servers (as installed by mason) to nvim-lspconfig LSP configurations to make it all Just Work.
Now nvim-lspconfig and mason-lspconfig are no longer required thanks to the `vim.lsp.config`/`vim.lsp.enable` setup so you don't need them unless you want the little bit of automagic setup. Mason you can retain if you find it easier to install LSP servers through it, otherwise you can drop that too. Personally I manage my LSP tooling through distro/mise and replaced the lspconfig plugins with just a few autocommands and manually grabbing the config files from nvim-lspconfig git repo as needed.
reply