DVM - D Version Manager 0.2.0

[Daniel Gibson]

Am 18.05.2011 14:21, schrieb Steven Schveighoffer:
> On Wed, 18 May 2011 03:15:50 -0400, Nick Sabalausky <a at a.a> wrote:
> 
>> But the bottom line seems to be: Linux is in a bigger DLL hell than
>> windows
>> has ever been, and I don't think *anyone* actually knows how to do it.
> 
> This is one of the side effects of having open source software.  Since
> everything on linux is expected to be open source, it's expected that
> you simply recompile everything for your system.  In this respect,
> Windows has Linux beat hands down.  A hardware company that builds a
> driver needs only to support one compiled driver that just keeps working
> no matter how many times XP is updated.

Drivers are completely different from normal applications on Linux.
Because the Kernel changes all the time you have to change drivers quite
often.
The userspace should be more stable - AFAIK the kernel ABI is backwards
compatible since kernel 0.99 or something, i.e. programs from back than
should still work.
In practice there is some kind of DLL hell because old software may rely
on old libs that are not available on newer distributions (or only in
not backward-compatible versions).
For Open Source software that is not that much of a problem, often it's
sufficient to recompile..
Closed source software on Linux often supplies almost all needed
libraries to avoid problems with preinstalled libs - or is even
statically linked. I think this is the same on Windows..

Also, as Nick mentioned, it helps to compile software on a older
distribution, because many libs are at least backwards compatible (to a
certain degree), but not the other way round, so it still works on
newer/recent distributions - while compiling on your newest bleeding
edge beta Ubuntu (or Debian unstable or whatever) will quite likely
produce binaries that won't work on older distributions.
I maintain Debian/Ubuntu packages for a Quake2 port (Yamagi Quake2) and
building them on a old Debian etch chroot jail produces binaries that
work on about any Debian/Ubuntu from the last years (at least there
never have been complaints that it doesn't work).

> 
> I think reading some of the issues with MacOSX breaking dmd builds by
> going through a *point* revision, it sounds like MacOSX is just as bad.
> 

Strange, considering that MacOSX isn't open and there are not a several
different distributions of it.

> At my previous company, we integrated software from pure software
> companies into their required OSes and hardware, and did all the
> OS/hardware dirty work for them (i.e. we turned pure software into an
> appliance).  One of the *worst* problems was when the customer wanted
> some version of Linux, and let's say they had a specific kernel build. 
> Because of the expectation from the Linux kernel that you just recompile
> all your drivers, any RAID card (a very common requirement) which had
> proprietary driver code would require us to contact the hardware vendor,
> and have them rebuild the RAID driver on their specific kernel (for a
> not-so-nominal fee of course, with very little support).
> 

That's why you should use hardware that doesn't rely on proprietary
drivers on Linux. If the driver is integrated in the Kernel you don't
have to worry if it still works after minor or major upgrades.
On Windows you may have hardware that is supported on Windows XP, but
not on Win7 etc.
I think using hardware with free/open drivers is realistic for about any
hardware besides video cards - although the open drivers for AMD/Ati are
getting better. And the proprietary drivers for them are compatible to
any recent kernels (apart from maybe the most recent one, but you won't
find that in distributions anyway). You just have to be a bit careful
and choose your hardware accordingly.


> I fantasized about building my own linux kernel that had zero
> configuration options, and would never break driver compatibility
> between point revisions.  Such a kernel would allow hardware companies
> to release one driver and have it work for any system that used their
> hardware and that kernel.  

Like Redhats 2.6.18 fork they maintained forever?

> I can't imagine hardware companies love
> supporting umpteen driver versions multiplied by umpteen linux vendors
> (generally they only pick one vendor and support that).  

Yeah, they should just donate the driver to the kernel (or at least
release HW specs so somebody else can write an open driver) and let the
kernel developers maintain it.

> Of course, that
> dream would be impossible to realize without tremendous effort, which I
> don't have.
> 
> Ah well.
> 
> -Steve

Cheers,
- Daniel