<unlmtd>
You can remove all references to 'God' and replace it with 'nature' or something like that. remember, this was written a while ago
<unlmtd>
Im not religious at all, but his logic is solid
<unlmtd>
Since an individual cannot lawfully use force against the person, liberty, or property of another individual, then the common force — for the same reason — cannot lawfully be used to destroy the person, liberty, or property of individuals or groups.
<unlmtd>
~ The Law, Bastiat
coconnor has quit [Ping timeout: 264 seconds]
<sphalerite>
looks like I missed an interesting discussion yesterday lol
<sphalerite>
unlmtd: I'm not sure about the muscle power thing you said. That's just solar energy, made useful in a rather roundabout way, no?
<sphalerite>
and I'm not an expert so I may be completely wrong, but I'm guessing the efficiency of that is a lot lower than that of PV or other ways of collecting solar energy
<MichaelRaskin>
sphalerite: well, if you assume you need to do _something_ with the people and you replace made-up office jobs with inefficient energy generation jobs… you still don't get theat much energy, but in a sense it is relatively cheap energy as you wanted to prevent starvation anyway.
<MichaelRaskin>
If you actually need non-trivially more energy than we have now, then of course you actually need to do something. Solar, maybe with consumption near production. Thorium.
goibhniu has joined #nixos-chat
IdleBot_4e8513a6 has joined #nixos-chat
MichaelRaskin has quit [Quit: MichaelRaskin]
<sphalerite>
Dyson sphere
<goibhniu>
wow
jtojnar has quit [Quit: jtojnar]
Synthetica has joined #nixos-chat
clefru has quit [Quit: Leaving]
goibhniu has quit [Ping timeout: 246 seconds]
Synthetica has quit [Quit: Connection closed for inactivity]
<gchristensen>
this is going to be a long day.
<gchristensen>
k8s.io/kubernetes]$ make
<gchristensen>
make: /bin/bash: Command not found
monotux has quit [Read error: Connection reset by peer]
monotux has joined #nixos-chat
MichaelRaskin has joined #nixos-chat
<MichaelRaskin>
Maybe you _have_ already installed NixOS?
<gchristensen>
huh?
<MichaelRaskin>
Well, if there is no /bin/bash on something Fedora-like, it _is_ going to be a _very_ long day. If the problem is that you have NixOS and something expects /bin/bash, there is a large set of quick-fix-scripts in NixPkgs to patch that.
<gchristensen>
ahh
<shlevy>
gchristensen: I managed to get kubelet building via a bunch of hoops starting from nix-shell
<shlevy>
Sounds like you're taking a saner approach :D
<gchristensen>
I don't know ... :)
Lisanna has quit [Quit: Lisanna]
dtz has joined #nixos-chat
* dtz
waves
<shlevy>
o/
<shlevy>
dtz: So re allmux and dynamic extensibility, I think we can have two levels. 1 which includes the modules in the allexe, and at dlopen time does dynamic dispatch and just registers the relevant ctors and dtors, and 2 which invovles a proper ABIDL (or perhaps multiple domain-specific ones)
<shlevy>
I imagine 2) could work via some kind of communication with the dynamic loader, so the non-allmux case would be completely identical at runtime
<shlevy>
But I'm not sure that's necessary
<dtz>
indeed
<shlevy>
I don't know what the dynamic loader will do if you dlopen the binary that's currently running though :D
<dtz>
somewhere... aw man where have you been all my life, lol I have so many notes and slides and such on these things :D okay uhhh
<shlevy>
Maybe hard-linking could be a solution here...
<shlevy>
But then you double the memory use unless the module unloads itself
<dtz>
so firstly there's a need to break apart the "reasons" / "uses" of dlopen/dlsym -- which by themselves are much too powerful for any given situation. And generally they're not the way anyone'd prefer to do things, just the available means to an end.....
<dtz>
well okay back to what you're saying --I guess I just meant "why are we trying to dynamically extend the program?"
<shlevy>
is lazy extension of nix builtins from a trusted source
<shlevy>
Ideally without reinstalling when we add a new plugin, but that cost may be lower than I'm imagining
<shlevy>
So in the dlopen world, I could have the plugin be referenced via a derivation that isn't actually built until the builtin is used
<dtz>
I'd argue most uses are only needed to overcome limitations in our platform-- that is--you want users of nix to be able to use your plugin, for example. Or maybe a firefox user wants to add additional functionality or something.
<dtz>
heh well so you're right costs can be significant, but it does indeed become an optimization problem
<shlevy>
Or the example that got us on this topic: I want to separate out core compiler logic/frontend drivers from emit-system specific logic
<shlevy>
Oh, sure
<shlevy>
I don't know of a good case that's inherently semantically required
<MichaelRaskin>
Building language feature implementation on demand sounds bold…
<dtz>
I mean that if you remove a number of social/technical issues preventing easily building X with Y (nix+shlevy, or FF+exttension) then the only reason to split separately is to (not unimportantly) optimize cost of compilation or hosting variants or w/e
<shlevy>
MichaelRaskin: builtins.importNative has existed for quite some time ;) I've used it on and off for some years
<shlevy>
dtz: Right, agreed
<shlevy>
In the ideal world the only thing that needs binaries as an interface is an OS/VM
<dtz>
which is kinda obvious but we've gone so far into a sort of technical debt (on linux/elf/etc esp) that simple things are no longer simple; the omplex become impossible. To paraphrase badly a favorite quote of mine :)
<dtz>
haha yeah
<shlevy>
Maybe the right answer is to change our pluggable tools to have actual interfaces
<dtz>
and even then! they're only a means to an end for moooost uses
<MichaelRaskin>
shlevy: I thought you wanted to register an impoertNative and only have it happen when the feature is actually encountered
<dtz>
does Joe care that there are shared libraries on his disk? that there is an ELF-spec executable somewhere? or does he care that he clicks an icon and it opens Word? :)
<dtz>
anyway
<shlevy>
MichaelRaskin: That's free with lazy semantics
Sonarpulse has joined #nixos-chat
<shlevy>
MichaelRaskin: let foo = importNative my-packages.fooPlugin; in ...
<dtz>
I think so, although you're a bit ahead of me (good!) in that I haven't really sat and thought how to best do this
<MichaelRaskin>
shlevy: unless you extend syntax
<dtz>
it's the "next step" ;)
<shlevy>
MichaelRaskin: Ah, I'm not that bold ;)
<MichaelRaskin>
Well, the parser has to be updated eagerly and the semantics can be built on-demand!
<MichaelRaskin>
dtz: I guess an extension of the «let's do everything cleanly enough to have musl just work» could be «let's do everything cleanly enough to be able to permute the syscall numbers at random and build a working system»
<shlevy>
MichaelRaskin: ++
<dtz>
MichaelRaskin: that's ... exactly what I'm doing for
<dtz>
MichaelRaskin: part of ALLVM doing awesome things is that
<dtz>
if you can do that, you can start doing things like... optimize across syscall boundaries, etc.
<shlevy>
dtz: So I guess the reason dlopen is attractive is running native code
<shlevy>
Then we put symbol resolution on top because that's all we know how to do
<shlevy>
I don't want my plugin interface to Nix to have to describe an entire VM semantics :P
<MichaelRaskin>
dtz: syscall permutation should be simpler than across-syscall optimisations…
<dtz>
also from a analysis POV ... these same rules really help bring common C/C++ code into the realm of things one could actually do pointer analysis /etc on without pessiimisitically assuming everything aliases everything
<dtz>
(because dlsym could find it, depending on... it's never-ending , trust me lol)
<shlevy>
Maybe we should take a hint from the kernel though and do everything in BPF :D
<dtz>
MichaelRaskin: oh, yes
<MichaelRaskin>
_Just_ syscall permutation gives you two kinds of guarantees: proper origin tracking for all the code (no mistakenly shipped prebuilt VMs) and the fun of any remote code execution instantly downgraded to a 99% likely crash.
<dtz>
lmao so it's funny re:wriiting VM semantics in Nix haha
<shlevy>
dtz: How much of the pain goes away if we keep the loading and position-independence of current dynamic loaders but not extra-modular symbol resolution?
<dtz>
well so I like position independence--and generally that's part of what's needed, in the sense code needs to not care about its position (although generally "PIC" refers to compiler-introduced deps on position, not app-level but same idea)
<dtz>
err
<dtz>
what loading do you mean?
* dtz
stops talking so he can listen
<shlevy>
So my thinking is, instead of having JIT-compiled declarative execution semantics for plugins (which isn't necessarily a bad idea, but can maybe be deferred), we keep the current model of plugins being some form of already-compiled native code. And the dynamic loader is allowed to find a space for it, and fixup relocations *within* the module, but we require some new kind of interface for the module to reference addresses in the
<shlevy>
surrounding code
<dtz>
oh, okay
<shlevy>
How much of the pain that you see goes away there?
<dtz>
via some runtime services provided by the platform, essentially
<shlevy>
I know you lose some optimizations of the module itself if it's not in IR, but I don't think you'd have to lose anything for the base program right?
<shlevy>
Yeah, or by just requiring the module to export allmux_entry and take a void* :P
<dtz>
yes you're right
<dtz>
and I think the mindset perhaps should be that this is not because of any semantic requirements but rather a selected point in the design space for how we could organize/prebuild these things
<dtz>
... maybe
<shlevy>
what's "this" in that sentence?
<dtz>
even so I think it'd be useful/good idea to be able to express to your system what plugin(s) you want--not necc need to dynamically handle them (although they could be done that way)
<dtz>
if nothing else, locks down things to ensure only that code is used or w/e xD
<shlevy>
Agreed.
<dtz>
oh, uh
<dtz>
I'm not sure, but if you agree with second part I think we're on the same page xd
<shlevy>
:D
<shlevy>
Like the kernel's out-of-tree module taint :)
<shlevy>
You rarely want to dynamically extend at runtime as opposed to at config time
<shlevy>
Semantically at least, sometimes you do at runtime for laziness's sake
<shlevy>
I think it's mroe likely than not that for me, any convincing case of actual dynamic runtime extension would also be a case for a properly constrained execution semantics anyway
<dtz>
:D
<dtz>
huge +1
<shlevy>
I just think "load a compiled binary blob" is a pretty good implemnetation detail for config-time dynamism
<shlevy>
And it would be nice if we had a path to that without giving up allmux
<dtz>
okay
<dtz>
I think what you have in mind is the right way to go, esp in terms of practicality/adoption
<dtz>
still need a "format" or interface or w/e to make that work
<dtz>
(you've suggested a few, I'm not particular, just as long as it's not the mess we have today re:accidental complexity)
<shlevy>
:)
<shlevy>
Do you think thinking in terms of symbols is the right way to go?
<shlevy>
"this plugin gets to access any of these symbols/functions exported by these C++ classes/etc."
<shlevy>
Or should we be more explicitly constrained
<shlevy>
I like this configtime vs runtime distinction... I think it applies more broadly than just here
<shlevy>
It's basically the late binding problem in Nix
<MichaelRaskin>
configtime is just one more phase
<shlevy>
Yep. Sonarpulse will be happy to extend his model ;)
<shlevy>
Actually I think config may fully generally subsume emit
<dtz>
xD
<Sonarpulse>
dtz: do you ever interact with the ML module people with this stuff?
<Sonarpulse>
or more C++
<Sonarpulse>
exclusively
<Sonarpulse>
(Also Rust)
<dtz>
._. no one really. Mostly from C/C++ community, though. Definitely lots to learn from how rust/ocaml/haskell have identified and handled these things
<Sonarpulse>
eh the Haskell module system is shit, nothing to learn there, move along please :D
<Sonarpulse>
actually ok in 8.2 onward it isn't
<Sonarpulse>
but new feature I sadly yet haven't plaid with
<Sonarpulse>
a cool thing would be to make http://mlton.org/ just as good without being whole-program :)