[TUHS] Mushi and Bagu

[TUHS] Mushi and Bagu

[Rudi Blom]

Tonal languages are real fun. I'm living and working in Bangkok,
Thailand and slightly tone deaf am still struggling.

Which reminds me, regarding binary there are 10 types of people, those
who understand and those who don't :-)

Cheers,
rudi

[TUHS] Mushi and Bagu

[jsteve]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 797 bytes --]

Try Cantonese… 9 tones, or 10, or 12.  Nobody agrees on how many which makes it all the more fun.  The more I learn, the more I don’t know it just adds in more confusion.

I never realized I was tondeaf until I moved to Hong Kong.

Sent from Mail for Windows 10

From: Rudi Blom
Sent: Friday, 17 February 2017 3:43 PM
To: tuhs at minnie.tuhs.org
Subject: Re: [TUHS] Mushi and Bagu

Tonal languages are real fun. I'm living and working in Bangkok,
Thailand and slightly tone deaf am still struggling.

Which reminds me, regarding binary there are 10 types of people, those
who understand and those who don't :-)

Cheers,
rudi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170216/9c3c2259/attachment.html>

[TUHS] Mushi and Bagu

[Nick Downing]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1916 bytes --]

I don't think Westerners are actually tone deaf as such. It's
basically that we didn't exercise our ability to tell those tones
apart when we were acquiring language, so we more or less lost the
opportunity to learn it when we could. Although it can be learnt
later, something that happens as a very natural process during
language aquisition, becomes a very artificial process involving
MONTHS or YEARS in the lab listening to tapes and testing oneself and
so on. Acquiring tones is somewhat similar to having perfect pitch in
music. There are courses out there that claim to teach you perfect
pitch. And, I believe it CAN be learnt, but it is an extraordinary
amount of work and will probably slide backwards if not maintained.
Anyway, I still find the phenomenon really strange and intriguing. My
wife is Vietnamese and I was at her relatives' house just tonight. I
spoke a little Vietnamese to her aunt and she didn't understand me at
all (as usual). It's because what sounds to us identical, sounds to
her like a completely different word -- so much so, that her brain
doesn't even register any similarity.
cheers, Nick
PS OT sorry.

On Thu, Feb 16, 2017 at 8:36 PM,  <jsteve at superglobalmegacorp.com> wrote:
> Try Cantonese… 9 tones, or 10, or 12.  Nobody agrees on how many which makes
> it all the more fun.  The more I learn, the more I don’t know it just adds
> in more confusion.
>
>
>
> I never realized I was tondeaf until I moved to Hong Kong.
>
>
>
> Sent from Mail for Windows 10
>
>
>
> From: Rudi Blom
> Sent: Friday, 17 February 2017 3:43 PM
> To: tuhs at minnie.tuhs.org
> Subject: Re: [TUHS] Mushi and Bagu
>
>
>
> Tonal languages are real fun. I'm living and working in Bangkok,
>
> Thailand and slightly tone deaf am still struggling.
>
>
>
> Which reminds me, regarding binary there are 10 types of people, those
>
> who understand and those who don't :-)
>
>
>
> Cheers,
>
> rudi
>
>

[TUHS] Mushi and Bagu

[Rudi Blom]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2279 bytes --]

The advantage of Thai is that it's character based so at least I can
see the difference easily and try to replicate. Pronouncing correctly
and hearing correctly is a different kettle of fish all together
though.

On 16/02/2017, Nick Downing <downing.nick at gmail.com> wrote:
> I don't think Westerners are actually tone deaf as such. It's
> basically that we didn't exercise our ability to tell those tones
> apart when we were acquiring language, so we more or less lost the
> opportunity to learn it when we could. Although it can be learnt
> later, something that happens as a very natural process during
> language aquisition, becomes a very artificial process involving
> MONTHS or YEARS in the lab listening to tapes and testing oneself and
> so on. Acquiring tones is somewhat similar to having perfect pitch in
> music. There are courses out there that claim to teach you perfect
> pitch. And, I believe it CAN be learnt, but it is an extraordinary
> amount of work and will probably slide backwards if not maintained.
> Anyway, I still find the phenomenon really strange and intriguing. My
> wife is Vietnamese and I was at her relatives' house just tonight. I
> spoke a little Vietnamese to her aunt and she didn't understand me at
> all (as usual). It's because what sounds to us identical, sounds to
> her like a completely different word -- so much so, that her brain
> doesn't even register any similarity.
> cheers, Nick
> PS OT sorry.
>
> On Thu, Feb 16, 2017 at 8:36 PM,  <jsteve at superglobalmegacorp.com> wrote:
>> Try Cantonese… 9 tones, or 10, or 12.  Nobody agrees on how many which
>> makes
>> it all the more fun.  The more I learn, the more I don’t know it just
>> adds
>> in more confusion.
>>
>>
>>
>> I never realized I was tondeaf until I moved to Hong Kong.
>>
>>
>>
>> Sent from Mail for Windows 10
>>
>>
>>
>> From: Rudi Blom
>> Sent: Friday, 17 February 2017 3:43 PM
>> To: tuhs at minnie.tuhs.org
>> Subject: Re: [TUHS] Mushi and Bagu
>>
>>
>>
>> Tonal languages are real fun. I'm living and working in Bangkok,
>>
>> Thailand and slightly tone deaf am still struggling.
>>
>>
>>
>> Which reminds me, regarding binary there are 10 types of people, those
>>
>> who understand and those who don't :-)
>>
>>
>>
>> Cheers,
>>
>> rudi
>>
>>
>

[TUHS] Mach for i386 / Mt Xinu or other

[jsteve]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1396 bytes --]

While testing a crazy project I wanted to get working I came across this ancient link:

http://altavista.superglobalmegacorp.com/usenet/b182/comp/os/mach/542.txt

--------8<--------8<--------8<--------8<

Newsgroups: comp.os.mach
Subject: Mach for i386 - want to beta?
Message-ID: <1364 at mtxinu.UUCP>
Date: 2 Oct 90 17:12:19 GMT
Reply-To: scherrer at mtxinu.COM (Deborah Scherrer)
Organization: mt Xinu, Berkeley
Lines: 24

Mt Xinu is currently finishing up its release of 2.6 MSD for the i386.
2.6 MSD is a CMU-funded standard distribution of the Mach kernel,
release-engineered with the following:
	2.5 Mach kernel, with NFS & BSD-tahoe enhancements
	Transarc's AFS
	X11R4
	most of the 4.3-tahoe BSD release
	Andrew Tool Kit
	Camelot transaction processing system
	Cornell's ISIS distributed programming environment
	most of the FSF utilities
	a few other nifty things

--------8<--------8<--------8<--------8<

Was any of this stuff ever saved?  I know on the CSRG CD there is some buried source for Mach 2.5 although I haven’t seen anything on where to even start to compile it, how or even how to boot it...  I know Mach is certainly not fast, nor all that ‘small’ but it’d be interesting to see a 4.3BSD on a PC!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170217/aec17263/attachment.html>

[TUHS] Mach for i386 / Mt Xinu or other

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3914 bytes --]

Yes.  In fact, the CMU's Mach/386 code base became the direct start for
OSF/1 both the full (RI) and embedded uK (aka monolithic or mK) versions as
well.  The later would seed DEC Tru64 after being ported to the Alpha, but
the 386 version of the mK would become Apple's Darwin.  The RI (uK) version
is what we used for the Intel Paragon.   Anything called OSF/1 version 4 or
later is based on the RI.  Before that's probably mK, but you should check
the readme to see which base.

The joke, of course, was that microKernel, was not that micro (it was
greater than 1-1.5M and used to run these on 4M 386 systems).   It was cool
and the research version (pure uK) is very slick and has a lot of
interesting ideas.  I think it's interesting to note that we did all of the
core TNC development for the Paragon which was on i860 processor, on
desktop 386 systems with ethernets to simulate the fabric in the
supercomputer.

OSF/1 uK technology worked very well, in fact; it worked so well AT&T's
replacement for SVR4 was announced to be based on Chorus, which was a
European rewrite using a different uKernel technology specifically to
counter OSF/1.

Anyway, if you do a little hunting around the archives, it is quite
available.   Note it will want to boot from either a floppy for a hard
drive, as USB had yet to be created, so bootstrapping on more modern
hardware might be take a little work.   But it should work.   A number of
us that worked with it, are still findable and few lurk on this list.

As a side note, during the OSF/UI wars, I made a plea with the late Roger
Gourd (then VP of Eng at OSF) and some of the folks management team at OSF
to make the OSF/1 generally available for the 386. At time,  Linux was
still in the .9 stages booting & installing from a 20-40 floppy disks, but
still lacked networking and window system. 386BSD/FreeBSD was coming along
but not quite reached its stride.  The AT&T/BSDi case had just been
completed so the UNIX IP question has been settled. I could not convince
them it was of any value and to an extent it would have been competing with
their members (HP, DEC et al).

I've something thought that was a real opportunity lost.

On Fri, Feb 17, 2017 at 6:30 AM, <jsteve at superglobalmegacorp.com> wrote:

> While testing a crazy project I wanted to get working I came across this
> ancient link:
>
>
>
> http://altavista.superglobalmegacorp.com/usenet/b182/comp/os/mach/542.txt
>
>
>
> --------8<--------8<--------8<--------8<
>
>
>
> Newsgroups: comp.os.mach
>
> Subject: Mach for i386 - want to beta?
>
> Message-ID: <1364 at mtxinu.UUCP>
>
> Date: 2 Oct 90 17:12:19 GMT
>
> Reply-To: scherrer at mtxinu.COM (Deborah Scherrer)
>
> Organization: mt Xinu, Berkeley
>
> Lines: 24
>
>
>
> Mt Xinu is currently finishing up its release of 2.6 MSD for the i386.
>
> 2.6 MSD is a CMU-funded standard distribution of the Mach kernel,
>
> release-engineered with the following:
>
>                 2.5 Mach kernel, with NFS & BSD-tahoe enhancements
>
>                 Transarc's AFS
>
>                 X11R4
>
>                 most of the 4.3-tahoe BSD release
>
>                 Andrew Tool Kit
>
>                 Camelot transaction processing system
>
>                 Cornell's ISIS distributed programming environment
>
>                 most of the FSF utilities
>
>                 a few other nifty things
>
>
>
> --------8<--------8<--------8<--------8<
>
>
>
> Was any of this stuff ever saved?  I know on the CSRG CD there is some
> buried source for Mach 2.5 although I haven’t seen anything on where to
> even start to compile it, how or even how to boot it...  I know Mach is
> certainly not fast, nor all that ‘small’ but it’d be interesting to see a
> 4.3BSD on a PC!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170217/d5ae52fe/attachment-0001.html>

[TUHS] Mach for i386 / Mt Xinu or other

[Chet Ramey]

On 2/17/17 9:22 AM, Clem Cole wrote:

> the 386 version of the mK would become Apple's Darwin.  

Filtered through NeXT.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet at case.edu    http://cnswww.cns.cwru.edu/~chet/

[TUHS] Mach for i386 / Mt Xinu or other

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 758 bytes --]

On Fri, Feb 17, 2017 at 6:30 AM, <jsteve at superglobalmegacorp.com> wrote:

> ​i​
> t’d be interesting to see a 4.3BSD on a PC!


​It should have added - that's easy today.  Just buy an Apple Mac or create
an HackenTosh, then ignore the Apple UI, just run from the terminal.
Darwin is Mach 2.5, with BSD under the covers.     Although to be fair,
over the years, that have more and more diverted from a lot of core UNIX in
many things in the back, but frankly, I do find it more UNIX-like than not
and  40+ years of "muscle memory" in my fingers mostly get the right
results.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170217/1f1bfe9a/attachment.html>

[TUHS] Mach for i386 / Mt Xinu or other

[Warner Losh]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1054 bytes --]

On Fri, Feb 17, 2017 at 7:29 AM, Clem Cole <clemc at ccc.com> wrote:
>
> On Fri, Feb 17, 2017 at 6:30 AM, <jsteve at superglobalmegacorp.com> wrote:
>>
>> i
>> t’d be interesting to see a 4.3BSD on a PC!
>
>
> It should have added - that's easy today.  Just buy an Apple Mac or create
> an HackenTosh, then ignore the Apple UI, just run from the terminal.  Darwin
> is Mach 2.5, with BSD under the covers.     Although to be fair, over the
> years, that have more and more diverted from a lot of core UNIX in many
> things in the back, but frankly, I do find it more UNIX-like than not and
> 40+ years of "muscle memory" in my fingers mostly get the right results.

You could install FreeBSD 1 and have no UI to ignore. Most of BSD 4.3
compiles under it (though with some hacking iirc) and the difference
in user experience between the 4.3 and 4.4 kernels isn't huge. Going
the other way is harder (running 4.4 in 4.3) since the 4.4 userland
uses a lot of kernel features new in 4.4. It was based on the net2
tape with missing bits filled in.

Warner

[TUHS] Mach for i386 / Mt Xinu or other

[Nemo]

On 17 February 2017 at 09:29, Clem Cole <clemc at ccc.com> wrote:
[...]
> It should have added - that's easy today.  Just buy an Apple Mac or create
> an HackenTosh, then ignore the Apple UI, just run from the terminal.  Darwin
> is Mach 2.5, with BSD under the covers.     Although to be fair, over the
> years, that have more and more diverted from a lot of core UNIX in many
> things in the back, but frankly, I do find it more UNIX-like than not and
> 40+ years of "muscle memory" in my fingers mostly get the right results.

Hhhmmm... this was thrashed out last month, starting at
http://minnie.tuhs.org/pipermail/tuhs/2017-January/007608.html

#6-)

>
> Clem
>

[TUHS] Mach for i386 / Mt Xinu or other

[jsteve]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1308 bytes --]

True, but It’s not 4.3 BSD …  I was hoping for something vintage of the era, just as Solaris 11 is SYSV, but it’s nothing like SYSVr2 on the VAX….

And historical is far more interesting than something I can just go buy retail….   Speaking as someone who’s own a NeXT, and even bought OS X Server 1.0 on release.


From: Nemo
Sent: Monday, 20 February 2017 6:41 AM
To: Clem Cole
Cc: tuhs at minnie.tuhs.org
Subject: Re: [TUHS] Mach for i386 / Mt Xinu or other

On 17 February 2017 at 09:29, Clem Cole <clemc at ccc.com> wrote:
[...]
> It should have added - that's easy today.  Just buy an Apple Mac or create
> an HackenTosh, then ignore the Apple UI, just run from the terminal.  Darwin
> is Mach 2.5, with BSD under the covers.     Although to be fair, over the
> years, that have more and more diverted from a lot of core UNIX in many
> things in the back, but frankly, I do find it more UNIX-like than not and
> 40+ years of "muscle memory" in my fingers mostly get the right results.

Hhhmmm... this was thrashed out last month, starting at
http://minnie.tuhs.org/pipermail/tuhs/2017-January/007608.html

#6-)

>
> Clem
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170219/709363ee/attachment.html>

[TUHS] Mach for i386 / Mt Xinu or other

[Steve Nickolas]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 476 bytes --]

On Sun, 19 Feb 2017, jsteve at superglobalmegacorp.com wrote:

> True, but It’s not 4.3 BSD … I was hoping for something vintage of the 
> era, just as Solaris 11 is SYSV, but it’s nothing like SYSVr2 on the 
> VAX….
>
> And historical is far more interesting than something I can just go buy 
> retail….  Speaking as someone who’s own a NeXT, and even bought OS X 
> Server 1.0 on release.

Isn't Jolix essentially Reno, if a 4.3BSD is what you're after?

-uso.

[TUHS] Mach for i386 / Mt Xinu or other

[Jason Stevens]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1204 bytes --]

It's a net/2 something much later.  I'm interested in what would have been an encumbered pre net/2 release of 4.2 or 4.3 for the i386...  I found out that CMU had BSD running on Mach, and I suspect there is straight ports as well.  It's that evelotionary dead end of 386 UNIX from 1986-1991 that interests me as they clearly could have had the market but they obviously blew it.

On February 19, 2017 3:01:04 PM GMT+08:00, Steve Nickolas <usotsuki at buric.co> wrote:
>On Sun, 19 Feb 2017, jsteve at superglobalmegacorp.com wrote:
>
>> True, but It’s not 4.3 BSD … I was hoping for something vintage of
>the 
>> era, just as Solaris 11 is SYSV, but it’s nothing like SYSVr2 on the 
>> VAX….
>>
>> And historical is far more interesting than something I can just go
>buy 
>> retail….  Speaking as someone who’s own a NeXT, and even bought OS X 
>> Server 1.0 on release.
>
>Isn't Jolix essentially Reno, if a 4.3BSD is what you're after?
>
>-uso.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170219/53c9ec93/attachment-0001.html>

[TUHS] Mach for i386 / Mt Xinu or other

[Larry McVoy]

On Sun, Feb 19, 2017 at 09:46:47PM +0800, Jason Stevens wrote:
> It's a net/2 something much later.  I'm interested in what would have
> been an encumbered pre net/2 release of 4.2 or 4.3 for the i386...
> I found out that CMU had BSD running on Mach, and I suspect there is
> straight ports as well.  It's that evelotionary dead end of 386 UNIX
> from 1986-1991 that interests me as they clearly could have had the
> market but they obviously blew it.

So before I start, let me state for the record I'm a died in the wool
BSD guy.  I grew up on BSD at University and then went to Sun and worked
on SunOS 4.x which was a BSD derived OS (many people at the time called it
"Bugfixed BSD" though it was more than that).

In my opinion, 386 BSD and friends lost because they didn't have a Linus.
They needed a strong leader that would provide direction to rally around.
Jolitz, as much as I like him, was not that leader.  Nor was Jordan or
Theo or Chris.  And BSDi, don't get me started.

A friend of mine once said "They couldn't decide who was going to drive
the big red fire truck, so instead they each got to sit on and drive
their own personal toy fire truck".  The mental image always fit for
me.

It's a big part of why I threw my support behind Linux.  A lot of the
BSD crowd considered me a "traitor" for doing so at the time.  Shrug.

Linus had the qualities of being a good programmer, a good architect,
and a good manager.  I've never seen all 3 in a person before or since.

[TUHS] Mach for i386 / Mt Xinu or other

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 961 bytes --]

Larry McVoy <lm at mcvoy.com> wrote:

> Linus had the qualities of being a good programmer, a good architect,
> and a good manager.  I've never seen all 3 in a person before or since.

My memory is different. He claims that his intention is to keep 
kernel/userspace interfaces stable, but given the fact that this did never 
happen, I tend to believe that he lacks the understanding on what all is part 
of the kernel/userspace interface.

He also send me a 10 line patch for cdrtools in 2004 and I did never get a 
worse patch (a patch that includes more new bugs) for my software.

So I cannot confirm your view.

He is a person with a strong ego and this may have helped to spread Linux.

Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

[TUHS] Mach for i386 / Mt Xinu or other

[Larry McVoy]

Oh brother.

On Mon, Feb 20, 2017 at 07:14:44PM +0100, Joerg Schilling wrote:
> Larry McVoy <lm at mcvoy.com> wrote:
> 
> > Linus had the qualities of being a good programmer, a good architect,
> > and a good manager.  I've never seen all 3 in a person before or since.
> 
> My memory is different. He claims that his intention is to keep 
> kernel/userspace interfaces stable, but given the fact that this did never 
> happen, I tend to believe that he lacks the understanding on what all is part 
> of the kernel/userspace interface.

So you're taking on the guy who won the Unix wars, has stayed in charge for
a couple of decades, created the OS that runs on 498 of 500 super computers,
the OS that runs on more phones than apple's phones, tablets, and computers
combined?

I've worked with Linus, I know him pretty well.  I stand by my description
above and nothing you've said has changed (and isn't likely to).

As for interfaces, huh.  I've got two decades of supporting a commercial
product that uses file system, networking, VM interfaces and I can't
remember a time were we had to change something because Linux broke
an API.

[TUHS] Mach for i386 / Mt Xinu or other

[Steve Johnson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2718 bytes --]

I too have worked with Linus, and agree with the good programmer and
good architect.
I think he managed the project well for quite a while, but never quite
recovered from the
GNU incursions.

As far as stability and portability is concerned, GNU is a disaster. 
Even when a feature is
the same across different architectures the option names and values
are often different.
In one company I worked for we had two releases nearly derailed
because of Linux/GCC
issues.  In one case, the way locales worked was different between
different versions of
Linux.  In another case, GCC simply silently removed an option that
we depended on and we
nearly shipped a product that would have bombed out if the user had
already upgraded
to the newest GCC.

In terms of following the Unix philosophy, the widow managers on Linux
are getting more
bizarre by the year.  Hitting a key at random by mistake can cause
windows to disappear,
screens of unknown utility to appear, everything to disappear, etc. 
Setting options to try to 
achieve some kind of consistency is totally different in each
system.  Etc. etc.   There seems 
to be no larger organizing principle at work...

----- Original Message -----
From: "Larry McVoy" <lm@mcvoy.com>
To:"Joerg Schilling" <schily at schily.net>
Cc:<tuhs at minnie.tuhs.org>
Sent:Mon, 20 Feb 2017 14:24:57 -0800
Subject:Re: [TUHS] Mach for i386 / Mt Xinu or other

 Oh brother.

 On Mon, Feb 20, 2017 at 07:14:44PM +0100, Joerg Schilling wrote:
 > Larry McVoy <lm at mcvoy.com> wrote:
 > 
 > > Linus had the qualities of being a good programmer, a good
architect,
 > > and a good manager. I've never seen all 3 in a person before or
since.
 > 
 > My memory is different. He claims that his intention is to keep 
 > kernel/userspace interfaces stable, but given the fact that this
did never 
 > happen, I tend to believe that he lacks the understanding on what
all is part 
 > of the kernel/userspace interface.

 So you're taking on the guy who won the Unix wars, has stayed in
charge for
 a couple of decades, created the OS that runs on 498 of 500 super
computers,
 the OS that runs on more phones than apple's phones, tablets, and
computers
 combined?

 I've worked with Linus, I know him pretty well. I stand by my
description
 above and nothing you've said has changed (and isn't likely to).

 As for interfaces, huh. I've got two decades of supporting a
commercial
 product that uses file system, networking, VM interfaces and I can't
 remember a time were we had to change something because Linux broke
 an API.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170220/b910235f/attachment.html>

[TUHS] Mach for i386 / Mt Xinu or other

[Larry McVoy]

I don't see how it is far to lay the userland issues at the feet of 
Linus, he does the kernel.  He's bitched about the same GCC issues
as you are.

And window managers?  What does that have to do with Linus?

On Mon, Feb 20, 2017 at 03:16:14PM -0800, Steve Johnson wrote:
> I too have worked with Linus, and agree with the good programmer and
> good architect.
> I think he managed the project well for quite a while, but never quite
> recovered from the
> GNU incursions.
> 
> As far as stability and portability is concerned, GNU is a disaster.??
> Even when a feature is
> the same across different architectures the option names and values
> are often different.
> In one company I worked for we had two releases nearly derailed
> because of Linux/GCC
> issues.?? In one case, the way locales worked was different between
> different versions of
> Linux.?? In another case, GCC simply silently removed an option that
> we depended on and we
> nearly shipped a product that would have bombed out if the user had
> already upgraded
> to the newest GCC.
> 
> In terms of following the Unix philosophy, the widow managers on Linux
> are getting more
> bizarre by the year.?? Hitting a key at random by mistake can cause
> windows to disappear,
> screens of unknown utility to appear, everything to disappear, etc.??
> Setting options to try to 
> achieve some kind of consistency is totally different in each
> system.?? Etc. etc.???? There seems 
> to be no larger organizing principle at work...
> 
> ----- Original Message -----
> From: "Larry McVoy" <lm at mcvoy.com>
> To:"Joerg Schilling" <schily at schily.net>
> Cc:<tuhs at minnie.tuhs.org>
> Sent:Mon, 20 Feb 2017 14:24:57 -0800
> Subject:Re: [TUHS] Mach for i386 / Mt Xinu or other
> 
>  Oh brother.
> 
>  On Mon, Feb 20, 2017 at 07:14:44PM +0100, Joerg Schilling wrote:
>  > Larry McVoy <lm at mcvoy.com> wrote:
>  > 
>  > > Linus had the qualities of being a good programmer, a good
> architect,
>  > > and a good manager. I've never seen all 3 in a person before or
> since.
>  > 
>  > My memory is different. He claims that his intention is to keep 
>  > kernel/userspace interfaces stable, but given the fact that this
> did never 
>  > happen, I tend to believe that he lacks the understanding on what
> all is part 
>  > of the kernel/userspace interface.
> 
>  So you're taking on the guy who won the Unix wars, has stayed in
> charge for
>  a couple of decades, created the OS that runs on 498 of 500 super
> computers,
>  the OS that runs on more phones than apple's phones, tablets, and
> computers
>  combined?
> 
>  I've worked with Linus, I know him pretty well. I stand by my
> description
>  above and nothing you've said has changed (and isn't likely to).
> 
>  As for interfaces, huh. I've got two decades of supporting a
> commercial
>  product that uses file system, networking, VM interfaces and I can't
>  remember a time were we had to change something because Linux broke
>  an API.
> 

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

[TUHS] Mach for i386 / Mt Xinu or other

[Steve Johnson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3928 bytes --]

I was responding to the comment about the stability of Linux for
product delivery.

Having a car with a transmission that works perfectly is of little
benefit if the engine and tires keep blowing up.

Linus does take responsibility for the kernel, and that is good.  But
nobody seems to take responsibility
for the other stuff, and that causes a ton of problems.

Steve

----- Original Message -----
From: "Larry McVoy" <lm@mcvoy.com>
To:"Steve Johnson" <scj at yaccman.com>
Cc:"Larry McVoy" <lm at mcvoy.com>, "Joerg Schilling"
<schily at schily.net>, <tuhs at minnie.tuhs.org>
Sent:Mon, 20 Feb 2017 15:18:42 -0800
Subject:Re: [TUHS] Mach for i386 / Mt Xinu or other

 I don't see how it is far to lay the userland issues at the feet of 
 Linus, he does the kernel. He's bitched about the same GCC issues
 as you are.

 And window managers? What does that have to do with Linus?

 On Mon, Feb 20, 2017 at 03:16:14PM -0800, Steve Johnson wrote:
 > I too have worked with Linus, and agree with the good programmer
and
 > good architect.
 > I think he managed the project well for quite a while, but never
quite
 > recovered from the
 > GNU incursions.
 > 
 > As far as stability and portability is concerned, GNU is a
disaster.??
 > Even when a feature is
 > the same across different architectures the option names and values
 > are often different.
 > In one company I worked for we had two releases nearly derailed
 > because of Linux/GCC
 > issues.?? In one case, the way locales worked was different between
 > different versions of
 > Linux.?? In another case, GCC simply silently removed an option
that
 > we depended on and we
 > nearly shipped a product that would have bombed out if the user had
 > already upgraded
 > to the newest GCC.
 > 
 > In terms of following the Unix philosophy, the widow managers on
Linux
 > are getting more
 > bizarre by the year.?? Hitting a key at random by mistake can cause
 > windows to disappear,
 > screens of unknown utility to appear, everything to disappear,
etc.??
 > Setting options to try to 
 > achieve some kind of consistency is totally different in each
 > system.?? Etc. etc.???? There seems 
 > to be no larger organizing principle at work...
 > 
 > ----- Original Message -----
 > From: "Larry McVoy" <lm at mcvoy.com>
 > To:"Joerg Schilling" <schily at schily.net>
 > Cc:<tuhs at minnie.tuhs.org>
 > Sent:Mon, 20 Feb 2017 14:24:57 -0800
 > Subject:Re: [TUHS] Mach for i386 / Mt Xinu or other
 > 
 > Oh brother.
 > 
 > On Mon, Feb 20, 2017 at 07:14:44PM +0100, Joerg Schilling wrote:
 > > Larry McVoy <lm at mcvoy.com> wrote:
 > > 
 > > > Linus had the qualities of being a good programmer, a good
 > architect,
 > > > and a good manager. I've never seen all 3 in a person before or
 > since.
 > > 
 > > My memory is different. He claims that his intention is to keep 
 > > kernel/userspace interfaces stable, but given the fact that this
 > did never 
 > > happen, I tend to believe that he lacks the understanding on what
 > all is part 
 > > of the kernel/userspace interface.
 > 
 > So you're taking on the guy who won the Unix wars, has stayed in
 > charge for
 > a couple of decades, created the OS that runs on 498 of 500 super
 > computers,
 > the OS that runs on more phones than apple's phones, tablets, and
 > computers
 > combined?
 > 
 > I've worked with Linus, I know him pretty well. I stand by my
 > description
 > above and nothing you've said has changed (and isn't likely to).
 > 
 > As for interfaces, huh. I've got two decades of supporting a
 > commercial
 > product that uses file system, networking, VM interfaces and I
can't
 > remember a time were we had to change something because Linux broke
 > an API.
 > 

 -- 
 ---
 Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170220/849b673f/attachment.html>

[TUHS] Mach for i386 / Mt Xinu or other

[Steve Nickolas]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1266 bytes --]

On Mon, 20 Feb 2017, Steve Johnson wrote:

> As far as stability and portability is concerned, GNU is a disaster.  
> Even when a feature is the same across different architectures the 
> option names and values are often different. In one company I worked for 
> we had two releases nearly derailed because of Linux/GCC issues.  In one 
> case, the way locales worked was different between different versions of 
> Linux.  In another case, GCC simply silently removed an option that we 
> depended on and we nearly shipped a product that would have bombed out 
> if the user had already upgraded to the newest GCC.

I'm no fan of GNU either, and have long considered doing a GNU-less, 
SysV-flavored Linux distribution as a reaction to all things that annoy me 
about GNU.

> In terms of following the Unix philosophy, the widow managers on Linux 
> are getting more bizarre by the year.  Hitting a key at random by 
> mistake can cause windows to disappear, screens of unknown utility to 
> appear, everything to disappear, etc.  Setting options to try to achieve 
> some kind of consistency is totally different in each system.  Etc. 
> etc.   There seems to be no larger organizing principle at work...

Which is probably truer than you realize.

-uso.

[TUHS] Mach for i386 / Mt Xinu or other

[Wesley Parish]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1645 bytes --]

I think we can lay a lot of the blame for that major annoyance on the two related facts:
a: there is no universal windowing system everybody adheres to, just two major commercial ones with 
spin-offs for smartphones and the like;
b: a lot of Linux developers are chasing MS Windows in hope of desktop market share and copy MS 
Windows features and misfeatures.

A major irony is that MS Windows itself has chased Linux somewhat on the graphical user interface 
front - Linux was the platform of GUI redesign for OLPC and Android, Microsoft took the bait and tried 
it as a desktop in MS Win 8.0 and got slammed for it.

Setting out standards for a herd of cats is not much of an option; the best one could do is publish RFCs 
giving a list of features that have been proven to work in practice and hope for the best.

Wesley Parish

Quoting Steve Nickolas <usotsuki at buric.co>:

> On Mon, 20 Feb 2017, Steve Johnson wrote:
> 
<snip>
> 
> > In terms of following the Unix philosophy, the widow managers on Linux
> 
> > are getting more bizarre by the year.  Hitting a key at random by 
> > mistake can cause windows to disappear, screens of unknown utility to
> 
> > appear, everything to disappear, etc.  Setting options to try to
> achieve 
> > some kind of consistency is totally different in each system.  Etc. 
> > etc.   There seems to be no larger organizing principle at work...
> 
> Which is probably truer than you realize.
> 
> -uso.
>  



"I have supposed that he who buys a Method means to learn it." - Ferdinand Sor,
Method for Guitar

"A verbal contract isn't worth the paper it's written on." -- Samuel Goldwyn

[TUHS] Mach for i386 / Mt Xinu or other

[Steve Nickolas]

On Tue, 21 Feb 2017, Wesley Parish wrote:

> I think we can lay a lot of the blame for that major annoyance on the 
> two related facts:
> a: there is no universal windowing system everybody adheres to, just two 
> major commercial ones with spin-offs for smartphones and the like;
> b: a lot of Linux developers are chasing MS Windows in hope of desktop 
> market share and copy MS Windows features and misfeatures.

I don't disagree.  But I think there is a universal system, although it 
has been left to crumble to dust over the years, and having been picked up 
it still needs a lot of work to be usable in the 21st century.  That would 
be CDE - I'm not aware of any other X Window environment that made it into 
any versions of the Unix standard (iirc it's part of "Unix 93 
Workstation"?)

> A major irony is that MS Windows itself has chased Linux somewhat on the 
> graphical user interface front - Linux was the platform of GUI redesign 
> for OLPC and Android, Microsoft took the bait and tried it as a desktop 
> in MS Win 8.0 and got slammed for it.

A tablet environment doesn't work very well on a desktop, although a 
desktop environment can work reasonably well on a tablet (been there done 
that; I have a Windows 10 tablet).

> Setting out standards for a herd of cats is not much of an option; the 
> best one could do is publish RFCs giving a list of features that have 
> been proven to work in practice and hope for the best.
>
> Wesley Parish

Herd of cats sums it up nicely.

At least CUA makes a reasonable baseline, and most open-source GUI 
environments and programs seem to support that, as have Windows and OS/2 
since almost the beginning.

-uso.

[TUHS] Mach for i386 / Mt Xinu or other

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2088 bytes --]

Larry McVoy <lm at mcvoy.com> wrote:

> I've worked with Linus, I know him pretty well.  I stand by my description
> above and nothing you've said has changed (and isn't likely to).

I know him as well, he send various personal attacks against me....when I tried 
to discuss Linux kernel bugs on LKML or made proposals on how problems could 
be fixed - e.g. the Linux kernel include files that are needed for various user 
space programs but these include files did not compile with user space 
programs. 

He told me that what I proposed was nonsense, but 5 years later, they 
implemented my proposal.

As Linux personally and incorrectly claimed that I was talking about kernel 
internal interfaces even though I was definitely talking about 
kernel/userspace interfaces, I assume that he has a problem with understanding
what an external interface is. 

> As for interfaces, huh.  I've got two decades of supporting a commercial
> product that uses file system, networking, VM interfaces and I can't
> remember a time were we had to change something because Linux broke
> an API.

You may have had luck.

You also may have used only those interfaces that are not Linux specific but 
rather UNIX interfaces that cannot be changed without protest from thousands of 
people. Let me assume that you are talking about BitKeeper SCCS, then it is 
obvious that you do not need to use Linux specific interfaces in your software.

You may have started with Linux later than I did - I started in 1996.

My software implements support for many Linux specific interfaces (*) and I 
have been a victim of incompatible interface changes many times.

Fortunately, I have no longer been hit since 5 years.


*) star e.g. implements support for Linux specific file meta data and 
   cdrtools e.g need to implement pass through SCSI.

Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

[TUHS] Mach for i386 / Mt Xinu or other

[Random832]

On Tue, Feb 21, 2017, at 05:30, Joerg Schilling wrote:
> *) star e.g. implements support for Linux specific file meta data 

Which interfaces for accessing these have been broken by which versions
of Linux?

> and cdrtools e.g need to implement pass through SCSI.

Requiring "pass through SCSI" for a CD burner violates the UNIX
philosophy that everything is a file (which implies that reading and
writing data be implemented, where possible, through the read and write
system calls rather than through special interfaces specific to a device
type).

So does requiring SCSI bus numbers rather than device filenames.

[TUHS] Mach for i386 / Mt Xinu or other

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1330 bytes --]

Random832 <random832 at fastmail.com> wrote:

> On Tue, Feb 21, 2017, at 05:30, Joerg Schilling wrote:
> > *) star e.g. implements support for Linux specific file meta data 
>
> Which interfaces for accessing these have been broken by which versions
> of Linux?


The filesystem specific kernel include files are broken on many linux 
distributions.

> > and cdrtools e.g need to implement pass through SCSI.
>
> Requiring "pass through SCSI" for a CD burner violates the UNIX
> philosophy that everything is a file (which implies that reading and
> writing data be implemented, where possible, through the read and write
> system calls rather than through special interfaces specific to a device
> type).

You are incorrectly informed:

Writing CDs is a highly complex task. No known kernel is able to do that 
internally.

So the only useful method is to use SCSI pass through. 


> So does requiring SCSI bus numbers rather than device filenames.

SCSI bus numbers are part of the SCSI CAM Standard for SCSI addressing, you
are badly informed a second time.

Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

[TUHS] Mach for i386 / Mt Xinu or other

[Diomidis Spinellis]

On 21/02/2017 17:18, Joerg Schilling wrote:
>> Requiring "pass through SCSI" for a CD burner violates the UNIX
>> philosophy that everything is a file (which implies that reading and
>> writing data be implemented, where possible, through the read and write
>> system calls rather than through special interfaces specific to a device
>> type).
>
> You are incorrectly informed:
>
> Writing CDs is a highly complex task. No known kernel is able to do that
> internally.
>
> So the only useful method is to use SCSI pass through.

This is an interesting point.  However, controlling the C/A/T 
phototypesetter 20 years before writable CD-ROM appeared, was also a 
very complex task, yet it was accomplished through a simple device file. 
  Controlling a voice modem is also complex, time-critical, and requires 
bidirectional communication. Again, voice modems were controlled through 
a character device file.

One can envisage a CD-ROM device driver abstracting the commands 
required for writing CD-ROMs into a text-based interface made available 
though a character device.  These precedents demonstrate that the SCSI 
pass through was an unneeded architecture-violating shortcut.

Arguably, the same can also be claimed for the networking system calls.

Diomidis

[TUHS] Mach for i386 / Mt Xinu or other

[Cory Smelosky]

Diomidis Spinellis wrote:
> On 21/02/2017 17:18, Joerg Schilling wrote:
>>> Requiring "pass through SCSI" for a CD burner violates the UNIX
>>> philosophy that everything is a file (which implies that reading and
>>> writing data be implemented, where possible, through the read and write
>>> system calls rather than through special interfaces specific to a device
>>> type).
>>
>> You are incorrectly informed:
>>
>> Writing CDs is a highly complex task. No known kernel is able to do that
>> internally.
>>
>> So the only useful method is to use SCSI pass through.
>
> This is an interesting point. However, controlling the C/A/T
> phototypesetter 20 years before writable CD-ROM appeared, was also a
> very complex task, yet it was accomplished through a simple device file.
> Controlling a voice modem is also complex, time-critical, and requires
> bidirectional communication. Again, voice modems were controlled through
> a character device file.

How would you handle the different writing methods? Separate device 
files or an ioctl on a generic device node?

(not arguing - genuinely curious about your theory)

>
> One can envisage a CD-ROM device driver abstracting the commands
> required for writing CD-ROMs into a text-based interface made available
> though a character device. These precedents demonstrate that the SCSI
> pass through was an unneeded architecture-violating shortcut.
>
> Arguably, the same can also be claimed for the networking system calls.
>
> Diomidis
>

[TUHS] Mach for i386 / Mt Xinu or other

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1923 bytes --]

Diomidis Spinellis <dds at aueb.gr> wrote:

> > Writing CDs is a highly complex task. No known kernel is able to do that
> > internally.
> >
> > So the only useful method is to use SCSI pass through.
>
> This is an interesting point.  However, controlling the C/A/T 
> phototypesetter 20 years before writable CD-ROM appeared, was also a 
> very complex task, yet it was accomplished through a simple device file. 

Well, it used a serial or parallel connection on top of a standard driver.
I cannot speak for a real C/A/T device, but I know the Berthold 
phototypesetters that use a serial line with a nearly identical interface
and C/A/T probably was a clone of a Berthold phototypesetter.

In the C/A/T case, troff has the knowledge about how to talk to the 
phototypesetter and uses a "pass through" UNIX driver to transfer the data.

For the CD writers, please keep in mind that during the time when everybody 
used them, there was a constant development on the SCSI command interface for 
the devices and many of the drives had massive firmware bugs. 

cdrecord does always include support for all recent drives and implements 
workarounds for the firmware bugs. Do not expect that people in the UNIX kernel 
area would ever react in time and do not expect that potential abstraction 
layers from the CD drives would be compatible amongst different UNIX versions.

Have a look at a similar problem from 1969:

	There was only one IMP and a set of IMP<->computer adaptors for every
	possible "computer" system.

The IMP<->computer adaptor is similar to the lowest layer of my libscg.

Above that layer in libscg, everything is portable and unified.

Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

[TUHS] Mach for i386 / Mt Xinu or other

[Random832]

On Tue, Feb 21, 2017, at 10:18, Joerg Schilling wrote:
> > So does requiring SCSI bus numbers rather than device filenames.
> 
> SCSI bus numbers are part of the SCSI CAM Standard for SCSI addressing,
> you
> are badly informed a second time.

Why does that make them more useful for end users than device filenames,
especially for non-SCSI devices? USB or ATA bus numbers - or USB device
identifiers - might be more useful than SCSI bus numbers, for end users
who have USB or ATA devices. ATA bus numbers had a deterministic mapping
to /dev/hd* device filenames, once upon a time.

Why does that mean the correct solution is "require the user to type in
the bus number on a program's command line" rather than "configure a
particular bus number to have a particular filename"?

[TUHS] Mach for i386 / Mt Xinu or other

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1665 bytes --]

Random832 <random832 at fastmail.com> wrote:

> Why does that make them more useful for end users than device filenames,
> especially for non-SCSI devices? USB or ATA bus numbers - or USB device
> identifiers - might be more useful than SCSI bus numbers, for end users
> who have USB or ATA devices. ATA bus numbers had a deterministic mapping
> to /dev/hd* device filenames, once upon a time.

You know that Linux implements several different competing methods to access 
these drive types?

You know that some of them do not (or not correctly) support DMA?

You know that DVD drives will not work for writing if you do not have DMA?

> Why does that mean the correct solution is "require the user to type in
> the bus number on a program's command line" rather than "configure a
> particular bus number to have a particular filename"?

Why do people always repeat the same questions that have been answered many 
times in the past already?

1)	CAM is a standard, why not use it? full stop

2)	**Most** Operating systems do not support /dev/* based access to SCSI.
	This includes a POSIX certified system like Mac OS X.

3)	**Most** Operating systems do not even support a file descriptor based
	interface to SCSI commands.
	This includes a POSIX certified system like Mac OS X.

4)	CAM is the only interface method that can be mapped to all
	existing operating system specific implementations.

Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

[TUHS] Mach for i386 / Mt Xinu or other

[Dan Cross]

On Feb 21, 2017 11:55 AM, "Joerg Schilling" <schily at schily.net> wrote:

Random832 <random832 at fastmail.com> wrote:

> Why does that make them more useful for end users than device filenames,
> especially for non-SCSI devices? USB or ATA bus numbers - or USB device
> identifiers - might be more useful than SCSI bus numbers, for end users
> who have USB or ATA devices. ATA bus numbers had a deterministic mapping
> to /dev/hd* device filenames, once upon a time.

You know that Linux implements several different competing methods to access
these drive types?

You know that some of them do not (or not correctly) support DMA?

You know that DVD drives will not work for writing if you do not have DMA?


All of which *could* be supported in a kernel driver.

> Why does that mean the correct solution is "require the user to type in
> the bus number on a program's command line" rather than "configure a
> particular bus number to have a particular filename"?

Why do people always repeat the same questions that have been answered many
times in the past already?


I don't think it was a question. It was a philosophical statement.

1)      CAM is a standard, why not use it? full stop

2)      **Most** Operating systems do not support /dev/* based access to
SCSI.
        This includes a POSIX certified system like Mac OS X.

3)      **Most** Operating systems do not even support a file descriptor
based
        interface to SCSI commands.
        This includes a POSIX certified system like Mac OS X.

4)      CAM is the only interface method that can be mapped to all
        existing operating system specific implementations.


In other words, you worked around perceived problems in what most on this
list would consider the traditional file based UNIX method by implementing
in terms of a different standard. That's fine, of course, but is
independent of the philosophical point that it is not in keeping with the
traditional method.

It's perhaps noteworthy that writing to a CD or DVD on Plan 9 is done with
cat (and networking is implemented in terms of opening, reading and writing
named files). So it's certainly *possible* to use a filesystem method to
write physical media, even if impractical on the array of real-world
systems you want to support.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170221/304ba76c/attachment.html>

[TUHS] Mach for i386 / Mt Xinu or other

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1407 bytes --]

Dan Cross <crossd at gmail.com> wrote:

> In other words, you worked around perceived problems in what most on this

No, I designed an interface that works on top of all known operating systems.

The term "perceived" does not apply.

> It's perhaps noteworthy that writing to a CD or DVD on Plan 9 is done with
> cat (and networking is implemented in terms of opening, reading and writing
> named files). So it's certainly *possible* to use a filesystem method to
> write physical media, even if impractical on the array of real-world
> systems you want to support.

So you believe you can create a dual layer video DVD with a layer break 
that matches the meta data in the IFO file with that driver concept?

So you believe you can write an audio CD with CD-Text that matches the indices 
on an existing CD with that driver concept?

So you believe you can read an audio CD in a way that allows you make a 
definite statement on whether all bits have been read correctly or whether 
there have been interpolated parts inside?

People who only have a hammer tend to believe that all problems are nails.

This is what you get on Plan 9...

Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

[TUHS] Mach for i386 / Mt Xinu or other

[Dan Cross]

On Tue, Feb 21, 2017 at 2:44 PM, Joerg Schilling <schily at schily.net> wrote:

> [snip]

People who only have a hammer tend to believe that all problems are nails.
>
> This is what you get on Plan 9...


I think you entirely missed the point of this discussion. I've noticed this
follows something of a pattern. *shrug*

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170221/dd74917b/attachment.html>

[TUHS] Mach for i386 / Mt Xinu or other

[Larry McVoy]

On Tue, Feb 21, 2017 at 11:30:34AM +0100, Joerg Schilling wrote:
> Larry McVoy <lm at mcvoy.com> wrote:
> 
> > I've worked with Linus, I know him pretty well.  I stand by my description
> > above and nothing you've said has changed (and isn't likely to).
> 
> I know him as well, he send various personal attacks against me.

Linus attacks anyone who he thinks is misguided.  He's been wrong but
he's usually right.

> As Linux personally and incorrectly claimed that I was talking about kernel 
> internal interfaces even though I was definitely talking about 
> kernel/userspace interfaces, I assume that he has a problem with understanding
> what an external interface is. 

Yeah, uh huh.  If it makes you feel better to say stuff like that, go
for it.  You do realize it doesn't reflect well on you, right?  The
guy is a pretty darn good kernel engineer, I think he knows what a 
kernel/userspace interface is.  It's a big part of the job description.

> You may have started with Linux later than I did - I started in 1996.

Was running Linux well before that, I ran it when you booted off of
floppies and there was no networking.  I don't know when I started but
this was in 1993:

http://www.mcvoy.com/lm/bitmover/lm/papers/srcos.html

and I'm sure I'd been running it for quite a while by that time.  

[TUHS] Mach for i386 / Mt Xinu or other

[jsteve]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5209 bytes --]

Wow that captures so much there.  I think the big thing at the time was the tools, and even the precious kernel source code.

I got into Linux around 0.12-0.95.  To me it was so amazing to get the kernel source code, and actually compile it myself.  Prior that that, I’d only been a user on VAX Ultrix, and helped out some mom & pop resellers that got in over their heads with Xenix.  BSD Unix was something that ran on massively expensive hardware, and was guarded like a state secret, so I never bothered to look it up as I didn’t get the exciting computerlab job, and by the time I had one we ran AIX, and were 100% against doing anything else, especially talks of using GCC/F2c instead of IBM’s XLC/Fortran.  We also had another lab with AT&T 3B2’s that one college kid had apparently ‘stolen’ source code to the kernel had relinked the kernels with his ‘improved’ modules .. and which is what they always blamed for stability issues (certainly not having 30 users on a machine that could barely keep up with 5).

There was such a high bar to get a UNIX system to mess around with, and it was such a castle vs peasant thing that it really reminded me of the whole microcomputer revolution.  Had I known that 386BSD was a thing I would have been interested.  But it was digging around on a BBS where I found SLS Linux diskette images that I could install on a 386sx that was just as useful as Xenix.  But with GCC I could actually port over my own stupid stuff.  The SDK didn’t cost more than a car and it was amazing.  Even better you not only could download the kernel, but were encouraged to do so, as the generic kernel sucked.

So reading comments up to here, it seems that being baggage free in terms of not working with ‘existing good’ code gave them a chance to challenge every known idea of what things should be, and then like extfs trying things, failing, and improving like ext2fs, ext3fs and ext4fs …  My personal catastrophic issues with Linux has always been the ‘hookers and blackjack’ approach, where someone doesn’t like LIBC then they’ll just replace it, over and over and over.  Then you get binary commercial products (Oracle) which are a nightmare to deal with, and now you end up with containers as a way to deal with the horrible impossibility of deploying binaries to Linux.  I’m still hopeful someone will just “borrow” what NeXT did with packages, and fat binaries.

I guess the other takeaway is that with Linus only focusing on a kernel is that everyone could make their own, while forking or making your own BSD as a user was (and Im sure is still) looked highly down on.  Just as we went through the whole NetBSD ouster of Theo and OpenBSD thing, and of course Matt’s Dragonfly.

I used to think it was more so right place at the right time, but really that blank slate seems to have been a big thing too, just as there has been some ancient bugs in BSD like the 33 year yacc bug (http://undeadly.org/cgi?action=article&sid=20080708155228) and a 25 year BSD bug (http://www.osnews.com/story/19731/The-25-Year-Old-UNIX-Bug).  

Linux would have never existed without the 386 Minix branch, which of course relied on there being a UNIX to copy and ‘improve’ with it’s microkernel in the first place, but now we seem to be really in that post UNIX world.

By modern standards SYSVr4 is embedded sized.  Although last time I asked Attachmate about it they didn’t know what a UNIX was.  I suspect it’s about the same with Microfocus.

From: Larry McVoy
Sent: Thursday, 23 February 2017 5:53 AM
To: Joerg Schilling
Cc: lm at mcvoy.com; tuhs at minnie.tuhs.org; jsteve at superglobalmegacorp.com
Subject: Re: [TUHS] Mach for i386 / Mt Xinu or other

On Tue, Feb 21, 2017 at 11:30:34AM +0100, Joerg Schilling wrote:
> Larry McVoy <lm at mcvoy.com> wrote:
> 
> > I've worked with Linus, I know him pretty well.  I stand by my description
> > above and nothing you've said has changed (and isn't likely to).
> 
> I know him as well, he send various personal attacks against me.

Linus attacks anyone who he thinks is misguided.  He's been wrong but
he's usually right.

> As Linux personally and incorrectly claimed that I was talking about kernel 
> internal interfaces even though I was definitely talking about 
> kernel/userspace interfaces, I assume that he has a problem with understanding
> what an external interface is. 

Yeah, uh huh.  If it makes you feel better to say stuff like that, go
for it.  You do realize it doesn't reflect well on you, right?  The
guy is a pretty darn good kernel engineer, I think he knows what a 
kernel/userspace interface is.  It's a big part of the job description.

> You may have started with Linux later than I did - I started in 1996.

Was running Linux well before that, I ran it when you booted off of
floppies and there was no networking.  I don't know when I started but
this was in 1993:

http://www.mcvoy.com/lm/bitmover/lm/papers/srcos.html

and I'm sure I'd been running it for quite a while by that time.  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170222/0a781c09/attachment-0001.html>

[TUHS] Mach for i386 / Mt Xinu or other

[Michael Kjörling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1042 bytes --]

On 22 Feb 2017 16:57 +0800, from jsteve at superglobalmegacorp.com:
> My personal catastrophic issues with Linux has always been
> the ‘hookers and blackjack’ approach, where someone doesn’t like
> LIBC then they’ll just replace it, over and over and over. Then you
> get binary commercial products (Oracle) which are a nightmare to
> deal with, and now you end up with containers as a way to deal with
> the horrible impossibility of deploying binaries to Linux. I’m still
> hopeful someone will just “borrow” what NeXT did with packages, and
> fat binaries.

Something like _snaps_, which Ubuntu is apparently pushing in their
most recent releases?

What is a snap? https://snapcraft.io/docs/snaps/intro

Can a vanilla Ubuntu 16.04 LTS Server run without snapd?
https://askubuntu.com/q/878431/11751

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

[TUHS] Mach for i386 / Mt Xinu or other

[jsteve]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1847 bytes --]

Packages go one further by including a single multi architecture binary.  Of course the only thing more fun than compiling something is to say compile it four times.  “-arch i386 -arch sparc -arch hppa -arch m68k” but now you had a binary that could run on all the NeXT platforms, instead of having 4 separate files.... 

Although I think today it’s largely x86_64 & ARM.  But I’m sure there is some holdouts with MIPS/PowerPC/S390/Sparc/Sparc64 etc.

Sent from Mail for Windows 10

From: Michael Kjörling
Sent: Thursday, 23 February 2017 6:12 PM
To: tuhs at minnie.tuhs.org
Subject: Re: [TUHS] Mach for i386 / Mt Xinu or other

On 22 Feb 2017 16:57 +0800, from jsteve at superglobalmegacorp.com:
> My personal catastrophic issues with Linux has always been
> the ‘hookers and blackjack’ approach, where someone doesn’t like
> LIBC then they’ll just replace it, over and over and over. Then you
> get binary commercial products (Oracle) which are a nightmare to
> deal with, and now you end up with containers as a way to deal with
> the horrible impossibility of deploying binaries to Linux. I’m still
> hopeful someone will just “borrow” what NeXT did with packages, and
> fat binaries.

Something like _snaps_, which Ubuntu is apparently pushing in their
most recent releases?

What is a snap? https://snapcraft.io/docs/snaps/intro

Can a vanilla Ubuntu 16.04 LTS Server run without snapd?
https://askubuntu.com/q/878431/11751

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170222/5a1192a4/attachment.html>

[TUHS] Mach for i386 / Mt Xinu or other

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1336 bytes --]

<jsteve at superglobalmegacorp.com> wrote:

> I used to think it was more so right place at the right time, but really that blank slate seems to have been a big thing too, just as there has been some ancient bugs in BSD like the 33 year yacc bug (http://undeadly.org/cgi?action=article&sid=20080708155228) and a 25 year BSD bug (http://www.osnews.com/story/19731/The-25-Year-Old-UNIX-Bug).  

Well, this is nothing special.

Last year, I fixed several aprox. 35 year old bugs in the Bourne Shell while 
doing automated testing after POSIX support was ready.

One was related to the rewrite that was needed to work around the design bug in 
the MC68000 but the other three were interesting:

-	Fixed a bug introduced in 1981 with SYSTEM III that caused continue 
	large-number to break and not to continue the outer loop.

-	Fixed a bug - present since 1977 - that caused an interactive shell 
	that calls "for i in 1 2 3 ; do echo $i; break 0; done" stop working.

-	Fixed a bug introduced in 1981 with SYSTEM III that caused cat 0<<-EOF 
	not to strip leading TABs.

Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

[TUHS] Mach for i386 / Mt Xinu or other

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3802 bytes --]

On Sun, Feb 19, 2017 at 1:20 AM, <jsteve at superglobalmegacorp.com> wrote:

> True, but It’s not 4.3 BSD …  I was hoping for something vintage of the
> era, just as Solaris 11 is SYSV, but it’s nothing like SYSVr2 on the VAX….
>
​Fair enough... the Mt Xinu version is pretty much the CMU version
unadorned.   Which mean that it is a 4.3BSD kernel, with the BSD based MMU
code ripped out and replaced with the CMU code, and the Mach interfaces
(ney RIG - Mach's and Accent's predecessor) messaging system spliced into
it; then the whole mess was built back up using a 4.3BSD user space (and on
top of the i386, an Intel developed boot system - which is a different
story I'll not repeat at this time - but thankfully was common to all the
UNIX systems of the day because Intel developed and make it available to
community at large).

The other option which I would suggest to look at is the OSF/1 mk for the
i386 (monolithic) about version 3x which as I said forked off the Alpha
line and a couple of other systems.   The i386 version of OSF/1 supports
the same chips (i386/i486/Pentium) at the CMU version, it also comes with
more HW device support (disk, tape, network, display *et al*),  than the
CMU/Mt Xinu version -- including most importantly SCSI support by
default, which is why is might be a little easier to work on today's HW and
VMs.   When I last used it, it lacked USB support; but that was being
worked on around the time I started doing other things so even that might
even be available today.

FWIW: OSF/1 also started with 4.3BSD userspace, but it had a lot of work
done to it to updating it - adding the Sys V commands that BSD lacked those
days and adding Sys V options to many commands.  * i.e.* its user space is
a tad more "complete" / "wider" than pure 4.3BSD and again makes it a
little easier to complete.

Note that the user space commands from the mk would become the basis for
Tru64, HP/UX and later versions of AIX.   And also the OSF/1 version will
have better Graphics, Motif and a much better GUI options all around that
Mt Xinu, which alone may be it easier to work.


As I also said elsewhere, the uK or Research Institute (RI) version is a
tad more fun to play with.   It's a real kernel architecture moving things
like file systems *et al* in user space.  But you can do do things like
start up multiple system interfaces.   LCC had their DOS/Win95 interface
was actually developed running instead of as a VM like it did for the basic
mk code, but in as "second server" but I do not think they ever sold it.
The other thing the RI never did, was the uk still has the pager and all
the networking code in the kernel, so the uk, is hardly 'micro' in size.

There is a OSF Version 4 and maybe even version 5 (I've forgotten, if some
one remembers - please correct me).  The OSF RI folks were trying to
rewrite it a bit in C++ as I recall, again this part of the UI vs OSF wars
of the day and Chorus has rewritten there version from Pascal to C++, and
IIRC the RI was trying to counter that.  I don't remember if that version
of the uk ever saw the light of day.




Anyway, no matter which is the 3 code streams you pick, Mt Xinu, OSF/1 mk
or uk one hardest problems for today will be that the compiler is of course
extremely old by today's standards, and you are probably going to run it
some walls in that area faster than you might think.   That said, if you
are willing to deal with the compiler as it comes, non of them should be
very high, or hard to get clear, but some are likely to take some work.

Have fun and good luck and let us know if you can get any of these running.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170219/0750fd70/attachment.html>

[TUHS] Mach for i386 / Mt Xinu or other

[Nick Downing]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5076 bytes --]

This is all very interesting, and I take it the source is available? I saw here:
http://shiftleft.com/mirrors/ifctfvax.harhan.org/pub/UNIX/thirdparty/Ultrix-32/
The Ultrix sources are available, also SunOS, not sure if these are a
"legally open sourced" copies, but in theory HP (Digital) and Oracle
(Sun) and others would now be allowed to open-source ancient versions
given that Caldera have opened up the code it was based on.

So I wonder if OSF/1 is now in the same boat? I'm not as interested in
comparing ancient VM or messaging architectures, I honestly feel like
the microkernel concept, at least as expressed in Mach, has been
pretty thoroughly debunked, exokernels or tiny hypervisors might be
more the go these days. But when you said "compiler" and "walls" my
ears pricked up. I'm partway through re-engineering the ancient
Ritchie compiler to be able to do a few new tricks, such as
automatically outputting ANSI compileable code. Unfortunately this
would occur after the C preprocessor step, I don't have plans to
back-annotate the original source code. But I have plans to make the
entire system as painless as possible. I already have modified "cc"
and "ld" to do some rather interesting stuff retaining Makefile
compatibility.

cheers, Nick

On Mon, Feb 20, 2017 at 8:19 AM, Clem Cole <clemc at ccc.com> wrote:
>
>
> On Sun, Feb 19, 2017 at 1:20 AM, <jsteve at superglobalmegacorp.com> wrote:
>>
>> True, but It’s not 4.3 BSD …  I was hoping for something vintage of the
>> era, just as Solaris 11 is SYSV, but it’s nothing like SYSVr2 on the VAX….
>
> Fair enough... the Mt Xinu version is pretty much the CMU version unadorned.
> Which mean that it is a 4.3BSD kernel, with the BSD based MMU code ripped
> out and replaced with the CMU code, and the Mach interfaces (ney RIG -
> Mach's and Accent's predecessor) messaging system spliced into it; then the
> whole mess was built back up using a 4.3BSD user space (and on top of the
> i386, an Intel developed boot system - which is a different story I'll not
> repeat at this time - but thankfully was common to all the UNIX systems of
> the day because Intel developed and make it available to community at
> large).
>
> The other option which I would suggest to look at is the OSF/1 mk for the
> i386 (monolithic) about version 3x which as I said forked off the Alpha line
> and a couple of other systems.   The i386 version of OSF/1 supports the same
> chips (i386/i486/Pentium) at the CMU version, it also comes with more HW
> device support (disk, tape, network, display et al),  than the CMU/Mt Xinu
> version -- including most importantly SCSI support by default, which is why
> is might be a little easier to work on today's HW and VMs.   When I last
> used it, it lacked USB support; but that was being worked on around the time
> I started doing other things so even that might even be available today.
>
> FWIW: OSF/1 also started with 4.3BSD userspace, but it had a lot of work
> done to it to updating it - adding the Sys V commands that BSD lacked those
> days and adding Sys V options to many commands.   i.e. its user space is a
> tad more "complete" / "wider" than pure 4.3BSD and again makes it a little
> easier to complete.
>
> Note that the user space commands from the mk would become the basis for
> Tru64, HP/UX and later versions of AIX.   And also the OSF/1 version will
> have better Graphics, Motif and a much better GUI options all around that Mt
> Xinu, which alone may be it easier to work.
>
>
> As I also said elsewhere, the uK or Research Institute (RI) version is a tad
> more fun to play with.   It's a real kernel architecture moving things like
> file systems et al in user space.  But you can do do things like start up
> multiple system interfaces.   LCC had their DOS/Win95 interface was actually
> developed running instead of as a VM like it did for the basic mk code, but
> in as "second server" but I do not think they ever sold it.   The other
> thing the RI never did, was the uk still has the pager and all the
> networking code in the kernel, so the uk, is hardly 'micro' in size.
>
> There is a OSF Version 4 and maybe even version 5 (I've forgotten, if some
> one remembers - please correct me).  The OSF RI folks were trying to rewrite
> it a bit in C++ as I recall, again this part of the UI vs OSF wars of the
> day and Chorus has rewritten there version from Pascal to C++, and IIRC the
> RI was trying to counter that.  I don't remember if that version of the uk
> ever saw the light of day.
>
>
>
>
> Anyway, no matter which is the 3 code streams you pick, Mt Xinu, OSF/1 mk or
> uk one hardest problems for today will be that the compiler is of course
> extremely old by today's standards, and you are probably going to run it
> some walls in that area faster than you might think.   That said, if you are
> willing to deal with the compiler as it comes, non of them should be very
> high, or hard to get clear, but some are likely to take some work.
>
> Have fun and good luck and let us know if you can get any of these running.
>
> Clem

[TUHS] Mach for i386 / Mt Xinu or other

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3753 bytes --]

On Sun, Feb 19, 2017 at 7:29 PM, Nick Downing <downing.nick at gmail.com>
wrote:

> This is all very interesting, and I take it the source is available?


​I have not looked in a while, they have been in the past.​   The RI
version in particular was floating around the open parts of the Internet as
recently as 10-15 years ago, if my memory serves me. I suspect, that the
darker areas have other versions too.   We played with/considered the RI
version at one of my startups but eventually decided against as it was too
big/heavy for what we needed at the time.    Google is your friend, as is
the Internet Way Back machines but I do expect if you poke around you'll
find them.

As for licenses, OSF/1 [from OSF itself] was based off the SVR3 AT&T
license from an AT&T standpoint.   If that is now clear, then it should be
also, but I'm not a lawyer nor play one on TV etc...   I'll leave that to
other more knowledgable about what has been released and what has not.
[As a side note, I do remember that all of Sun, IBM and HP had fully bought
out AT&T licenses meaning they could do whatever they wanted with the IP,
but DEC never took that step.   However, when HP bought Compaq later and
they started to shipping Tru64 et al under the HP licenses].

Anyway, Tru64 is based on OSF/1 but also has a lot of DEC proprietary
things (like TruClusters and anything Alpha specific) that goes beyond the
based OSF license, so you need the HP clearance before any of that can be
made available [same is true for HP/UX of course].   To my knowledge,
DEC/Compaq/HP never released the sources to Tru64 (or HP/UX) to the world
they way Sun did for Solaris, which in the case of Tru64 is sort of shame -
there is some every good stuff in there like the file systems, the lock
managers, cluster scaling, messaging, etc - which would be nice to compare
to today's solutions.   Since HP did have a bought out AT&T license, that
clearly could have done so, but I do not think anyone left there to make
that decision - sigh.

That said, VMS is still kept under lock and key, although HP has licensed
it to "VMS, Inc" in the last year (who is now supplying support for same
for Alpha, IA64 and announced a future INTEL*64 version amazingly).   I
bring this up, because we might be able to find out from those folks whom
that are working with at HP and see if we can get one of the HP execs that
is working with VMS to help to sign off on Tru64.   I don't know.


Which bring me to another though ....question for this fine group.... Sun
had a bought out A&T&T SVR4 license.  This was how they were able to make
Solaris open source because they owned both the Sun parts and had the
rights to release the part they had licenses from AT&T.   Does any one know
what became of the non-Sun version SVR4?   Did the rest of it, ever get
released?

Since it sounds like we are digging up a few of the 386 flavors, I thinking
that Warren needs to add an "x86" directory on the save level as the
current VAX and PDP-11 versions.  Then under that have "Distributions" -
with an SRV4/i386 tape assuming we could find same.

Same of course for SVR3 - which would make the some of the other versions
less murky if it was released, since I'm fairly sure that the SVR3 license
was the one that most commercial UNIX versions shipped under for the
longest amount of time.   If it was released, many of of the versions of
UNIX from the other "dead branches" - say, early Masscomp, Apollo's first
UNIX attempts, Pyramid's Universe stuff, etc would have a little clear path
to being able to me made available.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170219/7da88585/attachment-0001.html>

[TUHS] Mach for i386 / Mt Xinu or other

[Cory Smelosky]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4105 bytes --]







On Sun, Feb 19, 2017, at 13:19, Clem Cole wrote:

> 

> 

> On Sun, Feb 19, 2017 at 1:20 AM,
> <jsteve at superglobalmegacorp.com> wrote:
>> True, but It’s not 4.3 BSD …  I was hoping for something vintage of
>> the era, just as Solaris 11 is SYSV, but it’s nothing like SYSVr2 on
>> the VAX….
> Fair enough... the Mt Xinu version is pretty much the CMU version
> unadorned.   Which mean that it is a 4.3BSD kernel, with the BSD based
> MMU code ripped out and replaced with the CMU code, and the Mach
> interfaces (ney RIG - Mach's and Accent's predecessor) messaging
> system spliced into it; then the whole mess was built back up using a
> 4.3BSD user space (and on top of the i386, an Intel developed boot
> system - which is a different story I'll not repeat at this time - but
> thankfully was common to all the UNIX systems of the day because Intel
> developed and make it available to community at large).
> 

> The other option which I would suggest to look at is the OSF/1 mk for
> the i386 (monolithic) about version 3x which as I said forked off the
> Alpha line and a couple of other systems.   The i386 version of OSF/1
> supports the same chips (i386/i486/Pentium) at the CMU version, it
> also comes with more HW device support (disk, tape, network, display
> *et al*),  than the CMU/Mt Xinu version -- including most importantly
> SCSI support by default, which is why is might be a little easier to
> work on today's HW and VMs.   When I last used it, it lacked USB
> support; but that was being worked on around the time I started doing
> other things so even that might even be available today.
> 

> FWIW: OSF/1 also started with 4.3BSD userspace, but it had a lot of
> work done to it to updating it - adding the Sys V commands that BSD
> lacked those days and adding Sys V options to many commands.  * i.e.*
> its user space is a tad more "complete" / "wider" than pure 4.3BSD and
> again makes it a little easier to complete.
> 

> Note that the user space commands from the mk would become the basis
> for Tru64, HP/UX and later versions of AIX.   And also the OSF/1
> version will have better Graphics, Motif and a much better GUI options
> all around that Mt Xinu, which alone may be it easier to work.
> 

> 

> As I also said elsewhere, the uK or Research Institute (RI) version is
> a tad more fun to play with.   It's a real kernel architecture moving
> things like file systems *et al* in user space.  But you can do do
> things like start up multiple system interfaces.   LCC had their
> DOS/Win95 interface was actually developed running instead of as a VM
> like it did for the basic mk code, but in as "second server" but I do
> not think they ever sold it.   The other thing the RI never did, was
> the uk still has the pager and all the networking code in the kernel,
> so the uk, is hardly 'micro' in size.
> 

> There is a OSF Version 4 and maybe even version 5 (I've forgotten, if
> some one remembers - please correct me).  The OSF RI folks were trying
> to rewrite it a bit in C++ as I recall, again this part of the UI vs
> OSF wars of the day and Chorus has rewritten there version from Pascal
> to C++, and IIRC the RI was trying to counter that.  I don't remember
> if that version of the uk ever saw the light of day.
> 

> 

> 

> 

> Anyway, no matter which is the 3 code streams you pick, Mt Xinu, OSF/1
> mk or uk one hardest problems for today will be that the compiler is
> of course extremely old by today's standards, and you are probably
> going to run it some walls in that area faster than you might think.
> That said, if you are willing to deal with the compiler as it comes,
> non of them should be very high, or hard to get clear, but some are
> likely to take some work.
> 

> Have fun and good luck and let us know if you can get any of these
> running.
> 

> Clem



Has any mtXinu stuff survived to be archives?



--

  Cory Smelosky

  b4 at gewt.net




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170219/412abed1/attachment.html>

[TUHS] Mach for i386 / Mt Xinu or other

[Derek Fawcus]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 402 bytes --]

On Sun, Feb 19, 2017 at 02:20:15p.m. +0800, jsteve at superglobalmegacorp.com wrote:
> 
> And historical is far more interesting than something I can just go buy retail….   Speaking as someone who’s own a NeXT, and even bought OS X Server 1.0 on release.

Didn't Apple release the kernel source code for that under V1 of their public licence?
I seem to recall finding it once on a MIT server.

DF

[TUHS] Mushi and Bagu

[Noel Chiappa]

    > From: Larry McVoy

    > Are you sure? Someone else said moshi was hi and mushi was bug. Does
    > mushi have two meanings?

Yes:

  http://www.nihongodict.com/?s=mushi

Actually, more than two! Japanese is chock-a-block with homonyms. Any
given Japanese word will probably have more than one meaning.

There's some story I don't quite recall about a recent Prime Minister who
made a mistake of this sort - although now that I think about it, it was
probably the _other_ kind of replication, which is that a given set of kanji
(ideograms) usually has more than one pronunciation. (I won't go into why,
see here:

  http://mercury.lcs.mit.edu/~jnc/prints/glossary.html#Reading  

for more.) So he was reading a speech, and gave the wrong reading for a word.
There is apparently a book (or more) in Japanese, for the Japanese, that lists
the common ones that cause confusion.

A very complicated language! The written form is equally complicated; there
are two syllabaries ('hiragana' and 'katakana'), and for the kanji, there are
several completely different written forms!

	Noel

[TUHS] Mushi and Bagu

[Nick Downing]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3297 bytes --]

Yes, I just looked it up too.

http://jisho.org/search/むし
States that mushi means "insect" and "the act of ignoring". (In Japanese
some verbs are nouns and used with the word "suru" meaning "do").

http://jisho.org/search/ばぐ
States that "bagu" means computer bug/error. That's also my recollection as
they use loan words for most of these technical things.

However, Japanese is NOT a complicated language. The spoken language is
very simple. The grammar and sound system are basically like English but
cut down and streamlined. It has a few unique features like "wa" but many
of the particles like "o" and "ga" have direct translations.

Where Japanese is harder to learn is the politeness levels of which there
are basically 4: rude, normal, polite and ultra polite. In ultra polite
there is a different vocabulary so that common actions such as seeing,
going, eating etc have to use a different word, however most ultra polite
language and basically all of the rude and polite language may be derived
systematically from the normal. We do this in English but less rigorously.

The other main thing is the writing system, well Japanese view it as a
beautiful thing and highly cultured but it's not. It's actually the world's
clunkiest writing system, in the 50s the Japanese government seriously
tried to get rid of it and replace with Latin letters like many other
sensible countries have done, and if they'd succeeded then learning
Japanese would be no more difficult than say Tagalog (Filipino) or Bahasa
(Indonesian/Malay). The reason they did not succeed is the many homonyms
resulting from Japanese's very limited sound system (about 50 syllables
compared with hundreds for English and thousands for Chinese or Vietnamese)
which makes Japanese a bit confusing/slow to read when written
phonetically. Note English also uses a similar system to disambiguate
homonyms.

cheers, Nick

On Feb 16, 2017 2:30 AM, "Noel Chiappa" <jnc at mercury.lcs.mit.edu> wrote:

>     > From: Larry McVoy
>
>     > Are you sure? Someone else said moshi was hi and mushi was bug. Does
>     > mushi have two meanings?
>
> Yes:
>
>   http://www.nihongodict.com/?s=mushi
>
> Actually, more than two! Japanese is chock-a-block with homonyms. Any
> given Japanese word will probably have more than one meaning.
>
> There's some story I don't quite recall about a recent Prime Minister who
> made a mistake of this sort - although now that I think about it, it was
> probably the _other_ kind of replication, which is that a given set of
> kanji
> (ideograms) usually has more than one pronunciation. (I won't go into why,
> see here:
>
>   http://mercury.lcs.mit.edu/~jnc/prints/glossary.html#Reading
>
> for more.) So he was reading a speech, and gave the wrong reading for a
> word.
> There is apparently a book (or more) in Japanese, for the Japanese, that
> lists
> the common ones that cause confusion.
>
> A very complicated language! The written form is equally complicated; there
> are two syllabaries ('hiragana' and 'katakana'), and for the kanji, there
> are
> several completely different written forms!
>
>         Noel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170216/49bdf86b/attachment-0001.html>

[TUHS] Mushi and Bagu

[Nemo]

On 15 February 2017 at 11:13, Nick Downing <downing.nick at gmail.com> wrote:
> Yes, I just looked it up too.

I know no Japanese but I could not improve on Noel's and Nick's answers.

My Japanese colleague was born in Japan and obtained his
computer-engineering degrees from  Japanese universities so I would
defer to him.  (He has lived here a few decades but married a Japanese
woman and they send their kid to a special Japanese school for
ex-patriats on the weekend.)

N.

[TUHS] Mushi and Bagu

[Nemo]

Follow-up to Larry's "Mushi! Mushi!" story
(http://minnie.tuhs.org/pipermail/tuhs/2017-February/008149.html).

I showed this to a Japanese acquaintance, who found it hilarious for a
different reason. He told me that a s/w bug is "bagu" -- a
semi-transliteration -- and "mushi" is "I ignore you".  So corporate
called, asked for status, and the technical guy said "I am going to
ignore you!" and then hung up.

N.

[TUHS] Mushi and Bagu

[Larry McVoy]

On Wed, Feb 15, 2017 at 09:51:58AM -0500, Nemo wrote:
> Follow-up to Larry's "Mushi! Mushi!" story
> (http://minnie.tuhs.org/pipermail/tuhs/2017-February/008149.html).
> 
> I showed this to a Japanese acquaintance, who found it hilarious for a
> different reason. He told me that a s/w bug is "bagu" -- a
> semi-transliteration -- and "mushi" is "I ignore you".  So corporate
> called, asked for status, and the technical guy said "I am going to
> ignore you!" and then hung up.

Wow, that's even better than "Bug, bug!".  Are you sure?  Someone else
said moshi was hi and mushi was bug.  Does mushi have two meanings?

[TUHS] Mushi and Bagu

[John Floren]

When I studied Japanese in high school, our teacher told us mushi is bug.
Bagu is a literal transliteration that may be more common in actual use,
but mushi certainly means bug.

On Feb 15, 2017 08:01, "Larry McVoy" <lm at mcvoy.com> wrote:

> On Wed, Feb 15, 2017 at 09:51:58AM -0500, Nemo wrote:
> > Follow-up to Larry's "Mushi! Mushi!" story
> > (http://minnie.tuhs.org/pipermail/tuhs/2017-February/008149.html).
> >
> > I showed this to a Japanese acquaintance, who found it hilarious for a
> > different reason. He told me that a s/w bug is "bagu" -- a
> > semi-transliteration -- and "mushi" is "I ignore you".  So corporate
> > called, asked for status, and the technical guy said "I am going to
> > ignore you!" and then hung up.
>
> Wow, that's even better than "Bug, bug!".  Are you sure?  Someone else
> said moshi was hi and mushi was bug.  Does mushi have two meanings?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170215/5fd4c16e/attachment.html>

[TUHS] Mushi and Bagu

[Steve Nickolas]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 872 bytes --]

On Wed, 15 Feb 2017, Larry McVoy wrote:

> On Wed, Feb 15, 2017 at 09:51:58AM -0500, Nemo wrote:
>> Follow-up to Larry's "Mushi! Mushi!" story
>> (http://minnie.tuhs.org/pipermail/tuhs/2017-February/008149.html).
>>
>> I showed this to a Japanese acquaintance, who found it hilarious for a
>> different reason. He told me that a s/w bug is "bagu" -- a
>> semi-transliteration -- and "mushi" is "I ignore you".  So corporate
>> called, asked for status, and the technical guy said "I am going to
>> ignore you!" and then hung up.
>
> Wow, that's even better than "Bug, bug!".  Are you sure?  Someone else
> said moshi was hi and mushi was bug.  Does mushi have two meanings?
>

If you can believe this the Japanese version of "Pok��mon" occasionally 
puns on the dual meaning of "mushi" - ��ϟoҕ ("mushi wa mushi", more or 
less, "the bugs don't bug me").

-uso.