Understandable, he was right very often and "only" his tone was....unfiltered. but I ignore the "was right" part when using that phrasing :)
I'd like to imagine that this would be close to the phrasing Linus himself would choose, although I could be off of course!
Take a sentence with 200 characters then.
And your opinion is exactly that and doesnt match security research:
For the following you're not the target group but others reading this who might want to make their lifes easier. Just from your way of writing I at least don't expect that minor sources like okta or the NCSC will change your mind.
( article links with high level descriptions and links to their primary sources)
https://www.okta.com/identity-101/password-vs-passphrase/
https://www.4bis.com/passphrase-vs-complicated-passwords-passphrases-are-best/
https://specopssoft.com/blog/passphrase-best-practice-guide/
I really don't enjoy Linus' content without context I have to admit.
He was an absolute dipshit back then and he's one of the few people I've read about who not only acknowledged that but also put effort into changing it - and succeeded.
Yeah the newer mails are not as funny to third parties anymore but I'm really happy for him and especially the kernel devs around him.
There's a xkcd for that of course! Linking directly to the explain as it has more info but the important thing is: password guidelines tricked humans into thinking in a machine way about safe passwords but long pass phrases are more secure from an entropy point of view and way easier to remember!
https://www.explainxkcd.com/wiki/index.php/936:_Password_Strength
Just to herd a warning then from a Dev perspective: you want to remove them before interacting, not just opening.
I can send files without ever opening them and the sharing would keep the meta data if you'd not open the files manually with the cleanup tool.
Personally I've had a camera app a while back that I could configure which meta data it saved but I simply stopped sharing photos on social media and so this become s non issue for me :)
Honestly I find myself in your text a bit so perhaps I'm projecting:
If it's purely for specs than the other poster is right. You won't get bottlenecked with RAM even at 32GB. So if you're being capped now and short on cash just upgr to 32GB and future proof when the future is closer around the corner.
But to me it sounds like you might just want s complete upgrade and are now looking for a reason (that's the potential projection part :p). If that's the case then check your budget and go for it - but don't try to sugar coat it: the reasonable path is to do the smallest upgrade step possible that fullfils your needs!
DHL. Fucking DHL. Not sure if it fits your question but I got triggered badly here.
They removed all forms of contact except WhatsApp and their shitty z broken chat bot. If there is ever a use case for LLM than this is it. But they use s system that can either sell you stamps or breaks.
Oh but you can call them. Do you can talk to there chat bot. Once you've broken it enough for it to grant an audience with a human being the connection drops.
I very rarely get worked up by broken systems but someone else chose to use this shit shoe and I'm now imprisoned in their web of bullshit.
Oh yeah I see...
As some old philosopher once said: "shit's fucked, yo".
Seems to be appropriate here.
Because a security engineer focused on cloud would rightfully say "pod security is not my issue, I'm focused on protecting the rest of our world from each pod itself.". With AWS as example: If they then analyze the IAM role structures and to deep into where the pod runs (e.g. shared ec2 vs eks) etc. then it would just be a matter of different focus.
Cloud security is focused on the infrastructure - looks like you're looking for a security engineer focused on the dev side.
If they bring neither to the table then I'm with you - but I don't see how "the cloud" is at fault here... especially for security the world as full of "following the script" people long before cloud was a thing.
Spannend!
Wenn ich das richtig lese zahlen Selbstständige allerdings hier mit zu den atypischen ("einer der Bedingungen nicht erfüllt" und "muss in einem unbefristeten Angestelltenverhältnis sein").
Wäre schöner, Unternehmer und Selbständige raus zu nehmen, denn diese Gruppe hat nicht die Problematik, der "atypischen" Gruppe wir im Artikel beschrieben.
Bitte korrigiert mich,falls ich da einen Denkfehler habe.
Not stupid, friend, careful about unknowns :) and it's normal that a project wants to receive tested and validated pull requests - finding good testers is nearly as tough as finding devs I think.
And you're right: your situation is what docker usually excells at.
To address your concerns I suggest a three stage approach:
Pull/build from your repo in parallel with new volumes own port(s) etc. create some dummy data in there and rebuild with the test data, check that reconstruction works.
Then shut it down and remove it again. copy the volumes of your existing container and use that for the second instance.
If everything works fine there as well then shut down the old version, create a backup of the volumes and update it with your version.
This way you're safe and have an easy time seeing where and when something breaks at the same time.
You could also start with the last step and the backups only - but this way you can take w conscious step after the other. Your choice!
One could argue they a reading service should not alter the thing that's read. Android is not a quantum state!