read a filename from the user

Honestly for something repetitive like this I’d suggest trying to avoid user interaction completely. It’s probably better to get that info from the DVD drive itself (blkid -o value -s LABEL /dev/dvd), or if that fails assign a number.

First they came for 486, and I did not speak out - because I’ve never actually owned a 486…

Yep, I think that “cut a liberal and a fascist bleeds” is in the same vein. I understand where it’s coming from, but I feel like instead of alienating people who self-identify as liberals we need to point out that liberalism is self-contradictory (private ownership of capital is eventually incompatible with equality before law, democracy and liberty in general). So, when times get tough (because of centralization of capital and thus power in the hands of few, combined with lobbying/bribes/regulatory capture) liberals will have to choose one or the other - those who choose private ownership are fascists, and those who choose liberty are communists. I don’t have a good catchphrase to encompass that idea, though.

Thanks! I will try and report the results back to you.

Do I have to build all other parts myself before then? (I’m trying to package it for Nix so that other people can also build it more easily)

Are there any instructions on how to build this all to get the ventoy installer binary that can replace upstream? Or is the project not up to this stage yet? I can go without Windows and FreeBSD support.

AppImage suffers from the same problem that Flatpak does, the tool do work offline aren’t really good/solid and won’t save you for sure

I’ve been using my laptop in areas without internet for days. It works fine.

It also requires a bunch of very small details to all align and be correct for things to work out.

I have appimage-run from nixpkgs installed, which handles all those details. They are also not too hard to figure out manually should you need to.

Imagine the post-apocalyptic scenario, if you’re missing a dependency to get something running, or a driver, or something specific of your architecture that wasn’t deployed by the friend alongside the AppImage / Flatpak (ie. GPU driver) you’re cooked.

GPU drivers are emphatically not part of the AppImage. They are provided by Mesa, which is almost guaranteed to be installed.

Meanwhile on Windows it has basic GPU drivers for the entire OS bakes in, or you can probably fish around for an installer as fix the problem

It’s actually the other way around - if you want your GPU to work properly on a new Windows install, you have to fish around for AMD/NVidia drivers. On Linux Mesa is pretty much pre-installed on all distros.

It is way more likely that you’ll find machines with Windows and windows drivers / installer than Linux ones with your very specific hardware configuration.

LMAO, try moving a windows installation from Ryzen+AMD GPU to Intel+NVidia GPU and let me know how it goes (hint: you will have to manually uninstall, and then install a shit ton of drivers, for which you will need internet).

Meanwhile I’m typing this from a (Ryzen+AMD GPU) desktop which has an SSD from my (Intel+integrated graphics) laptop. When I plugged it in, it booted into sway just fine, with complete GPU support and all, and the only reason I had to update my config is to make it more convenient to use on the desktop.

Linux is not the best “apocalypse” OS, but it sure is better than Windows.

There are ways to deal with this. There’s AppImage for GUI apps (that replicates the “just get an exe from a friend on a flash drive”) and lots of bundling programs for non-GUI apps (I use nix-bundle because I use Nix, but there are other options too).

Lots of distro installers work offline too, by just bringing all the stuff you need as part of the installer.

And one major benefit of Linux is that when stuff does inevitably go wrong, it’s infinitely easier to fix than proprietary garbage.

I’ve actually found RawTherapee to be slightly faster for what I’m doing (slight edits to my amateur photography)

They only dedup runtimes, not individual dependencies.

Not sure I follow you fully, but I think we agree.

No, not quite. Flatpak is containers - it just stuffs every dependency that an application needs in a directory with no way to deduplicate or update independently. Gobo is a bit more nuanced, since dependencies are shared between applications when the versions match.

I think the main premise is that every version of every software has its own installation prefix. This allows you to mix&match different versions, perform atomic upgrades, etc. You can think of it as a proto-Nix. TBH I don’t see much point in it now that Nix(OS) and Guix exist, or, if you don’t like their purity, stal/IX.