Yeah that site is pretty good. There’s a lot of information though. I think a good starting point is maybe this page: https://reproducible-builds.org/docs/env-variations/
Yeah that site is pretty good. There’s a lot of information though. I think a good starting point is maybe this page: https://reproducible-builds.org/docs/env-variations/
An important point to add for someone who hasn’t heard of reproducible builds before: The key difference to a normal build process is that it is 100% deterministic i.e. it produces exactly the same output every time.
You might think that most built processes would be like this by default, however this is not the case. Compilers and linkers usually have some non-deterministic values that they put in the final binary such as timestamps. For a build to be deterministic these sources of variation must be disabled or mocked to be a repeatable value (i.e. not based on the actual compile time).
It seems like it’s alive again. You saved it OP!
Would a game that is essentially a micro Linux distro count? I feel that should be pretty doable as a bootable USB stick or CD.
If you did it that way you’d have to bundle the Linux kernel plus graphics drivers at a minimum. But I wonder how much of the OS you could avoid having. Certainly you wouldn’t need a Desktop Environment. I wonder if you would need something like X or Wayland or if you could get away without that (to run games built in a normal-ish userspace way). I guess finding the minimal environment for SDL would be a good starting point. That sounds like an interesting exercise for sure.
Although something like that probably isn’t as pure as you’re looking for, it would be pretty cool to do anyway. Maybe we should start a club.
I found this good video by Trace Dominguez. He gives a good overview and also mentions a bunch of new studies that are being done https://www.youtube.com/watch?v=dpjGLLbWZJ0
This is bizarre. Snap has improved a tiny bit over time, but it continues to not be that great. Meanwhile, flatpak is miles ahead. Things are generally just smoother and less annoying, even when Snap is working as intended.
Personal anecdote: I was having no end of trouble with Inkscape, it was just not working, very unreliable, all sorts of very odd issues. It got worse and worse over time to the point where it didn’t even seem to understand paths to open files anymore, if it even felt like opening that day. I tried reinstalling, clearing the config, all sorts of things. I suspected maybe the version of Inkscape Snap was giving me might have a bug in it so I was looking around for alternative ways to install an older version and then for some reason I tried Flatpak. It was like some kind of magic. Totally night and day. All of a sudden Inkscape had absolutely none of the issues that the Snap version had. It just worked. After that I realized that it hadn’t been a bug in that version of Inkscape at all, it was just Snap.
I haven’t had any issues with any other Snaps, but that incident really opened my eyes to just how bad things can get if a program isn’t packaged correctly.
Something I never seem to hear explained: What IS long COVID. Is it damage to lungs, is it a change in the behavior of the immune system, is it something that happens in the cells? Where in the body is it hiding? Is this something we just don’t know yet?
It would make sense that eventually you could do both real-time and after-the-fact calculations depending on whether real-time communications is available. Presumably it will depend on the specific application
Indeed. It seems this wouldn’t be useful for applications where real-time position is needed. You would most likely do the calculation at a later time like in the Miikshi video. It’s a little confusing from the article, but the video actually does a good job of explaining this limitation.
Unfortunately given how hard reproducible builds are they aren’t done much, and aren’t talked about much. A vicious cycle. A nice short video would indeed be helpful for understand and awareness.