<infinisil>
Works for me, I'm using wg-quick, all network traffic goes through the wireguard server
enick_64 has joined #nixos-chat
<bbigras>
infinisil: do you add an iptables rules to allow all the traffic or something like that? it's been a while and I don't have my old nix-config. I could check in my backups.
<adisbladis>
It's a monstrosity, but at least it's a monstrosity that works pretty well
<infinisil>
adisbladis: I think a major problem is Nix's directory hashing
<infinisil>
Because it's a whole custom thing which nobody else will have support for
<adisbladis>
infinisil: Sure, but who else actually does directory hashing?
<infinisil>
I'm thinking about downloading sources from tarballs, which then get unpacked and content hashed for fixed-output drvs
<infinisil>
If package managers want to make it easy for Nix, they would have to export Nix's directory hashing
<adisbladis>
But in those cases you could just not unpack in the FOD?
<infinisil>
Or alternatively guarantee that tarballs are never updated (which i think pypi does)
lunc has quit [Ping timeout: 240 seconds]
<infinisil>
Yeah ^
<infinisil>
But e.g. github doesn't do that, pretty sure the tarball hashes can change over time
<adisbladis>
infinisil: Probably the biggest thing we could do is to make Nix trust git sha's directly
<infinisil>
Yeah, at least that's now the case with fetchGit (though that's eval time)
<adisbladis>
"Kind of"
<infinisil>
kind of?
<adisbladis>
It's pretty impure
<infinisil>
Ah yeah..
<adisbladis>
It requires impure caching to achieve what it's doing :/
<adisbladis>
I mean.. I don't know how else it would do it
<adisbladis>
Without changing the entire source fetcher model
<adisbladis>
So I appreciate that we have the feature
<adisbladis>
infinisil: I think the best thing "we" (the Nix community) can do to get more poetry2nix style stuff is to keep our eyes open for promising $lang package managers and get in early enough to educate authors around packaging
<adisbladis>
If I didn't get in early and managed to push some changes in the lock file format before 1.0 the whole thing would have fallen apart
<adisbladis>
It requires a lot of effort and tenacity
<infinisil>
But like, it only works for poetry because sources are all mirrored with pypi, which doesn't update tarball hashes like github, right?
<adisbladis>
Of course it requires consistent hashes
<adisbladis>
It doesn't magically break some property of Nix ;)
<infinisil>
Yeah, so this gets pretty tough for all the package managers which allow getting sources from e.g. github
<adisbladis>
But how much do github tarballs actually change?
<infinisil>
Hmm not sure, investigating..
<adisbladis>
I was under the impression they didn't?
<adisbladis>
We use a lot of pinned github tarball hashes in nixpkgs...
<infinisil>
adisbladis: The tarball hashes change, but not the contents, so as long as you unpack before hashing you're good, which is what fetchzip and fetchTarball do
<infinisil>
Oh yeah, github uses `git archive` to generate tarballs
<adisbladis>
Oh yeah, that homebrew issue rings a bell
<infinisil>
And from `man git archive`, I don't see any mention of archive determinism, and it also provides options for changing compression level
<adisbladis>
Probably not reliable at all then ;)
<infinisil>
Yeah..
<infinisil>
So yeah, if a source provider updates the tarballs over time, package managers can't use the hash of it directly because that changes over time, and they can't use the hash of the contents either, because there's no standard way to hash a directory
da_dada has quit [Ping timeout: 246 seconds]
<infinisil>
I guess they could fetch the thing, unpack it, *repack* it deterministically, and then hash it..
<infinisil>
But I doubt a package manager would go to these lengths just for nix
<adisbladis>
Heh :P
<adisbladis>
That's pretty much what we're doing right now
<infinisil>
Nix does that?
<infinisil>
(I don't think so?)
<infinisil>
Ohhh
<infinisil>
Yeah no it does
da_dada has joined #nixos-chat
<adisbladis>
The directory hash is the nar hash
<infinisil>
Yeah got it
<infinisil>
Is there perhaps a more standard way to hash a directory?
<infinisil>
Ugh, that's pretty hard to understand, too much for my 4am brain
<infinisil>
It's explained in a bit too much detail
<adisbladis>
infinisil: Bytes go in, bytes go out
<adisbladis>
You can't explain that
<infinisil>
Looks like it hashes all files recursively, then concatenates the path+hashes from all of them and hashes that
<infinisil>
But seriously, we need a directory hashing standard
<lovesegfault>
infinisil: I have an idea :D
<lovesegfault>
To simplify bootstrapping new systems
<adisbladis>
infinisil: What feature set do you want to support?
<lovesegfault>
let nixus expose something that builds the default NixOS non-graphical ISO, but has one extra binary nixstrap which, once you've done all your partitioning etc, just does a "local deploy" to /mnt
<infinisil>
lovesegfault: maybe better for #nixus ?
<lovesegfault>
infinisil: yup, moving there
<infinisil>
adisbladis: Well for Nix we don't need support for owners and modes
<infinisil>
Though executable bit is needed
<infinisil>
And symlinks should be supported as well
<infinisil>
But if it's configurable like the dirhash standard, it's not really a problem to change the featureset
<energizer>
it doesnt look like the video in that issue
<energizer>
so maybe it's the wm's fault
<patagonicus>
That's a different issue, but I had the opposite of yours happen as well - Chromium would draw itself even if it was on an inactive workspace.
<patagonicus>
Sorry, different symptom, same root cause (most likely).
<__monty__>
Isn't color usually simply dictated by price?
<ar>
maybe
okad has quit [Quit: okad]
strobelight has joined #nixos-chat
strobelight has left #nixos-chat ["part, cya!"]
bridge[evilred] has quit [Remote host closed the connection]
bridge[evilred] has joined #nixos-chat
j4m3s__ has joined #nixos-chat
cosimone has quit [Ping timeout: 246 seconds]
cosimone has joined #nixos-chat
<eyJhb>
I seem to remember some Elm advocates, where you people at? Thinking of picking it up, but not sure if I should just go with VueJS etc.
<gchristensen>
I like elm
<eyJhb>
gchristensen: Do you then write it all in elm? And how do you incorporate it with other stuff, e.g. if you wanted UiKit?
<gchristensen>
I write basically zero front-end code
<gchristensen>
but I really like to use Elm when I'm doing a web thing
<eyJhb>
I really want to be better at doing frontend stuff. Like, I can "easily" write it, but the desgin part is what takes it toll on me
<eyJhb>
But it just seems like Elm is super nice, and has a lot of awesome features and the no runtime errors, that is just pure godness
<gchristensen>
yeah
<gchristensen>
my "secret" to UIs is steal
cosimone has quit [Quit: cosimone]
<eyJhb>
Ohh! You thief!
<eyJhb>
I do the same, but I end up wanting it minimal and sleak (code wise), and they have so much crud in the stuff you find online
<gchristensen>
grahamc.com's design was copy-pasted from Safari's "Reader View" rendering of my previous design
<eyJhb>
I should do more stealing. My newest design is... Shit
<eyJhb>
It's more like Grids, than actual design
<ar>
gchristensen: what is the reader view of that now?
<ar>
or, actually: does it make it any different now?
cole-h has joined #nixos-chat
lassulus has quit [Ping timeout: 260 seconds]
lassulus_ has joined #nixos-chat
lassulus_ is now known as lassulus
<gchristensen>
I dunno, I don't have a mac anymore
<gchristensen>
I imagine they have a new reader mode style though
<ajs124>
Are any of you using lego (through security.acme.certs) with dns01 (and rfc2136)?
<ajs124>
I'm trying to deploy that right now, but it's failing for most of the certs most of the time after "Waiting for DNS record propagation" with "NS $NS returned NXDOMAIN for _acme-challenge.$DOMAIN".
<ajs124>
The records seem to be there if I dig @ the ns, so idk what could be going wrong. Maybe lego is doing something weird?
<andi->
is lego using the local DNS server or did you specify one?
<andi->
I've tried to teach lego retries on DNS failure as it currently just barfs and exists on those but upstream doesn't really want the fix I provided..
rajivr has quit [Quit: Connection closed for inactivity]
<ajs124>
resolver? I tried both local and 1.1.1.1.
<gchristensen>
LE'd be using root DNS servers to find your DNS server to ask it, no?
<hexa->
primary*
<hexa->
ah yeah, resolve recursively, but ask the primary for the records
<andi->
Yeah it is supposed to do that but at least of the non-DNS challenge part it just uses the system resolvers..
<hexa->
lego checks for propagation before asking LE to check
<gchristensen>
aaah
<gchristensen>
115kmph winds on christmas day :x
<andi->
nice, so you can fire up your local hydra and still make money by selling the energy? :D
<gchristensen>
hah
<gchristensen>
I wish, instead I'm trying to decide if I should go get a generator or come up with a contingency plan for if we don't have heat for a week
<ajs124>
I like how it's NOT a fatal error if lego can't read a secret from a file specified in the environment. Like, how is that reasonable?
<steveeJ>
clever: I still have your pxe boot "justdoit" script bookmarked and I'm wondering if you ever built something more polished from it
<clever>
steveeJ: not yet
<gchristensen>
steveeJ: it'd be nice to have cobbler-but-for-nixos eh?
<hexa->
ajs124: file an issue please
<steveeJ>
gchristensen: the only "cobbler" I know consists of fruits and nuts. are you talking about that one? :-D
<ajs124>
hexa-: no time. need to get this working first, can yell at them later.
<andi->
gchristensen: https://www.theforeman.org/ also does something like that.. might even be using cobbler
<gchristensen>
gotcha
<steveeJ>
gchristensen: I was guessing you would quietly be working on bringing https://tinkerbell.org/ to the nixos world
<gchristensen>
cobbler is at least 10yrsold now
<gchristensen>
steveeJ: sorta, but my contract with Packet never got to that part :)
<steveeJ>
I don't know why but I feel so much resistance to even getting started with a 4-node cluster on my desk without some automation around it
<steveeJ>
also wondering whether installation and post-install upgrades should be tied into one system?
<gchristensen>
bootstrappnig hardware sucks in a lot of ways that ongoing maintenance doesn't
<steveeJ>
I can see that. I could probably get away with installing the 4 nodes manually
<sphalerite>
gchristensen: contrast 0/10
<steveeJ>
gchristensen: do you know a good read about how you or others manage config (maybe in form of nix channels) for pull-based auto-update/auto-reconfig of existing syst3ems?
<gchristensen>
sphalerite: contrast?
<sphalerite>
gchristensen: on cobbler's "about" string
<drakonis>
steveeJ: basalt?
<drakonis>
maybe i'm confusing what you wnat to do
<steveeJ>
drakonis: reading the basalt docs now. it looks like something I'd want, thank you
<steveeJ>
drakonis: is it currently maintained?
<drakonis>
yeah i dont know for sure right now
<drakonis>
development seems to have stopped a few months ago?
<steveeJ>
drakonis: I'm worried only because I don't know Haskell so couldn't even do quick fixes quickly
<drakonis>
that's troublesome
<drakonis>
i know that nix is functional as heck, but dont write things in impenetrable haskell :V
<drakonis>
useful things written in impenetrable languages
<sphalerite>
Haskell is far from impenetrable
<sphalerite>
I mean, some Haskell code certainly is
<sphalerite>
but that's no different from other languages.
<steveeJ>
so to round out my view: are there alternatives to basalt? chances are there are as I also hadn't heard of basalt before :-D
<steveeJ>
would be awesome to have something like that in the nix-community space, so it'd be somewhat of a convention to use it
<gchristensen>
I'd like to see a pull-based version which evaluates and builds remotely, instead of on the target being updated
<gchristensen>
evaluating nixos is significantly heavy, so making that happen on a production machine is not great imo
<sphalerite>
well then you could use nixops in a gitlab CI pipeline for instance, no?
<gchristensen>
nixops is push
<sphalerite>
uuuh… then I don't get what you mean
<gchristensen>
what if your update system was (at a fundamental level, but not actually as trivial as) $(nix-store -r $(curl https://update-server/$macaddr))/bin/switch-to-configuration switch
<sphalerite>
gchristensen: ok but if you're evaluating and building on a different machine from the one being updated… why does it matter if you're pushing to the updatee or the updatee is pulling?
<__monty__>
sphalerite: I guess a machine might know better when to go for updates, i.e., *not* when it's under high load?
<gchristensen>
sphalerite: pull tends to work better when you have a lot of things doing the action, with staggered retries, easily scaled distribution mechanisms, don't have to figure out how to push in a distributed way if you are already pulling
<gchristensen>
I dunno
<gchristensen>
imagine how you'd want to deploy to 10,000 nixos servers: would you rather have them pulling or would you rather push?
<__monty__>
Hmm, simply addressing 10k entities vs 1 does already sound a lot more involved.
<__monty__>
Though push does seem simpler at a glance. Probably don't have the right intuitions when it comes to distributed systems though.
<gchristensen>
it is simpler in the small, for sure
<gchristensen>
I've been trying morph lately and it is pretty good but even at a handful of servers its (sequential) push is feeling slow
<joepie91>
morph could really use parallel upload
<joepie91>
at least
<steveeJ>
gchristensen: any chance you've tried serokell's nix-deploy-rs as well?
<steveeJ>
gchristensen: also I think it's worth discussing that NixOS's auto-updater is already pull-based. so tooling to make building custom channels awesome would be valuable maybe?
<steveeJ>
and I'm very likely missing projects that target the latter
<gchristensen>
the auto-updater doesn't reaaallly work very well because you need the total configuration expression on that machine
<steveeJ>
gchristensen: mh, as opposed to a system closure?
<sphalerite>
gchristensen: multicast push :pp
<steveeJ>
sphalerite: would you want to upload from your admin machine to 10k servers?
<steveeJ>
sphalerite: mh, my mind automatically ditched multicast for what it is. now thinking it about it consciously, would multicast be at all realistic on WAN?
<gchristensen>
sphalerite: okay now you require significant control over your network :P
<gchristensen>
steveeJ: you can't multicast on the public network
<sphalerite>
steveeJ: no :D
<gchristensen>
sphalerite: tumblr had the netcat forwarding pipe to copy big datasets to many machines quickly, but it required no network faults to succeed
<sphalerite>
ok if multicast isn't an option then I'll take bittorrent :D
<gchristensen>
back to pull, I see!
<__monty__>
Why can't you multicast over the internet? Maybe not IP multicast but that's flawed in many ways anyways.
<gchristensen>
how would you multicast if not IP?
cosimone has joined #nixos-chat
<sphalerite>
__monty__: because the internet runs over IP?
<__monty__>
Application layer multicast?
<gchristensen>
it defeats the purpose of multicast
<__monty__>
Your build box pushes to a couple production machines which push to yet more production machines.
<gchristensen>
which is that with IP multicast every actor knows how to do it efficiently
<__monty__>
No it doesn't.
<gchristensen>
okay it doesn't
<__monty__>
It doesn't magically work but neither does IP multicast.
<gchristensen>
IP multicast is incredibly efficient at pretty much every layer, and that is not possible with it being at the application layer
<gchristensen>
so does it defeat the purpose of the idea of multicast, no, but it does defeat the performance benefits of using IP multicast
<sphalerite>
__monty__: that's not really multicast though, in that it doesn't reduce the amount of transmissions, just moves them to different places
<sphalerite>
wait let me think if there's actually a difference :p
<sphalerite>
yeah so in multicast the routers are aware of it and multicast the message, as opposed to the peer-to-peer thing you suggest __monty__ where only the terminal nodes are aware of it
<gchristensen>
https://signalsandthreads.com/multicast-and-the-markets/#1153 "they can just electrically repeat those bits simultaneously to 48 ports, or whatever, that that switch might have. And that’s just going to be much faster and more regular than you trying to do it on a general purpose server, where you might be writing multiple copies writing to multiple places, you really can’t compare the two"
<gchristensen>
"One of the key advantages of using switches is that the switches are doing the copying in specialized hardware, which is just fundamentally faster than you can do on your own machine."
<__monty__>
No one's disputing IP multicast is more efficient and maybe desirable in some niche usecases.
* gchristensen
is no longer engaging in this conversation
<__monty__>
But since we're looking at a problem where it's not even an option, multicast over the internet, I don't see why "It's less efficient than IP multicast," is even a problem.
<__monty__>
IRC is multicast over the internet.
<steveeJ>
gchristensen: more on the topic of native NixOS auto-updater vs an aftermarket one. assuming all package derivations are available at the binary cache, can we neglect performance in that case? what are the other factors contrary to the native auto-updater?
<gchristensen>
the native one is really designed for, like, the laptop case
<gchristensen>
where all yoru config is entirely local and you just run nixos-rebuild switch
<steveeJ>
is it unrealistic to put all config in a custom nix-channel?
<steveeJ>
I'm not sure if I've fully thought this through. but I imagine the local nix config would pull in a specific profile provided by the custom nix channel
<gchristensen>
it might be fine
<steveeJ>
and the local config would be put in place by the bootstrapping step
<gchristensen>
but still I'd rather not be evaluating configs locally
<andi->
Is what I occasionally do to switch my system to what CI has build.
<gchristensen>
cool
<andi->
that is as close to a personal channel as I want to come..
{^_^} has quit [Remote host closed the connection]
{^_^} has joined #nixos-chat
<steveeJ>
I vaguely remember a project that was a custom pull-based auto-updater but I can't find it now. it's written in haskell and either by tweag or target or someone around there
<andi->
here is the `hail` module in nixos
<andi->
that pulls from hydra
<steveeJ>
andi-: mhh, my memory is not serving me well, can't even confirm or deny that's what I was referring to
<andi->
I am not even sure someone uses it. The file wasn't touched since it was added in 2017...
<steveeJ>
andi-: thanks for digging that up though :-)
<andi->
no digging required, had it right here in memory :D
<steveeJ>
I'm kind of sad about activity being spread out thinly vs coordinated
<andi->
Can you expand on that?
<steveeJ>
the feeling stems from my perception that there's a pattern in the NixOS ecosystem of what looks like the beginning (beyond a PoC) of awesome projects and then they're left alone
<andi->
I have the feeling a lot with Nix :/
<gchristensen>
imo a lot of community itch-scratching and less concerted and well-funded efforts
<andi->
It is a nice PoC and research project but not polished
<hodapp>
did the Unison language - which reminded me a bit of NixOS in its principles - ever catch on much? I bookmarked it but hadn't read much in a year or two
lassulus_ has joined #nixos-chat
<gchristensen>
a buddy of mine works for unison web, I think they're growing
<hodapp>
it seems a neat concept and one that I can't name anything else comparable to in the land of programming languages
<gchristensen>
the wey they do PRs is ... interesting ....... and I think too weird
<{^_^}>
starship/starship#1446 (by matchai, 24 weeks ago, open): Replace the use of git2 with calls to the Git CLI
<cole-h>
yep
<andi->
hard to believe that solves their performance issues
<bbigras>
I have no idea
<andi->
a bunch of forks vs a bunch of native function calls
<gchristensen>
the only time I saw git-in-ps1 be ~fast was when it literally used a background daemon
<cole-h>
:D
<andi->
that is what pl10k is doing
<andi->
spawns a daemon for every shell I open..
<gchristensen>
okay well that isn't great
<andi->
yeah
<andi->
I also do not know why not just one daemon for all the shells
<bbigras>
the starship main dev would like to try to make it an async prompt eventually
lassulus has quit [Remote host closed the connection]
<andi->
tbh I don't think I need half the features of p10k.. For git stuff I always run git status manually anyway.
<bbigras>
you can probably disable the git stuff with starship
<andi->
On the other hand: never touch a running system..
<cole-h>
s/probably//
<andi->
It isn't one of the concerns I have right now
<bbigras>
cole-h: I mean. there's a config and stuff. I would be surprised if you can't disable it.
<cole-h>
Right, I was making your statement be "you can disable the git stuff with starship"
<bbigras>
I don't know why I didn't realize that. I know the s/before/after replacement thing
<cole-h>
:p
lassulus has joined #nixos-chat
<andi->
I'll wait another 5y before rust will be a dependency I add to my shell prompt.. Too early. The language isn't even 15y old :D
<bbigras>
we might live in a fallout game in five years
endformationage has joined #nixos-chat
<energizer>
bbigras: doesn't short time-horizon mean i should go with the known-good thing instead of the uncertain thing
<bbigras>
yeah. rust is great then :)
<drakonis>
oh my goooood
<energizer>
ok but investing in immature rust ecosystem projects will not pay off until later
<drakonis>
kde plasma 5.20 has landed
<drakonis>
finally
<bbigras>
it's not immature
<drakonis>
the crusty old kde plasma is out of the way
<energizer>
everything about rust is immature
<drakonis>
what language should i use instead of rust?
<drakonis>
this is a hot question
<energizer>
depends on the use case. in the case we're talking about -- configuring my PS1 -- i use shell
<drakonis>
i need to build an long term application
<drakonis>
i thought rust could be interesting
<energizer>
probably rust or go, i would think
<drakonis>
its simultaneously web facing and not
<bbigras>
I work full time with rust and I enjoy it. your mileage might vary.
<bbigras>
go is good too
<drakonis>
once upon a time, i wanted to make a thing with elixir and clojure but it seems like a lot of overhead
<energizer>
my claim was just that "the world might end tomorrow, man" is an argument against rust, not for it
<joepie91>
drakonis: depends on project, but I default to JS unless there is a specific reason why JS would not be suitable for it (super-constrained resource footprint, embedded device, heavily centered around dealing with numbers, etc.)
<joepie91>
(my interest in Rust is actually largely because it complements JS really well there, basically everything that JS is bad at, Rust is good at, at least on paper)
<drakonis>
its not a thing that JS would handle
<energizer>
what does it need to do that js is bad at?
<drakonis>
numeric processing, a significant number of connections, lots of database work
<drakonis>
i'd also like to use it in a resource constrained environment as well
<drakonis>
ie: microcontrollers
<joepie91>
significant number of connections and lots of database work are not an issue, numeric processing is fine so long as it's not the core premise of your application, but if you target microcontrollers then yeah, JS is out
<joepie91>
there's Duktape but I wouldn't wish that on anyone
<drakonis>
it is the core premise
<joepie91>
yeah okay, not suitable then :)
<drakonis>
the bits that are on the servers are number processing related
* energizer
can't quite imagine what application runs on a microcontroller, using a database, with many connections, doing numerics
<drakonis>
sorry, its a big application spread across various devices classes
<drakonis>
the microcontroller wont do a lot of heavy lifting
<energizer>
some people say "the best language for your next project is the language you know best", which has some truth to it imo
<drakonis>
yes but then, i'd rather learn something new that's best for the task at hand
<energizer>
(excluding obviously inappropriate languages, of course)
<drakonis>
rather than trying to shoehorn something into doing a thing it cannot handle
<drakonis>
i wouldnt use python for this :v
<drakonis>
i like python to a certain degree
<energizer>
hmm python is used for those tasks for sure
<drakonis>
for some of them maybe
<drakonis>
but not all of them
<energizer>
which tasks is it not used for?
<drakonis>
hmm, turns out it can be used for microcontrollers, but it needs a separate compiler