You don't even have to weatherproof the rack, putting racks into shipping containers is already done to some extent (and multiple deployments are to my knowledge working fine). It is often also marketed as "module data centers".
The main problem here is that it reduces efficiency (cooling a large datacenter is more efficient per Watt of dissipated heat than a shipping container) and increases initial cost (building in a shipping container is not actually as easy as doing it in a normal-ish building).
Portability (when offline, you can put a shipping container like this on a truck and cart it around) and availability (no need for a new/refit building, only power is required and could be included in the container with a generator (gas/diesel)) are the main reasons for accepting a higher TCO here.
NextCloud generally appears to use their own design system everywhere, Android apps are also not in Material or on iOS (iirc) in Cupertino. It makes for a subpar experience in general but is consistent.
NextCloud needs tuning (mostly of php-fpm and caching ) oob to be fast/usable in my experience. Just throwing resources at it won't make it faster as the defaults are generally quite conservative.
As a side note, it's PHP so your single core clocks will generally be more relevant for latency than multi-core performance, feeding many cores requires a lot of divisble work.
At least in germany it feels like you need a very dedicated and persistent person to make the case against a company/service (bonus points if they get media attention). Other countries are a bit better but it generally is not very consistent.
The enforcement for most small to mid-sized companies is often just not present and resources for relevant agencies are often only reluctantly allocated. Ime, in government institutions it is generally not very respected as it "impedes progress".
To be fair this likely should be handled by the interpreter/compiler for the compiled JS. V8 probably can merge this into one loop or another similar based on runtime types
You can iif you live in on of the supported cities that is not currently suspended. Waymo is a promising participant here, but it very much isn't at the "just be driven to work stage" for almost everyone.
I'm sometimes amazed by project sizes, a 30k line codebase is small? I'm aware that the ceiling is high but 30k lines of code can encode so much information and behavioural nuance.
Maybe this is just my backend/network focus with Golang though. Scaling beyond 10-15k lines of code always was quite intimidating as it is usually where I lose the ability to just keep a model of the codebase fully in my head.
Many distros deal with the problem of learning about these issues the same time as the public. Some have fast track processes to ensure patches can get into their stable/rolling releases but it is still a lot of work (especially as kernel updates usually mean that automatic updates won't fully shipped you (without alsp automatically rebooting after an update)).
It already has official packaging for Tumbleweed, see https://github.com/mullvad/mullvadvpn-app/issues/2242 for the upstream issue. Leap can use the normal Linux application, you will just have to provide the dependencies yourself.
Lanzaboote is great, I've been using it for almost a year now in a dual boot with Windows 11 for full secure boot on my desktop. It is quite stable (notably was set and forget) and the initial setup was relatively easy.
Not damaging their relationship with Google as a vendor most likely. For better or worse, GrapheneOS is depend on Android which is controlled by Google.
I feel for the people living there and being affected by the pollution. The long term effects of chemical pollution are ugly.
But the CEO in the intro just seems like an odd choice. PFAS were known to cause issues for a long time, if you continued to use them for years then it is in your back too.
Being "surprised" this might eventually affect your own product line just seems naive. You might have trusted 3M but just blindly trusting a supplier is not an excuse at some point.
Yep, that is accurate. There is also a command/API route to find the path on disk iirc.
In my setups it just was easier to use fixed paths (or relative to project dir) from a permissions management perspective. Backup tools did not always have to/should run as root which is helpful on machines providing multiple distinct services.
Putting borg or a similar tool in a container that is part of the compose manifest file can also help. I haven't seen this used in practice though yet.
Ime, the only useful product tours where in games, I. E., tutorials. This usually extends up to in-game hints at certain features like a characters ability. A lot of software can probably pull inspiration from there in regards to including hints with minimal interruption during usage (tooltips that are shown longer the first time you use something etc).
The "easiest" way is to use bind mounts to a local directory (or multiple directories) instead of volumes. Then you can just use normal backup tooling.
Docker volumes (and bind mounts) however have the minor problem of being hard to get a consistent copy to without stopping the service. You can work around this by, e. G., having ZFS or btrfs as the underlying FS and making a snapshot there. Otherwise, your software (like PostgreSQL) might also have other online backup tooling.