LLMs were -in part- designed as translation tools. It's one thing they do really really well.
https://arxiv.org/html/1706.03762v7 (Attention is all you need) "Experiments on two machine translation tasks show these models to be superior in quality while being more parallelizable and requiring significantly less time to train."
Ok, looking that up, that was quite literally one of the main design goals.
And they're really quite good at translating between the languages I use. They're the best tool for the job.
Anna's Archive ISBN visualization is fascinating; it really shows how fragmented and incomplete the ISBN landscape is. We don't use their data directly (licensing concerns), but it confirmed what we were seeing: massive gaps in non-English coverage.
WorldCat is great for library holdings but harder to use for translation discovery specifically, it tells you "this library has this edition" but doesn't easily answer "has this book been translated into Basque?" across its whole catalog. We'd love to integrate it eventually, though.
Right now Wikidata turned out to be the secret weapon: it has structured translation relationships that none of the others provide.
Same thing for allowing specific sudo-commands. Many tools (like vim or the tools mentioned in the article) would have the same problem when allowing them to be run with root privileges.
Now I feel a bit more justified for over-engineering my automatic restic backup to not run as root, but to instead use "capabilities" to read files it doesn't own.
Namely, CAP_DAC_READ_SEARCH [0] and related systemd settings. The only problem is that it inhibits using a convenience/wrapper script.
Some at work want to let me run sudo vim only to edit my hosts file. This is silly for a variety of reasons, one of them being that vim can allow the user to exec arbitrary commands. If you give me root for vim, just save me the trouble and let me have unrestricted root so I can do my job.
I had the same few years ago. When I pointed out that I can get full root with most of the whitelisted commands they answered "We know. It's not about security but to prevent lusers from accidentally rm -rf /* the server. Feel free to spawn a root shell. You obviously know what you do"
I deal with some regulated things and some users who usually wouldnt be allowed to see/work on a thing are granted special access to do so, with extreme limitations. Recently i was approached asking if we could strip down the users desktops to no gui, no sudo, for use as a jumpbox. I explained why users need sudo to do what they need, and was asked about limiting sudo.
Its really tough to tell someone who is all about security (not linux security but regulatory security and such) that basically granting any bit of sudo access can lead to full access.
There is a way that this can be handled, but its honestly sort of an afterthought functionality. facls. You can delegate multiple owners/groups and permissions for things, and it can work well, but you have to deal with facls on multiple fronts, setting them for basically the entire system. facls are great, in theory, but they feel like such an afterthought that they are often ignored.
You could provide decently meaningful and targeted sandboxing using mount namespaces and an overlay FS, while retaining sudo privileges for what you need to do.
Yeah, and then it probably isn't the developers job to fix that but rather the DevOps engineer's one.
Also saying "the developer has to fix this" is something we tried to abolish when talking about DevOps. What about shared responsibility? Bridging the knowledge gap.
Sure. But the malaise of smug people taking decisions that are outside of the scope of the software is creeping into linux too. It is up to me decide what is secure, not them.
reply