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.
