<steveeJ>
ldlework: I'm using qtile too and have been pretty happy with it!
<steveeJ>
ldlework: except for the occasional event when I lose a floating window behind everything else and the focus is broken
<ldlework>
steveeJ, the great thing about qtile is right now you can just open your config and write a function to set all windows in the current group to tiled and bind that to a global key and then instantly restart qtile without logging out
<ldlework>
i've stopped what i was doing and just sat down and wrote a widget before
<ldlework>
i have a widget where I can configure pgrep queries with labels, and if any processes are running that match, i get a little indicator telling that process is running
<ldlework>
it's great for being able to switch away from certain console commands that are not instant, but not particularly long either
<ldlework>
i can run a home-manager rebuild, and just wait for the little `nix` indicator on the bar to dissapear
<steveeJ>
ldlework: my qtile config is read-only /o\
<ldlework>
Well certainly your nix expressions have places where you can insert arbitrary Python into the config no?
<ldlework>
I have a whole module of custom Python code. My QTile is crazy customized with all sorts of shit.
<ldlework>
steveeJ:you can also see the indicator I was talking about, down at the bottom right
<ldlework>
letting me know that ffmpeg is running :D
<steveeJ>
nice gimmick
<ldlework>
thanks
<ldlework>
NixOS is the assurance I need that it'll keep working. Even if this machine crashes. I'll get all that back.
<ldlework>
Literally the only reason I'd spend so much time making things so nice for myself.
<steveeJ>
ldlework: so how do you have hot-reload with nix managed qtile config?
<ldlework>
I try to have the least amount of system-level configuration on my NixOS workstation as possible. I try to manage as much as possible with home-manager, with my modules split between linux and darwin modules. I try to put as much into the linux home manager config as possible. The idea being that as much of my system is portable as possible. So that said, home-manager has no problem sticking files into
<steveeJ>
this way I don't crash my current qtile if I make a mistake in the config
<ldlework>
Sure. You get pretty used to editing the config in another VT pretty quickly without Xephyr :D
<steveeJ>
ldlework: would be cool to have this automated and programatically detect broken configs. do you know if qtile has a command to parse and load a config and indicates the success in the exit code?
<infinisil>
I'm not sure how I feel about the batch thing
<infinisil>
But I guess it's alright
<etu>
I'm thinking of opting to a later batch though, like 3
<etu>
Because it seems like most hardware fixes they plan are kinda done at that point
<infinisil>
I can even wait for the Evergreen one, which seems to be the "full" version, which might be needed for europe (heard that in a comment)
<infinisil>
Because it has the full certifications or something, I dunno
<etu>
oh
<etu>
I guess I postpone it a bit and read reviews :D
<infinisil>
Unfortunately my old phone is kinda broken, but fortunately my even older phone still works, so I can use that for a while still
<andi->
It would be nice to hear what it takes to for example replace the case if they make signitifcant improvements on it. I can probably also wait until 2020Q3 but kinda don't want to use Android that long anymore.
LnL has quit [Ping timeout: 244 seconds]
<andi->
Now that 19.03 is nearing an end I managed to convince the Hetzner Cloud support to add 19.03 and remove the 18.09 image since it isn't supported anymore...
<manveru>
... :P
<andi->
It only took me 3 mails so not that bad.
<andi->
I'll just shoot them an email once the new release is a week or so old
<manveru>
reminds me that i should get rid of my hetzner box... almost moved everything over to vpsfree
noonien has quit [Quit: Connection closed for inactivity]
<eyJhb>
etu: did you try the thingy yesterday?
<etu>
eyJhb: Hmm, nope. Haven't had time yet
<etu>
eyJhb: maybe this weekend
<manveru>
,locate bin prettier
<{^_^}>
Couldn't find in any packages
<manveru>
damn... yet another one
<eyJhb>
etu: that is the same I am saying, but... Now I realise it will not happen... The bar at uni was open yesterday, and party to introduce all the new students tonight...
<eyJhb>
manveru: well, at least you know the name of what you want to use. I have forgotten the name for the 5th time
<manveru>
heh
<manveru>
it's mostly just installing all the extra stuff various emacs packages want
<manveru>
quite tiresome, why am i not living in the future where everyone uses nix yet :P
<Taneb>
RFC 52 interests me but I don't have the know-how to help out :( It's like "this is a cool idea I had no idea was remotely possible"
<Taneb>
Well, life is a learning experience :) I'm going to try and follow it along
<eyJhb>
manveru: Agreed, I keep getting teased about that by my friends, because I "need to code"to use my OS.
<manveru>
Taneb: i really like that rfc as well
<manveru>
seems like a good step to make nixos generally more secure as well
<manveru>
and know exactly what services puts what data where :)
<Taneb>
manveru: is the security advantage just services can't touch other services' data?
<eyJhb>
infinisil: thanks! :D
<manveru>
Taneb: pretty much
<srhb>
Though I guess it's less painful for me to hardcode the uids after the fact to make them work in a networked environment.. Fewer services total need that.
<eyJhb>
srhb: `Enlarge the reserved range of system users/groups`
<srhb>
But there's something really nice about moving filesystems around and the ownership just lines up.
<infinisil>
I think we should get away from the assumption that uids/gids are the same everywhere
<srhb>
I think that's probably true, but I don't know how nice the override mechanism is when I actually need to hardcode them.
<srhb>
I guess we can improve that instead.
<manveru>
you can still hardcode them yourself anyway
<srhb>
Sure.
__monty__ has joined #nixos-chat
<infinisil>
There is a slight problem with this, because once NixOS made a dynamic uid, you can't change it to a different static id unless you manually fix /var/lib/nixos/uid-map as well
<manveru>
infinisil: but DynamicUser wouldn't make any uid
<manveru>
so that doesn't affect it...
<infinisil>
And the manual change in uid-map is associated with a manual permission fixup of the files
<infinisil>
Yeah DynamicUser doesn't have that problem
<Taneb>
How does DynamicUser interact with making backups?
<manveru>
so in general, DynamicUser should be mandatory for ephemeral services, i think
<srhb>
I'm sort of leaning towards the huge range above the normal maxes. It's ugly in principle, but sounds like it'll be great in practice for a long while :-P
<infinisil>
Taneb: The average backup method shouldn't be affected. The only weird thing is going to be that the backed up files might have completely random uids not recognizable on the other machine. Restoring won't be a problem either
<infinisil>
s/might//
<manveru>
well, it will just fix the ids after restore on service startup, which might take a while
<infinisil>
srhb: Well, that's another problem, because while we can guarantee uniqueness in nixpkgs, there might be a whole lot of other repos assigning to the static range
<manveru>
just saying, that might be the worst case, if there is a conflict of ids or something...
<srhb>
infinisil: Won't all methods share that problem though?
<infinisil>
(like people's configurations or so)
<infinisil>
srhb: Things like users.users.foo.uid = 100, users.users.bar.uid = 100 can't happen with dynamically assigned ones
* srhb
nods
<infinisil>
So that's indeed only a problem when they're statically assigned
<infinisil>
I should mention that in the RFC
* infinisil
is back later
<manveru>
i'm still wondering why we're restricted to 16bit ids...
<manveru>
doesn't linux support at least 32?
vika_nezrimaya has joined #nixos-chat
<infinisil>
manveru: Ah good point, yeah I think we could use 32bit ones, but I'm not sure if all programs can handle those
<manveru>
would be fun to find out though :D
vika_nezrimaya has quit [Client Quit]
<infinisil>
manveru: Hehe, only now I'm realizing that you wrote the comment I was referring to, you even said so and I missed it :p
<eyJhb>
manveru: depends on the way you find out :p
<manveru>
whatever happened to testing in production!?
<manveru>
imagine the news headlines
<eyJhb>
Nothing? Isn't that the REAL place to test? It is like, crowd testing
<eyJhb>
:D
<eyJhb>
I actually took down a site yesterday for 1sec because I .. MIGHT have modified the source while the site was running. PHP <3
<etu>
eyJhb: That's what we call flexible ;)
<eyJhb>
etu: True! Was basically live coding for HR, because they needed some quick thing :p Don't think she realised what happened when the site didn't want to load. (so stupid tags! `<?php`)
jtojnar has quit [Remote host closed the connection]
jtojnar has joined #nixos-chat
psyanticy has joined #nixos-chat
drakonis has joined #nixos-chat
Jackneill has quit [Ping timeout: 245 seconds]
Jackneill has joined #nixos-chat
drakonis has quit [Read error: Connection reset by peer]
pie_ has joined #nixos-chat
waleee-cl has joined #nixos-chat
endformationage has joined #nixos-chat
drakonis has joined #nixos-chat
spacekookie_ has joined #nixos-chat
mog- has joined #nixos-chat
spacekookie has quit [Ping timeout: 244 seconds]
mog has quit [Read error: Connection reset by peer]
mog- is now known as mog
spacekookie_ is now known as spacekookie
worldofpeace has quit [Remote host closed the connection]
colemickens has quit [Write error: Connection reset by peer]
thefloweringash has quit [Write error: Connection reset by peer]
sphalerit has quit [Read error: Connection reset by peer]
tokudan[m] has quit [Read error: Connection reset by peer]
Ralith has quit [Write error: Connection reset by peer]
pinage404[m] has quit [Write error: Connection reset by peer]
Myhlamaeus1 has quit [Remote host closed the connection]
* sphalerite
considers opening a new RFC to propose moving RFC discussion to a mailing list, because the rfc49 (flakes) discussion is so awful to navigate
drakonis has joined #nixos-chat
<andi->
+1
<andi->
(I actually receive them as email but replies to code snippets etc is painful)
<elvishjerricco>
infinisil: Try having a sizable mbuffer between the send and receive processes. Lots of times the reads end up needlessly waiting on the writes just because the pipe buffer isn't large enough
<ldlework>
you gotta play like you got ants in your pants
<sphalerite>
andi-: people hate mailing lists though :p
<__monty__>
It's harder to keep track of code comments if it were a real mailing list though.
<andi->
sphalerite: I like them :-)
<sphalerite>
__monty__: not really, it works great for linux :)
<__monty__>
As I understand it in linux someone posts an entire patch, people comment, they change the patch, post it to the list again, etc.
<__monty__>
That's not a good format for a long-form discussion where people intermittently report typos/clarifications.
<__monty__>
At least imo.
<__monty__>
It's two things that should really happen in different contexts.
<sphalerite>
__monty__: since the patch is posted in email format, people can comment in-line perfectly well.
<sphalerite>
just like in-line replying to a regular email.
<sphalerite>
It's been around a lot longer than github's line comments x)
<__monty__>
That's not what I'm talking about.
<__monty__>
When the time comes to go over the reviews, github has them all in one place. A mailing list spreads them out over however many mails you've received since last time you fixed things up.
<__monty__>
Unless you advocate quoting whole messages. Which, you're a monster.
<__monty__>
Note that I'd love for the github threads to have better email integration. It's just that for the code comments, I always click the links to view on github.
<__monty__>
Maybe sr.ht does this better?
<__monty__>
Also, maybe I'm just biased. I've only passively participated in mailing lists before. But they've never seemed to be good for browsing/lurking to me.
<infinisil>
ldlework: Not my kind of jam, but that's still pretty catchy :o
<ldlework>
infinisil: me either, but i always practice to random genres. notable for how hard it was.