<nbp>
niksnut: There is a JavaScript package managment war going on … The NixOS Foundation should fight to make Nix a distribution medium for JavaScript, even on Windows, and even if we do not yet have the same safety as we have on Linux-es.
<nbp>
niksnut: Not suggesting yet another package manager, but provide integration for the best package manager solutions.
<nbp>
https://2019.jsconf.eu/videos/ 50% of these presentations are about distributing packages … with different solutions.
<niksnut>
nbp: the foundation has no ability to do that...
<manveru>
nbp: we don't have a good alternative either, only tools that enable building the packages with nix, but none that handle dependency resolution (afaik)
orivej has joined #nixos-dev
init_6 has joined #nixos-dev
<niksnut>
yes, also I don't see the JS community embracing a non-JS tool
<nbp>
niksnut: The foundation has a word on where to allocate money, and potentially intentions.
<nbp>
niksnut: I am sure that if you are sending a message to find a solution among the Nix community, you will get some momentum.
<nbp>
One interesting avenue of development, would be to offer Nix bindings in Node.
<nbp>
Such that these package managers could handle build outputs in Nix.
<nbp>
Then exporting these lock-files as Nix expression would be a plus for integrating it in NixOS, and simplifying the distribution aspect.
emily has quit [Quit: Updating details, brb]
emily has joined #nixos-dev
v0|d has quit [Ping timeout: 245 seconds]
arianvp has joined #nixos-dev
<Profpatsch>
nbp: I just hope that my yarn2nix tools won’t be outdated in half a year :)
<Profpatsch>
gchristensen: Should we remove the -f #nixos-unregistered flag from this channel?
<gchristensen>
sure
<Profpatsch>
I don’t think there have been many spam attacks recently.
<gchristensen>
there have been a couple, but this channel is much smaller than #nixos
<Profpatsch>
gchristensen: You have the op flag, right?
<gchristensen>
yeah
<Profpatsch>
cool
<ekleog>
is FRidh reachable over IRC or similar? I just wanted to have a chat about potential improvements to our python architecture with them
<ekleog>
(ie. the “trying to use sys.meta_path to get static linking to python and get rid of python.withPackages and propagatedBuildInputs” idea I was raising here the other day)
<LnL>
he's in #nixos sometimes
drakonis_ has quit [Ping timeout: 248 seconds]
<LnL>
I would also love to change the way propagated inputs and PYTHONPATH currently work, it completely breaks with multiple interpreter versions
drakonis_ has joined #nixos-dev
<ekleog>
right now I'm thinking we can get RPATH into the python world by using enough “sys.meta_path” hackery
<ekleog>
(which would require to patch python to include one “nixos” sys.meta_path entry, that'd read the store path to figure out the directories to check)
<ekleog>
if we can get that, then we can stop using propagated inputs for python and be forever happy
<ekleog>
also, thank you, I'll go check over #nixos from time to time to try and speak with him about it :)
Synthetica has quit [Quit: Connection closed for inactivity]
drakonis_ has quit [Ping timeout: 272 seconds]
drakonis_ has joined #nixos-dev
drakonis has joined #nixos-dev
drakonis has quit [Client Quit]
ma27 has joined #nixos-dev
init_6 has quit []
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 268 seconds]
drakonis has quit [Read error: Connection reset by peer]
drakonis has joined #nixos-dev
drakonis has quit [Ping timeout: 248 seconds]
Jackneill has quit [Remote host closed the connection]
avn_ has quit [Ping timeout: 258 seconds]
avn_ has joined #nixos-dev
drakonis has joined #nixos-dev
pie__ has quit [Remote host closed the connection]
pie__ has joined #nixos-dev
drakonis has quit [Ping timeout: 248 seconds]
<matthewbauer>
niksnut: have you looked at this issue: https://github.com/NixOS/nix/issues/2636 ? lots of debian users hit it, and there's not clear guidance for users
<matthewbauer>
niksnut: at least it would be good to have some guidance when "unshare" fails on how to fix (for debian you can run `sysctl -w kernel.unprivileged_userns_clone=1`)
<niksnut>
we should probably fall back to not using a user namespace
<matthewbauer>
yeah that makes sense. tbh i don't think anyone would mind if we just set kernel.unprivileged_userns_clone for them. the fact that debian disables user namespaces seems bad
<niksnut>
no I don't think we should mess with kernel settings
<catern>
matthewbauer: unprivileged user namespaces have had a lot of kernel vulns in the past, it's died down a bit now but it's very reasonable to disable it by default
<catern>
just fyi on Debian's motivations
<niksnut>
dammit, nixos doesn't even have kernel.unprivileged_userns_clone so that makes it harder to test
<matthewbauer>
catern: there's tons of kernel features that *could* have vulnerabilities though, singling out a very useful one like userns, seems like a weird decision
<matthewbauer>
but maybe there is more in consideration
<niksnut>
I mean, the nature of user namespaces makes them inherently risky
justanotheruser has quit [Ping timeout: 252 seconds]
drakonis has quit [Ping timeout: 246 seconds]
justanotheruser has joined #nixos-dev
orivej has quit [Ping timeout: 258 seconds]
<emily>
matthewbauer: it's a very useful feature that lets unprivileged users be uid 0, which the kernel is historically terrible at not taking to mean ultimately privileged
<emily>
so it's also a feature with a massive vulnerability surface
<samueldr>
correct my assumption, but it looks like the only reason it's run in a VM is because of that assumption, which can be done in another way