<emily>
I honestly just strung together nix words and only after the fact realized that it sort of sounds like something you could legitimately call this
<infinisil>
How about just envDrv
<emily>
I think that just proves my point
<infinisil>
Or envDerivation
<clever>
i think you could get away with just .overrideAttrs (old: { buildCommand = "env > $out"; })
<emily>
wish "derivation" was a shorter word
<clever>
that would likely root everything it depends on at build time
<emily>
oh yeah, using overrideAttrs would probably be a good idea I guess
<emily>
rather than the derivation (drv.drvAttrs // ...) thing
<clever>
as long as they havent messed with builder
<cole-h>
To the people who I was preaching to about pipewire last night: I was wrong. I still have to run `cadence-session-start --system-start` for jack audio, even with the socket enabled :(
<emily>
oh hey I was meaning to try pipewire
cole-h has quit [Quit: WeeChat 2.7.1]
cole-h has joined #nixos-chat
cole-h has quit [Quit: WeeChat 2.7.1]
cole-h has joined #nixos-chat
waleee-cl has quit [Quit: Connection closed for inactivity]
drakonis_ has quit [Read error: Connection reset by peer]
<ashkitten>
cole-h: does that start a separate jackd or does it just dbus-activate a pipewire component?
<lovesegfault>
HALP
<lovesegfault>
Someone asked for my consulting rate
<lovesegfault>
florb it, I'm saying my rate is $150
<Church->
An hour?
<lovesegfault>
Church-: yes, but it's for only one hour
<lovesegfault>
it's not a long consulting gig
<cole-h>
ashkitten: Truthfully, idk. I just `cadence-start-session --system-start` and get audio working which makes me happy
<ashkitten>
hah
<cole-h>
If I had to guess, I'd say it's unrelated to pipewire at all, because I wouldn't get audio without running that
<ashkitten>
valid
rardiol has quit [Ping timeout: 258 seconds]
<colemickens>
@cole-h I mostly use `mv`/`rm`/`cp`, sometimes `nautilus`, very rarely `ranger`.
<cole-h>
colemickens++, thanks. I'll stick with nautilus too. Was wondering if there were any better options :)
<{^_^}>
colemickens's karma got increased to 13
<cole-h>
(I prefer the GUI filemanagers when moving large batches of files to my externals)
<colemickens>
sounds like a good use for rsync --dry-run and then a trusty repeatable script
<colemickens>
/preach
<colemickens>
:P
<colemickens>
There's probably better ones, I just have "muscle memory" with nautilus I guess. I used to prefer Dolphin's column view but I think I might be the only person on earth, other than the designer, who did.
<lovesegfault>
I like the pantheon one
<lovesegfault>
pantheon-files or w/e it's called
myskran has joined #nixos-chat
myskran has quit [Ping timeout: 255 seconds]
cole-h has quit [Ping timeout: 255 seconds]
<eyJhb>
I normally use mv/rm/cp and ranger quite often
<eyJhb>
I haven't gotten the hang of all the shortcuts in ranger.. Should really do that
<eyJhb>
At some point ranger was at mod+e, but I guess I unbound that shortcut
<MichaelRaskin>
infinisil: aanderse: I switched to the old notification UI immediately. The new one looks like a broken IM more than like a broken email viewer with some case-specific features, which I find a step back
<infinisil>
MichaelRaskin: Give the new one a try if you have some spare cycles, if you have a lot of notifications I really find it much better
<eyJhb>
infinisil: which program are you discussing?
<infinisil>
eyJhb: New github notifications
<eyJhb>
Ahh, I like it better than the old one
<eyJhb>
But I myself don't use Github that much anymore, mostly on Gitlab now. But I hate their layout for things..
<MichaelRaskin>
I am subscribed to everything, but I skim the full stream as emails and use the GitHub UI to not miss anything in Participating (or to review PRs). I tried it for a single pass through new Participating mentions and found this horrible
<MichaelRaskin>
Gitlab loves JS too much
<MichaelRaskin>
So does the new GitHub notifications UI…
<infinisil>
I only got to love it after a couple days or so fwiw :)
<infinisil>
Found it really confusing at first
<MichaelRaskin>
It pattern-matches to too many other garbage UIs for me
<MichaelRaskin>
I found it annoyingly dynamic where it should not be, not confusing
<infinisil>
The confusing part for me was the paradigm shift: that now "Unread" notifications are not "Done", instead you're meant to look at them later again. Previously Unread meant Done
<__monty__>
I don't like the new UI. The seperation into groups by org/repo is way more useful to me.
<MichaelRaskin>
You mean «Read», right?
<infinisil>
Oh yeah
<infinisil>
Unread (new) => Read (seen it, but have to do something with it) => Done (no action needed from me as of now)
<eyJhb>
MichaelRaskin: generally the world loves JS too much
<MichaelRaskin>
I sort y emails as unread/deferred/pending-batch/read+done, so this part was pretty natural and who cares about labels
<infinisil>
__monty__: The new UI has that though?
<infinisil>
And above reason is why they have the "Mark all Unread as Done" thing (because previously Unread meant Done)
<__monty__>
infinisil: No it doesn't it's just a huge list of garbage.
<__monty__>
I don't want my workflow to require *extra* clicks for something the old UI just always did.
<infinisil>
__monty__: I'm pretty sure I require less clicks now
<infinisil>
What's garbage?
<__monty__>
Mark all read as done? You're not making any sense. How has unread ever meant done?
<infinisil>
Oh damn, I meant Read again
<MichaelRaskin>
I do not believe in a workflow that requires strictly less clicks in the new UI
<infinisil>
Previously *Read* meant Done, so they have a button to mark all Read as Done
<infinisil>
Well whatever you think of it, I'm loving it, and I'm much faster with the new UI with less pain involved. It's especially better if I look at many issues but can't respond to them immediately
<MichaelRaskin>
True that in my case it would have a high chance of being handled at the email level before even reaching the browser UI
<__monty__>
infinisil: I switched back to the old UI because the new one is a huge list of all your notifications. The old UI has notifications grouped by repo, NixOS/rfcs is a block, NixOS/nixpkgs is another block, etc.
<__monty__>
And this is without *any* clicking past going to the notifications page.
<infinisil>
__monty__ Did you use the "Mark read as done" button?
<infinisil>
This should "clean" your notifications list so it shouldn't be huge anymore
<MichaelRaskin>
Old UI is also almost OK to use with no clicking
<MichaelRaskin>
(keyboard-driven)
<__monty__>
infinisil: I don't care about that part. What I care about is having notifications grouped rather than chronological. Some repos I need to be on the ball. Others can just accumulate notifications until I have some time.
<MichaelRaskin>
Which is a typical common property for Web UIs that do not go into the crazy-blinking area
<infinisil>
__monty__: Hm I see, I guess the new ui doesn't have that as of now year
<__monty__>
And marking something unread was fine for me if I opened a notification I couldn't act on yet. I definitely don't want to have to explicitly mark anything as done.
<__monty__>
I've submitted feedback already, gonna stick with the old one for as long as I can.
<infinisil>
__monty__: Oh actually the old Ui was very bad for a similar reason you mentioned: I often had dozens of nixpkgs notifications. And because they are mostly more recent than other repos, all issues from other repos would usually be way down in the page
<MichaelRaskin>
Page down and sometimes End worked well enough for me
<__monty__>
infinisil: If your notifications were already basically a huge list I can see liking the new UI. That's not the case for me though. But again, comes down to chronology having nothing to do with relevance : >
<infinisil>
__monty__: And the read->done thing, I just quickly went through my opened issues to see which should be marked as Read again. Was really worth it, now I have a clear distinction between Read and Done
<__monty__>
I don't like explicitly marking stuff as done. I'd much rather have it the other way around like now.
<infinisil>
__monty__: The idea is that once you click on an issue, you can use the top bar to select the action and return to the view in one click
<__monty__>
Yeah, don't like it. I open all the issues I want to handle in tabs as a sort of work queue. I don't want to have any actions past that required to mark them as done.
<infinisil>
So where previously I would click the issue, if not done yet go back to the notifications view, search for the issue (awful!), and mark it as unread again
<infinisil>
Now it's just one click
<__monty__>
infinisil: That's why you open issues in a tab. That way you don't have to look for anything to mark as unread.
<MichaelRaskin>
So basically the new UI is for people who don't know how to use tabs?
<MichaelRaskin>
Makes sense, MS never liked tabs in browsers
<infinisil>
It's very easy for me to lose a tab, i have dozens of them
<MichaelRaskin>
In which window?
<__monty__>
I could see it work much better as a single window sure. But I don't like that. Tabs are great, you can shift them around as much as you want, you have an instant indication of how many things there are left to do and you can do whatever you want with them with the keyboard.
<__monty__>
infinisil: I never have fewer than 40 open tabs on average. I've never lost a tab.
<infinisil>
Organizing tabs is more work for me than what the new ui does
<__monty__>
I think we should report infinisil for neglectful tabbing.
<__monty__>
Another awesome thing about tabs is they work across the entire web, github, gitlab, launchpad, bitbucket, twitter, facebook, discourse, etc. ad infinitum.
<infinisil>
Well whatever, I like the new UI, it makes the experience much better for me :)
<__monty__>
The new github notifications only work with github.
<MichaelRaskin>
This reminds me the monitor brightness story. Around 100% of new monitors and laptops are sold configured _crazy_ too bright. So now half the garbage designer advice tells to use low-contrast colours to compensate for misconfigured monitors by eating brightness via gray background. Just to make sure it is more annoying for the rare people with properly configured monitors
<__monty__>
You are the enemy now, infinisil, they will never fix it if you go around liking it -_-
<infinisil>
:P
<__monty__>
Oh, I 100% agree, how bright a monitor gets is almost irrelevant to me. How *dark* it gets without turning off is *so* much more imporant.
<__monty__>
Unpatchable intel exploits? How do computers even work...
<MichaelRaskin>
I actually like black text on white, I just think that an ideal monitor config has a similar brightness and contrast to a white printed sheet of paper
<MichaelRaskin>
That is actually easy with LCD than with e-«paper», just requires paying attention
<MichaelRaskin>
Meh, unpatchable Intel exploits are in TPM, the more this garbage gets discredited the better
<__monty__>
I actually mentioned to someone with a macbook pro I thought it was weird the screen automatically got *brighter* when the environment got darker. They didn't understand my confusion. "Of course you want more light when it gets dark."
<MichaelRaskin>
Willing Mac users? What do you expect from them
<__monty__>
This was Lion-era macOS. Snow Leopard wasn't forgotten yet so it was a pretty good platform back then.
<__monty__>
And to their credit they've fixed their shit on iOS for ipads at least.
<__monty__>
The display still doesn't go dark enough but at least it's better than it was.
<MichaelRaskin>
I dunno, I had respect for Apple (although never willingness to use this) until seeing iPhone (the first one)
<__monty__>
Well, not everyone can/could (at the very least) use linux.
<infinisil>
__monty__: MichaelRaskin: A request regarding the notification discussion: Please don't make personal remarks because of my opinion, even ironically. That would be nice :)
<MichaelRaskin>
Yep, sorry, I did not depersonalise enough some of the remarks, my bad.
<infinisil>
<3
<MichaelRaskin>
__monty__: I think by the time Apple had abandoned the aim for high quality without space for doubt (as they did with iPhone), Mandrake was already as easy as possible if you require some level of transparency from the system.
<__monty__>
I definitely don't agree. Linux is still not as easy to use as windows or macOS. Simply because the other two come pre-installed.
<MichaelRaskin>
… and I have seen quite a few weird situations where Apple stuff is broken and cannot be usefully traced while anything else just works…
<__monty__>
You need someone who kinda knows computers before you can realistically use linux imo.
<__monty__>
For any power user linux is definitely more usable. But that's an exceedingly small percentage of users.
<MichaelRaskin>
We never called portable video players computers before, and I see no reason to start now
<MichaelRaskin>
And the story about brightness of the cinematic screen in darkness is different from the story about screens used to process information, sure
<MichaelRaskin>
I care about computers, and however I dislike Windows it still makes more sense as a computing OS than whatever Apple does
<__monty__>
I'm not sure I agree. You don't use OSX at that point, you're using the underlying BSD and that's decent.
<MichaelRaskin>
I guess it doesn't help that whenever I am shown some Apple GUI I find something in it approximately as aesthetically pleasant as the sound of a microfoam block being torn.
<MichaelRaskin>
And at some point I saw some completely unbelievable WiFi compatibility issues on macOS which I couldn't conceptualise better than «nah, your Ubiquity WiFi AP is not to my liking»
<eyJhb>
MichaelRaskin: Well, I have never really used Mac except the time I had a Mac and I removed Java in some way. And you cannot/could not install Java again, because installing something on Mac requires Java.
<eyJhb>
But I like the underlying BSD, which is why I am considering changing my work PC at LEGO for a Mac
<__monty__>
eyJhb: That's not true. Maybe adobe's java installer is written in java? Which is ridiculous and wouldn't work on any platform if you removed java...
<__monty__>
Java is not at all integrated into OSX.
<__monty__>
Look into the various issues re catalina and nix before switching. Still better than the total lack of support on windows but definitely a bummer.
<MichaelRaskin>
Well, when we had cygwin support, it worked, and got abandoned for lack of interest, not because of OS changes. Now you can just install in WSL.
<__monty__>
But that doesn't allow any of the Nix*OS* functionality, does it? As in you can't configure anything about windows using those? Nix-darwin gets close to NixOS level of declarative config.
<MichaelRaskin>
Last when I used Windows a lot, everything not strictly tied to Windows was inside coLinux…
<MichaelRaskin>
I mean, I don't use mainline NixOS anyway (although I do use NixOS-generated xorg.conf and Nixpkgs kernel)
<eyJhb>
__monty__: it is a LONG time ago
<eyJhb>
PowerBook long time ago. Couldn't do anything
<aanderse>
ma27 you around?
<__monty__>
eyJhb: Doesn't matter, java has never had any integration with OSX. It's actually pretty second class. Saw someone complain about java performance on OSX a day or two ago.
<eyJhb>
__monty__: Can't tell you much other, than it complained about not having Java and so I couldn't install anything, and I couldn't get Java installed because Java
<eyJhb>
But I was also smart and ran a `sudo find . -name '*java*' -exec rm {} \;` basically
<eyJhb>
Also, side-note nothing to do with anything. In HBOs Silicon Valley and they have tabs/space wars, I hate that they show the person using spaces presses space 4 times each time
<gchristensen>
that is why tabs are better
<MichaelRaskin>
Because movie people lie?
<gchristensen>
b/c sometimes you're in an editor where Tab doesn't do the right thing so you spc-spc-spc-spc-spc-spc-spc-spc-spc-...
<MichaelRaskin>
I mean, they are better, but I also don't like being on the same side as Hollywood
<infinisil>
Switch to spaces and demand 8.6% more salary!
<MichaelRaskin>
More like, search for a space-using company, they are desperate enough to pay 8.6% more
<gchristensen>
the real reason Nix settled on spaces comes out...
<eyJhb>
Forced to used tabs in Golang :(
<eyJhb>
Or "forced"
<__monty__>
gchristensen: If tabs are better then why not use variable width fonts as well? ; p
<gchristensen>
uhoh
<MichaelRaskin>
Because too few editors support proper adaptive tabs that well
mrCyborg has joined #nixos-chat
<__monty__>
What I find annoying about the tabs v. spaces debate is people never seem to want to admit what they're *actually* arguing. Usually they dislike alignment. In very few cases it's because they don't know a tab can insert spaces, i.e., they literally think people go spc-spc-spc-spc-spc-spc-spc-spc for two levels of python indent.
<__monty__>
Exceedingly rarely it's because they like a specific tab-width that's different from the default of 8 or the common 4-space indentation people use.
<eyJhb>
OR! spc-spc-spc-spc
<eyJhb>
But what about the filesize?
<eyJhb>
Also, I like not having to deal with.. Is it 2? Is it 4? Is it 8? What is it?
<eyJhb>
tab -> one indent, tab-tab -> two indents
<__monty__>
If that's an actual concern you should compress your files in which case spaces compress better because they're a more common character : p
<MichaelRaskin>
__monty__: it is actually enough to like a specific tab width even if it is 4 or 8, because, you know, both happen
<eyJhb>
Especially when it comes to PYTHON, F that
<andi->
I don't like spaces vs tab debates and I do not like the meta-discussions around that... :D
<MichaelRaskin>
What do you think about meta-discussions about meta-discussions about various code formatting issues?
<mrCyborg>
I just think gofmt has the right idea
<andi->
Isn't that just some setting in your editor and that translates to whatever the norm on the current project is? *shrugs*
<eyJhb>
mrCyborg: Love gofmt/goimports, awesome just running it
<__monty__>
MichaelRaskin: No, tabs only make sense if *your* preference specifically deviates from the width projects use. And if you really want to you can have leading spaces scaled as well.
<MichaelRaskin>
That's true
<andi->
For me the `tab` button is more like `please indent another level` whatever that means is up to people that like debating that.
<eyJhb>
andi-: same, but it is just when editing new code
<eyJhb>
It is sometimes hell when working with e.g. Python
<andi->
The solution to that is very simple
<MichaelRaskin>
__monty__: it is easier to scale tabs if my preference actually varies as I go along a file
<__monty__>
MichaelRaskin: That's a very peculiar workflow from what I've heard. So peculiar I'm fine with it warranting a plugin, at which point the character that's used for indentation doesn't matter.
* mrCyborg
is enjoying his popcorn
<__monty__>
I'd probably prefer automatic formatting. Problem is that very few languages have decent formatters.
<__monty__>
So you can't say "Obviously the solution is gofmt."
<mrCyborg>
Exactly. I personally feel like tabs for indentation, spaces for alignment is the best solution. Even if that means you are using both tabs and spaces on a single line.
<mrCyborg>
But this is very tricky to do without something like gofmt
<mrCyborg>
So without a formatter I would either use tabs and not align at all. Or use spaces
<__monty__>
That's always been worst of both worlds imo. It's fine in theory but it's so easy to mess up when you start changing indentation levels.
<mrCyborg>
Which is why it should only be done with a proper formatter
<__monty__>
Yes, we're in agreement on that.
<__monty__>
If only the default indentation level for tabs was equivalent to 2-4 spaces I think there'd be less discussions about the whole thing. 8-space indentation levels are just too much.
<__monty__>
Sure but how often are tabs still used for plaintext tables?
<MichaelRaskin>
By me? reasonably often (but usually set to display wider than 8)
<mrCyborg>
Tabs shouldn't be used for tables IMO
<MichaelRaskin>
And my point was that tab could not be 2-space at the start
<mrCyborg>
A tab should be used for one thing: indentation. And the tab-size shouldn't matter for the readability of what you are writing. When you are aligning (tables for example) spaces should be used.
<__monty__>
MichaelRaskin: I understand the argument. I'm just saying indentation of code is probably by far the main use case at this point.
<gchristensen>
tbh this is such a boring discussion
<__monty__>
No one's obligated to read or participate : )
<gchristensen>
good point
<MichaelRaskin>
Feel free to start a different flamewar, too!
<__monty__>
I'm up for discussing how to make NixOS nicer to use on low-power hardware though : )
<gchristensen>
delete all the options
<gchristensen>
evaluate and build on anothermachine
<__monty__>
So, nixops?
<mrCyborg>
__monty__: Some decent documentation on how nvidia optimus actual works on nix would be nice :P I basically gave up at this point
<MichaelRaskin>
Move to Nixpkgs configuration model!
<__monty__>
MichaelRaskin: Would that work? Note that this machine can barely get firefox-bin installed and when it works it takes hours.
<MichaelRaskin>
Hm, then I guess you do indeed an external builder
<MichaelRaskin>
And just nix-copy the resulting system, I guess
<__monty__>
That's so unfortunate though.
<adisbladis>
__monty__: Or more simply `nixos-rebuild --target-host=`
<__monty__>
I already use remote builders btw.
<MichaelRaskin>
Hmm. I wonder if wrapping evaluation in a build and pushing to a remote builder could make sense in some way
<__monty__>
I'm thinking mostly about the scenario of places where hand-me-down laptops are basically the only available computing devices.
<MichaelRaskin>
Hand-me-downs should not take hours to install firefox-bin…
<__monty__>
adisbladis: That's a way to get a machine to build a configuration for another machine's store?
<gchristensen>
is this your 1GHz Pentium laptop?
<__monty__>
Yeah
<gchristensen>
lol
<gchristensen>
yeah that is hard
<adisbladis>
I would not wanna run an eval on one of those :P
<gchristensen>
at that point I would recommend going getting a Raspberry Pi instead
<MichaelRaskin>
Just eval of firefox-bin closure already sounds painful in that case
<adisbladis>
__monty__: Well you'll also need --build-host, but yes
<__monty__>
And no one's concerned/cares that the apt/yum or even gentoo's ports approaches to packaging absolutely embarrass nix in such a scenario?
<gchristensen>
not really
<gchristensen>
not me anyway
<__monty__>
That's too bad.
<gchristensen>
Nix makes trade-offs in terms of CPU, RAM, and Disk in order to make systems more stable and reliable. they're trade-offs
<MichaelRaskin>
I actually have a script that would effectively give you a bit better than apt situation
<MichaelRaskin>
A script that scrapes hydra for a named package's latest succesful build, then fetches it
<MichaelRaskin>
Does zero Nix evaluation
<__monty__>
gchristensen: I don't buy that the problem nix solves requires serious computing power though. More diskspace absolutely. But what part of what nix does is computation intensive? Some hashing?
<MichaelRaskin>
Overridability
<MichaelRaskin>
If you do not need it — scrape Hydra, copy from cache
<__monty__>
MichaelRaskin: What's the advantage over imperative approaches like apt if you do that though? That packages come with the right dynamic libs?
<MichaelRaskin>
You can still grab a previous version if needed without going through a horror, and yeah, way way less chances for a package conflict
<__monty__>
That's a good step in the right direction but it's too bad you have to give up so much of the advantages for that.
rardiol has joined #nixos-chat
<__monty__>
Why does evaluating all-packages take so long, for example? In a lazy language I'd expect it to be almost as fast as just reading the file from disk.
<yorick>
__monty__: none of us have the time to fight Wirth's law when buying better hardware is cheaper
<MichaelRaskin>
Evaluating all-packages means evaluating everything in all-packages?
<yorick>
__monty__: evaulating by attribute is fast
<MichaelRaskin>
Evaluating a specific package just requires evaluating its closure, and proper clean bootstrapping of stdenv takes some layers
<yorick>
evaluating all of all-packages is slow since it's 11k packages
<MichaelRaskin>
Evaluating all-packages.nix should be pretty fast, it should error out quickly
<gchristensen>
haha
<__monty__>
I guess it's a bad example.
<__monty__>
Let's take firefox-bin instead.
<MichaelRaskin>
gchristensen: don't laugh, it were you who talked me into committing this!
<gchristensen>
MichaelRaskin: it was a good choice!
<__monty__>
Isn't it just download and extract the executable?
<gchristensen>
__monty__: I don't know, it sounsd like it'd be useful for you to investigate the slowness, do some profiling, and determine what is slotw
<MichaelRaskin>
Erm, also evaluate the build instructions for stdenv, gtk, etc.
<__monty__>
I'd love to but I don't have the expertise to know what to do.
<gchristensen>
sounds like a great learning opportunity :)
<MichaelRaskin>
Some hope that after the Flakes epic converges, caching of stuff like stdenv evaluation could be improved
<gchristensen>
MichaelRaskin: yeah, very plausible!
<MichaelRaskin>
(Although it might still be updated ~monthly…)
<__monty__>
Well why do you think I keep bringing it up? I'm hoping for someone to come along and be "That's probably... Verify whether that's true by running strace on command x and focusing specifically on y calls."
<MichaelRaskin>
Evaluate firefox-bin, look at all the dependencies, and try evaluating dependencies and checking the time…
<MichaelRaskin>
If it is linear, then it is just general doing-too-much in the flexible/overridable/universal Nix code
<__monty__>
And which command should I be looking at to get at the derivations, nix build/run/repl, nix-instantiate?
<MichaelRaskin>
nix-instantiate
<__monty__>
Hmm, can I pass allowUnfree using --arg? I guess that passes it to the expression, which is not what I want?
<infinisil>
--arg config '{allowUnfree = true;}'
<infinisil>
(in the nixpkgs root)
<__monty__>
Ah, or --option I guess?
<__monty__>
Or not...
<__monty__>
Oh, because nix options aren't nixpkgs options.
<eyJhb>
Well.. I just found a SSRF bug on a fairly big website
<eyJhb>
Including LFI
<__monty__>
I'll try the var cause the --arg complains about unexpected =.
<__monty__>
Oh, boy. Derivations aren't exactly very legible. Why can't I `--expr firefox-bin.buildInputs`?
claudiii has joined #nixos-chat
<MichaelRaskin>
I guess nativeBuildInputs could be (in the non-cross-compilation case) useful
<__monty__>
I think I'm just passing it wrong. I need --eval because the result is obviously not a derivation. But then it complains about the variable not existing.
<MichaelRaskin>
Maybe I am mixing up how it is called in the derivation…
<__monty__>
I guess what I'm trying to do doesn't even work because the list of buildInputs isn't very useful. I want the list of derivation paths.
<__monty__>
Right?
<infinisil>
__monty__: What exactly are you doing?
<infinisil>
Or trying to do?
<infinisil>
Probably better for #nixos though
<MichaelRaskin>
Well, you can take the drv path and do nix-store -q --references …
<MichaelRaskin>
(and also -qR for the closure)
<__monty__>
Oh, guess that's perfect.
<MichaelRaskin>
Then I guess you need to guess attribute names to instantiate them
<__monty__>
I'll ask in #nixos if I have more questions. To instantiate these derivations I can just pass the path to nix-instantiate? Oh, that doesn't work?
<infinisil>
I have this patch somewhere that adds something like pkgs.hello.attributePath, which would output "pkgs.hello" (or similar)
<__monty__>
Oh, the closure's only 1300 derivations, what fun... : (
<MichaelRaskin>
That should be a part of the explanation why it takes so long, though
<__monty__>
It'd be awesome if nix could take some pointers re profiling from shake.
<MichaelRaskin>
Now we have HTML5 unversioned living standard (this sounds bad already) of infinite and still growing size
<__monty__>
Hmm, I didn't expect these things to complicate the code so much.
<__monty__>
Figured all the rendering and such was the hard part.
<gchristensen>
!
<MichaelRaskin>
It's just _more_ code, many times more
<MichaelRaskin>
O-ohh, rendering
<MichaelRaskin>
Observe that in the last ten years browsers moved to multiprocess model
<MichaelRaskin>
To better use multicore (only harmful for you)
<MichaelRaskin>
And also because they are adding JS APIs faster than they think so they try to kind of isolate stuff because it is just too hole-ridden
<__monty__>
Oh, didn't expect Firefox 1.0 to have been released within the natural lifespan of this box.
<MichaelRaskin>
(I am not exactly fond of the modern Web mess, no)
<MichaelRaskin>
Well, 1.0 was more of a marketing milestone
<MichaelRaskin>
Firebird/Phoenix versions were pretty similar
<__monty__>
Any alternative browsers you'd suggest? Something like Qutebrowser, or Midori?
<emily>
adisbladis: I migrated my SSH keys to be the new fancy FIDO2 ed25519 keys, stored on my YubiKey
<emily>
which only ssh-agent supports the key type of (sk-ssh-ed25519@openssh.com)
<emily>
but github doesn't support it... so I also have an ed25519 openpgp key on the same card for "legacy" ssh :(
<emily>
(you can use openpgp keys as regular ssh-ed25519 keys; not so for FIDO because it uses a more restrictive protocol)
<srk>
:D fun. I've stopped using gpg-agent-ssh as it wasn't able to prompt for key when connected over ssh
<srk>
it's private key handling is weird as well, why it needs to import keys..
<srk>
s/it's/its/
<adisbladis>
emily: Ahh, cool.
<adisbladis>
I haven't toyed around with the new key types yet.
<emily>
logins are so fast now ^^
<emily>
compared to my old 4096-bit RSA OpenPGP key
<emily>
the key starts blinking about as soon as you enter the ssh command, and the delay between tapping it and being logged in is pretty low too
<adisbladis>
emily: I switched to a 2048 bits key because of the shitty performance with 4096 bit keys
<adisbladis>
git rebase was _painful_
<emily>
for commit signing?
* emily
hasn't started doing that yet, but set up the keys with an eye towards doing so this time
wildtrees has joined #nixos-chat
<emily>
I think my workflow will be "leave everything unsigned until right before push", honestly.
<emily>
then I can at least just do a bunch of tapping in one go. (or enable the tap timeout thing.)
<adisbladis>
emily: Yeah
<__monty__>
I use ed25519 keys too. Crypto professor warned us to be wary of ECC and GCM though : /
<Church->
Hmm, nfs in nixOS is great. Think I'll definitely use it for my NAS
<__monty__>
Noticeable improvement over other things?
<Church->
Eh just ease of setting it up client/server wise
<Church->
I have plenty of faults I've found with nixOS but nice and simple stuff like this is always a breeze
<Church->
Long as I don't look at the underlying details, there be dragons there no doubt
abathur has quit [Ping timeout: 256 seconds]
abathur has joined #nixos-chat
myskran has joined #nixos-chat
<eyJhb>
Church-: what about HTTP? :D
abathur has quit [Ping timeout: 255 seconds]
<Church->
heh
<eyJhb>
When I need to transfer files, I often fire up python -m http.server
<eyJhb>
(if it is on a computer that doesn't have ssh access)
<slack1256>
Has anyone configured tmux to emit a BELL sound from to the Desktop environment?
<slack1256>
I keep misssing my irc message because of this.
waleee-cl has joined #nixos-chat
<__monty__>
slack1256: Set visual-bell to "off" or "both"
<slack1256>
__monty__: This seems not enough, I need to set up a hook it seems.
<__monty__>
I don't think it should. Are you sure your terminal beeps when it receives a bell?
KeiraT has quit [Ping timeout: 240 seconds]
<gchristensen>
in jq, is there a way to know if a value is in an array? like | jq -r '.facilities | map(.id) | .[] | select(is the value from the previous step in $ids))' --argjson ids '["foo", "bar", "baz"]'
KeiraT has joined #nixos-chat
<LnL>
probably, you can do pretty crazy things with it
<eyJhb>
gchristensen: do you need to check if it is in a array inside jq? What is the use-case
<gchristensen>
I have a list of facility IDs, and a list of facility objects { "id": "...", "code": "..." } and I want to get the code for each ID I'm interested in
claudiii has quit [Quit: Connection closed for inactivity]
<gchristensen>
their rules look good
<cole-h>
srk: btw I was able to get gpg-agent ssh keys to prompt for my password when connected over ssh with a small workaround (if I'm understanding you correctly)
<cole-h>
I made a small pinentry wrapper that reads an env var I set in my (interactive) shell init, and if so calls out to my GUI pinentry (pinentry-gnome3)
<cole-h>
Otherwise, it falls back to pinentry-curses
<lovesegfault>
I recently got gpg-agent forwarding working
<lovesegfault>
samueldr: I'm having trouble building nixpkgs.git on aarch64 :(