3 ms·

Yeah but Windows releases are years apart, not 6 months apart. With Windows a big help towards easing the backwards-compatibility burden is having DLLs shipped

by acabal 14y ago

Yeah but Windows releases are years apart, not 6 months apart. With Windows a big help towards easing the backwards-compatibility burden is having DLLs shipped with the program. That way a program knows it can depend on whatever specific version of the library it needs, and thus can be decoupled from the system-wide update process. This shifts responsibility for stuff like security, but it's a tradeoff. Gobo Linux has taken some good steps towards doing something like this; as I understand it, apps are installed without any system-wide dependencies, so you can have different versions of the same app at the same time, regardless of the overall system configuration. Sadly I think Gobo Linux is abandoned, but the concept was a great step forward. Regardless of how hard it is to accomplish what Windows has done, I think it's essential for an OS if it truly wants to be in the big leagues. (OSX gets a special pass because they control their own hardware, which moots almost the entire point I'm making.) The concept of "upgrade one thing, upgrade everything" is a relic and pretty much the shot in the head for a distro that wants to usable by humans without crazy regressions every 6 months.

meaty 14y ago
+1. In these modern days of huge amounts of memory, this is exactly what we should be doing: static linking everything.
- 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! :)

by acabal 14y ago

meaty 14y ago

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

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! :)