From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <20100217150452.GE10816@nibiru.local> References: <20100217143303.GC10816@nibiru.local> <0ffee4ba13816a49a6360ce6668e65f2@quintile.net> <20100217150452.GE10816@nibiru.local> Date: Wed, 17 Feb 2010 11:00:13 -0800 Message-ID: <1fc0d9801002171100g253bf0dci83af4b4026387091@mail.gmail.com> From: Nick LaForge To: weigelt@metux.de, Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Subject: Re: [9fans] Binary format Topicbox-Message-UUID: d5caeeba-ead5-11e9-9d60-3106f5b1d025 Enrico Weigelt wrote: >> And another important feature of shared libraries is, that when >> some lib is updated, importing programs dont have to be recompiled. Enrico Weigelt wrote: > Actually, that's just a matter of clean dependency handling. > Include an API/ABI version in the filename, etc. Why create single points of failure? The complexity to justify creating a bureaucracy delegating responsibility of libraries to different people is not there in Plan9. The libraries are for convenience and orthogonality; they are not the definitive API. That is defined by the kernel and by 9P. They really are the black boxes. And shouldn't you be inspecting any new code paths when using new code? Why assume the library writer has tested against YOUR code in all paths, and bump to the new version, risking regression? This to me seems insane for production environments, and is all too common in the open source world where people seem to be writing new code for it's own sake and to everyone's detriment. A nice benefit of taking the simple route early on is that it becomes easier down the road to implement the functionality in one fell swoop, top-down. Maybe in the future the kernel could remove redundant code. 9vx and it's ilk already do something somewhat orthogonal to this by executing code that is shorter after it's been dynamically re-written.