<bqv>
i have a flake i wanna make, but i don't want it public >_>
<energizer>
is that not supported?
<bqv>
at the very least, it's not ergonomic
<energizer>
information wants to be freeeeee
<bqv>
it's not that i need to hide it, it's that it's a derivation that uses noChroot
<bqv>
so i wouldn't want people to see/use it
rardiol has quit [Ping timeout: 246 seconds]
rardiol has joined #nixos-chat
betawaffle has quit [Ping timeout: 240 seconds]
betawaffle has joined #nixos-chat
betawaffle has quit [Max SendQ exceeded]
betawaffle has joined #nixos-chat
emilazy has quit [Ping timeout: 244 seconds]
peel has quit [Ping timeout: 246 seconds]
emilazy has joined #nixos-chat
betawaffle has quit [Ping timeout: 260 seconds]
peel has joined #nixos-chat
peel has quit [Ping timeout: 260 seconds]
emilazy has quit [Ping timeout: 260 seconds]
peel has joined #nixos-chat
liszt has quit [Ping timeout: 240 seconds]
peel has quit [Ping timeout: 272 seconds]
peel has joined #nixos-chat
liszt has joined #nixos-chat
betawaffle has joined #nixos-chat
emilazy has joined #nixos-chat
endformationage has quit [Quit: WeeChat 2.7.1]
xd1le has quit [Remote host closed the connection]
<Mic92>
bqv: I think fetchTree actually supports submodules
<bqv>
I checked the source a while back, it does, but theres no route to use it from flake paths
<elvishjerricco>
So my Bluetooth headphones have a button to trigger Siri or whatever google's equivalent is called. Is there a way to use this trigger on a linux desktop to trigger a script or something?
<energizer>
maybe with gatttool?
FRidh has joined #nixos-chat
cole-h has joined #nixos-chat
xd1le has joined #nixos-chat
<ar>
i wonder how that's implemented. on my headphones, when i push this button i get a message in headphones saying "the google assistant is not connected"
cole-h has quit [Quit: Goodbye]
<Arahael>
That'd be a driver detail, honestly. And linux tends to have generic drivers.
<bqv>
Libredirect doesn't work on this tiny go app
* bqv
does a filthy mount dance instead
__monty__ has joined #nixos-chat
xd1le has quit [Remote host closed the connection]
LnL has quit [Ping timeout: 256 seconds]
parsley936 has joined #nixos-chat
<Mic92>
mpris-proxy makes the standard headphone buttons work
f0x has joined #nixos-chat
enick_617 has joined #nixos-chat
enick_617 has quit [Changing host]
enick_617 has joined #nixos-chat
enick_617 has joined #nixos-chat
enick_617 is now known as joepie91
bqv has quit [Ping timeout: 260 seconds]
bqv has joined #nixos-chat
MichaelRaskin has joined #nixos-chat
bqv has quit [Ping timeout: 246 seconds]
bqv has joined #nixos-chat
immae has quit [Quit: WeeChat 2.8]
immae has joined #nixos-chat
<infinisil>
elvishjerricco: Run xev and press the button to see if there's any output
<__monty__>
MichaelRaskin: Maybe you remember the discussion about DC power supplies in datacenters? With 12V into the box and then steps down inside? Looks like the new ATX 12VO standard is kinda going the same direction. PSU only delivers 12V and it's steppend down on the mobo. Apparently the efficiency saving can be significant.
<joepie91>
there's been all kinds of sudden noise about 12VO since the LTT video but I have yet to see a breakdown of how much the savings actually are, specifically due to moving the DC-DC conversion out of the PSU
<joepie91>
the LTT video seems to have conflated it with AC-DC to DC-DC conversion
<joepie91>
and it's not clear that they've actually benchmarked it against the correct thing
<__monty__>
Afaik they measured the power usage at the plug?
<__monty__>
At idle.
<joepie91>
like, a random pretty-good ATX PSU against an obviously-top-of-the-line 12VO PSU (since it's a tech demo unit) is not going to be a reasonable comparison
<joepie91>
__monty__: yes but they didn't control for all factors
<joepie91>
they just said "this PSU draws X, that PSU draws Y"
<joepie91>
with no evidence that moving the conversion to the mobo was the only difference
<__monty__>
I mean, that's the manufacturers' only reason to do this afaik?
<joepie91>
for example, does the tested ATX PSU actually do DC-DC conversion? or does it do multiple AC-DC conversion, and could it have been much more efficient without 12VO just by doing DC-DC?
<joepie91>
do more efficient ATX PSUs exist?
<__monty__>
So there *must* be an efficiency difference.
<joepie91>
ie. what factor is the efficiency difference actually attributable to?
<joepie91>
as I am not convinced it's the 12VO part, at all
<joepie91>
<__monty__> I mean, that's the manufacturers' only reason to do this afaik?
<joepie91>
a skeptical computer user might suspect that creating an incompatible standard is a good way to give one's revenue stream a new boost
<joepie91>
by obsoleting existing, otherwise-still-functioning-fine hardware
<__monty__>
Unless it turns out not to be an improvement? Why would people buy it?
<joepie91>
people don't buy things because they are good, they buy things because they're convinced that the things are good
<joepie91>
which is precisely why I am questioning the LTT claims
<joepie91>
because I am not convinced that the perceived improvement actually translates to a real-world improvement
<joepie91>
(as compared to in-PSU DC-DC)
<joepie91>
from a scientific perspective, LTT's benchmark was junk
<__monty__>
Joe shmoe computer user isn't the target customer though. It's OEMs. Why would an OEM put a worse product in their systems?
<joepie91>
that's not what LTT said, they said that OEMs are the initial target market
<joepie91>
and even if it is not more efficient, that does not necessarily make it "worse" from an OEM's perspective
<__monty__>
Note that I never said their benchmark was solid and conclusive. All I wanted to touch on was that the "AC to the box and all conversions in the PSU" paradigm is *indeed* being put into question.
<joepie91>
(plus, don't forget that companies are also regularly fleeced into bad deals)
<__monty__>
I imagine if a Dell gets fleeced they just drop you as a supplier next time around? That doesn't sound like sound business strategy.
<__monty__>
I could imagine mobos including slightly more expensive components because it's a smaller fraction of the cost.
<joepie91>
that's not how it works in practice
<joepie91>
you're assuming large corporate purchasing to be much more rational than it really is
<joepie91>
in practice it's largely politics and under-the-table deals and people knowing other people etc.
<joepie91>
and often it's much more about how well you can sell a given vendor to the management layer, than how good of a deal the vendor is actually offering
<joepie91>
add to that some hubris of those getting fleeced and not wanting to admit that, and wel...
<joepie91>
well*
<joepie91>
it's a popular view that corporations are rational economic actors and are optimally efficient in how they spend their money, but the truth couldn't really be further from that, wastage is extremely common, and there's very little rational about any of it
<__monty__>
My take on it is that it's just the next step in commoditizing PSUs. Make them so simple the supplier hardly matters anymore.
<joepie91>
except now you're just moving the complexity to the mobo
<joepie91>
which is likely to get replaced more often than a PSU
<__monty__>
Yeah but centralized complexity is still an improvement.
<joepie91>
it's not "centralized", it's just moved.
<ar>
i'm not exactly a fan of moving more things to the motherboard. it'll get more difficult to make desktop-class (as in, full pcie16 slot, normal dimm ram) itx motherboards
<__monty__>
That's true. I guess that's a reason for using cheaper components for the stepdowns.
<joepie91>
and it's not an improvement, because now you are moving it away from the specialized manufacturer and towards an industry with an at-best lukewarm track record for power management
<f0x>
another thing I'd worry about is heat, which would then be moved to the motherboard step-downs as well
<f0x>
whereas your standard PSU has its own fan where it matters
<joepie91>
honestly if anything I expect the power management on mobos to be much worse than in PSUs, even if just considering economic forces. mobos have a much shorter life than PSUs, which means that people will be willing to pay less for their power management portion while still having the same expectations, which would translate into worse-quality components and lifespan
<joepie91>
the non-specialization is just an added factor on top of that
<__monty__>
Or it's the PSU companies' way to get consulting fees from mobo manufacturers.
<joepie91>
this might be worth it if the energy savings are considerable, enough to offset the reduced component lifespan from an environmental perspective, but like I said above, I am very much doubting that to be the case :)
<__monty__>
Isn't the energy saving just the efficiency cost of 20-30cm less copper?
<joepie91>
except it will cause much more ecosystem damage than it prevents and wouldn't be very effective to begin with, and all the criticisms to that end are consistently ignored
<joepie91>
this reminds me a bit of the ocean cleanup thing
<joepie91>
"it's for the good of the environment!"
<joepie91>
and there are much better solutions available...
<joepie91>
__monty__: well that is the point, that is unclear
<joepie91>
because the only benchmark I've seen, which is the LTT one, doesn't control for the other factors!
<joepie91>
so there is no way to know whether "less copper" saved 30 watts idle or it actually only saved 1 watt idle and the other 29 is because they were comparing to an okay-ish AC-DC PSU
<joepie91>
and frankly the latter is sounding a lot more plausible to me at this point
<__monty__>
I don't see it as a benchmark tbh. It's just a sponsored video. LTT doesn't do serious benchmarking.
<joepie91>
because it's not like your PSU cables heat up significantly, so how much energy is really getting lost there?
<joepie91>
I just have a hard time believing that 30cm less wire is going to cause 30W of difference
<samueldr>
as I understood on this video: this is for integrators that sell computers that already are borderline uncompliant
<samueldr>
I don't know that we'll see this in the enthusiast segment soon, if at all
<__monty__>
Are there strong reasons for having 3.3V and 5V components actually?
<samueldr>
other than existing standards? good question
<samueldr>
I figure there must be, considering chips seem to tend to go lower and lower
<__monty__>
I can see there being no need for components to be 12V. And some insulation issues. But are there components that just couldn't be designed for 12V?
<samueldr>
e.g. at some points embedded cpus were working off of 5V, then 3.3V, now 1.8V
<__monty__>
True, I think that's mostly the insulation reason because of the distance between the traces?
<samueldr>
so I figure that the SSD must be designed to work off of 3.3V, otherwise it'd need its own regulators and such
<samueldr>
I don't really know why they operate at such low voltages, not an EE expert
bqv has quit [Ping timeout: 272 seconds]
bqv has joined #nixos-chat
<MichaelRaskin>
I think for many types of components lower voltage helps achieving lower power?
<MichaelRaskin>
Re: PSU choice — create an incompatible standard, bribe motherboard decision makers to adopt it for some model lines and market it as the way of the future… OEMs will be happy to push this, this means less upgrades and more entire-box sales
<samueldr>
though 12VO, as demonstrated, seems like something OEMs may dislike, as it adds more failure modes to the motherboards :)
<MichaelRaskin>
Just make sure it survives long enough for warranty to expire
<ar>
12vo also seems similiar to what many oems are doing already
waleee-cl has joined #nixos-chat
<infinisil>
Argh, the more I rate my music the more I realize that ratings are just awful for categorizing music
<infinisil>
But it will take a considerable amount of effort to the system I want (since it doesn't exist yet)
<infinisil>
s/to the/to switch to the/
<samueldr>
infinisil: just import the ratings from someone else
<samueldr>
easy!
<infinisil>
If only music wasn't subjective!
<samueldr>
objectively, music exists :)
<Church->
Heh
<Church->
I mean, that is a statement.
<infinisil>
I've already thought a bit about how to implement what I want
<infinisil>
The main thing I haven't figured out is how I can detect skip's in MPD
<bqv>
You know what'd be cool? Having priority on messages
<bqv>
So people don't get desensitized by you sending them memes
<bqv>
infinisil: I never sit that badly but my partner does
cjpbirkbeck has joined #nixos-chat
<bqv>
Man, I'm just gonna make ipfs suid so I don't have to deal with it breaking permissions constantly
<eyJhb>
gchristensen any US person in gerenal, we agree that if a recipe does not specify hot air or regular oven, etc. regular oven is used?
<eyJhb>
Not sure if it is called "hot air" btw. :P
<bqv>
Air fryer?
<Taneb>
Fan oven?
<eyJhb>
^^ That's the one I assume
<eyJhb>
Just called "Varm luft" in Danish, so took a direct translation without thinking further
<Taneb>
(disclaimer: I'm very much on the right hand side of the Atlantic)
<etu>
eyJhb: Unspecified means regular oven. And then you adapt by lowering the temperature about 20°C than it says if you have the fan oven
<bqv>
ok, so i'm thinking, ipfs, but the pins are declarative
<bqv>
nah, terrible idea...
<ashkitten>
trying to get nixos bootstrapped onto a computer with a single usb port... lol
<ashkitten>
(that is also its only boot medium aside from internal)
<lassulus>
copytoram?
<ashkitten>
i neglected to mention it has no keyboard
<ashkitten>
with which to navigate the bootloader
<bqv>
quite a big detail
<ashkitten>
(which has mouse support, but doesn't let you select boot options with it??)
<lassulus>
build a iso which has copytoram by default? :D
<ashkitten>
yeah i'm just building an image with my ssh key
<ashkitten>
so i can bootstrap it over ssh
<ashkitten>
actually, how can i make copytoram default?
<ashkitten>
i guess i can just edit the grub.cfg directly
<ashkitten>
it's just a bootstrap
<lassulus>
boot.kernelParams = [ "copytoram" ];
<ashkitten>
o
<ashkitten>
right
parsley936 has quit [Remote host closed the connection]
parsley936 has joined #nixos-chat
viric has quit [Quit: leaving]
viric has joined #nixos-chat
<viric>
it seems I'm bad at configuring rspamd
<viric>
I get core dumps
<eyJhb>
I would assume so as well etu ' and always does. But for some reason she caused doubts!
xd1le has joined #nixos-chat
<eyJhb>
So, late night baking then I guess
<philipp[m]>
Argh, since I just spent an hour on this: There is aboslutely no way to specify multiple PathChanged attributes for a systemd.path in nixos, right?
<bqv>
guys, help me square a circle
<bqv>
so the thing i like about ipfs, is that i don't have to worry about file names, and i don't have to worry about hierarchy, because everything is content addressed
<philipp[m]>
Because that would mean you have to have different multiple attributes with the same name in a set.
<bqv>
f0x: the two problems there: firstly, it doesn't solve the issue between me wanting names and not wanting names at the same time, and secondly, ipns is pretty damn broken and unergonomic
<f0x>
lol
<f0x>
yeah I looked at ipfs a while ago but really started using it
<bqv>
i've been using it for pastes for ages now, i'm now migrating my entire system to it
<joepie91>
never*?
<bqv>
i.e. everything that isn't managed through nix, will be either in tmpfs, or ipfs
<f0x>
uh *never yeah
rardiol has quit [Ping timeout: 240 seconds]
rardiol has joined #nixos-chat
<bqv>
haha, solved it!
<bqv>
and a few other issues at the same time..
<__monty__>
You just won't have files outside ipfs?
<__monty__>
*tmpfs?
<energizer>
bqv: how about gitfs
<bqv>
no
<energizer>
i mean it's silly but doesnt it do what you want
<bqv>
no :p
<bqv>
if that was all i wanted, i could just use brig
<bqv>
eh, it still works, and it's backed by a masters thesis
<drakonis>
there's also the likes of git-annex
<bqv>
the point of this is to divide my system into several categories - things manageable by nix, things content-addressible by ipfs, things backed up by online vcs repositories, and things that are entirely ephemeral
<bqv>
all of those are solved except the second one
<bqv>
(so git-annex, gitfs, aren't going to help)
<drakonis>
ah i see
<energizer>
why does it need to be ipfs?
<bqv>
content addressed
<drakonis>
nix will have content addressing soon
<drakonis>
but i dont think that's what you need right now either
<bqv>
yeah, but nix isn't great for plain data
<bqv>
it'd be cool, but then i also run the risk of nix randomly gcing my downloads
<energizer>
isnt brig content addressed?
<drakonis>
brig is unmaintained
<drakonis>
a bummer, really.
<bqv>
it is, yes, because it's backed by ipfs. it's the closest thing to what i'm trying to achieve
<drakonis>
but its agplv3
<bqv>
it does still work, and it doesn't really need much "maintaining"
<energizer>
what's wrong with that
<energizer>
agpl means free
<bqv>
infinisil: i might have a nixus module to make :D
ixxie has quit [Quit: Lost terminal]
<energizer>
or, why not git-annex
<drakonis>
energizer: nothing wrong really
<infinisil>
bqv: Oh what for?
<bqv>
infinisil: ipfs-cluster
<energizer>
or dat
<bqv>
dat isn't content addressed, fyi
<bqv>
not to mention:
<bqv>
> pkgs.dat.meta.broken
<{^_^}>
true
<drakonis>
DAT META IS BROKEN BRUHHHH
<drakonis>
i'm sorry
<drakonis>
not sorry
<__monty__>
What's the solution to your conflict between wanting names and content addressing?
<bqv>
ah, so at least someone was paying attention... turns out ipfs-cluster allows named pins, so i get the benefits of an ipfs name, with essentially the convenience of ipns stable-addressing without all the painfulness of using ipns
<bqv>
not to mention, ipfs-cluster spreads pins out across all machines
<bqv>
so there's a globally tracked "pinset"
<bqv>
i.e. ipfs-cluster just makes managing pins a lot nicer
<bqv>
and, if i use the crdt implementation, it's fully self-contained in the ipfs protocol, and has almost the perfect architecture for a nixus module
<philipp[m]>
Ha! Managed to write a nix expression that sets up a systemd pathchanged watch on all the certificates of my nginx and reloads nginx on any certificate change.
<energizer>
philipp[m]: nice
<bqv>
neat
<Church->
philipp[m]: Reason you don't just use acme and the reloadCmd option? Does the same thing in about four lines.
<makefu>
philipp[m]: make sure to push the changes upstream so everybody has the chance to benefit. I'd love to just 'enable' this feature for nginx :)
<philipp[m]>
Church-: I use dns challenges and they don't work in the same container.
<__monty__>
Guess I need to read about ipfs pinning and ipns tomorrow.
<philipp[m]>
So I can't even do postRun stuff.
__monty__ has quit [Quit: leaving]
<philipp[m]>
makefu: I'll clean it up and work on that.
<Church->
philipp[m]: You're running nginx in a container? Or LE?
<philipp[m]>
Both, actually.
<Church->
Ah, any reason you don't just use the nixOS modules?
<Church->
Already a solved problem technically. :P
<philipp[m]>
What problem is solved? Having certs just appear for nginx and nginx reloading accordingly?
<Church->
Yep
<philipp[m]>
How?
<Church->
So we have the security.acme module for LE certs, supports DNS challenges already. And there's a postRun style option for running commands after you reload a cert. So I just `systemctl reload nginx` in there. Done.
<Church->
This of course assumes you use the nixOS nginx module
<philipp[m]>
Only works if both are in the same container.
<philipp[m]>
I don't want nginx to be able to generate certs. nginx gets a read only mount of the certs it needs and that should be enough.
<Church->
Are you running nixOS in a container? I have mentioned using the native modules a few times, no container usage at all
<Church->
Yes? Nginx doesn't generate the certs this way
<Church->
Got it, I figured as much. Was just wondering why run in containers and come up with this new way to do a thing when there already default modules for both nginx and LE
<ashkitten>
ugh why does qt virtual keyboard only work with qt apps
<ashkitten>
i'd really like to be able to use it in firefox
<ashkitten>
instead of messing around with onboard or something
<ashkitten>
just by idk, clicking a thing to pull up the keyboard even
ottidmes has joined #nixos-chat
slack1256 has joined #nixos-chat
bridge[evilred] has quit [Remote host closed the connection]
slack1256 has quit [Ping timeout: 256 seconds]
bridge[evilred] has joined #nixos-chat
parsley936 has quit [Remote host closed the connection]