Comments by "Lawrence D’Oliveiro" (@lawrencedoliveiro9104) on "Linux AppImage Finally Addresses Greatest Flaw!!" video.

  1. 4:00 What it actually means is that you don’t need a kernel module to implement the filesystem. These take a special kind of chops to develop, as mistakes can screw up your kernel, cause crashes etc. FUSE lets you write the filesystem code to run in an ordinary user process. So any mistakes should only mean that process dies, and your system can continue running.
    3
  2.  @terrydaktyllus1320  I’m sure this will become relevant the day you can show us a microcontroller running an appimage.
    2
  3. There is already an XDG standard, the .desktop file. This lets you define menu items, icons, even document templates. All the major open-source GUIs understand them. They even share common standards for letting you customize things. That’s why you can switch GUIs on a Linux distro and see all the same apps, icons, everything.
    2
  4. 6:00 I notice that in the Debian repo there are separate packages for “libfuse2” and “libfuse3-3”. Typically this happens because of incompatible ABI changes. Otherwise you should be able to upgrade to a newer version of a package with the same name, and existing code dependent on that should just keep on working. Consider that the transition from “libc5” to “libc6” happened about 2 decades ago, and even with all the new stuff that has gone into GNU libc since then, there is still no “libc7”, and it could be there will never be. That’s because they found ways to keep all the changes so far backward-compatible.
    1
  5. It’s an incompatible ABI change. For example, I currently have both libfuse2 and libfuse3-3 packages installed; one has a library called libfuse.so.2, the other has libfuse.so.3. That way client code linked against one version will not accidentally pull in the wrong version, since the file names are different.
    1
  6.  @mgord9518  Why, do they tend to maintain their value? Or maybe they deprecate them instead?
    1