Enter und Shift sind unterschiedlich (die Deutsche Entertaste ist doof). Ich hatte Tastaturen ohne staggering getestet, fand ich doof (kann aber natuerlich auch muscle memory als vielschreiber sein - das unvoreingenommen testen wird vermutlich schwierig wenn man mehrere Jahrzehnte blind getippt hat)

It has been a while since I touched ssmtp, so take what I'm saying with a grain of salt.

Problem with ssmtp and related when I was testing it was its behaviour in error conditions - due to a lack of any kind of spool it doesn't fail very gracefully, and if the sending software doesn't expect it and implement a spool itself (which it typically doesn't have a reason to, as pretty much the only situation where something like sendmail would fail is a situation where it also wouldn't be able to write a spool) this can very easily lead to loss of mails.

I already had a working SMTP client capable of fishing mails out of a Maildir at that point, so I ended up just doing a simple sendmail program throwing whatever it receives into a Maildir, and a cronjob to send this forward. This might be the most minimalistic setup for reliably sending out mail (and I'm using it an all my computers behind Emacs to do so) - but it is badly documented, so if you don't care about reliability postfix might be a better choice, or if you don't just go with ssmtp or similar. Or if you do want to dig into that message me, and I'll help making things more user friendly.

A problem of this bubble is that it is making AI synonymous with LLM - and when it goes down will burn other more sensibly forms of AI.

I didn't do enough testing with different materials for a conclusive answer - but that was my guess as well.

I should have 3 different glow filaments somewhere, one PETG, two PLA. Typically I preferred the PLA versions - they had a bit more uniform glow. The PETG one had brighter spots, but as it was mostly transparent individual spots were more visible than with the PLA prints.

They're in a lot of government networks world wide (I visited them a long time ago to discuss some potential cooperation) - they're technically quite sound, and as bonus them being privately owned and headquartered in small Finland is generally seen as reducing the likelihood of backdoors or similar issues due to conflicting state interests.

The encryption tech in many cloud providers is typically superior to what you run at home to the point I don’t believe it is a common attack vector.

They rely on hardware functionality in Epyc or Xeon CPUs for their stuff - I have the same hardware at home, and don't use that functionality as it has massive problems. What I do have at home is smartcard based key storage for all my private keys - keys can't be extracted from there, and the only outside copy is a passphrase encrypted based64 printout on paper in a sealed envelope in a safe place. Cloud operators will tell you they can also do the equivalent - but they're lying about that.

And the homomorphic encryption thing they're trying to sell is just stupid.

Overall, hardened containers are more secure vs bare metal as the attack vectors are radically diff.

Assuming you put the same single application on bare metal the attack vectors are pretty much the same - but anybody sensible stopped doing that over a decade ago as hardware became just too powerful to justify that. So I assume nowadays anything hosted at home involves some form of container runtime or virtualization (or if not whoever is running it should reconsider their life choices).

My point is that it is simpler imo to button up a virtual env and that includes a virtual network env

Just like the container thing above, pretty much any deployment nowadays (even just simple low powered systems coming close to the old bare metal days) will contain at least some level of virtual networking. Traditionally we were binding everything to either localhost or world, and then going from there - but nowadays even for a simple setup it's way more sensible to have only something like a nginx container with a public IP, and all services isolated in separate containers with various host only network bridges.

Well with bare metal yes, but when your architecture is virtual, configuration rises in importance as the first line of defense

You'll have all the virtualization management functions in a separate, properly secured management VLAN with limited access. So the exposed attack surface (unless you're selling VM containers) is pretty much the same as on bare metal: Somebody would need to exploit application or OS issues, and then in a second stage break out of the virtualization. This has the potential to cause more damage than small applications on bare metal - and if you don't have fail over the impact of rebooting the underlying system after applying patches is more severe.

On the other hand, already for many years - and way before container stuff was mature - hardware was too powerful for just running a single application, so it was common to have lots of unrelated stuff there, which is a maintenance nightmare. Just having that split up into lots of containers probably brings more security enhancements than the risk of having to patch your container runtime.

Encryption is interesting, there really is no practical difference between cloud vs self hosted encryption offerings other than an emotional response.

Most of the encryption features advertised for cloud are marketing bullshit.

"Homomorphic encryption" as a concept just screams "side channel attacks" - and indeed as soon as a team properly looked at it they published a side channel paper.

For pretty much all the technologies advertised from both AMD and intel to solve the various problems of trying to make people trust untrustworthy infrastructure with their private keys sidechannel attacks or other vulnerabilities exist.

As soon as you upload a private key into a cloud system you lost control over it, no matter what their marketing department will tell you. Self hosted you can properly secure your keys in audited hardware storage, preventing key extraction.

Regarding security issues, it will depend on the provider but one wonders if those are real or imagined issues?

Just look at the Microsoft certificate issue I've mentioned - data was compromised because of that, they tried to deny the claim, and it was only possible to show that the problem exists because some US agencies paid extra for receiving error logs. Microsofts solution to keep you calm? "Just pay extra as well so you can also audit our logs to see if we lose another key"

Stop sprouting that kind of bullshit.

Class based networking has been obsolete for 3 decades now - and RfC 1519 was quickly implemented, so pretty much by the mid 90s any device looking up network masks by classes could be considered some broken legacy device.

RfC 1918 - which allocates the private IP ranges - came 2.5 years after the introduction of CIDR, specifies the networks in bit notation, and only references what the equivalent networks were in class notation as reference for people who have been asleep for a few years.

So at least the british bit is accurate for you

My m13 is from 1994, and I have non-trackpoint Model Ms going back to the late 80s, all working perfectly fine.

They nowadays also have a paddle boat going to Korkeasaari (the 'Vispilä'). Haven't noticed it for a while as we usually just went via Mustikkamaa - but few weeks ago I offered the kids the option of going by boat instead.