[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: -= PROPOSAL =- Release sarge with amd64

* 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.


Attachment: signature.asc
Description: Digital signature

Reply to: