Conversation

dynamic linking is nice and good

i love dynamic linking

4
1
1

@toast eh i absolutely don't miss importlibs and similar weirdness

2
0
0

@toast also that in order to use dlls efficiently you have to mark all external linkage dllimport which means you effectively have to pass to the code at build time what type of library you are linking against

0
0
0

@q66 Can't use dynamic linking in NixOS 😭

2
0
0

@toast i mean yeah that part is fine but other than that handling of windows dlls is uhh

i don't like static linking in the general case because it erases the real meaning of abi in practice and pushes things more towards being very wrong (like rust with its monomorphization and "compile everything, all at once" is largely enabled by "static link everything")

i want dynamic linking, generics via dynamic dispatch like eg swift (but i'm fine ish with the way c++ does it, if restraint is applied), stable abis, reasonable library management, being able to build all the pieces individually and get all the benefits stemming from that eg patch security issues on the fly without rebuilding world

i don't mind things being statically *linkable* (that should kinda just be implicit because there isn't anything you should be doing that should prevent it, in general) but i'm very sad about where things are going

flatpak is just a result of the whole "give distribution powers back to the developer" which is also its own nasty can of worms because developers generally don't give a shit about a large portion of their potential users

0
0
0

@q66 yea agreed , idk it just feels like statlinking is only ok for increasingly niche usecases (and rust. of course)

0
1
0

@toast i'm not sure how i feel about dlopen in general, i kinda feel like restraint should be applied when using it because it means the ldso cannot know ahead of time and symbol resolution at runtime is wonky

separate processes + ipc are ideal (and that also works for static) though not always doable

0
0
0
@Gabriel @q66 what do you mean? aren't nix packages normally dynamically linked? guix packages certainly are
1
0
0

@noisytoot @q66 My bad, you can't use dynamic linking in NixOS without patching the program you want to run

That's why I had (and gave) the impression you couldn't use dlls at all in NixOS

0
0
0

@q66 @toast remember dynamic linking with a.out?

0
0
0

@q66
I kinda miss how AmigaOS did it.
Similar to dlopen().

1
0
0

@kirtai @q66 i don't think dlopen is good as it makes dependency resolution harder to do stastically (you don't know what library it'll load until it asks to) which is pretty bad for security

1
0
0
@SRAZKVT @kirtai @q66 just do a systemd and shove json into a custom elf header /j

(i still can't believe that's what they're pushing for ugh)
1
0
0

@navi @q66 @kirtai right, because a elf header is always correct, and it's impossible to write a dlopen call without updating the header, and there is never a case where dlopen may get a value not expected by a dev, after all, vulnerabilities don't exist

1
0
0

@navi @q66 @kirtai honestly of the three options, dlopen is probably the worst, dynamic linking is, well, dynamic, but what it links with isn't, and if you've got a vuln in your linker you've got other problems, and, well, static linking is the same

0
0
0

@q66 i don't think it's particularly better than static, but it is what systems are built upon, and so should be what is preferred

though i can see a way to make statlinking work on the distribution side, but itd need all packages and software to be done differently to be good (the way i see it is a built but pre link cache (to not need to rebuild everything every time, only relink) and if the package or one of its deps gets updated, it gets relinked and its tests ran, if that fails, the update to that package is abandonned so users keep a working package, and an error is sent to maintainers

again, different model from what we're using right now, and our software doesn't expect that at all, so it's just a neat thought experimentation likely to never see the light of day

0
0
0