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.

Exactly this. IMO we just need better ways of rendering a mailing list inbox as a series of issues/PRs. And maybe better tooling from IDEs to “open a PR” using git send-email.

Source hut is close to my ideal here, but still seems rather complex. Maybe I just don’t appreciate the necessary problems it solves yet.

Agree with several people here that named parameters are a good solution, they add minimal overhead at the call site and function declaration and look very natural.

Another option for languages that want function arguments to have fixed size is bitmasks. I wonder if it could be a useful language feature to infer the flag names from the function declaration. Something like

def my_function(arg1, arg2, [FLAG1, FLAG2]) {
    if (FLAG1) {
        do thing
    } 
   ...
}

my_function(val1, val2, FLAG1 | FLAG2)

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.

I get that calling command line tools is a bit clunky, but python is always my go-to when shell scripting gets too painful

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…

Before we all jump ship to linux phones, is it possible that custom android ROMs can remove this feature?

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

You know, the more I think about this, the more I bristle at Dyson claiming this will solve Britain’s food security problem.

Firstly, this kind of system seems limited to small cash crops rather than staple foods. (Good luck growing wheat on these.)

More importantly, Dyson has personally done far more to harm British food security than this gadget could offset. He was an ardent Brexiteer, which resulted in substantial barriers to importing food from our closest neighbors. (He also then immediately started relocating his business to Singapore in a stunning show of confidence in post-Brexit Britain)

These people don’t want to save the world. They just want to look like heroes

Yes, but it’s still competing with a field full of dirt. So the value add has to be pretty substantial to justify any cost.

Not saying I disagree, but out of curiosity I looked up the yield of a conventional strawberry field, which is apparently 15-25 tons per hectare, or 11-18% of your threshold.

I agree that this would likely never be economically viable for strawberries, as I imagine it’d cost way more than £1M for a “hectares worth” of this setup.

More importantly, I don’t consider strawberries vital to our food security, unlike Dyson