<exarkun1>
Trying to boot sd-image-aarch64-linux with qemu-system-aarch4 and the qemu arm defconfig boot dtb. Boot fails with "Bad Linux ARM zImage magic!". Anyone have any tips on this?
<samueldr>
the second build product, click Help to get a store path for the -fd output of an aarch64 OVMF
<samueldr>
is you want to try that way
<samueldr>
not saying it'll fit your needs (I don't know them), but that's an alternative
<exarkun1>
I guess I have approximately no idea what any of that means. Guess I should learn something about EFI?
<exarkun1>
I find this area of the system is difficult to break in to. If you know of any documentation resources that cover it, I'd appreciate any suggestions.
<samueldr>
the good thing is that with qemu, booting an EFI image is the same for x86_64 and aarch64 (and also for x86 and armv7l)
<samueldr>
the main difference is that it needs a bios built for the specific arch
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej has joined #nixos-aarch64
efraim_ is now known as efraim
zupo has joined #nixos-aarch64
jtojnar has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<makefu>
btw is it currently possible to cross a complete system derivation? even though there is no way to "upgrade" on the system itself it should still be possible to cross-compile the update, nix-copy-closure it and activate it via nix-env, right?
<gchristensen>
there is trouble with perl not cross compiling
<exarkun1>
Indeed. I have tried cross-compiling a whole system a number of times and never gotten to the end.
<gchristensen>
there was a PR to rewrite the core perl pieces to python, but it failed for a few reasons. doing a rewrite is dangerous work, niksnut'd prefer moving to a stricter language (he told me Rust would be okay)
<gchristensen>
if anyone wants to take this on, I wrote a pretty good fstab parser, thinking about it :)
<makefu>
i like the idea of having a stricter language for the glue code, especially if it provides us with the means to cross a complete system :)
<gchristensen>
+1
<exarkun1>
Rust sure seems popular now.
<gchristensen>
C++ could work too
<exarkun1>
Eessh.
<exarkun1>
I'm surprised there isn't more focus on a functional language.
<exarkun1>
Functional languages only good for toy projects like package/system management? ;)
<gchristensen>
lol
<gchristensen>
any nice FP langs you like, which produce small binaries?
<exarkun1>
intentional goal-post moving (we were discussing cross-compilation, not binary size), unintentional goal-post moving, or is there a set of requirements for the core nix tools written up somewhere that I should look at?
<gchristensen>
there is a set of requirements
<gchristensen>
a major goal of Eelco's is keeping minimal closure sizes small
<exarkun1>
How large is the current nix toolchain implementation, including the set of perl packages required to use it? I'd be surprised if there weren't a mainstream functional language runtime that could produce executables in smaller space.
<gchristensen>
this isn't about Nix's toolchain, but about what is present on the minimal NixOS system
<gchristensen>
for example, we can't use java's (excellent) XML tooling in the nixos docs by default because users often have to rebuild docs when they change their system -- and java is a large dependency
<gchristensen>
correction: this isn't about Nix's toolchain, but about what is required to build the minimal NixOS system
<gchristensen>
_and_ what is present in the final image
<exarkun1>
can we use "toolchain" as shorthand for "what is required to build the minimal NixOS system"? Or does that have another name?
<gchristensen>
sure, the point of confusion was you said "nix toolchain" :)
<exarkun1>
ok, sorry
<gchristensen>
and this isn't about nix
<exarkun1>
it was sloppy of me, indeed.
<gchristensen>
(note: before going off and building a new implementation in a language different from Rust or C++ I'd recommend getting a +1)
<exarkun1>
So if the perl tools are ported to C++ then the size of the C++ compiler is a factor here?
<gchristensen>
mmm not sure
<exarkun1>
Don't worry there's -13% chance that I'm going to reimplement anything in the next 5 years
<gchristensen>
:)
<gchristensen>
it might be reasonable to expect that the tool is fetched from hydra and not rebuilt when you build your system
<gchristensen>
(this is not currently true because the perl scripts are regenerated each time the system is built, whereas a compiled version would likely accept these values as run-time parameters)
<gchristensen>
in the case of fetching a prebuilt artifact, the important factor is size of the final product
<exarkun1>
Okay. So a large build-time toolchain for the implementation language of the relevant artifacts (we're talking about, like, `nix-env` and such, right?) isn't necessarily a disqualifying factor.
<gchristensen>
it would be disqualifying if it is common to need to rebuild them
<gchristensen>
(see the java bits)
<gchristensen>
but not necessarily, right
<exarkun1>
right, okay. So needing the build-time toolchain for the implementation language of the relevant artifacts is disqualifying if that toolchain is large.
<exarkun1>
But if either you don't need it or it isn't large, it's okay
<exarkun1>
(whatever "large" means)
<gchristensen>
pretty much
<exarkun1>
thanks for the insight
<gchristensen>
also probably some qualitative "fitness of purpose" to be part of the judgement. brainfuck would not be a good choice. Idris would probably not be a good choice
<exarkun1>
certainly. probably a number of other requirements as well. eg, platform support.
<gchristensen>
right
<gchristensen>
ah, yes! definitely :)
<exarkun1>
and maybe it would even be nice if cross-compilation was supported! ;)
<gchristensen>
oh, right, that!
<gchristensen>
also a preference for tools which are already part of the toolchain... since the users will already have them ... but... yeah.
<andi->
LLVM-IR? :)
<gchristensen>
yes
<andi->
I would rate that more closely to brainfuck but thats my feeling.
* samueldr
wonders about perl to LLVM-IR
<andi->
there used to be a Perl to C "transpiler"
<andi->
not sure what it did.. I expect it to have bundled a interpreter and the script in an ELF file..
<exarkun1>
Somehow I think that might be a step in the wrong direction
<andi->
My serious thoughts about a replacement are somewhat split.. Moving to a language higher up the "stack" of dependencies/abstractions/… means we will have very frequent rebuilds and many dependencies that can break rebuilds. Looking at how we currently build rust packages I do not like either approach for such a basic component.. I think the optimal solution (for my current view) would be more towards
<andi->
C and C++. Rust would certainly be great for safety/ease of mind/…. 🤔
<samueldr>
is Rust useful without dependencies or whatever the "current;u build rust packages" means?
<andi->
It could be but you easily end up in a position where using a crate is favorable over reimplementing things. There is stuff other langauges have in the sdlib that was put into crates on purpose - for good reason IMO..
<andi->
you can also "vendor" all of them (preverably not with the fixed output "hack" we have currently..
<gchristensen>
carnix is not any fun at all
<samueldr>
I'm sure treating first-party code differently than third-party is a thing that can be argued, possibly with success
<gchristensen>
the cargo256 hash thing we do now is pretty nice, actually
<gchristensen>
UX wise
<andi->
i have some ongoing off-on discussion with tazjin regarding rewriting the carnix code generator... That is the most painful part fo us.. It breaks in many curious ways and lacks any kind of tests..
<gchristensen>
+1
<exarkun1>
andi-: I think you can separate "dependencies" from "abstractions". A higher-level language should let you have less churn. Choosing to use fewer outside dependencies should let you have less churn. You can make those decisions somewhat independently.
<andi->
yes UX wise until it shadows a segfault in the tool used ;)
<gchristensen>
every time I bump ofborg's deps it is hours of remembering how I use it
* samueldr
has about zero experience with the rust thingies
<samueldr>
only overhead things
<andi->
I gave up on my nix security tooling because of the carnix experience.. Doesn't help that I rewrote it all but can't deploy it because of syntax errors in the generated nix.
<gchristensen>
:|
<andi->
anyway, I think C++ or rust a good alternatives.. it is a tradeoff (as always).
<andi->
one good thing about the python port was that all of the dependencies were in the standard lib...
<gchristensen>
wouldn't know that until it is done :P
<gchristensen>
the nixos tools are not so complicated, it is possible they won't require external deps
* andi-
checks his crytal ball
<gchristensen>
> Ask again later
<{^_^}>
undefined variable 'Ask' at (string):222:1
zupo has joined #nixos-aarch64
<andi->
if you think about things like the grub installer that take full blown XML as an input you probably wont get away with just commandline arguments. Having something like a JSON parser in the stdlib makes that easier..
<gchristensen>
ah true
<gchristensen>
let's start the meme RWiiB
<samueldr>
RWiiB?
<andi->
rewrite in bash? (where is the 2nd i?)
<samueldr>
it in
<andi->
i know but makes no sense to me
<gchristensen>
bash ;)
<samueldr>
rewriting it in bash or the "it in" ? :)
<samueldr>
werll
<samueldr>
well*
<andi->
samueldr: I'd say both :)
<samueldr>
that sure would reduce the closure size
<gchristensen>
the first mis-qualified `rm -rf` would reduce a lot of closures' sizes
<samueldr>
your store is rw?
<gchristensen>
some of those scripts run before /nix/store is remounted ro
<samueldr>
:)
<gchristensen>
:)
<andi->
preload a library that prohibits file removal!
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]