Yes kinda? It depends a lot on the system. It’s still pretty common, even with containers like docker, for different services to run with different accounts and permissions. Eg. If you have a webapp with a small database or something, the web server will be www-data or whatever and the db will be a different user account like a postgres user or something. Even a fresh Linux install will have a separate user account for things like ntp (or systemd-timesync) etc. Users aren’t usually people, they’re daemons with limited scope and rule of least privilege.

Even if it’s all docker containers and you deploy them with the same docker account on the host, there are almost certainly a bunch of different accounts inside.

That way if there’s some vulnerability in ntp or something, an attacker might have permission to mess with the time but can’t, in theory, take over the whole container.

I think there is a trend towards caring less about that aspect of defence in depth if each service is in its own container and just rely on isolation. People are deploying services running as root with ansible or even just in dockerfiles, and not caring about it because there’s nothing else on the box for an attacker anyway. If they compromise the service, they’ve already got what they want.

I get the thought process but it still doesn’t feel good to me. If some docker bug shows up that allows a container user with root to break isolation and use the shared kernel to pivot to the host or other containers, then that one dodgy webapp that’s not running as a restricted user can become a part of a larger kill chain. It’s really easy to develop systems with least privilege in mind and there’s not much downside to doing it. It’s a good habit to create different accounts for different services (even if there’s one admin/docker/ansible/whatever account for deployment).

Your user account can run applications and read and write to a lot of locations on the disk.

So it can be used to run malware (cryptominers, ransomware, RATs etc.) Exfiltrate the data your account has access to, download or plant malicious or illegal data, use your internet connection to attack other systems with DOS or similar, use any logged in social media accounts to attack or spam your contacts, steal saved passwords and credentials from your web browsers, use your peripherals or connected devices (printers cameras microphone speakers), pivot to access other services on your local network (smart devices, IoT, TVs, home lab) etc.

There are comparatively few things an attacker wants on a desktop that actually require root access. It’s mostly just system files, package management and settings changes that require root to mess with. Eg. You would need root to dump a shadow file or stuff like luks encryption keys from kernel memory, but if an attacker has your logged in user account, the disk is already decrypted and account is already logged in.

I think they’re saying that it’s not generating slop from nothing. They take the artist’s “structure data” as a “ground truth” and the generation is “guided” to generate slop that won’t deviate too far from the original?

What debarchery!

For the unprivileged container thing, containers tend to be lighter on resources than VMs at the cost of a little isolation (they share the same kernel as proxmox which could have security implications).

The ability for lxc containers to run unprivileged with all the restrictions that entails alleviates a bit of that security risk.

Both options are generally considered pretty secure but bugs/vulnerabilities could break isolation in either case. The only real 100% safe isolation is bare metal.

I tend to run containers unless I have a really good reason to need a VM, and run unprivileged unless I have a really really good reason not to.

My recommendation is a VPN server to connect in from outside and have the default gateway for the VPN clients be a server that acts as a router that’s set up with your commercial VPN.

That way, you can be outside on a phone or a computer, access your internal network and still have your public internet traffic go out through your commercial VPN without having to be able to configure multiple VPN connections at once (eg. Android doesn’t support that).

Eg. 2 debian proxmox containers. One that runs wireguard (head/tailscale might also work here?) for external access and one that runs mullvad(or whoever) VPN cli and IP forwarding to be the gateway for your clients.

Only downside is the extra hops to send everything through your home network first rather than straight to the commercial vpn which is probably fine depending on your speeds. You can always disconnect and connect directly to the commercial VPN for faster internet traffic if you need to.

Their concept artists are allowed to use some generative AI tools to explore ideas and speed up their workflow. They’re currently hiring a bunch more concept artists (both juniors and a senior character artist) so if you’re trying to get a job: https://larian.com/careers/4fd694b3-ece7-4307-9949-15cac512a815

Great place to go if you’re looking for a concept artist job.

Awesome! I’m very much looking forward to it.

Hopefully there’s some more good mostly consumer-ready devices soon. The software side I’m happy to play with and write my own assistant logic. The gaps in the home assistant software I can code myself but the hardware stuff is outside my wheelhouse.

The issue with that is there isn’t an expensive option either. The only thing close is the home assistant voice preview and it’s still very “preview”. There’s not really any way to do it well at any price point right now.

This is very true, though I’d argue that Windows makes most of the same assumptions with user accounts. Also, the internal threat model is still important because it’s often used to protect daemons and services from each other. Programs not started by the user often run in their own user accounts with least privilege.

You no longer have 10 different humans using the same computer at once, but you now have hundreds of different applications using the same computer, most of which aren’t really under the user’s control. By treating them like different people, it’s better to handle situations where a service gets compromised.

The question is more about passwords which is mostly down to configuration. You can configure Windows to need a password for lots of things and you can configure Linux to not. They just have different defaults.

The big difference between UAC and Sudo is that you can’t as easily script UAC. They can both require (or not require) a password but UAC requires user interaction. Sudo has no way of knowing if it’s being interacted with by a person or a script so it’s easier for applications to escalate their own privileges without a person doing it. UAC needs to have the escalation accepted with the keyboard or mouse.

There’s still plenty of sneaky ways to bypass that requirement but it’s more difficult than echo password | sudo -S

And Debian Sid is still stuck on 6.3.6 :(

Hopefully they figure out the qt update thing and get the new version packaged soon?

Yeah, it’s a shame because some of those OSM-based ones are really close to being perfect. It just seems like it’s really difficult for the open source devs to reconcile OSM data with GTFS and timetables for some reason.

Often the “local app” is basically a proprietary wrapper around Google maps.

I want to like this, but because there’s no GTFS/public transport timetables, it makes it kinda impossible to use it to get around cities that publish their transport data.

PT is the one thing I’m still stuck on Google maps for. I REALLY want an open source alternative.

They also force you to pay a 99USD yearly fee just for the privilege of being a developer.

I feel like that would make them much harder to get running on different things. No compiled code means you would have to rewrite the whole game for different instruction sets. Very difficult for anything that isn’t x86.

I’d add to this to say that redis as a key-value store often sits alongside a relational database like postgres etc. to act as a cache for it.

Basically, requests to be sent to the relational db (like postgres) get turned into a key and the results stored as a value in redis. Then when the same request comes through again, it can pull the results quickly out of the key-value store without having to search postgres by running a long SQL query again. There’s a few different caching strategies to keep things up to date or have the cached data expire regularly, etc. but that’s the gist of it.

Important to note that not all applications need something like that and not all queries would even benefit from it (postgres is pretty fast and can even do that kind of thing itself) but if there’s a lot of users running the same slow query over and over, caching the results can help immensely.