Joe

That this is and will be abused is not in question. :-P

You are making a leap though.

While this is a popular sentiment, it is not true, nor will it ever be true.

AI (LLMs & agents in the coding context, in this case) can serve as both a tool and a crutch. Those who learn to master the tools will gain benefit from them, without detracting from their own skill. Those who use them as a crutch will lose (or never gain) their own skills.

Some skills will in turn become irrelevent in day-to-day life (as is always the case with new tech), and we will adapt in turn.

Indeed… Throw-away code is currently where AI coding excels. And that is cool and useful - creating one off scripts, self-contained modules automating boilerplate, etc.

You can’t quite use it the same way for complex existing code bases though… Not yet, at least…

This was similar to a trick that a few smaller (less serious) hobby-ISPs did back in the days of 14.4k/28.8k modems to take advantage of the “reasonably priced” business plans for ISDN. They’d register multiple businesses at a single address to qualify for the plans, then balance new egress connections across the pool using squid and other magic. Fun times…

I find it pretty useful to help get me over mental hurdle of starting something. So it’s faster than me procrastinating for another day. ;-)

https://www.urbandictionary.com/define.php?term=Hacker

“The media’s definition of the real term malicious cracker. A hacker used to be a well respected individual who loved to tinker with gadgets.”, plus a few other definitions.

Judges usually don’t know this stuff, but they primarily work with systems and software supplied by the state…whose experts should know what they are doing.

My bet is that this guy decided to work on personal equipment, probably in violation of the rules. Being a judge, he’s unlikely to be sanctioned for it, and will certainly learn from the experience. If anything, there may be some internal discussions which we’ll never hear about.

Law is an area where AI can add value, though… searching through past rulings and legal opinions is tedious, and anything that can assist to find needles in haystacks would be welcome. It shouldn’t be used to write legal judgements or arguments though…

But not Fire tablets (kids profile) or Samsung TV or many others that Plex currently supports.

JellyFin android phone app’s UI is a little weird at times, but does work pretty well for me.

…

What I would adore from any app would be an easy way to upload specific content and metadata via SFTP or to blob storage and accessible with auth (basic, token, or cloud) to more easily share it with friends/family/myself without having to host the whole damn library on the Internet or share my home Internet at inconvenient times.

Client-side encryption would be a great addition to that (eg. password required, that adds a key to the key ring). And of course native support in the JellyFin/other apps for this. It could even be made to work with a JS & WASM player.

Yeah, at that point I wouldn’t worry. If someone has docker access on the server, it’s pretty much game over.

Encryption will typically be CPU bound, while many servers will be I/O bound (eg. File hosting, rather than computing stuff). So it will probably be fine.

Encryption can help with the case that someone gets physical access to the machine or hard disk. If they can login to the running system (or dump RAM, which is possible with VMs & containers), it won’t bring much value.

You will of course need to login and mount the encrypted volume after a restart.

At my work, we want to make sure that secrets are adequately protected at rest, and we follow good hygiene practices like regularly rotating credentials, time limited certificates, etc. We tend to trust AWS KMS to encrypt our data, except for a few special use cases.

Do you have a particular risk that you are worried about?

Normally you wouldn’t need a secrets store on the same server as you need the secrets, as they are often stored unencrypted by the service/app that needs it. An encrypted disk might be better in that case.

That said, Vault has some useful features like issuing temporary credentials (eg. for access to AWS, DBs, servers) or certificate management. If you have these use-cases, it could be useful, even on the same server.

At my work, we tend to store deployment-time secrets either in protected Gitlab variables or in Vault. Sometimes we use AWS KMS to encrypt values in config files, which we checkin to git repositories.

Challenge accepted.