strangest systems I've sent email from

[Liam Proven]

On 17 May 2016 at 20:21, Sean Conner <spc at conman.org> wrote:
> 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:
>> >
>> >   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.
>
>   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).
>
>> 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.

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?

>> >  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! :-)
>
>   Not in light of this blog article: http://prog21.dadgum.com/173.html

Conceded!

>   While I might not fully agree with his views, he does make some compelling
> arguments and makes me think.
>
>> 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?

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.

>> >   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.
>
>   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?


>   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.
>
>   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.

>> >  Of course we need
>> > to burn the disc packs.
>>
>> I don't understand this.
>
>   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!

>   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.

Touché.

>> 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 ...

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)