On Tue, Jun 28, 2011 at 9:17 PM, Jimmy Cao <[email protected]> wrote:
> On Tue, Jun 28, 2011 at 9:05 PM, Andrew Wiley <[email protected]>wrote: > >> On Tue, Jun 28, 2011 at 3:13 PM, Nick Sabalausky <[email protected]> wrote: >> >>> "Michel Fortin" <[email protected]> wrote in message >>> news:[email protected]... >>> > On 2011-06-28 15:39:42 -0400, Walter Bright < >>> [email protected]> >>> > said: >>> > >>> >> On 6/28/2011 12:13 PM, Jacob Carlborg wrote: >>> >>> Since most of the applications and most the libraries (basically all >>> >>> that ships >>> >>> with Mac OS X) are universal there's usually no problem of >>> >>> running/building both >>> >>> 32 and 64bit software. >>> >> >>> >> I'll explain the motivation for 64 bit only DMD binaries: >>> >> >>> >> 1. It cuts the testing time in half. This is a significant deal for >>> me, >>> >> as adding another hour to the test cycle slows things down a lot. >>> >> >>> >> 2. It speeds downloading the dmd package. >>> >> >>> >> The only reason to have a 32 bit binary is if there are x86 Macs 10.5 >>> or >>> >> later that are incapable of running 64 bit code. >>> > >>> > Well, you could ship the next DMD version 64-bit only and of you get >>> > complains you bring back the 32-bit version as a universal binary. >>> > >>> > But you'll definitely rule out users of Apple's early Intel computers. >>> I >>> > think the last Apple model with a 32-bit CPU was the "Mac Mini (Late >>> > 2006)", which was replaced mid 2007 with a Core 2 Duo model. >>> > >>> > As for increasing the download speed, you could try one of these too: >>> > >>> > * separate per-OS packages >>> > * separate source package >>> > * separate documentation package >>> > * faster server >>> >>> * use 7z >>> >>> Using 7z instead of zip or tarballs has shrunk the size of my packaged >>> Goldie releases down to roughly one-quarter the size of a zip or tar.bz2 >>> (Yes, ~75% decrease is size). Of course, that's probably an extreme case, >>> but I just tried making a 7z of DMD 2.053, and it came out to just under >>> 9MB >>> (vs just over 15MB for the official zip release), so fairly close to half >>> the size. Still pretty damn good. >>> >>> And I really see no reason why any programmer shouldn't have a 7z-capable >>> extractor these days. Heck, it's pretty typical on Linux, and it's built >>> into WinRar. Zip and tarballs are like MP3's: They're still everywhere, >>> but >>> only because of inertia, not because of any inherent merit, of which >>> there >>> really isn't any. 7z is like moving to Vorbis (Except that I think 7z >>> support is probably more common than Vorbis support, which is unfortunate >>> for Vorbis fans like me, but that's even more OT...). >>> >>> >>> >> Have you tried xz on Linux? I think WinRar supports it on Windows, but I >> haven't checked in a while. >> >> > > I just tried using WinRAR to open a tar.xz file, and it didn't work. > Ah, then I suppose I'm a liar and/or delusional. I remember opening one on Windows with some archiver, but I've only ever done it a few times, and not on a box I have access to at the moment.
