* [TUHS] Mushi and Bagu @ 2017-02-16 7:28 Rudi Blom 2017-02-16 9:36 ` jsteve 0 siblings, 1 reply; 50+ messages in thread From: Rudi Blom @ 2017-02-16 7:28 UTC (permalink / raw) Tonal languages are real fun. I'm living and working in Bangkok, Thailand and slightly tone deaf am still struggling. Which reminds me, regarding binary there are 10 types of people, those who understand and those who don't :-) Cheers, rudi ^ permalink raw reply [flat|nested] 50+ messages in thread
* [TUHS] Mushi and Bagu 2017-02-16 7:28 [TUHS] Mushi and Bagu Rudi Blom @ 2017-02-16 9:36 ` jsteve 2017-02-16 10:42 ` Nick Downing 0 siblings, 1 reply; 50+ messages in thread From: jsteve @ 2017-02-16 9:36 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 797 bytes --] Try Cantonese… 9 tones, or 10, or 12. Nobody agrees on how many which makes it all the more fun. The more I learn, the more I don’t know it just adds in more confusion. I never realized I was tondeaf until I moved to Hong Kong. Sent from Mail for Windows 10 From: Rudi Blom Sent: Friday, 17 February 2017 3:43 PM To: tuhs at minnie.tuhs.org Subject: Re: [TUHS] Mushi and Bagu Tonal languages are real fun. I'm living and working in Bangkok, Thailand and slightly tone deaf am still struggling. Which reminds me, regarding binary there are 10 types of people, those who understand and those who don't :-) Cheers, rudi -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170216/9c3c2259/attachment.html> ^ permalink raw reply [flat|nested] 50+ messages in thread
* [TUHS] Mushi and Bagu 2017-02-16 9:36 ` jsteve @ 2017-02-16 10:42 ` Nick Downing 2017-02-16 13:49 ` Rudi Blom 0 siblings, 1 reply; 50+ messages in thread From: Nick Downing @ 2017-02-16 10:42 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1916 bytes --] I don't think Westerners are actually tone deaf as such. It's basically that we didn't exercise our ability to tell those tones apart when we were acquiring language, so we more or less lost the opportunity to learn it when we could. Although it can be learnt later, something that happens as a very natural process during language aquisition, becomes a very artificial process involving MONTHS or YEARS in the lab listening to tapes and testing oneself and so on. Acquiring tones is somewhat similar to having perfect pitch in music. There are courses out there that claim to teach you perfect pitch. And, I believe it CAN be learnt, but it is an extraordinary amount of work and will probably slide backwards if not maintained. Anyway, I still find the phenomenon really strange and intriguing. My wife is Vietnamese and I was at her relatives' house just tonight. I spoke a little Vietnamese to her aunt and she didn't understand me at all (as usual). It's because what sounds to us identical, sounds to her like a completely different word -- so much so, that her brain doesn't even register any similarity. cheers, Nick PS OT sorry. On Thu, Feb 16, 2017 at 8:36 PM, <jsteve at superglobalmegacorp.com> wrote: > Try Cantonese… 9 tones, or 10, or 12. Nobody agrees on how many which makes > it all the more fun. The more I learn, the more I don’t know it just adds > in more confusion. > > > > I never realized I was tondeaf until I moved to Hong Kong. > > > > Sent from Mail for Windows 10 > > > > From: Rudi Blom > Sent: Friday, 17 February 2017 3:43 PM > To: tuhs at minnie.tuhs.org > Subject: Re: [TUHS] Mushi and Bagu > > > > Tonal languages are real fun. I'm living and working in Bangkok, > > Thailand and slightly tone deaf am still struggling. > > > > Which reminds me, regarding binary there are 10 types of people, those > > who understand and those who don't :-) > > > > Cheers, > > rudi > > ^ permalink raw reply [flat|nested] 50+ messages in thread
* [TUHS] Mushi and Bagu 2017-02-16 10:42 ` Nick Downing @ 2017-02-16 13:49 ` Rudi Blom 2017-02-17 11:30 ` [TUHS] Mach for i386 / Mt Xinu or other jsteve 0 siblings, 1 reply; 50+ messages in thread From: Rudi Blom @ 2017-02-16 13:49 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 2279 bytes --] The advantage of Thai is that it's character based so at least I can see the difference easily and try to replicate. Pronouncing correctly and hearing correctly is a different kettle of fish all together though. On 16/02/2017, Nick Downing <downing.nick at gmail.com> wrote: > I don't think Westerners are actually tone deaf as such. It's > basically that we didn't exercise our ability to tell those tones > apart when we were acquiring language, so we more or less lost the > opportunity to learn it when we could. Although it can be learnt > later, something that happens as a very natural process during > language aquisition, becomes a very artificial process involving > MONTHS or YEARS in the lab listening to tapes and testing oneself and > so on. Acquiring tones is somewhat similar to having perfect pitch in > music. There are courses out there that claim to teach you perfect > pitch. And, I believe it CAN be learnt, but it is an extraordinary > amount of work and will probably slide backwards if not maintained. > Anyway, I still find the phenomenon really strange and intriguing. My > wife is Vietnamese and I was at her relatives' house just tonight. I > spoke a little Vietnamese to her aunt and she didn't understand me at > all (as usual). It's because what sounds to us identical, sounds to > her like a completely different word -- so much so, that her brain > doesn't even register any similarity. > cheers, Nick > PS OT sorry. > > On Thu, Feb 16, 2017 at 8:36 PM, <jsteve at superglobalmegacorp.com> wrote: >> Try Cantonese… 9 tones, or 10, or 12. Nobody agrees on how many which >> makes >> it all the more fun. The more I learn, the more I don’t know it just >> adds >> in more confusion. >> >> >> >> I never realized I was tondeaf until I moved to Hong Kong. >> >> >> >> Sent from Mail for Windows 10 >> >> >> >> From: Rudi Blom >> Sent: Friday, 17 February 2017 3:43 PM >> To: tuhs at minnie.tuhs.org >> Subject: Re: [TUHS] Mushi and Bagu >> >> >> >> Tonal languages are real fun. I'm living and working in Bangkok, >> >> Thailand and slightly tone deaf am still struggling. >> >> >> >> Which reminds me, regarding binary there are 10 types of people, those >> >> who understand and those who don't :-) >> >> >> >> Cheers, >> >> rudi >> >> > ^ permalink raw reply [flat|nested] 50+ messages in thread
* [TUHS] Mach for i386 / Mt Xinu or other 2017-02-16 13:49 ` Rudi Blom @ 2017-02-17 11:30 ` jsteve 2017-02-17 14:22 ` Clem Cole 2017-02-17 14:29 ` Clem Cole 0 siblings, 2 replies; 50+ messages in thread From: jsteve @ 2017-02-17 11:30 UTC (permalink / raw) [-- 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> ^ permalink raw reply [flat|nested] 50+ messages in thread
* [TUHS] Mach for i386 / Mt Xinu or other 2017-02-17 11:30 ` [TUHS] Mach for i386 / Mt Xinu or other jsteve @ 2017-02-17 14:22 ` Clem Cole 2017-02-17 16:13 ` Chet Ramey 2017-02-17 14:29 ` Clem Cole 1 sibling, 1 reply; 50+ messages in thread From: Clem Cole @ 2017-02-17 14:22 UTC (permalink / raw) [-- 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> ^ permalink raw reply [flat|nested] 50+ messages in thread
* [TUHS] Mach for i386 / Mt Xinu or other 2017-02-17 14:22 ` Clem Cole @ 2017-02-17 16:13 ` Chet Ramey 0 siblings, 0 replies; 50+ messages in thread From: Chet Ramey @ 2017-02-17 16:13 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 50+ messages in thread
* [TUHS] Mach for i386 / Mt Xinu or other 2017-02-17 11:30 ` [TUHS] Mach for i386 / Mt Xinu or other jsteve 2017-02-17 14:22 ` Clem Cole @ 2017-02-17 14:29 ` Clem Cole 2017-02-17 17:23 ` Warner Losh 2017-02-18 22:25 ` Nemo 1 sibling, 2 replies; 50+ messages in thread From: Clem Cole @ 2017-02-17 14:29 UTC (permalink / raw) [-- 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> ^ permalink raw reply [flat|nested] 50+ messages in thread
* [TUHS] Mach for i386 / Mt Xinu or other 2017-02-17 14:29 ` Clem Cole @ 2017-02-17 17:23 ` Warner Losh 2017-02-18 22:25 ` Nemo 1 sibling, 0 replies; 50+ messages in thread From: Warner Losh @ 2017-02-17 17:23 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* [TUHS] Mach for i386 / Mt Xinu or other 2017-02-17 14:29 ` Clem Cole 2017-02-17 17:23 ` Warner Losh @ 2017-02-18 22:25 ` Nemo 2017-02-19 6:20 ` jsteve 1 sibling, 1 reply; 50+ messages in thread From: Nemo @ 2017-02-18 22:25 UTC (permalink / raw) 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 > ^ permalink raw reply [flat|nested] 50+ messages in thread
* [TUHS] Mach for i386 / Mt Xinu or other 2017-02-18 22:25 ` Nemo @ 2017-02-19 6:20 ` jsteve 2017-02-19 7:01 ` Steve Nickolas ` (2 more replies) 0 siblings, 3 replies; 50+ messages in thread From: jsteve @ 2017-02-19 6:20 UTC (permalink / raw) [-- 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> ^ permalink raw reply [flat|nested] 50+ messages in thread
* [TUHS] Mach for i386 / Mt Xinu or other 2017-02-19 6:20 ` jsteve @ 2017-02-19 7:01 ` Steve Nickolas 2017-02-19 13:46 ` Jason Stevens 2017-02-19 21:19 ` Clem Cole 2017-02-19 22:59 ` Derek Fawcus 2 siblings, 1 reply; 50+ messages in thread From: Steve Nickolas @ 2017-02-19 7:01 UTC (permalink / raw) [-- 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. ^ permalink raw reply [flat|nested] 50+ messages in thread
* [TUHS] Mach for i386 / Mt Xinu or other 2017-02-19 7:01 ` Steve Nickolas @ 2017-02-19 13:46 ` Jason Stevens 2017-02-19 15:44 ` Larry McVoy 0 siblings, 1 reply; 50+ messages in thread From: Jason Stevens @ 2017-02-19 13:46 UTC (permalink / raw) [-- 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> ^ permalink raw reply [flat|nested] 50+ messages in thread
* [TUHS] Mach for i386 / Mt Xinu or other 2017-02-19 13:46 ` Jason Stevens @ 2017-02-19 15:44 ` Larry McVoy 2017-02-20 18:14 ` Joerg Schilling 0 siblings, 1 reply; 50+ messages in thread From: Larry McVoy @ 2017-02-19 15:44 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 50+ messages in thread
* [TUHS] Mach for i386 / Mt Xinu or other 2017-02-19 15:44 ` Larry McVoy @ 2017-02-20 18:14 ` Joerg Schilling 2017-02-20 22:24 ` Larry McVoy 0 siblings, 1 reply; 50+ messages in thread From: Joerg Schilling @ 2017-02-20 18:14 UTC (permalink / raw) [-- 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/ ^ permalink raw reply [flat|nested] 50+ messages in thread
* [TUHS] Mach for i386 / Mt Xinu or other 2017-02-20 18:14 ` Joerg Schilling @ 2017-02-20 22:24 ` Larry McVoy 2017-02-20 23:16 ` Steve Johnson 2017-02-21 10:30 ` Joerg Schilling 0 siblings, 2 replies; 50+ messages in thread From: Larry McVoy @ 2017-02-20 22:24 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 50+ messages in thread
* [TUHS] Mach for i386 / Mt Xinu or other 2017-02-20 22:24 ` Larry McVoy @ 2017-02-20 23:16 ` Steve Johnson 2017-02-20 23:18 ` Larry McVoy 2017-02-20 23:20 ` Steve Nickolas 2017-02-21 10:30 ` Joerg Schilling 1 sibling, 2 replies; 50+ messages in thread From: Steve Johnson @ 2017-02-20 23:16 UTC (permalink / raw) [-- 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> ^ permalink raw reply [flat|nested] 50+ messages in thread
* [TUHS] Mach for i386 / Mt Xinu or other 2017-02-20 23:16 ` Steve Johnson @ 2017-02-20 23:18 ` Larry McVoy 2017-02-20 23:25 ` Steve Johnson 2017-02-20 23:20 ` Steve Nickolas 1 sibling, 1 reply; 50+ messages in thread From: Larry McVoy @ 2017-02-20 23:18 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* [TUHS] Mach for i386 / Mt Xinu or other 2017-02-20 23:18 ` Larry McVoy @ 2017-02-20 23:25 ` Steve Johnson 0 siblings, 0 replies; 50+ messages in thread From: Steve Johnson @ 2017-02-20 23:25 UTC (permalink / raw) [-- 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> ^ permalink raw reply [flat|nested] 50+ messages in thread
* [TUHS] Mach for i386 / Mt Xinu or other 2017-02-20 23:16 ` Steve Johnson 2017-02-20 23:18 ` Larry McVoy @ 2017-02-20 23:20 ` Steve Nickolas 2017-02-21 0:12 ` Wesley Parish 1 sibling, 1 reply; 50+ messages in thread From: Steve Nickolas @ 2017-02-20 23:20 UTC (permalink / raw) [-- 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. ^ permalink raw reply [flat|nested] 50+ messages in thread
* [TUHS] Mach for i386 / Mt Xinu or other 2017-02-20 23:20 ` Steve Nickolas @ 2017-02-21 0:12 ` Wesley Parish 2017-02-21 1:05 ` Steve Nickolas 0 siblings, 1 reply; 50+ messages in thread From: Wesley Parish @ 2017-02-21 0:12 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* [TUHS] Mach for i386 / Mt Xinu or other 2017-02-21 0:12 ` Wesley Parish @ 2017-02-21 1:05 ` Steve Nickolas 0 siblings, 0 replies; 50+ messages in thread From: Steve Nickolas @ 2017-02-21 1:05 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 50+ messages in thread
* [TUHS] Mach for i386 / Mt Xinu or other 2017-02-20 22:24 ` Larry McVoy 2017-02-20 23:16 ` Steve Johnson @ 2017-02-21 10:30 ` Joerg Schilling 2017-02-21 13:47 ` Random832 2017-02-21 21:37 ` Larry McVoy 1 sibling, 2 replies; 50+ messages in thread From: Joerg Schilling @ 2017-02-21 10:30 UTC (permalink / raw) [-- 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/ ^ permalink raw reply [flat|nested] 50+ messages in thread
* [TUHS] Mach for i386 / Mt Xinu or other 2017-02-21 10:30 ` Joerg Schilling @ 2017-02-21 13:47 ` Random832 2017-02-21 15:18 ` Joerg Schilling 2017-02-21 21:37 ` Larry McVoy 1 sibling, 1 reply; 50+ messages in thread From: Random832 @ 2017-02-21 13:47 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 50+ messages in thread
* [TUHS] Mach for i386 / Mt Xinu or other 2017-02-21 13:47 ` Random832 @ 2017-02-21 15:18 ` Joerg Schilling 2017-02-21 15:54 ` Diomidis Spinellis 2017-02-21 16:32 ` Random832 0 siblings, 2 replies; 50+ messages in thread From: Joerg Schilling @ 2017-02-21 15:18 UTC (permalink / raw) [-- 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/ ^ permalink raw reply [flat|nested] 50+ messages in thread
* [TUHS] Mach for i386 / Mt Xinu or other 2017-02-21 15:18 ` Joerg Schilling @ 2017-02-21 15:54 ` Diomidis Spinellis 2017-02-21 16:38 ` Cory Smelosky 2017-02-21 16:48 ` Joerg Schilling 2017-02-21 16:32 ` Random832 1 sibling, 2 replies; 50+ messages in thread From: Diomidis Spinellis @ 2017-02-21 15:54 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* [TUHS] Mach for i386 / Mt Xinu or other 2017-02-21 15:54 ` Diomidis Spinellis @ 2017-02-21 16:38 ` Cory Smelosky 2017-02-21 16:48 ` Joerg Schilling 1 sibling, 0 replies; 50+ messages in thread From: Cory Smelosky @ 2017-02-21 16:38 UTC (permalink / raw) 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 > ^ permalink raw reply [flat|nested] 50+ messages in thread
* [TUHS] Mach for i386 / Mt Xinu or other 2017-02-21 15:54 ` Diomidis Spinellis 2017-02-21 16:38 ` Cory Smelosky @ 2017-02-21 16:48 ` Joerg Schilling 1 sibling, 0 replies; 50+ messages in thread From: Joerg Schilling @ 2017-02-21 16:48 UTC (permalink / raw) [-- 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/ ^ permalink raw reply [flat|nested] 50+ messages in thread
* [TUHS] Mach for i386 / Mt Xinu or other 2017-02-21 15:18 ` Joerg Schilling 2017-02-21 15:54 ` Diomidis Spinellis @ 2017-02-21 16:32 ` Random832 2017-02-21 16:55 ` Joerg Schilling 1 sibling, 1 reply; 50+ messages in thread From: Random832 @ 2017-02-21 16:32 UTC (permalink / raw) 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"? ^ permalink raw reply [flat|nested] 50+ messages in thread
* [TUHS] Mach for i386 / Mt Xinu or other 2017-02-21 16:32 ` Random832 @ 2017-02-21 16:55 ` Joerg Schilling 2017-02-21 17:10 ` Dan Cross 0 siblings, 1 reply; 50+ messages in thread From: Joerg Schilling @ 2017-02-21 16:55 UTC (permalink / raw) [-- 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/ ^ permalink raw reply [flat|nested] 50+ messages in thread
* [TUHS] Mach for i386 / Mt Xinu or other 2017-02-21 16:55 ` Joerg Schilling @ 2017-02-21 17:10 ` Dan Cross 2017-02-21 19:44 ` Joerg Schilling 0 siblings, 1 reply; 50+ messages in thread From: Dan Cross @ 2017-02-21 17:10 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 50+ messages in thread
* [TUHS] Mach for i386 / Mt Xinu or other 2017-02-21 17:10 ` Dan Cross @ 2017-02-21 19:44 ` Joerg Schilling 2017-02-21 21:17 ` Dan Cross 0 siblings, 1 reply; 50+ messages in thread From: Joerg Schilling @ 2017-02-21 19:44 UTC (permalink / raw) [-- 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/ ^ permalink raw reply [flat|nested] 50+ messages in thread
* [TUHS] Mach for i386 / Mt Xinu or other 2017-02-21 19:44 ` Joerg Schilling @ 2017-02-21 21:17 ` Dan Cross 0 siblings, 0 replies; 50+ messages in thread From: Dan Cross @ 2017-02-21 21:17 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 50+ messages in thread
* [TUHS] Mach for i386 / Mt Xinu or other 2017-02-21 10:30 ` Joerg Schilling 2017-02-21 13:47 ` Random832 @ 2017-02-21 21:37 ` Larry McVoy 2017-02-22 8:57 ` jsteve 1 sibling, 1 reply; 50+ messages in thread From: Larry McVoy @ 2017-02-21 21:37 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 50+ messages in thread
* [TUHS] Mach for i386 / Mt Xinu or other 2017-02-21 21:37 ` Larry McVoy @ 2017-02-22 8:57 ` jsteve 2017-02-22 9:56 ` Michael Kjörling 2017-02-22 10:29 ` Joerg Schilling 0 siblings, 2 replies; 50+ messages in thread From: jsteve @ 2017-02-22 8:57 UTC (permalink / raw) [-- 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> ^ permalink raw reply [flat|nested] 50+ messages in thread
* [TUHS] Mach for i386 / Mt Xinu or other 2017-02-22 8:57 ` jsteve @ 2017-02-22 9:56 ` Michael Kjörling 2017-02-22 10:26 ` jsteve 2017-02-22 10:29 ` Joerg Schilling 1 sibling, 1 reply; 50+ messages in thread From: Michael Kjörling @ 2017-02-22 9:56 UTC (permalink / raw) [-- 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) ^ permalink raw reply [flat|nested] 50+ messages in thread
* [TUHS] Mach for i386 / Mt Xinu or other 2017-02-22 9:56 ` Michael Kjörling @ 2017-02-22 10:26 ` jsteve 0 siblings, 0 replies; 50+ messages in thread From: jsteve @ 2017-02-22 10:26 UTC (permalink / raw) [-- 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> ^ permalink raw reply [flat|nested] 50+ messages in thread
* [TUHS] Mach for i386 / Mt Xinu or other 2017-02-22 8:57 ` jsteve 2017-02-22 9:56 ` Michael Kjörling @ 2017-02-22 10:29 ` Joerg Schilling 1 sibling, 0 replies; 50+ messages in thread From: Joerg Schilling @ 2017-02-22 10:29 UTC (permalink / raw) [-- 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/ ^ permalink raw reply [flat|nested] 50+ messages in thread
* [TUHS] Mach for i386 / Mt Xinu or other 2017-02-19 6:20 ` jsteve 2017-02-19 7:01 ` Steve Nickolas @ 2017-02-19 21:19 ` Clem Cole 2017-02-20 0:29 ` Nick Downing 2017-02-20 1:29 ` Cory Smelosky 2017-02-19 22:59 ` Derek Fawcus 2 siblings, 2 replies; 50+ messages in thread From: Clem Cole @ 2017-02-19 21:19 UTC (permalink / raw) [-- 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> ^ permalink raw reply [flat|nested] 50+ messages in thread
* [TUHS] Mach for i386 / Mt Xinu or other 2017-02-19 21:19 ` Clem Cole @ 2017-02-20 0:29 ` Nick Downing 2017-02-20 1:58 ` Clem Cole 2017-02-20 1:29 ` Cory Smelosky 1 sibling, 1 reply; 50+ messages in thread From: Nick Downing @ 2017-02-20 0:29 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* [TUHS] Mach for i386 / Mt Xinu or other 2017-02-20 0:29 ` Nick Downing @ 2017-02-20 1:58 ` Clem Cole 0 siblings, 0 replies; 50+ messages in thread From: Clem Cole @ 2017-02-20 1:58 UTC (permalink / raw) [-- 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> ^ permalink raw reply [flat|nested] 50+ messages in thread
* [TUHS] Mach for i386 / Mt Xinu or other 2017-02-19 21:19 ` Clem Cole 2017-02-20 0:29 ` Nick Downing @ 2017-02-20 1:29 ` Cory Smelosky 1 sibling, 0 replies; 50+ messages in thread From: Cory Smelosky @ 2017-02-20 1:29 UTC (permalink / raw) [-- 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> ^ permalink raw reply [flat|nested] 50+ messages in thread
* [TUHS] Mach for i386 / Mt Xinu or other 2017-02-19 6:20 ` jsteve 2017-02-19 7:01 ` Steve Nickolas 2017-02-19 21:19 ` Clem Cole @ 2017-02-19 22:59 ` Derek Fawcus 2 siblings, 0 replies; 50+ messages in thread From: Derek Fawcus @ 2017-02-19 22:59 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* [TUHS] Mushi and Bagu @ 2017-02-15 15:30 Noel Chiappa 2017-02-15 16:13 ` Nick Downing 0 siblings, 1 reply; 50+ messages in thread From: Noel Chiappa @ 2017-02-15 15:30 UTC (permalink / raw) > From: Larry McVoy > Are you sure? Someone else said moshi was hi and mushi was bug. Does > mushi have two meanings? Yes: http://www.nihongodict.com/?s=mushi Actually, more than two! Japanese is chock-a-block with homonyms. Any given Japanese word will probably have more than one meaning. There's some story I don't quite recall about a recent Prime Minister who made a mistake of this sort - although now that I think about it, it was probably the _other_ kind of replication, which is that a given set of kanji (ideograms) usually has more than one pronunciation. (I won't go into why, see here: http://mercury.lcs.mit.edu/~jnc/prints/glossary.html#Reading for more.) So he was reading a speech, and gave the wrong reading for a word. There is apparently a book (or more) in Japanese, for the Japanese, that lists the common ones that cause confusion. A very complicated language! The written form is equally complicated; there are two syllabaries ('hiragana' and 'katakana'), and for the kanji, there are several completely different written forms! Noel ^ permalink raw reply [flat|nested] 50+ messages in thread
* [TUHS] Mushi and Bagu 2017-02-15 15:30 [TUHS] Mushi and Bagu Noel Chiappa @ 2017-02-15 16:13 ` Nick Downing 2017-02-15 18:16 ` Nemo 0 siblings, 1 reply; 50+ messages in thread From: Nick Downing @ 2017-02-15 16:13 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 3297 bytes --] Yes, I just looked it up too. http://jisho.org/search/むし States that mushi means "insect" and "the act of ignoring". (In Japanese some verbs are nouns and used with the word "suru" meaning "do"). http://jisho.org/search/ばぐ States that "bagu" means computer bug/error. That's also my recollection as they use loan words for most of these technical things. However, Japanese is NOT a complicated language. The spoken language is very simple. The grammar and sound system are basically like English but cut down and streamlined. It has a few unique features like "wa" but many of the particles like "o" and "ga" have direct translations. Where Japanese is harder to learn is the politeness levels of which there are basically 4: rude, normal, polite and ultra polite. In ultra polite there is a different vocabulary so that common actions such as seeing, going, eating etc have to use a different word, however most ultra polite language and basically all of the rude and polite language may be derived systematically from the normal. We do this in English but less rigorously. The other main thing is the writing system, well Japanese view it as a beautiful thing and highly cultured but it's not. It's actually the world's clunkiest writing system, in the 50s the Japanese government seriously tried to get rid of it and replace with Latin letters like many other sensible countries have done, and if they'd succeeded then learning Japanese would be no more difficult than say Tagalog (Filipino) or Bahasa (Indonesian/Malay). The reason they did not succeed is the many homonyms resulting from Japanese's very limited sound system (about 50 syllables compared with hundreds for English and thousands for Chinese or Vietnamese) which makes Japanese a bit confusing/slow to read when written phonetically. Note English also uses a similar system to disambiguate homonyms. cheers, Nick On Feb 16, 2017 2:30 AM, "Noel Chiappa" <jnc at mercury.lcs.mit.edu> wrote: > > From: Larry McVoy > > > Are you sure? Someone else said moshi was hi and mushi was bug. Does > > mushi have two meanings? > > Yes: > > http://www.nihongodict.com/?s=mushi > > Actually, more than two! Japanese is chock-a-block with homonyms. Any > given Japanese word will probably have more than one meaning. > > There's some story I don't quite recall about a recent Prime Minister who > made a mistake of this sort - although now that I think about it, it was > probably the _other_ kind of replication, which is that a given set of > kanji > (ideograms) usually has more than one pronunciation. (I won't go into why, > see here: > > http://mercury.lcs.mit.edu/~jnc/prints/glossary.html#Reading > > for more.) So he was reading a speech, and gave the wrong reading for a > word. > There is apparently a book (or more) in Japanese, for the Japanese, that > lists > the common ones that cause confusion. > > A very complicated language! The written form is equally complicated; there > are two syllabaries ('hiragana' and 'katakana'), and for the kanji, there > are > several completely different written forms! > > Noel > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170216/49bdf86b/attachment-0001.html> ^ permalink raw reply [flat|nested] 50+ messages in thread
* [TUHS] Mushi and Bagu 2017-02-15 16:13 ` Nick Downing @ 2017-02-15 18:16 ` Nemo 0 siblings, 0 replies; 50+ messages in thread From: Nemo @ 2017-02-15 18:16 UTC (permalink / raw) On 15 February 2017 at 11:13, Nick Downing <downing.nick at gmail.com> wrote: > Yes, I just looked it up too. I know no Japanese but I could not improve on Noel's and Nick's answers. My Japanese colleague was born in Japan and obtained his computer-engineering degrees from Japanese universities so I would defer to him. (He has lived here a few decades but married a Japanese woman and they send their kid to a special Japanese school for ex-patriats on the weekend.) N. ^ permalink raw reply [flat|nested] 50+ messages in thread
* [TUHS] Mushi and Bagu @ 2017-02-15 14:51 Nemo 2017-02-15 15:01 ` Larry McVoy 0 siblings, 1 reply; 50+ messages in thread From: Nemo @ 2017-02-15 14:51 UTC (permalink / raw) Follow-up to Larry's "Mushi! Mushi!" story (http://minnie.tuhs.org/pipermail/tuhs/2017-February/008149.html). I showed this to a Japanese acquaintance, who found it hilarious for a different reason. He told me that a s/w bug is "bagu" -- a semi-transliteration -- and "mushi" is "I ignore you". So corporate called, asked for status, and the technical guy said "I am going to ignore you!" and then hung up. N. ^ permalink raw reply [flat|nested] 50+ messages in thread
* [TUHS] Mushi and Bagu 2017-02-15 14:51 Nemo @ 2017-02-15 15:01 ` Larry McVoy 2017-02-15 15:04 ` John Floren 2017-02-15 15:27 ` Steve Nickolas 0 siblings, 2 replies; 50+ messages in thread From: Larry McVoy @ 2017-02-15 15:01 UTC (permalink / raw) On Wed, Feb 15, 2017 at 09:51:58AM -0500, Nemo wrote: > Follow-up to Larry's "Mushi! Mushi!" story > (http://minnie.tuhs.org/pipermail/tuhs/2017-February/008149.html). > > I showed this to a Japanese acquaintance, who found it hilarious for a > different reason. He told me that a s/w bug is "bagu" -- a > semi-transliteration -- and "mushi" is "I ignore you". So corporate > called, asked for status, and the technical guy said "I am going to > ignore you!" and then hung up. Wow, that's even better than "Bug, bug!". Are you sure? Someone else said moshi was hi and mushi was bug. Does mushi have two meanings? ^ permalink raw reply [flat|nested] 50+ messages in thread
* [TUHS] Mushi and Bagu 2017-02-15 15:01 ` Larry McVoy @ 2017-02-15 15:04 ` John Floren 2017-02-15 15:27 ` Steve Nickolas 1 sibling, 0 replies; 50+ messages in thread From: John Floren @ 2017-02-15 15:04 UTC (permalink / raw) When I studied Japanese in high school, our teacher told us mushi is bug. Bagu is a literal transliteration that may be more common in actual use, but mushi certainly means bug. On Feb 15, 2017 08:01, "Larry McVoy" <lm at mcvoy.com> wrote: > On Wed, Feb 15, 2017 at 09:51:58AM -0500, Nemo wrote: > > Follow-up to Larry's "Mushi! Mushi!" story > > (http://minnie.tuhs.org/pipermail/tuhs/2017-February/008149.html). > > > > I showed this to a Japanese acquaintance, who found it hilarious for a > > different reason. He told me that a s/w bug is "bagu" -- a > > semi-transliteration -- and "mushi" is "I ignore you". So corporate > > called, asked for status, and the technical guy said "I am going to > > ignore you!" and then hung up. > > Wow, that's even better than "Bug, bug!". Are you sure? Someone else > said moshi was hi and mushi was bug. Does mushi have two meanings? > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170215/5fd4c16e/attachment.html> ^ permalink raw reply [flat|nested] 50+ messages in thread
* [TUHS] Mushi and Bagu 2017-02-15 15:01 ` Larry McVoy 2017-02-15 15:04 ` John Floren @ 2017-02-15 15:27 ` Steve Nickolas 1 sibling, 0 replies; 50+ messages in thread From: Steve Nickolas @ 2017-02-15 15:27 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 872 bytes --] On Wed, 15 Feb 2017, Larry McVoy wrote: > On Wed, Feb 15, 2017 at 09:51:58AM -0500, Nemo wrote: >> Follow-up to Larry's "Mushi! Mushi!" story >> (http://minnie.tuhs.org/pipermail/tuhs/2017-February/008149.html). >> >> I showed this to a Japanese acquaintance, who found it hilarious for a >> different reason. He told me that a s/w bug is "bagu" -- a >> semi-transliteration -- and "mushi" is "I ignore you". So corporate >> called, asked for status, and the technical guy said "I am going to >> ignore you!" and then hung up. > > Wow, that's even better than "Bug, bug!". Are you sure? Someone else > said moshi was hi and mushi was bug. Does mushi have two meanings? > If you can believe this the Japanese version of "Pok��mon" occasionally puns on the dual meaning of "mushi" - ��ϟoҕ ("mushi wa mushi", more or less, "the bugs don't bug me"). -uso. ^ permalink raw reply [flat|nested] 50+ messages in thread
end of thread, other threads:[~2017-02-22 10:29 UTC | newest] Thread overview: 50+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-02-16 7:28 [TUHS] Mushi and Bagu Rudi Blom 2017-02-16 9:36 ` jsteve 2017-02-16 10:42 ` Nick Downing 2017-02-16 13:49 ` Rudi Blom 2017-02-17 11:30 ` [TUHS] Mach for i386 / Mt Xinu or other jsteve 2017-02-17 14:22 ` Clem Cole 2017-02-17 16:13 ` Chet Ramey 2017-02-17 14:29 ` Clem Cole 2017-02-17 17:23 ` Warner Losh 2017-02-18 22:25 ` Nemo 2017-02-19 6:20 ` jsteve 2017-02-19 7:01 ` Steve Nickolas 2017-02-19 13:46 ` Jason Stevens 2017-02-19 15:44 ` Larry McVoy 2017-02-20 18:14 ` Joerg Schilling 2017-02-20 22:24 ` Larry McVoy 2017-02-20 23:16 ` Steve Johnson 2017-02-20 23:18 ` Larry McVoy 2017-02-20 23:25 ` Steve Johnson 2017-02-20 23:20 ` Steve Nickolas 2017-02-21 0:12 ` Wesley Parish 2017-02-21 1:05 ` Steve Nickolas 2017-02-21 10:30 ` Joerg Schilling 2017-02-21 13:47 ` Random832 2017-02-21 15:18 ` Joerg Schilling 2017-02-21 15:54 ` Diomidis Spinellis 2017-02-21 16:38 ` Cory Smelosky 2017-02-21 16:48 ` Joerg Schilling 2017-02-21 16:32 ` Random832 2017-02-21 16:55 ` Joerg Schilling 2017-02-21 17:10 ` Dan Cross 2017-02-21 19:44 ` Joerg Schilling 2017-02-21 21:17 ` Dan Cross 2017-02-21 21:37 ` Larry McVoy 2017-02-22 8:57 ` jsteve 2017-02-22 9:56 ` Michael Kjörling 2017-02-22 10:26 ` jsteve 2017-02-22 10:29 ` Joerg Schilling 2017-02-19 21:19 ` Clem Cole 2017-02-20 0:29 ` Nick Downing 2017-02-20 1:58 ` Clem Cole 2017-02-20 1:29 ` Cory Smelosky 2017-02-19 22:59 ` Derek Fawcus -- strict thread matches above, loose matches on Subject: below -- 2017-02-15 15:30 [TUHS] Mushi and Bagu Noel Chiappa 2017-02-15 16:13 ` Nick Downing 2017-02-15 18:16 ` Nemo 2017-02-15 14:51 Nemo 2017-02-15 15:01 ` Larry McVoy 2017-02-15 15:04 ` John Floren 2017-02-15 15:27 ` Steve Nickolas
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).