Pinned toot
Submitted a PR to add an Iterator for rust std::error::Error source()…
@rustlang #rustlang #rust…
Finished documentation for my rust error chaining crate…
Side effect: two pull requests for mdbook. 😎

@rustlang #rust #rustlang

With the help of squashfskit, libfaketime and some manual quirks, FedoraBook images build now reproducible with the same set of binary rpms as the source 😀


@kev Hi, I reinstalled my friendica instance on Somehow I don't get any new posts anymore from @harald
Is there some private key crypto involved or why does fosstodon not pickup any new posts?

Schade, dass es noch diese Landbevölkerung 🥚 mit AfD und CSU Wählern gibt.

Any good links on how to setup with the docker container?

Seems like mail is not working and the main page always display "page not found"

Re-announcing the first working version of my "FedoraBook" with SELinux and UEFI secure boot. Readonly /etc, split passwd/shadow/group/gshadow , TPM2 support with LUKS2 and clevis. Updates are done via A/B partitions.

On flatpak 

Today someone pointed out, and I saw some discussions around it today on fedi. As a user of Flatpak for both installing and developing applications I wanted to address it.

A lot of the issues they attribute to flatpak itself are really issues with the consumers of flatpak. Flatpak's sandbox is not useless, but the fact of the matter is many popular applications cannot fully use the sandbox in order to function. Inkscape is a good example. With Inkscape I can drag an icon from anywhere on my system and integrate it into the mockups I am working on. With a full sandbox that would not be possible, and the thing most important to most users is whether or not they can do their work with an application. So, as a trade-off, some apps choose their level of sandboxing.

There is a way to have a functioning app that interacts with the filesystem without turning off the sandbox, and that's through portals. Portals are not something that are automatically used, however. Applications need to be modified to support them - GtkFileChooserDialog becomes GtkFileChooserNative. This takes effort on the part of application developers, and if they aren't targeting flatpak themselves it's an effort they might not put in. This makes it so anyone packaging the flatpak needs to make the app work without portals, and that's through changing their sandboxing level.

Because some apps need to have permissions outside of the basic sandbox level, the author of flatkill states that "the users are misled to believe the apps run sandboxed". Contrarily, the flatpak CLI explicitly tells you what permissions are needed at install time. You can also use `flatpak info --show-permissions` after installation, and override permissions you don't want. The real issue lies once again with the consumers - package management interfaces like GNOME Software. To solve these issues these interfaces could:

• Show each permission the app requests explicitly
• Have a way to deny permissions at install time or post-install.

These are things that need to be worked on,
and likely will be worked on in the near-future as flatpak matures.

Flatpak is a new technology. There are growing pains, but I wouldn't write it off. The issues pointed out will be fixed as applications target the sandbox. There still might be some issues with third-party apps like Steam and Spotify, but those issues would still be present without flatpak. When used as a system for developers to distribute their own apps, flatpak has great potential.

I have to thank #Google for closing down #GooglePlus. Forces me to update myself on what's going on in the #fediverse :)


Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.