18 May
2016
18 May
'16
6:31 a.m.
On 17 May 2016 at 20:21, Sean Conner <spc at conman.org> wrote:
There is surely an important difference between requirements to meet a
definition, and requirements for being of pragmatic value.
Sure, there are microkernels on MMU-less hardware. I was vaguely aware
of QNX on 8088 although it had slipped my mind.
But in a real-world general-purpose computer, is there much point?
AIUI the main intention of microkernel designs in the Unix space was
to promote code simplicity and clarity, ease debugging, and increase
reliability. Is that not so?
Not in light of this blog article: http://prog21.dadgum.com/173.html
Conceded!
The Wintel monopoly of the desktop flooded Intel with enough money to keep
the x86 line going. Given enough money, even pigs can fly.
True.
I liked a friend's suggestion recently on Twitter:
@sbisson
Here's a thought. If Intel updated the i960 RISC architecture for
modern processes, would it have the ARM competitor it's looking for?
I personally wouldn't mind a few user bits per byte myself. I'm not sure
we'll ever see such a system.
Nor am I. Doesn't stop me hoping, though.
It's in reference to Alan Kay saying "burn the disc packs" with respect
to
Smalltalk (which I was told is a mistake on my part, but then everybody
failed to read Alan's mind about "object oriented" programming and
he's
still pissed off about that, so misunderstanding him seems to be par for
course).
Aha!
Touch?.
I have a link about that if I can only find it, but not wanting to
leave this dangling for another week...
--
Liam Proven ? Profile: http://lproven.livejournal.com/profile
Email: lproven at cix.co.uk ? GMail/G+/Twitter/Flickr/Facebook: lproven
MSN: lproven at hotmail.com ? Skype/AIM/Yahoo/LinkedIn: liamproven
Cell/Mobiles: +44 7939-087884 (UK) ? +420 702 829 053 (?R)
It was thus said that the Great Liam Proven once
stated:
:-)
This has been waiting for a reply for too long...
As has this ... On 4 May 2016
at 20:59, Sean Conner <spc at conman.org> wrote:
Nope, memory management is not a requirement for a microkernel. It's a
"nice to have" but not "fundamental to implementation." Just as you
can have
a preemptive kernel on a CPU without memory management (any 68000 based
system) or user/kernel level instruction split (any 8-bit CPU).
Part of that was the MMU-less 68000. It certainly made message passing
cheap (since you could just send a pointer and avoid copying the message)
Well, yes. I know several Amiga fans who refer to classic AmigaOS as
being a de-facto microkernel implementation, but ISTM that that is
overly simplistic. The point of microkernels, ISTM, is that the
different elements of an OS are in different processes, isolated by
memory management, and communicate over defined interfaces to work
together to provide the functionality of a conventional monolithic
kernel. If they're all in the same memory space, then
even if they're
functionally separate, they can communicate through shared memory --
While the Amiga may have "cheated" by passing a reference to the message
instead of copying it, conceptually, it was passing a message (for all the
user knows, the message *could* be copied before being sent). I still
consider AmigaOS as a message based operating system.
Also, QNX was first written for the 8088, a machine not known for having a
memory management unit, nor supervisor mode instructions. I think what made the Amiga so fast (even with a
7.1MHz CPU)
was the specialized hardware. You pretty much used the MC68000 to script
the hardware.
That seems a bit harsh! :-) While I might not fully agree with his views, he
does make some compelling
arguments and makes me think.
Well, I take your point and TBH I think I'd mostly agree with you. But
I can also see that for many people Mencius Moldbug goes too far.
But Curtis Yarvin is a strange person, and at
least via his
pseudonymous mouthpiece Mencius Moldbug, has some unpalatable views.
You are, I presume, aware of the controversy over his appearance at
LambdaConf this year?
Yes I am. My view: no one is forcing you to attend his talk. And if no
one attends his talks, the liklihood of him appearing again (or at another
conference) goes down. What is wrong with these people? Nice in theory. Glacial performance in practice.
Everything was glacial once.
We've had 4 decades of very well-funded R&D aimed at producing faster
C machines. Oddly, x86 has remained ahead of the pack and most of the
RISC families ended up sidelined, except ARM. Funny how things turn
out. Internally, the x86 lines is RISC. The legacy
instructions are read in
and translated into an internal machine lanuage that is more RISC like than
CISC. All sorts of crazy things going on inside that CPU architecture.
True, but it's not alone in that. Transmeta went further and I am
still sad that they did not push the idea further.
The Lisp machines had tagged memory to help with the
garbage collection
and avoid wasting tons of memory. Yeah, it also had CPU instructions like
CAR and CDR (even the IBM 704 had those [4]). Even the VAX nad QUEUE
instructions to add and remove items from a linked list. I think it's
really the tagged memory that made the Lisp machines special.
We have 64-bit machines now. GPUs are wider still. I think we could
afford a few tag bits. Of course we need
to burn the disc packs.
I don't understand this. It's also an oblique reference to Charles Moore,
who has gone on record as
saying the ANSI Forth Standard is a mistake that no one should use---in
fact, he's gone as far as saying that *any* "standard" Forth misses the
point and that if you want Forth, write it your damn self!
OIC. Yes. This sort of attitude is one of the problems.
There are, I think, at least 3 types of programmers:
* Geniuses, who can use very hard, dangerous, tools safely to achieve
amazing things. Such tools include C, Lisp, assembler, etc.
* Non-geniuses, most of whom are in accordance with Dunning-Kruger and
don't know it. They use the same tools, make mistakes, and the results
go wrong in tragic or very expensive or disastrous ways. At best, they
produce stuff that mostly works most of the time, and their output
comprises the bulk of the industry.
* Workmen. They don't think they're geniuses, they just have a job to
do, but the freedom to choose their own tools. For me, they are
perhaps best exemplified by the legions of Delphi developers that used
to get a ton of work done in the Windows space. More recently -- or in
the FOSS world, perhaps -- it's Python.
Finally, of course, there is the fourth type: people writing code who
do not consider themselves programmers at all. Vast Excel
spreadsheets, self-taught builders of elaborate Access databases, or
dabblers using VB building simple little hacks that evolve over years
into complex systems that are nearly unmaintainable.
The problem is that type #2 here covers most people, and sadly, the
ivory towers of the industry & academia do not accept that certain
languages or language features are actually widely-liked or attractive
to people because they do not fit with the prevailing wisdom. So,
although, for instance, TP & later Delphi demonstrated that the Pascal
family can be appealing, practical, and a desirable choice; and the
Oberon OS proves that the Pascal family can be used to build an
entire, practical, useful and widely-used (in its niche) OS from the
metal up.
But no, the received wisdom is that Pascal & its relatives are not
suitable for OS construction, and not well suited for the creation of
commercial apps. So, instead, we have a global
multi-hundred-billion-dollar problem with buffer overflows and
stack-smashing attacks, because EVERYONE knows that C is more suitable
for OS kernels and that if you need performance and tight code then C
is a good choice.
If you mean
that, in order to get to saner, more productive, more
powerful computer architectures, we need to throw away much of what's
been built and go right back to building new foundations, then yes, I
fear so.
Careful. Read up on the Intel 432, a state of the art CPU in 1981. Yes, tear down
the foundations and rebuild, but top of the new
replacement, much existing code could, in principle, be retained and
re-used.
And Real Soon Now, we'll all be running point-to-point connections on
IPv6 ...