Relevant repos:
https://github.com/sailfishos/qtmozembed https://github.com/sailfishos/embedlite-components https://github.com/sailfishos/gecko-dev
296 karma · joined December 7, 2020
Relevant repos:
https://github.com/sailfishos/qtmozembed https://github.com/sailfishos/embedlite-components https://github.com/sailfishos/gecko-dev
My only problem is that BIOS updates delete the systemd-boot efistub, probably caused by the vendor only having exceptions for the Windows bootloader and GRUB.
FAT32 is still very dominant & I wonder why Microsoft & Apple don't push the vendors to use exFAT. Users unaware of filesystems won't need their stick being recognized by the UEFI, but they will have files > 4GB.
§1Contract, test and evaluation period The test period of the product begins on 01.06.2023 and applies to the non-guaranteed maximum duration of one year. We reserve the right to refuse service to any person at any time for any reason. All files will be deleted after expiration of the testperiod. The service can have software bugs which can result in losing data.
It's up to the instance admin for Invidious and the behaviour of Piped to proxy googlevideo. Not sure if it's visible at Invidious if you use an instance that doesn't proxy the traffic, but you can be sure it's proxied when you use Piped.
They need to reliably filter secrets or they are in trouble once Copilot suggests them.
Podman-compose was feature-lacking and beta even when podman already had its 3rd major release, while the communitcation was that "Podman is a drop-in replacement for Docker". It just wasn't a drop-in at all for all compose users. People either stopped considering Podman or enablded the socket daemon, so that they are still able to use docker-compose. But this goes against the design ideas podman had.
Feels as half-baked as Ingnition, which also still feels very bare-bone, as if there's no financial interest to enhance it further.
https://wiki.archlinux.org/title/Dm-crypt/Swap_encryption
Does someone know how it's handled on Windows and macOS?
RMS' management of the GNU project derailed long ago, from him vetoing for his jokes in project he's not involved anymore, going OT & insulting on mailing lists and often threatening GNU maintainers by stating that their project belongs to GNU, not them.
If someone knows why this sandboxing is better/worse than SELinux or AppArmor access rules, can you pls elaborate? I'd really like to know.
> The purpose of an AppImage is simply to condense such a tarball to a single runnable file, for convenience - nothing more.
This still forces the user to learn the internals if the AppImage doesn't work. E.g. if MATLAB would use Appimage, I'd have to extract squashfs contents, fix the broken libraries inside and the repackage it. Or I would have to write a script to start the executable outside. It's a simpler from a pure technical standpoint when it's a tarball + wrapper script.
> Snap permanently runs a daemon, and Flatpak requires you to run programs with "flatpak run" - yuck!
Snap has many issues Canonical just refuses to solve (e.g. users without home under /home), so I just ignore that. What flatpak does is arguably exactly what Appimage does, a wrapper script. Maybe more complex, but with additional features and the it's the same script for all packages. If you have 100 AppImages installed, you have the same thing as "flatpak run" in up to 100 slightly different versions. I can't see how that reduces complexity.
AppImages are not comparable with statically linked binaries.