![](/static/253f0d9b/assets/icons/icon-96x96.png)
![](https://lemmy.ml/pictrs/image/q98XK4sKtw.png)
I don’t know if this is still the case, but IIRC browsers (chrome and Firefox) have their own sandboxing which is quite effective, but their efficacy is hindered by flatpak.
I don’t know if this is still the case, but IIRC browsers (chrome and Firefox) have their own sandboxing which is quite effective, but their efficacy is hindered by flatpak.
Early Knoppix live CDs have a special place in my heart
I’ve used silverblue on my gaming rig for over three years now. It has been a completely uneventful experience, so I really like it.
The only pain point I have is that compiling kernel modules is an utter disaster and it’s ridiculous that there is not a seamless mechanism for this yet. Every kernel update (and there are tons) requires me to rebuild my third party modules, but you need to do it in a toolbox and the kernel headers version must match the running kernel version, which is actually more annoying than it sounds.
Was this written by AI?
Linux has dominated the router firmware market for a loooong time. Nearly all vendor firmware for consumer routers is Linux based.
Vterm not working well with evil was actually my motivation to drop evil completely and embrace emacs key bindings.
It was the best decision I made. I don’t perceive a any measurable impact on my ability to efficiently write code or edit text, but I’ve seen a significant improvement on my ability to use emacs in general
I more or less live in emacs on my development machine, so vterm is my main terminal
Coopers hawk and male house finch?
Reminder to read the official git book. It’s free and it’s useful. My dudes, stop pretending to understand your tools and actually learn them.
This is amazing
deleted by creator
Vterm was so integral to my workflow that I finally abandoned vim and learned the default key bindings.
Totally worth it too. I got rid of so many extra packages adapting things to evil mode
Our current understanding having spoken to systemd developers is that we should be able to find a path that brings us much closer to upstream, if not entirely.
The only way the systemd developers will allow musl support upstream is if musl supports the glibc-isms that systemd uses.
They have been extremely clear that they will not carry patches for other libcs.
I find GNOME’s “must be perfect” approach to accepting new code counterintuitive.
One of the largest benefits of having a clean architecture is increased velocity and extensibility. What’s the point in nitpicking over perfection when it takes literally years to merge a feature, arguably one considered basic and essential by today’s standards?
KDE is on the other side of this pendulum, integrating everything and resulting in a disjointed, buggy disaster.
Where’s the middle way? It used to be XFCE. What is it now?
Don’t forget to put a red tailed hawk call over it lol.
That’s a good lookin bird
This makes no sense because dbus uses unix domain sockets.
It sounds like you don’t actually understand what dbus is.
“Bro just use sockets lol” completely misses the point. When you decide you want message based IPC, you need to then design and implement:
And before you know it you’ve reimplemented dbus, but your solution is undocumented, full of bugs, has no library, no introspection, no debugging tools, can only be used from one language, and in general is most likely pure and complete garbage.
Nice birb
This assumes the exact same ads will be injected in the same time markers for every viewer, every time. I doubt any of these will be true.
Edit: I got this backwards…