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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
