3 ms·

+1. In these modern days of huge amounts of memory, this is exactly what we should be doing: static linking everything.

by meaty 14y ago

rogerbinns 14y ago
Static linking still doesn't help that much with version issues. For example how do you deal with other changes? One example is the Gnome world has gone from gconf to dconf. If you have private library versions then you'll get apps randomly picking settings in random ways, system files (eg nsswitch, trusted ssl cas), clipboard formats etc. (Arguably this does still happen to some degree but at least attempts are made to curtail it.) The one other approach which works for some is not using milestones at all - just keep everything rolling. This is actually a far better match for how much of the upstream software actually works, and some distros have had some success (eg gentoo). You see rolling releases proposed every now and then (eg for Suse).
- meaty 14y ago
  You get the interfaces between the processes right and keep them the same and cleanly versioned. For example with gconf to dconf, you get gconf right the first time (or even better don't use either as they are the spawn of hell). Look at the C standard library and core UNIX system call interfaces and Win32 for examples. I wrote something (an NNTP client) for Win32 for NT4 that was statically linked. It still works fine now on Windows 8 x64 16 years later without a recompile.
  - rogerbinns 14y ago
    Your solution is that developers be perfect and get interfaces right the first time :-) While that is admirable, the chances of it happening for the majority of software is zero! Your Microsoft binaries still work because of the huge amount of effort Microsoft puts into backwards compatibility - read Raymond Chen's blog for details. In particular when apps are buggy, Microsoft goes to great lengths to keep the app working.
    - meaty 14y ago
      Yes they keep the interfaces as buggy as they always were! :)

+1. In these modern days of huge amounts of memory, this is exactly what we should be doing: static linking everything.

by meaty 14y ago

+1. In these modern days of huge amounts of memory, this is exactly what we should be doing: static linking everything.

Static linking still doesn't help that much with version issues. For example how do you deal with other changes? One example is the Gnome world has gone from gconf to dconf. If you have private library versions then you'll get apps randomly picking settings in random ways, system files (eg nsswitch, trusted ssl cas), clipboard formats etc. (Arguably this does still happen to some degree but at least attempts are made to curtail it.) The one other approach which works for some is not using milestones at all - just keep everything rolling. This is actually a far better match for how much of the upstream software actually works, and some distros have had some success (eg gentoo). You see rolling releases proposed every now and then (eg for Suse).

meaty 14y ago
You get the interfaces between the processes right and keep them the same and cleanly versioned. For example with gconf to dconf, you get gconf right the first time (or even better don't use either as they are the spawn of hell). Look at the C standard library and core UNIX system call interfaces and Win32 for examples. I wrote something (an NNTP client) for Win32 for NT4 that was statically linked. It still works fine now on Windows 8 x64 16 years later without a recompile.
- rogerbinns 14y ago
  Your solution is that developers be perfect and get interfaces right the first time :-) While that is admirable, the chances of it happening for the majority of software is zero! Your Microsoft binaries still work because of the huge amount of effort Microsoft puts into backwards compatibility - read Raymond Chen's blog for details. In particular when apps are buggy, Microsoft goes to great lengths to keep the app working.
  - meaty 14y ago
    Yes they keep the interfaces as buggy as they always were! :)