Komrade Desktop Environment

I had no issues when my domain was registered with GoDaddy. It was shortly after switching to porkbun that the issues started. Porkbun blamed nominet and nominet blamed porkbun. Not sure what actually happened, but it does seem related to nominet’s policy about who can hold a .uk domain

Nominet manages the .UK domain, and they’re a bit funny about proof of residence. Not sure I had to give Porkbun any photo ID, but the did temporarily suspend my domain. Took forever to clear up.

IMO the moral if the story is avoid ccTLDs (though now I have it I’m sticking with it for as long as I can).

No apologies necessary! I was partly kicking the hornets nest to see if an interesting discussion fell out…

That blog post is absolutely brilliant! It does a great job of stating what a user should want from a system: easy and deterministic re-deployment. If atomic ends up being the best too for that job, I’ll come back. But for now I’m happy with Debian, a separate home partition, and a strong preference for flatpak over apt.

Hmm, I think I agree with this.

Certainly I’d love a universal GUI/CLI package manager with optional sandboxing. I don’t use nix, but it seems like the closest solution out there right now

Its not so much the UX that I take issue with, but the complexity of what’s going on under the hood.

The way I see it, either the base image of an atomic/immutable distro is suitable for you, or it isn’t. Once you start getting into the territory of layering new tools/drivers/whatever on top, you’re reintroducing the statefulness that the atomicity was supposed to eliminate.

This is cool, and I’m interested to see where this goes. But to me the whole sysext thing is actually a compelling argument for why Linux power users (i.e. most Linux users on lemmy) aren’t suited to immutable distros.

When something as fundamental as git requires multiple obscure commands to install, you’ve got to think twice about the target audience.

Personally, I do think it’s a useful exercise to decide what your red-lines are when it comes to OS level age verification.

For me: Having a field in a database that could contain my DoB is acceptable. Having a prompt to populate it during first time set up is very concerning. Requiring that data to be validated by a third party is the red line.

If you don’t want to be boiled like a frog, bring a thermometer.

I’d say don’t risk it if you’re not based in the UK.

I have a .uk domain and had to provide proof of residence or something to nominet. I can’t remember the exact process now, but they did temporarily suspend my domain (without warning) until I contacted them.

The change would be using Gitmail as the plumbing, and normalising the creation of user-friendly porcelain on top.

E.g. suppose there is a repo foo/bar hosted by a forgejo instance at myinstance.org/foo/bar. Sending an email to foo.bar@myinstance.org (or similar) could automatically create a PR and, conversely, opening a PR could send a patch series to the foo/bar mailing list.

GNUwU

To be honest, I’m starting to drink the Sourcehut coolaid here. We have a distributed method of interacting with repositories: Email.

Don’t get me wrong, the current user experience of email-based patches and discussion isn’t great because it’s too easy to send a badly formatted patch. But if we invested time in making email patches easier to use (e.g. sending them through a web ui for people who prefer github style PRs) then we could skip all the architectural pains of solutions like forgefed.

MacOS Requirements: 💵💵💵

Debian 13.

Tried open suse, but on my laptop it was slow and loud and the battery would die almost instantly (had to make it hibernate rather than suspend if I wanted it to make it through the night).

Installed Debian 13 and it feels like a new laptop. Not sure what exactly made the difference between the two but I’m not complaining…

Not sure I like their definition of declarative. I’d instead say that a config is “declarative” if the result of applying that configuration is independent of the current state of the system.

MacOS

I had a go at using guix as a package manager on top of an existing distro (first an immutable fedora, which went terribly, then OpenSUSE). Gave up for a few reasons:

• As mentioned in the article, guix pull is sloow.
• Packages were very out of date, even Emacs. If I understand correctly, 30.1 was only added last month, despite having been available since February. I get that this isn’t the longest wait, but for the piece of software you can expect most guix users to be running, it doesn’t bode well.
• The project I was interested in trying out (Gypsum) had a completely broken manifest. Seems like it worked on the dev’s machine though, which made me concerned about how well guix profiles actually isolate Dev environments. This was probably an error on the dev’s part, but I’d argue such errors should be hard to make by design.

All in all I love the idea of guix, but I think it needs a bigger community behind it. Of course I’m part of the problem by walking away, but 🤷

Its actually GNU image manipulation program, so pretty much.

Or “Green Is My Pepper” if you ask RMS…

There’s a river Foss that runs through York. Brings a new meaning to sending patches upstream…

Yeah, I’m leaning toward this option tbh.

If we got to the point where popular machines had custom images with all the necessary extra drivers etc, it might be a value add. But for now I’m not seeing a huge benefit