Jan > It would be very good if one set of components was chosen
Jan > as a standard PC and development would be based on that one set
Jan > of hardware components.

Not so needed IMHO. With working generic IDE driver, generic
VESA framebuffer graphics, three generic types of network cards
(Realtek, Intel, 3com), generic AC97 sound... we already mostly have
such unified office i386 x86-32 platform... Let's hardware support will be
provided by NetBSD or Linux kernel compiled for 586-mmx.
Just use it by syscalls from small programs, builded with optimising linker.

Jan > Yes, syscalls would be ideal. But it would be necessary to write a
Jan > new small kernel in assembler for the standardised hardware.
Jan > A terrible job.

I don't think we really needs this 'millions lines of code'.
It's not really achivement, those lines. It is traces of lazyness))
If programmers was paying for each line of code we now have much
better programs))

But anyway, why do so hard work)) Assembly usage must be minimised.
We need HIGH level environment, wich helps REDESIGN old systems and iteratively
desing new. And separate IMP/DEF of Modula-2 greatly helps in changes
ordering, isn't it?)) THIS is source of Modula-2 magic. Like arrow stabilizer
or architector templates for drawing lines or car brakes.

In searching ways to replace huge libc i read on... dietlibc, uclibc, etc...
But then i think that this search already was passed by all good ASSEMBLER
programmers. Now i found some mini-libc in asmutils-0.18 package by
Konstantin Boldyshev. He says this i386 lib was portable between Linux and all
BSD flavours - NetBSD, FreeBSD, OpenBSD. In next days with help of NASM
in spare time i try to rebuild Mocka on top of this assembler minilibc.
Asmutils contains some demos showing that file io, console support and
some _graphics_ on top of it... possible?
Doing 'nm -s' on mocka library i found that it use not so many from libc.
And only more or less basic calls. 15-20.

Jan > Oberon-0 is high on my list of priorities for many years now.
Jan > I managed to port the first part of the Oberon-0 compiler to Linux.
Jan > I just need to port the rest....

Oberon is good, yes. But it's problems follows it's achivements.
Because Oberon is a system ARCHITECTURE, not just language. It builded
to show possibility of great simplifications in OVERALL system if properly
design it from scratch, without legacy compromises. And so Oberon MUST have
own system/runtime support. And so not so easy integrates with legacy systems.
More logic in runtime means greater possibility of conflicts with legacy
app logic, problems with realtime and predictability, etc. Sample: caml,
haskell. Maybe YAFL. I know that metaprogramming was useful in Oberon also,
just can't download yafl to taste it))

And more, i think that 'inheritance considered harmful'))
Because breaks encapsulation and hides relations between components.
Maybe some other feature (like multiple interfaces to one implementation)
do that work better.

On the other side, Oberon make some other achivements over Modula-2.
In syntax, etc. Really we need in future some hybrid of Modula-2 and Oberon.
Halfway. And not one of both 'bigger' than other. Both languages just
different.

But now we must start with something. Using available existing proven
Modula-2... Really, all modula not needed. Integer only arithmetic will be
sufficient for compiler. But just now we can use Modula-2 as is.
Plan own path, then start travel with little steps. There.
Then there. And so on.
Mocka and direct syscall-based libc is just relatively small first step.

I hear about SPIN. I just don't like Modula-3. It's halfway to Ada bloat.
Too hard to support. Sure we may read some sources from SPIN and LUMOS.
If needed.

Christoph > I never managed to get an executable out of the combination
Christoph > of Linux and ACK. Any stories of success out there?

i just think what ACK was not minix-only... maybe wrongly...
i see ACK-5.5 files dated 1991-2002 years. Installation text lists some
old unixes and possibility of success build on generic unix. Jan also
confirm this possibility and problems in way. Only in other words.

jes > That's interesting. 68K machines are old and probably obsolete,
jes > but I've got a bunch of old McIntosh of different kinds, all of
jes > them based on the 68K family...

in my private opinion there is no such thing as old or weak processors.
every processor just or works reliably or not works at all.
speed not so critical on many people's tasks...
in our hospital we have working 68030-based (multiprocessor, 4-5 boards
in backplane) Picker X-ray tomograph...
and not so many days back i replace my previous workhorse
WinchipC6-188mhz by athlon64-3000. not because need, only because
latest now sooo cheap)) in console mode you see difference only when
start compile/archiving))

P.S. forgive me leaky english, i'm russian and only trained in reading
english docs, not writeing it))
...maybe i need to say two words with russian oberon/blackbox
community? This maybe helps in their porting BlackBox-1.5 to Linux...

sincerely yours, 4k. <GDKBadmin on wsr.ru>