<abathur>
this overlaps with a few tricky questions about how to make command handling more modular/extensible. I needed to just get something basic working. I'm specifying two file/exchange formats, one for indicating how likely a given executable is to sub-exec, and one for indicating that a specific argument in a specific invocation does
<abathur>
so this actual version here is fairly manual, I'm generating those input files to tell it that 'find' is a known execer (but none of the others) and to specify that argument before invoking
<abathur>
I've got a few ~working external tools for generating the first of those two formats from the nix inputs, but I needed to start somewhere a little simpler
patagonicus1 has joined #nixos-chat
<abathur>
it shouldn't be too hard to switch that first part over to the external tool version now that I have working test-cases
<abathur>
the second part is basically the backstop--how a user would manually triage arguments to a likely execer that resholve can't ~parse; when I figure out how I want to handle individual commands, I intend to fill in support for the most common builtin/external sub-execers in front of that so that the manual override is hopefully not needed too often
<gchristensen>
that is fantastic
<gchristensen>
I love it
<abathur>
but IDK what the tail looks like; if it starts to look like it'll end up carrying a complex catalogue of argument parsing rules I'll probably just focus on the ergonomics of the manual override :)
<gchristensen>
:)
<gchristensen>
I'm off to bed... really great, I'm excited to see more of this
<abathur>
night <3 gchristensen
<{^_^}>
gchristensen's karma got increased to 461
<gchristensen>
<3 abathur :)
<{^_^}>
abathur's karma got increased to 27
<tomberek>
abathur: is the point that patchShebangs is more complete?
<eyJhb>
sphalerite: Exactly. I need to make a list.
<eyJhb>
infinisil: After I have looked at your do-image-updater, I have come to the conclusion, that Nix needs a `requests.nix`. :p Just for creating curl queries (would be cool)
__monty__ has joined #nixos-chat
<tazjin>
colemickens: I'm very interested in reading this
<colemickens>
It wound up not being appropriate for the thread. tl;dr I wish there was a roadmap for flakes, because I can't go back to non-pure-eval/flakes, but I also sympathize with those unwilling to commit to a moving target
<tazjin>
why can't you go back? I'm a bit shocked by how much stuff suddenly depends on experimental features, I think the ecosystem has taken a huge hit because of this
<colemickens>
Because it makes life that much better? and because any non-flake user can use flakes stuff
<tazjin>
also the presence of the flake-utils lib and it being used almost everywhere seems to point towards some severe deficiency in the concept as it stands, this makes me uneasy
<colemickens>
whereas the opposite is not true, again due to pure-eval
<colemickens>
I don't use flake-utils, but I understand the criticism
<colemickens>
but also look at nix stdlib and nixpkgs stdlib, its all a mess
<colemickens>
at least flakes makes it not-awful to compose
<colemickens>
every nixpkgs-wayland user uses flakes, effectively
* colemickens
unpopular opinion flakes-util exists because nameValuePair and genAttrs are in nixpkgs and not nix stdlib
<colemickens>
how has "the ecosystem take a huge hit" because of flakes?
<tazjin>
colemickens: every project that switches to flakes contributes to a fracture in the community where, if you don't want to use unstable features, the only choice you have (currently) is using a semi-compatible compatibility shim maintained by a single person
<tazjin>
and because so many projects (and, I assume, also customers of Tweag) have started using this it'll be very difficult to make significant changes to the concept again
<colemickens>
there's no such fracture
<colemickens>
meanwhile, life is better for me
<colemickens>
I don't understand what I'm supposed to practically do with what you just said
<tazjin>
you personally? nothing, probably - I'm just telling you my view, not asking for any action :p
<colemickens>
The thread in Discourse, people are expressing like, actual suggestions.
<colemickens>
That, I understand.
<colemickens>
But, I guess I just don't understand this, "it's not stable"
<colemickens>
IT feels like "drugs are bad because they're illegal"
<tazjin>
flakes are in a superposition of "this is officially unstable, but we've committed to doing exactly this"
<colemickens>
I understand there's more nuance to it than that, but it solves practical problems for me and advances the Nix UI in a way, in a time, that is very needed.
<colemickens>
that doesn't outweigh the benefits, for me.
<colemickens>
I'd rather take this as a step than whatever it is ... I'm not even sure what should happen instead? nothing?
<joepie91>
yeah I think I agree with colemickens here, the situation kinda sucks but not addressing the lingering issues sucks more
<joepie91>
and I say that as someone not yet using flakes but only having looked at the design/purpose/etc.
<tazjin>
I'd like to see: taking a step back, listing which benefits people got from the experiment in practice, listing which flaws were observed (like stuff that flake-utils forced), proposing a new design iteration (without committing to using the current experimentation in a sunk-cost fallacy way)
<colemickens>
have you looked at what flakes-util is?
<tazjin>
yes
<colemickens>
put genAttrs in nix stdlib, there is almost no reason for flakes-util
<colemickens>
I use flakes in like 4 projects, it's really not some necessity
<colemickens>
anyway, I'm being overly defensive, that's not helpful at all
<colemickens>
But, I don't see why you can't go offer critiques and designs now. Wanting people to stop using something that is solving problems for them, in order to start designing something better is confusing, to me.
<tazjin>
well, that situation is sort of a result of the drama surrounding the original RFC, we could have committed to saying "we'll run this experiment for $time and then do $procedure to evaluate what we learned", but instead the RFC was closed and we said "lets see what happens"
<tazjin>
now significant changes are unlikely to still happen (a la Haskell's "avoid success at all costs" thing), which means that I *personally* am mostly interested in making sure that flakes doesn't require language changes or evaluator support (i.e. "flake-compat" can always be written in pure Nix)
<DigitalKiwi>
error: 'info' is not a recognised command
<DigitalKiwi>
most of the flakes being experimental seems to be stuff like that
<DigitalKiwi>
and renaming develop/shell or w/e
<colemickens>
tazjin: I would say that I assume that was a given, but have no reason to believe that now that I'm considering it.
<colemickens>
yeah, hm, I guess I just had assumed that was out of the question
<tazjin>
which part?
<NinjaTrappeur>
colemickens: To answer your discourse question "what are these". To me, the main issue is the poor UX design of flakes. Want backward compatibility? you need to pull a first external lib (flakes-compat). Want a sensible way to declare your flake? You're up to import a second external lib (flake-utils). Want to patch a upstream flake before importing it? You're up to rely on a third library and
<NinjaTrappeur>
import flake-utils-extra.
<NinjaTrappeur>
This splitted code encourage adding more nix to the equation.
<NinjaTrappeur>
And from my experience, too much nix is a clear antipattern. (that's a subjective opinion, I rekon)
<NinjaTrappeur>
I'm using nix to glue npm-grade distributed monstruosity.
<NinjaTrappeur>
Ending up doing the same npm-grade pattern in Nix makes me highly dubious wrt. flakes.
<colemickens>
tazjin: I had assumed that something like flakes-compat would always exist and always be usable from stable nix.
<NinjaTrappeur>
They seem to be highly-optimized towards a single workflow and try to fix too much stuff at the same time to me (pure eval + code distribution + standardized entry point).
<NinjaTrappeur>
sorry for responding on IRC, I'm not really willing to invest time to monitor the discourse answers :)
<joepie91>
NinjaTrappeur: the npm approach works extremely well actually
<joepie91>
that is, if you actually use the npm approach and don't try to emulate another language's dependency model with it
* colemickens
wonders how his poor flakes survive without these utils
<joepie91>
ie. you don't try to 'avoid dependencies' and add a few big ones
<NinjaTrappeur>
joepie91: I'm affraid we'll have to agree on disagree on that one :)
<colemickens>
NinjaTrappeur: can I copy/paste this into Discourse and attribute it to "NinjaTrappeur"?
<NinjaTrappeur>
*to
<NinjaTrappeur>
you can but I won't answer further.
<colemickens>
I can not attribute it to you too, if you'd prefer.
<NinjaTrappeur>
This chat is public ;)
<joepie91>
shrug. I've heard large amounts of people complain about npm, but the common theme is that none of them ever seem to really understand the dependency model, and the issues they complain about basically always originate from the dependencies that violate the dependency model
<colemickens>
fair enough!
<joepie91>
and a vast chunk of the complaints seem to literally be "it doesn't work like in other languages" but with a layer of indirection via "it does weird things [because I am making assumptions about how it works that do not apply in npm]"
* DigitalKiwi
doubts your authenticity; i believe you are neither a ninja or a fur trader!
<NinjaTrappeur>
damn, you got me :P
<colemickens>
tazjin: thank you for elaborating, I'm glad I was able to understand. If you also are not interested in posting on Discourse I could simply express my own hopes that flakes stay usable from stable nix evaluations.
<NinjaTrappeur>
joepie91: my main complain about npm is that it makes pretty hard to have a clear understanding of your overall dependency tree and hard to patch them.
<joepie91>
NinjaTrappeur: what do you mean with "understanding" exactly?
<NinjaTrappeur>
ok, let's take that the other way.
<NinjaTrappeur>
Your dependency tree depth is going to get pretty big real quick.
<joepie91>
NinjaTrappeur: yes, that is correct.
<NinjaTrappeur>
The issue is not tool-specific, it's about the package granularity and their high level of connectivity (ie. lot of deps)
<joepie91>
that's a feature, not a bug
<NinjaTrappeur>
That's why I proposed to agree to disagree.
<joepie91>
DigitalKiwi: anything that treats "a dependency" as a unit of cost irrespective of its size or complexity is basically automatically not a credible argument :)
<joepie91>
on a very fundamental level, at least; in some languages it may be partially a unit of cost due to language design decisions
<joepie91>
but JS is not one of those
<DigitalKiwi>
i didn't mean it to be a comment about js at all it just reminded me of it
<joepie91>
I'm making the comment because that post unfortunately seems to be making exactly this error
<joepie91>
like most posts about dependency complexity, tbh
<joepie91>
"dependency mechanics are really poorly understood" applies not only on a package management level....
<joepie91>
:(
<joepie91>
it saddens me how much cargo culting there is around what's probably one of the most promising mechanisms for making tech benefit the public commons
<__monty__>
Fwiw, in the haskell world the arguments do hold.
<__monty__>
That's unfortunate but we don't get to ignore it .
<DigitalKiwi>
the whole "only one instance" thing right?
<joepie91>
ok, quite possibly, I'm not familiar with the exact technical design of dependencies in Haskell
<joepie91>
oh, Haskell only supports a single version of any given dep? yeah, then a dependency is a unit of cost
<DigitalKiwi>
also when ghc gets updated...
<NinjaTrappeur>
joepie91: if you want to make your point, I'd be interested in seeing the nodePackages performance situation getting fixed. Building a material-ui + reactjs project takes about 12 minutes on my ryzen7 desktop.
<joepie91>
NinjaTrappeur: what does "building" mean here, exactly? because merely installing the packages for a large production Node project is typically measured in seconds, not minutes
<NinjaTrappeur>
nix-build
<NinjaTrappeur>
Great news! Looking forward for the fix then, it'll greatly improve my day to day life.
<joepie91>
ok, but what does it do behind the scenes? because I've noticed yarn2nix-based builds being significantly slower than a normal npm/yarn install, but not that significantly slower
<joepie91>
NinjaTrappeur: to be clear, this is not a problem with Node, but with Nix's Node tooling
<joepie91>
if you remove Nix from the equation the problem does not exist
<NinjaTrappeur>
could you have a look?
<NinjaTrappeur>
I can provide you with a package.json and webpack config if needed
<joepie91>
I honestly don't have the time or energy to work on fixing performance issues in Nix tooling that I am totally unfamiliar with
<joepie91>
also, if the build involves webpack then that is a much more likely source of issues
<joepie91>
some webpack configurations result in weirdly high build times
<NinjaTrappeur>
ok
<NinjaTrappeur>
I'll keep my current opinion on npm then ;)
<joepie91>
???
<joepie91>
I literally just told you that the problem is not with npm
<NinjaTrappeur>
(the package set, not the tool ofc)
<joepie91>
also, regarding webpack, there are profiling tools for determining where all the build time goes
<gchristensen>
anyone want to write a trivial systemd stuff for ofborg? :) have a timer that runs every 10 minutes and runs `systemctl restart x.service` if available disk space is <5G
<gchristensen>
the good ops right here
Synthetica has joined #nixos-chat
<hexa->
looking
<gchristensen>
I'm being punished here by this one mac having a smaller hard disk than allll the rest
<samueldr>
with that, you can take the USB UEFI image and **just do a normal install**
<hodapp>
hm, how many ARM-based distros have UEFI installers?
<samueldr>
standards-based boot on SBCs is the future, whether you like it or not
<srk>
hodapp: SUSE was doing that for some time as well
* lukegb
gets "please dear god everyone should just use UEFI and stop doing ~~weird shit~~" vibes from samueldr
<samueldr>
hodapp: at least 5
<samueldr>
NixOS, Fedora, SUSE, ubuntu, debian
<samueldr>
unclear what alpine's UEFI iso is
<samueldr>
(I couldn't boot it on my test board the other day)
<samueldr>
lukegb: you're good
<lukegb>
would you like to buy my BSP? it comes with a 10 year old Linux kernel version with a random collection of patches and security vulnerabilities
<samueldr>
hodapp: perfect, where do you think device tree comes from?
<hodapp>
the device ground
<hodapp>
and device seeds
<samueldr>
:)
<srk>
and a bit of forth :D
<samueldr>
so you can have UEFI **and** device tree!
<hodapp>
kinda want to score an old Itanium box and play around...
<lukegb>
ARM-based distros will probably get UEFI installers once VMware-for-M1 launches tbf
<samueldr>
lukegb: they already do
<samueldr>
from before then
<hodapp>
what's the connection with VMware and UEFI?
<lukegb>
sorry, I mean, more of them :P
<samueldr>
and I kind of think that no
<samueldr>
they will instead provide vhds
<samueldr>
because that's what most distros do for ARM
<samueldr>
just make a prebuilt image targeting a specific board
<samueldr>
now you have n insecure images with default credentials
<samueldr>
and poor customisation
<lukegb>
VMware's _only_ targeting booting Linux on macOS VMs at the moment - Windows is out, because you can't get a license for ARM Windows, and macOS is out because their boot process is arcane and undocumented
<samueldr>
want to partition/format it differently? :)
<samueldr>
btw, I was playing with UEFI boot, and it's not a pipe dream, it works... almost without hitches 100% of the way
<samueldr>
for other distros
<samueldr>
for NixOS?
<samueldr>
it works 100% of the way
<samueldr>
well
<samueldr>
well, well as in it works well
<Ke>
why would EFI boot not work
<Ke>
I don't think the issue ever has been not working
<Ke>
unless you mean unpatched kernels, maybe then
<samueldr>
many reasons
<samueldr>
but you're starting with the assumption that the target machine does UEFI boot
<samueldr>
which on SBCs is neither the default, nor the expectation
<samueldr>
so people assume (wrongly) that UEFI doesn't work on ARM
<samueldr>
and then there are the "UEFI sceptics", those that think legacy boot is so much better and all that jazz that comes in muddying up the water
<samueldr>
I've seen people say things like "why would you use something as complicated on UEFI just to boot a raspberry pi??"
<samueldr>
which confuses me greatly
<samueldr>
considering the vendor boot flow for the raspberry pi is one overcomplicated mess that would be well served by a good firmare setup that boots in a standard way
<samueldr>
and then comes the issue that, apparently, maye **installers** fail to work well with some "incomplete" UEFI implementations
<samueldr>
e.g. if you take Debian's or Ubuntu's installers (both different!) they fail in mostly the same way
<samueldr>
they try to set their installed GRUB as the boot option using EFI vars
<samueldr>
that fails
<samueldr>
and then they abort the installation
<samueldr>
leaving you with an incomplete installation even though this can be worked around trivially
<samueldr>
Fedora's also complains, but lets you continue
rajivr has quit [Quit: Connection closed for inactivity]
waleee-cl has joined #nixos-chat
<MichaelRaskin>
Is it just me or is «Celebrite fell from someone's X» becoming a niche meme?
<gchristensen>
it surely is
<MichaelRaskin>
I wonder, is K9 + receiving an exploit as an attachment enough to trigger the issue
<das_j>
Hmm as anyone here ever experienced ENOMEM with execve()? I'm really clueless here on how that happens. There is enough physical memory available and I can run the same process from my shell
<MichaelRaskin>
What environment that execve runs in?
<das_j>
MichaelRaskin: A systemd service. But executing that parent process (icinga2) in my shell results in the same error
<MichaelRaskin>
I wonder if environment as in getenv matters
<MichaelRaskin>
I think there is a pretty achievable cap
<das_j>
Hmmm maybe. Let me check
<das_j>
Hmm probably no: 0x138d4700 /* 30 vars */
<das_j>
but strace won't show them by default, let me check the man page on how to fix that
<hodapp>
I've definitely seen skeptics of UEFI. It brings to mind one friend who is also a skeptic of Unicode...
<hodapp>
as for me I think I migrated my setup to pure EFI when I bought a compliant motherboard in 2013 or something
<lukegb>
I've seen some truly atrocious UEFI implementations that burned some people in the early days
<lukegb>
but mostly things seem to just work
<gchristensen>
supermicro's has very strange bugs as of last year
<MichaelRaskin>
To be fair, mostly things just work with booting the first 512 bytes as well
<hodapp>
I've seen my share of weird bugs there too
* hodapp
shouts loud enough for Compaq to hear
<hodapp>
I used to start Linux from DOS via loadlin...
<MichaelRaskin>
das_j: hmmmm. Apparently people manage to build container-like environments where ELF type of DYN (library first) fail to start as executables with ENOMEM
<lukegb>
hodapp: I love that so much HPE stuff still have Compaq references
<lukegb>
like their firmware updates being "RomPaq"s...
<hodapp>
hah
<hodapp>
didn't know that
<hodapp>
do any DEC references hang around still?
* lukegb
shrugs
<hodapp>
aww. I have a DEC coffee mug
<das_j>
MichaelRaskin: I found that as well but my binary looks pretty normal. I even removed the wrapper around it
<hodapp>
that says something like "digital is a software company" and lists 137 products with basically no record online of existing
<MichaelRaskin>
das_j: how deep you can drop ulimit before it starts complaining?
<das_j>
MichaelRaskin: which one?
<MichaelRaskin>
das_j: there are not that many, all of them!
<das_j>
oof
<MichaelRaskin>
I guess virtual memory size could be pushed low enough to fail just the initial mapping?