• 0 Posts
  • 138 Comments
Joined 2 years ago
cake
Cake day: June 25th, 2023

help-circle
  • One counterpoint - even with a weak speed to capacity ratio it could be very useful to have a lot of storage for incremental backup solutions, where you have a small index to check what needs to be backed up, only need to write new/modified data, and when restoring you only need to read the indexes and the amount you’re actually restoring. This saves time writing the data and lets you keep access to historical versions.

    There’s two caveats here, of course, assuming those are not rewritable. One, you need to be able to quickly seek to the latest index, which can’t reliably be at the start, and two, you need a format that works without rewriting any data, possibly with a footer (like tar or zip, forgot which one), which introduces extra complexity (though I foresee a potential trick where the previous index can leave an unallocated block of data to write the address of the next index, to be written later)




  • Shouldn’t it be more efficient to download only the changes and patch the existing files?

    As people mentioned, that becomes problematic with a distro like arch. You could easily be jumping 5-6 versions with an update, with some more busy packages and updating less frequently. This means you need to go through the diffs in order, and you need to actually keep those diffs available.

    This actually poses two issues, and the first one is that software usually isn’t built for this kind of binary stability - anything compiled/autogenerated might change a lot with a small source change, and even just compressing data files will mess it up. Because of that, a diff/delta might end up not saving much space, and going through multiple of them could end up bigger than just a direct download of the files.

    And the second issue is, mirrors - mirrors need to store and provide a lot of data, and they’re not controlled by the distribution. Presumably to save on space, they quickly remove older package versions - and when I say older, I mean potentially less than a week old. In order for diffs/deltas to work, you’d need the mirrors to not only store the full package files they already do (for any new installs), but now also store deltas for N days back, and they’d only be useful to people who update more often than every N days.







  • I think you’re wrong about one thing - it’s not about compute cost, but about complexity of accounting for latency. You could check if the player can see the enemy they’re claiming to have shot, but you really need to check if they feasibly could’ve seen the enemy on their computer at the time they sent the packet, and with them also having outdated information about where the enemy was.

    The issue gets more complex the more complex the game logic is. Throw physics simulation into the mix and the server and clients can quickly diverge from small differences.

    Ultimately, compensating for lag is convoluted, can still cause visible desync for clients (see people complaining about seeing their shots connect in CS2 without doing damage), and opens up potential issues with fake lag.

    More casual games will often simply trust the client, since it’s better for somebody to, say, fly around on an object that’s not there for other players, than for a laggy player to be spazzing out and rubberbanding on their screen, unable to control their character.




  • Both java and go seem excessively complex at runtime for fundamental system utilities, featuring garbage collection. Rust, on the other hand, keeps the complexity in the compiler and source, keeping the runtime code simpler. And of course it’s doing that while trying to make it easier to manage memory and harder to make mistakes, without forcing extra runtime logic on you.



  • I think most of the work is in the fact that there often isn’t an “equivalent call”, and it can be quite a lot of code to make it work. One funny thing is the whole esync-fsync-ntsync issue, where synchronization is done differently on Linux and on windows, and translating it was a big performance hit, and difficult to do accurately. If I understood correctly, esync, fsync and ntsync were a series of kernel patches implementing additional synchronization code in the kernel, with ntsync actually replicating the windows style.






  • KubeRoot@discuss.tchncs.detoLinux@programming.dev*Permanently Deleted*
    link
    fedilink
    English
    arrow-up
    3
    arrow-down
    2
    ·
    2 months ago

    And then fuck it up by pointing Linux at your windows EFI partition, end up with neither system bootable and make things worse as you panic and try to rush a fix without understanding what you’re doing.

    If you’re new to how it all works and having a working machine is important, best to keep it simple and as separated as you can.

    I’m also not convinced that “Windows doesn’t know about the other partitions”, that sounds like the kind of thing that’s true until it isn’t and it overwrites your Linux bootloader.