* colemickens
didn't think he'd ever see "Rust+Kubernetes+Nix" in a job description, let alone for Target. someone pinch me
<gchristensen>
:D
__monty__ has quit [Quit: leaving]
jasongrossman has joined #nixos-chat
<Arahael>
Same acronym as "Real Kool Now!" :)
<infinisil>
Oh no
<infinisil>
I just came to the conclusion that NixOS modules suck
<samueldr>
and what can we do to make them suck less, or even good?
<infinisil>
I remember somebody once showing me their alternative "module system", which is based on functions
<infinisil>
So instead of doing `services.foo.enable = true;`, you do `services.foo = mkFooService { <setting options for foo here> }`
<infinisil>
I'm not entirely sure how it worked though
<infinisil>
And I'm not sure how overriding things can work with this (if at all)
<infinisil>
But that would completely eliminate all performance and permission issues in nixos modules
<infinisil>
(permission issues = any module can set any option, no restrictions)
<Arahael>
Also makes it less declarative, I'd say?
* Arahael
is still learning nixos, mind you.
<infinisil>
Doesn't look less declarative to me
<samueldr>
it changes how it composes declarations, I guess
<samueldr>
could mkFooService, behind the scenes, import the service and simply set the same configs?
<samueldr>
would circle back for the permission issue, but would help in importing only the bare minimum?
<infinisil>
Not with the current module system
<gchristensen>
"suck" is pretty strong
<infinisil>
gchristensen: Yeah I guess that's an overstatement. It does have some issues that can't be fixed elegantly with how it works now.
<infinisil>
I did come up with an idea which could speed it up considerably, the one we have now
<infinisil>
(I could explain it if anybody is curious)
<samueldr>
I'm almost always curious
<infinisil>
I'm only 90% sure on it working though
<infinisil>
samueldr: Okay so
<infinisil>
The basic idea is that modules can have a special attribute (special like imports) `enableMapping`, which can have a value like `enableMapping = { services.foo.enable = <nixpkgs/nixos/modules/foo>; }`
<infinisil>
While this does sound very simple, making it work is a bit more complicated
<samueldr>
can this deal with something that always sets a config option, even though it's not been "mapped" through enabling the service?
<infinisil>
samueldr: Not entirely sure what you mean
<samueldr>
I imagine that services.foo.bar won't be an option until services.foo.bar.enable is set to true, right?
<samueldr>
would it be unwise to call that "mapping"?
<infinisil>
Hmm that's a good point..
<infinisil>
And you can also set options even without enabling the service, which is useful if you want to temporarily turn it off
<samueldr>
if module baz, through services.baz.enable is always setting services.foo.bar to some value, simply because it previously didn't have to care about the `enable = true` part of foo, and also because it becomes a chore to gate those under if
<samueldr>
and yeah, even your point, which I didn't think, temporarily disabling
<infinisil>
Yeah, so this idea on its own won't work..
<samueldr>
I'm wondering if `enableMapping` meaning that anything goes and validation only kicks in on enable is a bad idea?
<samueldr>
probably
<samueldr>
but still wondering
<samueldr>
so that I can even services.foo.fdisufhsuhf = 1; since services.foo has been kinda declared as a namespace?
<samueldr>
not sure if I make sense
<infinisil>
Maybe
<samueldr>
it wouldn't work for all namespaces, but I think the general idea might work for most services
<samueldr>
most of the time services.$anything wouldn't be used until $anything is enabled
<infinisil>
Although, other modules could still refer to services.$anything
<samueldr>
the main bad thing about that is how it allows for invalid config until that namespace is mapped
<infinisil>
Yeah that too..
<samueldr>
and yeah :/ if other services use the values from $anything, then it's another issue
<infinisil>
It's a dependency mess..
<samueldr>
(use the values without enabling it)
<infinisil>
The module system is so complex, it almost feels like any feature we add is bound to cause problems somewhere
<infinisil>
Like submodules, merging, the fact that you can add options to submodules from anywhere, the fact that submodules are hacky and don't work like full modules
pie___ has joined #nixos-chat
pie__ has quit [Ping timeout: 246 seconds]
drakonis has quit [Quit: WeeChat 2.3]
ivan has quit [Quit: lp0 on fire]
drakonis has joined #nixos-chat
ivan has joined #nixos-chat
endformationage has quit [Ping timeout: 245 seconds]
ninjin has quit [Ping timeout: 256 seconds]
jackdk has quit [Ping timeout: 245 seconds]
Myhlamaeus has quit [Ping timeout: 250 seconds]
ninjin has joined #nixos-chat
ivan has quit [Quit: lp0 on fire]
ivan has joined #nixos-chat
pie_ has joined #nixos-chat
Zer000 has quit [Ping timeout: 255 seconds]
__monty__ has joined #nixos-chat
lejonet has quit [Ping timeout: 250 seconds]
jtojnar has quit [Remote host closed the connection]
jtojnar has joined #nixos-chat
lejonet has joined #nixos-chat
jtojnar_ has joined #nixos-chat
jtojnar has quit [Read error: Connection reset by peer]
jtojnar_ is now known as jtojnar
{^_^} has quit [Remote host closed the connection]
{^_^} has joined #nixos-chat
johanot has joined #nixos-chat
jtojnar has quit [Remote host closed the connection]
<clefru>
any opinions on terminal-based IRC clients? It should run in tmux/screen, and it would be best to have it run in some form of LXC container
<gchristensen>
weechat is nice
<clefru>
I have that on my radar already :)
<ldlework>
been using weechat a long time now
<gchristensen>
same
<clever>
clefru: ive been using irssi under screen for years
<elvishjerricco>
gchristensen: Not just the kernel. Pretty much any large make project has slow install phase times. Usually you can just do `make install -j`, but I dunno why that's not default in nixpkgs. And the fact that autoconf hasn't parallelized configure scripts yet confuses me greatly.
<ldlework>
should i be using this lorri thing
<gchristensen>
are you asking me?
<ldlework>
sure :)
<gchristensen>
yes
<gchristensen>
=)
<ldlework>
it needs a global watch service
<ldlework>
maybe
<gchristensen>
I agree
drakonis has joined #nixos-chat
drakonis_ has quit [Ping timeout: 258 seconds]
Myhlamaeus has joined #nixos-chat
drakonis_ has joined #nixos-chat
drakonis has quit [Ping timeout: 250 seconds]
MichaelRaskin has joined #nixos-chat
<steveeJ>
what terminals are people with tiling WM's using here? I've been using roxterm which can be configured borderless and has nice fonts etc, but somehow it broke as when the WM kills one window of it all roxterm instances die
<gchristensen>
I use sakura, it is fine most of the time -- but leaves segfaults in dmesg (not noticable to me the user)
<simpson>
steveeJ: I put up with terminator. I used to put up with sakura. I also put up with xterm as default/fallback.
<MichaelRaskin>
rxvt_unicode+screen
<Ralith>
I've been on termite for a while, it gets the job done
<gchristensen>
I wish I had the time and interest to contribute to a terminal's development
<gchristensen>
for example I wish I could select stderr / stdout separately after the fact
<Ralith>
alacritty seems interesting
<samueldr>
isn't it already too late?
<Ralith>
but it's a bit bleeding edge
<samueldr>
that'd be within the shell's realm?
<gchristensen>
samueldr: I don't think so, bash doesn't merge them I don't think
<steveeJ>
if I have one wish to a terminal it'd be to be able to open the output in vim
<samueldr>
something merges them, and I didn't think the terminal would be given multiple streams
<samueldr>
maybe it's a difference between bash interactive and not interactive?
* samueldr
is out of his element
* gchristensen
too
<elvishjerricco>
I'm not sure why I chose terminator for a terminal, but I'm not happy I did. Just haven't gotten around to replacing it
<MichaelRaskin>
I think bash doesn't merge them, but normally both fd1 and fd2 point to the controlling terminal
<MichaelRaskin>
And I am not sure what happens if they point to _different_ PTYs
<samueldr>
right, so it's still already merged once the terminal gets them, due to that pty?
<MichaelRaskin>
Yes
<infinisil>
clefru: Another vote for weechat. I've used irssi previously, and weechat is really so much nicer
<samueldr>
makes sense, even my bash interactive assumption didn't really make sense to me, forgot about how ptys are things
<MichaelRaskin>
One could spawn bash with separate streams, that should actually work
<MichaelRaskin>
But some interactive programs could be amazed by fd0 fd1 fd2 being three different PTYs
<elvishjerricco>
couldn't the terminal spawn the child process with stderr and stdout pointing to different ones?
<steveeJ>
thanks for the suggestions y'all
<MichaelRaskin>
Yes it can
<MichaelRaskin>
But think what, say, less does
<MichaelRaskin>
when asked to show stdin and still needing to be controlled from terminal
<MichaelRaskin>
It makes assumptions
<MichaelRaskin>
Hm. Maybe terminal emulator could try writing input to both terminals (0+1 and 2) just in case. One could argue that anyone confused by that is already doing something wrong…
<MichaelRaskin>
Hm. BuyVM is out of stock in Luxembourg. Maybe I just got lucky with a VM. On the less bright side, apparently the network connectivity is via Cogent, which might mean it is _usually_ OK…
pie_ has quit [Ping timeout: 245 seconds]
waleee has quit [Quit: WeeChat 2.4]
Zer000 has joined #nixos-chat
pie_ has joined #nixos-chat
aanderse has quit [Ping timeout: 250 seconds]
drakonis has joined #nixos-chat
drakonis has quit [Quit: WeeChat 2.3]
<infinisil>
A tiny thing that would help a lot in the lorri blogpost is linking to lorri when you first mention it, I had a hard time finding it
<infinisil>
gchristensen: ^
<gchristensen>
hmmm
<gchristensen>
not sure I can release that update, but I'll try!
<gchristensen>
infinisil: I put an edit in the release queue, but it is a bit late for the team that reviews them