Re: How to define a release architecture
On Sat, Mar 26, 2005 at 12:38:05AM -0800, Steve Langasek wrote:
> On Tue, Mar 22, 2005 at 01:01:24PM +0100, Wouter Verhelst wrote:
> > On Mon, Mar 21, 2005 at 05:28:51PM -0800, Steve Langasek wrote:
> > > This adds up to a lot of effort for a dead-end architecture. Do
> > > you believe that such ports are going to command enough interest
> > > to be able to keep up with Debian's stable support requirements
> > > for more than 2 1/2 years (18mo. release cycle + 1 year support
> > > for oldstable) after being discontinued as a product?
>
> > I'm assuming you're talking about m68k here. If not, please correct me.
>
> Hmm, not particularly. I don't really have any preconception/prejudice that
> the processors need to be in ongoing use in new *desktop* products; Debian
> obviously runs the gamut from mainframe to server/desktop to embedded.
>
> If the m68k architecture is still being used in new systems capable of
> running Debian, then I think this requirement is met.
That is the case. The BVM VME modules are capable of running Debian (and
did so with woody); the q60 machines should be, too (although they are
not supported with bootfloppies and not very well tested with d-i)
> > m68k has been EOLed in desktop hosts for about 10 years now. There are
> > still people interested in it, who install Linux on their old hardware
> > for the first time, even today.
>
> > I think that pretty much translates to an answer of 'yes' to the above
> > question.
>
> Possibly, but I'm not convinced that potential userbase size ever guarantees
> a viable port just by numbers alone. I don't know if the liveliness of the
> m68k community is related to the continued availability of new m68k
> processors (which are still available, based on the general response I've
> gotten that this requirement doesn't affect any of our current ports? Even
> though I don't know where to find a new m68k myself).
http://www.bvm.co.uk/vmeprods.html
http://www.q40.de/
These are systems that can be bought new today, and are supported under
Debian. The VME requires one to have a VME case, but it should (in
theory) work in a new VME case as well (the VME technology is a single
board computer bus architecture that is an industry standard, somewhat
comparable in function to the blade system).
http://www.czuba-tech.com/CT60/english/welcome.htm
for the CT60 and CT63, which are expansion boards for the Atari Falcon.
The CT60 was designed only one or two years ago, while the CT63 is even
more recent. They both allow one to upgrade a Falcon to a 68060-based
system that would run at 100Mhz. There are some Debian/m68k porters that
own one of the CT60 boards, and we're working on getting them supported.
Since the board requires one to already own an Atari Falcon, however,
I'm not sure whether this satisfies your requirement; but it sure does
show that the m68k community is far from dead (else there wouldn't be
any interest in such a board design, let alone two of them).
> I would be inclined to suspect that it is.
[related to availability of the processor]
So would I; but as it is still available (and still quite often used in
embedded situations), I would think that this is not currently a
problem.
> > If the DSA people do not have enough time to spend in keeping stable
> > security buildds for old architectures running, they are welcome to hand
> > over buildd maintenance to other people; there are enough experienced
> > people to take over, if required.
>
> If they choose to do so, that's fine with me; however, particularly for
> buildds for stable-security, I think it's important that the machines be
> under the de facto authority of DSA
They already are. If a machine would not satisfy a requirement set by
DSA, they can remove that machine's SSH key from the wanna-build
authorized_keys file.
> -- even though they might delegate a particular machine's
> administration to someone who doesn't have authority over Debian
> machines in general.
So what would be the difference with today?
> > In the specific case of OpenOffice.org, the point is moot.
> > OpenOffice.org requires some assembly glue, so needs to be ported to
> > every architecture it runs on; currently, there are OpenOffice.org
> > packages for i386, powerpc, sparc, and s390; none for any of the slower
> > architectures, and doing them wouldn't be possible without someone
> > spending their time on it anyway.
>
> The OOo example was not mine;
I know, but I found it necessary to explain this bit.
[...]
> > > The porters don't control the size of the largest packages in the archive;
> > > and package sizes do continue to go up, just like everything else.
>
> > Not just that; package build times for equally-sized packages continue
> > to go up as well, because of increased optimisation.
>
> Indeed. So eventually, all architectures will be able to run the code, but
> none will be able to build it. ;)
Heh :)
--
EARTH
smog | bricks
AIR -- mud -- FIRE
soda water | tequila
WATER
-- with thanks to fortune
Reply to: