The worst thing to happen to computers is dynamic linking. It's a fucking mistake from the times storage was abysmal...

The worst thing to happen to computers is dynamic linking. It's a fucking mistake from the times storage was abysmal, a fucking mistake that caused so much wasted effort and fighting to "make it work". Seriously, fuck dynamic linking.

Attached: 1540237078445.png (686x689, 85K)

Works fine on my machine

who hurt you, OP?

No. The worst thing to happen is package management.

ldd firefox
linux-vdso.so.1 (0x00007ffe87dfe000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f25789cf000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f25787cb000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f2578443000)
libm.so.6 => /lib64/libm.so.6 (0x00007f25780f8000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f2577ee1000)
libc.so.6 => /lib64/libc.so.6 (0x00007f2577b2b000)
/lib64/ld-linux-x86-64.so.2 (0x00007f2578e29000)

ldd ../bin/libxul.so
linux-vdso.so.1 (0x00007fff9a90b000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f44cb78a000)
libmozsandbox.so => not found
libnspr4.so => /lib64/libnspr4.so (0x00007f44cb54c000)
libplc4.so => /lib64/libplc4.so (0x00007f44cb347000)
libplds4.so => /lib64/libplds4.so (0x00007f44cb143000)
liblgpllibs.so => not found
libnss3.so => /lib64/libnss3.so (0x00007f44cae1a000)
libnssutil3.so => /lib64/libnssutil3.so (0x00007f44cabea000)
libsmime3.so => /lib64/libsmime3.so (0x00007f44ca9c3000)
libmozsqlite3.so => not found
libssl3.so => /lib64/libssl3.so (0x00007f44ca771000)
libmozgtk.so => not found
libmozwayland.so => not found
libdl.so.2 => /lib64/libdl.so.2 (0x00007f44ca56d000)
librt.so.1 => /lib64/librt.so.1 (0x00007f44ca365000)
libm.so.6 => /lib64/libm.so.6 (0x00007f44ca01a000)
libX11.so.6 => /lib64/libX11.so.6 (0x00007f44c9cdc000)
libX11-xcb.so.1 => /lib64/libX11-xcb.so.1 (0x00007f44c9ada000)
libxcb.so.1 => /lib64/libxcb.so.1 (0x00007f44c98b2000)
libXcomposite.so.1 => /lib64/libXcomposite.so.1 (0x00007f44c96af000)
libXcursor.so.1 => /lib64/libXcursor.so.1 (0x00007f44c94a5000)
libXdamage.so.1 => /lib64/libXdamage.so.1 (0x00007f44c92a2000)
libXext.so.6 => /lib64/libXext.so.6 (0x00007f44c9090000)
libXfixes.so.3 => /lib64/libXfixes.so.3 (0x00007f44c8e8a000)
.........

how the fuck do I compile FF statically? Why did they remove the configure flags? I need to get this shit into aws lambda, except for going through diffs in what /lib64 there contains any other way?

Why couldn't everything just be linked statically. Golang got this right at least.

Functions properly on my device :)

Yes because having 100 different programs installed that each needs to be updated independently either manually or through an always-running background service is a much better solution... or having to update 20 programs because of a vulnerability in libpng when you could simply upgrade libpng

I unironically agree. Containers can't save us soon enough.

Good thing Flatpaks don't have this problem.

If you think this is the worst thing, you haven't seen enough.

Yeah, there is nothing better than distributing the shit you already have installed in every possible version. That's why Electron is the best.

Dynamic linking as a concept is fine and actually was implemented correctly well over 30 years ago.
Too bad it was on dead end OSes.

No, the worst thing to happen to computers was the internet. Botnet was added, testing dropped, help files mostly dropped, bloat added because very very low limitations for cost of distribution media.

>>Good thing Flatpaks don't have this problem.
flatpaks (and snaps and appimages) have exactly that problem. The whole reason they were invented is because devs constantly want to vomit out broken shit that falls over if you upgrade any of the underlying libraries it uses.

Flatpaks don't need to be updated automatically. Flatpaks share dependencies that are identical to save space.

>storage
Not only storage, but RAM too. Imagine bloating every program by ten times its size. Linux would never do it into low-power consumer devices then.

>Flatpaks share dependencies that are identical to save space.
Like dynamic linking does?

The fact that OS-wide libraries prevent applications from saying "I want version X and never any version greater than X" is a feature, not a bug. If you can't update the library version underneath your application, the problem isn't that the OS updated the library, the problem is that your application is broken.

libs
name
1.0.img
1.1.img
apps
name
1.0.img

no redundancy of bundling everything in everything, and no stupidity of overwriting dependency versions. A text file in the root of each image file listing its dependencies.

Learn what Flatpak does. I won't bother explaining everything.

>libdicks.so is widely used
>libdicks.so.4 has a crticial vulnerability

Dynamic linking solution: update libdicks.so
Static linking solution: update 100 Electron packages

Yeah sure, worst thing to happen,

Attached: explainthatagain.jpg (500x371, 25K)

>I don't understand licensing
Im glad fags like OP cant reproduce

Attached: 1501774074453.png (396x381, 130K)

Imagine being you.
Just sad.

>Learn what Flatpak does.
it does an end-run around the OS package-management systems, that's what it does. We built package managers for damn good reasons and gain important advantages from them, and lazy app devs in their continuing efforts to Windows-ify everything are throwing them away.

You probably compile with default flags and dynamic link glibc anyways brainlet.

I'm very curious to know which dead end operating systems implemented dynamic linking correctly would you mind listing a few?

Terry had it right, no linker for HolyC.
Linkers are for MIT niggers.
FUCK YOU MIT NIGGER!💢

>I need to get this shit into aws lambda
are you trying to run a browser on lambda
what the fuck are you doing

what's with the linux trend of adding .3 or .4 onto library names?

no it isn't, Unix just wasn't made with it in mind. Lo and behold, Unix clones suck at handling it properly. Same thing applies to package management and GUI.