I guess it depends on what Nix wants, if it wants to remain a niche system, then things are good as-is.
Though, on the other hand, the comment says a new CLI is close to release, so I guess people are trying to improve things.
I don't want to be too critical, I love Nix. But the experimental new UI was already in development (and available) when I started using Nix in 2018. It has also changed quite a lot recently and is now very strongly tied to flakes. However, the flakes RFC was withdrawn . Given that flakes are a large change, I'd expect (but maybe I am wrong) that there will be a new RFC.
At any rate, I would be surprised if the new CLI with flakes are close to release.
1. Possibly it is something to do with rust-analyzer. I work on a pretty large rust project and that does lock things up sometimes.
2. I actually hit C-x C-c by mistake. It's very possible, my fingers often do things by themselves when I'm not concentrating.
(put 'save-buffers-kill-emacs 'disabled "You probably didn't want to do that...\n")
which makes emacs prompt you for whether you really meant to ask it to exit. (I'm sure there are a ton of other ways to do this; this is just the first one I hit on a decade or more ago :-))
All of these techniques work. As I mentioned in the very next sentence, only the first in that list is common, but that doesn't mean the rest don't work. If you have found some fundamental hole in NaCL or CHERI or JVM security which makes them ineffective, feel free to publish your results.
These also rely on wrapping the entire userspace into a sandbox, which is hardly relevant to the libraries vs. services thing. You can't inspect a stack from inside the attacker's process and expect that to do anything at all, let alone control access to a resource.
See the article:
>If user code is running on a sufficiently advanced platform, one not administered by the user, then a library can safely manipulate resources that aren't accessible to the rest of the program. For example:
>[the list quoted above]
JVM security has nothing to do with this.
"Java-style stack inspection can restrict user or library code to deny access at runtime to unauthorized methods.",
which doesn't seem true to me, if the user has access to the library binaries. It's very possible for the user to just patch the library and use it however they want. It's possible (although I'm not especially convinced) that you can prevent the user from reflectively doing this at runtime, but that's not the only way to access unauthorized methods.
Could you explain what gave you the impression that this was about licensing schemes? That was definitely not my intention.
This is all just to say, I don't think "GPL drivers" and "PnP generic images" are as separate as you're suggesting.
Actually, Unix domain sockets are substantially more flexible than localhost. For exampe, Unix domain sockets have filesystem-based access controls, they can have meaningful paths instead of magic numbers, and they are trivially used across different containers (just bind mount the socket file in to whatever container, just like any other file).
This is dependent on the operating system. The Linux kernel obeys access permissions on the file inode, but Solaris doesn't. (I always forget how AIX, macOS, FreeBSD, NetBSD, and OpenBSD behave.) But even on Linux there's the classic race condition if your umask isn't set correctly when you invoke bind. Interestingly, on Linux you can fchmod the descriptor before calling bind, which is better than temporarily changing the umask around bind as it's not thread friendly--the umask is global so would effect whatever files are being opened in other threads at that moment.
But you don't need to rely on the permissions of the socket file inode itself. You can just create a directory with the restrictive permissions and then bind the socket into that directory. That's perfectly portable, presumably even to Windows, and also avoids umask races. In fact, using directories this way is almost always the superior option (e.g. for temporary files, etc), though it's a tad more leg work so unfortunately people rarely use that pattern.
But all Unix systems also support querying credentials over Unix domain sockets, where "credentials" basically means the UID and GID of the peer, which permits supporting user- or group-based authentication without passwords. I'm pretty sure Postgres supports this; that is, you can configure Postgres to allow user foo to access DB bar without a password, token, or signed cert. I submitted a patch many years ago so this would work on OpenBSD. (At the time OpenBSD provided getpeereid for querying peer credentials, but Postgres only supported SO_PEERCRED and some other mechanisms. Years later OpenBSD eventually adopted the SO_PEERCRED approach, which is what Linux uses, and made getpeereid a wrapper, because sometimes it's not worth swimming upstream. None of these are defined by POSIX but the capability is supported one way or another on all the extant Unix systems.)
 Depending on the OS, credentials can include other information, like PID.