Changing the default x86-64 compilation target to v2 or v3

[mathstuf]

@zackw

I think I saw something go by about tagging ELF shared objects with subarchitecture requirements so that the dynamic loader will refuse to load modules that the CPU can't handle

I think you're referring to the glibc Hardware capabilities section in ld.so(8) which will additionally search glibc-hwcaps/$subarch in each search path directory first to load hwcap-aware builds of libraries.

[ais523]

@zackw

The path of least resistance for X and Wayland may well be to fork off a notify-send process.

One problem here is that you'd need to ensure that a) notify-send is installed, and b) it's the executable the program thinks that it is, rather than some other file with the same name. For example, looking for a notify-send on $PATH could be a security bug if the user is running a program with more permissions than they have themself, as they could cause the program to find a malicious notify-send executable rather than the one they were looking for. (This might end up not being a real problem in practice, though – it would be rare for a program that isn't compatible with the current CPU architecture to be given elevated permssions.)

[zackw]

@ais523

you'd need to ensure that a) notify-send is installed, and b) it's the executable the program thinks that it is

The way Unix works is you aren't supposed to worry about either of those things. You run the notify-send binary on your PATH. If it doesn't exist, you print a message on stderr and give up. If it exists but doesn't do the job—for a very abstract definition of "does the job"; the human controlling the machine is entitled to put a notify-send binary in the first directory on the PATH that discards all notifications—then the system is misconfigured and it's not your problem to fix it.

A set-id binary must sanitize its PATH (and a whole bunch of other environment variables) but this is not a new requirement, and nowadays it's my impression that set-id binaries are considered bad practice, period.

[SkiFire13]

@zackw

If it exists but doesn't do the job—for a very abstract definition of "does the job"; the human controlling the machine is entitled to put a notify-send binary in the first directory on the PATH that discards all notifications—then the system is misconfigured and it's not your problem to fix it.

That only works if you have an oracle telling you that notify-send is misconfigured, otherwise the only thing you see is the program immediately closing without any error message and at that point what tells you whether it's your problem to fix or not?

[Vorpal]

Then on Linux it is up to the user to run it again in a terminal, possibly with strace if there is nothing helpful on the terminal.

You might argue it is not good UX. You would be right if you argued that. There is a reason it isn't yet the year of the Linux desktop.

(I say that and I do run KDE on Linux. Make of that what you will.)

[josh]

Lest we go too far down the rabbit hole of notify-send: I don't think we should ever spawn a program for this. Printing a warning is one thing, spawning a program would be too much complexity with too many downsides.