The main “wasted” resources here is storage space and maybe a bit of RAM, actual runtime overhead is very limited. It turns out, storage and RAM are some of the cheapest resources on a machine, and you probably won’t notice the extra storage or RAM usage.

VMs are heavy, Docker containers are very light. You get most of the benefits of a VM with containers, without paying as high of a resource cost.

We should probably make a poll thread here, it could be pretty interesting to see everyone’s primary and secondary motivations.

There are a few decent options, all with some caveats:

• Seafile - wicked fast, but uses a funky disk format, so you need either a FUSE layer or the web UI/API to access anything
• OCIS/OpenCloud - default install uses a funky file format, but you can change this to POSIX if you want (experimental on OCIS, might be default now on OpenCloud?)
• others - probably work fine, but they get less blog attention

I’m playing with OCIS and I like it so far. There was some funkiness when I had things misconfigured, but now that it’s working, I like it.

It’s the easiest way to get stuff running, so I’m guessing that’s why. But it’s far from the best way.

I’m not sure how the weight is distributed, so maybe? Maybe it needs sandbags in the front?

Either way, it sounds workable as an around town truck, even in snow, without 4WD.

It usually comes down to privacy and independence from big tech, but there are a ton of other reasons you might want to do it. Here are some more:

• preservation - no longer have to care if Google kills another service
• cost - over time, Jellyfin could be cheaper than a Netflix sub
• speed - copying data on your network is faster than to the internet
• hobby - DIY is fun for a lot of people

For me, it’s a mix of several of reasons.

The only real problem here is the price. It should’ve been more like $30.

Yes please!

And that’s a big reason why I don’t buy Ubisoft games. Even the old Ezio trilogy has that crap.

So yeah, no more.

And that’s why I generally avoid the genre, not because “survival” sucks, but because bad “survival” sucks.

Nice, amateur hour it seems.

That’s a good way to always keep chips on hand.

Eh, you can be reasonably sure that GrapheneOS or other Android ROMs without any Google Play apps is private.

Ouch.

This plus those wearable battery things that recharge with movement could be super cool. Or just plug into a wheelchair battery or something.

X to doubt…

Maybe you just have low expectations, but I’ve seen so many threads about terrible performance on top tier hardware. That’s inexcusable.

And this is why I don’t buy day 1. Performance actually looks reasonable compared to other day 1 releases, but it’s still not what I want to play. I bet most of these issues will be resolved in a month or two, and definitely resolved by the first sale, so I’ll hold off. It’s not like there’s going to suddenly be content to miss out on, it’s a remaster, so waiting is absolutely reasonable.

That’s fine honestly, provided it’s smooth. In the video, there was a fair amount of hitching though…

Are you really going to take it into the woods with just two seats, mediocre suspension (likely, given the limited payload and towing), and limited range? Just get a Polaris side-by-side or something, they’re built for that.

I get it, a cheap truck is appealing, but at this price target, it’s going to make a lot of compromises. It should do fine in plowed roads (might need sandbags in the back though), so it’ll probably be fine for around town use, which seems to be its target.

Let’s look at a scenario where there’s an exploit that requires a change to an API. With JavaScript, the browser vendor can ship a fix to the API, and web devs update their code. With a plugin, the browser vendor ships a patch, then the plugin vendor needs to ship a patch, and then web devs need to update their code. Some plugin vendors will be slower than others, so the whole thing will see massive delays and end users are more likely to stick to insecure browser versions.

Plugin vendors are going to demand the same API surface as current web standards and perhaps more, so you’re not saving anything by using plugins, and you’re dramatically increasing the complexity of rolling out a fix.

I think the current web is a decent compromise. If you want your logic in something other than JavaScript, you have WebAssembly, but you don’t get access to nearly as many APIs and need to go through JavaScript. You can build your own abstraction in JavaScript however to hide that complexity from your users. The browser vendor retains the ability to fix things quickly, and devs get flexibility.