<energizer>
`sensors` says `Adapter: ACPI interface temp1: +16.8°C (crit = +20.8°C)` isn't 20.8C/69.4F that a little low for a critical temperature?
<energizer>
also why is it so cold in there, it's way warmer in this room
<abathur>
it should probably use fifos in the longer term, but I was leery of getting bogged down trying to replicate what gitstatusd does or roll my own
<colemickens>
__go_on_now_lilgit :P
<colemickens>
bbigras: was it you that mentioned filing an issue on starship? Did you end up doing that? Someone in that project would likely be most motivated to port this over to Rust
<abathur>
not sure how much info they extract, keeping it pretty minimal does play a big role
<abathur>
earlier on I was trying to use the diff/status features in pygit2 and they were a good way to blow through a few hundred ms
<colemickens>
right right, they already support more features than the dirty/branch, so,...
<colemickens>
yeah, I saw the comment, would be fun to see a profile of it
<abathur>
though I assume you can convince people who have to work with big repos that a few hundred ms per command isn't a good trade for an exact ahead/behind count
<abathur>
or whatever
supersandro2000 has quit [Disconnected by services]
supersandro2000 has joined #nixos-chat
<abathur>
I can also probably be convinced to make it a little slower for good reasons, especially if a rust/go translation shaves off some more time, it's already a good 5-10x faster than I thought I even imagined being able to achieve
<colemickens>
maybe if I fix nixpkgs-wayland I'll treat myself to some rust and play with gitoxide
rajivr has joined #nixos-chat
elvishjerricco has quit [Ping timeout: 264 seconds]
elvishjerricco has joined #nixos-chat
lunc has quit [Ping timeout: 272 seconds]
<bbigras>
colemickens: do you mean fill an issue to make them consider using gitstatusd?
<bbigras>
mjlbach: any reason you prefer p10k? just curious
<aterius>
I find the prompt snappier
<aterius>
Just generally less laggy, instant prompt is kinda cool
<aterius>
I'm not a configuration-phile so I just switched one day and didn't A/B test
<bbigras>
gotcha. thanks
<colemickens>
last time I tried them out I tried pure too, still wound up back on p10k
<bbigras>
thanks. I'll try p10k. I'm mostly curious how fast prompts can be. and would like for starship to keep up
<colemickens>
I wish nix would keep a big file in /nix somewhere that it can delete if it needs to
<colemickens>
nix-collect-garbage -d fails if you're out of space
<lovesegfault>
colemickens: is that still true?
<lovesegfault>
I thought that had been fixed
<colemickens>
I just hit it on my PBP. I had to SSH in and delete a source code dir to get nix-collect-garbage -d to actually start freeing space
<cole-h>
It's definitely still true, despite having an 8MB file in /nix/var/nix/db/reserved (I think that's the file it's supposed to delete to free up space)
<aterius>
bbigras: there's an issue on the starship tracker in which the author of p10k commented on the performance limitations of the current design for starship
<aterius>
I'll check back in a couple years and see how it's going :P
<infinisil>
It's definitely *not* the first of april
<abathur>
like change you find under the sofa cushions, but made of chicken, and in your computer
<infinisil>
Lol
<infinisil>
I now feel bad because a shitty KFC console detracts from the really interesting and well-written article about how the Pfizer vaccine works
<abathur>
as it should be
<infinisil>
No!
<abathur>
I mean more like: this is our fate, and less like: this is just
<infinisil>
I'd like to sign up our universe for one change of fate please
<gchristensen>
I really wish I had interest in gaming PCs to justify getting one
<abathur>
anyone aware of a generic program/utility for analyzing the relative value of some parameters? (in my case, some ~fuzzing settings that may be useful or may just keep someone's fried chicken warm)
<infinisil>
gchristensen: Do it like me: Imagine you're gonna become a gamer, buy high-end gaming PC, end up not gaming all that often!
<colemickens>
infinisil++
<{^_^}>
infinisil's karma got increased to 394
<colemickens>
I even boot into Windows with the intent to game, and then after a few games wind up SSH'd into something
<abathur>
get some colorful LEDs, mask them with the Nix snowflake, etc.
<infinisil>
I do kind of want some fancy LED lighting
<abathur>
I was annoyed when I bought my system that the LED fans were the same price, so I bought them, but they've grown on me...
<infinisil>
I've got some Hue lights in my room, and I do like them very much too
<infinisil>
Although it's kind of the only light in my room that's not too bright, so I don't really have a choice other than to like them lol
<infinisil>
But no, they are pretty neat
<hexa->
agreed
* colemickens
swears parallel just stops going sometimes
<gchristensen>
I'm an xargs kind of guy
<gchristensen>
parallel does too much for me to remember how to use it
<andi->
same
<andi->
find -print0 | xargs -0 all the way
waleee-cl has quit [Quit: Connection closed for inactivity]
<abathur>
no find -delete? :)
<energizer>
pkgs.fd all the way
<cole-h>
I'm too lazy to learn `find`, so I agree.
<abathur>
in your defense, find is like the upside down
<siraben>
nix run nixpkgs.the-powder-toy -c powder
Mic92 has quit [Quit: WeeChat 3.0]
Mic92 has joined #nixos-chat
{^_^} has quit [Remote host closed the connection]
{^_^} has joined #nixos-chat
leah2 has quit [Ping timeout: 264 seconds]
eyJhb has quit [Quit: Clever message]
eyJhb has joined #nixos-chat
eyJhb has joined #nixos-chat
eyJhb has quit [Changing host]
leah2 has joined #nixos-chat
<viric>
I wanted to try pidgin videocall.... but it relies on gstreamer whoknows what configuration, and I have no idea how can I tell gstreamer what microphone/webcam use
cosimone has joined #nixos-chat
cosimone has quit [Quit: cosimone]
cosimone has joined #nixos-chat
<ar>
hm. is there a reason why nixos doesn't have a pre-built tickless (NO_HZ_FULL=y) kernel? it seems that enabling it (https://dpaste.com/C2GPDAXM5.txt) has cut down around 1-1.5W of power usage, according to powertop, apparently mostly by reducing the amount of cpu time tick_sched_timer gets
<ar>
this is all assuming powertop is at all accurate on amd/renoir laptops
<siraben>
as a bilingual, the live translation is impressive, I could not translate that quickly
<eyJhb>
Soon #nixos-* will be 50% of Freenode
<eyJhb>
siraben: Same, I was very impressed. Seems like they have gotten some semi-pro translators going
<ar>
eyJhb: you've not seen how many #hackerspace-pl-* channels there are
<siraben>
this is the experience that politicians get
<siraben>
are they sharing the different ways they are linking the event live?
<eyJhb>
ar: There are more #nixos
<eyJhb>
Do /msg alis LIST *nixos-*
* Emantor
ponders starting #nixos-wayland and towing colemickens in.
<siraben>
Emantor: i would join!
<siraben>
is there an IRC channel for following rc3?
<Emantor>
siraben: over on hackint #rc3
<siraben>
Anyone on Freenode?
<siraben>
Any*
<etu>
Nah, ccc have their channels on hackint
<siraben>
ah ok
<siraben>
joined #rc3
spudly has quit [Ping timeout: 264 seconds]
spudly has joined #nixos-chat
dadada_ has quit [Quit: WeeChat 3.0]
__monty__ has joined #nixos-chat
cole-h has joined #nixos-chat
kraem has joined #nixos-chat
temporary_compar has joined #nixos-chat
<kraem>
matrix <-> irc test
<gchristensen>
pass
<kraem>
gchristensen: sweet :) do you see this as kraem[m] or kraem over in irc-land?
<gchristensen>
just kraem
<Ox4A6F>
Joined #nixos-rc3
<kraem>
gchristensen: perfect, thanks
<Ox4A6F>
@freenode
<MichaelRaskin>
Pet vs cattle systems: Nix allows having a nine-lives-cat as a pet, and Flakes are detrimental to that.
<gchristensen>
oooh?
<MichaelRaskin>
Did you know that pure eval thinks that «just use this store path as the thing to evaluate» is not reliably pinned enough?
<MichaelRaskin>
That's actually one of the things discussed in the Flakes RFC comments (acceptable ways of pinning the source without, you know, putting everything into Nix binary no matter what), but we all know what happened to that RFC
<MichaelRaskin>
I guess a few things around Nix make me go back towards my old pre-Nix-core-team views
<gchristensen>
hard to change systems :(
<MichaelRaskin>
I would say some of the events look like actual change to the worse.
<MichaelRaskin>
I also wonder if nine-lives-cat pet is of any use to describe non-SaaS usecases of something Nix-like
<gchristensen>
I like thaht
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-chat
<MichaelRaskin>
I wonder how much visibility could be got for the nine-lives-pet model, and can anything useful be obtained from direction point of view from that visibility…
<infinisil>
Honestly I have no idea what this discussion is about, am I missing something?
<MichaelRaskin>
Probably no, probably I am just being a bit too cryptic
<gchristensen>
do you know about cattle and pets?
<MichaelRaskin>
(as models of managing something tunable)
<infinisil>
Nope
<joepie91>
I know about cattle vs. pets but not the nine-lives-pet...
<eyJhb>
Is there any ability in i3 to have multiple sets of workspaces, and switch betweens those? e.g. I have 7 workspaces open now, but I want to open a new set of workspaces while keeping the old ones
* joepie91
is also interested
<maljub01>
Is it strictly a nine-lives-pet or perhaps more of a phoenix?
<MichaelRaskin>
More like a phoenix, indeed, but keeping a phoenix as a pet might violate your local fire code!
<joepie91>
I doubt many fire codes mentioning phoenixes
<joepie91>
mention*
<maljub01>
I like my phoe-Nixes though.. (horrible pun. I know.. I'll see myself out)
<MichaelRaskin>
joepie91: it might qualify as an excessively flammable object without being directly mentioned, you know
<maljub01>
I have to admit I'm also a bit lost on the reference to what's wrong with flakes.. I haven't used them yet but very excited about them..
<joepie91>
MichaelRaskin: I think 'flammable' just describes things which can be set on fire externally, not things which emit fire by themselves?
<__monty__>
What about them excites you?
<__monty__>
joepie91: Think of it like a fireplace.
<joepie91>
maljub01: I'm in a somewhat similar boat. I find the concept interesting and probably-good, but also I've been getting the distinct impression that community feedback is not really being taken on board
<__monty__>
Not forbidden but it might raise your fees : )
* infinisil
wouldn't mind if anybody could *concretely* explain the problem(s) with flakes
<joepie91>
lol
<maljub01>
Every time I run `nixos switch` I risk something new that was updated implicitly breaking random things
<__monty__>
And by implicit you mean channels?
<maljub01>
I think flakes solve this in a seemingly elegant way
<MichaelRaskin>
joepie91: and even those can be restricted! But indeed a phoenix might be hypergolic, depending on the mythological tradition
<joepie91>
hmm, right
<maljub01>
Yes, channels. I have a script to lock it by reusing my current one but flakes also means I can use someone else's configs and know I'll get the exact same thing
<joepie91>
MichaelRaskin: so then the question becomes, which mythological tradition results in the lowest insurance rate
<MichaelRaskin>
maljub01: only if you lock anyway, and then you could just ask for a commit and set the corresponding NIX_PATH
<joepie91>
re: flakes, my main interest is in its potential to decentralize packaging more without breaking Nix's guarantees
<joepie91>
and without being a pain
<MichaelRaskin>
joepie91: it will be a pain in an obvious and well documented pain if you use it specifically for decentralising packaging
<maljub01>
Yes that's also pretty cool.
<__monty__>
It's always seemed to me like the thing preventing nixpkgs being distributed isn't technical but organizational.
<MichaelRaskin>
Because then cross-cutting changes will become a pain
<joepie91>
MichaelRaskin: I'm okay with tradeoffs when they are obvious actually
<joepie91>
realistically we already have these issues, they're just kinda not talked about
<joepie91>
(see: overlays, custom channels, ...)
<joepie91>
I would much prefer formalizing the tradeoffs into a single model that's simple enough to reason about
<MichaelRaskin>
joepie91: Linux kernel tells us, that by being willing to include everything, you can limit the impact of cross-cutting changes to things you do not care enough about
<MichaelRaskin>
In case of Linux kernel, ZFS
<__monty__>
The only really new thing I've seen flakes enable is the input configuration being tracked.
<joepie91>
MichaelRaskin: flakes don't prevent that though
<maljub01>
One pain point for me for example is that I actually use multiple nixpkgs channels in the same evaluation. I never liked the pinning options since they all were slow, so I still prefer to use channels. The way I actually do this is I have channels for specific packages I want pinned (like nixpkgs-nvidia to avoid expensive and time wasting rebuilds
<maljub01>
every update). Those channels are themselves pinned.
<maljub01>
Flakes seem to take that kind of hacky behaviour I do and make it more streamlined and easier to do
<maljub01>
And standard
<__monty__>
But if you don't update a pin why would you get rebuilds?
<MichaelRaskin>
joepie91: flakes per se do not, but I expect people trying to cuyt Nixpkgs in different flakes, doing some damage, then giving up
<maljub01>
Yes exactly I only get the rebuilds when I explicitly update it, but it's still in a channel which is managed in a shell script basically
<joepie91>
MichaelRaskin: that's an organizational concern though, and fairly easily addressed by basically just writing documentation that goes "we are not going to cut up nixpkgs because reason such-and-such, file an issue for discussion if you believe you have a solution to these issues"
<__monty__>
maljub01: But what do you gain by having it in a channel?
<maljub01>
Faster evaluation. No cache expiry.
<joepie91>
MichaelRaskin: a useful feature being abusable by a specific consumer seems like a bad reason to not include it :)
<maljub01>
At least the tar and git options always seemed too slow
<MichaelRaskin>
joepie91: I believe too many people, including the people developing flakes, believe giving up on a monorepo is a bad idea, so…
<MichaelRaskin>
Sorry
<joepie91>
then there's no problem, is there?
<MichaelRaskin>
some believe it is a bad idea abd some believe it is not a bad idea
<maljub01>
I think my point is that we can (and I suspect many do) already have a bad flakes implementation, each different and bad for different reasons. It's good to have a unified good one :)
<joepie91>
if there is already organizational consensus that splitting up nixpkgs is undesirable, then having a feature that could be used for it is not a problem
<joepie91>
exactly what maljub01 said
<__monty__>
maljub01: Sounds like your pinned nixpkgs didn't end up becoming GC roots. This hasn't been my experience with pinning.
<MichaelRaskin>
I expect Eelco to push through the split\
<joepie91>
it just formalizes something we're now doing in 3 different hacky ways, which is frankly a recurring thing in Nix that really needs addressing
<MichaelRaskin>
maljub01: curernt implementation is also a bad one
<MichaelRaskin>
I mean, it is tied to what fetchers are built into Nix
<maljub01>
No I think the issue is because the evaluation needs to download the pinned nixpkgs from the internet, so by default it will cache it for a specific duration and the first evaluation without a cache is always very slow
<MichaelRaskin>
Nope, just having a Nix path from elsewhere is not enough
<maljub01>
At least I prefer to deal with the update separate from evaluation
<MichaelRaskin>
So do I, which I achieve via having a checkout
<__monty__>
maljub01: I don't think there is such a concept of caching. It's put into the store, and it stays there unless it's garbage collected.
<maljub01>
I was sure I saw that somewhere, but let me check again
<__monty__>
And yes, having a nixpkgs checkout obviates the network traffic involved.
<maljub01>
I had those issues back in my early days with Nix, so I might have been doing something wrong like not adding the content hash or something..
<__monty__>
Sounds likely.
<__monty__>
Tbh, I'd look into it again cause your channel setup sounds like swimming against the current.
<maljub01>
I actually quite like it now :(
<__monty__>
But is it rational to? : )
<MichaelRaskin>
Yes
<maljub01>
Maybe?
<MichaelRaskin>
The only reason to use Nix is because when you set up something it stays set up
<maljub01>
This is what I have now for `nix-channel --list`
<maljub01>
So the URLs are basically what the unpinned versions redirected to anyway
<pie_>
i think this is one of the key issues here <MichaelRaskin> I expect Eelco to push through the split\
<pie_>
the other things are technicalities
<maljub01>
It's different I know, but it sort of works and uses less boilerplate, at least until flakes come along then I'll get rid of that and use flakes :)
<maljub01>
Well, it actually works nicely for me at least.. every time I need a specific pinned version, I just import from the channel
<MichaelRaskin>
pie_: well, not supporting arbitrary store paths as readonly enough to pure eval is also not encouraging
<maljub01>
MichaelRaskin can you elaborate on that?
<MichaelRaskin>
And also I have an impression that flakes have completely broken idea of platform support
<MichaelRaskin>
maljub01: pure eval in Nix defaults to only agreeing to touch things downloaded using builtin fetchers
waleee-cl has joined #nixos-chat
<maljub01>
But how do flakes change that?
<MichaelRaskin>
I believe pure eval was developed mostly for flakes and together with flakes
<gchristensen>
I think pure has existed for much longer than flakes?
<gchristensen>
Tue Jan 16 18:50:38 2018 +0100 d4dcffd64349bb52ad5f1b184bee5cc7c2be73b4 Add pure evaluation mode
<gchristensen>
it is quite annoying to use
<__monty__>
maljub01: If anything it's been my impression flakes add a lot of boilerplate if all you want to do is pin something.
<MichaelRaskin>
Well, a bit less than a year
<maljub01>
Fair enough, I haven't actually used them myself yet. I'll try to switch to them in the next couple of days
<__monty__>
Tbh, it's looking more and more like the people who didn't want flakes to be part of nix were right. It's apparently already the de facto solution to this problem and it's not even had a stable release yet.
<maljub01>
But isn't that a testament that it solves some real problems? I'm open to either side but I still don't quite get what's wrong with them (beyond repair) yet.
sorki has joined #nixos-chat
<maljub01>
I guess if not flakes, then what would you do instead?
srk has quit [Ping timeout: 240 seconds]
<MichaelRaskin>
maljub01: entrenching bad solutions to some of the problems while making sure other won't be addressed is a very typical outcome of rushing a solution
<MichaelRaskin>
And things like niv seemed to work fine without modifying core Nix
sorki is now known as srk
<maljub01>
So why was niv never made the official solution?
<maljub01>
I think there's a lot to be said for having an official "blessed" way to include external deps and Nix lacked that as far as I can tell.
<maljub01>
Include and manage
<bbigras>
Do we have the MesloLGS NF font in nix for powerlevel10k?
<pie_>
whats that webapp thingy for looking at the intersections of times people have availible?
<bbigras>
I think there's an open source one and a closed one. I forgot what they are.
<maljub01>
Although I just prefer to use a shared online spreadsheet :)
<pie_>
I think i was thinking of framadate
<pie_>
no not framadate
<pie_>
you could drag rectangle to color in the schedule :P
<bbigras>
"<infinisil> I know people prefer https://framadate.org/ because it's open source, but I'll continue using https://www.when2meet.com/ because its UX is just so much better, and I haven't found anything comparable that's open source"
<pie_>
yup its when2meet
<bbigras>
when2meet is the evil "better" one
<pie_>
aww dammit
<bbigras>
wait. I should have said "evil" better one
<bbigras>
I trust infinisil when he's saying it's the better one. and I'm joking about it being evil
<pie_>
thanks in any case
<eyJhb>
`Dec 27 17:57:10 tutti systemd-logind[565]: Failed to get load state of reboot.target: Connection timed out` Well okay then, guess I will not reboot then!
<MichaelRaskin>
maljub01: because there was a customer who paid for flakes development…
eyJhbV2 has joined #nixos-chat
eyJhbV2 is now known as eyJhb
eyJhb has joined #nixos-chat
eyJhb has quit [Changing host]
tilpner_ has joined #nixos-chat
tilpner has quit [Ping timeout: 260 seconds]
tilpner_ is now known as tilpner
Jackneill has quit [Ping timeout: 240 seconds]
<__monty__>
maljub01: Nix lacked one because no solution so far had garnered enough support to be accepted as official. Now because of flakes no other solution has much of a chance to garner that support because people just want a "blessed" way like you do. (Nothing wrong with shying away from trying every idea people come up with but don't make the mistake of thinking flakes won through some sort of natural
<__monty__>
selection/being found the superior solution.)
<MichaelRaskin>
… or even take into account anything learned from the previous solutions
<infinisil>
MichaelRaskin: Who paid for flakes development?
<__monty__>
Yes, they funded lorri too but that's not controversial because it doesn't affect nix.
<__monty__>
And I'm not convinced flakes had to.
<pie_>
surprisingly, target has a significant in some meaning of the word FP team
<__monty__>
Oof, that was hard to parse : )
<pie_>
im great
<infinisil>
Commas!
<__monty__>
Or em-dashes : )
<MichaelRaskin>
Note that neither of these are actually directed
<eyJhb>
FP team?
<eyJhb>
Front Person team?
<hexa->
Functional programming
<eyJhb>
Wouldn't have guessed that in forever, thanks hexa- !
<eyJhb>
Reminds me that I really want to find some time to do some Elm
<maljub01>
Thanks for the info. But flakes did go through the RFC process right? Was the feedback from experiences with previous solutions just ignored?
<maljub01>
My assumption for flakes being better came from my assumption that having gone through RFC, it must have gone through scrutiny by people who are interested in the problems solved by it and who probably have experiences with existing solutions. The RFC getting accepted in my mind implied some sort of consensus or majority opinion at least..
<MichaelRaskin>
Nope, they effectively did not
<__monty__>
Did you read the comments on the RFC?
<maljub01>
But I'm not as familiar with the inner workings of how nix is developed as I'd like to be
<maljub01>
No, but now I really want to :)
<maljub01>
It shot right up to the top of my to-do list
<__monty__>
I can't really recommend it but it'll make the controversy clear at least.
<MichaelRaskin>
Flakes were submitted as an RFC proposal, discussed, _some_ of the comments were acted upon in some ways, then they were declared experimental and RFC proposal withdrawn
<MichaelRaskin>
Then things started to be pushed to rely on flakes anyway
<maljub01>
Oh ok that's not great. The blog post about it at least seemed to imply that the RFC had the regular treatment..
<MichaelRaskin>
The RFC did. And it ended up withdrawn
<__monty__>
And while the point that RFCs aren't for experimental stuff may be arguable it looks like no one actually seems to care about the experimental status and is assuming it's as good as part of nix already.
<pie_>
__monty__: maybe thats because of the precedent the CLI set
tilpner has quit [Ping timeout: 240 seconds]
<pie_>
nix experimental seems to mean experimental but not really. or something.
<maljub01>
Well, maybe I'm misremembering, but after reading the blog posts on it, I had the impression it was basically a matter of time
<maljub01>
Before it makes it to nix proper
tilpner has joined #nixos-chat
<MichaelRaskin>
Yeah, and that doesn't involve resolving some of the issues raied
<MichaelRaskin>
(I mean, some will be resolved, some ignored)
<drakonis>
and now we have nickel i guess
<gchristensen>
I'm not sure how "we" "have" nickel
<drakonis>
phrasing
<MichaelRaskin>
Are you betting it won't ever become a mandatory dependency to build Nixpkgs?
<MichaelRaskin>
(I probably would not bet either way at even odds, at odds skewed into my favour… need to evaluate the evidence)
<drakonis>
its getting more attention from eelco ever since it was announced
<drakonis>
flakes related developments appear to have slowed down
<drakonis>
and the config branch from nixcon hasnt gotten any attention
<drakonis>
on the upside, there's manpages for the nix command now
<MichaelRaskin>
Flakes slowing down is also an upside
<drakonis>
on the other hand, nickel development is heating up
<MichaelRaskin>
They are there enough for everyone who actively wants them now
<drakonis>
its good that flakes are stable tho
<lukegb>
I'd argue having a nixFlakes attribute in nixpkgs was probably a bad start
<MichaelRaskin>
Well, it is free software and some people are running it in production, so there is no strong argument against packaging it!
<maljub01>
So, having not heard the pro-flakes side yet. I still have to say I think some solution like flakes needs to be part of Nix, or at least tightly integrated with it. It's crazy that it's not there already imo. Everyone I try to convince to use Nix "because reproducibility" ends up giving me weird looks when they see that by default nothing is
<maljub01>
actually reproducible..
<maljub01>
I do think it would still be fair game as long as there is a new RFC before it leaves experimental
<lukegb>
MichaelRaskin: yeah, I guess there's already multiple versions of other software in nixpkgs
<lukegb>
I prefer sticking to a close-to-one-version rule though :P
<lukegb>
(also, arguably, the people using nixFlakes can use their flaky nix to get a flake containing nix)
<drakonis>
but then you'd have to recompile it every time you upgrade your system!
<drakonis>
have a generally stable version of the flakes branch on nixpkgs
<drakonis>
which is exactly what was done.
<__monty__>
maljub01: I don't think it's fair. Because that RFC would be "Should we flip the experimental switch on flakes." Alternatives get far less visibility and acceptance would entail significant work to integrate them with nix. That's not exactly good footing for a fair anything.
<infinisil>
And the alternative of "Flakes has to stay experimental" isn't even really an option
<maljub01>
The alternative could be "change those things in flakes" which should imo also include potentially major changes.. it is experimental afterall
<__monty__>
Of course in theory experimental features can simply be excised without consideration for backwards compatibility.
<maljub01>
One option could be to just move it out of nix into a separate thing
<maljub01>
No?
<pie_>
(maljub01: thats what should have happened to begin with, put it on a separate public branch or something and let nix continue business as usual)
<__monty__>
Yes, but why would it if it was made part of nix with opposition from some?
<pie_>
actually im going to stop talking because i have no idea what actually happened
<pie_>
i made an unfair assumption that things just got merged into master
<manveru[m]>
most of the flakes work is by eelco, and him having to maintain two parallel versions of nix is kinda ... a lot
<__monty__>
Why is it so inseparable from nix in the first place?
<manveru[m]>
because it affects all aspects of nix
<__monty__>
It seemed to me like that was just the easiest way to develop it because the developer was so familiar with nix.
<manveru[m]>
i'm not sure the nix plugin api would be enough to pull this off, it introduces caching of evaluations, stronger purity, a whole new layer of CLI commands, additional builtins, etc...
<pie_>
each of those could have been PRed separately
<manveru[m]>
that's kinda hard if you don't even know what the end result should look like first
<__monty__>
All of those becoming part of the API would've enable alternative solutions to also be more easily implemented.
<manveru[m]>
anw, i didn't commit any of this code, so i have no right to judge how people should've done things :P
<drakonis>
the new CLI predates flakes
<__monty__>
You're allowed an opinion.
<pie_>
nevertheless they will be judged >::P
<drakonis>
stronger purity too
<manveru[m]>
and you still have the problem of fragmentation when you have ten different implementations of "flakes"
<drakonis>
that's also a big issue
<pie_>
i dont know just committing whatever willy nilly doesnt really sound like a better option
<drakonis>
there's also the issue with nix channels being messy
<manveru[m]>
it's already a PITA to get people to install the right nix version, set all the nix.conf flags, before even getting started on a new project
<manveru[m]>
nix was supposed to solve that, but now you need a nix for nix :P
<pie_>
im not really sure how the whole BDFL dynamic could work better here
<pie_>
since eelco seems to be at least somewhat in this position, it would be his job to point at something and say "we are going with this"
rajivr has quit [Quit: Connection closed for inactivity]
<pie_>
but then here we are with the whole flakes situation
<__monty__>
I don't see fragmentation as a problem necessarily. Another word for it is competition and that's usually good for users.
<pie_>
my naive opinion is that really we should be improving the quality of the interpreter
<manveru[m]>
i found the RFC reasonable, and i've been using flakes for about a year now... so i'm a bit biased :)
<pie_>
if the interpreter is good, people can do things like niv
<manveru[m]>
niv still works with flakes
<MichaelRaskin>
I guess RFC process primary value so far has been to make sure decisions where Eelco has no time to ever commit to an opinion with some reasoning get made in a respected way, and here we had an opposite situation, leading to a… well, some outcome
<pie_>
ive never used niv with flakes
<pie_>
or i just didntr know about it xD
<manveru[m]>
you can do all the fetching you did previously, it just won't show up as flake input...
<pie_>
aaa. I need to stop, I dont even know what flaked do yet really. It's all second hand stuff.
<pie_>
(otoh all the people I listen to I have high opinions of so its not completely unfounded)
<__monty__>
manveru[m]: What benefit do you get from flakes in that scenario?
<pie_>
its called nix :P<manveru[m]> nix was supposed to solve that, but now you need a nix for nix :P
<manveru[m]>
__monty__: mostly backwards compatiblity, so people don't have to relearn tooling
kalbasit has joined #nixos-chat
<manveru[m]>
flakes still provides purity and caching, so things are more reproducible and fast
<MichaelRaskin>
__monty__: I assume, it is not to get a benefit from flakes (niv does everything you need) but to use things that people unfortunately have migrated to flake format
<MichaelRaskin>
Does caching actually need flakes or just --pure, BTW?
<__monty__>
manveru[m]: That sounds like the benefit of sticking to niv despite flakes.
<manveru[m]>
the biggest benefit in our org for flakes is strategic, since it's easier to reason about dependencies and calling conventions
<pie_>
even if flakes is technically sound, its a big failure of process from my second hand point of view
<MichaelRaskin>
It's an attempt to apply process beyond its true limitations that no one was willing to talk about
<pie_>
not sure if i should tie myself to a stake for even saying that sentence haha
<pie_>
like did i really just say that
<pie_>
(people are gonna yell when they dont like something and not when they do :P)
cosimone has quit [Quit: cosimone]
<pie_>
MichaelRaskin: limitations?
<manveru[m]>
MichaelRaskin: i'm not sure if --pure blocks channels
<MichaelRaskin>
pie_: I do not think anyone has tried before override Eelco's actually well-researched opinion via RFC process…
<manveru[m]>
i don't even know what commands support pure...
<pie_>
MichaelRaskin: well who has decision power if both people say no?
<maljub01>
__monty__ I do think fragmentation is a real problem. You want dependency resolution to be transative
<__monty__>
Imo it's wrong to talk about fragmentation in the first place when talking about nascent technology.
<__monty__>
It has a very negative connotation.
<MichaelRaskin>
As long as Nixpkgs is a single thing there to reuse, the costly to replicate part is not ffragmented
<__monty__>
"The" solution hadn't been found yet. Experiments should be various to identify the best solution.
<pie_>
im not sure what happened with respect to documentation but that might be an example of the right way to do it
<pie_>
i recall somethiing about multiple RFCs for various experiments demonstrating solutions?
<MichaelRaskin>
No ,attrition happpened
<pie_>
i have no idea what happened but there was a LOT of stuf
<pie_>
MichaelRaskin: clarify please?
<MichaelRaskin>
There was an RFC to design a binding vote, which failed to design something universally recognised
<__monty__>
I haven't seen any RFCs talking about alternatives to flakes.
<MichaelRaskin>
Next there was an RFC to give up and go to MarkDown
<pie_>
__monty__: maybe part of that is that flakes is too many things at once
<MichaelRaskin>
by which time everyone who cared mostly agreed that moving to Markdown is better than the continuation of the discussion
<pie_>
MichaelRaskin: oof xD
<__monty__>
pie_: I interpreted your statement about various experiments to mean there *have* been RFCs for flake alternatives. Guess you were talking about something else.
<MichaelRaskin>
I mean, this is fine in the sense that the first discussion did provide a bound on benefits of other options
<pie_>
MichaelRaskin: well in any case that still sounds reasonable
<pie_>
__monty__: i meant t6he doc format switch
<__monty__>
Markdown won because of its familiarity even though the docs will more likely than not require a homespun flavor of markdwon which is therefore not familiar >.,
<__monty__>
*>.<
<pie_>
:(
<pie_>
well they will have tried both ends of the spectrum and can hae another argument in 10 years :D
<joepie91>
I actually wouldn't consider that an issue so long as it's possible to write documentation with the base set of Markdown, and any additional custom things are purely additive
<pie_>
nooooo you cant just cripple the expressivity hahaha pandoc go brrrrr
<joepie91>
the point is to get documentation written at all
<MichaelRaskin>
Of course somehow people ended up agreeing not to discuss the desired structure of docs tnot derail the discussion of the format for who-knows-what, and the actual discussion on structure has yet to happen
<pie_>
valid
<__monty__>
I think even tables require extensions?
<__monty__>
So I don't see how it's not going to affect writing documentation.
<__monty__>
Unless you're of the opinion that embedding HTML is just fine.
<MichaelRaskin>
It won't anyway, because still no one has any idea what goes where
<drakonis>
bikeshedding all this time to decide going with markdown
<pie_>
sounds to me ilke three wouldve been less drastic solutionsthe only way i can see of having the cake and eating it too is dual stack
<__monty__>
My suggestion to have an agreed-upon barebones subset of the docs converted into every suggested format as a way to evaluate basic shortcomings was met with quite a lot of opposition imo.
<pie_>
but apparently that wasnt wanted?
<joepie91>
__monty__: I didn't really see 'opposition' to that? seemed more like a general disinterest and/or lack of time
<__monty__>
I suggested that thinking the first step would be to convert the existing docs to the new format. So people could start contributing in the format selected.
<__monty__>
joepie91: There was some "That's a waste of time, let's not do that."
<pie_>
good conversion is hard? there did seem to have been some examples?
<__monty__>
Yes but the examples were either format demos or total conversions, the former isn't concrete enough for cross format comparison and the latter is actually too much work with some formats imo.
<__monty__>
And the conversion I was talking about wouldn't have to be automatic.
<pie_>
i agree that to make a well founded decision in such a situation requires ...well, youd have to be thorough and thats a lot of work
<pie_>
its not a herding cats thing
<pie_>
or, youd have to herd the cats
<__monty__>
Not sure what you mean.
<joepie91>
__monty__: I've also seen people go "sure, go do it and we'll take it into consideration", followed by... nothing
<__monty__>
I figured a small-as-possible sample of the docs, covering all the features currently used would make a good start to compare formats objectively.
<pie_>
__monty__: that sounds reasonable. it might have helped to propose a concrete thing that should be translated
<__monty__>
That's what I did.
<pie_>
oh
<pie_>
:(
<pie_>
no feature matrix pinned at the top of the thread? :P
<pie_>
not sure what it would have taken to get anyone to work on anyting
<pie_>
*completion matrix
<pie_>
ah well, i gotta go work on some stuff now
<__monty__>
You gonna work on improving the docs? : )
<pie_>
no i have a linker error ive been sitting on for half a year
<pie_>
xD
cosimone has joined #nixos-chat
<elvishjerricco>
Anyone here have a MacBook with both a Touch Bar and an escape key? How do you like the Touch Bar?
<pie_>
oh no i cant find my notes for this project >.>
kalbasit has quit [Ping timeout: 256 seconds]
<drakonis>
macbooks with a physical escape key AND a touch bar? do these exist?
<elvishjerricco>
drakonis: Yea they've all had both since last year
<elvishjerricco>
The 13" ones may have only gotten the escape key early this year actually... But yea they all have both now
<elvishjerricco>
Based on how annoying I find it to change brightness with control center on iOS, I'm thinking I'd be annoyed by the Touch Bar as well, especially since the volume control is there too.
<elvishjerricco>
Man id like a phone with a bunch of programmable buttons on the side, like those gaming mouses with a trillion buttons
<drakonis>
i'm surprised apple walked back on that
<drakonis>
well
<drakonis>
i see that and raise you tasker
endformationage has joined #nixos-chat
<drakonis>
apple has added their own fancy actions system too
<drakonis>
google has an improved power menu now that can be potentially used to do programmable buttons
<drakonis>
so its all interesting
<MichaelRaskin>
elvishjerricco: Gemini/Cosmo? Fx Pro1?
<MichaelRaskin>
(just kidding, but there _is_ a ton of extra buttons to the side of the screen…)
<viric>
Today I tried linphone, jami and pidgin for videocalls (farstream). All wrong.
<viric>
webrtc is the only thing that 'works' on nixos, I think
<__monty__>
Wrong?
<__monty__>
Are you looking for just videocalls or videoconferencing?
<viric>
videocalls would be enough for first.
<viric>
I admit I want hw encoding
<viric>
+ decoding
<viric>
echo cancellation can be done by pulse, I think
<energizer>
viric: did you try jitsi?
<viric>
that's webrtc, isn't it?
<viric>
I used chrome with vaapi but it looked like taking a lot of cpu still.
<viric>
with ffmpeg I saw that I can take mjpeg from the webcam and reencode it h264 at 5% of cpu
<viric>
so I'd like something that worked on those figures
<__monty__>
viric: Hmm, could you pretend the ffmpeg stream is a webcam somehow? Like what people do with OBS? Maybe if you have ffmpeg convert it to the encoding the software wants there's no software encoding involved?
<MichaelRaskin>
__monty__: I think there is also the question of decoding
<__monty__>
True, I guess I was assuming it's asymmetric.
<pie_>
https://apenwarr.ca/log/20201227 "This apparent lack of structure too often disguised an informal, unacknowledged and unaccountable leadership that was all the more pernicious because its very existence was denied."
<pie_>
this post is actually about systems design, sidenote.
<viric>
I think ffmpeg encoding + sending rtp and something like mpv receiving and playing in parallel, in each end, could work. I've to find how to cut the buffers/latency and use pulse echo cancellation...
<viric>
(on a tinc vpn)
cosimone has quit [Quit: cosimone]
cosimone has joined #nixos-chat
cole-h has quit [Quit: Goodbye]
__monty__ has quit [Quit: leaving]
ghuntley has quit [Ping timeout: 260 seconds]
jackdk has quit [Ping timeout: 260 seconds]
srhb has quit [Ping timeout: 260 seconds]
waleee-cl has quit [Ping timeout: 260 seconds]
{^_^} has quit [Ping timeout: 260 seconds]
lopsided98 has quit [Ping timeout: 260 seconds]
lopsided98 has joined #nixos-chat
Mic92 has quit [Ping timeout: 260 seconds]
waleee-cl has joined #nixos-chat
jackdk has joined #nixos-chat
Mic92 has joined #nixos-chat
srhb has joined #nixos-chat
cole-h has joined #nixos-chat
{^_^} has joined #nixos-chat
ghuntley has joined #nixos-chat
cole-h has quit [Client Quit]
tokudan has quit [Remote host closed the connection]
tokudan has joined #nixos-chat
cole-h has joined #nixos-chat
<cole-h>
Was the bug in out Firefox package / wrapper (where all addons got deleted and stuff) fixed on nixos-unstable?
<cole-h>
s/out/our/
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-chat
<LinuxHackerman>
cole-h: yep
<cole-h>
Great.
<cole-h>
Time to reinstall NixOS onto my NVMe :D
temporary_compar has quit [Ping timeout: 245 seconds]