[TUHS] Mach for i386 / Mt Xinu or other

[TUHS] Mach for i386 / Mt Xinu or other

[Rudi Blom]

>Date: Sun, 19 Feb 2017 20:58:59 -0500
>From: Clem Cole <clemc at ccc.com>
>To: Nick Downing <downing.nick at gmail.com>
>Cc: Jason Stevens <jsteve at superglobalmegacorp.com>,
>        "tuhs at minnie.tuhs.org" <tuhs at minnie.tuhs.org>
>Subject: Re: [TUHS] Mach for i386 / Mt Xinu or other
>Message-ID:      <CAC20D2NM_oyDz0tAM2o5_vJ8Ky_3fHoAmPHn8+DOqNwKoMyqfQ at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
>
>On Sun, Feb 19, 2017 at 7:29 PM, Nick Downing <downing.nick at gmail.com> wrote:

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

As far as I know only the TRU64 Advanced File System (aka AdvFS) has
been released to the OpenSource community, in 2008. Status now unknown
(to me)

See also
. http://advfs.sourceforge.net
. https://www.cyberciti.biz/tips/download-tru64-unix-advanced-filesystem-advfs-sourcecode.html

Cheers,
rudi

[TUHS] Mach for i386 / Mt Xinu or other

[Dave Horsfall]

On Sun, 26 Feb 2017, Norman Wilson wrote:

>   And if my failing memory serves me correctly, [Henry Spencer] wrote 
>   C-News in conjunction with Geoff Collier, as B-News was starting to 
>   show its age and limitations.
> 
> ====
> 
> Your failing memory is correct, except that his name is spelt Collyer, 
> not Collier.

Oops - noted.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Mach for i386 / Mt Xinu or other

[Norman Wilson]

Dave Horsfall:

  And if my failing memory 
  serves me correctly, [Henry Spencer] wrote C-News in conjunction with Geoff Collier, as 
  B-News was starting to show its age and limitations.

====

Your failing memory is correct, except that his name is spelt
Collyer, not Collier.

Norman Wilson
Toronto ON

[TUHS] Mach for i386 / Mt Xinu or other

[Dave Horsfall]

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

On Thu, 23 Feb 2017, Clem Cole wrote:

> > I actually met [Henry Spencer] when he visited Australia, and he's 
> > about the most unassuming guy you will ever meet.
> 
> ​Indeed - ​I've know him for years.  He's an old USENIX type (like me).

Yep; his USENET fame did not go to his head.  And if my failing memory 
serves me correctly, he wrote C-News in conjunction with Geoff Collier, as 
B-News was starting to show its age and limitations.  All of which of 
course got blown away when NNTP arrived...

There was an infamous USENET forgery of him, complete with his style and 
diction, and Henry actually congratulated the forger!

Sigh; those were the days...  Now everything is based upon instant 
gratification by the kiddie brigade (overnight batch jobs on ye olde 
360/50, anyone?).

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[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: 578 bytes --]

On Thu, Feb 23, 2017 at 5:02 PM, Dave Horsfall <dave at horsfall.org> wrote:

> Spencer, not Spenser;
>
​sorry and yes that is correct - dyslexia-r-me -- I'll often not notice the
error. until you point it out.




> I actually met him when he visited Australia, and
> he's about the most unassuming guy you will ever meet.
>

​Indeed - ​I've know him for years.  He's an old USENIX type (like me).

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

[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: 816 bytes --]

And thanks to Henry we have those Usenet tapes!  It's amazing that a decade of Usenet is about 7GB.

On February 24, 2017 12:00:47 AM GMT+08:00, Clem Cole <clemc at ccc.com> wrote:
>
>
>On Thu, Feb 23, 2017 at 10:31 AM, Nemo < cym224 at gmail.com
><mailto:cym224 at gmail.com> > wrote:
>
>
>I was a grad student at Toronto but in math, not C
>
>
>​I hear you and accept that was your experience, but I do find that it
>is interesting, that one of the most  infamous and notorious UNIX
>hackers of all time is Henry Spenser of the UT Zoology Dept - not Math,
>not CS or EE.

-- 
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/20170224/dc525062/attachment.html>

[TUHS] Mach for i386 / Mt Xinu or other

[Dave Horsfall]

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

On Thu, 23 Feb 2017, Clem Cole wrote:

> I hear you and accept that was your experience, but I do find that it is 
> interesting, that one of the most  infamous and notorious UNIX hackers 
> of all time is Henry Spenser of the UT Zoology Dept - not Math, not CS 
> or EE.

Spencer, not Spenser; I actually met him when he visited Australia, and 
he's about the most unassuming guy you will ever meet.

His email address was something like *vax!utzoo!henry.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Mach for i386 / Mt Xinu or other

[Nemo]

On 23 February 2017 at 11:00, Clem Cole <clemc at ccc.com> wrote:
>
> On Thu, Feb 23, 2017 at 10:31 AM, Nemo <cym224 at gmail.com> wrote:
>>
>> I was a grad student at Toronto but in math, not C
>
>
> I hear you and accept that was your experience, but I do find that it is
> interesting, that one of the most  infamous and notorious UNIX hackers of
> all time is Henry Spenser of the UT Zoology Dept - not Math, not CS or EE.

Sure -- this is real irony (and a missed opportunity).  I walked past
Zoo almost daily ignorant of Henry's existence.  (Had I known, I would
have gladly stopped in to talk.) The point is that though we had Sun
kit in the math dep't, we were not part of the UNIX "in crowd".

N.

[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: 516 bytes --]

On Thu, Feb 23, 2017 at 10:31 AM, Nemo <cym224 at gmail.com> wrote:

> I was a grad student at Toronto but in math, not C


​I hear you and accept that was your experience, but I do find that it is
interesting, that one of the most  infamous and notorious UNIX hackers of
all time is Henry Spenser of the UT Zoology Dept - not Math, not CS or EE.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170223/8b153e3c/attachment.html>

[TUHS] Mach for i386 / Mt Xinu or other

[Nemo]

On 21 February 2017 at 23:17, Larry McVoy <lm at mcvoy.com> wrote (in part):
> On Tue, Feb 21, 2017 at 11:07:20PM -0500, Dan Cross wrote (in part):
>> I can say from first-hand experience that it was NOT easy to get access to
>> Unix source code there.
>
> My experience at UWisc-Madison, during the time they were working on
> 4.3-Uwisc, matches Dan's pretty well.
>
> I don't think it was like what Clem says for most people.  Clem went
> to CMU if I remember correctly, that puts him in a pretty elite class
> right there.  I can easily imagine that the CMU CS department let all
> their students have access to the source if they wanted it.  I don't
> think that was anywhere near as common as Clem thinks it was.

Agreement here.  I was a grad student at Toronto but in math, not CS.
Outside CS were the hoi-poli.  (But there was a lively MINIX
community, especially in biomed.)

N.

[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

[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

[jsteve]

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

I always hear that universities had access, but it wasn’t undergrads in 1000 level classes that arrived.  Asking for that kind of thing was either greeted with laughs, or should shrugging.  Access to anything like that was for either graduate students or people ‘in the click’ and people just arriving were neither.

Just like the partitioning code that was apparently common, none of this stuff was available to anyone that simply didn’t know as there was no central clearing house of information.  And I gather the fear of AT&T meant it wasn’t anything anyone was willing to share.  Not everyone got 20th generation photocopies of the Lions book, nor did they get access to anything other than what teachers were willing to let kids have access to.

Prior to Net/2 people were trying to hack milnet to find BSD source code.  And even when Net/2 was a thing I can tell you that in south Florida among hackers I knew that were my age, none of us had heard of it, or knew anything about it.  When people saw us kids swapping floppies, and lugging around our 386’s to do Linux install parties nobody ever once mentioned anything about having BSD source or anything.  It was a very much gated community, and new students were certainly not welcome.  In those regards it really is no surprise that Linux used nothing from places with ‘source licenses’ as nothing in that was available to actually look at.

Another thing that killed Net/2 was that second networking package for Linux, surprisingly called NET2 shared an incredibly similar name, and even in it’s readme:

	NOTE: In this document, ``NET-2'' does not refer to the Berkeley
	Software Distribution NET-2 release of BSD UNIX. Yes, the names
	are conflicting. In this FAQ, ``NET-2'' refers only to the new
	generation of TCP/IP code in the Linux kernel.

And I’m sure the lawyers were happy that way as us 1000 level kids didn’t care and would happily steal said source, and try to use it.  Even today I’m finding out about this CMU Mach+4.3BSD that was available in 1990, and I suspect there are other i386 based BSD’s that could have filled some kind of gap but either chose not to, or were at best public secrets.

Just as I’m sure if the non Portuguese world had heard of Tropix (http://www.tropix.nce.ufrj.br/) it too may have had a following.

Had AT&T won, there was no stopping Linux though.  It didn’t use anything from AT&T, and back then it was still based on a.out, and some people were looking at using COFF... After AT&T’s defeat did the whole ELF thing come, and then there was the lawsuits on API’s and headers.

If anything I’m more so surprised that the USSR with their stolen BSD didn’t push some kind of Soviet UNIX (DEMOS) into the west, to ride that whole ‘free’ software thing.  Or they were just too politically blind, and figured that westerns would be highly suspicious of Russians pushing stolen American tech.

Sent from Mail for Windows 10

From: Clem Cole
Sent: Thursday, 23 February 2017 11:27 AM
To: Dan Cross
Cc: TUHS main list; Noel Chiappa
Subject: Re: [TUHS] Mach for i386 / Mt Xinu or other


On Tue, Feb 21, 2017 at 8:50 PM, Dan Cross <crossd at gmail.com> wrote:
If I may, I think there was an additional thing at play: Linux was essentially Unix.
​But that is of course my point.   Linux is (was) UNIX, AND ...  "UNIX" as a free UNIX was available at the time.​

 

Linux "won" because people wanted low-cost or free (as in gratis) Unix with source that could run on modest commodity hardware, and Unix wasn't available at a price point that was reasonable for most individuals (certainly not with source).
​Indeed - that was 386BSD.​   At first anyone with a source license (which was just about anyone at University - so that means students like Linus BTW), and most commercial places had access to the BSD license.  The ftp site for download 'Jolix' as some one called it earlier today was pretty much the worst kept secret on the Internet.   All you had to do is ask, and you could find it and once NET/2 was released, and then FreeBSD, NetBSD et al came to be it was all over.

They key was in the case of 386BSD, you want to ask for it (and officially needed a license to ask), but long before Linux shows up there were >>freely<< available PC/UNIX systems.

And you point, which is 100% in agreement with my own is that under the rules of Christiansen disruption, a PC/386 based UNIX that was "cheap enough" was going to win.

The question Noel asked was why did this flavor of UNIX win over the others since there were other choices.   That is what I tried to answer.   As Larry and I both pointed out, if the BSDi/AT&T suit had not occurred the "hackers" which Larry described very well in his document, were going to find something.   386BSD was that place.   Then it got clouded in legal nonsense and lot of us fled.

Larry suggest there were other reasons.  He and many others think the GPL/2 vs the BSD license was important.  I really don't think so.  But that's less of an argument.   The key is that the BSD version was cloud in legal issues (and as Larry pointed out some strong personalities).  


​... 
 So Linux comes along and it's basically a "simplest possible solution" Unix, freely available, runs on a PC, comes with source, and wasn't mired in a lawsuit brought by a major US company. It was the right thing in the right place at the right time.

​Exactly ... ​
Linux arrive at the right time, free of the perceived legal issues.  The sad truth is that if AT&T had won, technically Linux would have had to be removed from the market in the US and NATO countries.   I'll not try to speculate what would have happened then other than to say the not only was cow out of the barn, th
​e​
barn had caught fire so there was not place to put it back.


 

I think there's a network effect that blinds a lot of folks to this reality. Most of the folks on this list had access to Unix source and, with no disrespect intended, it's easy to lose sight of what a big deal that was. But unless you were in a position to already have access to it, it was remarkably difficult to come by. 
​Actually, I always found that a strange statement.  I hear you and no disrespect intended, but  I fear that people that make that claim just did not know where to look.  It was ignorance (not stupidity mind you) - just lack of knowledge that is was available.

I'm going to ask Dan, were you not at an university at time?  Most schools in the US and Europe had BSD licenses.  If you working, I can understand it somewhat.   Many people's first UNIX experience was on a Sun Workstation so those folks did not have UNIX source licenses.   But if you were at a either a University or commercial enterprise with a AT&T and BSD license,  All it took was making sure you university had one and sending and email to the UCB folks (which many of us on this list were some of the folks that might have read it).​ They reply (I if I got searching through old email I might even have a copy of some where) basically was the url of the blind ftp address to pull the iso off the ucb ftp site.  It was incredibly easy to get but you did have to have ftp access (and know the magic path - which if you asked was easy to get).   Even with the first ISO, at one point, I seem to remember the bazillion *BSD floppies showed up on the one of the netnews channels and clogging up the dial-up links for a few days.

The point was if you were at all in the community, it was pretty easy to find the BSD code.  

Which brings me to my point... many developers abandoned it - and most of them certainly know how to get it.  They why I think the incorrect belief that legal entanglement (miss guided as it turned out) where not there with Linux.

By the time the legal case was settled, the developed had "completed enough" of what was missing in Linux from *BSD that many folks never went back.   And the newbie never knew any better.  


 
Linux filled a gap that a lot of people were looking to have filled.
​Agreed..​ but that gap would not have been there if the AT&T legal case had not clouded it all.   Imagine that if the case had no occurred, the hackers were already working with *BSD.

So then the question comes which Larry raises, was the UNIX personalities and/or the licensing what would have caused Linux to rise.

I don't think so, because BSD had too much of a lead - already had networking, windowing, and in fact had a "better" installer on a PC/386.   The first stuff "distro" that was at all reasonably easy t install was a PC was slackware and that was partly because they pulled a bunch of stuff from the stuff Jordan had created.

But they problem was that FreeBSD et al was starting under a legal cloud, I know I was worried.  I ran it on two of my systems, but was working on Linux on another to hedge my bet.  I was not sure BSDi/UCB would win, so I started helping make Linux work better too.

Clem


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170222/0621b9f6/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: 2484 bytes --]

Yeah slices? A: b: c: d: e:?  But C: is the whole drive??? I had some really old BSD book that talks about needing 4 people to install a harddisk as they were so heavy, and talking about it’s massive ‘500MB’ capacity (Eagle drive on a VAX?) but it certainly didn’t fit in the DOS / OS/2 / Windows NT world.

And OS/2 was so much like MS-DOS needing to reboot and so clunky, while Windows NT let you partition at will, and even concatenating disks, or setting up software raid with absolute ease it made you wonder why it always was so difficult on anything else.

Sent from Mail for Windows 10

From: Wesley Parish
Sent: Thursday, 23 February 2017 7:14 AM
To: Larry McVoy
Cc: TUHS main list; Noel Chiappa
Subject: Re: [TUHS] Mach for i386 / Mt Xinu or other

Now that brings up another reason why I think Linux won. Most of the early Linux developers were 
educated partly in the MS/PC/DR DOS world. They wanted a Unix, but they had bought IBM PC clones 
with MS DOS and were familiar with the DOS way of doing things.

Linux's disk partitioning is very familiar to anyone who's familiar with the DOS way of disk partitioning. 
BSD's disk partitioning is a culture shock. (I know. I'd gotten used to the DOS way of doing things after 
learning about disk partitioning with my 486 and IBM OS/2 - the hard way. I tried Linux and the 
terminology was the same and due to a neat trick with the DOS filesystem I could experiment with it on 
an unchanged DOS system. I then tried FreeBSD and I didn't understand the terminology. So I stuck with 
what I'd learnt.)

FWLIW :)

Wesley Parish

Quoting Larry McVoy <lm at mcvoy.com>:

> On Tue, Feb 21, 2017 at 03:28:13PM -0500, Steve Nickolas wrote:
> > On Tue, 21 Feb 2017, Larry McVoy wrote:
> > 
> > >In terms of crash worthyness, ext2 was better. I think the ext2
> people
> > >took the approach that they wanted to be as robust as dos but with
> > >performance. And they made it, it's some very nice work.
> > 
> > Wouldn't "as robust as DOS" be a *bad* thing?
> 
> The DOS file system, while stupid, was very robust in the face of
> crashes
> (sort of had to be, he says slyly).
>  



"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

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

[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

[Larry McVoy]

On Tue, Feb 21, 2017 at 11:07:20PM -0500, Dan Cross wrote:
> I can say from first-hand experience that it was NOT easy to get access to
> Unix source code there. The cadre of university system administrators that
> formed something of a cabal did not hand it out lightly, and it took
> significant time to gain the sort of trust that would result in you getting
> access to it. I strongly suspect that if a random CS student had written to
> UCB asking for access to the BSD source code, and that had gotten back to
> the aforementioned cabal, it would not have gone well for the student. Lots
> of intrusive questions would have been asked; angry letters written and
> placed into files. Uncomfortable meetings with academic advisors and the
> university computer security officer would have taken place. Questions of
> academic malfeasance or expulsion may have come up, etc.

My experience at UWisc-Madison, during the time they were working on
4.3-Uwisc, matches Dan's pretty well.  Yup, source was there.  Access
was restricted, you had to get a login on slovax, and you had to be
"somebody" to get that login.  I don't remember how I got access, 
I just knew I wanted it.  So I probably just begged and eventually
one of the admins took pity on me?  Dunno.

I don't think it was like what Clem says for most people.  Clem went
to CMU if I remember correctly, that puts him in a pretty elite class
right there.  I can easily imagine that the CMU CS department let all
their students have access to the source if they wanted it.  I don't
think that was anywhere near as common as Clem thinks it was.  My guess
is that Clem interacted with a bunch of people who were his peers (aka
pretty elite people) and all those guys had source access.  Us unwashed
masses had to work a lot harder to get it.

Once 386BSD came out, yeah, source was easy.  Not before.

Even when I was at Sun the historic source was there, v7, 32v, etc., but
you had to get past Shannon to get at it.

[TUHS] Mach for i386 / Mt Xinu or other

[Larry McVoy]

On Tue, Feb 21, 2017 at 08:06:29PM -0800, Larry McVoy wrote:
> The open source BSD stuff was a train wreck from the very beginning.
> Nobody could get along with Jolitz, so NetBSD started, then Theo wanted
> to be in charge of something so OpenBSD was born.  I can't remember how
> FreeBSD got spun out, but what I do remember is that there were power
> struggles from day 1.  

Oh, and I forgot, then there was the BSDi group.  While we all loved 
those guys, they left a sour taste.  There was some bad blood between
them and Jolitz (he unfairly got the short end of that stick).  And
as Clem says, we all wanted a free or really really cheap Unix and
these guys wanted $995 for a release.  I think a lot of us felt like
they sort of betrayed the ethos of Unix, we wanted free like it was
when you got a tape from dmr (no, I never got one, just got to hear
the stories and they sounded great).

The whole BSD thing in the early 90's was a train wreck.  In my opinion.

[TUHS] Mach for i386 / Mt Xinu or other

[Dan Cross]

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

On Tue, Feb 21, 2017 at 10:11 PM, Clem Cole <clemc at ccc.com> wrote:

> [snip: I think we're mostly in agreement here, Clem]
>
>> I think there's a network effect that blinds a lot of folks to this
>> reality. Most of the folks on this list had access to Unix source and, with
>> no disrespect intended, it's easy to lose sight of what a big deal that
>> was. But unless you were in a position to already have access to it, it was
>> remarkably difficult to come by.
>>
> ​Actually, I always found that a strange statement.  I hear you and no
> disrespect intended, but  I fear that people that make that claim just
> did not know where to look.  It was ignorance (not stupidity mind you) -
> just lack of knowledge that is was available.
>
> I'm going to ask Dan, were you not at an university at time?  Most schools
> in the US and Europe had BSD licenses.  If you working, I can understand it
> somewhat.   Many people's first UNIX experience was on a Sun Workstation so
> those folks did not have UNIX source licenses.   But if you were at a
> either a University or commercial enterprise with a AT&T and BSD license,
>  All it took was making sure you university had one and sending and email
> to the UCB folks (which many of us on this list were some of the folks that
> might have read it).​ They reply (I if I got searching through old email I
> might even have a copy of some where) basically was the url of the blind
> ftp address to pull the iso off the ucb ftp site.  It was incredibly easy
> to get but you did have to have ftp access (and know the magic path - which
> if you asked was easy to get).   Even with the first ISO, at one point, I
> seem to remember the bazillion *BSD floppies showed up on the one of the
> netnews channels and clogging up the dial-up links for a few days.
>

So I was in high school, but I was affiliated with a major university (one
that, yes, did have a Unix source license) because I held a part-time
sysadmin job. For the curious, it was Penn State University; not a huge CS
powerhouse like, say, MIT or CMU, but it held it's own as a large research
university (they have, for instance, hands-down the best Acoustics
department in the world. Also, while it may seem quaint, they hands-down
have the best agriculture department in the world: kind of important for
that whole food thing. :-)). I didn't go there as a student, but lived in
the town during high school and cut my teeth on their computers.

I can say from first-hand experience that it was NOT easy to get access to
Unix source code there. The cadre of university system administrators that
formed something of a cabal did not hand it out lightly, and it took
significant time to gain the sort of trust that would result in you getting
access to it. I strongly suspect that if a random CS student had written to
UCB asking for access to the BSD source code, and that had gotten back to
the aforementioned cabal, it would not have gone well for the student. Lots
of intrusive questions would have been asked; angry letters written and
placed into files. Uncomfortable meetings with academic advisors and the
university computer security officer would have taken place. Questions of
academic malfeasance or expulsion may have come up, etc.

Was any of that justified? No, not really. I suspect much of it came from
an outsized sense of trying to protect the university from potential
litigation should a poorly-secured student machine on the dorm network be
compromised with AT&T proprietary material/trade secrets on it, etc. As
became clear a few years ago, perhaps that energy should have been spent
looking into the school's football program, but of course the local
sysadmins had nothing to do with that. Anyway, for what it's worth, as a
student/low-level staff in the early- to mid- 90s? No, you weren't going to
get access to Unix code using the site license -- even from Berkeley --
unless you were on a first-name basis with a number of folks in the local
computing community. And that wasn't going to happen for the majority of
students for logistical reasons if nothing else.

The point was if you were at all in the community, it was pretty easy to
> find the BSD code.
>

Please see above. It may have been easy, but that didn't mean there
wouldn't be consequences due to misunderstandings or what have you.

Which brings me to my point... many developers abandoned it - and most of
> them certainly know how to get it.  They why I think the incorrect belief
> that legal entanglement (miss guided as it turned out) where not there with
> Linux.
>
> By the time the legal case was settled, the developed had "completed
> enough" of what was missing in Linux from *BSD that many folks never went
> back.   And the newbie never knew any better.
>

The point I was trying to make was that the newbie didn't know any better
but didn't want anything else, even if s/he did know any better. Plan 9 was
available after 2000 gratis, but by then no one wanted it (more's the pity,
IMHO). If I think about the systems that were interesting in the research
sphere in the late 80s early 90s, they were V, Chorus, Minix and Xinu for
education, Mach, NeXTSTEP, etc: again, no one really wanted them. They
wanted Unix a la SunOS 4/System V instead. As you noted, BSD's future
looked dubious, so they got Linux instead: it was the next closest thing
that didn't look like it might result in a trench-coated G-man breaking
down your door.

Linux filled a gap that a lot of people were looking to have filled.
>>
> ​Agreed..​ but that gap would not have been there if the AT&T legal case
> had not clouded it all.   Imagine that if the case had no occurred, the
> hackers were already working with *BSD.
>
> So then the question comes which Larry raises, was the UNIX personalities
> and/or the licensing what would have caused Linux to rise.
>
> I don't think so, because BSD had too much of a lead - already had
> networking, windowing, and in fact had a "better" installer on a PC/386.
> The first stuff "distro" that was at all reasonably easy t install was a PC
> was slackware and that was partly because they pulled a bunch of stuff from
> the stuff Jordan had created.
>
> But they problem was that FreeBSD et al was starting under a legal cloud,
> I know I was worried.  I ran it on two of my systems, but was working on
> Linux on another to hedge my bet.  I was not sure BSDi/UCB would win, so I
> started helping make Linux work better too.
>

I think you are absolutely right. It's kind of sad, in a way. Oh well.

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

[TUHS] Mach for i386 / Mt Xinu or other

[Larry McVoy]

On Wed, Feb 22, 2017 at 03:45:54AM +0000, ron minnich wrote:
> On Tue, Feb 21, 2017 at 7:18 PM Larry McVoy <lm at mcvoy.com> wrote:
> 
> > That was pretty early, Ron.  I betcha if you tried it now (or 10 years
> > ago) things would be different.
> 
> I think that is true. But from my point of view "linux winning" was not
> necessarily "linux was better at the time." I think it was a lot of factors.
> 
> When I got to Los Alamos in 1999, it was still a tossup between the BSDs
> and Linux as to "which is better." Nevertheless, for lots of reasons, in
> 1998 (the same year I found Linux to be less reliable over time) Los Alamos
> had cast its lot with Linux, for all kinds of reasons.

I lived through all this and payed close attention to all of the people
involved (Theo has/had my Sun 4/470, we argued about VM systems in my
flat in SF, Jolitz worked for me, I hung with Chris Demetriou back in
the 386BSD days, I was all over that stuff and wanted it to succeed).

The open source BSD stuff was a train wreck from the very beginning.
Nobody could get along with Jolitz, so NetBSD started, then Theo wanted
to be in charge of something so OpenBSD was born.  I can't remember how
FreeBSD got spun out, but what I do remember is that there were power
struggles from day 1.  Everyone thought they were better than the other
guy, when in fact, what was pretty good was the BSD source base and most
of these people, initially, had very little skin in the game in the form
of code, they were all leveraging the BSD source base.  I actually think
Jolitiz had more code in there in the beginning than anyone else.

No matter who did what, they couldn't / wouldn't / didn't rally around a
single leader and a single project.  So it was "divide and fail" where
Linux was a big tent, anyone who could write decent code was welcome,
but you had to get it past Linus.  Which was fine, people figured out he
had a clue and put up with the fact that they had to get past his filter
(many of us, myself included, valued that filter very, very much).

By 1998/1999, all of these BSD struggles for power were blindingly obvious
to anyone who was remotely paying attention.  I think they were obvious
4-5 years before that.  And it wasn't obvious just to people like me,
management types track this stuff far more than most people believe.
They have to back the right horse or it costs them.  Linux was simply
a safer bet.  The community was larger and growing very fast.  I was
program committee chair at Linux Expo in 1999 (sort of their Usenix
at the time).  It was way more fun than Usenix.

I think a lot of the "better" stuff came from the fact that Linux got
networking long after BSD had pretty sweet networking.  The BSD guys
still think their networking is better than Linux (pro tip, it is not,
go read networking research papers, they all use Linux as the platform
and it's not because there is so much to fix, it's because Linux 
networking is better).  BSD hasn't been better than Linux in any way
that I know of for about 15 years.
-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

[TUHS] Mach for i386 / Mt Xinu or other

[Rudi Blom]

>On Tue, 21 Feb 2017 19:08:33 -0800 Cory Smelosky wrote:
>
>>On Tue, Feb 21, 2017, at 17:22, Rudi Blom wrote:
>> Probably my (misplaced?) sense of humour, but I can't help it.
>>
>> After reading all comment I feel I have to mention I had a look at
>> freeDOS :-).
>>
>> Cheers,
>> rudi
>
>Do I need to pull out TOPS-10 filesystem code now, too? ;)

In 1967 I was 12 and probably had barely discovered ScienceFiction
novel and computers.

Just quickly downloaded a TOPS-10 OS Commands Manual (from 1988) but
no mention of the Level-D filesystem

[TUHS] Mach for i386 / Mt Xinu or other

[ron minnich]

On Tue, Feb 21, 2017 at 7:18 PM Larry McVoy <lm at mcvoy.com> wrote:

> That was pretty early, Ron.  I betcha if you tried it now (or 10 years
> ago) things would be different.
>
>
>

I think that is true. But from my point of view "linux winning" was not
necessarily "linux was better at the time." I think it was a lot of factors.

When I got to Los Alamos in 1999, it was still a tossup between the BSDs
and Linux as to "which is better." Nevertheless, for lots of reasons, in
1998 (the same year I found Linux to be less reliable over time) Los Alamos
had cast its lot with Linux, for all kinds of reasons.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170222/e46105ef/attachment.html>

[TUHS] Mach for i386 / Mt Xinu or other

[Larry McVoy]

That was pretty early, Ron.  I betcha if you tried it now (or 10 years 
ago) things would be different.

On Wed, Feb 22, 2017 at 01:04:16AM +0000, ron minnich wrote:
> I got to thinking about the file system sync vs. order argument as a result
> of this interesting discussion.
> 
> Back in NJ in 1998 I had a 144-node PC cluster. It started with 80 FreeBSD
> nodes, and a few months later we add 64 Linux nodes. It was DARPA funded
> and we were looking at issues around clustering.
> 
> What we discovered, when we added the Linux cluster, was that building
> power was really terrible. We had not realized it with the freebsd cluster
> because it tended to cleanly recover from unplanned nasty power cycles. But
> the Linux cluster tended to always have a small number of nodes that did
> not get through fsck.
> 
> yeah, it's not that good a data point maybe, but we found it interesting.

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

[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: 6053 bytes --]

On Tue, Feb 21, 2017 at 8:50 PM, Dan Cross <crossd at gmail.com> wrote:

> If I may, I think there was an additional thing at play: Linux was
> essentially Unix.
>
​But that is of course my point.   Linux is (was) UNIX, AND ...  "UNIX" as
a free UNIX *was *available at the time.​



>
> Linux "won" because people wanted low-cost or free (as in gratis) Unix
> with source that could run on modest commodity hardware, and Unix wasn't
> available at a price point that was reasonable for most individuals
> (certainly not with source).
>
​Indeed - that was 386BSD.​   At first anyone with a source license (which
was just about anyone at University - so that means students like Linus
BTW), and most commercial places had access to the BSD license.  The ftp
site for download 'Jolix' as some one called it earlier today was pretty
much the worst kept secret on the Internet.   All you had to do is ask, and
you could find it and once NET/2 was released, and then FreeBSD, NetBSD et
al came to be it was all over.

They key was in the case of 386BSD, you want to ask for it (and
officially needed a license to ask), but long before Linux shows up there
were >>freely<< available PC/UNIX systems.

And you point, which is 100% in agreement with my own is that under the
rules of Christiansen disruption, a PC/386 based UNIX that was "cheap
enough" was going to win.

The question Noel asked was why did *this flavor *of UNIX win over the
others since there were other choices.   That is what I tried to answer.
As Larry and I both pointed out, if the BSDi/AT&T suit had not occurred the
"hackers" which Larry described very well in his document, were going to
find something.   386BSD was that place.   Then it got clouded in legal
nonsense and lot of us fled.

Larry suggest there were other reasons.  He and many others think the GPL/2
vs the BSD license was important.  I really don't think so.  But that's
less of an argument.   The key is that the BSD version was cloud in legal
issues (and as Larry pointed out some strong personalities).


​...
>  So Linux comes along and it's basically a "simplest possible solution"
> Unix, freely available, runs on a PC, comes with source, and wasn't mired
> in a lawsuit brought by a major US company. It was the right thing in the
> right place at the right time.
>

​Exactly ... ​
Linux arrive at the right time, free of the *perceived* legal issues.  The
sad truth is that if AT&T had won, technically Linux would have had to be
removed from the market in the US and NATO countries.   I'll not try to
speculate what would have happened then other than to say the not only was
cow out of the barn, th
​e​
barn had caught fire so there was not place to put it back.




>
> I think there's a network effect that blinds a lot of folks to this
> reality. Most of the folks on this list had access to Unix source and, with
> no disrespect intended, it's easy to lose sight of what a big deal that
> was. But unless you were in a position to already have access to it, it was
> remarkably difficult to come by.
>
​Actually, I always found that a strange statement.  I hear you and no
disrespect intended, but  I fear that people that make that claim just did
not know where to look.  It was ignorance (not stupidity mind you) - just
lack of knowledge that is was available.

I'm going to ask Dan, were you not at an university at time?  Most schools
in the US and Europe had BSD licenses.  If you working, I can understand it
somewhat.   Many people's first UNIX experience was on a Sun Workstation so
those folks did not have UNIX source licenses.   But if you were at a
either a University or commercial enterprise with a AT&T and BSD license,
 All it took was making sure you university had one and sending and email
to the UCB folks (which many of us on this list were some of the folks that
might have read it).​ They reply (I if I got searching through old email I
might even have a copy of some where) basically was the url of the blind
ftp address to pull the iso off the ucb ftp site.  It was incredibly easy
to get but you did have to have ftp access (and know the magic path - which
if you asked was easy to get).   Even with the first ISO, at one point, I
seem to remember the bazillion *BSD floppies showed up on the one of the
netnews channels and clogging up the dial-up links for a few days.

The point was if you were at all in the community, it was pretty easy to
find the BSD code.

Which brings me to my point... many developers abandoned it - and most of
them certainly know how to get it.  They why I think the incorrect belief
that legal entanglement (miss guided as it turned out) where not there with
Linux.

By the time the legal case was settled, the developed had "completed
enough" of what was missing in Linux from *BSD that many folks never went
back.   And the newbie never knew any better.




> Linux filled a gap that a lot of people were looking to have filled.
>
​Agreed..​ but that gap would not have been there if the AT&T legal case
had not clouded it all.   Imagine that if the case had no occurred, the
hackers were already working with *BSD.

So then the question comes which Larry raises, was the UNIX personalities
and/or the licensing what would have caused Linux to rise.

I don't think so, because BSD had too much of a lead - already had
networking, windowing, and in fact had a "better" installer on a PC/386.
The first stuff "distro" that was at all reasonably easy t install was a PC
was slackware and that was partly because they pulled a bunch of stuff from
the stuff Jordan had created.

But they problem was that FreeBSD et al was starting under a legal cloud, I
know I was worried.  I ran it on two of my systems, but was working on
Linux on another to hedge my bet.  I was not sure BSDi/UCB would win, so I
started helping make Linux work better too.

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

[TUHS] Mach for i386 / Mt Xinu or other

[Cory Smelosky]

On Tue, Feb 21, 2017, at 17:22, Rudi Blom wrote:
> Probably my (misplaced?) sense of humour, but I can't help it.
> 
> After reading all comment I feel I have to mention I had a look at
> freeDOS :-)
> 
> Cheers,
> rudi

Do I need to pull out TOPS-10 filesystem code now, too? ;)

-- 
  Cory Smelosky
  b4 at gewt.net

[TUHS] Mach for i386 / Mt Xinu or other

[Steve Nickolas]

On Tue, 21 Feb 2017, Dan Cross wrote:

> If I may, I think there was an additional thing at play: Linux was
> essentially Unix.
>
> Linux "won" because people wanted low-cost or free (as in gratis) Unix with
> source that could run on modest commodity hardware, and Unix wasn't
> available at a price point that was reasonable for most individuals
> (certainly not with source). The people working on successor systems
> weren't trying to reinvent Unix: they were working on new systems that
> weren't Unix, but that's not what people wanted: Unix was good enough and
> people were familiar and comfortable with it and that's what they wanted.
> So Linux comes along and it's basically a "simplest possible solution"
> Unix, freely available, runs on a PC, comes with source, and wasn't mired
> in a lawsuit brought by a major US company. It was the right thing in the
> right place at the right time.
>
> I think there's a network effect that blinds a lot of folks to this
> reality. Most of the folks on this list had access to Unix source and, with
> no disrespect intended, it's easy to lose sight of what a big deal that
> was. But unless you were in a position to already have access to it, it was
> remarkably difficult to come by. Linux filled a gap that a lot of people
> were looking to have filled.
>
>        - Dan C.
>

I started screwing around with Linux in the late 90s, and it would be many 
years before any sort of real Unix (of the AT&T variety), in any form, was 
readily available to me - that being Solaris when Sun started offering it 
for free download.

-uso.

[TUHS] Mach for i386 / Mt Xinu or other

[Dan Cross]

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

On Tue, Feb 21, 2017 at 10:02 AM, Clem Cole <clemc at ccc.com> wrote:
>
> On Tue, Feb 21, 2017 at 7:02 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
> wrote:
>
>> So there is a question here, though, and I'm curious to see what others
>> who
>> were closer to the action think. Why _did_ Linux succeed, and not a Unix
>> derivative? (Is there any work which looks at this question? Some Linux
>> history? If not, there should be.)
>>
>
> ​I​'ve thought and written a bit about this question a bit [
> Would it be possible/advantageous to rewrite the Linux kernel in Rust when
> the language is stable?
> <https://www.quora.com/Would-it-be-possible-advantageous-to-rewrite-the-Linux-kernel-in-Rust-when-the-language-is-stable>
>  &
>  Why did Unix succeed and not Multics
> <https://www.quora.com/Why-did-Unix-succeed-and-not-Multics> ] ​
> ​
> and I'll not repeat all of here but
> ​as one of the people that did switch from 386BSD to linux at the time,
> the reason for me was purely because of the AT&T/BSDi case.    You are
> right, I wanted a "free" (i.e. very inexpensive) UNIX for the 386 and the
> "big guns"​ were not going to give it.   I thought we had it the 386 port
> BSD which I had helped in a small way to create.
>
> ​But I like, most hackers of the day, misunderstood incorrectly​ the case
> to be about *trade secret *and the all based around the 1956 consent
> decree, IBM vs AT&T; telephones and the computers. I was worried AT&T
> would win because it was going to hard to cleaim that that the BSD code was
> not a derivative work of the AT&T *copyright code base *(not
> understanding the *trade secret*  and the  *copyright* difference
> mattered).
>
> So...I switched to Linux *not because I thought it was "better"* - in
> fact, I b*tched (and still do) about many gratuitous differences, but as I
> knew that we needed something for "consumer" HW (which was bring driven by
> the WINTEL economics), and I was willing to use the "lessor" technology
> (Linux) because it was "good enough" and gave me what I needed (UNIX on a
> PC/386).  I thought (incorrectly) somehow original Linux's European
> authorship was going to protect me and my fellow hackers ever though it was
> not as good as my beloved BSD system.
>
> Simple put - using Christiansen's theories:  Linux "won" because:
>
>    - it was "good enough",
>    - had a lot of people behind it that valued that was there and
>    invested in making it "better", and
>    - the economics of the platform (PC/386 - WINTEL etc) was on the
>    fastest grow curve [and its Christiansen's economic disruption was
>    displacing the Mini & Workstation].
>
>
> BTW: at the time, I argued with the Roger Gourd and the OSF folks, that if
> they released (sold) the OSF/1 RI uK which had not AT&T technology in it
> (again thinking Copyright not Trade Secret); I was suggesting $100/copy
> there was a market for it.  I just could not get them interested.
>
> Sun has done the RoadRunner and had their 386 port of Solaris; but again.
> All the "UNIX" folks were still interested in pushing out "iron" so were
> blind to the WINTEL economic disruption.
>
> Woulda, Coulda, Shoulda .... sigh
>

If I may, I think there was an additional thing at play: Linux was
essentially Unix.

Linux "won" because people wanted low-cost or free (as in gratis) Unix with
source that could run on modest commodity hardware, and Unix wasn't
available at a price point that was reasonable for most individuals
(certainly not with source). The people working on successor systems
weren't trying to reinvent Unix: they were working on new systems that
weren't Unix, but that's not what people wanted: Unix was good enough and
people were familiar and comfortable with it and that's what they wanted.
So Linux comes along and it's basically a "simplest possible solution"
Unix, freely available, runs on a PC, comes with source, and wasn't mired
in a lawsuit brought by a major US company. It was the right thing in the
right place at the right time.

I think there's a network effect that blinds a lot of folks to this
reality. Most of the folks on this list had access to Unix source and, with
no disrespect intended, it's easy to lose sight of what a big deal that
was. But unless you were in a position to already have access to it, it was
remarkably difficult to come by. Linux filled a gap that a lot of people
were looking to have filled.

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

[TUHS] Mach for i386 / Mt Xinu or other

[jason-tuhs]

> I got to thinking about the file system sync vs. order argument as a 
> result of this interesting discussion.
> [...]
> What we discovered, when we added the Linux cluster, was that building 
> power was really terrible. We had not realized it with the freebsd 
> cluster because it tended to cleanly recover from unplanned nasty power 
> cycles. But the Linux cluster tended to always have a small number of 
> nodes that did not get through fsck.

Soft updates was available in 1998.  Were you running that?

Surprised it hasn't come up already in this discussion; I've been waiting 
for someone to mention it.

http://www.mckusick.com/softdep/

There was some licensing issue with it in the early days: it was freely 
available and free to use, but McKusick wanted a chance to try to sell it 
to a commercial unix vendor as well.  But he ended up BSD-licensing it a 
couple years later.

The original README from the FreeBSD source tree:
https://svnweb.freebsd.org/base/release/3.0.0/contrib/sys/softupdates/README?revision=42952&view=co


Anyway, it solved the on-disk consistency problem and boosted performance 
as well.  I enabled it on all my systems.


  -Jason

[TUHS] Mach for i386 / Mt Xinu or other

[Rudi Blom]

Probably my (misplaced?) sense of humour, but I can't help it.

After reading all comment I feel I have to mention I had a look at freeDOS :-)

Cheers,
rudi

[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: 5143 bytes --]

​below... this one made me a laugh a little because it skipped a few steps
that knew (and was a part).​

Once again it was ignorance and little luck that brought us what we got,
not invention nor knowledge.

On Tue, Feb 21, 2017 at 5:58 PM, Wesley Parish <wes.parish at paradise.net.nz>
wrote:

> Now that brings up another reason why I think Linux won. Most of the early
> Linux developers were
> ​ ​
> educated partly in the MS/PC/DR DOS world. They wanted a Unix, but they
> had bought IBM PC clones
> ​ ​
> with MS DOS and were familiar with the DOS way of doing things.
>
​Sort of.... but be careful of a little history here.​




>
> Linux's disk partitioning is very familiar to anyone who's familiar with
> the DOS way of disk partitioning.
>
​Yes, because Linux was not not really enough of UNIX hacker to know that
UNIX partition scheme for PC's was open source and all the code to do it
was available to him.  He wrote his own.​  I remember when I first
encountered the Linux craziness and thinking something on the order of:
 "Why, why are they putting things in DOS partitions ... the BIOS ROMS are
a mess and are already broken... we fixed this already for UNIX on the
386!!!!"

In truth, most end users running real UNIX on a PC/386 were not trying to
dual boot DOS and UNIX, so other than being able to boot the system into
UNIX, they just wanted partitions to map an entire drive and properly load
the read OS (UNIX). So the UNIX scheme, of reserving the disk from the boot
rom, and getting those damned DOS roms out the way ASAP was a fine
solution.  And in the beginning of PC/UNIX that is all that was wanted and
what was there.





> BSD's disk partitioning is a culture shock.
>
The PC Disk partitioning scheme was developed by Intel and the code
released to the UNIX community.  It was the same code base for all 3 System
V ports (which were all done by Interactive Systems under contract for each
of Intel, IBM, and AT&T - one of the best bit of salesmanship Phil Shevrin
ever pulled off IMO -- they did one port and sold it three times).  It was
also used by the AIX/386 folks and eventually usd by Sun.   Part of the
original deal was a project CMU had done with both Intel and IBM for during
that time frame, and between Intel and IBM they got the CMU code made
available (as part of the Andrew project IIRC).   CMU would of course use
this bot/partition code for the Mach port, Jolitz for the BSD port, as well
as all the AT&T base versions.  In fact, it was because of CMU, that UNIX
partition type (type 63) was defined as Intel got Microsoft to add it to
the master database.

The history was something like this as I understand it.... Microsoft starts
to develop Xenix for the 286/68K/Z8000 and maybe one other processor I've
forgotten.  One of the original Xenix ports it to the PC/AT which is 286
based, which it is doing jointly with Intel as well as IBM.  CMU was
working with IBM in Andrew and some how got into that mix and is using
PC/AT as part of the Andrew project.   CMU guys want C tools, so they write
an fdisk/boot system for their stuff.   That migrates back to Intel which
migrates to back to Xenix and Microsoft.   They also made it to UCB as a
version of them is what Jolitz uses for 386BSD.

The question I always wonder was why Andy Tannenbaum did not use those
tools with Minix, but I'm guessing he was trying to do everything virgin
and clean.   Because Linus started with the Minix fdisk, the rest is
history.  Had Linus looked (or asked) the code was very available and he
might have used it too.

The point is that until Minux and Linux, it was actually kinda cool.  All
of the UNIX on a PC/386 platform used the made boot and disk scheme and
hard started with the same C source for boot and fdisk.






> I then tried FreeBSD and I didn't understand the terminology. So I stuck
> with
> what I'd learnt.)
>

That said, as disks kept getting bigger and bigger and the "big iron" folks
had better boot roms, folks like Sun, Masscomp, DEC et al, had much better
support for disk geometry.   The original UNIX on PC partition scheme had
some rough edges, particularly WRT linear addressed drives (such stated
with SCSI, but the PC morphed there also), so BSD took the current scheme
and re-did. Hence, one group PC/UNIX (BSD) folks started to trying to make
the PC boxes do the same things that the Workstations and Mini's could.

So the FreeBSD guys start to extend (sounds like folks from Redmond
eh...)....  Anyway, that's were the new terms like "slice" came from, and I
​admit by the 3rd or 4th rewrite what was in PC/BSD and what was originally
in PC/UNIX differed.

Of course, Microsoft/Intel also had to deal with the bigger and bigger
disks and the same issues withe BIOS that IBM had given us from very small
disks a long time ago but they were not trying emulate "big unix."   So
they did something that worked well for them.    Linux was able to ride the
MS/Intel solutions.   ​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170221/26def03b/attachment-0001.html>

[TUHS] Mach for i386 / Mt Xinu or other

[ron minnich]

I got to thinking about the file system sync vs. order argument as a result
of this interesting discussion.

Back in NJ in 1998 I had a 144-node PC cluster. It started with 80 FreeBSD
nodes, and a few months later we add 64 Linux nodes. It was DARPA funded
and we were looking at issues around clustering.

What we discovered, when we added the Linux cluster, was that building
power was really terrible. We had not realized it with the freebsd cluster
because it tended to cleanly recover from unplanned nasty power cycles. But
the Linux cluster tended to always have a small number of nodes that did
not get through fsck.

yeah, it's not that good a data point maybe, but we found it interesting.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170222/1da3aba5/attachment.html>

[TUHS] Mach for i386 / Mt Xinu or other

[Andy Kosela]

On Tuesday, February 21, 2017, Larry McVoy <lm at mcvoy.com> wrote:

> On Tue, Feb 21, 2017 at 07:02:18AM -0500, Noel Chiappa wrote:
> > So there is a question here, though, and I'm curious to see what others
> who
> > were closer to the action think. Why _did_ Linux succeed, and not a Unix
> > derivative? (Is there any work which looks at this question? Some Linux
> > history? If not, there should be.)
>
> http://www.mcvoy.com/lm/bitmover/lm/papers/srcos.html
>
> is worth a read, I was very much in the middle of all this at the time.
>
> I think Linux succeeded because:
>
>     - it was free and GPLed.  BSD license is nice but it has the problem
>       that people can take it closed source and not give back changes.
>
>     - no lawsuit
>
>     - Linus (as mentioned, much stronger leader than any in the Unix world)
>
>     - no religion.  I can't make this point hard enough.  At Sun, we
> couldn't
>       change any API, any utility, it was compat to the point that it was
> not
>       useful.  Look at SVr4/Solaris /proc and then look at Linux /proc.
> The
>       Linux one is way, way, way, way more useful, you can dig shit out
> with
>       shell scripts.  The rest of the Unix world was blindly posix compat
>       even when posix compat made no sense.  Linux was glorious in that
>       Linus wanted compat but was willing to break it for good reasons.
>
>     - good enough
>
>     - fun, all the cool kids were there.
>
> Here is perhaps something that will resonate with this crowd.  When I was
> teaching OS at Stanford, for file systems I made people go through the
> thought process on when you write what (think the sync writes so the FS
> isn't busted when you crash).
>
> For years, the BSD guys insisted that Linux was doing it wrong because
> they didn't do the sync writes, they did ordered writes (but the BSD
> guys didn't understand the write ordering so they thought it was busted,
> as did I).
>
> But Linux wasn't busted, they had carefully gone through the process
> of figuring out when stuff had to be first so that you could survive
> a crash.
>
> The BSD guys refused to believe that it was possible, they were stuck
> on writes had to be synchronous in order to get a file system that
> wasn't corrupted on a crash.
>
> I eventually started convincing them that Linux had it right by saying
> just untar some big tarball and unplug the power in the middle of that
> on a system with UFS and a system with ext2.  Tell me what happens when
> you power it up.  Answer?  The UFS based system dropped you into a fsck
> nightmare of unattached inodes, the ext2 based systems lost some data
> but the file system was fine.
>
> Obviously, the Linux approach won, it's better.  Way better, higher
> performance and a much better user experience.  But the traditional
> Unix guys had to be dragged kicking and screaming, over a decade,
> into that world.  It's stuff like that that made Unix stagnate while
> Linux forged ahead.
>

Interesting points.  I think Linux really succeded because big IT players
like IBM, HP, Oracle etc. started to promote and financially support
it around 99.  Before that time Linux and FreeBSD went head-to-head and one
can argue that actually FreeBSD was more technically advanced at that time.

When IBM poured millions of dollars in developing Linux it showed.  After
year 2000 the growth of Linux was phenomenal -- it started to show
up everywhere, from embedded world to supercomputers.

Hardware support from big vendors also helped make it the official Open
Source Unix.  To this day you will not get a support contract for FreeBSD
from HP or Dell, and they make up the majority of what you see in modern
data centers.

--Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170221/294e5437/attachment.html>

[TUHS] Mach for i386 / Mt Xinu or other

[Arthur Krewat]

Not to mention, DOS was pretty much single-threaded. It wasn't very 
often that you had multiple threads writing files in different 
locations. And when they did, a write was atomic. Update the block(s), 
update the FAT. There was no preemption. Only when Windows (and it's 
other multi-tasking brethren) came along was it possible that two 
threads would be writing to different files. Even then, I'm willing to 
bet that the entire "write block, update FAT" was atomic for the 
DOS-based Windows. Of course, I'm only talking about the FAT file system 
as it grew out of the first floppy-disk based PC's, and not NTFS nor the 
NT-based Windows versions to come later.

However, it was possible to actually be in the middle of writing a block 
(or sector) and cut the power and it wouldn't finish writing sector. 
Leading to data or FAT corruption. If I remember correctly, when that 
happened, it was best to manually pick through both FAT copies and see 
which one was correct :)

The worst was overwriting an existing block, because the FAT wasn't 
updated, and if the data wasn't completely written when the power cut, 
well, say good bye to the disk sector it was on.

On 2/21/2017 4:49 PM, Noel Chiappa wrote:
> The duplicated FAT, and the way file sectors are linked using it, is I suppose
> a little more robust than other designs (e.g. the way early Unixes did it,
> with indirect blocks and free lists), but I think a lot of it must have been
> that DOS wrote stuff out quickly (as opposed to e.g. the delayed writes on
> early Unix FS's, etc). That probably appoximated the write-ordering of more
> designed-robust FS's.
>

[TUHS] Mach for i386 / Mt Xinu or other

[Nick Downing]

I'm just going to jump in about the philosophical "everything is a
file" Unix concept.

I reckon this works very well for things that are "file like" in
nature. The genius of Thompson and Ritchie was to realize that a file
is a sequence of characters, and so is a TTY (or at least one
direction of a TTY). And of course it is REALLY REALLY HANDY, to have
things like an ad-hoc scripting ability (redirect a file to a program
that's expecting a TTY) and all the other combinations that are
possible.

At the same time, files have an additional capability which is
seeking. So did they implement some crazy ad-hoc scheme where you have
to write an escape sequence to the file in order to effect a seek? No
they did not. They added a seek(), or later lseek() system call, which
sensibly returns an error code if the thing receiving the command is
not capable of doing a seek. That is, they made it object-oriented.

As well, terminals have additional capabilities, like setting the
baudrate, changing the interrupt character, etc. And, in the  same
vein, they added an ioctl() system call, which sensibly returns an
error code (ENOTTY) if the thing receiving the command is not a TTY.

Same thing for pipes, except now another object-oriented feature comes
into the mix: Constructors. Once created, a pipe does not have any
interesting extra capabilities, indeed it acts like a base class of
files and terminals since it does not support lseek() OR ioctl(),
however the interesting thing is that pipes (ignoring named pipes) are
not created with open(), they have their own constructor function
pipe().

The BSD sockets interface is nice because it exactly follows the same
philosophy: Sockets are like terminals except that instead of ioctl()
they have slightly different capabilities (setting buffer size,
checking for out-of-band data, etc), and they also have some
interesting new characteristics like being bidirectional. But the most
interesting thing with sockets is the elaborate set of
constructors/factories for them.

Now, along comes Plan 9 and what do they do? Completely reverse all
this and force everyone to go through open() in the filesystem, which
is NOT object-oriented, can you imagine C++ without constructors? And,
in my understanding at least (it's a while since I looked at this),
you do things like opening sockets by echoing strings to various
places in the filesystem. This is nice if you're shell scripting.

To explain why I think this is a bad thing I'm going to digress
slightly. Let's consider the AT command set for modems. Well it's nice
because it's human readable, and it was also a decent engineering
solution to a problem where a programmable device was connected
through a dumb terminal interface. Likewise, the ANSI command set for
terminals, pretty much the same thing -- a good idea at the time.

But what I most emphatically DO NOT agree with, is when a modem is
built into the system, and still emulates an AT command set. Or when a
terminal is built into the system (xterm, say), and still emulates an
ANSI command set. It IS nice in some respects: (1) compatibility, and
(2) shell scripting / expect type stuff. But as an engineering
solution it's really bad. It's wasteful since any other program, such
as say a dialer, is encoding the commands into AT commands, and then
they are immediately getting decoded and executed. Same thing with
xterm and the ANSI command sequences. It's nice to be able to put
escape sequences in your prompt to change the colour of your prompt,
but something like the curses library should NOT have to encode
everything into ANSI when it's then decoded immediately.

So, in my humble opinion the best way to handle such issues is, to
provide a programmatic API where you tell the device what you want it
to do, and then if it's something like an xterm or an internal modem,
it immediately does what you ask it to do, whereas if it's something
like an actual ANSI terminal or an external modem, the driver takes
care of encoding your commands into ANSI or AT commands and then
untangling the results, and reports to you in a machine-readable way
(rather than a human-readable way) whether it succeeded etc.

So, my philosophy is quite opposite to the Plan 9 philosophy, and
that's why I don't use Plan 9. I don't believe in trying to put square
pegs in round holes basically. What I would like to see is basically
every device to implement the common functionality like read() and
write() but ONLY IF THAT IS SENSIBLE, and to expose a programmatic
interface through ioctl() or similar. Note that I have actually come
to believe that overloading everything onto ioctl() is a bit
undesirable since ioctl() was originally intended only for terminals.
It would be better if each thing that a user process can hold a "fd"
to, could define its own syscalls, but ioctl() is okay as an
encapsulation for such syscalls.

I also don't really agree with things like the /proc filesystem. For
its intended and original purpose, it's fine -- it was supposed to be
a collection of files named for the pids of running processes in the
system, so that debuggers and such like, could read/write the
process's address space. Personally I think it should have its own
constructor, like say: fd = openaddressspace(pid, O_RDWR); which would
be equivalent to something like: sprintf(buf, "/proc/%d", pid); fd =
open(buf, O_RDWR); since there's no good reason to put it in the
filesystem in my opinion. Having said that, there's no real harm in
putting it in the filesystem, especially as it's hardly ever used.
What I DO NOT agree with, is all the pseudo-files, where you do
something like: echo 1 >/proc/sys/some/silly/function from the shell
to turn stuff on or off.

So now having explained my basic philosophy I will touch on the SCSI
driver and burning CDs/DVDs/BDs. We can look at it two ways, either we
can build a high level interface into the system so that writing
software doesn't need to know how the drive is connected. This is a
bit like my proposal for xterms vs. ANSI terminals and internal vs
external modems. Then if it HAPPENS to be a SCSI drive then the driver
should communicate with the drive in SCSI language, etc. BUT: This is
a huge amount of work, because the SCSI specification is very
complicated. Moreover, it's highly unlikely that any device will be
built in the foreseeable future that burns CDs/DVDs/BDs and does not
understand SCSI. (It might be iSCSI, it might be SCSI encapsulated
into IDE or SATA, or whatever, but it still understands SCSI). In my
opinion then, there is no need for a high level driver. It's like the
situation with ANSI terminals or external models BEFORE things like
xterms or internal modems were ever invented. So why would you need an
extra level of abstraction? Just provide access to the TTY.

cheers, Nick

On Wed, Feb 22, 2017 at 8:49 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
>     > From: Larry McVoy
>
>     > The DOS file system, while stupid, was very robust in the face of
>     > crashes
>
> I'm not sure it's so much the file system (in the sense of the on-disk
> format), as how the system _used_ it (although I suppose one could consider
> that part of the FS too).
>
> The duplicated FAT, and the way file sectors are linked using it, is I suppose
> a little more robust than other designs (e.g. the way early Unixes did it,
> with indirect blocks and free lists), but I think a lot of it must have been
> that DOS wrote stuff out quickly (as opposed to e.g. the delayed writes on
> early Unix FS's, etc). That probably appoximated the write-ordering of more
> designed-robust FS's.
>
>         Noel

[TUHS] Mach for i386 / Mt Xinu or other

[Wesley Parish]

Now that brings up another reason why I think Linux won. Most of the early Linux developers were 
educated partly in the MS/PC/DR DOS world. They wanted a Unix, but they had bought IBM PC clones 
with MS DOS and were familiar with the DOS way of doing things.

Linux's disk partitioning is very familiar to anyone who's familiar with the DOS way of disk partitioning. 
BSD's disk partitioning is a culture shock. (I know. I'd gotten used to the DOS way of doing things after 
learning about disk partitioning with my 486 and IBM OS/2 - the hard way. I tried Linux and the 
terminology was the same and due to a neat trick with the DOS filesystem I could experiment with it on 
an unchanged DOS system. I then tried FreeBSD and I didn't understand the terminology. So I stuck with 
what I'd learnt.)

FWLIW :)

Wesley Parish

Quoting Larry McVoy <lm at mcvoy.com>:

> On Tue, Feb 21, 2017 at 03:28:13PM -0500, Steve Nickolas wrote:
> > On Tue, 21 Feb 2017, Larry McVoy wrote:
> > 
> > >In terms of crash worthyness, ext2 was better. I think the ext2
> people
> > >took the approach that they wanted to be as robust as dos but with
> > >performance. And they made it, it's some very nice work.
> > 
> > Wouldn't "as robust as DOS" be a *bad* thing?
> 
> The DOS file system, while stupid, was very robust in the face of
> crashes
> (sort of had to be, he says slyly).
>  



"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

[Noel Chiappa]

    > From: Larry McVoy

    > The DOS file system, while stupid, was very robust in the face of
    > crashes

I'm not sure it's so much the file system (in the sense of the on-disk
format), as how the system _used_ it (although I suppose one could consider
that part of the FS too).

The duplicated FAT, and the way file sectors are linked using it, is I suppose
a little more robust than other designs (e.g. the way early Unixes did it,
with indirect blocks and free lists), but I think a lot of it must have been
that DOS wrote stuff out quickly (as opposed to e.g. the delayed writes on
early Unix FS's, etc). That probably appoximated the write-ordering of more
designed-robust FS's.

	Noel

[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

[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 03:28:13PM -0500, Steve Nickolas wrote:
> On Tue, 21 Feb 2017, Larry McVoy wrote:
> 
> >In terms of crash worthyness, ext2 was better.  I think the ext2 people
> >took the approach that they wanted to be as robust as dos but with
> >performance.  And they made it, it's some very nice work.
> 
> Wouldn't "as robust as DOS" be a *bad* thing?

The DOS file system, while stupid, was very robust in the face of crashes
(sort of had to be, he says slyly).

[TUHS] Mach for i386 / Mt Xinu or other

[Steve Nickolas]

On Tue, 21 Feb 2017, Larry McVoy wrote:

> In terms of crash worthyness, ext2 was better.  I think the ext2 people
> took the approach that they wanted to be as robust as dos but with
> performance.  And they made it, it's some very nice work.

Wouldn't "as robust as DOS" be a *bad* thing?

-uso.

[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: 2217 bytes --]

On Tue, Feb 21, 2017 at 2:21 PM, Larry McVoy <lm at mcvoy.com> wrote:

> In terms of crash worthyness, ext2 was better.  I think the ext2 people
> took the approach that they wanted to be as robust as dos but with
> performance.  And they made it, it's some very nice work.
>
​Fair enough - It never seems from the outside a much different and when I
was working with it, it was just enough different that all of the tools
(like BSD backup/restore) broke.​

Having personally worked on fsck v6/v7 at CMU and Kirk reimplementing it
with BSD, I had a fairly strong sense of "keep the tools" working.  I
actually hated SysV's FSDB, but could use it.   Kirk and Sam reimplemented
dump/restore but kept the "script" level interface pretty much as is.

So, here come linux and the only part of file kits that still works is part
of the user space stuff (ls, tar, cp).   But beyond that it is all
different.   Ted/Steve eventually did do a fsck-like thing for ext2 fairly
quickly, but nothing else - so that was part of my comment about
"gratuitous changes."  Why because by 1991 when linux comes into my house,
I have a set of other UNIX systems at home running and here it is I have to
have different tools for this new linux box.   grumble...



>
> Nope.  And I sort of made my name working on FFS with srk, I'm a fan of
> what FFS/UFS could do but ext2 went way way further.
>
​Fair enough...​




> And did so pretty
> quickly, far more quickly than any of the Unix shops would have done,
> they were more cautious.
>
​Agreed, although I always thought megasafe (advfs) was pretty cool and
have had fairly good experiences with XFS after SGI let it out to other
folks (still run it on my linux based NAS box truth known) .  As I said, my
main complaint against ext2 was when I first encountered it none of the BSD
FS tools worked and that ticked me off.



​

>
> The linux kids were like the young guys you got straight out of school
> and told them to do the impossible.  Once in a while, they did.
>
​Ok, I'll accept that.  ​

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170221/ecaed4ce/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

[Larry McVoy]

On Tue, Feb 21, 2017 at 01:58:40PM -0500, Clem Cole wrote:
> For instance, I personally don't think ext[234] are much better that
> BFFS/UFS[12], certainly compared to MegaSafe (aka AdvFS) or XFS.   

So I was also at SGI, I know the whole XFS (and XLV) team, and I know
the code pretty well, I plugged it into NFS so that NFS could use
all that bandwidth:

http://www.mcvoy.com/lm/bitmover/lm/talks/bds.pdf

In terms of crash worthyness, ext2 was better.  I think the ext2 people
took the approach that they wanted to be as robust as dos but with 
performance.  And they made it, it's some very nice work.

> got to write his own, which was cool for a young guy at the time.  To me,
> it would have made a lot more sense because BSD was freely licensed to just
> grab the BFFS to replace Minux FS and run with it.

Nope.  And I sort of made my name working on FFS with srk, I'm a fan of
what FFS/UFS could do but ext2 went way way further.  And did so pretty
quickly, far more quickly than any of the Unix shops would have done,
they were more cautious.

The linux kids were like the young guys you got straight out of school
and told them to do the impossible.  Once in a while, they did.

> That said, Linus got along with enough folks at it worked.   

Sort of.  i think a far bigger deal was that he commanded respect,
there were lots of stories floating around like when people sent him
patches he knew the code well enough that an context diff was enough
context that he'd see a bug in the patch, edit the patch, and apply it.
I've seen him do that, he's a programmer's programmer.  Unlike a lot
of leaders who lead but when they have to get their hands dirty they 
are sort of wussy.

[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: 4819 bytes --]

comments below, before I start, I will say - "hear, hear" - I agree with
Larry on this way more than I disagree.

On Tue, Feb 21, 2017 at 11:47 AM, Larry McVoy <lm at mcvoy.com> wrote:

>
> http://www.mcvoy.com/lm/bitmover/lm/papers/srcos.html
>
> is worth a read,

​Indeed - I agreed then and still do.​  I was trying to do the same thing
at OSF.   But we were working the same ideas.




> I was very much in the middle of all this at the time.
>
Indeed, I can verify that ;-)​




>
> I think Linux succeeded because:
>
>     - it was free

​I agree...​




> and GPLed.  BSD license is nice but it has the problem
>       that people can take it closed source and not give back changes.
>
​This is where we disagree and probably always have on this point, but
that's topic for a beer sometime which I definitely want to have!
​

>
>     - no lawsuit
>
​100% agree, to be that was the most important point after the
acquisition cost.
​

>
>     - Linus (as mentioned, much stronger leader than any in the Unix world)
>
​Mumble - maybe.   Like you, I've know the players.  Linus' ego is​ not
better or worse than any of the rest of them, although I admit some of the
UNIX players got really nasty.  Sadly, the old "he who has the gold, rules"
game held true [a dragon's curse maybe].  The best I ever saw were folks
that never really wanted it.  Dennis and Vic (as Doug said), were quiet
leaders.   Linus was better at the beginning, but he really did not listen
well either.   There was a lot of reinventing going on, with little true
advantage other than said person was able to say they did it.

For instance, I personally don't think ext[234] are much better that
BFFS/UFS[12], certainly compared to MegaSafe (aka AdvFS) or XFS.   But Ted
got to write his own, which was cool for a young guy at the time.  To me,
it would have made a lot more sense because BSD was freely licensed to just
grab the BFFS to replace Minux FS and run with it.

But Linus was not that type of leader,  I also think he is a very smart
guy, but was blind to a lot of the things on outside of his world.  He
admits he did not know about 386BSD when he started.

That said, Linus got along with enough folks at it worked.   If, Linus has
had say, Theo's or some of other personalities of the day, maybe he would
have ticked off more people early on and you might be right.   So
personally >>helped<< here but I don't think it was as important as being
at the right place, when the law suit came about a lot of scared hackers
like me looking for an alternative for the 386.




>
>     - no religion.  I can't make this point hard enough.

​I'ld change that a little.  It started with less religion, it now is as
contentions, if not worse than the UNIX Wars of the day.   The difference
is when is started it did not have the economic impact of the "big UNIX/big
Iron" so it was irgnored.   That's Christiansen disruption -- a worse
technology is ignored by the big guys.​




> ​      ​
> At Sun, we couldn't
>       change any API, any utility, it was compat to the point that it was
> not
>       useful.

​I get it and I will grant this to a point.​



> ​      ​
> Look at SVr4/Solaris /proc and then look at Linux /proc.  The
>       Linux one is way, way, way, way more useful, you can dig shit out
> with
>       shell scripts.  The rest of the Unix world was blindly posix compat
>       even when posix compat made no sense.  Linux was glorious in that
>       Linus wanted compat but was willing to break it for good reasons.
>
​Yep, a clean sheet can help when you are lucky enough to be able to ignore
the past.  But Linux got started and it's toe hold because it did not
ignore the past.  It was the POSIX nature that allowed us to consider it.
What you are saying is that UNIX dogma, got in the way.  Again, we let
traditional "Harvard Business School -H-BS" thinking set up sustaining
thinking, and could not see it was killing the golden goose.​




>
>     - good enough
>
​Amen brother... I really think this is the key point.   It was good
enough, and worked on a the WINTEL economic disruption.   Yup is was not
"as good" but it was good enough, and with *BSD
being tainted by the USL/BSDi legal actions, folks like you, me and folks
on this list not only said " we can fix that", that did it and filled in
what was missing.

​

>
>     - fun, all the cool kids were there.

​All amend that to say, many of the cool kids ran over there because the
pool was not being "peed in" by all the other messes we just discussed.

Anyway - as I said, I agree way more than I disagree.
Well said Larry!!
Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170221/2424ba36/attachment-0001.html>

[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: 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

[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

[Larry McVoy]

On Tue, Feb 21, 2017 at 07:02:18AM -0500, Noel Chiappa wrote:
> So there is a question here, though, and I'm curious to see what others who
> were closer to the action think. Why _did_ Linux succeed, and not a Unix
> derivative? (Is there any work which looks at this question? Some Linux
> history? If not, there should be.)

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

is worth a read, I was very much in the middle of all this at the time.

I think Linux succeeded because:

    - it was free and GPLed.  BSD license is nice but it has the problem
      that people can take it closed source and not give back changes.

    - no lawsuit

    - Linus (as mentioned, much stronger leader than any in the Unix world)

    - no religion.  I can't make this point hard enough.  At Sun, we couldn't
      change any API, any utility, it was compat to the point that it was not
      useful.  Look at SVr4/Solaris /proc and then look at Linux /proc.  The
      Linux one is way, way, way, way more useful, you can dig shit out with
      shell scripts.  The rest of the Unix world was blindly posix compat
      even when posix compat made no sense.  Linux was glorious in that 
      Linus wanted compat but was willing to break it for good reasons.

    - good enough

    - fun, all the cool kids were there.

Here is perhaps something that will resonate with this crowd.  When I was
teaching OS at Stanford, for file systems I made people go through the
thought process on when you write what (think the sync writes so the FS
isn't busted when you crash).

For years, the BSD guys insisted that Linux was doing it wrong because
they didn't do the sync writes, they did ordered writes (but the BSD
guys didn't understand the write ordering so they thought it was busted,
as did I).  

But Linux wasn't busted, they had carefully gone through the process
of figuring out when stuff had to be first so that you could survive
a crash.

The BSD guys refused to believe that it was possible, they were stuck
on writes had to be synchronous in order to get a file system that 
wasn't corrupted on a crash.

I eventually started convincing them that Linux had it right by saying
just untar some big tarball and unplug the power in the middle of that
on a system with UFS and a system with ext2.  Tell me what happens when
you power it up.  Answer?  The UFS based system dropped you into a fsck
nightmare of unattached inodes, the ext2 based systems lost some data
but the file system was fine.

Obviously, the Linux approach won, it's better.  Way better, higher 
performance and a much better user experience.  But the traditional
Unix guys had to be dragged kicking and screaming, over a decade, 
into that world.  It's stuff like that that made Unix stagnate while
Linux forged ahead.

[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

[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

[Noel Chiappa]

    > From: Diomidis Spinelli

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

Well, it depends on exactly what you mean by "networking system calls". If
you mean networking a la BSD, perhaps.

However, I can state (from personal experience :-) that the I/O architecture
circa V6/V7 was not very suitable for TCP/IP internetworking (with its
emphasis on an un-reliable network, and smart endpoints). The reason is that
such networking doesn't really fit well into the 'start one I/O operation and
then block the process until it completes' model.

Yes, if you have an application running on top of a reliable stream, you
might be able to coerce that into the 'uni-directional, blocking' I/O model
(if the reliable stream implementation is in, or routed through, the kernel),
but lots of other thing don't work so well. (Think, e.g. an interface with
asynchronous, un-predictable, RPC calls in both directions.)

	Noel

[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

[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

[Chet Ramey]

On 2/21/17 7:02 AM, Noel Chiappa wrote:

> So there is a question here, though, and I'm curious to see what others who
> were closer to the action think. Why _did_ Linux succeed, and not a Unix
> derivative? (Is there any work which looks at this question? Some Linux
> history? If not, there should be.)
> 
> It seems to me that they key battleground must have been the IMB PC-compatible
> world - Linux is where it is now because of its success there. So why did
> Linux succeed there?
> 
> Was is that it was open-source, and the competitor(s) all had licensing
> issues? (I'm not saying they did, I just don't know.) Was it that Linux worked
> better on that platform? (Again, don't know, only asking.)  Perhaps there was
> an early stage where it was the only good option for that platform, and that's
> how it got going?  Was is that there were too many Unix-derived alternatives,
> so there was no clarity as to what the alternatives were?

I was there at the time (bash was the first thing Linus ported to Linux)
and I have to say it was the combination of the availability, since the
BSDs were still encumbered, the accessibility, since its hardware demands
were very modest, and the FSF's enthusiastic porting of all the GNU apps
to it. It was the perfect student/starting system for the time.  You can
talk about lost opportunities, but it was the right system at the time,
and I say this as a BSD guy from way back.

Chet
-- 
``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: 3176 bytes --]

On Tue, Feb 21, 2017 at 7:02 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

> So there is a question here, though, and I'm curious to see what others who
> were closer to the action think. Why _did_ Linux succeed, and not a Unix
> derivative? (Is there any work which looks at this question? Some Linux
> history? If not, there should be.)
>


​I​'ve thought and written a bit about this question a bit [
Would it be possible/advantageous to rewrite the Linux kernel in Rust when
the language is stable?
<https://www.quora.com/Would-it-be-possible-advantageous-to-rewrite-the-Linux-kernel-in-Rust-when-the-language-is-stable>
 &
 Why did Unix succeed and not Multics
<https://www.quora.com/Why-did-Unix-succeed-and-not-Multics> ] ​
​
and I'll not repeat all of here but
​as one of the people that did switch from 386BSD to linux at the time, the
reason for me was purely because of the AT&T/BSDi case.    You are right, I
wanted a "free" (i.e. very inexpensive) UNIX for the 386 and the "big
guns"​ were not going to give it.   I thought we had it the 386 port BSD
which I had helped in a small way to create.

​But I like, most hackers of the day, misunderstood incorrectly​ the case
to be about *trade secret *and the all based around the 1956 consent
decree, IBM vs AT&T; telephones and the computers. I was worried AT&T would
win because it was going to hard to cleaim that that the BSD code was not a
derivative work of the AT&T *copyright code base *(not understanding the *trade
secret*  and the  *copyright* difference mattered).

So...I switched to Linux *not because I thought it was "better"* - in fact,
I b*tched (and still do) about many gratuitous differences, but as I knew
that we needed something for "consumer" HW (which was bring driven by the
WINTEL economics), and I was willing to use the "lessor" technology (Linux)
because it was "good enough" and gave me what I needed (UNIX on a PC/386).
I thought (incorrectly) somehow original Linux's European authorship was
going to protect me and my fellow hackers ever though it was not as good as
my beloved BSD system.

Simple put - using Christiansen's theories:  Linux "won" because:

   - it was "good enough",
   - had a lot of people behind it that valued that was there and invested
   in making it "better", and
   - the economics of the platform (PC/386 - WINTEL etc) was on the fastest
   grow curve [and its Christiansen's economic disruption was displacing the
   Mini & Workstation].


BTW: at the time, I argued with the Roger Gourd and the OSF folks, that if
they released (sold) the OSF/1 RI uK which had not AT&T technology in it
(again thinking Copyright not Trade Secret); I was suggesting $100/copy
there was a market for it.  I just could not get them interested.

Sun has done the RoadRunner and had their 386 port of Solaris; but again.
All the "UNIX" folks were still interested in pushing out "iron" so were
blind to the WINTEL economic disruption.

Woulda, Coulda, Shoulda .... sigh

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

[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

[Michael Kjörling]

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

On 21 Feb 2017 13:24 +0100, from steffen at sdaoden.eu (Steffen Nurpmeso):
> And it has grown a very, very large codebase.  Just yesterday:
> 
>   ?0[steffen at wales ]$ sysctl hw.ncpu
>   sysctl: cannot stat /proc/sys/hw/ncpu: No such file or directory

Not sure what you meant to show by that...


> About, i don't know, 16 or so
> years later?, Linux is still free software, and

The Linux kernel was originally released in September 1991 (and was
Torvald's way of learning about the 80386). 0.12 was the first GPL'd
version, released in February 1992; and 1.0 was released in March
1994. So we are just about 23 years past Linux kernel 1.0.

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

[Steffen Nurpmeso]

jnc at mercury.lcs.mit.edu (Noel Chiappa) wrote:
 |So there is a question here, though, and I'm curious to see what others who
 |were closer to the action think. Why _did_ Linux succeed, and not a Unix
 |derivative? (Is there any work which looks at this question? Some Linux
 |history? If not, there should be.)

Likely this can at least in parts be explained with human
behaviour and social movement.  It was new, it was fresh, the
early postings of Linus Torvalds give a clear impression that he
wants to get out and rise and get this thing done.  His thing was
completely baggage-free (means something, just listen [1]) and
everybody was welcome to take part and make this something
one can be prowd of.  Or nearby that.
And it has grown a very, very large codebase.  Just yesterday:

  ?0[steffen at wales ]$ sysctl hw.ncpu
  sysctl: cannot stat /proc/sys/hw/ncpu: No such file or directory

Then again i wildly guess and find this is to be a GNU problem.
And: you don't have to write a good documentation, or any at all.
I will _never_ forget once i came from SUSE, then RedHat and
Halloween Linux to FreeBSD the first time, with all that grown
infrastructure, also that in /usr/share/doc and /usr/share/misc,
that was nothing but an enlightenment to me.  Plan9 i didn't know
at all until three or so years ago, there you also have nice
documentation (and if you include doc.cat-v.org).

You are a student, you have no girl friend, you don't have much
money, saturday nights are long and boring, and there you can get
something really great going, can be creative and get some
self-fulfilment, and communicate with others all over the world
which all pull together.  That is pretty cool -- and the result
really was, too, even before IBM and such spent billions of
dollars to improve it even further.  About, i don't know, 16 or so
years later?, Linux is still free software, and it has not be torn
in pieces due to all the interests: i think that really is a great
achievement, and likely that the person Linus Torvalds is not
innocent at it.

  [1] https://www.youtube.com/watch?v=45OhGdzcEFk

--steffen

[TUHS] Mach for i386 / Mt Xinu or other

[Noel Chiappa]

    > From: Joerg Schilling

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

Well, I wasn't there, and I don't know much about the early Linux versus
UNIX-derivative contest, but from personal experience in a similar contest
(the TCP/IP versus ISO stack), I doubt such personal attributes had _that_
much weight in deciding the winner.

The maximum might have been that it enabled him to keep the Linux kernel
project unified and heading in one direction. Not inconsiderable, perhaps, if
there's confusion on the other side.,,

So there is a question here, though, and I'm curious to see what others who
were closer to the action think. Why _did_ Linux succeed, and not a Unix
derivative? (Is there any work which looks at this question? Some Linux
history? If not, there should be.)

It seems to me that they key battleground must have been the IMB PC-compatible
world - Linux is where it is now because of its success there. So why did
Linux succeed there?

Was is that it was open-source, and the competitor(s) all had licensing
issues? (I'm not saying they did, I just don't know.) Was it that Linux worked
better on that platform? (Again, don't know, only asking.)  Perhaps there was
an early stage where it was the only good option for that platform, and that's
how it got going?  Was is that there were too many Unix-derived alternatives,
so there was no clarity as to what the alternatives were?

Some combination of all of the above (perhaps with different ones playing a key
role at different points in time)?

     Noel

[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

[Doug McIlroy]

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

No comment about Linus, but Vic Vyssotsky is my pick for the title.
He created the first dataflow language (in 1960!). He invented 
bit-parallel flow analysis and put it into Fortran 2 years later.
He was one of the technical triumvirs for Multics. Ran several
big development groups at Bell Labs, and was 2 levels up from
the Unix team in Research. I could go on and on. What he
didn't do was publish; he got ahead on pure innate ability
and brilliant insight--a profound influence on almost all]
the original Unix crowd.

Doug

[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

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

[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: 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]

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

[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

[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

[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

[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] 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

[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

[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

[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

[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

[Jason Stevens]

Wow that'd be incredible!!!

I'd love to see how Mach 2.5/4.3BSD compared to the Mach 3.0/Lites 1.1 that
is as close as I've been able to find... I know about the NeXT stuff, as I
have NS 3.3 installed although running it on 'white' hardware gets harder
and harder as PC's get newer and the IDE controllers just are too feature
ful, and too new for NS to deal with, beyond it can only use 2GB disks
properly.  Obviously with no source or any way to get in to write drivers or
update the FFS on NeXTSTEP it's basically stuck in those P1 era machines, or
emulation.  There is even previous a 68030/68040 cube based emulator for
running all the 'native' versions.

archive what you can, I can only contribute minro things I stubmle uppon,
mostly by accident.

> ----------
> From: 	Atindra Chaturvedi
> Reply To: 	Atindra Chaturvedi
> Sent: 	Friday, February 17, 2017 11:47 PM
> To: 	jsteve at superglobalmegacorp.com; tuhs at minnie.tuhs.org
> Subject: 	Re: [TUHS] Mach for i386 / Mt Xinu or other
> 
> Amazing - brings back memories. I was a Unix "enterprise IT user" not a
> "kernel developer guru" back in the day working at a pharmaceutical
> company and was responsible for moving the company off IBM 3090 and SNA to
> Unix and TCP/IP.
> 
> Used to buy the new Unix-like releases as they were available to stay
> current - including the Mt. Xinu Mach 386 distro. I still have it and will
> happily send it to the archives - if I can be guided a bit.
> 
> Ran the Mt. Xinu for many years as my home machine - it is pre-SCSI for
> booting ( needs ESDI disks ) but was very stable. So will need tweaking to
> boot/install. 
> 
> Happy to have worked in the mid-70 - 80's era when there were huge changes
> in computer hardware and software technology. I have my books and the
> software for all the cool stuff as it came out in those days - some day I
> will compile it and send it to where it can be better used or archived as
> history.
> 
> Atindra.
> 
> 
> 
> 	-----Original Message----- 
> 	From: jsteve at superglobalmegacorp.com 
> 	Sent: Feb 17, 2017 6:30 AM 
> 	To: "tuhs at minnie.tuhs.org" 
> 	Subject: [TUHS] Mach for i386 / Mt Xinu or other 
> 
> 
> 
> 	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!
> 
> 

[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

[Clem Cole]

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

On Fri, Feb 17, 2017 at 11:55 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>
>
> Please do! And everyone else, please emulate! (I'm already doing my bit!
> :-)p
>

​Indeed - many, many thanks!!!!

Clem​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170217/422d9417/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

[Noel Chiappa]

    > From: Atindra Chaturvedi

    > including the Mt. Xinu Mach 386 distro. I still have it and will happily
    > send it to the archives

Oh, that's fantastic. It's so important that everyone who has these chunk of
computing history make sure they make it into repositories!

    > I have my books and the software for all the cool stuff as it came out
    > in those days - some day I will compile it and send it to where it can
    > be better used or archived as history.

Please do! And everyone else, please emulate! (I'm already doing my bit! :-)p

       Noel

[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

[Atindra Chaturvedi]

An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170217/02f3998b/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: 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

[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

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