Re: Future of m68k - Etch and beyond
On Wed, 28 Feb 2007, Ingo Juergensmann wrote:
[snip]
> > 2. General purpose PC for lightweight GUI apps: word processing with
> > SIAG Office, FLWriter, or AbiWord, email with Silpheed, light Web
> > browsing with Dillo, and so on.
>
> I'll travel today to my parents house again. Usually I use one of my old
> computers to act as a temporary workstation.
I agree. There are loads of packages that are still viable.
> > 3. Programming platform for students, and amateur programmers like
> > me. M68k is great for learning programming: the assembly language
> > is nice, and there's plenty of improvement left to be made. There
> > are a lot of things somebody could contribute to open source
> > operating systems for the 68k. Not everything has already been
> > done.
>
> Sadly, the CS dept on the local university is teaching x86 assembler and
> I think it this is similar to other CS depts. ;)
Perhaps so, but in electronics departments, that doesn't really hold.
Microcontrollers are more important, and it seems to be that the best one
for teaching assembler is the 68HC11.
> > 4. Increase the 'genetic diversity' of the 'Net. With Apple moving
> > to x86, we have reached a historic low point in the diversity of
> > computing hardware on the Internet. While the short-term benefits
> > might be in the economies of scale, one major down-side is that it
> > makes the job of malicious programmers that much easier. It's
> > quite conceivable that a single binary could be devised that would
> > infect MacOS and MS-Windows, and probably also x86-based Linux
> > systems as well. But making it run on a 68K Amiga or Atari would
> > be much more difficult. And why would anybody ever bother?
>
> Well, Debian is about freedom (of choice). It's obvious that there needs
> to be diversity to have a choice of at all. Within a x86 world, there's
> no diversity and therefore no choice. Sure, there's AMD and there's
> Intel, but that is like having the choice between poppy seed rolls and a
> normal bap. So, after Debian has fought the monolithic OS world of MS
> Windows, it's now supporting a monolothic world of x86 architure by
> pushing other archs out of the release. That's bad because one of
> Debians main strengths was to have the same operating system throughout
> all of your favorite archs. So, when this advantage is going away, why
> should I bother to use Debian at all, when there are other distributions
> that are more uptodate, are more polished, etc?
There are other distributions that have more flexibility. On small
machines, the best distros are the source-based distros. Reason being, it
is easier to control dependencies, CPU tuning and configure options to
avoid wasting the limited resources. Binary package support is necessary
too.
> > As I've said before on this list, I think Damn Small Linux would be a
> > great model for an m68k-centric mini-distro. It has Debian roots,
> > which should simplify morphing Debian/m68k in that direction. The
> > MyDSL mini-package system is great for small systems. And focusing
> > the GUI elements around FLTK would be a good move.
>
> I think most of the Debian m68k porters would prefer to stay with Debian
> instead of another distro. Just an assumption... ;)
Yes, but I'll say it anyway: Gentoo gives you sufficient flexibility
<ducks>
Just the fact that they don't really have a "release cycle" makes it
attractive. And (apparently) it has already been ported to m68k. And it
now supports multiple package repos...
I can't say I've tried their m68k port, but I will do so when I get around
to it -- particularly now that paludis (written in C++) is able to replace
portage (written in python).
[snip]
> > I think such a thing is quite doable, considering the level of effort
> > that has already been put into continuing to support the m68k
> > architecture in Debian. Perhaps the time, computing resources, and
> > expertise would be better spent if it were directed toward a somewhat
> > more narrowed goal and a significantly narrowed set of packages.
>
> I agree here, of course. It's just insane to have to built 6600 source
> packages just because of "we are able to build them", when rarely 1000
> are commonly used.
Used or not, they help validate the tool chain.
Well, until aranym gets faster, it may be insane to offer _certain_
packages. And it seems to me that, when the archive doubles in size, then
the build farm must double too. But this isn't what killed the etch
release.
The problem with the debian archive on small machines is the archive
itself: packages are ./configured --with-3-kinds-of-kitchen-sink, and the
reverse dependencies can expect that. This blows out the number of deps,
build time, run-time RAM and disk consumption etc. And, no, that isn't
what killed the etch release either, but I think it illustrates where the
aims of the project tend to diverge from the needs of one port.
-f
Reply to: