68k and coldfire and future
what i understood from reading about coldfire:
it is 10x faster than 68060 (not fast by today's standards,
but still capable if not unreasonable about demand from it)
it is problematic in some floating point areas
-- not that much faster there (think ppc604*), more in the integer part
-- it does not really support the traditional 68k method of using trap,
which is severely deprecated in all the rest of the computing world
(* but with faster memory and bus and other fresher connectivities)
-->>> 68k has to change some to accomodate CF.
it is very efficient, suitable for a handheld computer.
(a real step from the old apple Newton, anyway)
i believe that handhelds will be the hot product in the next few
years. we don't expect them to be so fast. but us Linux people
would like something like a fair respectable OS. it could require
some packages need build on a desktop or/and with cross/dist
compilers.
______________
could someone explain issue with TLS,
? it is needed because SSL is not up to GNU FSW standards ?
? the GNU package for TLS does not build without some hidden
assumed support ? I looked on the GNU download page and it mentions
it requires one package but that says nothing to do with glibc... (its
crypto s/w).
_____________
i don't see that there is any real future in only a "virtual" 68k machine...
why bother ?
however, note that the parrot VM is based on a CISC design. with lots
of Registers. they say that is how apple did succeed with their VM of
68k on ppc. (see my other post today on parrot).
________________
i really feel strongly that Debian needs a lite sub-distro. for one
thing to concentrate support for useable software. this could be
a multi-arch effort.
i don't like heavy software. (its like burning off natural gas to get to oil)
realistically, the value of 68k as a teaching tool is high. because of
its limitations partly. you learn how to make best use of limited resources.
with new computers you learn the opposite...
i think though it would be hard to get maintainers to focus on bugs where
most of the software is (realistically) unuseable on this platform, because
of the hardware limitations. if at least one of the members of the port
was reasonably fast (not counting virtual machines) it could make a big
difference, especially if it were represented at least hope of a portable
machine... (at least hope of popular, not too popular of course). or/and
another way is to cut the list packages from 14,000 to say, ?3000??
Brian
Reply to: