Arch doesn’t use zram by default?

check the FAQ on chimeraOS here: https://chimera-linux.org/docs/faq#so-why-use-a-bsd-based-userland-anyway

Lovely write up!

Nice! Leaves me wondering why the funding was increased tho. Is it because the SFT projects have been successful so far? Or because they were not moving fast enough? Or perhaps simply because more money was needed to achieve this year’s aims?

Granted, 4 mil might not be an enormous amount for an institution this size.

Some people over at reddit seem to suggest that the functionally you speak of doesn’t exist, except in the form of a proof of concept snippet over at SO.

EDIT: Said snippet would probably be sufficient, if it handled codeblocks correctly (stuff in between ```. At the moment, it handles them miserably (maybe because they are multineline elements?)

No joke, Emacs has the ability to render in line markdown, essentially the current line is just text, while the rest of the doc is rendered as markdown titles, links, lists, etc.

This sounds amazing. I’ve been using markdown-mode for ages now though, and I’ve never come across this feature.

How do you enable this?

can’t you just trigger a script after some udev event? Your battery would be happg

best comment

One thing that hasn’t been mentioned yet is interopability, that is, flatpak interacting with the rest of your system.

I’m not that familair with flatpak, but in my brief experience with the steam flatpak, I had trouble getting it to recognize my controllers. Steam installed through pacman (Arch’s package manager) had no such issues, on the other hand. My hunch is that this has to with flatpaks being more isolated from the rest of your system.

Im pretty sure that’s just some kind of permission issue, but it can be nice to not have to troubleshoot acces rights and the like. But this is obviously a double edged sword: more isolation may also mean more security, just at the cost of ease of interaction with other components.