* Raul Miller (moth@debian.org) wrote: > The problem here -- the reason these alternatives are expensive -- > is that they don't offer a migration path. The resulting low volume > sales has kept the price high. Or because they're more expensive to manufacture, have a lower good yield turnout, and are overpriced by their manufactures to begin with (hint: this is much more likely). Hey, here's a good point too: most people buy new *systems* which include new *disks* which they have to install on to (at least, most of our users anyway). They can handle *installing* on to those systems. If all they need on those systems is Debian, then, hey, they've got it, or as much as builds (97% or whatever). We don't suffer the Winbloze problem of lots of legacy code they refuse to update to work with recent/different archs. > > i386 systems are sold in bulk (low prices), and are assembled in a commodity > > manner which gives a good variety of parts that can be used. AMD64 is just > > the next generation of i386 server CPUs. Soon the 32bit Athlon and P4 CPUs > > will go the same way as the K6 and the P2 and it'll be all 64bit from both > > AMD and Intel. > > Yep. Unfortunately, the current debian amd64 port pretty much ignores > this, because it's "inelegant". This just doesn't make any sense. We're trying to put together *something* that can be used by these people, and is *faster* and what people *want* to run on the systems they buy. You're trying to say that we ignore them and that instead we shouldn't be trying to release amd64 w/ sarge? How does that make any sense? > > Once CPUs capable of running the AMD64 instruction set are commonly available > > a straight AMD64 system with no 32bit compatibility will be better than PPC > > on the basis of price and features. > > That is true, and I did ignore this aspect. However, by this logic, > we should consider "amd64 architecture which offers 32 bit > compatability" to trump "ppc architecture which does not". > > In other words, "that ppc doesn't have a /lib64" isn't sufficient reason > to not use that system on amd64. No, the fact that it sucks is plenty enough reason all by itself. Get over it. We're not going to modify all of the libs right before sarge releases. We're certainly not going to modify all of the libs *now* and then *again* in 3 (if that..) months when we start implementing multiarch. The options that remain are: a) release sarge with pure64/amd64 support - Good enough for most people - Can still run some 32bit apps using ia32-lib - Can run 32bit apps in a chroot b) release sarge with *no* amd64 support Running around 'real quick' and changing all the libs to be biarch so that we can then release sarge and then turn back around and change all the libs *again* for multiarch just isn't an option. Stephen
Attachment:
signature.asc
Description: Digital signature