<Profpatsch>
Should rewrite everything to either Python or perl to have a consistent setup
<Profpatsch>
And people prefer python, so let’s get rid of perl
<Profpatsch>
Their power is very similar, so better to only have one for less overhead
<Profpatsch>
doesn’t really matter which
<Profpatsch>
Guix doesn’t have this problem scnr
<adisbladis>
They have entirely new problems :P
<LnL>
the consistency is nice but I feel like it makes it a lot harder for newcomers to contribute
<xfix>
in theory, switch-to-configuration.pl could be rewritten to C++ or whatever, but I don't think anyone would want to actually do that
<Profpatsch>
LnL: You mean only having to know one language instead of two very similar ones makes it *harder*?
<Profpatsch>
That’s an interesting view.
<LnL>
given that nix isn't a language everybody knows, yes
<ehmry>
Profpatsch: remember, you are the one mixing dhall and nix :p
<LnL>
I'm referring to the mix of languages in nixpkgs compared to doing everything in a dsl
<LnL>
not perl vs python
<xfix>
i personally don't see Perl being required for NixOS to be an issue, sure, it uses some space, but likely Perl would be installed by something else anyway
<Profpatsch>
LnL: Ah, okay.
<Profpatsch>
Well, that wasn’t the point of the discussion
<Profpatsch>
so
<adisbladis>
xfix: My problem is that it ends up in the minimal installer and that I as a nixpkgs contributor have to know multiple languages to hack on the OS tooling
<Profpatsch>
Guix makes distinction even more difficult than nix, because it uses guile for configuration *and* at build time *and* at runtime
<adisbladis>
By my rough guesstimate Perl adds another 150M
<adisbladis>
(not just perl, including libraries pulled in by the scripts)
<xfix>
i don't think most contributors have to understand how switch-to-configuration.pl works, but... 150MB is kinda a lot
<Profpatsch>
xfix: Minimal closures for non-maximal applications (a full NixOS user system with desktop env *is* a maximal application) are useful on their own right
<Profpatsch>
e.g. for minimizing deployment times
<Profpatsch>
My server application might not have anything that uses perl, just some static haskell binary and a minima nixos colsure
<Profpatsch>
So I don’t want to transfer 150MB to my production server every time I update.
<ehmry>
i think perl is bigger that
<Profpatsch>
Especially if I don’t have access to Gigabit
<ehmry>
well I think it depends if its split output or not
<adisbladis>
ehmry: Perl itself is ~90M
<adisbladis>
But as soon as you start pulling in libraries things snowball
<xfix>
30MB of that is glibc, so Perl is more like 50MB
<xfix>
i don't think realistically we will ever get rid of glibc
<Valodim>
wasn't command-not-found rewritten in rust? what's not to like? :)
<manveru>
Valodim: where did you get that info?
<xfix>
although i find it interesting that 10MB of Perl is pretty much for CJK encoding support
<xfix>
but likely nothing we can do about that
<manveru>
xfix: same with ruby... iconv is pretty massive
<xfix>
like, i would be surprised if NixOS actually cared about legacy CJK encodings (for me, anything non-Unicode is legacy), but it's here whatever you want it or not
<aanderse>
xfix (@xfix:xfix.pw): I'm under the impression many of those legacy encodings are still in common use in some parts of Asia (though i don't know for sure)
<xfix>
i don't disagree
<manveru>
hm, actually encodings only make up about 4MB of ruby now, i thought it was much bigger...
<xfix>
however, NixOS scripts shouldn't need those, but the unfortunate part is that they are here whatever they are needed or not
<xfix>
i know that Shift-JIS is very common in Japan still, but it's still a lot of space used for encodings if the only use of Perl is for NixOS scripts
<manveru>
that seems a bit overkill, but ok...
<aanderse>
xfix (@xfix:xfix.pw): I've never even thought about it but if i have Japanese in filenames on my nixos pc what encoding are they in? assuming utf8...
<xfix>
likely UTF-8, but Linux doesn't enforce any particular encoding, it's just bytes
<manveru>
i had to host samba in japan... you get all kinds of fun encodings :)
<manveru>
not even gonna go into emails
<xfix>
and yeah, i mentioned that glibc is 30MB, about 24MB of that is due to encodings, of course, nothing really we can do about that, but be annoyed about duplication of encoding handling everywhere
<Profpatsch>
We are missing the mark in this discussion anyway
<Profpatsch>
perl vs python is about reducing overhead of things people need to know to contribute
<Profpatsch>
they are similar, so this overhead is unnecessary
<Profpatsch>
thus: let’s get rid of one in favor of the other
<Profpatsch>
people time is much more valuable than machine timen
<Profpatsch>
-n
<xfix>
i personally don't think that's an issue, a contributor doesn't need to know how `switch-to-configuration.pl` works to contribute to nixpkgs
<Profpatsch>
“you don’t need to know how this part works, just accept it or learn a new language”
<Profpatsch>
“this is for the elite of people who have enough time to study programming languages in their free time”
<Profpatsch>
“only super nerds allowed here for no deeper reason than that the author felt like using a different language here”
<Profpatsch>
“tooling is only good for python sorry, doesn’t make sense to make it good for perl which is only 20% of the code”
<manveru>
Profpatsch: nixos-options is now C++, and it looks like command-not-found will be Rust...
<manveru>
i know neither Python, C++, nor Rust well enough to contribute much
<Profpatsch>
manveru: that’s the same discussion for non-scripting languages.
<xfix>
similarly, if you don't want to change Pantheon update scripts (written in Elixir), you don't really need to know Elixir
<xfix>
well, unless you want to change switch-to-configuration.pl, you don't really need to understand what it's doing
<Profpatsch>
I am in favor for aiming towards moving everything to stable rust, away from C++/Haskell/Javascript
<Profpatsch>
xfix: I believe I made a good case for why “you don’t have to understand what X is doing” is not a good philosophy to have.
<Profpatsch>
I will not go into this any further.
<xfix>
i don't think it's a reasonable expectation for anyone contributing to nixpkgs to understand everything in nixpkgs
<manveru>
i don't think anyone expected that ever
<xfix>
if a maintainer of a package wanted to write their update scripts in Brainfuck, their choice
<manveru>
i just pray that there won't be even more C++
<manveru>
Rust at least can give you stack traces when it fails...
<Profpatsch>
xfix: you just steelmanned my argument
<Profpatsch>
I thank you *draws hat*
<Profpatsch>
manveru: I was pretty amazed when I noticed that the rust allocator can give you useful hints when it would just segfault in C
<Profpatsch>
Or idk if it’s the allocator, but there was a helpful error message of what went wrong with some raw pointer stuff when C would just print segfault or something
<manveru>
yep
<manveru>
my coredumpctl always overflows...
<xfix>
but okay, let me try a more reasonable argument, switch-to-configuration.pl is part of a system that you don't need to understand how it exactly works when dealing with other components
<xfix>
similarly with glibc (written in C) which is too a part of a system you don't need to understand how it exactly works when dealing with other components
<xfix>
yes, switch-to-configuration.pl is more NixOS specific than glibc, but contributors usually won't need to read source code of either
<xfix>
<Profpatsch "manveru: I was pretty amazed whe"> yeah, every time Rust allocates memory, it checks whether it was successful, and if it wasn't, it calls OOM handler
<xfix>
but that's really it, Rust by default uses system allocator, in the past it has used jemalloc, but that's not the case anymore
<manveru>
for me it's mostly about debuggability as sysadmin, and debugging segfaults in e.g. nix itself is at least a magnitude harder than debugging backtraces from switch-to-configuration... ideally we'd just use safe rust for everything so i don't get either :)
<manveru>
wishful thinking, but one can dream :D
<xfix>
i wonder how practical rust will be for NixOS stuff, i would love to see Rust being used more in NixOS
<abathur>
I stumbled into a timewaster today and trying to sort it out turned up something a little odd; not sure if it's reportably so...
<abathur>
travis-ci build broke w/ unknown hash algo on what was just a merge separated by a few days from last run on branch; clever pointed out a new SRI hash as likely cause since travis builds are still on Nix 2.0.4 (released this day, 2018)
<LnL>
are there sri hashes in nixpkgs?
<abathur>
I cloned nixpkgs, diffed the successful/failed releases for uses of `\bhash\b =` and found several; I think pip is the cause (only one I noticed in the output for my successful build)
<abathur>
but I didn't think colon was a valid SRI separator, and I guess it isn't, but it's supported as a legacy Nix format
<abathur>
so I got even more curious and ran `git grep "sha256-" -- "*.nix" | wc -l` and did the same for colon; haven't audited them all yet but 87 matches for "sha256:" and 38 matches for "sha256-"
__monty__ has quit [Quit: leaving]
<abathur>
yeah, I saw that while I was trying to figure out wtf is going on
<LnL>
should be disallowed IMHO
<LnL>
unless minver.nix is bumped that is
<cole-h>
SRI hashes in nixpkgs? +1.
<abathur>
those aren't all legit matches, making better grep
<abathur>
so 8 `hash = "sha256-...", 10 more `sha256 = "sha256-..." (not sure what the status of this is? is this intended front-running?)
<abathur>
also not sure about the status of the : form, I see 15 `hash = "sha256:..."` and 19 `sha256 = "sha256:..."`
<abathur>
also for metadata fun, of the 1300 commits I was looking at to find my culprit, there were 8 new `hash = "sha256:..." forms, 1 new `sha256 = "sha256-..."`, and 1 new `hash = "sha256-"`
<abathur>
LnL cole-h I take it this is worth a report? @ nix? nixpkgs? anywhere else?
<emily>
one problem is that recent nix prints out sri hashes, so it's kind of annoying for tofu
<emily>
(maybe recent = nixFlakes? but I think maybe nixUnstable too... I don't remember about stable nix)
<LnL>
I know, that's why I made that pr
<qyliss>
pretty sure stable nix doesn't do that
<emily>
ah I missed the Nix PR
<abathur>
so, eh? big deal, little deal? open an issue on nixpkgs but just mention the nix PR LnL opened? aggressive mentions or let the system do its thing?
<abathur>
don't want to whisper if it's a problem, but don't want to go sing it from the rooftops if it's minor
<LnL>
dunno
drakonis_ has quit [Read error: Connection reset by peer]