blobjim [he/him]

Linux has an API now for allowing sandboxed apps to simulate keyboard input. Unfortunately, I couldn’t find any simple Flatpak apps that use it to provide a virtual keyboard.

That’s a pretty cool idea. It would be especially neat for headless server installation.

The article says

Firefox on Linux to date has focused on the Video Acceleration API (VA-API) that works well for some vendors but lacks official support from NVIDIA unless using the independent NVIDIA-VAAPI driver project that layers VA-API on NVDEC. There are also various embedded drivers and more not supporting VA-API

So it’s basically just because the existing video decoder API in Linux doesn’t have support for various hardware devices for various reasons. But those devices still have Vulkan support. Not sure why Vulkan support for those devices wasn’t just added to VA-API, who knows.

You need to figure out what B-Bus API is called to open the URL, and block it using the flatpak run argument --no-talk-name=NAME

Make sure embedded video is selected (Tools > Preferences > “All” (bottom left) > Video > “Embeded video”)

Also are you using a distro package or the VLC Flatpak app?

There is at least already a userspace PCIe API. And USB and so on.

It’s frustrating that there isn’t much of an effort to turn Linux into more of a microkernel. Instead the kernel just keeps getting bigger with even more subsystems and modules that can be exploited.

ah I guess that’s exactly what a backdoor is. I read the headline and thought security vulnerability or privilege escalation.

How is this a backdoor if it requires being able to install custom PAM modules???

It’s such a well know piece of software now, I can’t believe that’s even an issue. The other definition of the word probably has a fraction of the people who know about it.

Nobody is forking systemd, especially over something like this. People have no idea how much work it is to maintain software like this.

This change is mostly in the userdb code which is a sub-component of systemd that stores user records. It isn’t in the PID1 process. But I could see an argument for having it be part of the desktop environment in GNOME or something like that instead.

Windows does plenty of things better. Like having a stable device driver API, so you can install third-party drivers really easily. And there’s only one Windows compared to many Linux distros, so there’s no need to compile software specifically for many separate Linux distros. Not as much of an issue with things like Flatpak. Windows also uses software library APIs for most operating system features, compared to the patchwork of file descriptors and file systems and sockets and all the other nonsense that makes up the interfaces used by Linux applications. The documentation is also in one place for Windows (https://learn.microsoft.com/en-us/windows/win32/api/). WIth Linux, you have to do research just to figure out what APIs are available. If Linux had as uniform of an API as Windows does, there would be even more software for it. The main reason there is more Linux software these days is because Linux is open source.

It’s built on top of Devuan which is a fork of Debian which uses Linux.

Apparently Devuan is “Debian without systemd”. 🤡🤡🤡

I would stay away! systemd provides so many well-designed APIs that are helpful for server management.

Also most projects that promote not using systemd are weird ideologues at this point.

It says “coming soon”, which I guess probably means it’s a somewhat second-class feature.

Seems pretty neat. Hopefully it’s somewhat simple to compile and set up. It’s kind of weird that livekit is VC funded though. Not necessarily the best, since they might have to relicense it to make investors happy at some point.

Look at their list of investors: https://livekit.io/about

The programmability aspect of LiveKit is cool, not that it matters much since this “meet” app is just something built on top of livekit.

Hopefully it will include focusing on getting things like inputfd (https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/110) added to the spec, and not just stuff that would be useful to Valve/Steam (so they can sell more games on their own Linux systems).

DRI_PRIME is an environment variable. DRI_PRIME=1 gimp is a bash syntax for setting an environment variable for a specific command execution, Whisker probably doesn’t use shell commands, it’s expecting an executable. So it’s trying to look up a file named DRI_PRIME=1 in your PATH.

You’re going to need to figure out if whisker has a way to set env vars for a command (I don’t use it so not sure what it shows when you click the “Help” button). If not, you’ll need to create an executable script file which executes your command with the environment variable set like you’re attempting to do (DRI_PRIME=1 gimp), and then point whisker at your script.

I did an update or something and it corrupted the bootloading for Fedora Silverblue. Had to just reinstall everything. Also was a time when the update url or something was broken and I couldn’t update. That remains the biggest issue. But it might not be an issue for a professionally maintained distro like Ubuntu that has a company backing it. I feel like it’s safe to recommend Ubuntu but not any other distros.

And it’s definitely true that the average user has more control on Windows. You can download installers and random zip files with executables and they’ll just work. Linux has such a messed up model for executables and libraries that they usually have to be recompiled for every Linux distro unless you use flatpak.

But I think it’s mostly the learning curve of getting used to how linux desktops work and their idiosyncrasies that makes it hard for people. And tons of bad advice online telling you to run commands.

Linux actually has lots of GUI apps that can help fix issues and do things in Linux but people keep offering outdated advice about using command line tools and editing brittle config files.

And some things are distro-specific.

Apple is such a frustrating company lol. In Seattle we still don’t have tap-to-pay for public transit with iPhones because Apple keeps so much control over what the NFC transceiver on their devices can be used for. You can tap-to-pay with Android devices. So I’m stuck still using my physical card.