Hacker News new | past | comments | ask | show | jobs | submit | catern's comments login

nix-env (including nix-env -u) is purely a user-facing UI helper for new users. One would never use it in production, or even for development, even when it was first released; it's only ever been for new user onboarding. So it's a bit low priority, since it has no production impact and experienced users don't use it...

Today's new users are tomorrow's experienced users.

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.

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 [1]. 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] https://github.com/NixOS/rfcs/pull/49

I believe it is only withdrawn for further work on it.

Yes. But since there was an initial RFC, I would expect there to be another RFC when flakes are ready.

My favorite dired feature is that if you C-x C-q (the standard Emacs binding to toggle the read-only status of a file), it makes the directory buffer writable. You can then edit the buffer like a regular file, including changing file names (or symbolic link targets, or other things, I presume), and when you're done, C-c C-c and it applies all the changes as renamed files, symbolic link retargeting, etc etc. Very handy, since you can use all the usual Emacs features like query-replace or kmacros while doing it.

I've wondered the same thing! In particular, the highly polished and powerful interfaces of some roguelikes (DCSS comes to mind) strongly remind me of Emacs. It seems like the scriptability and power of Emacs interfaces is a natural fit for roguelikes.

Crashes, as in actually exits without you triggering it? That's definitely very unusual; most lisp shouldn't be able to do that. Is there anything particularly unusual about your config? Are you maybe using a loadable module? If you do investigate it, you might find a reportable bug.

It's been years since emacs has crashed on me, very rare.

Emacs crashes on me once a month or so. I'll just be typing something and suddenly it will disappear. I have two theories,

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.

Yeah, I do 2 from time to time, because I use emacs as my long-running editor but also jmacs as a quick-one-off emacs-keybindings terminal editor, and so I tend to autotype C-x C-s C-x C-c for save-and-exit. My fix was to add this to my .emacs:

(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 :-))

Set confirm-kill-emacs to (quote yes-or-no-p) through customize-variable. See http://gnu.ist.utl.pt/software/emacs/manual/html_node/Exitin....

Poor wording, locks up and becomes entirely unresponsive.

Hm, I've been searching for a good replacement for Google Play Music, and this looks like a compelling option - the library of youtube, the recommendations of last.fm, and the UI of Emacs - an excellent set of ingredients!

>none of these actually work and none of the implementations you will find in the wild are anything but snakeoil

This is wrong. The foundation of the modern web is safe Javascript implementations. BPF/eBPF is another widespread technology using isolation mechanisms like this.

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.

Huh? NaCL is dead, and as far as I know nothing relies on the JVM sandbox for security anymore (and it was a disaster when they tried).

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.

>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]

I think you are talking about different things. I have absolutely decompiled obfuscated third-party Java libraries, fiddled with a few variables or method signatures, and recompiled + used them.

JVM security has nothing to do with this.

You're correct that obfuscation of Java libraries has nothing to do with Java stack inspection/JVM security... but the latter is what the article talks about and what is cited above, so not sure why you have just now brought up decompiling obfuscated Java libraries, which is, as you say, totally unrelated...

What it says is

"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.

Yes, the OP has this backwards. The Java sandbox would allow an application to limit the access granted to a library to protect from a malicious library. It does not protect a library from being used by an application in way that was not intended by the library creator. It is certainly not a means of enforcing a licensing scheme.

>It is certainly not a means of enforcing a licensing scheme.

Could you explain what gave you the impression that this was about licensing schemes? That was definitely not my intention.

I cannot believe this is not at the top. Short-circuiting is useful and fun in places, but to suggest it as a general replacement for conditionals as the OP does is absolutely wrong and will cause bugs.

I'd say the reason generic kernels/images are missing in the ARM world is because people generally don't run their own software on the ARM hardware they own. And the reason for that in turn is that often people don't have the ability to run their own software on their ARM hardware. Which brings us back to the GPL - this is standard "Tivoization", something that the GPLv3 tried to prevent, but unfortunately Linux is GPLv2... Still, for drivers that are open source and upstream, a practical consequence is typically that people are allowed to run their own kernels on the associated devices - which I think would give the PnP, generic image world you want.

This is all just to say, I don't think "GPL drivers" and "PnP generic images" are as separate as you're suggesting.

>it can use localhost which is realistically as efficient as domain socket but is more flexible.

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).

> Unix domain sockets have filesystem-based access controls

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[1], 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.)

[1] Depending on the OS, credentials can include other information, like PID.

well, X11's abstract sockets try to disagree about the access-control part

Yikes, if that's actually how they end up doing it, that's a big reduction in the amount of Chrome that is open source... Chrome has always been closed source but if they do that it's going to be quite far from Chromium...

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact