domenkozar[m] has quit [Ping timeout: 248 seconds]
worldofpeace has quit [Ping timeout: 272 seconds]
roberth has quit [Ping timeout: 260 seconds]
roberth has joined #nixos-officehours
aanderse has joined #nixos-officehours
roberth has quit [Quit: killed]
aanderse has quit [Quit: killed]
<gchristensen>
we're holding a special office hours today, I hope y'all will be able to come. probably 1h long
roberth has joined #nixos-officehours
<gchristensen>
/!\ Today's office hours is a different format /!\ watch live: https://youtu.be/FKpeI8U8-AE discuss in #nixos-officehours, no group Zoom call today. We're discussing the last few weeks: Hydra's memory problems, the flakes.nix merge to nixpkgs, RFC process, etc. We start in 38 minutes
* samueldr
packs laptop away
<samueldr>
(my main computer audio setup is weird)
<samueldr>
I have the ipod playing music in the line-in, that's sinked into the main audio output
<manveru>
is that memory improvement also applicable to nixops?
<edef>
Rust's feature gates are *only available on nightly builds*
<edef>
this is not an appropriate comparison
<edef>
with rustc, if my stuff builds without making a non-nightly rustc executable, i can be certain it will continue to do so with future rustc versions (within the same major version)
<edef>
this guarantee does not exist with the way the feature flags in Nix are used/released
<qyliss>
There could be a configure option
<edef>
yes, this would be acceptable
drakonis has joined #nixos-officehours
<gchristensen>
manveru: not at this time, but interesting idea
<gchristensen>
puck: indeed, the marking of those commands was done after the activation phase already used the nix 2.0 interface
<gchristensen>
so reverting those back to the old-style is definitely something we should do.
<edef>
disabling feature flags by default would indeed serve the purpose of preventing this kind of accident
<puck>
yeah
<puck>
there's a PR that just adds the "--experimental-feature nix-command" argument
<gchristensen>
nice
<edef>
if a PR is open for 5 months, it getting merged is more surprising than the alternative
<edef>
IRC is not a recordkeeping mechanism
<qyliss>
^^
<edef>
"oh haha forgot to inform y'all, whoops" very much feels like the default for the flakes process so far
<tazjin>
is there still a nix repl without the nix-command?
<puck>
also re. the fork, i have a local fork of nixpkgs inside my own /etc/nixos git repo, since there's a few patches i have that i have not upstreamed for some reasons or other
<samueldr>
not anymore
<edef>
nix-repl(1) is not very alive
<edef>
but was Technically Never Stable, so,
<tilpner>
qyliss: Wait, there was no RFC meeting since October?
<qyliss>
n
<qyliss>
*no
<tilpner>
Just for the flakes RFC, or for any RFC?
<qyliss>
for the flakes RFC
<edef>
a variety of other RFCs have gone more nicely
<tilpner>
Oh, I didn't know each RFC got its own meeting, that makes sense
* tilpner
assumed you went over all open RFCs at once
<qyliss>
there's a different shepherding team for each RFC
<qyliss>
there's also the RFC Steering Committee that goes over all of them
<tilpner>
Ahh, I mixed up who was meeting, since I looked at the steering commitee notes today
<jared-w>
`nix run .:nixosConfigurations.vyr.config.system.build.toplevel -c switch-to-configuration test` h'what
<edef>
the Rust code had hella UB when merged
<flokli>
some of the remarks there still aren't adressed
<puck>
i'm not entirely certain but i think the amount of UB only grew in the meantime?
<edef>
and i do not remember seeing any response other than "lol we'll revert rustc if newer rustc breaks it"
<edef>
despite this plausibly changing by optimisation level, architecture, day of the week
<edef>
and unless we're throwing SAT solvers at the *binaries* and verifying that they match a formal specification, maybe just use defined behaviours of the language
<jared-w>
the rust code has extensive UB? How do you even do that in rust?
<edef>
hella unsafe C++ interfacing
<jared-w>
ah ok. Not great, but not entirely unexpected
<edef>
some of the Rust software i am known for does some very strange things in terms of unsafe behaviour, and i have not needed to do things that are as obviously UB as this
<drakonis>
that sounds like a recipe for a hella bad time.
<edef>
the cxx crate would probably very much improve things
<edef>
it does not feel like there is a real interest in ensuring Nix is stable, reliable software that i can reasonably build my business on
<tazjin>
but *is* flakes "tentatively approved"?
<edef>
and this is from the perspective of someone who is very much interested in doing that
<drakonis>
tazjin: as far as i'm aware, we're constantly going "this would be so much better if flakes was available"
<tazjin>
who is "we"?
<drakonis>
irc
<edef>
i wonder what percentage of those use cases are decently solved by niv or git subtree merges
<cole-h>
>> "Reinstall Chrome"
<edef>
and what stops people from using the experimental flags/branches if they genuinely do think flakes would be an improvement
<samueldr>
irc is not a coherent entity
<gchristensen>
edef: I think it is a good thing for people to use flakes and experiment
<edef>
i think they should feel welcome to experiment
<drakonis>
edef: needs a slightly higher amount of documentation than what's already available
<edef>
but the current response to the GCpocalypse is "you will only get urgent fixes if you are on the experimental branch"
<drakonis>
which is basically just the rfc and code reading
<gchristensen>
edef: what?
<samueldr>
I think it's important we reduce the confusion in the two separate issue
<jared-w>
GCpocalypse?
<drakonis>
jared-w: memory issues
<edef>
…sorry, my brain jumped threads there
<samueldr>
is there a plan to merge the hydra evaluator thing to master?
<edef>
and/or i hit enter on the wrong half-typed message
<jared-w>
drakonis: the hydra ones? gotcha. I'm following now :)
<drakonis>
yes
<samueldr>
(this time I think it's extremely important because of the confusion that engulfs those two issues)
<drakonis>
the hydra job evaluator got reverted and returned to hydra didnt it?
<gchristensen>
yes
<edef>
gchristensen: broadly i think people trying out flakes is good, but if i have to be aware of experimental branches to get production fixes, that's a problem
<edef>
(i am definitely getting tired, so i think i will drop off soon)
<tazjin>
note that there's a difference between "trying out flakes" and "using the experimental flakes branch to work around some production blocker"
<edef>
yeah
<samueldr>
anyway the call should be dwindling and closing
<samueldr>
(it's about that time)
<edef>
my caffeine level is definitely dwindling and closing
<jared-w>
ah that reminds me. Coffee...
<aanderse>
what? today was office hours? aw dangit i thought it was next week >_<
<edef>
so far i do not feel particularly more comfortable about the concerns i had, and an additional one came up (the whole GC thing, which i hadn't paid close attention to)
<gchristensen>
tazjin: I'm not sure if I'm understanding your message correctly, but in case it wasn't clear: the changes to the Hydra evaluator are not part of the Nix flakes branch at all, and are in Hydra master and work with the Nix master branch and the Nix flakes branch. the changes were initially made in the flakes branch out of expediency, but were removed after it was implemented in Hydra
<gchristensen>
itself
<tazjin>
gchristensen: I wasn't referring to the GC thing
<gchristensen>
okay
<gchristensen>
it sounded like you were, since that was the production blocker
<tazjin>
I meant this as in, if we're feature-gating stuff as experimental then it should be clear that these experimental things are not to be relied on and should also not be recommended as workarounds for other stuff
<tazjin>
it was more in response to, eh, one sec
<tazjin>
20:48:58 <drakonis> tazjin: as far as i'm aware, we're constantly going "this would be so much better if flakes was available"
<tazjin>
^ this
<gchristensen>
ah
<tazjin>
as in, if someone shows up on IRC and says "hey I'd like to do $thing", where that is potentially something flakes could address, we shouldn't recommend flakes if they're going to be relying on that
<drakonis>
we keep tilting between "we should use flakes for this" and "we shouldn't use flakes because its experimental"
<gchristensen>
I don't know of anyone doing that at this time, but good point
<tazjin>
flakes is just one example, it's also the other experimental things
<tazjin>
I didn't know that the "nix" command is experimental and could be removed at any point
<multun>
it could just be there by default, and get a warning message on startup
<gchristensen>
yeah, it was a mistake to make `nix` available by default however many years ago
<drakonis>
merge flakes and encourage a slow uptake
<drakonis>
otherwise it'll languish in limbo
<gchristensen>
I know I personally look forward to flakes being available as a way to share expressions, and I think it will make thinsg easier
<tazjin>
drakonis: my understanding is that the RFC is not accepted, so encouraging uptake is not the right thing to do atm
<drakonis>
making nix available by default did boost adoption
<gchristensen>
unfortunately so
<drakonis>
despite being clearly incomplete
<gchristensen>
yes, and it was a mistake
<tazjin>
and flakes is also an insular problem, for example in my Nix world flakes solves no problems
<tazjin>
that's not saying it doesn't solve anyone's problems
<tazjin>
but taking for granted that it is the correct thing to do is not something I see as given right now
<gchristensen>
we don't want adoption of it. we want people to experiment with it and try it with their use cases
<gchristensen>
tazjin: as far as I know, I don't think that is what is happening
<drakonis>
how to encourage experimenting then? merge and leave it gated?
<drakonis>
its relatively unknown to the wide mass of users
<gchristensen>
sure
<gchristensen>
I think it requires people to take interest and try it. whether they get it from the master branch or the flake branch I think is not significantly different from the user's perspective, so I'm not sure why we'd merge it
<qyliss>
I think Flakes would have benefitted a lot from being implemented outside of Nix
<edef>
++
<qyliss>
I know Eelco does not agree with that.
<qyliss>
I _believe_ it would have been possible to do that way.
<qyliss>
Then we could have compared niv, flakes, etc. as equals.
<qyliss>
And picked one (or none at all) based on their merits.
<gchristensen>
samueldr submitted a nix expr which does much of it I think
<qyliss>
As it stands, we're instead stuck with flakes or no flakes.
<samueldr>
only the subset required for what was needed, though zimbatm did share an interesting expression that may help
<qyliss>
I'm still not sure I understand what flakes brings to the table over Niv.
<gchristensen>
ah
<qyliss>
I might have done a few months ago, but that's part of the problem with the RFC having been dormant for so long. :P
<drakonis>
the branch doesn't pull only flakes from what i've noticed
<samueldr>
I don't know niv, (and don't really grok flakes yet as I haven't followed its development)
<drakonis>
there's a command for handling profiles
<multun>
gchristensen: what's wrong with the nix command line utility ?
<drakonis>
dev-shell, seems to be nix-shell but better?
<gchristensen>
multun: it is entirely an experimental interface subject to change (documented in nix --help) but nobody really believes it because it is just available
<edef>
it turns out that consensus reality, rather than some note stashed away in --help determines reality
<edef>
this holds for any social project
<multun>
gchristensen: alright, but isn't the tool alright ?
<multun>
wow I should have read that one more time
<gchristensen>
well sure it is fine but it shouldn't be relied upon
<gchristensen>
or used in prod-like thinsg
<edef>
"can an interface be modified backwards-compatibly" is a social property, an observed property
<gchristensen>
and Nix development has taken for granted the availability, ignoring its unstable interface :P
<edef>
it's something you can steer but not simply declare into being
erictapen has quit [Ping timeout: 260 seconds]
<multun>
gchristensen: I'm pretty sure an unstable user interface is file
<multun>
fine
<edef>
nixos-rebuild already uses it
<gchristensen>
multun: the problem is not the interface, the problem is a dependence upon it
<qyliss>
user interfaces aren't only used directly by users ;)
<gchristensen>
^
<multun>
huh yeah
<gchristensen>
and the "new" interface is actually mandatory for a few things, which is not good
<aanderse>
watching office hours... i missed a good one!
<multun>
gchristensen: what's the drawback of that, except that you can't break backward compat ?
<multun>
it's not like it can't evolve
<drakonis>
re: niv, it looks like it does dependency management.
<gchristensen>
multun: well it is just a lie
<drakonis>
flakes has gone beyond simple dependency management as it stands
<multun>
:o
<gchristensen>
multun: and we need to be truthful about the boundaries of an unstable interface which should not be depended upon
<drakonis>
you can break backwards compat when nobody still uses it.
<gchristensen>
drakonis: has it?
<edef>
no, because it is infeasible to at this point
<drakonis>
the manner it presents itself or perhaps the way we see it?
<gchristensen>
edef: we'll see when the next Nix comes out with `nix` disabled by default
<edef>
would anyone *actually* want to propose a serious, backwards-incompatible change to nix(1), even if that is necessary
<gchristensen>
`nix`'s UX has broken signifcantly once before, we can do it again! :P
<tilpner>
edolstra recently said that the weird nix eval behaviour was changed on flakes
<edef>
gchristensen: is that a thing that is actually going to occur
<tilpner>
Where you had to wrap expressions in parentheses or it would be interpreted as an attrpath
<edef>
because i'd love to see the discussion that leads there
<gchristensen>
edef: not sure
<gchristensen>
but it is marked as experimental now
<edef>
mm
<gchristensen>
anyway, `nix` has changed SIGNIFICANTLY since 20d165c34467338f07c4808783cd50318c38a47b
<tilpner>
I didn't ask if the parentheses were still accepted, but that might also break things
<edef>
i have a few feelings about process as it goes now
<drakonis>
atm flakes presents itself as a replacement for channels and how systems are composed
<drakonis>
so that's well beyond what niv would achieve
<multun>
gchristensen: you could add an "this utility is experimental" runtime warning
<drakonis>
multun: it only shows when you run `nix`
<drakonis>
not when running commands
<edef>
one of them is that the biggest possible win for enforced process right now looks a lot like "prevent stuff from happening"
<edef>
because that's seemingly the only way process actually gets respected — if it manages to be an actual roadblock
<edef>
it very much feels like a concession to the community
<drakonis>
and then there's the ability to slice nixpkgs onto manageable pieces, which was bikeshedded upon in the rfc
<edef>
i think not having to juggle a humongous dependency matrix is half of what makes nix so appealing right now
<drakonis>
certainly.
<edef>
(and i continue to have a strong sense that the problem being solved there is called "version control")
<edef>
a lot of the stuff that plays out in nixpkgs right now will just play out more diffusely and become problems that need to be solved by flakes now
<drakonis>
its already playing out
<edef>
elaborate
<drakonis>
nixpkgs forks with lots of patches overlaid on top
<drakonis>
nix trees containing alternative build infrastructures
<drakonis>
see haskell.nix and nixpkgs-emacs
<edef>
mm
<edef>
i'm on the "forks with lots of patches" end here
<drakonis>
hell, even spectrum would benefit from that
<edef>
i just git merge -Xsubtree into my monorepo from time to time
<drakonis>
there's nixos-mobile
<edef>
this branching model works out fairly well for the kernel and at least a subset of the Nix community, afaict
<drakonis>
NUR would be easier to use without relying on overlays to include it
<edef>
i think overlays are a decent piece of mechanism, and imposing policy on it from the nix core side is still very much something that feels given as a command from above
<drakonis>
the bad is that channels arent very elegant
<drakonis>
the channels live on their own little islands
<edef>
i agree (and would probably disable channels if they were a feature flag — i do not use them)
<drakonis>
well, we'll see how this goes now.
<qyliss>
drakonis: Spectrum will be using the subtree approach, should anything like this ever be required
<drakonis>
aigh.
<drakonis>
aight.
<qyliss>
(as things stand, anyway)
<drakonis>
also worth pointing out at the significant piles of out of tree but useful things
<drakonis>
you have to go out of your way to track those down, but it isn't relevant to the issue at hand
<drakonis>
there's a third party repo that does improved cross compilation, its fascinating.
<qyliss>
The "Support for patching nixpkgs" issue is related to this