<jared-w>
You also can't share inner things between different builds. Each derivation is a black box with deep constructive traces (or in Nix's terminology, its extensional store)
<drakonis>
gchristensen: its probably linux-libre.zfs
<gchristensen>
hm?
<drakonis>
no librezfs yet
<gchristensen>
I don't understand
<gchristensen>
what are we talking about?
<drakonis>
ah okay nevermind i read it wrong
<drakonis>
i'm reading a thing and not getting it
<drakonis>
so, on the topic of *2nix proliferation, the overall problem with those is the dependency footprint
<gchristensen>
ah
<drakonis>
you can't offer them in a default capacity because you're going to pull several languages, as they're usually written in the same language they import
<jared-w>
and nobody wants a default closure to be 7GB worth of toolchain
<drakonis>
it would honestly be preferable to have the entire nix user interface written in a single language that can reasonably be modified and extended without a lot of effort
<drakonis>
while the c++ parts remain for managing the store
<jared-w>
drakonis: what, you mean you don't like writing cythonearlust++?
<jared-w>
(and bash. So much bash)
<emily>
23:57 <gchristensen> emily: Hydra write to S3 at roughly 2Mb/s, and 5 files per second, and last I knew, ipfs struggles to be able to sustain that
<emily>
gchristensen: fair enough
<emily>
gchristensen: good to know
<emily>
gchristensen: also, is that *continuous*?
<gchristensen>
yes
<emily>
cool
<emily>
the builds never stop ^_^
<drakonis>
god i dont like having to deal with bash to interact with the world
<jared-w>
It's definitely an interesting quirk of nix that we have this beautiful paradigm of operation and the way we get most stuff done in it is... bash, *make, and thousands of lines of patches, hacks, workarounds, duct tape, and glue
<drakonis>
reduce the platform dependent nix bits
<jared-w>
(I do find it endlessly amusing that it's still far better than competing solutions by several metrics despite the "ugliness")
<gchristensen>
jared-w: it is because bash is the best language for the job
<jared-w>
or least immediately terrible? :p
<gchristensen>
no
<gchristensen>
and once Nix has completed its task, it doesn't matter and nobody knows or cares that bash was involved
<ldlework>
only the people maintaining the bash
<gchristensen>
so what?
<ldlework>
bash sucks i think is the sentiment
<gchristensen>
the bash nightmares happen when your bash programs are calling bash programs forever and don't have clear boundaries
<jared-w>
Isn't the bash a major blocker to windows compatibility?
<ldlework>
the bash nightmares are intrinsic to bash because as a language it's arcane and impossible to internalize
<jared-w>
gchristensen: I feel like that scenario happens frequently in an ecosystem designed around towers of overrides, merges, and combination?
<gchristensen>
jared-w: but again, once nix-instantiate finishes, nix lang is totally gone and yo uhave a spec of what will happen. once nix-build exits, it is gone and you have a result you can examine
<gchristensen>
a totally different bear than running scripts in prod
<jared-w>
It honestly has similarities to me with wordpress and its hook system + php.
<gchristensen>
it is totally different because the lifecycle is totally different
<gchristensen>
Nix and builds has no "execution timeline" that scripts in prod or wordpress do
<gchristensen>
if you don't like what an evaluation did you've damaged nothing, same with a build
<jared-w>
Once the lifecycle exits all you get in wordpress is HTML/CSS/JS. Nobody has to know or care that you wrote it in php. It's not a perfect analogy, of course, but it can feel similar in certain ways
<gchristensen>
if you don't like what a regular bash script did to your system, or a patch to wordpress did to your database, you're restoring from backups
<jared-w>
ofc the theory behind Nix is sound which makes an incredible amount of difference, don't get me wrong :p
<jared-w>
I'm not sure that the underlying theory being robust and sound completely excuses some of the valid concerns of using something like bash as the main way of interfacing with it. Alleviates, sure
<gchristensen>
bash sucks but in the most wonderful terrible ways
<drakonis>
bash is the most arcane wizardry thing, just short of perl
<ldlework>
no bash just sucks, and it's value add is anachronistic if substantial and real
<gchristensen>
everybody knows bash enough to make an uncomplicated nix-build problem work
<drakonis>
i'd like to actually just use a function to create text and move things
<drakonis>
but then it'll slowly make nix into a real language in order to make it work
<ldlework>
technically you don't need to use bash for anything right
<ldlework>
because you can just pull in whatever language you want into the derivation
<ldlework>
and do the work
<jared-w>
"technically"
<gchristensen>
sure
<drakonis>
pulls in dependencies for things
<gchristensen>
`builder` can be anything, and `args` can be anything
<ldlework>
sure it pulls in dependencies but not ones that end up in the package
<drakonis>
yes
<jared-w>
Does nix have a way to separate the closure of builder/args/etc and the final closure of the package?
<ldlework>
the reason why bash is used because the things you're doing with bash is stuff that bash is the most suited to
<ldlework>
there isn't really another language that can do shell things as fluently as bash
<ldlework>
it's just everything else it is the *worst* at
<ldlework>
like... conditionals and just literally everything else
<emily>
the bash problems happen because bash is a bad language
<emily>
in every way
<ldlework>
it's kind of a ridiculous universe to be in
<emily>
justifying it because "you need a shell glue language" doesn't make it better
<emily>
python with subprocess would be 10x better for nixpkgs
<ldlework>
i feel like that's the point i'm trying to make so i'm glad you agree
<ldlework>
but subprocess is not as fluent as bash is as the shell bits
<emily>
that was just my general contribution to the discussion :p
<ldlework>
hehe
<emily>
"everybody knows bash enough to make an uncomplicated nix-build problem work" ... and almost nobody knows bash enough to make a complicated nix-build problem work
<ldlework>
that was my reaction as well lol
<emily>
it's better than portable POSIX sh, at least...
<drakonis>
there's a often repeated adage, "there's a point you should ask yourself, do i rewrite this complicated shell script in <x> language?"
<ldlework>
tbh, my problems with productively using nix have nothing to do with bash
<ldlework>
all bash problems are a google away
<ldlework>
but the majority of nix problems are at least some goodwill of people in here away
<emily>
drakonis: that point is about 10 lines for me
<emily>
admittedly, most build scripts are below that
<emily>
but stdenv isn't, it's a huge ball
<jared-w>
I can go about 800 lines of complicated bash before I feel a strong urge to switch, but that's admittedly very unusual and I have a weirdly large knowledge of it
<drakonis>
ldlework: do tell about them
<ldlework>
i have to look up how conditions work, every. time.
<drakonis>
i had to do a loop in shell to include gzdoom's soundfonts on the package
<drakonis>
it looked ugly as sin
<emily>
jared-w: I like esoteric languages too but I try not to inflict them on my production systems ^^
<jared-w>
what, you mean ! [[ -z "$foo" ]] && test -x "${blah-:"wat"}" && echo "are you not entertained" doesn't make sense?
<drakonis>
that is very... ugh...
<ldlework>
drakonis: i haven't been mucking with nix in the last several months so nothing actionable is in mind, but i typically come here when i'm facing issues so you've likely already read all of them
<jared-w>
go on, figure out what -z does, how quotes changes $foo in the presence of unset vs set-to-empty-string and how all of that changes when you use [[ ]] vs [ ]
<ldlework>
it's mostly to do with how to actually build the needed software development environments
<jared-w>
better yet, ! [[ -z "$foo" ]] is not always equivalent to [[ -n "$foo" ]] (-n and -z are opposites)
<drakonis>
ugh... shell gives me headaches
<drakonis>
just... why...
<ldlework>
jared-w: exactly lol
<ldlework>
i would rather just play mandolin..
<jared-w>
the test x with substitution is a fun one tho
<joepie91>
jared-w: oh, you're one of *those* people :D
<jared-w>
It's a good read and helpful to know, but also, value your sanity so
<ldlework>
you know half of it is that bash is hard to internalize and the other half is not *wanting* to internalize it from being offended from the first half
<joepie91>
(I am too, sometimes, but with JS)
<joepie91>
ldlework: yeeeep.
<jared-w>
function() { var self = this; self.prototype.y = function () { console.log("pls no more") } }
<jared-w>
spot da bug amirite
<drakonis>
i can hardly tell
<ldlework>
when i code in C# i rarely have to spot my own bugs because Intellij's ReSharper engine is essentially deux ex machina
<ldlework>
it tells me as i type them
<joepie91>
jared-w: nah, one can do much more fun things
<jared-w>
oh, there's always the classic "do you even know JS" interview question: for (var i = 0; i < 10; i++) { /* screw with setTimeout and var scope lifting */ }
<jared-w>
ldlework: if only it was good enough to tell you before you typed them :p
<ldlework>
sometimes it will be like "You implemented another property with classic style. Wanna update the whole project to new style properties?"
<jared-w>
Gotta wait for C# 10 probs /s
<ldlework>
there's just nothing like coding C# in Rider, and then to open a bash script it's enough to make you wanna become a musician
<jared-w>
joepie91: don't forget polyfilling async/await with generators. Man isn't JS fun? *ugh*
<jared-w>
not even using bitshifting with the comma operator. Do you even obfuscate? :p
<ldlework>
es gets better all the time though and that's as much as i can ask acknowledging our given history
<ldlework>
also just use ts
<ldlework>
(not that it does or can fix everything)
<jared-w>
I wrote a type in TS that grabbed an object and treated it like an AST, traversing it and constructing an entirely new object with branching/switching on different field names
<jared-w>
Admittedly, I am always curious when people dislike JS (but are very experienced in it) but dislike TS more
<ldlework>
i definitely recommend TS over Vanilla
<ldlework>
entire classes of errors you get to know about as you type them
<jared-w>
drakonis: I've seen hnix! I like it. It'll be cool to see where it goes
evanjs has joined #nixos-chat
<ldlework>
it's like why even though it feels funny, type hints are objectively useful in Python
<jared-w>
ldlework: the typesystem is trivially unsound *and* incoherent
<jared-w>
which is impressive
<ldlework>
jared-w: what do you expect though?
<jared-w>
Eh, nothing else
<jared-w>
But it does mean that you end up faking types to mock out your API in the hopes that developers figure out how to not ignore the red squiggles and maybe sorta kinda use your API right
<ldlework>
yeah, but that's way better than nothing
<ldlework>
way better
<elvishjerricco>
TS is so much better than JS
<elvishjerricco>
They're both terrible
<jared-w>
yeh, but I can see how people write off and get jaded with TS when you have to spend a week hunting through a bug you introduced because you tried assume the type system would actually help you
<elvishjerricco>
But TS at least allows me to *try* to make some tiles
<elvishjerricco>
s/tiles/rules/
<ldlework>
yeah i'm just happy that there is active progress to improve ES and TS is actively supported by a company like MS
<ldlework>
like, take those two factors out
<ldlework>
and a worse universe we have
<jared-w>
At least with JS you know you're blind whereas with TS you can almost think you're safe which, in some ways, is even more dangerous
<ldlework>
nah
<jared-w>
(particularly if you try to type the result of a fetch call)
<ldlework>
i've written some medium sized things in TS
<joepie91>
jared-w: I don't "dislike" JS, though I do have criticisms about it. my problem is with TS, which adds a very mediocre type system that doesn't really prevent much, at the cost of no longer being able to play to JS' strengths (namely, trivial abstraction), and so you just get the worst of both worlds.
<joepie91>
if you want static typing, use an actual statically typed language (Rust or Haskell or whatever), not some bolt-on thing like TS
<ldlework>
the safety it brings, and so the immediate productivity far outweights any hangups you're alluding to
<joepie91>
ldlework: and this is *precisely* the discussion I wanted to opt out of
<jared-w>
Oh don't get me wrong. TS 100% of the way. I like TS far more and it's hugely more productive than raw JS for me.
<joepie91>
it goes the exact same way literally every time someone tries to have it
<ldlework>
joepie91: have some self control?
<ldlework>
hehe
<joepie91>
always the same arguments, always missing the same aspects of JS
<jared-w>
But, like, I try not to pretend I'm magically safe about it
<joepie91>
it's not a discussion worth having anymore to me
<ldlework>
and yet
<jared-w>
and yeh, TS fundamentally changes what API designs you're allowed to do conveniently
<ldlework>
obviously as someone who is selling the merits of any kind of savings from the help of any kind of type system I agree that languages with better type systems come with even more benefit
<jared-w>
which is huge. Same goes for C/C++ API designs vs Rust API designs. Not all of those design changes are always unambiguously better
<ldlework>
i just don't see that as a reason to discount TS
<elvishjerricco>
The "convenience" of dynamically typed APIs has always alluded me
<ldlework>
It's far easier to get my team to use TS when they're using JS to get them to use Haskell
<ldlework>
If I can do that, then we get the benefits TS brings if not those that Haskell could
<ldlework>
it's a perfect enemy of good thing
<jared-w>
ldlework: I've noticed that too. It's a small shift vs a complete paradigm changer, and of course there's the whole "GHCJS sucks and purescript is slow as hell" thing to contend with
<ldlework>
who knows how good haskell's js transpilation is, or how well it interoperates with vanilla libs
<elvishjerricco>
GHCJS and PureScript are so sad... Hoping the WASM work goes well
<ldlework>
forget having one toolkit centered around npm
<jared-w>
I do find a certain irony in people arguing against Elm because debugging the JS is hard, but they'll use babel+webpack+transpiling+React+stylish components+friggin mdx files with no problem
<ldlework>
to just dismiss people who would have this conversation for not being liek muh haskell, i think is a bit whimsical let's say
<jared-w>
It's like as soon as they lose the curly braces they're like "oh my god how am I supposed to debug this"
<ldlework>
jared-w: to be fair, MLs are a bit wierd and Elm is a weird ML
<ldlework>
if all you've done is JS or cousins
<jared-w>
/shrug idk how's that debugging "accessing f of undefined at line 1:98236732 going for you?"
<elvishjerricco>
ldlework: Weird for people who grew up on curly-brace-like languages
<ldlework>
nah man, i like SML and CSML and F# and OCaml
<ldlework>
Elm is weird
<jared-w>
ldlework: true, but that's a consistent argument I see when, in reality, the gap between "JSX & CSS in JS" and sourcemaps is further than elm to sourcemaps
<ldlework>
i just mean, if i turned to my coworker and was like
<jared-w>
joepie91: I do respect the "playing to JS's strengths" argument though, fwiw
<ldlework>
ok look, i can't take this anymore, we're moving to either TS or Elm
<ldlework>
it's gonna be TS like 80%
<ldlework>
more because Elm is an ML rather than Elm is a wierd ML
<jared-w>
and if it was between Elm and PureScript, 80% of the time it's "well have fun on your job hunt, feel free to use me as a reference" :p
<ldlework>
haha
<ldlework>
indeed
<ldlework>
in my opinion, F# is a nicer ML than Elm and the F# community has not only produced a very good JS transpiler, but they've also created a very good web ecosystem replicating Elm's design and architecture
<ldlework>
if you have to add "using .NET for the first time" it's probably not a possible sell
<ldlework>
but those things equal, i really think they've done a better job
<joepie91>
jared-w: (I'd go into more detail if it weren't liable to explode in a fireball of "no you're wrong JS sucks lrn2types"...)
<ldlework>
they have really magical things built ontop of their Elm clone
<jared-w>
joepie91: My DMs are a safe space, feel free to slide in :p
<jared-w>
ldlework: F# has a JS transpiler now?
<ldlework>
yeah it's good
<ldlework>
and they built a bunch of high quality web stuff on top
<ldlework>
which is all F#
<ldlework>
you got F# on the frontend and stuff
<ldlework>
it's sick
<ldlework>
you just have to confront "using .net for the first time"
<ldlework>
argh!
<jared-w>
noice. I knew ocaml had a pretty good one and that FB did a uwotm8 with it and released reasonML because language fragmentation wasn't bad enough
<ldlework>
ocaml is legit ml, but feels dated - no it's just ugly
<jared-w>
semicolons, so not trending rn
<ldlework>
there's other things too
<ldlework>
but ocaml is legit i hate to talk negatively about it in anyway since more people should at least try it
<jared-w>
heh, yeah. OCaml's GC is also just absolutely ridiculous
<ldlework>
if you like ocaml gc stuff, you might like Nimlang
<ldlework>
they designed Nim's gc as a love story in some ways
<ldlework>
but then also made it highly programmable
<jared-w>
been seeing Nim trending a lot lately
<ldlework>
so you have some pretty silly levels of control from your own program over it's GC
<ldlework>
you can even use multiple and assign heaps and stuff
<ldlework>
it's neato
<ldlework>
jared-w: Nimlang is worthy of a lot of praise
<ldlework>
it does a few things that i find unfortunate but overall it's super solid language. very contemporary
<jared-w>
noice. Gotta look more at it now
* jared-w
pencils in some stuff to my list of growing negative free time
<ldlework>
where Golang was like how can we forget the last 50 years of PL design, Nimlang looked back and was like "what do people *love* from the last 50 years."
<ldlework>
admittedly they have seemingly randomly diverged from that principle in a couple places
<ldlework>
one of nim's coolest features is that its compiler features a VM for a major subset of the language which allows them to implement really powerful hygenic ast macros and other metaprogramming features
<ldlework>
like, if you've ever fucked with xml/html parsing, xpath, or generating xml/html stuff like that, then you basically have all the skills to do absolute black-magic in Nim
<ldlework>
which some people might turn their nose up at, but for some things not even a powerful type system can really express in the most natural way
<ldlework>
sometimes you need black-magic metaprogramming. things like trying to create ECS frameworks with simulatenously nice to use APIs and OK to maintain implementations
colemickens_ has joined #nixos-chat
colemickens_ has quit [Quit: Connection closed for inactivity]
JakeRake has joined #nixos-chat
JakeRake has left #nixos-chat [#nixos-chat]
endformationage has quit [Ping timeout: 240 seconds]
<ashkitten>
samueldr: will you be upstreaming your stage0 for nixos-mobile? it would be very useful for arm laptops using uboot to list generations, i think
<eyJhb>
It's always fun with a exam, where the questions doesn't make much sense and the slides give nothing extra info
kenjis has joined #nixos-chat
<ashkitten>
ahahah, the us government apparently funded a smartphone that was found to have what appears to me from skimming the article as the same malware that shipped with the cosmo
kenjis has quit [Remote host closed the connection]
Jackneilll has joined #nixos-chat
Jackneilll has quit [Quit: Leaving]
__monty__ has joined #nixos-chat
nckx has quit [Ping timeout: 268 seconds]
kenjis has joined #nixos-chat
drakonis has joined #nixos-chat
<eyJhb>
... Read up to exam, or setup Mutt?
endformationage has joined #nixos-chat
drakonis has quit [Ping timeout: 248 seconds]
drakonis has joined #nixos-chat
ivan_ has joined #nixos-chat
ivan has quit [Ping timeout: 268 seconds]
<tazjin>
eyJhb: set up notmuch :3
wildtrees has joined #nixos-chat
<Church->
Setup mutt
<Church->
Ugh, notmuch
<__monty__>
You're the first persone I've heard not liking notmuch.
* Church-
shrugs
* joepie91
throws DBeaver out of the window
<__monty__>
Please put your dislike into more words.
<gchristensen>
I would say I don't like notmuch, but that isn't true -- I don't like offlineimap/mbsync/isync, and I also hate email no matter what way it is sorted and displayed
<joepie91>
taking suggestions for an actually-usable, non-terminal PostgreSQL client
<joepie91>
requirement: must not break in a dark theme
<joepie91>
(so pgadmin is out)
<gchristensen>
linux I assume
<gchristensen>
there was this really great one I paid $300 for back in 2010, but it was macos
<__monty__>
joepie91: Why so little terminal love?
<tazjin>
gchristensen: at least for gmail + notmuch, the whole syncing problem is now solved by lieer
<tazjin>
which is excellent
<joepie91>
__monty__: really not interested in that discussion right now, sorry
<gchristensen>
lieer?
<joepie91>
gchristensen: yeah, Linux (and preferably free, as I will only occasionally be using it)
<gchristensen>
tazjin: ah, bummer now that I don't use gmail anymore :|
<gchristensen>
but, finally!
<drakonis>
by the way do we have any channel for off the record talk?
<drakonis>
not logged talk
<gchristensen>
we don't
<drakonis>
aight
<__monty__>
drakonis: Keep in mind that many people log irc. There's more than just public logs.
<drakonis>
i'm aware yes.
<drakonis>
i have my own logs but i mean non public accessible logs
<drakonis>
non webfacing logs that is
<drakonis>
that's far more important than local logs
<__monty__>
Just making sure.
<gchristensen>
for a couple reasons, almost everybody keeps logs on their own and so it isn't really a promise, but also I think it is important for the culture and community since people may act very differently if they think it is private, and in (almost) all cases the desirable culture is one where the behavior is okay being public
<drakonis>
its nothing offensive nor an attack towards anyone
<gchristensen>
of course
<gchristensen>
but dark rooms can make strange things
<drakonis>
of course
<__monty__>
Even though I consider IRC public forum. I still redact nicks when sharing snippets from my logs if the sharing happens outside the logged channel/group of channels.
<gchristensen>
same
<drakonis>
so as it happens, i have previously talked about metadata on packages for organization, and when i talked about it yesterday, i pretty much took inspiration from a fosdem talk regarding that
<drakonis>
its basically the same core idea
<drakonis>
it makes feel a bit awkward for doing that
<__monty__>
Just properly acknowledge the work you're deriving from/
<__monty__>
*?
<drakonis>
again, i have talked about this kind of thing before yesterday, i can even fetch the logs where i talked about it
<drakonis>
"talk is cheap, show me the code" someone said once
<infinisil>
oh that sounds better
<drakonis>
looks like linus torvalds said that one
<drakonis>
hmm
<drakonis>
20 years ago
<drakonis>
time flies doesnt it.
<gchristensen>
pretty much every project maintainer annoyed by "could"s and "should"s says that :P
<__monty__>
Hmm, my default reply's more along the lines of "Sounds great. Let me know when it's ready to merge."
<infinisil>
How many levels deep are other people here in regards to being sidetracked?
<infinisil>
My sidetracking level is about 3 now
<drakonis>
6
<drakonis>
i have a problem
<__monty__>
I use a fixed depth fifo : >
<__monty__>
Means sometimes I get side-tracked doing the original thing I was doing...
<infinisil>
Recursive sidetracking
<samueldr>
ashkitten: the goal with all of mobile nixos is to it to be subsumed in upstreams as much as possible
<samueldr>
and yes, once it's been proven, the intent is to make it usable standalone as much as possible
<infinisil>
My sidetracking consists of: Wanting to improve my system config -> Rewriting an ugly module of it -> Creating a better secret store because the module needs secrets
<drakonis>
no secret store rfc?
<drakonis>
i should be learning scheme right now
<infinisil>
Hehe, that would be a hard one
<infinisil>
And I already have 2 open RFCs :)
kenjis has quit [Remote host closed the connection]