An alternative to shared libraries • Hacker News Board

Re: An alternative to shared libraries

#21

Post by csirac2 » Mon, Apr 27, 2015, 1:01 AM UTC

101914 wrote: post #11

"In summary, the answer is to write lean, efficient and small pieces of code..." What if the user could avoid "non trivial" programs, i.e. the ones that purportedly make it impossible to avoid shared libraries? To put it another way, what if a user could have a system containing only trivial programs that each do one thing and then use them in combination to do "complex" tasks? The term "non trivial software" is one…

Shared code is the only sane way to manage secure systems. Not only do I not want to wait 6 months for an lzo or libpng RCE to be fixed separately in 28 different pieces of software (some are no longer maintained so I'll have to wait for a kind package maintainer or modify/compile/distribute myself), I also don't want the job of finding which of my software constitute the list of programs making my system vulnerable and require this attention - or don't, if they've already been fixed (how do you check?).

Performance and disk space have almost nothing to do with why we use shared libraries, IMHO.

Re: An alternative to shared libraries

#22

Post by hbogert » Mon, Apr 27, 2015, 9:21 AM UTC

hyc_symas wrote: post #17

jjoonathan wrote: post #5

Earlier quoted context omitted.

> if your tiny executable uses just some methods of a gigantic library, it can do so an it will still stay tiny How many other functions do the ones you explicitly call drag into the executable? How do you propose to deduplicate them and their resources between processes? I'm specifically thinking about UI code. Having 30 different copies of your UI toolkit and its resources would be silly, even if each was stripped…

The X Window System architecture solves a specific problem - allowing clients to use graphical applications no matter where the app actually runs. This was important in the 1980s and is still worthwhile today - no matter how much compute power you can stash under your desk or wear on your wrist, you can cram orders of magnitudes more into a data center. Having a uniform interface that's independent of where the heavy…

Now, only if X actually worked when you want it to run in a data center and see it on your laptop. X is horrible when the latency goes above 5ms.

Re: An alternative to shared libraries

#23

Post by hyc_symas » Mon, Apr 27, 2015, 10:08 AM UTC

hbogert wrote: post #22

hyc_symas wrote: post #17

Earlier quoted context omitted.

The X Window System architecture solves a specific problem - allowing clients to use graphical applications no matter where the app actually runs. This was important in the 1980s and is still worthwhile today - no matter how much compute power you can stash under your desk or wear on your wrist, you can cram orders of magnitudes more into a data center. Having a uniform interface that's independent of where the heavy…

Now, only if X actually worked when you want it to run in a data center and see it on your laptop. X is horrible when the latency goes above 5ms.

Not saying X is anywhere near perfect. But losing network transparency is a mistake.

Personally I always preferred MGR. I suppose that evolved into Plan 9's window system, but I've never tried the latter. My attempt to bring MGR into the modern age is clunky at best. https://github.com/hyc/mgr But there's a lot to be said for a lightweight network-transparent protocol with a braindead-simple runtime.

Re: An alternative to shared libraries

#24

Post by jjoonathan » Mon, Apr 27, 2015, 10:54 PM UTC

hyc_symas wrote: post #23

hbogert wrote: post #22

Earlier quoted context omitted.

Now, only if X actually worked when you want it to run in a data center and see it on your laptop. X is horrible when the latency goes above 5ms.

Not saying X is anywhere near perfect. But losing network transparency is a mistake. Personally I always preferred MGR. I suppose that evolved into Plan 9's window system, but I've never tried the latter. My attempt to bring MGR into the modern age is clunky at best. https://github.com/hyc/mgr But there's a lot to be said for a lightweight network-transparent protocol with a braindead-simple runtime.

> losing network transparency is a mistake.

Why? X11 competes with VNC to provide remote interaction. VNC wins, and not by a small factor, on the apps I use day-to-day.