Hi, long time Renoise fan and recent customer (felt I had to give something back after using the demo for so many years) here, with a couple of technical queries about the Linux builds.
$ pspax -p $(pgrep renoise) USER PID PAX MAPS ETYPE NAME CAPS ATTR root 4277 PemRs w|x ET_EXEC renoise = cap_ipc_lock,cap_sys_nice+ep staff_u:staff_r:renoise_t:s0
(no I’m not running Renoise as root! that’s just pspax being buggy)
Note the ET_EXEC – it really ought to be ET_DYN (i.e. built with fPIE) instead. Is there any reason why the 64-bit builds aren’t PIE? I can understand why 32-bit builds wouldn’t be, but the performance hit is so tiny on 64-bit that there’s no reason not to do it.
Secondly, is there a reason why Renoise needs W|X (i.e. allowing execmem in SELinux) since 3.0? Did you switch from Lua to Luajit? If not, what’s the cause? Lots of programs these days use these kinds of permissions for absolutely no benefit (e.g. JITs that are spun up even when though they’re not going to be used, hacky optimizations, badly written bindings for dynamic languages), and whenever I find something that needs them, I always wonder whether it’s actually necessary (the Python ctypes module is a famous one – it uses execmem every time you import it for some bug workaround, but the bug in question doesn’t even affect Linux, so distros have to patch those lines out in order to get it to play nicely with SELinux).
I guess most audio people would avoid SELinux anyway for performance reasons, but for anyone that does use Renoise with SELinux, the only options are to allow execmem globally (very very bad), use PaX to enforce it instead (good, but means using a non-vanilla kernel and it’s only user-friendly if you use Gentoo or Arch), or write a policy to allow it just for Renoise (which is what I do, but most people wouldn’t bother).
It would be a good idea to mention the requirement in the documentation at least, so that people aren’t tempted to just disable SELinux or allow execmem everywhere without understanding the consequences first.