> I think that the SNI thing, expecially under your point of view, is very good.
> It is a germany based company and it shows as collaborative. Marketing chances
> for theyr machines are much higher than for hybrid MIPS/PC we are hacking just
> now, that are ~4 years old.
Consider even the fact that we have quite some different machine types and
just a few more developers. No good thing for fast advance. I'm a big fan
of hard and software architectures that are not as uniform as the biggest
part of the PC and Mac world. But we're beyond what is acceptable.
> I will release my gcc 2.7.0 binaries and libc 4.something UNLESS some serious
> known bug prevents to do so. Then we can schedule the next release to let's
> say four months. This will give to the people that work on it all the time
> to add new features, fix the bugs, and release a comprensive source/binaries
> package. I want to say my opinion about binaries distributions here. They
> are GOOD. A great point of force for Linux is they large availability.
> Basically they allow a fresh hacker, let's somebody that isn't yet very
> skilled about gnuism, unix code and stuff, to gradually approach the system
> and it's complexity. Not everybody is fascinated by the 'tools to make tools'
> > paradigm, at least not at the very starting point of a project.
I've got a binary package with GCC 2.7.1/binutils 2.5.2 compiled for both
ELF and a.out targets on a tape here at the university. The problem ist
just that I've got neither an Exabyte nor DAT at home nor can write QIC-24
tapes and so need to find someone who can convert my tape ...
About the sources - two days ago I tried to bootstrap a complete Linux/MIPS
crossdevelopment with all whistles and bells from nothing but sources. I
had to find that it's tricky to do the things in the right order. Didn't
remember that it was such a pain ... Someone who hasn't done that before
will probably go crazy due to all the things that don't compile.
As example - GCC's makefile tries to test the cross compiler by building a
little program. That of course fails because there are no libraries
installed yet. You again can't build the library because the compiler isn't
installed yet. So you need to install the compiler manually. Some minor
changes in the kernel also break compiling the old libc 4.6.27 that I'm
discontinuing to support and oh, why is that damned float.h thing GCC is
always complaining about ...
Probably just a few people on this list know all the traps building all that
stuff. In short: I'll build binary distributions of exactly the utilities
that I'm using from now on. If you people post it I can also try to
build crossdevelopment kits for other architectures that I can access.
Or maybe even building a big killer makefile (NOT FOR RISC/OS :-) that knows
all the traps of building a crossdevelopment environment. Using that
even people with machines that I can't access (SGI :-( should be able to
build an uptodate crossdevelopment environment with no trouble. How about
(But remember - a 486/33 will need a night to build all that stuff ...)
> > A last word to the rules Paolo mentioned, even at the risk that
> > I repeat myself: The rule should be to move Linux/MIPS to a
> > usable state. Then it becomes fun anyway.
> I think that everyone should agree on this.
Of course. The big time of nuking everything is over. Just some minor
fixes are missing; then we should be in the *real* Linux buisness.