For games, I think it's even worse on GNU/Linux systems, since most game developers mainly target Windows and sometimes completely ignore conventions for other platforms (possibly since some game engines have that "Build for Linux" button).
This also applies to game engines and their own conventions. For example Unity has Application::persistentDataPath[1], which uses $XDG_CONFIG_HOME (still a bit meh, since I wouldn't treat savefiles as "config", but at least some convention). However, some games tend to write those into Application::dataPath[1] (or even other random directories they see fit), which is supposed to be read-only and could possibly be outside of $HOME.
Fortunately the single one advantage of antivirus software out there seems to be that the above seems to break with some AV, so developers either tell their players to disable AV or they simply fix the issue. I made countless bug reports on this issue and so far it exclusively got fixed because of AV, so I'm using that as an argument for future reports.
While at least most of the Unity games I've packaged seem to adhere to these conventions, other games and game engines are a mixed bag and I've seen games dumping their stuff into $PWD to games writing to Windows paths (eg. /home/foo/SomeVendor\Somegame).
Patching these games is also very tedious, since some of them tend to get updates, so patching needs to be done in a way to be forward-compatible.
For example here is a patcher I wrote to get Factorio to adhere to XDG:
Essentially it's disabling gesture activation, so if you want to allow audio you need to do this explicitly. Note however, that whenever you directly visit a video file, audio will still play but this is very rarely the case.
That's certainly true for the standard library and the documentation on the language itself. However for the internals, this wasn't always the case and it looked more like this:
Agreed, the language support situation is a very mixed one in nixpkgs, where support ranges from rudimentary (or even non-existing) to well integrated and supported. Particularly the Erlang/Elixir situation is - as you already brought up a while ago[1] - very rudimentary and really needs to be improved.
Right now, I do manage my Erlang dependencies with Nix only and without using rebar/mix (particularly since I do want full release upgrades with hot code reloading), but manually managing those dependencies certainly doesn't scale well for all projects, especially if they already use rebar/mix.
I also haven't looked into newer projects like nix-elixir[2], but as another commenter here mentioned, there are typically tools available to convert between the language-specific package managers, but they all come with their
own set of issues and tradeoffs (eg. duplicating dependency information or importing from other derivations at evaluation time) so they might not be suitable for your project.
The situation with secrets is a long lasting issue[3] with several attempts of solving, but so far the best practice is to just to either leave secrets out of the Nix store or just make sure the entire Nix store is not accessible.
Since I also use NixOS for a few days, I can imagine why it could be frustrating if things don't work out of the box like on other distros. Having had my own adventures patching things like no tomorrow, I know sometimes the effort to do this could be quite time consuming, especially the GOG games[4] you mention.
So I'd say if you frequently use software that is problematic on NixOS and don't want to go through the hoops of patching or making workarounds like eg. Docker or FHS user environments[5], I'd probably stay off NixOS.
Personally however I think it is worth going through a few hoops, since to me it shifts the frustration of "my system broke during an update" to "just want to get X to work NOW" and among other nice benefits (eg. bisecting
whole systems, rollbacks and/or using specific packages before they broke) I'd rather prefer a working and reproducible system.
That's easier said than done, since I think Nix has a somewhat steep learning curve.
However, what I'm missing in most comments here is that - if I'm not mistaken - Flatpak and most others are essentially tailored towards distributing binaries, which is at least my personal gripe with them.
The reason is that especially with Nix I'm used to ad-hoc `.override`/`.overrideAttrs` and patch software in ways I'd like them to behave rather than being degraded to being the sole user of a software not supposed to be modified.
Flatpak, Snap and even Docker go the opposite route, which essentially degrades FOSS to essentially proprietary software, if even upstream would just point you towards "just use the Flatpak"™.
Others here also have suggested that it would be a good way to only distribute proprietary software, but as a Nix user who's packaging and patching (well, and reverse engineering) proprietary software I'd even disagree on that, because patching the environment and the entire dependency graph is something very useful which you'll lose with Flatpak/Snap.
There was a patch[1] a few years ago, but apparently it didn't make it into mainline. At least looking in net/ipv4/tcp.c I haven't found any traces related to that.
However, I could have sworn that I've seen a similar patch in recent years, but either my memories are serving me wrong or I simply can't find it anymore.
Nevertheless, I didn't benchmark whether this is the case, nor was performance the main goal for writing ip2unix. So if performance is a concern, maybe benchmark with your specific workload?
If programs call getsockname() the result is not a sockaddr_un, but instead sockaddr_in(6) is used from the original call to bind(). If the socket was implicitly bound, a random[1] address is generated.
Things are a bit trickier if it gets to getpeername(), since we want to have somewhat stable addresses. This is done by querying SO_PEERCRED and encoding[2] the pid for IPv4 or pid, uid and gid for IPv6 into the address.
In summary: Programs shouldn't get confused, but if they do, it's certainly a bug in ip2unix. Feel free to open an issue :-)
Thanks a lot for the suggestion. While I can't change the title here on HN, the README now mentions LD_PRELOAD in the first paragraph and I also added a small FAQ[1] section about socat.
