<cole-h>
lovesegfault: Working on a history paper about how the Guatemalan coup d'etat in 1954 wasn't only due to the United States and its UFCO
<cole-h>
It's sucking the soul out of me and it's due Friday
<lovesegfault>
cole-h: :(
<lovesegfault>
That sounds horrible
<cole-h>
5-6 pages, big RIP.
<lovesegfault>
It's like when the idiots back at home say the military coup d'etat was a revolution 🤣
<aanderse>
so recently the television in my living room turns on when i nixos rebuild... but only sometimes 🤔
<cole-h>
lovesegfault: Totally wasn't because of Decreto 900 screwing over UFCO and the fact that SecState (and his brother) were in bed with them 🤔
<cole-h>
aanderse: wot
<aanderse>
cole-h: not sure, i'm too lazy to look into it yet
<aanderse>
its probably going to get increasingly annoying pretty fast, though
<cole-h>
You sure it's not a coincidence?
<cole-h>
Because that sounds really, really weird
<aanderse>
lol its hooked up :P
<aanderse>
pc is in the kitchen at a standing desk against the wall, tv is in the living room on the other side of the wall
<aanderse>
an hdmi cable runs through the wall
<aanderse>
the tv uses CEC to communicate with the computer
<aanderse>
so you can control kodi via a tv remote
<aanderse>
CEC has the ability to turn tvs on and off
<cole-h>
OK, not sounding as weird now... haha
<cole-h>
Still weird
<aanderse>
yes, still weird
<cole-h>
But not paranormal-weird
<cole-h>
:D
<aanderse>
i'm really wondering why the nixos-rebuild does it... what on earth is impacting that
<cole-h>
It might be restarting services that contact the TV/whatever is running on it?
<aanderse>
yeah will have to look at some logs later
<Gaelan>
ugh why does everything i do inevitably end up in stdenv rebuilds
<samueldr>
aanderse: systemd service switch/reload?
<aanderse>
samueldr: i'm guessing, but i don't know what that has to do with kodi
<aanderse>
kodi exclusively locks the CEC device
<samueldr>
hmm
<aanderse>
only once in a while though... hmm
<aanderse>
i've just rebuilt about 10 times, only did it once
<aanderse>
i should really look at a log
<aanderse>
or go to bed
<ornxka>
aanderse: you have ghosts, consider exorcising your pc
<aanderse>
ornxka: i'll keep that as an option
<ashkitten>
i wish CEC worked on my tv...
<ashkitten>
it's a roku tv, and it should theoretically at least turn on when asked to even though it doesn't support remote control passthrough, but it doesnt
vika_nezrimaya has quit [Ping timeout: 258 seconds]
<aleph->
Huh had totally forgotten there was a nix module for SaltStack
<aleph->
How odd
<drakonis1>
nix has a kitchen sink of modules
drakonis1 has quit [Quit: WeeChat 2.8]
drakonis has quit [Read error: Connection reset by peer]
drakonis has joined #nixos-chat
waleee-cl has quit [Quit: Connection closed for inactivity]
drakonis has quit [Read error: Connection reset by peer]
drakonis_ has joined #nixos-chat
cole-h has quit [Quit: Goodbye]
endformationage has quit [Quit: WeeChat 2.6]
<aleph->
Heh
<aleph->
drakonis_: Other way around
<aleph->
Salt having a model to install packages via nix
<colemickens>
confession: I really don't know how to setup bridged networking for libvirt machines anymore :(
<colemickens>
I think they removed it frm virt-manager.
<srhb>
colemickens: Hmm, I think I set mine up manually, but I don't actually know if it works anymore. :P
<srhb>
colemickens: Seems to work fine.
* colemickens
imposter syndrome intensifies
<srhb>
colemickens: I have a networking.bridges.virtd.interfaces = []; and an interface.virtd.ipv4 on the host which defines an address for the bridge
<colemickens>
I've actually gotten bridged networking working a while back for an ICS scenario, so maybe I can figure it out.
<colemickens>
hm, I thought the point was that the VM would be able to just bridge and then DHCP normally. I need to dig in more than and re-acquaint myself I think
<srhb>
colemickens: Oh, yeah, that'll require a bit more than that :)
<srhb>
Actually not much more. Probably some firewalling.
<eyJhb>
srhb: How is it going in the weather department? :p
<srhb>
eyJhb: I haven't workd there since.. uh, october, I think :P
<eyJhb>
srhb: Why not? :o
<srhb>
Started at my old job in DBC again. :)
<eyJhb>
I... I swithech the jobs around .. :p Somewhat got into my tiny mind that you started at DMI again...
<eyJhb>
Well, how is the book buisness going? :p
<srhb>
Good! Well, a bit slow because of covid I guess, but that part hasn't really affected us much. There's always infrastructure stuff to be done. :)
<srhb>
eyJhb: How about you? Weird studying remote?
<eyJhb>
THat's true, always stuff to be done. But the libraries are mostly closed, right?
<eyJhb>
It is, and the material is seriously lacking... And soooo many exams I have to prepare for, because I got srewed by a reexam (basically someone thought the beginning of the 6. semester was moving too slow, so they put additional course hours in, so less time to read up on reexams...)
<eyJhb>
But jush had the other reexam that we wrote about. Weird having a MS Teams meeting for a exam
<srhb>
eyJhb: Yeah, but libraries are reopening soon I think. Which is good.
<eyJhb>
On the 18th right?
<srhb>
I actually can't remember, which is a bit embarassing. :D
<eyJhb>
When the servers start to have a load, that is when :p
<srhb>
eyJhb: Yeah, I expect there will be a spike. But I think we have plenty of capacity :P
<srhb>
colemickens: It looks like the virt-manager iface option to pick for bridging is "shared device"
<srhb>
colemickens: Because we needed another term for that :-)
<srhb>
colemickens: Picking my host-side bridge there had it create a vnet0 which is linked properly to my virtd bridge
<srhb>
(which in turn also has my ethernet)
<srhb>
colemickens: And looks like dhcp works just fine.
<eyJhb>
srhb: surely :D Does working at DBC give you more time to work on NixOS and contribute more than at DMI?
<srhb>
eyJhb: Yes, though I'm always not good enough at taking time to upstream. Practice practice :P
<sphalerite>
colemickens: srhb: the bridge stuff is only weird when using the libvirt user session thing. When connecting to qemu:///system, the bridges are displayed correctly.
<srhb>
sphalerite: Oh, I don't think I've ever used the user sessions.
KeiraT has quit [Ping timeout: 240 seconds]
<sphalerite>
yeah I recently used it for the first time, works well too, except for the bridge weirdness (you have to select "Shared device" and then _type_ the name of the bridge
<sphalerite>
and I just use the default virbr0 bridge, no setup required
<srhb>
Yeah, I like the manual one because I often isolate vms in funny ways.
KeiraT has joined #nixos-chat
<colemickens>
I am on qemu:///system
<colemickens>
but the default network is forward mode=nat, an it has its own ip range
<colemickens>
if I go to the VM, and try to add a NIC, I see where the shared device option is.
<colemickens>
But I'm confused, sphalerite do you have a different virbr0? or can I still re-use this virbr0 for a shared device too? I feel like I'm close but getting wires slightly crosses
<eyJhb>
srhb: with time it might come :p
<sphalerite>
colemickens: right, mine uses nat and has its own IP range too
<sphalerite>
colemickens: what's your goal state?
<eyJhb>
Anyone using Bitlbee in here?
<eyJhb>
Thinking of making a Bitlbee like thing in Go, because I am kinda annoyed that everything is C in Bitlbee. I really do hate making networking stuff in C... Integration with e.g. Facebook messenger, etc.
<sphalerite>
colemickens: well yes, you can select the network "default" as the network source in multiple VMs..?
<sphalerite>
colemickens: for me it appears as "Virtual network 'default': NAT"
<colemickens>
sorry, when I first stated it I was trying to say that I want the VM on my LAN
<sphalerite>
oooh
<colemickens>
this used to be very easy to do in virt-manager because I'd never manually configured a bridge before 6 months ago
<colemickens>
and now I'm just butting heads with NM mostly, I think :/
<sphalerite>
in that case, you can either use macvtap
<sphalerite>
or create a bridge and put your physical interface in it and specify it as a shared device in virt-manager
<sphalerite>
I think
<colemickens>
yeah, the second one is the general concept that I thought I understood, but NM isn't quite doing what I think the commands ought to be doing.
<colemickens>
I do remember using macvtap in the past... idk why I'm not seeing it now in virt-manager :s
<sphalerite>
you're not? o.O
<colemickens>
heh I swear I've been doing too much tech support for people and the "weird unexplainable PEBKAC-sounding problems" have been increasing!
<colemickens>
I've got enough hints that I've got plenty of things to go off and check my understanding on and try :)
maxdevjs has quit [Remote host closed the connection]
maxdevjs has joined #nixos-chat
__monty__ has joined #nixos-chat
tokudan[m] has quit [Quit: tokudan[m]]
tokudan[m] has joined #nixos-chat
parsley936 has joined #nixos-chat
<gchristensen>
til you can send signals via systemctl to entire units: systemctl kill --user --signal STOP run-rc4750630f19b48758b92158b96c0ebe4.scope
<gchristensen>
(this scope happens to be Slack's scope, since I only have 30min left of battery)
<__monty__>
All those wasted cycles 😢
<gchristensen>
with window switching events you could get mobile-phone like process management
<__monty__>
That doesn't sound very desirable tbh. Aren't mobile phones trying to get away from that?
<__monty__>
Though if it saves considerable power...
<joepie91>
I'd love to be able to just suspend process groups (and have them actually work again when unsuspended, including GUI applications), similar to how smartphones do it
<gchristensen>
joepie91: it seems to work!
<andi->
gchristensen: window switching with native wayland applications basically does that already.. it just runs the background thread and painting is paused.. but slack isn't really native wayland
<joepie91>
AFAIK there are too many caveats on Linux for this to actually work, eg. what if a process listens for particular dbus signals?
<joepie91>
you might want those to be queued, or wake up the process, etc.
<gchristensen>
andi-: web browsers and slack seem to take up considerable CPU even when I'm not looking at them, though?
<gchristensen>
joepie91: you might indeed! no magic here, but I think many of my programs would work well under this model, ymmv :)
<andi->
obviously they'll still run many silly javascript callbacks and do stuff in the background but at least they will not require a repaint
<andi->
I have been thinking of just disallowing `setTimeout` and `setInterval` on all tabs by default..
<joepie91>
gchristensen: right, but that's the thing, what I want is for this to *always* work, not "for many things" :P
<joepie91>
I want it as a real, first-class OS feature, rather than some hack with caveats
<gchristensen>
sure
<gchristensen>
joepie91: well ,maybe you could use a dbus spy to wake up the program. or maybe programs listening on dbus shouldn't be suspended, or whatever. I dunno, but this has been a fun experiment for me
<gchristensen>
socket-activated but dbus-activated
<andi->
there is already `Type=dbus` in systemd
<gchristensen>
perfect!
<andi->
but that wouldn't work in many cases where a client is listening on events. It only works if some service is being requested.
<gchristensen>
yeah
<makefu>
joepie91: you managed to get into my twitter feed with your firebase. Some tiny social media bubble i have ...
evils has quit [Remote host closed the connection]
<emily>
I wonder if these packages that extract .msis into $out intended to just extract a bunch of installer metadata/scripts plus a monolithic .cab :s
<ornxka>
today i learned that services.zfs.trim.enable defaults to true
<ornxka>
i wish there was some warning about that because it has (not extremely important but still worth considering) security implications
<srhb>
ornxka: It was in the 20.03 release notes, and the option does say it defaults true. But perhaps it should be enriched with some text?
<ornxka>
ahhh thats when it happened
<ornxka>
i remember looking for that option and thinking it defaulted to false so i wouldnt need to set it
<ornxka>
ideally the default would be dependent on whether the underlying devices used luks
<ornxka>
but i dont think thats possible
<srhb>
ornxka: It might sort of be (since we mostly know about how devices map to luks volumes directly in Nix) and there's also the zfs native encryption case to consider.
<srhb>
But this is getting dangerously on-topic. :-)
<ornxka>
on-topic is a subset of off-topic :p
<srhb>
Oh :P
<ashkitten>
is there any ddrescue option for dealing with badly behaved drives? my friend has one that seemingly resets itself every time it encounters a bad sector, which means it's been rescuing data at about 0.5 gigs per HOUR
<__monty__>
Gaelan: So, I'll put you down for a status update in November? Or do you think you'll need more time?
<__monty__>
: >
<Gaelan>
lol
<hexa->
:D
<cole-h>
gchristensen: "class UNKNOWN" lol
<gchristensen>
:)
* gchristensen
adds a very small asterisk
<Gaelan>
NOOOOOO
<Gaelan>
nix on the Pi4 has decided that llvm is lonely and it should compile gcc at the same time
<emily>
Gaelan: time to buy one of those fancy manycore aarch64 servers to build on
<__monty__>
Please tell me cross is an option for aarch64?
<Gaelan>
i don't have a x86 linux machine handy atm lol
<Gaelan>
and darwin->linux cross is Very Broken
<samueldr>
(it could be a linux VM on your machine if it's powerful enough)
<samueldr>
I think there's a thing to do linux builds more gracefully through that hypervisor kit or thingy of macOS
<Gaelan>
yeah
<emily>
idk, is the rpi4 so slow that software aarch64 emulation on x86-64 would be faster?
<emily>
it gets you more cores I guess
<samueldr>
I wasn't thinking about software emulation
<Gaelan>
same number of logical cores, actually
<samueldr>
and... using *user* emulation through qemu-user would be faster, most likely, but not that much of a margin depending on the exact situation
<balsoft>
MichaelRaskin: I've looked at the 2017 act and it seems that only the owners of the infra are accountable.
<MichaelRaskin>
Yes, 2017 is definitely only for those who run services.
<balsoft>
I'm pretty sure self-hosting a VPN qualifies too
<balsoft>
I'm not sure there's any liability for that though (yet)
<MichaelRaskin>
Some of the DO IP address blocks are blocked in Russia
<MichaelRaskin>
NixOS.org resolves to multiple IPs, and some of the IPs are in these blocks
<MichaelRaskin>
(the blocks are officially related to attempts to block Telegram)
<balsoft>
MichaelRaskin: I think in this case it wasn't telegram, one IP I got while randomly digging was blocked because some other site used to host on it
<balsoft>
And that site had some gambling stuff on it
<MichaelRaskin>
DO does sound like the old Telegram blanket-bans
<__monty__>
Ah, so Russia's efforts to undermine the internet?
<MichaelRaskin>
I would say that at undermining the internet Russia had some success by stealing exploits from NSA and publishing them…
<MichaelRaskin>
But also some parts of Russian government try to make Telegram unavailable inside Russia
<MichaelRaskin>
Some parts, because of course some ministries still run official Telegram channels
<__monty__>
Sounds like cognitive dissonance.
<pie_>
who said one government is a coherent single brain
<__monty__>
No one, but it's not as if brains are a coherent single brain.
<balsoft>
__monty__: as with many things here, it's a case of "noone cares enough". Some officials say that Telegram is banned, others say it's allowed and even have official telegram channels.