Jason_Grossman has quit [Ping timeout: 240 seconds]
<ldlework>
infinisil: yay I've finished converting over my system configuration to options style
<infinisil>
Nice
<samueldr>
FINALLY
<samueldr>
I was definitely in the deep end right there (for me)
<samueldr>
but refactored something important for cross-compiling
matthewbauer has joined #nixos-chat
matthewbauer has quit [Read error: Connection reset by peer]
matthewbauer has joined #nixos-chat
matthewbauer has quit [Read error: Connection reset by peer]
matthewbauer has joined #nixos-chat
matthewbauer has quit [Ping timeout: 240 seconds]
matthewbauer has joined #nixos-chat
matthewbauer has quit [Ping timeout: 240 seconds]
matthewbauer has joined #nixos-chat
matthewbauer has quit [Read error: Connection reset by peer]
matthewbauer has joined #nixos-chat
matthewbauer has quit [Read error: Connection reset by peer]
aither has quit [Ping timeout: 256 seconds]
matthewbauer has joined #nixos-chat
snajpa has quit [Ping timeout: 265 seconds]
srk has quit [Ping timeout: 265 seconds]
snajpa has joined #nixos-chat
<ldlework>
infinisil: if you're around can you remind me how to use the znc module from your nixpkgs fork? not like how to setup the config, just how do I /use/ your fork in the first place
matthewbauer has quit [Read error: Connection reset by peer]
aither has joined #nixos-chat
matthewbauer has joined #nixos-chat
srk has joined #nixos-chat
dmc has quit [Quit: WeeChat 2.1]
matthewbauer has quit [Ping timeout: 268 seconds]
dmc has joined #nixos-chat
lassulus_ has joined #nixos-chat
lassulus has quit [Ping timeout: 256 seconds]
lassulus_ is now known as lassulus
<jcrben>
idlework: what's options style, out of curiosity?
Lisanna has quit [Remote host closed the connection]
Guanin has quit [Ping timeout: 245 seconds]
obadz- has joined #nixos-chat
obadz has quit [Ping timeout: 260 seconds]
obadz- is now known as obadz
Guanin has joined #nixos-chat
jD91mZM2 has joined #nixos-chat
obadz- has joined #nixos-chat
obadz has quit [Ping timeout: 240 seconds]
obadz- is now known as obadz
tilpner has quit [Ping timeout: 265 seconds]
tilpner has joined #nixos-chat
obadz- has joined #nixos-chat
obadz has quit [Ping timeout: 240 seconds]
obadz- is now known as obadz
Jason_Grossman has joined #nixos-chat
tilpner has quit [Remote host closed the connection]
__monty__ has joined #nixos-chat
tilpner has joined #nixos-chat
ma27 has quit [Ping timeout: 256 seconds]
ma27 has joined #nixos-chat
<infinisil>
ldlework: I'd recommend to switch to a git checkout, then it's as easy as adding my repo as a remote, fetching it and cherry-picking the commit
obadz- has joined #nixos-chat
obadz has quit [Ping timeout: 260 seconds]
obadz- is now known as obadz
Jason_Grossman has quit [Ping timeout: 240 seconds]
Jason_Grossman has joined #nixos-chat
makefu has quit [Ping timeout: 248 seconds]
makefu has joined #nixos-chat
Jason_Grossman has quit [Ping timeout: 268 seconds]
Jason_Grossman has joined #nixos-chat
Jason_Grossman has quit [Ping timeout: 245 seconds]
Jason_Grossman has joined #nixos-chat
__monty__ has quit [Quit: leaving]
Jason_Gr` has joined #nixos-chat
Jason_Grossman has quit [Ping timeout: 248 seconds]
Jason_Grossman has joined #nixos-chat
Jason_Gr` has quit [Ping timeout: 240 seconds]
Jason_Gr` has joined #nixos-chat
obadz- has joined #nixos-chat
Jason_Grossman has quit [Ping timeout: 268 seconds]
obadz has quit [Ping timeout: 255 seconds]
obadz- is now known as obadz
obadz- has joined #nixos-chat
obadz has quit [Ping timeout: 240 seconds]
obadz- is now known as obadz
jtojnar has quit [Remote host closed the connection]
jD91mZM2 has quit [Quit: WeeChat 2.0]
Sonarpulse has joined #nixos-chat
ma27 has quit [Quit: WeeChat 2.0]
ma27 has joined #nixos-chat
<ldlework>
infinisil: I looked over your "deployer" thing and got super confused
<ldlework>
Are you deploying all your servers everytime you rebuild your nixos config?
<infinisil>
ldlework: It's a wrapper around nixops really
<infinisil>
So if I just want to rebuild one machine I can use `rb --include <name>`
<infinisil>
All arguments get passed through to nixops
Guanin has quit [Remote host closed the connection]
matthewbauer has joined #nixos-chat
<joepie91>
so, I have an article about the costs of decentralization in the pipeline, talking about different forms of decentralization, the complexities and costs they introduce, why decentralized alternatives almost always fail, and so on
<joepie91>
if anybody has a question or topic around that that they want to see addressed, this is your chance
<joepie91>
:P
matthewbauer has quit [Read error: Connection reset by peer]
matthewbauer has joined #nixos-chat
<infinisil>
joepie91: Hmm.. Maybe why certain ones succeeded nonetheless? E.g. DNS, E-Mail, IP, IRC
<ldlework>
infinisil: what's in your private repo?
<infinisil>
ldlework: Not telling :P
<ldlework>
-_-' lol
<infinisil>
Passwords, nixops state, openvpn keys, stuff like that
<infinisil>
Mostly in modules
<joepie91>
infinisil: right, I'll be addressing those
<joepie91>
(incidentally, IRC is technically not *really* decentralized)
<joepie91>
(each IRC network is its own single-point-of-trust system, they just happen to use similar protocols)
<ldlework>
a given network is usually made from a number of servers though
<joepie91>
yes, but they are all operated by the same consortium of operators
<ldlework>
Yes but there is no "main" server.
<joepie91>
unlike in a federated system, where each system is independently controlled and can operate without explicit authorization of other providers
<joepie91>
ldlework: that just makes it distributed, not decentralized :)
<joepie91>
I guess I should address the difference between 'distributed' and 'decentralized' as well
<ldlework>
I'm not an expert, but IRC servers authorize other servers to bind with them, but there isn't a single party who controls authorization of each server.
<joepie91>
namely, 'distributed' being an architectural property of spreading the system across multiple physical/logical systems, and 'decentralized' being a matter of not having centralized *control* or authority
<ldlework>
That is, a single party who controls authorization of every* server.
<ldlework>
Of course, no freenode server operator will agree to authorize servers that the other freenode server operators approve of.
<joepie91>
ldlework: technically some variants of the IRC protocol can operate in a federated manner, yes, but in practice this isn't really done and iirc the routing was never really figured out
<ldlework>
So in that sense it is centralized around the consensus of all the freenode operators.
<ldlework>
joepie91: I'm fairly certain that is how it works.
<joepie91>
IRC networks pretty much universally use a hub-and-spoke model of some variety
<joepie91>
at least from an authorization perspective
<ldlework>
The only sense in which IRC is not decentralized is the practical organization of the freenode organization and their policies for inclusion of new servers.
<joepie91>
(I'm not just talking about Freenode here)
<ldlework>
Sure!
<ldlework>
My point is, from a technical perspective, IRC is federated afaict
<samueldr>
depends on the implementation and the politics
<joepie91>
ldlework: part of the problem here is that there is not really such a thing as 'IRC'; it's not one protocol, rather a large family of rather broadly deviating lookalike protocols
<samueldr>
while there is IIRC a "server protocol", not all servers are linked using it
<samueldr>
the server protocol *can* be used in a more federated manner
<joepie91>
this is why I'm going with "how are run things in practice", because that's always been what has defined IRC
<joepie91>
even the RFC is literally "let's try to document what people are doing in practice"
<ldlework>
Yeah, I mean most modern IRCds support federation, but not all organizations operating networks, as a matter of policy.
<joepie91>
well, RFCs*
<ldlework>
I agree I can't think of any networks that have an open federation practice, just that the IRCd's work that way.
<joepie91>
most IRCds are pretty much unable to deal with federation though, from what I know :P
<samueldr>
I would hazard a guess that most networks, even including smaller ones, are not at all federated, and still have centralized *administration*
<joepie91>
unless that has changed recently, which I doubt
<ldlework>
joepie91: yeah open federation
<ldlework>
since rogue server operators can do a lot of damage
<ldlework>
which is probably why no one does it that way :D
<joepie91>
like, even if there is a server routing protocol it generally involves "well if this hub isn't available let's try the other one"
<joepie91>
which... yeah
<joepie91>
single-path routing does not get you terribly far in a federated network :P
<samueldr>
:)
Guanin has joined #nixos-chat
<infinisil>
joepie91: In your presentation you could show the points that define decentralization, and show for each of them why they would be desired or not
<infinisil>
Or I guess it might only be one point
<samueldr>
I never checked how to do "discovery" with totally decentralized things, like e.g. bittorrent has DHTs
<joepie91>
infinisil: I'm approaching it a little differently; by explaining the costs of trustless decentralization and what you get back for it, and in which scenarios this can make sense
<joepie91>
mostly because the general public opinion right now is "decentralize everything!"
<joepie91>
which doesn't work :p
<joepie91>
samueldr: BitTorrent has a few different discovery mechanisms including DHTs and PEX
<samueldr>
or they think they decentralized though they didn't
<joepie91>
that's also a common one, yeah
<samueldr>
joepie91: I meant as a more general concept, different discovery mechanisms, though not sure how it relates to your article
<infinisil>
joepie91: What's the most compelling reason for not being able to decentralize everything?
* samueldr
thinks authority
<joepie91>
samueldr: anyway, a common 'bootstrapping' method for a DHT is to persist the list of known peers locally, use a centralized server for initial matchmaking, and from that point on always start by iterating through the peers that were valid last time the program ran to see if they are still alive, and get new peers from them
<joepie91>
in ye olde Bitcoin days bootstrapping was done over IRC, hehe
<joepie91>
but yeah, probably a bit out of scope for this article :P
<joepie91>
infinisil: cost
<joepie91>
not just monetary
<samueldr>
fun fact: westwood RTS handled matchmaking and lobby through a custom IRC server
<joepie91>
overhead, complexity, lack of development agility
<joepie91>
everything is just *harder* when it's trustlessly decentralized (ie. not federated)
<infinisil>
Good point..
<joepie91>
every feature addition requires rounds of threat modelling and designing mitigations against attacks
<infinisil>
There's no chance this could be alleviated in the future?
<joepie91>
because you can't trust any node to behave honestly
<joepie91>
infinisil: I've seen no plausible evidence that it is
<joepie91>
(possible to alleviate)
<joepie91>
not going to give a hard 'no' but that's definitely what it looks like right now
<joepie91>
most of the 'trustless' projects right now, especially in the 'blockchain' space, paper over this by adding hidden centralized parts, or just ignoring certain attack models
<joepie91>
ie. are broken from a trustless decentralization perspective
<infinisil>
Isn't there progress on having reproducible builds along with a proof that the result corresponds to the inputs?
<infinisil>
Maybe that could have an impact
<joepie91>
that still introduces a reproduction cost :)
<joepie91>
this is the problem: it's never *cheaper* to do something trustlessly, at best it might be equally expensive but there are hundreds of reasons why it can be *more* expensive
<infinisil>
Hmm yeah
<joepie91>
even if that 'more expensive' is only a little, you're still at a disadvantage
<joepie91>
this is what dooms all the 'trustlessly decentralized alternative to googlebookspacegram" projects
* infinisil
is back later, goes to eat
<ldlework>
infinisil: why is there a systemd unit involved?
<ldlework>
It's like it is reducing ${cfg.directory} down by dirname until the reduced path exists, then it is using the original cfg.directory to do some git stuff, then it does something at the end with that reduced $dir variable
<ldlework>
it is confusing
<ldlework>
Why is the nixops wrapper cloning Infinisil/system if the wrapper itself comes from deploying Infinisil/system? Wouldn't it already be around?
<infinisil>
ldlework: Ah that, I actually haven't tested this
<infinisil>
ldlework: It's supposed to git init a directory with the config, and it having the correct permissions
<infinisil>
So it first goes back to the first parent that exists to get the owner
<infinisil>
Then it goes the clone, which can create a bunch of new subdirs. Then it chmods each of them up to the first dir that existed before
<infinisil>
chowns*
<infinisil>
It's a bit overcomplicated, especially since I almost won't use it :)
<ldlework>
I see.
<ldlework>
infinisil: OK so I think I'm coming to the final conclusion that I don't need any part of your deployer thing if I'm used to just using nixops directly, and that the missing understanding that I needed was that to deploy ZNC to my server using your new module all I need to do is clone your fork, and export NIX_PATH=nixpkgs=$path_to_clone ?????
<infinisil>
Well I wouldn't suggest using the clone directly, but rather cherry-pick the changes to the version you're currently using
<ldlework>
So when I use nixops to deploy a new server, it uses the nixpkgs from the deployment machine (my machine) rather than like, cloning stable over on the machine or something?
<infinisil>
Yeah
<ldlework>
infinisil: OK I get how to get nixops to use the special nixpkgs with NIX_PATH, but how do I get my local machine to use that clone too?
<infinisil>
You just set nixpkgs=/path/to/nixpkgs
<infinisil>
In NIX_PATH
* ldlework
covers his face.
<infinisil>
And there's the nix.nixPath option for that
<ldlework>
Ah so I can do it from my configuration.nix
<infinisil>
Yeah, but setting nix.nixPath only changes it after a rebuild
<ldlework>
And by making the nixpkgs checkout a submodule of my overall configuration repo, I can ensure that setting nix.nixPath should always work?
<ldlework>
you get a new laptop, etc, you just wanna clone and go
<ldlework>
you might forget to set NIX_PATH correctly or whatever
<infinisil>
Hmm..
<infinisil>
I should probably put this into my rebuild script
<infinisil>
So it sets -I nixpkgs=
<infinisil>
Wait that doesn't work, because the script gets rebuild with the system itself..
<ldlework>
hehe
<infinisil>
I could use a nix-shell script for that though
<ldlework>
sounds like a wrapper bash script around nixos-rebuild or whatever would work?
<ldlework>
in the config repo
<ldlework>
or that
<infinisil>
The problem with my setup is that I don't plan to have a fixed nixpkgs location
<ldlework>
I know that clever has some crazy bootstrapping method but I couldn't understand it
<infinisil>
Wait no it should work
ma27 has quit [Quit: WeeChat 2.0]
ma27 has joined #nixos-chat
<ldlework>
infinisil: I guess technically I should treat my cherry-picked clone of nixpkgs as unstable?
<infinisil>
Treat it?
<ldlework>
I feel like we should be able to add git repos, local or remote, as nixos channels
<ldlework>
infinisil: like I should take NixOS/nixpkgs:release-18.03 as the base and cherry pick your znc change onto it, but isn't your branch based on nixpkgs master?
<ldlework>
I dunno maybe i'm over thinking
<infinisil>
I mean if there is no merge conflict it's probably fine
<ldlework>
infinisil: wouldn't it be nice if you could just add a bunch of nixpkgs forks as channels that you could easily and distinctly refer to inside your nix expressions?
<infinisil>
Well you can just set them in NIX_PATH
<samueldr>
can't you?
<ldlework>
import <nixpkgs-infinisil> {};
<ldlework>
infinisil: yeah but that seems more fragile I dunno why
<ldlework>
samueldr: can you?
<samueldr>
I haven't used channels much, but I thought you could
<ldlework>
I think channels are technically formatted/organized differently than say just nixpkgs or nixos repos
<infinisil>
Hmm right, but it should be fairly easy to write some functions that deal with this
<infinisil>
ldlework: Don't use that for your system though.., I'm using some master version there, not any channel
<ldlework>
infinisil: I don't know what you mean
<samueldr>
yeah, I'd use it only like the FAQ entry says, and not as the main `nixos` or `nixpkgs` channel
<infinisil>
ldlework: The channels are well tested so they don't break your system
<infinisil>
My branch there is just some master version with a commit with changes
<infinisil>
For packages that would be completely fine because they can't break anything, but nixos can break
<ldlework>
Can't I simply add your nixpkgs fork, at the specific commit where you add the znc module changes, as a channel nixpkgs-infinisil, then somehow use *just* the znc module from your fork, and everything else from the release-18.03 branch?
<ldlework>
Or are you saying that is *only* possible with mere packages.
<samueldr>
imports = [<nixpkgs-infinisil/nixos/modules/...>] may work?
<samueldr>
though I don't know what happens for conflicting definitions
<LnL>
yeah + disabling the original module if it defines the same options
<infinisil>
Ah yes you can do that
<infinisil>
Probably
<ldlework>
lol
* ldlework
weeps
<infinisil>
I mean, there is disabledModules
<infinisil>
You can use to disable specific modules
<infinisil>
But not sure if this would work because both channels ones have the same name
__monty__ has joined #nixos-chat
<samueldr>
haven't checked, but if it uses paths, paths would be different?
<infinisil>
Or not! Because I changed znc from a single file "znc.nix" to a folder "znc", heh
<ldlework>
Interestingly, now I'm thinking that each nixops deployment should have its own set of channel configurations.
osom has joined #nixos-chat
<osom>
hey
<infinisil>
ldlework: Yeah, unfortunately not possible for now :(
<ldlework>
Each time a deployment is done, it should reliably be using the same sources.
<samueldr>
→ moduleKey = m: if isString m then toString modulesPath + "/" + m else toString m;
<samueldr>
always ends up being a path it seems
<LnL>
yeah, that's the identity of modules
<ldlework>
hi osom
<osom>
how are you guys doing?
<ldlework>
confused :)
<osom>
why's that>
<LnL>
by default it prefixes them for you, but you could disable multiple versions of the same module if necessary for some weird reason
<ldlework>
Nix is complicated yo!
osom has quit [Client Quit]
<ldlework>
:(
<samueldr>
nix is simple, what you achieve can be :D
<ldlework>
samueldr: what's the point with identifying that modules are named by a path?
<samueldr>
it's a fully qualified name
<samueldr>
so having imports = [ ./modules/foo.nix ]; both in your local config and nixpkgs will import two `./modules/foo.nix` file
<samueldr>
if you pass it a string, it will be equivalent to prefixing the nixpkgs fully qualified path
<samueldr>
so only the nixpkgs-provided one will be removed
<samueldr>
dunno if how I explained it briefly made sense
<ldlework>
you mean via disabledModules?
<samueldr>
yrs
<samueldr>
yes*
<LnL>
yeah, and since modules define options/values across multiple attributes the best identity is the file
<ldlework>
lets say I have nixpkgs as the 18.03 ad nixpkgs-infinisil as the infinisil channel - how would I refer to the 18.03 znc module to disable it? Do I then just use the infinisil options as normal?
<samueldr>
as it's the "default" one, the one from your nixpkgs, you can use a string
<samueldr>
(in disabledModules)
<ldlework>
infinisil: think this could work?
<infinisil>
Probably
<infinisil>
But why not just use a git checkout?
<ldlework>
Because then I have to maintain my own fork with a cherry-picked merging of the things.
<ldlework>
And then change once it is merged in.
<infinisil>
Eh, it's not hard
<infinisil>
git rebase does all the work for you
<ldlework>
This method would theoretically allow one to track multiple disparate features in different forks, at the same time.
<infinisil>
The good thing with git rebase is that once the feature is merged, it will notice this and automatically not reapply it again
<ldlework>
But there is the point that, using a checkout and NIX_PATH allows you to use different things for different hosts.
<ldlework>
So I don't have to have this bearing upon my local system, as it shares channels with nixops.
<LnL>
it was exactly added for this reason, I want to track 18.03 by default to get security updates
<samueldr>
I personally would try using disabledModules and importing the file from infinisil's repo
<samueldr>
be it from a channel or a git checkout of infinisil's repo
<ldlework>
interesting, I first grabbed nixos/nixpkgs@release-18.03 and then I fetched infinisil/nixpkgs@better-znc-module and it said "warning: no common commits"
<ldlework>
infinisil: good idea
<ldlework>
infinisil: OK, I cloned nixos/nixpkgs@release-18.03 then I fetched your remote and cherrypicked c9ee4f9136dafb767837505edb7491d56c1c0e65. Then I export NIX_PATH=nixpkgs=/nixcfg/hosts/spy/ext/nixpkgs:$NIX_PATH and redeployed my machine with nixops. I got this: https://gist.github.com/dustinlacewell/d97dcfc3431e2bbce05bfd45b971529e
<ldlework>
I'm not sure why docbook is being installed or why it fails when I cherry pick your znc ontop of 18.03
<infinisil>
Huh weird
<infinisil>
I do have an option type which is recursive
<infinisil>
But I adjusted the description of it so it shouldn't be a problem (the description would by default include the description of its subtypes)
<ldlework>
should I cherry-pick onto a different mainline branch?
<ldlework>
infinisil: fwiw, using your pr commit directly the closure successfully built
<ldlework>
I suppose your pr isn't going to be merged into release-18.03 but it could be a problem come merge time
<ldlework>
there were no merge conflict, just breakage at build time
<infinisil>
Not sure, must be something that changed in nixpkgs
<infinisil>
You could bisect it
<ldlework>
I'm not exactly sure how git bisect works with a cherry-pick in play.
<ldlework>
hmm
<ldlework>
Would I start from your branch, and rebase nixos/nixpkgs@master over your branch? The last commit from your branch would be the "good" commit, and the latest commit, now rebased ontop, would be the "bad" commit?