Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)SC
Posts
1
Comments
227
Joined
2 yr. ago

  • Mullvad (and every other decent VPN) supports WireGuard and OpenVPN configurations that will be supported on any distro through the network settings without the need for additional software. It's also pretty likely the mullvad client will be in the software center of whatever distro you're using

  • NFS is generally the way network storage appliances are accessed on Linux. If you're using a computer you know you're going to be accessing files on in the long term it's generally the way to go since it's a simple, robust, high performance protocol that's used by pros and amateurs alike. SSHFS is an abuse of the ssh protocol that allows you to mount a directory on any computer you can get an ssh connection to. You can think of it like VSCode remote editing, but it'll work with any editor or other program.

    You should be able to set up NFS with write caching, etc that will allow it to be more similar in performance to a local filesystem. Note that you may not want write caching specifically if you're going to suddenly disconnect your laptop from the network without unmounting the share first. Your actual performance might not be the same, especially for large transfers, due to the throughput of your network and connection quality. In my general experience sshfs is kind of slow especially when accessing many different small files, and NFS is usually much faster.

  • IMO the syntax is fine except for the borrow checker shit that just looks arcane. The fact that everything cargo drags in is statically linked really turns me off the language for anything serious. It's really unfortunate because I'd otherwise put some time into learning it, but it seems like the rust foundation is fine with this (ridiculous IMO) workflow.

  • Yeah, for this reason I would pretty much never encourage exceptions in Python over some other form of error handling. It's so frustrating when called code throws some random exceptions that are completely undocumented. This is one of the few things Java got (sort of) right

  • Probably the worst game launch in my memory, like the Arkham game that was pulled from steam but it wasn't just broken on AMD cards. Game would crash every 5 - 10 minutes, servers would rarely make it through a match without crashing so your progression wouldn't be saved, performance issues, etc. It took them over a year to get it stable, but after they fixed it it was a great game.

  • I don't think paid online is gonna happen. The only way I could see them doing it would be if they left steam so valve couldn't refund the game, made an absolutely killer multiplayer game, idk if Helldiver's would even be good enough, and bait and switch everyone after the game got really popular. Even then most of the players would probably just go to another game.

  • It'll definitely need some kind of quality enforcement to make hosting work. It'd be really useful if the app would automatically transcode to the server's preferred quality when uploading, using the uploaders device. If the server has to transcode all the video the compute costs could get astronomical.

  • A dedicated server is needed because something needs to keep a catalog of the smart devices available on your network and ideally be accessible to many people in one household. You could make a system that went phone -> device but you would need to set up each device on each phone you wanted to use, which isn't a great user experience. You could also run into issues where devices would need to handle multiple conflicting commands from different users coming in at once. Since smart devices are usually trying to use as little power as possible, that extra complexity would hurt you in that department. The third reason is that having a separate server enables automated workflows that would depend on an always online server that orchestrates multiple devices. For example, let's say you have some automatic insulating blinds, a smart thermostat. You want to raise and lower the blinds to maximize your energy efficiency. Since you have the dedicated server, that server can check the temperature set point of your thermostat, current weather, and sunrise\sunset times. If it's sunny out, and your set point is higher than the outdoor temperature, the server can raise the blinds to let warm sunlight in, and vice versa. If only your phone could control the devices a workflow like this couldn't work when you were out of the house.

  • The main problem is weapon durability is in direct contention with how the dungeons are designed. The shrine puzzles try to encourage experimentation in finding solutions, but when using the time lock tool hitting objects depletes your durability, then once you run out of weapons, you need to leave the shrine to find new weapons\materials which ends up being a big interruption in the main gameplay loop. It's made even worse by the fact every weapon applies a different amount of force to a locked object per hit. I'm not sure what interesting and creative problem solving weapon durability adds. It really just encourages you to avoid combat and use easy to come by weapons wherever you can.