Shouldn't that be the easiest way to distribute audio software for linux? It's just a static shared library and maybe some data.
> This is the first time I'm reading of Pipewire, and it sounds promising, but will need to have host support before it becomes a reasonable VST / LADSPA replacement.
I'm pretty sure they didn't mention pipewire as a replacement for vst or lv2 (or ladspa lol). It's benefit would be for your standalone since it supports alsa, jack and pulseaudio clients and can get decent latency.
No. First, "static shared library" is self-contradicting: libraries are either shared or static, not both.
The longer answer is that plugins have to be compiled with the `-fPIC` flag to be loadable. The `-fPIC` flag basically says that it has relocatable symbols. You can't link against system-provided static libraries because they're never (by design) compiled with `-fPIC`. It might be possible for us to configure our build system to recompile every library we depend on as static and relocatable, but that'd be quite a bit of effort to set up.
As such, we have to link against shared libraries, and you can have conflicts with the host if it is also pulling in those shared libraries. Ardour, on Linux, specifically, in their own packages, pull in a bunch of non-system shared libraries that conflict with the system ones, which breaks our plugin. There are other shenanigans with other hosts.
> It might be possible for us to configure our build system to recompile every library we depend on as static and relocatable, but that'd be quite a bit of effort to set up.
Sounds like you already know the solution to your problems. Link all your dependencies into your plugin, hide all symbols except the plugin interface and base system ones and you can make your plugin distro-agnostic. If you depend on external shared libraries then yes, your interface to the system becomes a lot more complex and thereby brittle.
There are 53 shared libraries that our small app depends on (this is not strange on Linux). Getting them set up to all be built independently by our build system would be a large task, and a large thing to maintain. Technically it's probably the best way to go, but it's probably a week solid of work, and probably not worth it to support our small number of Linux users.
> Another approach might be x11docker [5] with Kata Containers [6].
Why all the complexity? Just qemu/kvm and xpra, waypipe, whatever would be way simpler and in turn have way smaller of an attack surface. Same if you don't need virtualisation, just use bubblewrap instead of docker etc. It will even give you more fine grained control and you can just use your distributions package manager to keep everything up to date.
Also, xpra and waypipe are developed with the intent of being used remotely. They do not have any zero-copy provisions to reduce latency and overhead on local-only applications, like you would get with at least the virtio_wl and WSLg approaches.
Well, in the case of WSLg the sandbox is WSL itself (and you can spin up multiple different ones, though they'd hardly qualify as micro VMs). The only part that "only works on Windows" is the RDP client. The rest is specifically developed for Linux and open source. The backend is an extension of FreeRDP, so presumably the FreeRDP client would be just fine on Linux.
As mentioned to open, containers within VMs are a security standard for cloud-native when security is critical.
x11docker is just a (very convenient) security layer for containers which need to expose graphics (and possibly webcam, audio, networking, clipboard, printers...). Kata Containers are just "micro VMs" where you spin up a separate kernel to drop the container into.
Bubblewrap is okay if you trust your kernel, but locking the app away in its own VM with its own kernel gives another layer to bust through.
> x11docker is just a (very convenient) security layer for containers which need to expose graphics (and possibly webcam, audio, networking, clipboard, printers...). Kata Containers are just "micro VMs" where you spin up a separate kernel to drop the container into.
Yeah, thats what I meant, you can just use kvm and your gui/audio/etc. stuff directly instead of having all the unnessecary complexity and dependency those layers bring along.
> Bubblewrap is okay if you trust your kernel
Thats why I proposed it for when you don't need virtualisation. You can ofc also use it in a VM to further restrict processes.
If you read the examples you'll see that they mount /tmp/.X11-unix in the container, thats where the X-Sessions Unix domain socket is. You can do the same for pulseaudio. But you shouldn't. Use Wayland and Pipewire if you are actually interested in using this as a security measure, since they are built for sandboxing.
> I thought modern browsers would need /dev/dri/?
They only need it for hw-acceleration. You can also give the container access to it if you need that.
many argue that silicon valley firms are de facto extension of the US government [1]. a swiss army knife (haha) in their toolkit that allows complete control over the flow of information. i mean seriously, just look at how fast the Crypto AG story was forgotten. only this Dutch article [1] and a handful of others properly dives into the profound impacts that the CIA backdoored Crypto AG devices likely had on world events in the past 50 years. [2]
so yeah if SV firms were not extensions of the US govt. (hardware firms too, not just software), they would have already been broken up years ago.
the senate hearings are just a charade used to stroke the ego's of the 'visionary' SV tech bro CEOs. they also show us how tech illiterate the working class has been made. [2]
If you have a sufficiently smart (TM) metaprogramming system you can just stick things like this in a macro or template then you get the expressiveness but don't have to a write DSL.
