We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Rethinking basic primitives for store based systems Q&A

00:00

Formal Metadata

Title
Rethinking basic primitives for store based systems Q&A
Title of Series
Number of Parts
28
Author
License
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Addressing modeModule (mathematics)Roundness (object)Software testingInheritance (object-oriented programming)BootingTrailHeegaard splittingDynamical systemMathematicsControl flowPatch (Unix)Run time (program lifecycle phase)File formatMultiplicationDecision theoryComplete graphComplex (psychology)MehrplatzsystemLinker (computing)Kernel (computing)Variety (linguistics)Uniform resource locatorThumbnailInterpreter (computing)Standard deviationDistribution (mathematics)HorizonSlide ruleLevel (video gaming)MereologySheaf (mathematics)Grand Unified TheoryMeeting/Interview
Transcript: English(auto-generated)
So we're going to try this.
I have no sound yet. Yeah, okay. Can you unmute me real quick? Okay. I'm sorry, Fareed, but I'm going to mute you for just a second. There we go. So Fareed, it's no longer audible. The thing is, we're going to try the Q&A. I hope Fareed can hear us as well. We're going through multiple layers of IP currently,
so there's some delay in there. Yeah. Yeah, it's a new experience here. Okay, sure. So is there a question currently? Yes, I'll go to the very back.
So we just pick your question and then we'll unmute and then hopefully it'll come through eventually. Hey, so that was fascinating, thank you. You're proposing a new dynamic loader, which is like a really exciting and intriguing idea, but how would that work if Nix is installed in a single user fashion?
Because you wouldn't be able to put that in a well-known location, right? So do you have any idea on how that could be possible? Or would that be a split between the Nixos world where we do have this loader installed somewhere and the rest of the Nix world where that might not be the case? Thanks.
Can you guys hear me? Test, test. Yeah? Oh, okay.
I'm sure there's some light. Thanks for letting me do this remote. It's also in the morning, so if I say something wrong, it's because I haven't had any coffee yet. So the idea I think could work in both the Linux distribution of Nix as well as Nixos, the dynamic linker is set in the interpreter path. So it doesn't need to be in a well-known location.
So the dynamic linker could be specified as part of the base installation of Nix. I think the last slide also mentions not only is there the opportunity to write a dynamic linker, but even perhaps pursue on our own executable format. I think there's a variety of ways to do that.
Most likely would need Nixos because you could write a kernel module to support a new format. I'm still thinking through whether you need a new format or you can kind of like at runtime patch up elf from this expanded way with our own custom dynamic linker. I mean, the challenge there is it's a lot more
complexity doing it faking elf. The real premise of the talk is I think that's okay at the start. Nix has always been great at pragmatic decisions to start and that would be one. Just do a dynamic linker first, don't do a new executable format, but longer term. The talk is saying Nix can be more pervasive
and more deeper and challenge all these status quos that I think whether we take for granted or we just see and we assume can't change. And Nix is really letting us change everything from the ground up.
Thank you for it.
Okay, from the beginning. Yeah, thank you for doing this. I'm glad to see that the issues, there's a gleam of light on the horizon
for the issue that I opened five years ago. Do you think it would make sense to extend the existing elf format rather than to come up with a new one given that, I mean, it's happened in the past. We now have run path and our path when we used to have only our path, which behaves strangely. So I think there's the other people can benefit
more from it if we extend the existing standard. Someone give me a thumb up, can you guys hear me? I need to know when to speak.
Test, test, okay. I might say some foot in mouth answer here. Okay, my gut is no. Elf is already extremely configurable. It has no, it's like the FHS, it's all convention.
It's really just a section of containers. And by design, things have come up in tags that mean specific things. Adding more to that convention seems to go against the problem. My approach is we can have very targeted tooling
that works extremely well for Nix rather than putting a diaspora of things that work well together. Why do we wanna use tooling that has support for run path and our path? And I don't know if you know this, but our path only works at the top level of the graph, run path works like parent change through your ancestry.
I mean, it's just mind boggling to try to keep track of all these different things. When we could just do something super simple because in Nix, you know the full graph. You know everything you're gonna link to. Like a lot of these problems can be solved.
So I guess my answer would be no. Yeah, but I mean, yeah, at least to start and then it's just such an uphill battle I'm sure to extend Elf and I don't know what kind of consortium you need to do that.
Okay, thank you, Fareed. Fareed, we can no longer hear you. I'm terribly sorry, but we have to move on. So if I can get one more round of applause for first of all the hacky setup and for Fareed as well.
Okay, we're gonna have a five minute break.