I don't think Westerners are actually tone deaf as such. It's basically that we didn't exercise our ability to tell those tones apart when we were acquiring language, so we more or less lost the opportunity to learn it when we could. Although it can be learnt later, something that happens as a very natural process during language aquisition, becomes a very artificial process involving MONTHS or YEARS in the lab listening to tapes and testing oneself and so on. Acquiring tones is somewhat similar to having perfect pitch in music. There are courses out there that claim to teach you perfect pitch. And, I believe it CAN be learnt, but it is an extraordinary amount of work and will probably slide backwards if not maintained. Anyway, I still find the phenomenon really strange and intriguing. My wife is Vietnamese and I was at her relatives' house just tonight. I spoke a little Vietnamese to her aunt and she didn't understand me at all (as usual). It's because what sounds to us identical, sounds to her like a completely different word -- so much so, that her brain doesn't even register any similarity. cheers, Nick PS OT sorry. On Thu, Feb 16, 2017 at 8:36 PM, <jsteve(a)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: &lt;1364(a)mtxinu.UUCP&gt; Date: 2 Oct 90 17:12:19 GMT Reply-To: scherrer(a)mtxinu.COM (Deborah Scherrer) Organization: mt Xinu, Berkeley 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!

On 2/17/17 9:22 AM, Clem Cole wrote: Filtered through NeXT. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet(a)case.edu http://cnswww.cns.cwru.edu/~chet/

On Fri, Feb 17, 2017 at 7:29 AM, Clem Cole &lt;clemc(a)ccc.com&gt; wrote: 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

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(a)minnie.tuhs.org Subject: Re: [TUHS] Mach for i386 / Mt Xinu or other On 17 February 2017 at 09:29, Clem Cole &lt;clemc(a)ccc.com&gt; wrote: [...] Hhhmmm... this was thrashed out last month, starting at http://minnie.tuhs.org/pipermail/tuhs/2017-January/007608.html #6-)

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 &lt;usotsuki(a)buric.co&gt; wrote: -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

Larry McVoy &lt;lm(a)mcvoy.com&gt; wrote: 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@schily.net (home) Jörg Schilling D-13353 Berlin joerg.schilling(a)fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

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" &lt;lm(a)mcvoy.com&gt; To:"Joerg Schilling" &lt;schily(a)schily.net&gt; Cc:<tuhs@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: architect, since. did never all is part 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.

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" &lt;lm(a)mcvoy.com&gt; To:"Steve Johnson" &lt;scj(a)yaccman.com&gt; Cc:"Larry McVoy" &lt;lm(a)mcvoy.com&gt;, "Joerg Schilling" &lt;schily(a)schily.net&gt;, &lt;tuhs(a)minnie.tuhs.org&gt; 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: and quite disaster.?? that Linux etc.?? can't -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm

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 &lt;usotsuki(a)buric.co&gt;: <snip> "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

Larry McVoy &lt;lm(a)mcvoy.com&gt; wrote: 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. 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@schily.net (home) Jörg Schilling D-13353 Berlin joerg.schilling(a)fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

Random832 &lt;random832(a)fastmail.com&gt; wrote: The filesystem specific kernel include files are broken on many linux distributions. 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. SCSI bus numbers are part of the SCSI CAM Standard for SCSI addressing, you are badly informed a second time. Jörg -- EMail:joerg@schily.net (home) Jörg Schilling D-13353 Berlin joerg.schilling(a)fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

Diomidis Spinellis wrote: 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)

On Tue, Feb 21, 2017, at 10:18, Joerg Schilling 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. 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"?

On Feb 21, 2017 11:55 AM, "Joerg Schilling" &lt;schily(a)schily.net&gt; wrote: Random832 &lt;random832(a)fastmail.com&gt; wrote: 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 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.

On Tue, Feb 21, 2017 at 2:44 PM, Joerg Schilling &lt;schily(a)schily.net&gt; wrote: People who only have a hammer tend to believe that all problems are nails. I think you entirely missed the point of this discussion. I've noticed this follows something of a pattern. *shrug* - Dan C.

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(a)mcvoy.com; tuhs(a)minnie.tuhs.org; jsteve(a)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: Linus attacks anyone who he thinks is misguided. He's been wrong but he's usually right. 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. 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.

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(a)minnie.tuhs.org Subject: Re: [TUHS] Mach for i386 / Mt Xinu or other On 22 Feb 2017 16:57 +0800, from jsteve(a)superglobalmegacorp.com: 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(a)kjorling.se “People who think they know everything really annoy those of us who know we don’t.” (Bjarne Stroustrup)

On Sun, Feb 19, 2017 at 1:20 AM, &lt;jsteve(a)superglobalmegacorp.com&gt; wrote: ​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

On Sun, Feb 19, 2017 at 7:29 PM, Nick Downing &lt;downing.nick(a)gmail.com&gt; wrote: ​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

On Sun, Feb 19, 2017 at 02:20:15p.m. +0800, jsteve(a)superglobalmegacorp.com wrote: 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