www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DVM - D Version Manager 0.2.0

reply Jacob Carlborg <doob me.com> writes:
I just released a new version of DVM, 0.2.0.
For installation instructions see: https://bitbucket.org/doob/dvm

Changelog:

Version 0.2.0

New/Change Features
  * 64bit version now available on Linux
  * It's now possible to update an already existing DVM installation
  * Added an option for installing 32bit compilers, useful on 64bit 
platforms
  * Added support for the new structure of the DMD zip, appeared in 
version 1.068 and 2.053
  * Added a "current" wrapper which points to the current compiler
  * Added an option for specifying a default compiler
  * Better compatible between different shells
  * Added support for installing Tango
  * Added support for installing 64bit compilers (default on 64bit 
platforms)
  * The fetch/install command now shows progress when downloading. 
Thanks to jdrewsen.
  * Added support for the new structure of the DMD zip, appeared in 
version 1.067 and 2.052.
  * Added a changelog.

Bugs Fixed
  * RDMD now has executable permission
  * Exit if the DVM executable cannot be found
  * Always remove the temp path
  * Don't use "exit" in the DVM shell script
  * Added dmd.conf patch for druntime as well.
  * Fixed: DMD2 was incorrectly handled.
  * Bump version number.


Sorry, still no version for Windows. I've seen another application that 
does the same but for Ruby, on Windows, so now I know it should be 
possible at least.

-- 
/Jacob Carlborg
May 17 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Jacob Carlborg" <doob me.com> wrote in message 
news:iquopl$1l9u$1 digitalmars.com...
I just released a new version of DVM, 0.2.0.
 For installation instructions see: https://bitbucket.org/doob/dvm

 Changelog:

 Version 0.2.0

 New/Change Features
  * 64bit version now available on Linux
  * It's now possible to update an already existing DVM installation
  * Added an option for installing 32bit compilers, useful on 64bit 
 platforms
  * Added support for the new structure of the DMD zip, appeared in version 
 1.068 and 2.053
  * Added a "current" wrapper which points to the current compiler
  * Added an option for specifying a default compiler
  * Better compatible between different shells
  * Added support for installing Tango
  * Added support for installing 64bit compilers (default on 64bit 
 platforms)
  * The fetch/install command now shows progress when downloading. Thanks 
 to jdrewsen.
  * Added support for the new structure of the DMD zip, appeared in version 
 1.067 and 2.052.
  * Added a changelog.

 Bugs Fixed
  * RDMD now has executable permission
  * Exit if the DVM executable cannot be found
  * Always remove the temp path
  * Don't use "exit" in the DVM shell script
  * Added dmd.conf patch for druntime as well.
  * Fixed: DMD2 was incorrectly handled.
  * Bump version number.


 Sorry, still no version for Windows. I've seen another application that 
 does the same but for Ruby, on Windows, so now I know it should be 
 possible at least.
Sounds cool, but dvm-0.2.0-linux-32 is just giving me "Illegal instruction" on Kubuntu 10.04 x86-32. And I don't see any instructions for how to build it anywhere in the source tree or on the homepage.
May 17 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-05-18 06:35, Nick Sabalausky wrote:
 "Jacob Carlborg"<doob me.com>  wrote in message
 news:iquopl$1l9u$1 digitalmars.com...
 I just released a new version of DVM, 0.2.0.
 For installation instructions see: https://bitbucket.org/doob/dvm

 Changelog:

 Version 0.2.0

 New/Change Features
   * 64bit version now available on Linux
   * It's now possible to update an already existing DVM installation
   * Added an option for installing 32bit compilers, useful on 64bit
 platforms
   * Added support for the new structure of the DMD zip, appeared in version
 1.068 and 2.053
   * Added a "current" wrapper which points to the current compiler
   * Added an option for specifying a default compiler
   * Better compatible between different shells
   * Added support for installing Tango
   * Added support for installing 64bit compilers (default on 64bit
 platforms)
   * The fetch/install command now shows progress when downloading. Thanks
 to jdrewsen.
   * Added support for the new structure of the DMD zip, appeared in version
 1.067 and 2.052.
   * Added a changelog.

 Bugs Fixed
   * RDMD now has executable permission
   * Exit if the DVM executable cannot be found
   * Always remove the temp path
   * Don't use "exit" in the DVM shell script
   * Added dmd.conf patch for druntime as well.
   * Fixed: DMD2 was incorrectly handled.
   * Bump version number.


 Sorry, still no version for Windows. I've seen another application that
 does the same but for Ruby, on Windows, so now I know it should be
 possible at least.
Sounds cool, but dvm-0.2.0-linux-32 is just giving me "Illegal instruction" on Kubuntu 10.04 x86-32. And I don't see any instructions for how to build it anywhere in the source tree or on the homepage.
Ok, strange. I built the tool on Ubuntu 11.04, maybe it's too new. How can I build it to work on as many platforms as possible? The runtime dependencies are just the same as a regular C application and zlib. Added build instructions at the bottom of: https://bitbucket.org/doob/dvm -- /Jacob Carlborg
May 17 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Jacob Carlborg" <doob me.com> wrote in message 
news:iqvpon$6p0$1 digitalmars.com...
 On 2011-05-18 06:35, Nick Sabalausky wrote:
 Sounds cool, but dvm-0.2.0-linux-32 is just giving me "Illegal 
 instruction"
 on Kubuntu 10.04 x86-32. And I don't see any instructions for how to 
 build
 it anywhere in the source tree or on the homepage.
Ok, strange. I built the tool on Ubuntu 11.04, maybe it's too new. How can I build it to work on as many platforms as possible? The runtime dependencies are just the same as a regular C application and zlib.
You know, I'm far from a Linux expert, but making compatible linux binaries seems to be quite a nightmare. In fact, I just recently went through hell myself trying to figure out how to compile a Hello World CGI app on my linux system and have it actually work on another linux system. You can follow my fun-filled adventures through it with these discussions: digitalmars.D.learn: "D CGI test: linux.so.2: bad ELF interpreter: No such file or directory" (2011/04/25) digitalmars.D.learn: "Linux: How to statically link against system libs?" (2011/04/26) http://ubuntuforums.org/showthread.php?t=1740277 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. In my case, I ended up just installing an older version of linux in a VM and compiling inside that (CentOS 4, largely because I needed to be able to run on a CentOS server that wasn't happy with my Kubuntu 10.04 executables). The resulting binaries did work on my Kubuntu 10.04 machine, too, so I guess the trick is to just compile on the oldest machine you can. Go figure: All the focus everyone puts on updating to newer versions, and it ends up best to stick with the older versions - not because the older ones were better, but just *because* they're older. Meh. Anyway, pardon the rant :/ You'd think there'd be a way to compile in a backwards-compatible way on linux, but I'm getting the impression that if it's possible, no one actually knows how.
 Added build instructions at the bottom of: https://bitbucket.org/doob/dvm
Thanks :) I think I'm almost there. I've been using D2/Phobos/RDMD for the past year or so (plus my usual machine is a windows box), so I had a lot of setting up to do, but I think I've almost got it now. When I do, I'll post the final binary in case it helps anyone else (I can only make a 32-bit binary though).
May 18 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:iqvru7$cnu$1 digitalmars.com...
 "Jacob Carlborg" <doob me.com> wrote in message 
 news:iqvpon$6p0$1 digitalmars.com...
 On 2011-05-18 06:35, Nick Sabalausky wrote:
 Sounds cool, but dvm-0.2.0-linux-32 is just giving me "Illegal 
 instruction"
 on Kubuntu 10.04 x86-32. And I don't see any instructions for how to 
 build
 it anywhere in the source tree or on the homepage.
Ok, strange. I built the tool on Ubuntu 11.04, maybe it's too new. How can I build it to work on as many platforms as possible? The runtime dependencies are just the same as a regular C application and zlib. Added build instructions at the bottom of: https://bitbucket.org/doob/dvm
Thanks :) I think I'm almost there. I've been using D2/Phobos/RDMD for the past year or so (plus my usual machine is a windows box), so I had a lot of setting up to do, but I think I've almost got it now. When I do, I'll post the final binary in case it helps anyone else (I can only make a 32-bit binary though).
Done. Here's the binary, it works for me: http://www.semitwist.com/download/app/dvm-0.2.0-linux-32
May 18 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-05-18 10:21, Nick Sabalausky wrote:
 "Nick Sabalausky"<a a.a>  wrote in message
 news:iqvru7$cnu$1 digitalmars.com...
 "Jacob Carlborg"<doob me.com>  wrote in message
 news:iqvpon$6p0$1 digitalmars.com...
 On 2011-05-18 06:35, Nick Sabalausky wrote:
 Sounds cool, but dvm-0.2.0-linux-32 is just giving me "Illegal
 instruction"
 on Kubuntu 10.04 x86-32. And I don't see any instructions for how to
 build
 it anywhere in the source tree or on the homepage.
Ok, strange. I built the tool on Ubuntu 11.04, maybe it's too new. How can I build it to work on as many platforms as possible? The runtime dependencies are just the same as a regular C application and zlib. Added build instructions at the bottom of: https://bitbucket.org/doob/dvm
Thanks :) I think I'm almost there. I've been using D2/Phobos/RDMD for the past year or so (plus my usual machine is a windows box), so I had a lot of setting up to do, but I think I've almost got it now. When I do, I'll post the final binary in case it helps anyone else (I can only make a 32-bit binary though).
Done. Here's the binary, it works for me: http://www.semitwist.com/download/app/dvm-0.2.0-linux-32
Thanks, I'll upload it when I get a chance. -- /Jacob Carlborg
May 18 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-05-18 13:27, Jacob Carlborg wrote:
 On 2011-05-18 10:21, Nick Sabalausky wrote:
 "Nick Sabalausky"<a a.a> wrote in message
 news:iqvru7$cnu$1 digitalmars.com...
 "Jacob Carlborg"<doob me.com> wrote in message
 news:iqvpon$6p0$1 digitalmars.com...
 On 2011-05-18 06:35, Nick Sabalausky wrote:
 Sounds cool, but dvm-0.2.0-linux-32 is just giving me "Illegal
 instruction"
 on Kubuntu 10.04 x86-32. And I don't see any instructions for how to
 build
 it anywhere in the source tree or on the homepage.
Ok, strange. I built the tool on Ubuntu 11.04, maybe it's too new. How can I build it to work on as many platforms as possible? The runtime dependencies are just the same as a regular C application and zlib. Added build instructions at the bottom of: https://bitbucket.org/doob/dvm
Thanks :) I think I'm almost there. I've been using D2/Phobos/RDMD for the past year or so (plus my usual machine is a windows box), so I had a lot of setting up to do, but I think I've almost got it now. When I do, I'll post the final binary in case it helps anyone else (I can only make a 32-bit binary though).
Done. Here's the binary, it works for me: http://www.semitwist.com/download/app/dvm-0.2.0-linux-32
Thanks, I'll upload it when I get a chance.
I've uploaded your version now, thanks again. -- /Jacob Carlborg
May 18 2011
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-05-18 09:15, Nick Sabalausky wrote:
 "Jacob Carlborg"<doob me.com>  wrote in message
 news:iqvpon$6p0$1 digitalmars.com...
 On 2011-05-18 06:35, Nick Sabalausky wrote:
 Sounds cool, but dvm-0.2.0-linux-32 is just giving me "Illegal
 instruction"
 on Kubuntu 10.04 x86-32. And I don't see any instructions for how to
 build
 it anywhere in the source tree or on the homepage.
Ok, strange. I built the tool on Ubuntu 11.04, maybe it's too new. How can I build it to work on as many platforms as possible? The runtime dependencies are just the same as a regular C application and zlib.
You know, I'm far from a Linux expert, but making compatible linux binaries seems to be quite a nightmare. In fact, I just recently went through hell myself trying to figure out how to compile a Hello World CGI app on my linux system and have it actually work on another linux system. You can follow my fun-filled adventures through it with these discussions:
Yeah, I read parts of those threads.
 digitalmars.D.learn: "D CGI test: linux.so.2: bad ELF interpreter: No such
 file or directory" (2011/04/25)
 digitalmars.D.learn: "Linux: How to statically link against system libs?"
 (2011/04/26)
 http://ubuntuforums.org/showthread.php?t=1740277

 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.

 In my case, I ended up just installing an older version of linux in a VM and
 compiling inside that (CentOS 4, largely because I needed to be able to run
 on a CentOS server that wasn't happy with my Kubuntu 10.04 executables). The
 resulting binaries did work on my Kubuntu 10.04 machine, too, so I guess the
 trick is to just compile on the oldest machine you can. Go figure: All the
 focus everyone puts on updating to newer versions, and it ends up best to
 stick with the older versions - not because the older ones were better, but
 just *because* they're older. Meh. Anyway, pardon the rant :/
Hehe.
 You'd think there'd be a way to compile in a backwards-compatible way on
 linux, but I'm getting the impression that if it's possible, no one actually
 knows how.
Wouldn't it just be possible to use an older version of GCC?
 Added build instructions at the bottom of: https://bitbucket.org/doob/dvm
Thanks :) I think I'm almost there. I've been using D2/Phobos/RDMD for the past year or so (plus my usual machine is a windows box), so I had a lot of setting up to do, but I think I've almost got it now. When I do, I'll post the final binary in case it helps anyone else (I can only make a 32-bit binary though).
-- /Jacob Carlborg
May 18 2011
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 18 May 2011 03:15:50 -0400, Nick Sabalausky <a 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. 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. 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). 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. 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). Of course, that dream would be impossible to realize without tremendous effort, which I don't have. Ah well. -Steve
May 18 2011
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 18 May 2011 08:21:45 -0400, Steven Schveighoffer  
<schveiguy yahoo.com> wrote:

 Of course, that dream would be impossible to realize without tremendous  
 effort, which I don't have.
Should have read "don't have time for" :) -Steve
May 18 2011
prev sibling next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 18.05.2011 14:21, schrieb Steven Schveighoffer:
 On Wed, 18 May 2011 03:15:50 -0400, Nick Sabalausky <a 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
May 18 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 18 May 2011 10:47:02 -0400, Daniel Gibson <metalcaedes gmail.com>  
wrote:

 Am 18.05.2011 14:21, schrieb Steven Schveighoffer:
 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 don't want to get into a philosophical debate here, but this is truly unrealistic. I think it's one of the main reasons many hardware companies don't support Linux. Opening the source does not mean you will not support it, and then you have to deal with 8 million configuration options for the kernel to test against your driver. As a hardware company whose main purpose is not writing drivers, that sounds like a QA nightmare. Yes, XP drivers don't work on Windows 7, but they work on XP, and there is only *one* XP. Furthermore, Microsoft *purposely* does not invalidate existing drivers. Compare that to Linux, where not only do the interfaces in the kernel change from revision to revision, but someone is *rebuilding* the entire kernel and all the drivers on every revision. I'm surprised it works as well as it does. Case in point, while I was using Linux as my main OS, an upgrade of the Fedora kernel simply broke my sound card driver. There was no changes to the driver, and I really never figured out what happened, but an upgrade to the next major release fixed the problem. There is absolutely no reason for existing drivers to break on a minor upgrade.
 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.
Printer support is woefully missing. My 2-year old printer still isn't supported on Linux.
 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?
Not really. I mean freeze the configuration options for the kernel -- they can never change except for a major release. Then, don't recompile the drivers for every kernel update. Maintain *binary* compatibility for drivers, so one never has to recompile them unless the driver itself has a bug.
 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.
This isn't always possible, many companies do not own all the software in their drivers, and especially many of the RAID card companies put a lot of the RAID code into their drivers -- that's their IP, and they would be giving away their trade secrets to make it open source. -Steve
May 18 2011
next sibling parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 18.05.2011 17:20, schrieb Steven Schveighoffer:
 On Wed, 18 May 2011 10:47:02 -0400, Daniel Gibson
 <metalcaedes gmail.com> wrote:
 
 Am 18.05.2011 14:21, schrieb Steven Schveighoffer:
 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 don't want to get into a philosophical debate here, but this is truly unrealistic. I think it's one of the main reasons many hardware companies don't support Linux. Opening the source does not mean you will not support it, and then you have to deal with 8 million configuration options for the kernel to test against your driver. As a hardware company whose main purpose is not writing drivers, that sounds like a QA nightmare.
I don't know much about coding for the kernel, but I guess that most of the configuration options shouldn't affect your driver. Of course there may still be a lot of options left that could affect your driver.
 Yes, XP drivers don't work on Windows 7, but they work on XP, and there
 is only *one* XP.  Furthermore, Microsoft *purposely* does not
 invalidate existing drivers.  Compare that to Linux, where not only do
 the interfaces in the kernel change from revision to revision, but
 someone is *rebuilding* the entire kernel and all the drivers on every
 revision.  I'm surprised it works as well as it does.
 
 Case in point, while I was using Linux as my main OS, an upgrade of the
 Fedora kernel simply broke my sound card driver.  There was no changes
 to the driver, and I really never figured out what happened, but an
 upgrade to the next major release fixed the problem.  There is
 absolutely no reason for existing drivers to break on a minor upgrade.
 
Are you sure that it wasn't some userspace fuckup? Also: bugs in the kernel and drivers are always possible, especially when using a bleeding edge distribution like Fedora.
 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.
Printer support is woefully missing. My 2-year old printer still isn't supported on Linux.
As I said, you have to choose your hardware accordingly. There are a lot of printers that have really good Linux support - more expensive ones via postscript and/or PCL, cheap ones (especially inkjets) often need some proprietary libs, that are however independent of the kernel and tend to work, even when they haven't been updated for some years (cheap HP printers are often supported via HPs open source hplip driver). http://www.openprinting.org/printers is pretty helpful and the proprietary drivers are available from the printer vendors (for example Brother supports many of their printers), so it's a good idea to look on that page and on the vendors page for linux support before buying a printer ;-)
 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?
Not really. I mean freeze the configuration options for the kernel -- they can never change except for a major release. Then, don't recompile the drivers for every kernel update. Maintain *binary* compatibility for drivers, so one never has to recompile them unless the driver itself has a bug.
 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.
This isn't always possible, many companies do not own all the software in their drivers, and especially many of the RAID card companies put a lot of the RAID code into their drivers -- that's their IP, and they would be giving away their trade secrets to make it open source.
As far as I know there are RAID cards with kernel support, for example a lot of HP cards: http://cciss.sourceforge.net/ Another possibility for a vendor is to ship most parts of the driver precompiled and just a wrapper for the kernel as source code, so you just have to recompile/change the wrapper for newer kernels. AMD and nvidia do that for their video card drivers.
 
 -Steve
Cheers, - Daniel
May 18 2011
prev sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 18/05/2011 16:20, Steven Schveighoffer wrote:
 Printer support is woefully missing. My 2-year old printer still isn't
 supported on Linux.
Now this is beyond me. Everyone I've talked to says printer support in Linux sucks, but I've been through several printers, and Linux has been the only operating system I've used that's had no problems with it. Regardless of the distro, it picks up a local or network printer and allows me to print without any configuration whatsoever - apparently it doesn't 'just work' for anyone else though. In OS X and Windows I have to manually find network printers and find drivers online, only the latter for local printers. Even then they don't always work. -- Robert http://octarineparrot.com/
May 18 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 18 May 2011 14:51:18 -0400, Robert Clipsham  
<robert octarineparrot.com> wrote:

 On 18/05/2011 16:20, Steven Schveighoffer wrote:
 Printer support is woefully missing. My 2-year old printer still isn't
 supported on Linux.
Now this is beyond me. Everyone I've talked to says printer support in Linux sucks, but I've been through several printers, and Linux has been the only operating system I've used that's had no problems with it. Regardless of the distro, it picks up a local or network printer and allows me to print without any configuration whatsoever - apparently it doesn't 'just work' for anyone else though. In OS X and Windows I have to manually find network printers and find drivers online, only the latter for local printers. Even then they don't always work.
At work, since I've been here (almost 2 years), my laptop always cuts off about 1/8 of an inch from the left of the page. Until the latest upgrade to ubuntu 11, I would have to adjust the "image quality" to 1200 dpi every time I printed (even from the same application) or else any graphics on a page would be super-grainy like I printed it in 1995. I'm sure it works great in some cases. Just not in general. And mostly not for me :( -Steve
May 18 2011
parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 18.05.2011 21:22, schrieb Steven Schveighoffer:
 On Wed, 18 May 2011 14:51:18 -0400, Robert Clipsham
 <robert octarineparrot.com> wrote:
 
 On 18/05/2011 16:20, Steven Schveighoffer wrote:
 Printer support is woefully missing. My 2-year old printer still isn't
 supported on Linux.
Now this is beyond me. Everyone I've talked to says printer support in Linux sucks, but I've been through several printers, and Linux has been the only operating system I've used that's had no problems with it. Regardless of the distro, it picks up a local or network printer and allows me to print without any configuration whatsoever - apparently it doesn't 'just work' for anyone else though. In OS X and Windows I have to manually find network printers and find drivers online, only the latter for local printers. Even then they don't always work.
At work, since I've been here (almost 2 years), my laptop always cuts off about 1/8 of an inch from the left of the page. Until the latest upgrade to ubuntu 11, I would have to adjust the "image quality" to 1200 dpi every time I printed (even from the same application) or else any graphics on a page would be super-grainy like I printed it in 1995. I'm sure it works great in some cases. Just not in general. And mostly not for me :( -Steve
http://localhost:631 Printers -> click on that printer -> Administration -> Set Default Options -> General -> Print Quality
May 18 2011
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-05-18 14:21, Steven Schveighoffer wrote:
 On Wed, 18 May 2011 03:15:50 -0400, Nick Sabalausky <a 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.
The problem I have with my tool is like the chicken and the egg problem. The tool installs D compilers and you're supposed to use the tool without the requirement of an pre-existing DMD compiler.
 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.
I have only had that issue with DMD. I guess it somewhat special since it needs to be compatible with GCC and the linker in another way than regular applications need to be. As far as I know a DMD compiled on an older version will run on a newer version but it's another thing with the executables produced by dmd. I'm still using a very old version of synergy on Mac OS X, I think it was compiled around 2006 on Mac OS X 10.4. I'm using it without any problems on Mac OS X 10.7. -- /Jacob Carlborg
May 18 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Jacob Carlborg" <doob me.com> wrote in message 
news:ir0o9o$1st5$1 digitalmars.com...
 On 2011-05-18 14:21, Steven Schveighoffer wrote:
 On Wed, 18 May 2011 03:15:50 -0400, Nick Sabalausky <a 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.
The problem I have with my tool is like the chicken and the egg problem. The tool installs D compilers and you're supposed to use the tool without the requirement of an pre-existing DMD compiler.
I've been thinking it would probably be possible to bootstrap DVM with a shell script that would wget some specific DMD, set it up, at least enough to build DVM (possibly even automatically building DMD/druntime/phobos/tango - which is something we really need a more automated way to do anway, especially for "trunk" versions (or whatever the Git-lingo for "trunk" is)), and then use that to build DVM. I may give it a try myself.
May 18 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-05-18 22:33, Nick Sabalausky wrote:
 "Jacob Carlborg"<doob me.com>  wrote in message
 news:ir0o9o$1st5$1 digitalmars.com...
 On 2011-05-18 14:21, Steven Schveighoffer wrote:
 On Wed, 18 May 2011 03:15:50 -0400, Nick Sabalausky<a 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.
The problem I have with my tool is like the chicken and the egg problem. The tool installs D compilers and you're supposed to use the tool without the requirement of an pre-existing DMD compiler.
I've been thinking it would probably be possible to bootstrap DVM with a shell script that would wget some specific DMD, set it up, at least enough to build DVM (possibly even automatically building DMD/druntime/phobos/tango - which is something we really need a more automated way to do anway, especially for "trunk" versions (or whatever the Git-lingo for "trunk" is)), and then use that to build DVM. I may give it a try myself.
In the case I just could have written the tool in shell script in the first place and that's what I want to avoid. I hate shell scripts and it would make it even harder to create a version for Windows. I think the right approach is to provied pre-compiled binaries. I downloaded Ubuntu 4.10, or something like that. I'll install it in a virtual machine and try it out. -- /Jacob Carlborg
May 18 2011
prev sibling next sibling parent reply Jonas Drewsen <jdrewsen nospam.com> writes:
On 17/05/11 23.15, Jacob Carlborg wrote:
 I just released a new version of DVM, 0.2.0.
 For installation instructions see: https://bitbucket.org/doob/dvm

 Changelog:

 Version 0.2.0

 New/Change Features
 * 64bit version now available on Linux
 * It's now possible to update an already existing DVM installation
 * Added an option for installing 32bit compilers, useful on 64bit platforms
 * Added support for the new structure of the DMD zip, appeared in
 version 1.068 and 2.053
 * Added a "current" wrapper which points to the current compiler
 * Added an option for specifying a default compiler
 * Better compatible between different shells
 * Added support for installing Tango
 * Added support for installing 64bit compilers (default on 64bit platforms)
 * The fetch/install command now shows progress when downloading. Thanks
 to jdrewsen.
 * Added support for the new structure of the DMD zip, appeared in
 version 1.067 and 2.052.
 * Added a changelog.

 Bugs Fixed
 * RDMD now has executable permission
 * Exit if the DVM executable cannot be found
 * Always remove the temp path
 * Don't use "exit" in the DVM shell script
 * Added dmd.conf patch for druntime as well.
 * Fixed: DMD2 was incorrectly handled.
 * Bump version number.


 Sorry, still no version for Windows. I've seen another application that
 does the same but for Ruby, on Windows, so now I know it should be
 possible at least.
This is a very nice tool. Keep up the good work! /Jonas
May 18 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-05-18 13:11, Jonas Drewsen wrote:
 On 17/05/11 23.15, Jacob Carlborg wrote:
 I just released a new version of DVM, 0.2.0.
 For installation instructions see: https://bitbucket.org/doob/dvm

 Changelog:

 Version 0.2.0

 New/Change Features
 * 64bit version now available on Linux
 * It's now possible to update an already existing DVM installation
 * Added an option for installing 32bit compilers, useful on 64bit
 platforms
 * Added support for the new structure of the DMD zip, appeared in
 version 1.068 and 2.053
 * Added a "current" wrapper which points to the current compiler
 * Added an option for specifying a default compiler
 * Better compatible between different shells
 * Added support for installing Tango
 * Added support for installing 64bit compilers (default on 64bit
 platforms)
 * The fetch/install command now shows progress when downloading. Thanks
 to jdrewsen.
 * Added support for the new structure of the DMD zip, appeared in
 version 1.067 and 2.052.
 * Added a changelog.

 Bugs Fixed
 * RDMD now has executable permission
 * Exit if the DVM executable cannot be found
 * Always remove the temp path
 * Don't use "exit" in the DVM shell script
 * Added dmd.conf patch for druntime as well.
 * Fixed: DMD2 was incorrectly handled.
 * Bump version number.


 Sorry, still no version for Windows. I've seen another application that
 does the same but for Ruby, on Windows, so now I know it should be
 possible at least.
This is a very nice tool. Keep up the good work! /Jonas
Thanks. -- /Jacob Carlborg
May 18 2011
prev sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Tue, 17 May 2011 23:15:42 +0200, Jacob Carlborg wrote:

 I just released a new version of DVM, 0.2.0. For installation
 instructions see: https://bitbucket.org/doob/dvm
 
 Changelog:
 
 Version 0.2.0
 
 New/Change Features
   * 64bit version now available on Linux * It's now possible to update
   an already existing DVM installation * Added an option for installing
   32bit compilers, useful on 64bit
 platforms
   * Added support for the new structure of the DMD zip, appeared in
 version 1.068 and 2.053
   * Added a "current" wrapper which points to the current compiler *
   Added an option for specifying a default compiler * Better compatible
   between different shells * Added support for installing Tango
   * Added support for installing 64bit compilers (default on 64bit
 platforms)
   * The fetch/install command now shows progress when downloading.
 Thanks to jdrewsen.
   * Added support for the new structure of the DMD zip, appeared in
 version 1.067 and 2.052.
   * Added a changelog.
 
 Bugs Fixed
   * RDMD now has executable permission
   * Exit if the DVM executable cannot be found * Always remove the temp
   path
   * Don't use "exit" in the DVM shell script * Added dmd.conf patch for
   druntime as well. * Fixed: DMD2 was incorrectly handled. * Bump
   version number.
 
 
 Sorry, still no version for Windows. I've seen another application that
 does the same but for Ruby, on Windows, so now I know it should be
 possible at least.
I just installed DVM, and it seems like a very useful tool. It works pretty well, but I ran into an issue for which I created a bug report: https://bitbucket.org/doob/dvm/issue/5/invalid-character-in-dvm-env-files Also, I have some suggestions for features you may want to add in the future. I'll add enhancement requests for these. Thanks for making a nice tool! -Lars
May 31 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-05-31 12:25, Lars T. Kyllingstad wrote:
 On Tue, 17 May 2011 23:15:42 +0200, Jacob Carlborg wrote:

 I just released a new version of DVM, 0.2.0. For installation
 instructions see: https://bitbucket.org/doob/dvm

 Changelog:

 Version 0.2.0

 New/Change Features
    * 64bit version now available on Linux * It's now possible to update
    an already existing DVM installation * Added an option for installing
    32bit compilers, useful on 64bit
 platforms
    * Added support for the new structure of the DMD zip, appeared in
 version 1.068 and 2.053
    * Added a "current" wrapper which points to the current compiler *
    Added an option for specifying a default compiler * Better compatible
    between different shells * Added support for installing Tango
    * Added support for installing 64bit compilers (default on 64bit
 platforms)
    * The fetch/install command now shows progress when downloading.
 Thanks to jdrewsen.
    * Added support for the new structure of the DMD zip, appeared in
 version 1.067 and 2.052.
    * Added a changelog.

 Bugs Fixed
    * RDMD now has executable permission
    * Exit if the DVM executable cannot be found * Always remove the temp
    path
    * Don't use "exit" in the DVM shell script * Added dmd.conf patch for
    druntime as well. * Fixed: DMD2 was incorrectly handled. * Bump
    version number.


 Sorry, still no version for Windows. I've seen another application that
 does the same but for Ruby, on Windows, so now I know it should be
 possible at least.
I just installed DVM, and it seems like a very useful tool. It works pretty well, but I ran into an issue for which I created a bug report: https://bitbucket.org/doob/dvm/issue/5/invalid-character-in-dvm-env-files Also, I have some suggestions for features you may want to add in the future. I'll add enhancement requests for these. Thanks for making a nice tool! -Lars
I'll have a look, thanks. -- /Jacob Carlborg
May 31 2011