<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
<{^_^}>
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>
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
<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
<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>
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 ...`?
<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
<__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
<__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>
(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
<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
<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
<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
<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
<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
<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 1.1.1.1, 8.8.8.8, 9.9.9.9
<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 1.1.1.1 or 8.8.8.8, 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 8.8.8.8 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 1.1.1.1 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
<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