<gchristensen>
usb-c is already so unsafe adding 10k would definitely be an improvement
<pie_>
lol
<MichaelRaskin>
Indeed, then the people will at least notice
<MichaelRaskin>
Some people might even notice it before getting a shock!
<MichaelRaskin>
The fun part of 10kV is, of course, that there is not enough space inside USB-C form-factor to prevent an arc discharge through the air
<aanderse>
manveru: you around?
<aanderse>
trying out new bundix
gchristensen has quit [Ping timeout: 252 seconds]
gchristensen has joined #nixos-chat
jtojnar has quit [Remote host closed the connection]
<eyJhb>
Requested a dormant namespace from Gitlab before I went to bed, woke up at 5.00 AM, got a email from them at 2.00 AM saying they released the namespace. Then trying to register it, it said it was already taken.... That was no fun
<eyJhb>
Until they said they forgot to save it.
Myhlamaeus has joined #nixos-chat
Drakonis has quit [Quit: WeeChat 2.4]
Drakonis has joined #nixos-chat
Myhlamaeus has quit [Remote host closed the connection]
wavirc22 has joined #nixos-chat
Myhlamaeus has joined #nixos-chat
__monty__ has joined #nixos-chat
Myhlamaeus has quit [Remote host closed the connection]
cjpbirkbeck has joined #nixos-chat
<aanderse>
manveru: unfortunately i didn't get too far
<joepie91>
pie_: yeah. I think we should probably just stop trying to market Nix as a functional thing, and just have that as a "show, don't tell" property of it :)
<gchristensen>
I have tried to avoid the f word for the last couple years
<aanderse>
i get strange looks whenever i say "functional programming" to anyone about nixos
<aanderse>
but my crowd is the object oriented programmer or sysadmin crowd
<{^_^}>
nix#2825 (by grahamc, 7 weeks ago, open): Using flakes is not obvious, and no documentation has been written
<joepie91>
aanderse: I've pretty consistently gotten better results from avoiding the term :P
<gchristensen>
joepie91: no
<gchristensen>
it is in the `flakes` branch
<joepie91>
aanderse: when I call it 'functional', or people notice the term on the site, the first thing people expect me to do is to 'defend' towards them why functional anything is appropriate or useful for package management... whereas when I approach it from a "this is how package management could be better" angle, they take existing systems as the baseline and the improvements make intuitive sense to them, and they are just left asking how it could
<joepie91>
possibly provide those guarantees - at which point the explanation about the functional properties comes in :P
<joepie91>
gchristensen: ah, right, got excited there for a moment :(
<aanderse>
joepie91: makes sense
cjpbirkbeck has quit [Quit: Quitting now.]
<Ralith>
+1
waleee-cl has joined #nixos-chat
<__monty__>
I use "declarative" rather than functional.
<joepie91>
I've found that to work with some subset of programmers (mostly more experienced ones), but basically nobody else :P at least, not unless I explain what I mean with it
<joepie91>
it does work with *non-functional* programmers, though
<__monty__>
Works with anyone who knows SQL.
<joepie91>
definitely not (in my experience)
<__monty__>
"You know how you can write a simple query and the RDBMS turns it into efficient instructions? Well, nix..."
<joepie91>
I mean, I'm talking about the term 'declarative' itself here - if you actually explain the *concept* behind it, it'll find a much broader audience of course
<MichaelRaskin>
Dangerous path!
<joepie91>
though I'd probably avoid the mention of 'efficient' here, given Nix' lingering performance issues :)
<joepie91>
"you said it'd be fast!"
<MichaelRaskin>
Because SQL actually makes people think about version combination resolution
<arianvp>
Nix is anything but declarative imo ;p
<MichaelRaskin>
Yeah
<__monty__>
I don't know, I think the people experienced enough to worry about that are experienced enough not to need me explaining nix.
<__monty__>
It's the least *un*declarative package management solution we have : >
<joepie91>
arianvp: it's in that weird spot where it has most of the properties of a declarative language, but with the limited ability (and tradeoffs) to essentially add 'generation logic' for the declarative data
<joepie91>
to a lot of people, this registers as "declarative"
<MichaelRaskin>
I would say that Nix itself is about removing interactions between packages that you don't want
<joepie91>
and I have yet to find a better term to describe it, in the sense of distinguishing it from imperative do-this-then-that languages
<MichaelRaskin>
Nix is actually pretty do-this-then-tha
<MichaelRaskin>
tIt just has scoping
<joepie91>
in a way, Nix shares a space with declarative formats like YAML (which allows limited references and such)
<joepie91>
MichaelRaskin: eh, I disagree
<MichaelRaskin>
Unlike «put everything into the global shared namespace» that dpkg/rpm do
<joepie91>
it still does things sequentially, but that isn't what I was talking about
<joepie91>
I'm talking about the method of specification
<joepie91>
which is distinctly *not* imperative in Nix (aside from the build scripts)
<MichaelRaskin>
Dunno, seems pretty direct «do that» to me
<joepie91>
you specify chunks of configuration, that get converged into a single essentially-declarative configuration, which is then analyzed by the runtime (Nix) and turned into a series of steps to execute
<joepie91>
'converged' is not the perfect word here, but I can't find the word I mean
<MichaelRaskin>
Ah, NixOS configuration. That's just horrible
<joepie91>
MichaelRaskin: NixOS uses this, yes, but ultimately the language itself is designed around this principle
<MichaelRaskin>
Let's start with a purely functional language and expend nontrivial amount of effort and complexity to model global variables
<joepie91>
?
<MichaelRaskin>
At the core Nix is pretty much about scripting imperative package builds, only with abstractions and scoping
<MichaelRaskin>
Those things Lisp and Fortran added on top of assembly
<MichaelRaskin>
NixOS configuration adds quite a bit of «global variable» complications back
<joepie91>
oh, in that sense. I partly agree, in the sense that the current implementation has those sorts of issues (eg. the single-service-instance limitations), but I don't think they are inherent
<joepie91>
and ultimately, "scripting imperative package builds, only with abstractions and scoping" is something that applies to ~every functional language, once you replace "package builds" with "logic"
<joepie91>
in the end it's all sequential operations on mutating state
<joepie91>
but it's not about the implementation, it's about the interface to the developer and what guarantees and conveniences it provides
<MichaelRaskin>
Well, you can have better proprties if you have both functional language _and_ good properties of the underlying domain
<MichaelRaskin>
There are alternatives — SQL, Datalog, SAT-solvers…
<joepie91>
so I don't think it's terribly relevant that there is technically still an imperative layer underneath it, so long as you do not need to interact with or account for that layer, and I don't think it's fair to call something imperative just because under-the-hood it does imperative things
<MichaelRaskin>
I think having actual scoping is the interesting part
<joepie91>
someone I haven't spoken to in a literal decade has just appeared, so I'm going to have to excuse myself from this discussion :D
<__monty__>
I'm not sure what scoping you're talking about tbh. Do you mean the sandboxy behavior the nix store gives us?
<MichaelRaskin>
Well, you can call it sandboxy, although outside builds it's pretty weak from that point of view
<MichaelRaskin>
But yes, it allows me to call different things «glibc» in different contexts
<__monty__>
I look at that more as parametricity than scoping.
<MichaelRaskin>
You can have parametricity with Puppet just fine
<MichaelRaskin>
But the parameters of different calls end up colliding in the global storage there
<__monty__>
Then that's not what I understand when I hear parametricity.
<__monty__>
Now I understand why you focus on scoping though.
<MichaelRaskin>
Maybe you just take scoping for granted? And maybe you normally refuse to discuss parametric recipes when the situation is not sane enough for avoidance of silly collisions
<pie_>
joepie91, dont suppose youve ever seen an irc client that has bookmarks
<Shados>
MichaelRaskin: From my perspective, nixos configuration isn't primarily about modelling global variables, that's an unintentional (and terrible) downside. I *think* it's primarily modelling mutually-recursive late-bound attribute sets
<MichaelRaskin>
Well, it's about intention and outcome
<joepie91>
pie_: define 'bookmarks'
<MichaelRaskin>
The intent seems to be in the direction of aspect-oriented system definition I guess?
<MichaelRaskin>
The result has some properties typically associated with global variables in imperative programs…
<pie_>
isnt that unavoidable if you want a top level system config? its...inherently global
<pie_>
joepie91, markers in logs i can label and jump back to
<pie_>
ive never seem what "proper" aspect oriented stuff i slike
<MichaelRaskin>
I think it just doesn't exist
<MichaelRaskin>
pie_: well, it depends on what you want from your system config…
<MichaelRaskin>
System is just a package in NixOS anyway, so it could be closer to buildEnv
<MichaelRaskin>
Which limits (or makes it more explicit?) the possibilities of configuration, sure
<pie_>
"limitations arent always bad"
wavirc22 has quit [Remote host closed the connection]
endformationage has joined #nixos-chat
<MichaelRaskin>
Especially given that NixOS config limits the abstractions anyway, just in a different way
<Shados>
pie_: Not necessarily. The current problematic bits are things like... every module can modify every other module. Which means you can't securely re-use third-party modules. If there was, say, a hierarchical module system where modules could only modify modules beneath them, then that wouldn't be the case, and the user could still manage system config from the top level.
<joepie91>
pie_: ah, nope, unfortunately not then :(
<Shados>
(or more flexibly where module modification was moderated through a shared parent module, or whatever; dream up some system :P)
<joepie91>
pie_: it's on my list of "shit I want to exist" though :P
<pie_>
Shados, securely using 3rd party modules would be cool, might also mean you can import user configs
<Shados>
Yeah.
<MichaelRaskin>
Fun stuff: and then some modules still use enough let expressions that using that extreme override flexibility for whatever you actually want might still be hard
<pie_>
)Shados, also something something capability system)
<pie_>
MichaelRaskin, huuuuuge pet peeve there.
<Shados>
(pie_, I was slightly thinking of Genode with my "ore more flexibly" comment, haha)
<Shados>
*or
<MichaelRaskin>
Well, if you structure your system like Nixpkgs, not NixOS, your service definitions go halfway towards a capability system
<MichaelRaskin>
(The second part needs runtime sandboxing, maybe with nsjail or something like that )
<pie_>
Shados, which more flexibility comment, also yeah genodes been in the back of my mind the whole time, havent had time to play with it. Or Virtualization Or Containers or ISOLATION-FLAVOR
<pie_>
nsjail, selinux, apparmor, seccomp, etc
<pie_>
its feasible, just need to get people spare cycles to actually design something :V
<MichaelRaskin>
Note that nsjail provides you with easy scoping/putting things at desired names/whatever, and selinux/apparmor doesn't
<MichaelRaskin>
Well, I would say NixOS is moving _further_ from it, not closer
<pie_>
:(
<pie_>
yeah?
<pie_>
design decisions or just accumulating mass?
<MichaelRaskin>
Old NixOS config was more limited but less magic
<pie_>
ah yeah. :/
<pie_>
things tend toward more abstractions but also increasing complexity
<pie_>
i mean, you need moar features so its kind of inevitable...
<MichaelRaskin>
Well, the way Nixpkgs is structured is kind of better
<pie_>
yeah but nixpkgs doesnt have runtime state?
<pie_>
hmm ok maybe thats orthogonal
<MichaelRaskin>
Not really relevant
<MichaelRaskin>
Yeah
<pie_>
packages dont have interactions
<MichaelRaskin>
I mean, if you run Firefox it will surely bring runtime state into your $HOME
<MichaelRaskin>
Tell me more about buildEnv and python.withPackages etc.
<MichaelRaskin>
And QT
<pie_>
*arent designed to have interactions? :P
<MichaelRaskin>
Tell me even more about Qt!
* pie_
shrugs cluelessly xD
<MichaelRaskin>
And now everything is tied together in NixOS
<MichaelRaskin>
The package logic
<MichaelRaskin>
I mean, actual config generation
<MichaelRaskin>
How it interacts with the module system
<MichaelRaskin>
How it interacts with systemd
<pie_>
unless you implement things in a fundamentally principled way sure that you cant violate things like independence...youre going to violate them :(
<pie_>
i guess its why functional purity is so good
<pie_>
youd have to express "cannot rely on this" somehow
<MichaelRaskin>
Well, they are intertwined «by design or lack thereof» now
<pie_>
yeah
<MichaelRaskin>
We seem to manage NixOS assumptions in Nixpkgs though
<pie_>
the lack of diversity in fully supported systems is probably related in both directions
<pie_>
though thankfully our automation helps
<pie_>
so...wat do? :c
<MichaelRaskin>
Give up on mainline, write your own bootscripts
<MichaelRaskin>
(that's what I do)
<pie_>
sounds hard and or involved
<MichaelRaskin>
We need some experience from stupid trick attempts
<pie_>
if you mean people trying weird things, ive heard of some cases, needs more aggregation :V
<MichaelRaskin>
I think right now we still need more content to aggregate
<pie_>
more articles! more librarians! nevermind who is going to be able to read all the stuff :D
<pie_>
still need to write that nixos from scratch series :p
<MichaelRaskin>
Actually, making stdenv build is the hard part, bootscripts are easier
<MichaelRaskin>
And NixOS module system can be abused to more or less access most config-generating functions without using NixOS proper
<pie_>
not sure if thats abuse
<MichaelRaskin>
I have a feeling that everything having to do with the module system is abuse…
<pie_>
ah...
<pie_>
im still missing alternative...
<pie_>
well ok i guess that was the namespacing services.
<pie_>
but modules as a concept and that seems orthogonal
<MichaelRaskin>
Yes
<MichaelRaskin>
If we had a separate library of parametric config-generating functions, module system would be more opt-in
<pie_>
im looking forward to declarative scale-invariant plugboards :P
<pie_>
</tangent>
<pie_>
I dont follow
<MichaelRaskin>
Well, whatever you do with services you need to generate configs
<pie_>
you mean functions that speak various config formats, and then
<pie_>
yeah ok
<pie_>
i think thats something we should do anyway
<pie_>
would help clean up the code?
<MichaelRaskin>
Might be
<MichaelRaskin>
Also might unify the code for homemanager and for NixOS
<pie_>
one of the problems is probably that everyone has their own variants on config syntax thoguh
<MichaelRaskin>
Well, many of them are related
<pie_>
but there is probably enough identical implementations to get sufficiend negative code delta to be worth it
<MichaelRaskin>
And then, the library of dialect-handling routines per-service could still be a separate thing
<pie_>
osmething something i think "generators" are supposed to be in this direction?
<pie_>
yeah, imo this would be something we want in any case
<pie_>
more abstractions -> more core complexity but less peripheral complexity
<pie_>
^ something thats bothering me because its exactly what im trying to do right now
<infinisil>
It's an interaction of not using new-style builds yet, an internal library depending on the non-internal library, and wanting to generate docs with haddock
<infinisil>
It might be worth looking into switching nixpkgs to use new-style builds
<__monty__>
Hmm, good catch. Not very surprising it slipped through the cracks.
<__monty__>
Definitely, though tbh I think nixpkgs haskell infra might benefit from being replaced with haskell.nix once that has all its kinks worked out.
<__monty__>
And I'm assuming they already do new-builds.
fmsbeekmans has joined #nixos-chat
<infinisil>
__monty__: I was just wondering if haskell.nix supported it
<infinisil>
I also can't switch to new-build just yet because haskell-ide-engine still has some problems with it afaik
<__monty__>
I'd be surprised if a company interested in both haskell and nix published a system based on old-build though.
<__monty__>
Is that really a problem? Oh, in its analysis? I was thinking just install that with old-install and use new-build for projects.
<infinisil>
__monty__: HIE doesn't support the cabal.project files well I think
<infinisil>
Also HIE seems to have problems with multiple components, even with old-style builds :(
<__monty__>
I've never bothered. Never seemed like it gives me much over and above fast-tags, ghcid and hlint.
<infinisil>
__monty__: Being able to view the type of expressions is really nice, and autocompletion too. And there's more features I'm not even using yet which would be nice, like the recently introduced auto-import feature (automatically suggest library imports for unknown symbols)
<__monty__>
I have autocompletion. And type holes are pretty comfortable with ghcid.
<__monty__>
Not at the point where I need auto-imports yet.
fmsbeekmans has quit [Remote host closed the connection]
<infinisil>
Hm yeah type holes are nice
<__monty__>
But I do understand wanting an all-in-one experience. Not dissing HIE.
<infinisil>
I actually often end up using ghci on the side anyways
<__monty__>
Did you check out the icfp contest?
kraem has quit [Ping timeout: 268 seconds]
<infinisil>
__monty__: Nope, what's it about?
<infinisil>
Or what was it about?
<__monty__>
I figure you might like it since you participated in AoC. The assignment was pretty cool. Very hard though.
kraem has joined #nixos-chat
<__monty__>
nn, infinisil
<__monty__>
nn, everyone else
<infinisil>
Neat
<infinisil>
Recently I'm more interested in coding actually useful things though :P