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

help-circle
  • I had to dig through the website shoving paid services down my throat and found the script builder, is that what you mean? If yes, I can see it generate either a command using chocolatey, or a config file (to feed chocolatey?), which seems to require me to install chocolatey manually first.

    Looks like it doesn’t meet the basic requirement of being a standalone script, and requires you to do extra setup first. I’m also very much not a fan of the website so far, but I can give it a pass since ninite being opinionated in the package choice is a subjective thing.


  • The great thing about ninite is how you can go there ahead of time and generate a single file, and when you’re done installing you just run that file. I suppose one could generate a batch script that installs stuff with some other package manager (you’d need to include install/update for it first, I remember reading about how Winget can come outdated with a broken version), but the issue with that is simply that ninite definitively exists and works reliably, while I don’t know any such service to generate install scripts.



  • Right, but that requires somebody to find and document exploitable firmware revisions, create and distribute hardware/software to exploit them, develop the aftermarket software/hardware, and all that potentially separately for each car model. And then that just becomes a war with the manufacturers, who might try to update their firmware more aggressively, lock things down more, and threaten/sue people working on such things.




  • some of my games didn’t launch, complaining about missing stuff.

    I don’t know Slackware, but I know on arch there’s the standard steam runtime version, and then there’s the unofficial steam-native-runtime, which uses system packages instead of steam’s own bundled runtime. And if we’re talking native Linux games, which is where the problem is, they tend to not work with steam’s runtime, presumably because they weren’t properly built to target it, and need to be launched with the native runtime (or switch to running the windows version with proton…)



  • I use KDE, but for my file manager I stick to Thunar, which I think is from a fork of GNOME. Does cause me some issues, since Thunar uses gvfs for stuff like mounting USB drives, whereas plasma loads kio, seemingly with no way to disable it, and they fight for control over devices.

    I remember one thing in particular that pissed me off about Dolphin is how it displays folders with 4 tilted miniature icons of files inside, with no way to turn it off, or even just make them not be randomly tilted. Such a minor thing, but when I was choosing it was between clean icons and a scrambled mess, I went with clean icons.

    Ultimately, I wish gvfs/kio wasn’t an issue, but I love to have the freedom to choose.



  • 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.




  • 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.



  • I don’t think “update notes or any marketing material” qualifies for making this kind of change non-silent - if the update is pushed through the same channel as regular security updates, and doesn’t explicitly notify the user the behavior of the button has changed, that’s pretty silent.

    Often for those kinds of updates software will show a special introduction screen, tutorial, or outright a prompt asking you to choose between the new and old behavior - but that’s software from people that care about the user having a good experience, and making such changes is a big deal for them.