Re: [boost] C++ announcements coming tomorrow

Subject: Re: [boost] C++ announcements coming tomorrow
From: Olaf van der Spek (ml_at_[hidden])
Date: 2012-11-05 10:53:28

On Mon, Nov 5, 2012 at 3:46 PM, Paul Mensonides <pmenso57_at_[hidden]> wrote:
>> For an app it's easy to depend on another lib. But for a lib,
>> depending on another lib that might not be easily available /
>> installable can be problematic.
>
>
> In some ways, Windows deployment is easier because you can distribute
> in-directory DLLs for many libraries that don't require their own
> installation programs and largely avoid DLL hell.  In many ways, the Linux
> model is better because it has better facilities for reuse, but dealing with
> C++ ABI issues and version availablity issues can be a nightmare also.
> Granted, you can do the same thing as with Windows with rpath if you really
> want to, but then you throw away memory and, usually less importantly, disk
> reuse (just as you get with Windows with in-directory DLLs).

Actually, I meant build-time deployment. Getting includes and libs installed.

>> They could be better but I don't think calling them fundamentally
>> broken is fair.
>
>
> Sorry, I didn't mean the tools themselves.  I'm referring to the single
> points of update and/or vetting of the content that those tools work with
> (at least, via official repositories).  They are fundamentally broken
> because all updates are essentially serialized through a single point.  That
> just doesn't scale despite herculian effort, and most Linux distros are way
> behind the most current releases of most software because of that.  Pressure
> for throughput at that point far outweights the available throughput--the
> outcome is inevitable.  Currently, deploying on Linux via any of the package
> management systems is a nightmare unless you only need old compilers and
> only rely on old versions of other libraries.  Besides the boilerplate
> distro differences in how one specifies a package, you run smack into
> version availability issues (related to which versions have so far gone
> through the single point) and ABI issues.

I guess my definition of broken is different than yours. Yes, the
model can be improved (greatly), but calling it broken?

-- 
Olaf