gchristensen changed the topic of #nixos-chat to: NixOS but much less topical || https://logs.nix.samueldr.com/nixos-chat
drakonis2 has quit [Read error: Connection reset by peer]
drakonis2 has joined #nixos-chat
drakonis has quit [Ping timeout: 256 seconds]
parsley936 has quit [Remote host closed the connection]
<gchristensen> would it be weirdly self-serving to link to my blog post from the impermanence readme?
<gchristensen> also, impermanence might be the thing to get me using home-manager
<risson> I don't think so, it's a great introduction for people new to this
<energizer> there are two reasons: acknowledging the post as inspiration, and providing background reading for the user
Peetz0r has quit [Ping timeout: 256 seconds]
<DigitalKiwi> what's impermanence readme
Peetz0r has joined #nixos-chat
<DigitalKiwi> oic
Peetz0r has quit [Ping timeout: 258 seconds]
Peetz0r has joined #nixos-chat
Peetz0r has quit [Ping timeout: 260 seconds]
Peetz0r has joined #nixos-chat
Peetz0r has quit [Ping timeout: 272 seconds]
Peetz0r has joined #nixos-chat
slack1256 has quit [Remote host closed the connection]
<cole-h> gchristensen: IMO, no. I was actually thinking about PRing both your and etu's blog posts on temporary roots.
drakonis1 has quit [Quit: WeeChat 2.8]
Woutifier has quit [Remote host closed the connection]
<cole-h> gchristensen: OK, done :) https://github.com/nix-community/impermanence/pull/7
<{^_^}> nix-community/impermanence#7 (by cole-h, 17 seconds ago, open): README: add links to inspiration
Woutifier has joined #nixos-chat
waleee-cl has quit [Quit: Connection closed for inactivity]
<JJJollyjim> oof
<JJJollyjim> i just noticed github had a rust project of mine marked as a Nix project
<JJJollyjim> because it has 195 SLOC of rust
<JJJollyjim> and a 2893 SLOC Cargo.nix
<JJJollyjim> maybe this is a sign that i should slim down my dependency tree :P
<JJJollyjim> lol the crate2nix boilerplate is still more than my rust code
<JJJollyjim> guess i gotta write more code
<cole-h> Hehe, we had the same thing happen to the ofborg repo while we were using carnix :P
leah2 has quit [Ping timeout: 260 seconds]
leah2 has joined #nixos-chat
leah2 has quit [Ping timeout: 256 seconds]
leah2 has joined #nixos-chat
cole-h has quit [Quit: Goodbye]
monsieurp has joined #nixos-chat
monsieurp has quit [Quit: Lost terminal]
monsieurp has joined #nixos-chat
cjpb0 has joined #nixos-chat
cjpbirkbeck has quit [Ping timeout: 246 seconds]
cjpb0 is now known as cjpbirkbeck
<sphalerite> JJJollyjim: nothing wrong with using libraries instead of reinventing the wheel :)
<JJJollyjim> Agreed
monsieurp has quit [Read error: Connection reset by peer]
monsieurp has joined #nixos-chat
monsieurp has joined #nixos-chat
monsieurp has quit [Changing host]
hax404_ has joined #nixos-chat
hax404 has quit [Read error: Connection reset by peer]
hax404_ has quit [Client Quit]
hax404 has joined #nixos-chat
__monty__ has joined #nixos-chat
<DigitalKiwi> have you seen the haskell book meme
<srk> no :)
<DigitalKiwi> not the specific one i was looking for but close enough
<srk> :D
<eyJhb> I have begun to hate imports, from anything but std
<eyJhb> stdlib I guess
<srk> DigitalKiwi: embarrassment of extensions :D
<__monty__> eyJhb: Sounds like your language of choice either has a terrible module system, terrible conventions like implicit imports/exports or terrible dependency management?
<eyJhb> __monty__: nope, more trust
<eyJhb> Having a lib that slowly gets unmaintained, or someone else takes over opens up for sooo much
<eyJhb> It rarely happens that someone embeds malware in imports, but it can happen
<joepie91> eyJhb: the solution to that is to review your dependencies :P
<eyJhb> And the unmaintained part.. How should one combat that? Check all imports one by one.
<eyJhb> You know how long that chain gets joepie91 :p
<eyJhb> THe imports of imports
<joepie91> eyJhb: yes, I know, I do this for a living, it is entirely viable with the right tooling and a healthy ecosystem
<joepie91> eyJhb: the problem is seeing it as a cost
<joepie91> reviewing dependencies isn't a cost; it's a cost reduction
<joepie91> because the alternative is exploring all of the problem spaces and writing your own implementations including edge case handling
<joepie91> reviewing an existing implementation takes way less time than rolling your own to a similar level of reliability, even accounting for transitive dependencies
<eyJhb> Not what I am saying. If I can find something with little to no dependencies, I will take it. But if it requires little to no extra code from my side I will handle it myself...
<eyJhb> But the general philosofi in Go is also to use the standard lib, which is where it might come from
<joepie91> I understand what you're saying, what I'm trying to say is that it's based on a faulty premise :P
<eyJhb> Depends on what deps we are taking
<eyJhb> I would never roll my own JWT or crypto lib fx.
<joepie91> additionally, the whole reason "use deps by default" is a thing is because you cannot actually accurately establish the complexity of a given problem without exploring its problem domain first
<joepie91> there are a ton of cases where people think "oh I just need a little bit of code here" and then it turns out they are missing 80% of cases without realizing it
<joepie91> because they misestimated the complexity of the problem domain
<joepie91> this is where the value in single-responsibility dependencies lies, and why tiny dependencies are fine
<joepie91> because not only are some of those tiny dependencies actually not as tiny as you might think for problem domain reasons, some of them will also become more complex over time as other people do the work of discovering the full problem domain for you
<eyJhb> But then you have NPM, which shows that some angry dev can take it all down
<joepie91> eyJhb: what incident are you referring to?
<__monty__> I wouldn't want to work on 5 codebases that each solved "a simple problem" their own way. Even if they're all equivalent module alpha-renaming.
<joepie91> eyJhb: leftpad was a registry policy failure and had absolutely nothing whatsoever to do with dependency size
<__monty__> *modulo
<ldlework> > builtins.unescape "[{\"cases\":[\"module options support\"],\"file\":\"/home/ldlework/src/stix/src/tests/test-options.nix\"}]"
<{^_^}> attribute 'unescape' missing, at (string):315:1
<eyJhb> Deps have pros and cons, use where it makes sense but I wouldn't really be afraid of imlementing small things with little to no disadvantages
<joepie91> eyJhb: see this is the whole problem with the "npm is awful" bandwagon, almost the entire hype against it is based on leftpad, which is an incident where almost noone understands what *actualy* happened there
<eyJhb> joepie91: but it is the concept of depending on something
<joepie91> actually*
<joepie91> eyJhb: no, not in the sense you think
<joepie91> <eyJhb> Deps have pros and cons, use where it makes sense but I wouldn't really be afraid of imlementing small things with little to no disadvantages
<joepie91> yes, the pros far exceed the cons in virtually every case
<joepie91> *including* for "small things"
<joepie91> pretty much the only case where this doesn't hold true is when a dependency is notably badly written
<eyJhb> In 99% of my usecases atm. it really does not
<joepie91> which... is why you should review your dependencies
<joepie91> eyJhb: I can assure you that it does
<joepie91> I think you are underestimating the complexity of solving problems fully
<eyJhb> I can assure you that it doen't, I have many niche usecases
<joepie91> yes, so do I
<eyJhb> I think you do not know how small the problems are :p
<joepie91> one of the major reasons I use JS is that I have many niche usecases
<eyJhb> But got to go now joepie91 , soryy
<eyJhb> sorry**
<joepie91> because unlike most other languages, it actually has an ecosystem that is modular enough to usefully support this
<joepie91> rather than assuming that everyone is building a CMS or an IRC bot
<joepie91> eyJhb: I've been working on niche projects for many years, with weird requirements. I've both written my own implementations for things and used dependencies off npm. since I've started actually (even cursorily) reviewing my dependencies, I've come to the realization that I was significantly underestimating the complexity of the problem spaces I was working with, and in a *ton* of cases what I believed to be a full
<joepie91> implementation of a solution was actually incomplete and missed one or more edge cases.
<joepie91> any one developer isn't going to accurately understand the entirety of the problem domain they are working with; the value of dependencies is in the ability to benefit from the collective experience of many developers with different usecases, in exploring and addressing that problem domain.
<joepie91> and over the years I've come to the conclusion that when someone thinks "oh this is just a few lines of code, I can easily do that myself" it's pretty much a surefire sign that they are overestimating their grasp of the problem space
<joepie91> (I've seen many people claim/think that, and it has held true pretty much without exception so far)
<joepie91> anyway, this addresses that same topic in a more blog-y format: https://github.com/sindresorhus/ama/issues/10#issuecomment-117766328
<joepie91> also, regarding leftpad: that was actually a combination of registry policy failure and people's own bad project management
<joepie91> the whole incident occurred because the registry let people remove published packages; something that pretty much every other language registry realized was a bad idea and therefore disallowed
<joepie91> and because a ton of developers set up extremely stupid CI pipelines, which would re-download all packages from npm whenever a build was done, without any sort of local caching whatsoever, the removal of the package immediately set a bunch of CI pipelines on fire
<adisbladis> Tbf though most CIs have extremely shitty caching options
<joepie91> the same incident would have occurred with a small library, with a big library, even with a library that was maintained by the core Node team and happened to be distributed separately(!) because the problem was ultimately one of bad registry policy
<joepie91> and it would have broken the same way if npm were just, like, down for a while
<joepie91> adisbladis: that's no excuse in JS; there has been an off-the-shelf caching npm proxy available for many years now (previously named sinopia, now verdaccio)
<joepie91> if you cared at all about not being 100% dependent on npm as an SPOF, you were running one of those
<joepie91> the CI itself doesn't even need to have caching functionality
<adisbladis> joepie91: I mean hosted / off the shelf solutions like Travis
<joepie91> adisbladis: yes, same still applies
<joepie91> point it at your caching proxy instead of npm directly
<adisbladis> That you presumably need to host somewhere?
<joepie91> correct
<joepie91> if you don't want to do that, find a CI vendor with a reasonable cache mechanism
<joepie91> this is all ultimately the responsibility of the organization using it
<joepie91> and it's more than a little shitty to offload the blame for that to someone who removed their package
<adisbladis> That's sort of my point, there isn't a single CI vendor out there with decent caching.
<adisbladis> Maybe because the problem space is next to impossible without the Nix model for dependencies
<joepie91> I'm pretty sure I know of people caching their npm deps
<joepie91> without verdaccio
<adisbladis> Sure, you can do that
<joepie91> no idea about the specifics of their setup though
<adisbladis> But most CIs caching strategy is to keep a copy of a directory between runs
<adisbladis> Which obviously breaks pretty often
<joepie91> I mean, that works fine if that directory is your cache folder
<adisbladis> joepie91: I've been developing large nodejs projects with native dependencies. We gave up on caching until we started using Nix because shit broke way too often.
<adisbladis> In the end we _lost_ time by caching
<adisbladis> Since you ended up debugging for an hour every week or so
<joepie91> and ultimately my point here is pretty much: you, as a developer/organization, are responsible for your choice of tools
<joepie91> adisbladis: what specifically did you cache?
<adisbladis> joepie91: node_modules
<adisbladis> joepie91: We're in agreement :)
<adisbladis> I'm just stating that I understand why so many organisations have really shitty caching
<joepie91> adisbladis: so... don't do that
<joepie91> node_modules is not a cache folder :P
<joepie91> there is a separate cache folder, in both npm and yarn, where the upstream packages (and metadata I believe) are stored
<joepie91> that's the one you want to be caching
<adisbladis> joepie91: Yes, I know this.
<adisbladis> But the dev(s) who set it up didn't
<joepie91> <adisbladis> I'm just stating that I understand why so many organisations have really shitty caching
<joepie91> sure. but that is still their responsibility.
<adisbladis> And travis-ci/gitlab/whatever all tell you to cache node_modules
<adisbladis> So you end up with that kind of broken setup by cargo culting
<joepie91> sure, I can believe that. but again, their responsibility.
<joepie91> that is the underlying point here.
<joepie91> the whole leftpad bandwagon has varyingly been "it's npm's fault", "it's the fault of small dependencies", and "it's the fault of the guy who removed his package"
<joepie91> only the first one is partly true and one's own practices and deployment infrastructure have gone curiously uncriticized
<joepie91> and it's especially that last one that I take serious issue with
<adisbladis> I think that last one is pretty funny :P
<joepie91> it is not some random package author's responsibility to compensate for your shitty CI infrastructure
<joepie91> I don't think it's funny at all, the guy got a lot of shit
<adisbladis> joepie91: I mean that it's funny that he did it
<joepie91> wouldn't classify that as funny either, it was very much an "I'll take my toys and go home then" scenario, he was leaving npm over shitty handling of a trademark claim
<joepie91> (by which I mean that npm just took one of this packages and gave it to a company who complained frivolously)
<joepie91> one of his*
<adisbladis> joepie91: In this regard I really think Go is doing the right thing.
<monsieurp> joepie91: that company threatened him legally after he refused to gave up his npm namespace
<adisbladis> No central registry, but with a central authority that caches the ecosystem
<monsieurp> *give up
<JJJollyjim> otoh go packages break if you change your username right?
<adisbladis> I think what the whole left-pad debacle shows is really how broken centralisation is
<monsieurp> ... when managed by a private organisation
<adisbladis> JJJollyjim: Yes, that's an unfortunate side effect of decentralisation
<adisbladis> Something something package names on the blockchain
<adisbladis> ^ Not serious
<gchristensen> gotta put functions on the blockchain, and then packages of functions on the blockchain. not just names
<JJJollyjim> yeah idk
<gchristensen> you can't unpublish e0c80459-9c47-4c0c-810a-6d127c79eb90 from the blockchain
<JJJollyjim> like, speaking as a trans person, if i have to choose between breaking everyone using my library and everyone looking at my deadname, the obvious choice is just to quit programming forever
<JJJollyjim> :P
<adisbladis> gchristensen: You're joking but that's a thing
<gchristensen> I know :P
<gchristensen> unison?
<adisbladis> gchristensen: Tbf though deploying contracts costs a lot of gas
<gchristensen> yeah
<adisbladis> Having shared library code brings down the new contract code by like.. A lot.
<joepie91> adisbladis: also, apologies if I come across a bit grumpy, I'm pretty worn out from years and years of anti-dependency culting resulting from the leftpad incident, and the degree to which people are comfortable deriving conclusions from it without even understanding what happened
<gchristensen> I actually like go's model of vendoring sometimes
<adisbladis> joepie91: I always appreciate your grump <3
<adisbladis> Is grump a word? It should be.
<gchristensen> oh yeah
<joepie91> this is why I asked "what incident are you referring to" earlier, because 99% of the time it's leftpad
<adisbladis> Insightful grump
<gchristensen> last night my city counselor blew me up on twitter and told me to do my own research about how she isn't in conflict of interest. so I did my own research, and I can only find ways in which she is violating the law by holding two positions :')
<JJJollyjim> gas in ethereum seems like a good metaphor because it involves literally burning massive amounts of fossil fuels
<JJJollyjim> :P
<adisbladis> JJJollyjim: Depends on your consensus model, but yeah =)
<JJJollyjim> Hmm?
<JJJollyjim> Have they implemented an alternative?
<JJJollyjim> (sorry I don't really follow this stuff at all)
<JJJollyjim> (for the past several years at least)
<__monty__> They wanted to switch to PoS, not sure if they ever did.
<monsieurp> gchristensen: is it allowed? where do you live already?
<adisbladis> The mainnet is still running on PoW (of course)
<adisbladis> But I've been running private chains on PoA
<gchristensen> monsieurp: berkshires, massachusetts
parsley936 has joined #nixos-chat
<monsieurp> ah
<adisbladis> JJJollyjim: An interesting side effect of PoA is that 0 block time is actually viable
<joepie91> adisbladis: aside, I don't think that what Go does is meaningfully different from what npm does; it just outsources the namespace management to DNS. ultimately it comes down to "a central registry, but with a low-availability second source URL, and no semver+immutability"
<joepie91> (some of the bits and pieces are flipped around but ultimately you still end up with the central cache as a crucial piece of infrastructure, without which your availability drops like a brick)
<joepie91> anyway, likewise, I don't actually think it's much more decentralized at all for that reason, the namespace is still controlled by a central authority
<joepie91> root namespace*
<monsieurp> gchristensen: I read in another of your tweets that you use ZFS on Linux as your main FS
<monsieurp> gchristensen: is it stable?
<gchristensen> yeah
<gchristensen> works great :)
<monsieurp> I wish there were an installer as simple as the FreeBSD installer to set up a Linux distro with ZFS
<etu> monsieurp: Ubuntu?
<etu> It's super simple and super unflexible
<gchristensen> how does freebsd's installer work?
<JJJollyjim> ^
<adisbladis> The only bit I find annoying with ZFS is that it's not always compatible with the latest kernels
<gchristensen> thanks, monsieurp, I'll give it a watch in 20min
<adisbladis> So sometimes I have to stay one or two kernel versions behind
<gchristensen> adisbladis: yeah that is a bit annoying. I haven't run in to that in a long time.... but yeah
<adisbladis> gchristensen: I ran into it on 5.6
<adisbladis> You notice this stuff fast when you're on nixpkgs master
<gchristensen> guh right lol
<adisbladis> Admittedly it is a problem somewhat of my own making
<eyJhb> Did you really end up with functions on the blockchain?
<adisbladis> eyJhb: What do you think smart contracts are?
<eyJhb> Money.
<adisbladis> They're just a piece of code running on a distributed computer
<__monty__> Even bitcoin transactions are scripts.
<eyJhb> ^ answer to everything!
<joepie91> adisbladis: neither smart nor contracts :P
<__monty__> adisbladis: What do you run private chains for?
<eyJhb> Don't write so fast adisbladis and __monty__ ...
<adisbladis> joepie91: You're not wrong :)
<adisbladis> __monty__: Inter-organisational trust
<adisbladis> Consortiums basically
<adisbladis> Enterprise AF
<joepie91> adisbladis: might I suggest a look at https://github.com/paragonie/chronicle (and similar systems, I think Google did a thing like this at some point also)
<__monty__> What sort of stuff do they put on the blockchain? Business contracts? API contracts?
<eyJhb> I should really find something better than BlackFriday for Markdown...
<joepie91> adisbladis: it's extremely likely that that model will solve your inter-organisational trust requirements without all the complexity and fragility of blockchains
<adisbladis> __monty__: We (my previous job) were doing _basically_ blockchain-based PKI
<joepie91> I can't for the life of me recall the name of the Google thing, do we have a resident internal-Google-project-knower?
<adisbladis> joepie91: Trillian
<joepie91> hmm, I'm not sure it was Trillian
<__monty__> joepie91: I don't think a PoA blockchain is all that complex/fragile.
<joepie91> seems to sit at a different abstraction level than what I'm thinking of
<__monty__> It's basically a simple merkle-tree with authorized parties signing off on it.
<joepie91> that doesn't sound like a blockchain to me then :)
<__monty__> Well, many people think blockchain implies bitcoin PoW but it doesn't have to.
<joepie91> no, that's not what I'm arguing
<joepie91> but to be honest I don't have much energy for this discussion today :P
<Valodim> has someone made a blockchain yet that bases its trust model on Prisoners of War?
<eyJhb> `Prisoners of War is an Israeli television drama series made by Keshet and originally aired on Israel's Channel 2 from March to May 2010. A second season aired ...`?
<joepie91> did everyone catch the GnuTLS vuln...?
<joepie91> it's uh, bad
<eyJhb> Well depends if you are the NSA, then it is good
<eyJhb> But nice they have a null and void feature in GnuTLS
<ldlework> I have a nice little system for nixt, with a Nimlang CLI calling out to nix-instantiate and getting back json which I unmarshall into types and then display nice unicode output for
<Valodim> eyJhb: (it was a play on the more common usage of the "PoW" acronym)
<Valodim> man that gnutls issue looks pretty bad
<Valodim> interesting that the recommendation shifted back to openssl
<Valodim> jtojnar: I appreciate your writeup of common cmake issues (at https://github.com/jtojnar/cmake-snips#please-fix-your-cmake-builds)
<__monty__> I don't think it ever seriously shifted away from OpenSSL tbh.
<Valodim> jtojnar: I made a suggestion for a revised wording that sounds.. less annoyed at cmake and its users ;) feel free to merge or close and disregard https://github.com/jtojnar/cmake-snips/pull/1
<{^_^}> jtojnar/cmake-snips#1 (by Valodim, 1 minute ago, open): make wording more friendly
<joepie91> __monty__: https://twitter.com/jedisct1/status/1270078914996682753 suggests otherwise
<__monty__> Seems to only list homebrew as a repo that changed to GnuTLS? Since Debian's choice was based on the license?
<pie_> apparentlyopenssl has improved or something
<gchristensen> what makes you say that? :P
luc65r has joined #nixos-chat
<__monty__> joepie91: How do you deal with version constraints on such small dependencies? Just use the latest version at time of writing and freeze files? No constraints whatsoever? Tools so you can say "constrain everything to semver component x.y?"
<joepie91> __monty__: semver range that permits all API-compatible versions
<joepie91> (ie. how this is done in JS and Rust)
<__monty__> Do you add these manually for every dependency?
<joepie91> an important thing to keep in mind is that when all modules have precisely one purpose and a well-defined scope, breaking changes are rare (there is not much to break) and breaking changes that actually matter are even rarer
<joepie91> __monty__: package manager does that, at least in JS
<joepie91> when you `npm install foo` or `yarn add foo`, it will automatically look up the most recent version, and add `^version` to your package.json, where 'version' is that version
<__monty__> And that means API-compatible constrained below by "version"?
<joepie91> righ
<joepie91> right*
<joepie91> (you can use a lockfile on an application level to lock in specific versions on install, throughout all levels of the dependency tree, until you explicitly upgrade them; this can be useful when you review/audit all of your dependencies, but otherwise it is probably better to leave it out)
<__monty__> Ok, thanks.
<gchristensen> pavucontrol should have a "make this stream mono" button
<pie_> gchristensen: im only basing off that people i deem as likely competent have said
<gchristensen> gotcha
<ar> oh, nvm, someone linked the gnutls thing here already
Valodim has quit [Ping timeout: 256 seconds]
Valodim has joined #nixos-chat
<ldlework> It's really annoying that I can't import a file safely
<infinisil> ldlework: What do you mean?
<gchristensen> that is annoying
<ldlework> I'm writing a test runner. From my main nix routine, I can't iterate over all candidate files and import them to see if they are functions.
<ldlework> Because if even a single one of them has a syntax error, the whole things explodes.
<ldlework> I can't just record that that file failed to import, or ignore it or anything..
<eyJhb> lovesegfault: a little something for you - https://i.imgur.com/idkeYm2.png
<infinisil> ldlework: Just import Nix files?
<infinisil> I'm probably missing something
<infinisil> Oh
<infinisil> Wait no, still missing something, why would Nix files have syntax errors?
<ldlework> .....
<ldlework> I have no idea how to answer that lol
<ldlework> Do you have some kind of secret AST-based Nixlang editor?
<infinisil> Well no, but wouldn't people just fix their files if they try to use them and notice a syntax error?
<ldlework> I can't do any kind of reporting or anything, it just blows up with no way to handle it
<ldlework> so all they get to see is the first error
<ldlework> it would be nice to be able to run over all the files and then display the status of each
<ldlework> to treat syntax errors just like failed test-cases
<ldlework> but can't, it just blows up with stack trace
<infinisil> ldlework: Can I get some more context
<infinisil> I only know it's something about test discovery, but I still have no idea why this would involve invalid Nix files
<ldlework> I'm writing a Nixlang unit-test runner
<ldlework> I just don't know what the confusion is
<ldlework> If someone has some code
<ldlework> has some tests
<ldlework> the code or tests have any sort of syntax error
<ldlework> they run the test runner
<ldlework> it can't do anything helpful but explode with a stacktrace
<infinisil> Doesn't this work similarly in all other languages?
<ldlework> Er no most languages have some kind of error handling
<infinisil> If you write your tests in C but forgot a ";", it can recover from that?
<infinisil> Oh, I guess you mean an evaluation error
<infinisil> Not a syntax error
<infinisil> Right?
<ldlework> no a syntax error
<ldlework> and C is a pretty primitive language
<gchristensen> python can of course, but
<infinisil> I guess at least all compiled languages will throw a single syntax error if you have one in your tests
<ldlework> Yeah a single error per file is fine
<ldlework> The problem is the test runner itself cannot recorver
<ldlework> lol
<gchristensen> maybe a two-stage test runner, first a stage to gather viable test files and a second stage to run the tests
<ldlework> that's what I'm doing
<gchristensen> cool
<ldlework> it's just really annoying because it's a lot of json communciation between nim and nix-instantiate
<ldlework> Also
<ldlework> I can't have a first stage runner that just tries to find candidate files
<infinisil> ldlework: So I guess what you'd want is a builtins.tryEval that catches all errors and emits their message
<ldlework> Because to be a candidate file, you must be a function with the right args, etc
<ldlework> So really
<ldlework> The first stage has to call out to nix-instantiate for every file
<ldlework> in a separate process
<ldlework> because if the discovery was in nix, the first file that failed to import would blow it up
<ldlework> so i have to move discovery to nim
<ldlework> infinisil: even the first message, yeah
<infinisil> I guess that would make tryEval impure though
<infinisil> It might already be though
<infinisil> Actually no, I think currently tryEval is pure
<infinisil> And emitting the error message within Nix itself would make it impure
<__monty__> infinisil: Would it? Presumably the same code would always lead to the same error message?
<infinisil> __monty__: Not if the same code is in different files
<__monty__> Then it's not the same code though?
<infinisil> The filename isn't part of the expression
<ldlework> haha "not if the same code is in different files" that made me do that "math floating around face" meme
<__monty__> You're talking about the scenario where a syntactically identical expression implicitly depends on different expressions by name, right?
<infinisil> Have two files a.nix and b.nix, both with contents `1 + ""`. Then have a default.nix with contents `let a = import ./a.nix; b = import ./b.nix; in (builtins.tryEval a).error`
<infinisil> That would evaluate to `error: cannot add a string to an integer, at a.nix:1:1`
<infinisil> While the same with b would give it with b.nix
<__monty__> infinisil: Ah, but you can't say a == b, so purity isn't violated anyway : )
<infinisil> Hmm, that's a good point
<__monty__> I'm actually thinking maybe it doesn't really make sense to talk about purity in the face of syntax errors. Language properties only apply to valid code.
<ldlework> Yeah but is the caller valid?
<__monty__> I'm not sure. The lack of a static type system makes this a lot harder. Normally any program that doesn't pass the type checker isn't valid.
waleee-cl has joined #nixos-chat
luc65r has quit [Ping timeout: 272 seconds]
luc65r has joined #nixos-chat
drakonis has joined #nixos-chat
drakonis2 has quit [Ping timeout: 246 seconds]
drakonis_ has joined #nixos-chat
drakonis1 has joined #nixos-chat
drakonis has quit [Ping timeout: 256 seconds]
drakonis_ has quit [Ping timeout: 258 seconds]
drakonis has joined #nixos-chat
drakonis1 has quit [Ping timeout: 256 seconds]
<lovesegfault> Eh, does anyone know what the wifi (wpa_supplicant) service on NixOS is called?
drakonis1 has joined #nixos-chat
<infinisil> lovesegfault: wpa_supplicant?
<infinisil> Oh but the nixos options are under networking.wireless
<infinisil> Or networking.supplicant for interface-specific settings apparently
<lovesegfault> infinisil: I found it as supplicant-wlan0.service
<risson> gchristensen: how would you go about impersistence for a host and its virtual machines? The host with impersistence on zfs, and then each vm on a qcow2 or a zvol?
<risson> Each vm would then have another zfs on the of the host's, isn't that too much overhead?
<risson> Or would you go with a zvol for each persistent volume of the vm and / as a tmpfs
cole-h has joined #nixos-chat
<drakonis1> aight people
<ar> i wonder if they'll also try enforcing notarizing for all software at the same time
<drakonis1> i mean, this is apple, why wouldnt they
<cransom> they switched archs once, they can do it again.
<drakonis1> they had powerpc back then
<ashkitten> im really annoyed at planet rn
<ashkitten> samueldr: they haven't replied to my email yet, btw, but they told another backer on indiegogo that they haven't yet locked all "other" keyboard layout perks
<ashkitten> which is *not what they said in their update*
<samueldr> oof
<ashkitten> they said they were locking *all* remaining perks last week, and now they're saying actually it's everyone except you
<ashkitten> (not just me, but yk)
<ashkitten> so maybe they'll finally lock my contribution this week, or were they talking about actually next week?
<samueldr> in 3 week's time they'll post an update explaining how they solved the issue with "other" keyboard
<ashkitten> yeah
<ashkitten> and they'll ship it out and i'll already have moved
<ashkitten> this is honestly such an unacceptably bad level of communication
<ashkitten> delays happen, i get that, but this is just making people angry that you told them the wrong thing
hax404 has quit [Quit: WeeChat 2.7.1]
hax404 has joined #nixos-chat
<pistache> risson: I'm doing ZFS over ZFS, and I'm not really happy with the performance
<lovesegfault> pistache: What's zfs over zfs?
<pistache> but I may just have set it up incorrectly (although I did spend quite a bit time fiddling with recordsizes and all)
<pistache> lovesegfault: ZFS in a VM backed by a file on a ZFS dataset (as I've had even worse performance with zvols)
<lovesegfault> Oh, interesting
<lovesegfault> Yeah, I can't imagine that has good perf
<lovesegfault> it's a shame because zvols are promising for this, but zvols are riddled with issues
<lovesegfault> c.f.
<lovesegfault> *c.f. swap on zvol
<pistache> yes I gave up on zvols, I just use raw files
<lovesegfault> ping etu and/or talyz
<pistache> but I don't understand why has the performance got to be so bad
<pistache> ah they're doing that kind of stuff ?
<lovesegfault> No, unrelated ping :P
<lovesegfault> I do run ZFS though
<lovesegfault> But no ZFS-on-ZFS
<lovesegfault> and I use a swap partition outside of zfs altogether
<pistache> it's a shame because if you want FDE it gets complex quickly if you have swap outside of zfs
<lovesegfault> Yes
<pistache> on the other hand, the pool-level features are much nicer on ZFS than handling MDADM+LUKS+LVM+EXT4
<lovesegfault> Yes
<lovesegfault> that whole mess
<pistache> *fear*
<lovesegfault> I regret creating a swap partition
<lovesegfault> I want to delete it, expand my zpool, and then configure a swap file
<lovesegfault> I have vm.swappiness=1 anyway
<pistache> vm.swappiness=1 is just to avoid OOM right ?
<pistache> as in, it only swaps when memory pressure gets very very high
<gchristensen> lovesegfault: I'm pretty sure you can do that
<pistache> ah no what I implied is swappiness=0
<risson> The only time I used a swap partition on a zfs zvol I deadlocked 4 minutes later x)
<risson> I'll probably go with ext4 over a zvol then
<ashkitten> swap on zfs is not supported
<ashkitten> worst case it can corrupt your pool
<risson> Acutally it is, just not recommended
<ashkitten> "you can technically do this" and "this is supported" are different things
<{^_^}> openzfs/zfs#7734 (by runderwo, 1 year ago, open): Swap deadlock in 0.7.9
<risson> Well, you can use a zvol as a swap partition, but it might deadlock
<risson> Swap files aren't supported though
<ashkitten> that doesn't sound supported to me
<risson> Oh yeah, I see what you mean x)
<risson> Indeed, it isn't
<__monty__> In btrfs terminology I was expecting the answer to be 1 subvolume snapshot per VM type + 1 subvolume per VM for persistent data.
<risson> So you would mount the nix store readonly?
<__monty__> Depends on whether you mind having a store per snapshot I'd say.
<energizer> it created /tmp/loki/{chunks,index} and /var/lib/loki but it's not writing anything into them
<cransom> all this talk of memory made me go look at something. fail2ban... why are you using 400megs of ram.
<energizer> is that expected?
<gchristensen> seeing as it is barely a security tool I'm surprised any time it uses anything more than "barely any"
* energizer doesn't see the purpose of fail2ban
<pistache> well it's useful to get DoS'ed
<joepie91> fail2ban--
<joepie91> useless security theater
<pistache> how else would you allow random people to fill up your firewall rules ?
<energizer> gchristensen: i dont suppose your loki config is public?
<cransom> i don't enjoy the bots crawling through and poking my ssh for vulnerabilities that haven't been announced yet.
<energizer> what about poking your fail2ban for vulnerabilities that haven't been announced yet?
<joepie91> cransom: the problem is that fail2ban is incredibly unlikely to actually prevent that
<gchristensen> energizer: the configs are in here: https://github.com/ofborg/infrastructure likely in commits from the last 6mo
<lovesegfault> ashkitten: Wait, swapfiles don't work either?
<joepie91> vulnerability probing generally does not take the shape of a bruteforcing attempt
<gchristensen> ahcool
<joepie91> exploitation might take that shape, but by that point you are already on the 'worthy target' list and an attacker is gonna be using a pool of proxies, which fail2ban will also not deal with
<gchristensen> I kind of want to write an LSM (https://www.kernel.org/doc/html/latest/security/lsm.html?highlight=lsm)
<ashkitten> i don't use fail2ban because i don't have ssh password auth enabled so it's like, what are you even gonna do? bruteforce my ed25519 key?
<cransom> i agree that if someone wants in, and they want to not be found, they can do it. but for the random hosts probing, i'd rather have iptables logs than sshd filled with failed root logins'
<ashkitten> cransom: that's an aesthetic choice, not a security one
<pistache> BSD has blacklistd which is quite nice, as all the filtering work is done by the JIT'd BPF
<pistache> but even then, it's more of a good way to shoot yourself in the foot and allow attackers to deny any access to your infrastructure
<ashkitten> i imagine if there's any isps out there that allow source ip spoofing, yeah
<pistache> well... https://isbgpsafeyet.com/
<ashkitten> lol
<eyJhb> fail2ban is useful, do not just isolate it to SSH, etc... Servers with lots of different services, where not all are well written etc.
<eyJhb> But yes, there are many times when it is useless
<adisbladis> I see fail2ban as a spamfilter for logs
<adisbladis> It doesn't really do anything useful except the bots give up quicker
<cransom> i'd contemplate a move to ipv6 only if i didn't have things that required v4 at home.
<ashkitten> wonder if anyone is gonna reverse engineer the cosmo cover display firmware
<ashkitten> ah
<ashkitten> well, there's one thing by one person
<samueldr> sams person who found the security issues
<ashkitten> oh that's ninji
<samueldr> that's _Ninji on twitter
<samueldr> yeah
<ashkitten> i didn't recognize the alt username
<lovesegfault> gchristensen, adisbladis: Do y'all have clarity on what's a priority in NixOps development? I'm wondering how likely some features are to land. Namely #1264, #1283, #1353, and #1331
<{^_^}> https://github.com/NixOS/nixpkgs/pull/1264 (by urv, 6 years ago, merged): autofs: upgrade 5.0.5 -> 5.0.8
<{^_^}> https://github.com/NixOS/nixpkgs/pull/1283 (by ocharles, 6 years ago, merged): haskellPackages.indexedFree: New expression
<{^_^}> https://github.com/NixOS/nixpkgs/pull/1353 (by ocharles, 6 years ago, closed): haskellPackages.tasty*: Update to tasty 0.5
<{^_^}> https://github.com/NixOS/nixpkgs/pull/1331 (by urv, 6 years ago, merged): fix: syntax error in networking/mumble
<lovesegfault> Bad bot
<lovesegfault> {^_^}: --
<lovesegfault> {^_^}--
<ashkitten> :<
endformationage has joined #nixos-chat
<talyz> lovesegfault: pong!
<infinisil> lovesegfault: nixops#<number> to have nixops PRs be linked instead
<adisbladis> lovesegfault: All of them will be in 2.0 I think
<adisbladis> nixops#1283 is ready to go
<{^_^}> https://github.com/NixOS/nixops/pull/1283 (by adisbladis, 7 weeks ago, open): Add SSH jump host support
<adisbladis> nixops#1264 requires a bit more work
<{^_^}> https://github.com/NixOS/nixops/pull/1264 (by grahamc, 10 weeks ago, open): Example NixOps State Backends
<adisbladis> I'm reconsidering if nixops#1353 is exactly the right approach
<{^_^}> https://github.com/NixOS/nixops/pull/1353 (by adisbladis, 2 weeks ago, open): Add support for pluggable transports
<adisbladis> I'd love more input on that one
<adisbladis> That last one is interesting, I really need to validate it.
<pistache> I'll try to add some comments tomorrow on that one
<pistache> but well I may not be best person to make actually interesting and contributing comments..
<infinisil> nixops#1331
<{^_^}> https://github.com/NixOS/nixops/pull/1331 (by dhess, 5 weeks ago, open): eval-machine-info.nix: add nixpkgsPath argument.
<lovesegfault> talyz: o/
<lovesegfault> Do you want me to rebase that perms thing onto master?
<lovesegfault> adisbladis: I can't give feedback on approach, but I can give feedback on _need_; I run an ssh server on my laptop just to deploy from it to it
<lovesegfault> I'd love to not have to do that
<lovesegfault> (PSA I don't use nixops)
<gchristensen> from my perspective, that is squarely in a "wouldb
<lovesegfault> what's a wouldb
<gchristensen> from my perspective, that is squarely in a "would-be-cool" zone of features, since nixops isn't *really* for deploying to the deploy host and therefor "gotta have SSH, sorry" isn't an unreasonable answer
<lovesegfault> Oh, I agree
<lovesegfault> (that it's no way a must-have)
<infinisil> lovesegfault: I actually just had a problem regarding that
<lovesegfault> infinisil: deploying to self?
<infinisil> I deploy from my deploy host to itself with nixus, and even though the internet connection broke, it couldn't detect any problem, since I could still ssh to itself
<infinisil> the last s/I/it
<lovesegfault> I've had the same :D
<lovesegfault> When I switched to systemd-networkd
<infinisil> Yeah, so ideally there would always be two hosts
<lovesegfault> Chain deployment!
<infinisil> Maybe instead of deploying to itself, make another host do the deployment to the original deploy machine
<lovesegfault> A deploys to B, if B is successful it then deploys to A
<infinisil> Hehe yes
* infinisil thinks about how that would work in nixus
<infinisil> I guess it's really just inverting roles, with some good abstractions this might be pretty simple
<gchristensen> hot diggity! the -L corruption bug isclosed
<lovesegfault> Which one?
* lovesegfault waves a Rust flag at infinisil
<gchristensen> inverting roles but with access control issues
<infinisil> lovesegfault: I think it's gonna be Haskell after all!
<gchristensen> I don't usually like my deploy targets to be able to pwn my deploy host
<lovesegfault> Noooooo :P
<infinisil> gchristensen: It wouldn't really be a full deployment. In nixus case it would just be that it uses the connection between them to verify networking still works
<infinisil> So instead of the deploy host doing (simplified) `ping <other host>` it would be the other host pinging the deploy host
<lovesegfault> infinisil: I guess nixus could _also_ use well-known IPs for testing
<lovesegfault> by pinging,,
<infinisil> Hm yeah, though I really like that it's based on ssh, because that's what's really needed to not lose the server
<infinisil> Hm, although that's a problem if the deploy host doesn't have a public ip
<gchristensen> wireguard!
<infinisil> Ah yes, it could use any form of non-public-ip-based routing instead
<infinisil> I guess a simple reverse ssh forward would be enough in this case
luc65r has quit [Quit: Quit]
<__monty__> If you end up using or, please don't hardcode them. Not everyone's happy pinging google infra.
<infinisil> __monty__: Oh yeah definitely
<__monty__> Afair systemd-nspawn did something like this.
<infinisil> They hardcoded ips to be pinged?
<samueldr> are those well-known ip addresses providing a ping service?
<samueldr> while they may right now ping successfully, if it's not part of the service it could fail
<adisbladis> gchristensen: I have other plans for that feature ;)
<infinisil> samueldr: I'd expect this to be implicitly part of the service
<samueldr> (yes, it would be a bit of a jerk move if e.g. google.com or stopped responding to ping, but it could happen)
<infinisil> samueldr: I imagine a ton of things breaking if well-known services stopped giving pings
<infinisil> Or pongs rather
<lovesegfault> Imagine how much stuff would break
<samueldr> that would be fun
<cransom> relying on random public ips is so dirty.
<lovesegfault> Yes, picking IPs at random would suck
<samueldr> arbitrary?
<energizer> what is the reason to involve when you're only trying to contact certain specific hosts?
<cransom> arbitrary, yes.
<immae> I think mozilla officially offers one (which they use in their browser)
<infinisil> energizer: I guess ideally the user would specify the ips/sites they care about
<infinisil> E.g. to verify internet connectivity from my normal machine I want you to ping reddit.com, youtube.com and github.com
<infinisil> If all three of them fail, no internet
<energizer> i see, that makes sense
<infinisil> If two of them fail, cloudflare is probably down :P
<infinisil> If one of them fails, that site is down
<energizer> ping isn't really the right protocol then, curl would be better
<infinisil> curl could be problematic with user agents and such
<infinisil> And these sites probably have some policy against web-scraping-like behavior
<infinisil> ping however is kind of intended to be used by tools
<gchristensen> icanhazip.com is pretty friendly to this sort of thing
<infinisil> Nice
<energizer> is impermanence ready for use?
<lovesegfault> My arch-enemy is the UPS driver that drives to the street before mine, then parks there for _hours_ before delivering me my package
<gchristensen> wtf printers are so bad
<lovesegfault> Printers are performance art
jared-w has quit [Read error: Connection reset by peer]
jared-w has joined #nixos-chat
__monty__ has quit [Quit: leaving]
<ldlework> finishing software is so hard
<ldlework> I have an OK system for calling Nix from Nim now though.
<lovesegfault> Tempted to turn mitigations off in my laptop
<energizer> do you use the web on your laptop?
<samueldr> lovesegfault: I would, first, find a representative benchmark of what you hope this will help with, run it, and then compare
<samueldr> AFTER that, I would start considering
<samueldr> and also important, looking into if your browser has their own mitigations
<samueldr> but I guess if you do anything remotely sensitive, it's most likely not a good idea to turn them off
<samueldr> in any cases, if you do, do it in full knowledge of where it affects you
<lovesegfault> samueldr: They do impact compilation times quite a bit
<samueldr> according to your experience or according to data gathered from elsewhere?
<samueldr> that's why I'm saying: benchmark representative of what you want to achieve
<samueldr> it may very well affecting your workload!
<talyz> lovesegfault: if you want to continue on the users suboption feature, then sure!
<talyz> lovesegfault: or was it useful without that too?
<gchristensen> arianvp is talking about using his bank's API to file his taxes and here I am dealing with printed out statements
<ldlework> OK I got test discovery in Nixt to be independent for each file checked.
<ldlework> So now you can have syntax errors and stuff, and the whole thing doesn't blow up.
<infinisil> Awesomely catchy track: https://www.youtube.com/watch?v=E-4Nk466iIo
<lovesegfault> talyz: it's useful without that too, it's useful if you want to have bind-mounted things with right permissions, regardless of the owner
<ldlework> I just realized I'll actually have to run each case in a separate process, not just each test suite
<ldlework> since any case can cause nix to blow up