Microsoft have not maintained a monopoly on search, mobile, or maps, and they seem to mostly maintain their large market segments based on familiarity, not hype.

How are you sandboxing your Pi coding harness? Directly only mounting certain folders, using capabilities to kill the network and not giving it all your shell env vars, that sort of thing? Or do you use a tool?

I prefer KDE (on Ubuntu, because I tried it and it's good enough) - it's got more stuff built into the OS in terms of settings. I tended to find that Gnome needs you to install more things to expose configuration settings, whereas KDE's configuration UI is pretty good.

I agree that integrity can be done by secure boot, but HTTPS does mean that someone can't intercept your request and serve you valid, signed, older software that has a known security flaw in it.

An LLM pointed this out to me as well which I think is a fair point.

However, in practice it doesn't matter for any machine that has persistence since it only needs to netboot once to transfer an image to local storage. Besides that, you can also invert and bootstrap with BMC or even a flash drive and skip the whole network anyway.

Finally, you can reduce risk if you only bootstrap a minimal executable which itself has a robust bootstrapping mechanism. In the post, they're jumping to iPXE from UEFI so the concern would be loading an old iPXE version.

I'm not an expert in database hints, but the syntax looks very readable and composable. That's great thing to have got right.

Most people have laptops now, in my experience of large corporations.

I got the RAM upgraded in my work laptop.

Last time I requested that, they just swapped my laptop for a newer one with more RAM

On very rare occasions I may do that for a user, if I happen to have extra RAM on hand from - for example - a broken machine. But by and large it's just going to be a whole machine upgrade.

I mean, I had to install it myself.

My users would somehow manage to start a fire if they attempted that.

All force-with-lease does it stop you from clobbering rather than you having to realise somehow that you did that. It seems like a no-brainer. What's the problem with it?

The only situations in which I would use a git push --force would be in which I have carefully considered what state the remote is in, and what state I want it to be be in, and I know that it's not a moving target it any way in between checking its state and doing the force.

Already, "git push" stops from clobbering: it warns that your proposed push is non-fast-forward and that you need --force.

If you are using git as intended, that's all the warning you need.

I understand that there are dubious workflows out there where a repo has multiple downstream users and they are all doing "git push --force", without coordinating with each other. They need a double force to make sure that they are clobbering what they think they are clobbering.

If that's not you (which it arguably shouldn't be, and certainly isn't me), you don't need to know about force-with-lease.

The only thing I would ever do with --force-with-lease is go "oh", and immediately repeat the command with --force, knowing that I'm in a situation in which the check is not applicable.

Even if the force were erasing a new commit that came from another repo, I would know that. Like I pushed something into upstream U from repo B, but I'm fixing the situation out of repo A which hasn't picked up the change. Yes, I know what I'm doing, that's why I'm using --force, and don't require --simon-says-force. I want the chain of commits I now have in A to be exactly what is in U, as a rare exception to normal git use. After I'm done from A, I will switch back to B, do a "git fetch" and probably "git reset --hard origin/master" to make B look like U.

Hm - I think I follow. But say I push a commit on a branch, then realise I messed up the commit message, so I --amend and push. I know that git push will fail, but if I git push -f then it won't detect that someone else pushed to the same branch in between - it'll just silently wipe their push.

Using --force-with-lease means the git push -f will succeed if no-one's pushed in between, and fail otherwise.

(I couldn't find this announced on the Proton website - apologies if there was a page, Proton!)

Well, that was terrible searching by me! Thanks. @dang could you update it please?

> and if you're lucky Firefox

I haven't had any problems with Firefox so far. Why do you say this?

That was more a (gloomy) outlook into the future, given Chrome's market dominance and tendency for unilateral actions in web standards.

I haven't ever noticed Cloudflare having any issues on Firefox, so presumably that implies any unilateral actions in web standards have been worked around by CF to provide the service to Firefox as well.

I'm pretty frequently blocked by Cloudflare when I use Firefox on OpenBSD -- apparently it's too suspicious of a combination for their liking, or something. Even on Linux I've occasionally had issues. I've had to email site operators to ask them to change their configuration so I can actually be a customer of their business.

Oh dear. That is tricky. It must be a rare enough combination that it looks like automation.

It's already a problem with Firefox + some essential web condom extensions.

I was reading things[0] about sugar a lot earlier than that - maybe 2007? And it made a lot of sense back then.

[0] https://nosdiet.com

Oh, I mean people have known that high-sugar diets are a bad idea for about a century, but you could argue that it started coming more into the public consciousness in the early 21st century.