samc

u/samc@feddit.uk
1 posts · 139 comments

Recent posts

Recent comments

He's resigning but contesting the resulting by-election.

I guess the logic is that he's about to get suspended, which would likely trigger a by-election anyway, so he'd rather do it in his own terms.

Funny thing is that winning this self-imposed by-election doesn't necessarily stop the recall election from happening shortly thereafter. He's just as likely to get suspended if he wins again, and it still only takes 10% of the electorate to be pissed off with him to trigger it again.

Maybe he'd win both contests, but I could also see the people of Clacton deciding that he's become a liability and opting for e.g. a Restore candidate instead.

Honestly I'm wondering if this is his way of trying to make an exit but saving some face and blaming the establishment?

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.

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)

Its a fair point, and well explained. However, I think it implies that illegal immigrants are fine so long as they're not more criminal than the general population.

Generally if somebody is using crime statistics to argue for more immigration control, they're probably the kind of person that believes the only acceptable amount of crime for an illegal immigrant to commit is zero crime.

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.

Well now I'm nervous! My first instinct though is that the vast majority of Emacs packages are plain elisp, and Emacs users have a habit of cracking open and tinkering with their packages, so any malicious code ought to be spotted quickly.

With the native compiled modules however, it could be another story...