* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') @ 2014-06-02 2:09 Doug McIlroy 2014-06-02 2:24 ` John Cowan ` (2 more replies) 0 siblings, 3 replies; 56+ messages in thread From: Doug McIlroy @ 2014-06-02 2:09 UTC (permalink / raw) Phil Garcia wrote: I've always wondered about something else, though: Were the original Unix authors annoyed when they learned that some irascible young upstart named Richard Stallman was determined to make a free Unix clone? Was he a gadfly, or just some kook you decided to ignore? The fathers of Unix have been strangely silent on this topic for many years. Maybe nobody's ever asked? Gnu was always taken as a compliment. And of course the Unix clone was pie in the sky until Linus came along. I wonder about the power relationship underlying "GNU/Linux", as rms modestly styles it. There are certain differences in taste between Unix and Gnu, vide emacs and texinfo. (I grit my teeth every time a man page tells me, "The full documentation for ___ is maintained as a Texinfo file.") But all disagreement is swept away before the fact that the old familiar environment is everywhere, from Cray to Apple, with rms a very important contributor. Doug ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-02 2:09 [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') Doug McIlroy @ 2014-06-02 2:24 ` John Cowan 2014-06-02 2:59 ` Warner Losh 2014-06-02 12:04 ` Clem Cole 2 siblings, 0 replies; 56+ messages in thread From: John Cowan @ 2014-06-02 2:24 UTC (permalink / raw) Doug McIlroy scripsit: > But all disagreement is swept away before the fact that the old > familiar environment is everywhere, from Cray to Apple, with rms > a very important contributor. Amen. My checkered career has taken me from Eunice to Microsoft Xenix System III to Solaris to BSD386 to Linux (native and CoLinux) to Cygwin, and except when playing a sysadmin I have never had to know or care which flavor of the Grand Ole OSry I was using that year. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org Assent may be registered by a signature, a handshake, or a click of a computer mouse transmitted across the invisible ether of the Internet. Formality is not a requisite; any sign, symbol or action, or even willful inaction, as long as it is unequivocally referable to the promise, may create a contract. --Specht v. Netscape ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-02 2:09 [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') Doug McIlroy 2014-06-02 2:24 ` John Cowan @ 2014-06-02 2:59 ` Warner Losh 2014-06-02 3:17 ` Greg 'groggy' Lehey ` (2 more replies) 2014-06-02 12:04 ` Clem Cole 2 siblings, 3 replies; 56+ messages in thread From: Warner Losh @ 2014-06-02 2:59 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1930 bytes --] On Jun 1, 2014, at 8:09 PM, Doug McIlroy <doug at cs.dartmouth.edu> wrote: > Phil Garcia wrote: > I've always wondered about something > else, though: Were the original Unix authors annoyed when they learned that > some irascible young upstart named Richard Stallman was determined to make > a free Unix clone? Was he a gadfly, or just some kook you decided to > ignore? The fathers of Unix have been strangely silent on this topic for > many years. Maybe nobody's ever asked? In private moments, some of the BSD old-timers have told me they are silent due to bad blood that Stallman’s early fund-raising and propaganda efforts created. Why rehash 20 year old battles with an obvious nutcase, eh? Since more than one person has told me this, so I think silence is a wide-spread case of “If you can’t say anything nice, say nothing at all." > Gnu was always taken as a compliment. And of course the Unix clone > was pie in the sky until Linus came along. I wonder about the power > relationship underlying "GNU/Linux", as rms modestly styles it. Of course, it should be noted that the GNU project was totally incapable of producing a working kernel… They did decent clones of user land stuff, but Hurd was a total dead end... > There are certain differences in taste between Unix and Gnu, vide > emacs and texinfo. (I grit my teeth every time a man page tells me, > "The full documentation for ___ is maintained as a Texinfo file.") > But all disagreement is swept away before the fact that the old > familiar environment is everywhere, from Cray to Apple, with rms > a very important contributor. Emacs is awesome…. Warner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140601/f1059c8d/attachment.sig> ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-02 2:59 ` Warner Losh @ 2014-06-02 3:17 ` Greg 'groggy' Lehey 2014-06-02 3:37 ` John Cowan 2014-06-02 4:04 ` Nick Downing 2014-06-02 3:18 ` John Cowan 2014-06-02 6:08 ` Steve Nickolas 2 siblings, 2 replies; 56+ messages in thread From: Greg 'groggy' Lehey @ 2014-06-02 3:17 UTC (permalink / raw) On Sunday, 1 June 2014 at 20:59:13 -0600, Warner Losh wrote: > > On Jun 1, 2014, at 8:09 PM, Doug McIlroy <doug at cs.dartmouth.edu> wrote: > >> Phil Garcia wrote: >> I've always wondered about something >> else, though: Were the original Unix authors annoyed when they learned that >> some irascible young upstart named Richard Stallman was determined to make >> a free Unix clone? Was he a gadfly, or just some kook you decided to >> ignore? The fathers of Unix have been strangely silent on this topic for >> many years. Maybe nobody's ever asked? > > In private moments, some of the BSD old-timers have told me they are > silent due to bad blood that Stallman?s early fund-raising and > propaganda efforts created. Why rehash 20 year old battles with an > obvious nutcase, eh? Since more than one person has told me this, so > I think silence is a wide-spread case of ?If you can?t say anything > nice, say nothing at all." But now you've said something, and it's not nice. Clearly this is indicative of the standpoints of the others as well. A lot is simply personality conflict. As you know, I don't share that opinion, and I think the emphasis that FreeBSD places on ridding itself of GNU software is unhealthy. Yes, rms is "unusual", but that goes for a lot of the BSD crowd too. And I know enough people in the Linux space who dislike him as well. >> Gnu was always taken as a compliment. And of course the Unix clone >> was pie in the sky until Linus came along. I wonder about the power >> relationship underlying "GNU/Linux", as rms modestly styles it. > > Of course, it should be noted that the GNU project was totally > incapable of producing a working kernel? They did decent clones of > user land stuff, but Hurd was a total dead end... But if you state that, you need to analyse why. I think the big issue was the grandiose goals that they set. And who knows what might have happened if Linux and the free BSDs hadn't come along? I don't think it's fair to simply dismiss it as a dead end. >> There are certain differences in taste between Unix and Gnu, vide >> emacs and texinfo... > > Emacs is awesome?. Not part of my vocabulary, but I couldn't live without Emacs. Shall we degrade this discussion into a vi/Emacs fight? Greg -- Sent from my desktop computer. Finger grog at FreeBSD.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140602/59ec0160/attachment.sig> ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-02 3:17 ` Greg 'groggy' Lehey @ 2014-06-02 3:37 ` John Cowan 2014-06-02 4:08 ` scj 2014-06-02 5:03 ` Greg 'groggy' Lehey 2014-06-02 4:04 ` Nick Downing 1 sibling, 2 replies; 56+ messages in thread From: John Cowan @ 2014-06-02 3:37 UTC (permalink / raw) Greg 'groggy' Lehey scripsit: > Not part of my vocabulary, but I couldn't live without Emacs. Shall > we degrade this discussion into a vi/Emacs fight? Sure, go ahead. As a firm adherent to "ex", I'll umpire the contest. -- "Well, I'm back." --Sam John Cowan <cowan at ccil.org> ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-02 3:37 ` John Cowan @ 2014-06-02 4:08 ` scj 2014-06-02 5:03 ` Greg 'groggy' Lehey 1 sibling, 0 replies; 56+ messages in thread From: scj @ 2014-06-02 4:08 UTC (permalink / raw) Three comments on Gnu/Unix. The first is that the Unix creators were very ambivalent about the AT&T Lawyers. The legal situation surrounding AT&T licensing software was murky, and the lawyers attitude was often "let's wait 10 years and see what happens in case law...". I spent about six months trying to get the PCC C grammar released to the public domain, with the notion that this would help limit the splintering of the language that was starting to happen pre ANSI C. I couldn't get anywhere with that. The second comment is that, for me personally, the ripping off bothered me less than the complete lack of attribution of the original creators. There were easily two dozen people who contributed some significant code and/or ideas to Unix, but you'd never know it by looking at Gnu. The third comment is that the loss of central control has had its costs. I get a rash looking at the 500-page gcc manual, orders of magnitude larger than the code for pcc. It's hard to steer a sensible course between stagnated central control and chaotic anarchy, but for my taste letting every grad student with a couple of hours of spare time piddle on the code base has not, on the whole, been a good thing.] Steve ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-02 3:37 ` John Cowan 2014-06-02 4:08 ` scj @ 2014-06-02 5:03 ` Greg 'groggy' Lehey 2014-06-02 12:31 ` Ronald Natalie 1 sibling, 1 reply; 56+ messages in thread From: Greg 'groggy' Lehey @ 2014-06-02 5:03 UTC (permalink / raw) On Sunday, 1 June 2014 at 23:37:46 -0400, John Cowan wrote: > Greg 'groggy' Lehey scripsit: > >> Not part of my vocabulary, but I couldn't live without Emacs. Shall >> we degrade this discussion into a vi/Emacs fight? > > Sure, go ahead. As a firm adherent to "ex", I'll umpire the > contest. :-) Greg -- Sent from my desktop computer. Finger grog at FreeBSD.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140602/58bb9036/attachment.sig> ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-02 5:03 ` Greg 'groggy' Lehey @ 2014-06-02 12:31 ` Ronald Natalie 0 siblings, 0 replies; 56+ messages in thread From: Ronald Natalie @ 2014-06-02 12:31 UTC (permalink / raw) Amusingly I never learned VI. I had worked for a group that was beholden to Interactive Systems editor (which I believe was a variant of Yost's Rand Editor) and by the time I left there I was working with various pre-GNU Unix EMACS (Warren Montgomery, JOVE, Gosling). I even worked for Unipress for a very short period as a consultant. To this day if there's no EMACS I juse use ed or ex. It always amazed my coworkers how fast I fly in line editor mode. On Jun 2, 2014, at 1:03 AM, Greg 'groggy' Lehey <grog at lemis.com> wrote: >> >> >>> Not part of my vocabulary, but I couldn't live without Emacs. Shall >>> we degrade this discussion into a vi/Emacs fight? >> >> Sure, go ahead. As a firm adherent to "ex", I'll umpire the >> contest. > > : ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-02 3:17 ` Greg 'groggy' Lehey 2014-06-02 3:37 ` John Cowan @ 2014-06-02 4:04 ` Nick Downing 2014-06-02 4:43 ` John Cowan 1 sibling, 1 reply; 56+ messages in thread From: Nick Downing @ 2014-06-02 4:04 UTC (permalink / raw) Yeah. I think Richard Stallman is a legend (umm if that's too close to "awesome" vocabulary wise then let's say he's an inspiration :) :) ), I totally agree with everything he's done for & on behalf of free software and really it's easy to forget how totally locked out of the unix world I was as a 10yr old MS Basic programming hobbyist or 20yr old MS Basic programming developer, never even used an SCCS until I was nearly 30. My professional life would have been way more productive and satisfying if Stallman had come along much earlier... I knew people who used unix and packet-switched networks such as X.25 but being run for profit by large corporations it was totally out of my price range. I also remember how much I just yearned to have the source code of MS DOS, CP/M, AppleSoft & DOS 3.3, etc, so many unanswered questions that were only partially alleviated by books such as "Undocumented DOS" and "Beneath Apple DOS"... I did eventually get some of those sources or a version of them when it was much too late & was disappointed to see how mediocre they looked from developer's viewpoint... community could have dome much better but were locked out of the process & relegated to writing apps & device drivers that took ages to get working in light of limited technical info. I'll never be in that situation again thanks to Stallman's insights and Torvalds's and everyone else's contribution. I deplore the infighting though and have had bad experiences in trying to offer what little time I could afford to open source projects, now I do not really bother & just use the tools with my own private modifications. I do think Stallman has a point about naming of Linux v. GNU/Linux though. What I do not like about GNU is the "kitchen sink" philosophy of including every little used feature in every utility with longer and longer command line switches and manpages. Bash I guess is an extreme example of this, we do not need a commandline shell that is 1Mb in size!! Another issue I have is the incredibly complex tools such as GCC being written in plain C when some subset of C++ would clearly be more appropriate given their fundamentally object oriented design. This is very laborious, repetitive and wasteful and involves a lot of differing "private solutions" to already-solved problems. Further the build systems are totally broken, I appreciate what automake/autoconf is doing but from a developer point of view they are totally unwieldy and another example of the "kitchen sink" philosophy of supporting every conceivable, and outdated, architecture. Much better solutions exist for these kinds of problems. For these reasons I would likely not work on a GNU project, however I use the tools daily and simply ignore the parts I don't like. If software development were left to me I would be infinitely subroutinized, redesigning the CPU so I could redesign the ISA and then return to redesigning the compiler followed by the OS kernel followed by the C library, the windowing system and the apps hehehe so RMS perceived a need and filled it within a useful timescale and I'm infinitely grateful :) cheers, Nick On 02/06/2014 1:26 PM, "Greg 'groggy' Lehey" <grog at lemis.com> wrote: > On Sunday, 1 June 2014 at 20:59:13 -0600, Warner Losh wrote: > > > > On Jun 1, 2014, at 8:09 PM, Doug McIlroy <doug at cs.dartmouth.edu> wrote: > > > >> Phil Garcia wrote: > >> I've always wondered about something > >> else, though: Were the original Unix authors annoyed when they learned > that > >> some irascible young upstart named Richard Stallman was determined to > make > >> a free Unix clone? Was he a gadfly, or just some kook you decided to > >> ignore? The fathers of Unix have been strangely silent on this topic for > >> many years. Maybe nobody's ever asked? > > > > In private moments, some of the BSD old-timers have told me they are > > silent due to bad blood that Stallman?s early fund-raising and > > propaganda efforts created. Why rehash 20 year old battles with an > > obvious nutcase, eh? Since more than one person has told me this, so > > I think silence is a wide-spread case of ?If you can?t say anything > > nice, say nothing at all." > > But now you've said something, and it's not nice. > > Clearly this is indicative of the standpoints of the others as well. > A lot is simply personality conflict. As you know, I don't share that > opinion, and I think the emphasis that FreeBSD places on ridding > itself of GNU software is unhealthy. Yes, rms is "unusual", but that > goes for a lot of the BSD crowd too. And I know enough people in the > Linux space who dislike him as well. > > >> Gnu was always taken as a compliment. And of course the Unix clone > >> was pie in the sky until Linus came along. I wonder about the power > >> relationship underlying "GNU/Linux", as rms modestly styles it. > > > > Of course, it should be noted that the GNU project was totally > > incapable of producing a working kernel? They did decent clones of > > user land stuff, but Hurd was a total dead end... > > But if you state that, you need to analyse why. I think the big issue > was the grandiose goals that they set. And who knows what might have > happened if Linux and the free BSDs hadn't come along? I don't think > it's fair to simply dismiss it as a dead end. > > >> There are certain differences in taste between Unix and Gnu, vide > >> emacs and texinfo... > > > > Emacs is awesome?. > > Not part of my vocabulary, but I couldn't live without Emacs. Shall > we degrade this discussion into a vi/Emacs fight? > > Greg > -- > Sent from my desktop computer. > Finger grog at FreeBSD.org for PGP public key. > See complete headers for address and phone numbers. > This message is digitally signed. If your Microsoft MUA reports > problems, please read http://tinyurl.com/broken-mua > > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140602/272d52ae/attachment.html> ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-02 4:04 ` Nick Downing @ 2014-06-02 4:43 ` John Cowan 2014-06-02 6:23 ` arnold 0 siblings, 1 reply; 56+ messages in thread From: John Cowan @ 2014-06-02 4:43 UTC (permalink / raw) Nick Downing scripsit: > Bash I guess is an extreme example of this, we do not need a commandline > shell that is 1Mb in size!! Well, some people find it useful. But if you want dash or Unix rc, you know where to find them. > Further the build systems are totally broken, I > appreciate what automake/autoconf is doing but from a developer point of > view they are totally unwieldy and another example of the "kitchen sink" > philosophy of supporting every conceivable, and outdated, architecture. Indeed. I rather like the Chicken Scheme approach: there is a Makefile fragment for each supported architecture, currently BSD, Solaris, Android, AIX, Haiku, iOS, MinGW with or without MSYS, Cygwin, Hurd, MacOSX, and Linux. If you want anything else, provide your own Makefile fragment. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org Eric Raymond is the Margaret Mead of the Open Source movement. --Bruce Perens, a long time ago ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-02 4:43 ` John Cowan @ 2014-06-02 6:23 ` arnold 2014-06-02 17:35 ` John Cowan 0 siblings, 1 reply; 56+ messages in thread From: arnold @ 2014-06-02 6:23 UTC (permalink / raw) John Cowan <cowan at mercury.ccil.org> wrote: > Indeed. I rather like the Chicken Scheme approach: there is a Makefile > fragment for each supported architecture, currently BSD, Solaris, Android, > AIX, Haiku, iOS, MinGW with or without MSYS, Cygwin, Hurd, MacOSX, > and Linux. If you want anything else, provide your own Makefile fragment. This is only possible because of the standardization efforts at the C and POSIX levels. Remember that Autoconf/Automake were invented to solve the issue of all the forks: SunOS / Solaris / HP-UX / Ultrix / MIPS / Pryamid / DG-UX / ad nauseum. Lots of things that were almost but not quite entirely like V7 or System V Unix. Today many of those players are no longer around, AND standardization of header files and libraries means that C code is *more* portable than it was in 1992. So there's less need for those tools *now*, but that doesn't mean they didn't solve a real problem when they first came along. I'll agree on most of the GNU complaints (and I'm a GNU developer...); the original Unix "Small Is Beautiful" baby has been thrown out along with the proprietary licensing bath water. Sigh. (Boy, was that a great use for an old cliche, or what? :-) Thanks, Arnold ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-02 6:23 ` arnold @ 2014-06-02 17:35 ` John Cowan 2014-06-02 18:44 ` Warner Losh 0 siblings, 1 reply; 56+ messages in thread From: John Cowan @ 2014-06-02 17:35 UTC (permalink / raw) arnold at skeeve.com scripsit: > This is only possible because of the standardization efforts at the > C and POSIX levels. Remember that Autoconf/Automake were invented to > solve the issue of all the forks: SunOS / Solaris / HP-UX / Ultrix / > MIPS / Pryamid / DG-UX / ad nauseum. Lots of things that were almost but > not quite entirely like V7 or System V Unix. Oh, absolutely. But Autotools themselves are very unstable, so we've apparently replaced spatial variation with longitudinal variation. The Chicken project was undergoing too much churn trying to run correctly with different installed versions of Autotools. So we switched to CMake, but that was even more unstable, and couldn't handle a bootstrapped self-compiler well. So finally we switched to the current scheme of Makefile fragments. Each fragment specifies appropriate cc and ld options, including libraries required, and then writes out a chicken-defaults.h file with a bunch of HAVE_* macros. That's all that's needed. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org That you can cover for the plentiful and often gaping errors, misconstruals and disinformation in your posts through sheer volume -- that is another misconception. --Mike to Peter ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-02 17:35 ` John Cowan @ 2014-06-02 18:44 ` Warner Losh 2014-06-02 18:52 ` John Cowan 0 siblings, 1 reply; 56+ messages in thread From: Warner Losh @ 2014-06-02 18:44 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1534 bytes --] On Jun 2, 2014, at 11:35 AM, John Cowan <cowan at mercury.ccil.org> wrote: > arnold at skeeve.com scripsit: > > >> This is only possible because of the standardization efforts at the >> C and POSIX levels. Remember that Autoconf/Automake were invented to >> solve the issue of all the forks: SunOS / Solaris / HP-UX / Ultrix / >> MIPS / Pryamid / DG-UX / ad nauseum. Lots of things that were almost but >> not quite entirely like V7 or System V Unix. > > Oh, absolutely. But Autotools themselves are very unstable, so we've > apparently replaced spatial variation with longitudinal variation. > The Chicken project was undergoing too much churn trying to run correctly > with different installed versions of Autotools. So we switched to CMake, > but that was even more unstable, and couldn't handle a bootstrapped > self-compiler well. > > So finally we switched to the current scheme of Makefile fragments. > Each fragment specifies appropriate cc and ld options, including libraries > required, and then writes out a chicken-defaults.h file with a bunch of > HAVE_* macros. That's all that's needed. Sounds a bit like imake-uberlite… Or should I not mention imake lest the love-fest for all things evil continue on it. :) Warner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140602/08a4544b/attachment.sig> ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-02 18:44 ` Warner Losh @ 2014-06-02 18:52 ` John Cowan 0 siblings, 0 replies; 56+ messages in thread From: John Cowan @ 2014-06-02 18:52 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 14324 bytes --] Warner Losh scripsit: > Sounds a bit like imake-uberlite… Or should I not mention imake > lest the love-fest for all things evil continue on it. :) Not much like, because there is no configuration tool at all. You just say "make PLATFORM=foo" and it includes Makefile.foo. I've attached a couple of Makefile fragments to this email for easy comparison. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org Principles. You can't say A is made of B or vice versa. All mass is interaction. --Richard Feynman -------------- next part -------------- # Makefile.linux - configuration for Linux -*- Makefile -*- # # Copyright (c) 2008-2014, The Chicken Team # Copyright (c) 2007, Felix L. Winkelmann # All rights reserved. # # Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following # conditions are met: # # Redistributions of source code must retain the above copyright notice, this list of conditions and the following # disclaimer. # Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following # disclaimer in the documentation and/or other materials provided with the distribution. # Neither the name of the author nor the names of its contributors may be used to endorse or promote # products derived from this software without specific prior written permission. # # THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS # OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY # AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR # CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR # CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR # SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY # THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR # OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE # POSSIBILITY OF SUCH DAMAGE. ifneq ($(CONFIG),) include $(CONFIG) endif SRCDIR ?= ./ # platform configuration ARCH ?= $(shell sh $(SRCDIR)/config-arch.sh) # options C_COMPILER_OPTIONS ?= -fno-strict-aliasing -fwrapv -DHAVE_CHICKEN_CONFIG_H ifdef DEBUGBUILD C_COMPILER_OPTIMIZATION_OPTIONS ?= -g -Wall -Wno-unused else ifdef OPTIMIZE_FOR_SPEED C_COMPILER_OPTIMIZATION_OPTIONS ?= -O3 -fomit-frame-pointer else C_COMPILER_OPTIMIZATION_OPTIONS ?= -Os -fomit-frame-pointer endif endif LINKER_LINK_SHARED_LIBRARY_OPTIONS = -shared LINKER_LINK_SHARED_DLOADABLE_OPTIONS = -L. -shared -Wl,-R"$(RUNTIME_LINKER_PATH)" LINKER_LINK_SHARED_PROGRAM_OPTIONS = -Wl,-R"$(RUNTIME_LINKER_PATH)" LIBCHICKEN_SO_LINKER_OPTIONS = -Wl,-soname,lib$(PROGRAM_PREFIX)chicken$(PROGRAM_SUFFIX).so.$(BINARYVERSION) LIBRARIES = -lm -ldl NEEDS_RELINKING = yes USES_SONAME = yes # special files CHICKEN_CONFIG_H = chicken-config.h # select default and internal settings include $(SRCDIR)/defaults.make chicken-config.h: chicken-defaults.h echo "/* GENERATED */" >$@ echo "#define HAVE_DIRENT_H 1" >>$@ echo "#define HAVE_DLFCN_H 1" >>$@ echo "#define HAVE_INTTYPES_H 1" >>$@ echo "#define HAVE_LIMITS_H 1" >>$@ echo "#define HAVE_LONG_LONG 1" >>$@ echo "#define HAVE_MEMMOVE 1" >>$@ echo "#define HAVE_MEMORY_H 1" >>$@ echo "#define HAVE_POSIX_POLL 1" >>$@ echo "#define HAVE_SIGACTION 1" >>$@ echo "#define HAVE_SIGSETJMP 1" >>$@ echo "#define HAVE_SIGPROCMASK 1" >>$@ echo "#define HAVE_STDINT_H 1" >>$@ echo "#define HAVE_STDLIB_H 1" >>$@ echo "#define HAVE_STRERROR 1" >>$@ echo "#define HAVE_STRINGS_H 1" >>$@ echo "#define HAVE_STRING_H 1" >>$@ echo "#define HAVE_STRTOLL 1" >>$@ echo "#define HAVE_STRTOQ 1" >>$@ echo "#define HAVE_SYS_STAT_H 1" >>$@ echo "#define HAVE_SYS_TYPES_H 1" >>$@ echo "#define HAVE_SETENV 1" >>$@ echo "#define HAVE_UNISTD_H 1" >>$@ echo "#define HAVE_UNSIGNED_LONG_LONG 1" >>$@ echo "#define STDC_HEADERS 1" >>$@ echo "#define HAVE_ALLOCA 1" >>$@ echo "#define HAVE_ALLOCA_H 1" >>$@ echo "#define HAVE_GRP_H 1" >>$@ echo "#define HAVE_ERRNO_H 1" >>$@ echo "#define HAVE_SYSEXITS_H 1" >>$@ echo "#define HAVE_MEMMOVE 1" >>$@ echo "#define C_STACK_GROWS_DOWNWARD 1" >>$@ ifdef GCHOOKS echo "#define C_GC_HOOKS" >>$@ endif ifdef SYMBOLGC echo "#define C_COLLECT_ALL_SYMBOLS" >>$@ endif ifneq ($(HACKED_APPLY),) echo "#define C_HACKED_APPLY" >>$@ endif cat chicken-defaults.h >>$@ include $(SRCDIR)/rules.make -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.bsd Type: chemical/x-crossfire Size: 4200 bytes Desc: not available URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140602/6b0fc4e0/attachment.bsd> -------------- next part -------------- # Makefile.solaris - configuration for Solaris -*- Makefile -*- # # Copyright (c) 2008-2014, The Chicken Team # Copyright (c) 2007, Felix L. Winkelmann # All rights reserved. # # Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following # conditions are met: # # Redistributions of source code must retain the above copyright notice, this list of conditions and the following # disclaimer. # Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following # disclaimer in the documentation and/or other materials provided with the distribution. # Neither the name of the author nor the names of its contributors may be used to endorse or promote # products derived from this software without specific prior written permission. # # THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS # OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY # AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR # CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR # CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR # SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY # THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR # OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE # POSSIBILITY OF SUCH DAMAGE. ifneq ($(CONFIG),) include $(CONFIG) endif SRCDIR = ./ # platform configuration ARCH ?= $(shell sh $(SRCDIR)/config-arch.sh) # default to gcc - use "make ... C_COMPILER=cc ..." to use SunPro CC export C_COMPILER ?= gcc export INSTALL_PROGRAM ?= ginstall # options ifeq ($(C_COMPILER),cc) ifneq (,$(filter-out x86 x86-64,$(ARCH))) # -xannotate=no is not supported on x86/x86-64 DISABLE_ANNOTATIONS=-xannotate=no else DISABLE_ANNOTATIONS= endif C_COMPILER_OPTIONS ?= -errtags -xdebugformat=stabs $(DISABLE_ANNOTATIONS) -DHAVE_CHICKEN_CONFIG_H else C_COMPILER_OPTIONS ?= -fno-strict-aliasing -fwrapv -DHAVE_CHICKEN_CONFIG_H endif ifdef DEBUGBUILD ifeq ($(C_COMPILER),cc) C_COMPILER_OPTIMIZATION_OPTIONS ?= -g +w else C_COMPILER_OPTIMIZATION_OPTIONS ?= -g -Wall -Wno-unused endif else ifdef OPTIMIZE_FOR_SPEED ifeq ($(C_COMPILER),cc) C_COMPILER_OPTIMIZATION_OPTIONS += -g -xO4 else C_COMPILER_OPTIMIZATION_OPTIONS ?= -O3 -fomit-frame-pointer endif else ifeq ($(C_COMPILER),cc) C_COMPILER_OPTIMIZATION_OPTIONS += -g -xO3 else C_COMPILER_OPTIMIZATION_OPTIONS ?= -Os -fomit-frame-pointer endif endif endif ifeq ($(C_COMPILER),cc) # Assuming 'cc' means SunW/SunStudio compiler LINKER_LINK_SHARED_LIBRARY_OPTIONS = -G $(DISABLE_ANNOTATIONS) LINKER_LINK_SHARED_DLOADABLE_OPTIONS = -G $(DISABLE_ANNOTATIONS) -R"$(RUNTIME_LINKER_PATH)" -L. LINKER_LINK_SHARED_PROGRAM_OPTIONS = -R"$(RUNTIME_LINKER_PATH)" else LINKER_LINK_SHARED_LIBRARY_OPTIONS = -shared LINKER_LINK_SHARED_DLOADABLE_OPTIONS = -shared -Wl,-R"$(RUNTIME_LINKER_PATH)" -Wl,-L. LINKER_LINK_SHARED_PROGRAM_OPTIONS = -Wl,-R"$(RUNTIME_LINKER_PATH)" endif LIBRARIES = -lsocket -lnsl -lm -ldl -lrt NEEDS_RELINKING = yes USES_SONAME = yes # special files CHICKEN_CONFIG_H = chicken-config.h # select default and internal settings include $(SRCDIR)/defaults.make chicken-config.h: chicken-defaults.h echo "/* END OF FILE */" >$@ echo "#define HAVE_DIRENT_H 1" >>$@ echo "#define HAVE_DLFCN_H 1" >>$@ echo "#define HAVE_INTTYPES_H 1" >>$@ echo "#define HAVE_LIMITS_H 1" >>$@ echo "#define HAVE_LONG_LONG 1" >>$@ echo "#define HAVE_MEMMOVE 1" >>$@ echo "#define HAVE_MEMORY_H 1" >>$@ echo "#define HAVE_POSIX_POLL 1" >>$@ echo "#define HAVE_SIGACTION 1" >>$@ echo "#define HAVE_STDINT_H 1" >>$@ echo "#define HAVE_STDLIB_H 1" >>$@ echo "#define HAVE_STRERROR 1" >>$@ echo "#define HAVE_STRINGS_H 1" >>$@ echo "#define HAVE_STRING_H 1" >>$@ echo "#define HAVE_STRLCAT 1" >>$@ echo "#define HAVE_STRLCPY 1" >>$@ echo "#define HAVE_STRTOLL 1" >>$@ echo "#define HAVE_SYS_STAT_H 1" >>$@ echo "#define HAVE_SYS_TYPES_H 1" >>$@ echo "#define HAVE_SETENV 1" >>$@ echo "#define HAVE_UNISTD_H 1" >>$@ echo "#define HAVE_UNSIGNED_LONG_LONG 1" >>$@ echo "#define STDC_HEADERS 1" >>$@ echo "#define HAVE_ALLOCA_H 1" >>$@ echo "#define HAVE_ALLOCA 1" >>$@ echo "#define HAVE_GRP_H 1" >>$@ echo "#define HAVE_ERRNO_H 1" >>$@ echo "#define HAVE_SYSEXITS_H 1" >>$@ echo "#define C_STACK_GROWS_DOWNWARD 1" >>$@ ifdef GCHOOKS echo "#define C_GC_HOOKS" >>$@ endif ifdef SYMBOLGC echo "#define C_COLLECT_ALL_SYMBOLS" >>$@ endif ifneq ($(HACKED_APPLY),) echo "#define C_HACKED_APPLY" >>$@ endif cat chicken-defaults.h >>$@ include $(SRCDIR)/rules.make -------------- next part -------------- # Makefile.cygwin - configuration for Linux -*- Makefile -*- # # Copyright (c) 2008-2014, The Chicken Team # Copyright (c) 2007, Felix L. Winkelmann # All rights reserved. # # Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following # conditions are met: # # Redistributions of source code must retain the above copyright notice, this list of conditions and the following # disclaimer. # Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following # disclaimer in the documentation and/or other materials provided with the distribution. # Neither the name of the author nor the names of its contributors may be used to endorse or promote # products derived from this software without specific prior written permission. # # THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS # OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY # AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR # CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR # CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR # SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY # THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR # OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE # POSSIBILITY OF SUCH DAMAGE. ifneq ($(CONFIG),) include $(CONFIG) endif SRCDIR = ./ # platform configuration ARCH ?= $(shell sh $(SRCDIR)/config-arch.sh) HACKED_APPLY ?= 1 DLLSINPATH = 1 # options SO = .dll EXE = .exe C_COMPILER = gcc CXX_COMPILER = g++ RC_COMPILER = windres LINKER = gcc TARGET_RC_COMPILER ?= $(RC_COMPILER) C_COMPILER_OPTIONS ?= -fno-strict-aliasing -fwrapv -DHAVE_CHICKEN_CONFIG_H ifdef DEBUGBUILD C_COMPILER_OPTIMIZATION_OPTIONS ?= -g -Wall -Wno-unused else ifdef OPTIMIZE_FOR_SPEED C_COMPILER_OPTIMIZATION_OPTIONS ?= -O3 -fomit-frame-pointer else C_COMPILER_OPTIMIZATION_OPTIONS ?= -Os -fomit-frame-pointer endif endif C_COMPILER_SHARED_OPTIONS = -DPIC LINKER_LINK_SHARED_LIBRARY_OPTIONS = -shared LINKER_LINK_SHARED_PROGRAM_OPTIONS = -Wl,--dll-search-prefix=cyg LIBCHICKEN_SO_LINKER_OPTIONS = -Wl,--out-implib,lib$(PROGRAM_PREFIX)chicken$(PROGRAM_SUFFIX).dll.a \ -Wl,--export-all-symbols \ -Wl,--enable-auto-import \ -Wl,--image-base=0x10000000 \ -Wl,--dll \ -Wl,--add-stdcall-alias \ -Wl,--no-whole-archive LIBRARIES = -lm LIBCHICKEN_IMPORT_LIBRARY = lib$(PROGRAM_PREFIX)chicken$(PROGRAM_SUFFIX).dll.a # special files CHICKEN_CONFIG_H = chicken-config.h APPLY_HACK_OBJECT = apply-hack.$(ARCH)$(O) # select default and internal settings include $(SRCDIR)/defaults.make LIBCHICKEN_SO_LIBRARIES = $(LIBRARIES) chicken-config.h: chicken-defaults.h echo "/* GENERATED */" >$@ echo "#define C_INSTALL_RC_COMPILER \"$(RC_COMPILER)\"" >>$@ echo "#define C_TARGET_RC_COMPILER \"$(TARGET_RC_COMPILER)\"" >>$@ echo "#define HAVE_DIRENT_H 1" >>$@ echo "#define HAVE_INTTYPES_H 1" >>$@ echo "#define HAVE_LIMITS_H 1" >>$@ echo "#define HAVE_LONG_LONG 1" >>$@ echo "#define HAVE_MEMMOVE 1" >>$@ echo "#define HAVE_MEMORY_H 1" >>$@ echo "#define HAVE_POSIX_POLL 1" >>$@ echo "#define HAVE_SIGACTION 1" >>$@ echo "#define HAVE_STDINT_H 1" >>$@ echo "#define HAVE_STDLIB_H 1" >>$@ echo "#define HAVE_STRERROR 1" >>$@ echo "#define HAVE_STRINGS_H 1" >>$@ echo "#define HAVE_STRING_H 1" >>$@ echo "#define HAVE_STRLCAT 1" >>$@ echo "#define HAVE_STRLCPY 1" >>$@ echo "#define HAVE_STRTOLL 1" >>$@ echo "#define HAVE_STRTOQ 1" >>$@ echo "#define HAVE_SYS_STAT_H 1" >>$@ echo "#define HAVE_SYS_TYPES_H 1" >>$@ echo "#define HAVE_UNISTD_H 1" >>$@ echo "#define HAVE_UNSIGNED_LONG_LONG 1" >>$@ echo "#define STDC_HEADERS 1" >>$@ echo "#define HAVE_ALLOCA 1" >>$@ echo "#define HAVE_ALLOCA_H 1" >>$@ echo "#define HAVE_GRP_H 1" >>$@ echo "#define HAVE_ERRNO_H 1" >>$@ echo "#define HAVE_SYSEXITS_H 1" >>$@ echo "#define HAVE_DLFCN_H 1" >>$@ echo "#define C_STACK_GROWS_DOWNWARD 1" >>$@ ifdef GCHOOKS echo "#define C_GC_HOOKS" >>$@ endif ifdef SYMBOLGC echo "#define C_COLLECT_ALL_SYMBOLS" >>$@ endif ifdef HACKED_APPLY echo "#define C_HACKED_APPLY" >>$@ endif cat chicken-defaults.h >>$@ include $(SRCDIR)/rules.make ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-02 2:59 ` Warner Losh 2014-06-02 3:17 ` Greg 'groggy' Lehey @ 2014-06-02 3:18 ` John Cowan 2014-06-02 6:08 ` Steve Nickolas 2 siblings, 0 replies; 56+ messages in thread From: John Cowan @ 2014-06-02 3:18 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 695 bytes --] Warner Losh scripsit: > “If you can’t say anything nice, say nothing at all." And a Good Thing Too. Public squabbling about trivia serves no one's interest except the enemies'. > They did decent clones of user land stuff, Much less buggy and more Posix-compliant, I think you mean. (The .sig below was chosen at random and in advance, but it's fitting.) -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org We are lost, lost. No name, no business, no Precious, nothing. Only empty. Only hungry: yes, we are hungry. A few little fishes, nassty bony little fishes, for a poor creature, and they say death. So wise they are; so just, so very just. --Gollum ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-02 2:59 ` Warner Losh 2014-06-02 3:17 ` Greg 'groggy' Lehey 2014-06-02 3:18 ` John Cowan @ 2014-06-02 6:08 ` Steve Nickolas 2 siblings, 0 replies; 56+ messages in thread From: Steve Nickolas @ 2014-06-02 6:08 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 484 bytes --] On Sun, 1 Jun 2014, Warner Losh wrote: > Of course, it should be noted that the GNU project was totally incapable > of producing a working kernel… They did decent clones of user land stuff, > but Hurd was a total dead end... The HURD isn't even a joke, it's just a punch line... That said, to me with the userland, BSD gets it right, and GNU is a joke - slow and bloated. You know how Microsoft is known for "embrace, extend and exterminate" ? GNU does the same damn thing. ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-02 2:09 [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') Doug McIlroy 2014-06-02 2:24 ` John Cowan 2014-06-02 2:59 ` Warner Losh @ 2014-06-02 12:04 ` Clem Cole 2014-06-02 12:27 ` Ronald Natalie 2 siblings, 1 reply; 56+ messages in thread From: Clem Cole @ 2014-06-02 12:04 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1889 bytes --] On Sun, Jun 1, 2014 at 10:09 PM, Doug McIlroy <doug at cs.dartmouth.edu> wrote: > Gnu was always taken as a compliment. And of course the Unix clone > was pie in the sky until Linus came along. > Actually I would say the real contribution was not emacs or the getting the user space code rewritten, but gcc. While compared to many commercial compilers it has never been the "the best" but is seems like its always "up there" when compared and in fact I find it a "better" compiler than some of the commercial ones in the embedded space. rms's gift was getting a "production quality" compiler in the everyone's hands that was portable "enough" that it was basically OS independent. As for UNIX clones, Doug, I would sort of differ with you on that. There were numerous "clones" and rewrites from Plauger's Irdis efforts to Andy's Minux if you want to discount the slow rewrite from the inside out of BSD. I content, what really made Linux happen was the ill fated AT&T vs BSDi/UCB case -- a lot of people (myself included) miss understood and were worried BSD would have to go away. I would later be educated in realize, if AT&T had won all of the UNIX "clones" would have had to go away in the west/Nato countries. And frankly, I'm not sure it would have survived that. I agree with you about being annoyed with the words ""The full documentation for ___ is maintained as a Texinfo file" but I find a number of things in Linux that make me just as annoyed. It seems like there are a lot of changes because they could, not be cause it really mattered. But then I remember that as you point out, it runs on everything and that does make me smile and does make life so much easier for all of us. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140602/0893a4c0/attachment.html> ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-02 12:04 ` Clem Cole @ 2014-06-02 12:27 ` Ronald Natalie 2014-06-02 13:28 ` Clem Cole 2014-06-02 14:24 ` John Cowan 0 siblings, 2 replies; 56+ messages in thread From: Ronald Natalie @ 2014-06-02 12:27 UTC (permalink / raw) Well PCC wasn't bad (we used it to build the compilers for the HEP Supercomputer), but you are correct GCC was reasonably good. In addition to Idris mentioned, there was also Mark Williams's Coherent. The bigger issues with these "clones" and the legitimate Unices like XENIX, IS/1, etc... were that the PC platform wasn't quite there yet. Still with all it's flaws, on the 286 and later UNIX actually did run in protected mode, something it took ages for DOS/Windows (one can argue backwards compatibility with the early processors) or Apple (no excuse here, the early Macs were 68000's which had protection) to pick up upon. Wasn't just us in academia who were concerned. Spent an evening sitting in the hallway of some dormitory (UDel?) with Dennis Mumaugh from the NSA discussing security holes we'd fixed. Carping about obscure bugs in Version 6 is sort of silly (as I stated, they were even fixed as of V7) and frankly, software security / reliability was a different world back then. We had less of a time with our TOPS-10 system only because we didn't give students so much free rain on the accounts (compared to the UNIX system which you just had to ask pretty much) but I still remember crashing the EXEC-8 system at UofM with a corrupted file I kept around. Of course there were always hardware bugs to deal with. There were some on the PDP-11 and even on the 386 (when I was working with AIX ...really the UCLA Locus version of UNIX) there was disgusting hacks that doiubled up the paging protection with the old segment-offset stuff because of a security bug there. ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-02 12:27 ` Ronald Natalie @ 2014-06-02 13:28 ` Clem Cole 2014-06-02 14:11 ` Tim Bradshaw 2014-06-02 14:30 ` John Cowan 2014-06-02 14:24 ` John Cowan 1 sibling, 2 replies; 56+ messages in thread From: Clem Cole @ 2014-06-02 13:28 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 2915 bytes --] On Mon, Jun 2, 2014 at 8:27 AM, Ronald Natalie <ron at ronnatalie.com> wrote: > Well PCC wasn't bad (we used it to build the compilers for the HEP > Supercomputer), but you are correct GCC was reasonably good. Ron you are right.. A number of us used dmr's compiler much less Steve's compiler to "port UNIX" to a lot of different things (some where good and some not so good - my own attempt at retargeting the V7 Rtichie compiler to yet to be name processed experimental process from Moto (later called the 68000) proved "good enough" for the Magnolia project at Tek but it was not really not a very good compiler). But you had to have an AT&T license to get it. Admittedly a lot of universities did and that did certainly cause C to get a huge foot hold over its contemporaries (say BCPL, BLISS and maybe PL/360). IMHO: what rms did was put a production quality compiler into play that had sources, that anyone could use and anyone could hack on without having to purchase it or need some sort of license other than his GPL. At the time, there had been lots of attempts at different compilers both "free" and commercial - some with sources some not (I fondly remember Ron Cain's Small C for the 8080 being pushed in Byte Magazine the late 1970s/early 1980). Even Whitesmith's (Plauger's) compiler was really not what would we have called production code quality. gcc was not (still is not) perfect and compared to a number of commercial compilers -- say something like the current Intel compiler or the old DEC, Masscomp or Sun compilers. But the "gcc family" did prove to be fairly easy move to a lot of UNIX/UNIX-like and non-UNIX OS platforms, at the same time able to be retarget to a number of different ISAs, even a number of different front ends; all while generally creating good/reasonable if not darned good/close to optimal code (at least for many of the targets were the most popular/that mattered). Frankly, we have seen few developer suites that have been as lasting and I might suggest that until the LLVM project there has been few (none) that have had a chance of being so [Tannebaum's compiler kit maybe - but I never same that it never really went anywhere]. My observation is that without a "pretty good" compiler that was reasonably "universal" the rest of the command suite would have languished/not happened. As Doug points out the base OS really never happened from rms (they had Trix, then the Hurd and finally defaulted to Linux). But the command suite was able to grow and lots of people besides rms contribute to it, because the basic development tools were there. As strange and difficult a person he is, I suspect we do all own rms a certain level of thanks for the basic dev tools. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140602/5178fdff/attachment.html> ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-02 13:28 ` Clem Cole @ 2014-06-02 14:11 ` Tim Bradshaw 2014-06-02 14:25 ` Clem Cole 2014-06-02 14:26 ` arnold 2014-06-02 14:30 ` John Cowan 1 sibling, 2 replies; 56+ messages in thread From: Tim Bradshaw @ 2014-06-02 14:11 UTC (permalink / raw) On 2 Jun 2014, at 14:28, Clem Cole <clemc at ccc.com> wrote: > [About gcc] > But the command suite was able to grow and lots of people besides rms contribute to it, because the basic development tools were there. As strange and difficult a person he is, I suspect we do all own rms a certain level of thanks for the basic dev tools. In particular I think the existence of GCC was critical to the existence of Linux: there is some complicated history involving a GCC port to ?Minix?, which I think was done because Minix's compiler was rudimentary, and that port enabling some Finnish guy (using Minix I guess) to bring up a kernel. I suspect there are people on this list who remember this better than I do though. --tim -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140602/b0fa22fe/attachment.html> ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-02 14:11 ` Tim Bradshaw @ 2014-06-02 14:25 ` Clem Cole 2014-06-02 14:41 ` John Cowan 2014-06-02 20:06 ` Jacob Goense 2014-06-02 14:26 ` arnold 1 sibling, 2 replies; 56+ messages in thread From: Clem Cole @ 2014-06-02 14:25 UTC (permalink / raw) Tim - cart and horse reversed.. ;-) Linus did not like the fact the when Andy wrote Minux, he and his students did not use the 386 MMU HW. It was made to run on a 8086/8088 -- straight PC/XT because Andy wanted the lowest cost of entry for his students. Also at the time, Andy's compiler tool kit was not as easy to get the source. My memory on this part is hazy, but I think you had to purchase the compiler sources. So Linus started with MINUX and started to add more and more support. He eventually tossed out the ukernel nature of Minux and went the more traditional kernel architecture. He and Andy would famously fight about that choice on usenet. Linus this would eventually need a compiler and pulled rms' suite. The funny part is that his University has 386BSD (aka 4.2 for the 386) at the time which did use the MMU, had networking and even the first step at X11. At the time I had helped the guys get the AT disk driver working as I had access to all the Western Digital documentation. But to get the code from CRSG, you needed at BSD license, which required an AT&T license. Linus' university had one, but he did know know the magic ftp site to download or have access. I've often wondered what would have happened if he had known about it. And again, fast forward about 18-24 months and folks like me were worried when the BSDi case came out that we were going to lose access to a UNIX for the Intel processor. So we started to help him, even though at the time is a huge step backwards. Clearly, the "powers" at AT&T really did not know they were awaking a sleeping animal in the hacker community. Clem On Mon, Jun 2, 2014 at 10:11 AM, Tim Bradshaw <tfb at tfeb.org> wrote: > > On 2 Jun 2014, at 14:28, Clem Cole <clemc at ccc.com> wrote: > > [About gcc] > > But the command suite was able to grow and lots of people besides rms > contribute to it, because the basic development tools were there. As > strange and difficult a person he is, I suspect we do all own rms a certain > level of thanks for the basic dev tools. > > > In particular I think the existence of GCC was critical to the existence > of Linux: there is some complicated history involving a GCC port to > ?Minix?, which I think was done because Minix's compiler was rudimentary, > and that port enabling some Finnish guy (using Minix I guess) to bring up a > kernel. I suspect there are people on this list who remember this better > than I do though. > > --tim > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140602/1d034672/attachment.html> ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-02 14:25 ` Clem Cole @ 2014-06-02 14:41 ` John Cowan 2014-06-02 14:50 ` Armando Stettner 2014-06-02 20:06 ` Jacob Goense 1 sibling, 1 reply; 56+ messages in thread From: John Cowan @ 2014-06-02 14:41 UTC (permalink / raw) Clem Cole scripsit: > I've often wondered what would have happened if he had known about it. Linus is on record as saying that if either the Hurd or the 386BSD system had been available to him, he would never have written the Linux kernel. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org If I have seen farther than others, it is because I was standing on the shoulders of giants. --Isaac Newton ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-02 14:41 ` John Cowan @ 2014-06-02 14:50 ` Armando Stettner 2014-06-02 18:27 ` Brantley Coile 0 siblings, 1 reply; 56+ messages in thread From: Armando Stettner @ 2014-06-02 14:50 UTC (permalink / raw) And, to think, I thought operating system wars and editor religions had died long ago.... aps. Begin forwarded message: > From: John Cowan <cowan at mercury.ccil.org> > Subject: Re: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') > Date: June 2, 2014 at 7:41:05 AM PDT > To: Clem Cole <clemc at ccc.com> > Cc: TUHS main list <tuhs at minnie.tuhs.org>, Tim Bradshaw <tfb at tfeb.org>, Doug McIlroy <doug at cs.dartmouth.edu> > > Clem Cole scripsit: > >> I've often wondered what would have happened if he had known about it. > > Linus is on record as saying that if either the Hurd or the 386BSD system > had been available to him, he would never have written the Linux kernel. > > -- > John Cowan http://www.ccil.org/~cowan cowan at ccil.org > If I have seen farther than others, it is because I was standing on > the shoulders of giants. --Isaac Newton > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-02 14:50 ` Armando Stettner @ 2014-06-02 18:27 ` Brantley Coile 2014-06-02 18:52 ` Dan Cross 0 siblings, 1 reply; 56+ messages in thread From: Brantley Coile @ 2014-06-02 18:27 UTC (permalink / raw) Isn't it part of the nostalgia? iPhone email > On Jun 2, 2014, at 10:57 AM, "Armando Stettner" <aps at ieee.org> wrote: > > And, to think, I thought operating system wars and editor religions had died long ago.... > > aps. > > > Begin forwarded message: > >> From: John Cowan <cowan at mercury.ccil.org> >> Subject: Re: [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') >> Date: June 2, 2014 at 7:41:05 AM PDT >> To: Clem Cole <clemc at ccc.com> >> Cc: TUHS main list <tuhs at minnie.tuhs.org>, Tim Bradshaw <tfb at tfeb.org>, Doug McIlroy <doug at cs.dartmouth.edu> >> >> Clem Cole scripsit: >> >>> I've often wondered what would have happened if he had known about it. >> >> Linus is on record as saying that if either the Hurd or the 386BSD system >> had been available to him, he would never have written the Linux kernel. >> >> -- >> John Cowan http://www.ccil.org/~cowan cowan at ccil.org >> If I have seen farther than others, it is because I was standing on >> the shoulders of giants. --Isaac Newton >> _______________________________________________ >> TUHS mailing list >> TUHS at minnie.tuhs.org >> https://minnie.tuhs.org/mailman/listinfo/tuhs > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-02 18:27 ` Brantley Coile @ 2014-06-02 18:52 ` Dan Cross 2014-06-02 19:10 ` arnold ` (4 more replies) 0 siblings, 5 replies; 56+ messages in thread From: Dan Cross @ 2014-06-02 18:52 UTC (permalink / raw) On Mon, Jun 2, 2014 at 2:27 PM, Brantley Coile <brantley at coraid.com> wrote: > Isn't it part of the nostalgia? > Perhaps. But nostalgia aside, something I find interesting (and frankly a bit distressing) is what seems to me to simply be an acceptance that it's all going to end with Linux. That is to say, no one ever seems to talk about what will come *after* Linux. Will Linus's kernel truly be the last kernel anyone works on seriously? Somehow I very much doubt that. And yet, you don't see a lot of talk about evolutionary paths beyond Linux; it's a sort of tunnel vision. For a while, it seemed like Plan 9 and/or Inferno could be the way forward, but they seem to be all but dead. What will be the next step forward? - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140602/aea6337b/attachment.html> ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-02 18:52 ` Dan Cross @ 2014-06-02 19:10 ` arnold 2014-06-03 1:45 ` Brantley Coile 2014-06-02 19:30 ` John Cowan ` (3 subsequent siblings) 4 siblings, 1 reply; 56+ messages in thread From: arnold @ 2014-06-02 19:10 UTC (permalink / raw) Dan Cross <crossd at gmail.com> wrote: > But nostalgia aside, something I find interesting (and frankly a bit > distressing) is what seems to me to simply be an acceptance that it's all > going to end with Linux. That is to say, no one ever seems to talk about > what will come *after* Linux. Will Linus's kernel truly be the last kernel > anyone works on seriously? Somehow I very much doubt that. And yet, you > don't see a lot of talk about evolutionary paths beyond Linux; it's a sort > of tunnel vision. > > For a while, it seemed like Plan 9 and/or Inferno could be the way forward, > but they seem to be all but dead. What will be the next step forward? Brantley can tell you that Plan 9 isn't dead, although the Labs aren't really providiing the "central control" that Steve mentioned and which is so valuable. There is even some innovation in the Plan 9 world, but much of it is "researchy" - not something to run your enterprise on. (At least, not without a few very sharp gurus handy.) It seems like Plan 9 has been stuck somewhere between V7 and 4.3BSD in terms of "solidity" for many years now. This is rather sad. Arnold ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-02 19:10 ` arnold @ 2014-06-03 1:45 ` Brantley Coile 0 siblings, 0 replies; 56+ messages in thread From: Brantley Coile @ 2014-06-03 1:45 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1821 bytes --] On Jun 2, 2014, at 3:10 PM, arnold at skeeve.com wrote: > Brantley can tell you that Plan 9 isn't dead, although the Labs aren't > really providiing the "central control" that Steve mentioned and which > is so valuable. Plan 9 will be my development system for the foreseeable future. I built the PIX on BSDI using all the tools from the Labs that I could get my hands on, such as sam(1), rc(1) (from Byron), mk(1), and 9win. I shifted the group to real Plan 9 in 1995, when it became available. I used it to build Coraid and I’ll use it for any startups in the future. I get more done faster using it than any other system I’ve tried. I have always kept an independent version running and pick and choose what goes into it. For example, I still run a Ken Thompson file server, even after it was replaced with “better” technology. Plan 9’s stability is one of the things I greatly value; some parts of our system have uptime’s longer than two years. In the past few years, Erik Quanstrom has been Coraid's keeper of our version of Plan 9. For me, he still is. He has worked, with others, to keep the drivers current and adjust things to the changes in hardware. We run a 64 version, for example, on the latest Intel hardware. It might have a very tiny user base, but they will pry Plan 9 out of my cold dead fingers. (That’s a Mike O’Dell reference.) So it will remain alive. Post script. If you want a mindblowingly elegant and beautiful system, study the Oberon system from the 1980’s by Niklaus Wirth. It inspired the Plan 9 editor acme(1). I’ve seen nothing that compares to it’s clarity of thought. Interestingly, Ken Thompson and Niklaus Wirth were both students at Berkeley at same time. I wonder if Harry Huskey’s values are reflected in their work. Brantley ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-02 18:52 ` Dan Cross 2014-06-02 19:10 ` arnold @ 2014-06-02 19:30 ` John Cowan 2014-06-02 19:54 ` Dan Cross 2014-06-02 19:47 ` Chris Nehren ` (2 subsequent siblings) 4 siblings, 1 reply; 56+ messages in thread From: John Cowan @ 2014-06-02 19:30 UTC (permalink / raw) Dan Cross scripsit: > But nostalgia aside, something I find interesting (and frankly a bit > distressing) is what seems to me to simply be an acceptance that it's all > going to end with Linux. That is to say, no one ever seems to talk about > what will come *after* Linux. Will Linus's kernel truly be the last kernel > anyone works on seriously? Somehow I very much doubt that. And yet, you > don't see a lot of talk about evolutionary paths beyond Linux; it's a sort > of tunnel vision. This is like asking when there will be a new scientific discovery in some field. There will be a new kernel when someone decides, as Linus did, to write a new kernel. If it catches on, it may supplement or replace Linux. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org Sir, I quite agree with you, but what are we two against so many? --George Bernard Shaw, to a man booing at the opening of _Arms and the Man_ ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-02 19:30 ` John Cowan @ 2014-06-02 19:54 ` Dan Cross 2014-06-02 23:37 ` John Cowan 0 siblings, 1 reply; 56+ messages in thread From: Dan Cross @ 2014-06-02 19:54 UTC (permalink / raw) On Mon, Jun 2, 2014 at 3:30 PM, John Cowan <cowan at mercury.ccil.org> wrote: > Dan Cross scripsit: > > > But nostalgia aside, something I find interesting (and frankly a bit > > distressing) is what seems to me to simply be an acceptance that it's all > > going to end with Linux. That is to say, no one ever seems to talk about > > what will come *after* Linux. Will Linus's kernel truly be the last > kernel > > anyone works on seriously? Somehow I very much doubt that. And yet, you > > don't see a lot of talk about evolutionary paths beyond Linux; it's a > sort > > of tunnel vision. > > This is like asking when there will be a new scientific discovery in some > field. Forgive me, but I think that's a bit of an odd analogy (or perhaps an indication that I did not adequately explain what I meant). However, let me run with it for a moment and rephrase my statement: there can only be a discovery if one decides it's worth doing the sort of investigation that would lead to a new discovery, and I wonder whether "we" still have that kind of curiosity or drive. Or has Linux become so entrenched that no one can imagine bothering anymore? There will be a new kernel when someone decides, as Linus did, to > write a new kernel. If it catches on, it may supplement or replace Linux. To whit: it appears that "we" (for some large value of "we") have collectively decided that it's not worth looking for a replacement for Linux. If nothing else, I find that interesting. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140602/29ccb321/attachment.html> ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-02 19:54 ` Dan Cross @ 2014-06-02 23:37 ` John Cowan 2014-06-03 1:24 ` Dan Cross 0 siblings, 1 reply; 56+ messages in thread From: John Cowan @ 2014-06-02 23:37 UTC (permalink / raw) Dan Cross scripsit: > > There will be a new kernel when someone decides, as Linus did, to > > write a new kernel. If it catches on, it may supplement or replace Linux. > > To whit: it appears that "we" (for some large value of "we") have > collectively decided that it's not worth looking for a replacement for > Linux. If nothing else, I find that interesting. It doesn't matter how many people decide not to do it, any more than it matters how many people decide not to try to find a replacement for the Standard Model. It only takes one to decide *to* do it. Of course, some people may decide and never do it, or never finish it, or be mute inglorious Miltons who are never heard of, or who are heard of but fail to take over the world. All anyone can do is either do it themselves or wait for someone else to do so. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org If I have not seen as far as others, it is because giants were standing on my shoulders. --Hal Abelson ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-02 23:37 ` John Cowan @ 2014-06-03 1:24 ` Dan Cross 2014-06-03 2:16 ` John Cowan 0 siblings, 1 reply; 56+ messages in thread From: Dan Cross @ 2014-06-03 1:24 UTC (permalink / raw) You are, of course, free to not find it interesting in the way that I do. :-) On Mon, Jun 2, 2014 at 7:37 PM, John Cowan <cowan at mercury.ccil.org> wrote: > Dan Cross scripsit: > > > > There will be a new kernel when someone decides, as Linus did, to > > > write a new kernel. If it catches on, it may supplement or replace > Linux. > > > > To whit: it appears that "we" (for some large value of "we") have > > collectively decided that it's not worth looking for a replacement for > > Linux. If nothing else, I find that interesting. > > It doesn't matter how many people decide not to do it, any more than it > matters how many people decide not to try to find a replacement for the > Standard Model. It only takes one to decide *to* do it. Of course, > some people may decide and never do it, or never finish it, or be mute > inglorious Miltons who are never heard of, or who are heard of but fail > to take over the world. > > All anyone can do is either do it themselves or wait for someone else > to do so. > > -- > John Cowan http://www.ccil.org/~cowan cowan at ccil.org > If I have not seen as far as others, it is because giants were standing > on my shoulders. --Hal Abelson > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140602/77f8a708/attachment.html> ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-03 1:24 ` Dan Cross @ 2014-06-03 2:16 ` John Cowan 2014-06-03 2:18 ` Dan Cross 0 siblings, 1 reply; 56+ messages in thread From: John Cowan @ 2014-06-03 2:16 UTC (permalink / raw) Dan Cross scripsit: > You are, of course, free to not find it interesting in the way that I do. It's not that, I just think you are asking for a prediction of the inherently unpredictable. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org I amar prestar aen, han mathon ne nen, http://www.ccil.org/~cowan han mathon ne chae, a han noston ne 'wilith. --Galadriel, LOTR:FOTR ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-03 2:16 ` John Cowan @ 2014-06-03 2:18 ` Dan Cross 0 siblings, 0 replies; 56+ messages in thread From: Dan Cross @ 2014-06-03 2:18 UTC (permalink / raw) On Mon, Jun 2, 2014 at 10:16 PM, John Cowan <cowan at mercury.ccil.org> wrote: > Dan Cross scripsit: > > You are, of course, free to not find it interesting in the way that I do. > > It's not that, I just think you are asking for a prediction of the > inherently > unpredictable. I'm not asking for any prediction. I'm merely stating that it seems to me that people aren't interested in these sorts of things anymore. I find that interesting (and a little sad). - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140602/6a676fdd/attachment.html> ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-02 18:52 ` Dan Cross 2014-06-02 19:10 ` arnold 2014-06-02 19:30 ` John Cowan @ 2014-06-02 19:47 ` Chris Nehren 2014-06-02 20:23 ` Dan Cross 2014-06-02 21:08 ` [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') Charlie Kester 2014-06-03 0:37 ` Tim Newsham 4 siblings, 1 reply; 56+ messages in thread From: Chris Nehren @ 2014-06-02 19:47 UTC (permalink / raw) On Mon, Jun 02, 2014 at 14:52:12 -0400, Dan Cross wrote: > But nostalgia aside, something I find interesting (and frankly a bit > distressing) is what seems to me to simply be an acceptance that it's all > going to end with Linux. That is to say, no one ever seems to talk about > what will come *after* Linux. Will Linus's kernel truly be the last kernel > anyone works on seriously? Somehow I very much doubt that. And yet, you > don't see a lot of talk about evolutionary paths beyond Linux; it's a sort > of tunnel vision. You (specifically) don't see a lot of evolutionary paths beyond Linux because you're not looking for them. There is a lot of innovation happening in illumos and BSD. Thanks to the aforementioned rms, Linux has been about evangelism almost from the start. The illumos and BSD communities are more focused on great engineering rather than proselytization. Let Linux have the fame; everyone who wants to do great work (that Linux users will then want to steal, and then gripe about because of licensing FUD) is elsewhere. -- Chris Nehren -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 907 bytes Desc: not available URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140602/09bd9da7/attachment.sig> ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-02 19:47 ` Chris Nehren @ 2014-06-02 20:23 ` Dan Cross 2014-06-03 18:48 ` [TUHS] Evolutionary Paths (was Gnu/Stallman (was Bugs in V6 'dcheck')) scj 0 siblings, 1 reply; 56+ messages in thread From: Dan Cross @ 2014-06-02 20:23 UTC (permalink / raw) On Mon, Jun 2, 2014 at 3:47 PM, Chris Nehren <cnehren+tuhs at pobox.com> wrote: > On Mon, Jun 02, 2014 at 14:52:12 -0400, Dan Cross wrote: > > But nostalgia aside, something I find interesting (and frankly a bit > > distressing) is what seems to me to simply be an acceptance that it's all > > going to end with Linux. That is to say, no one ever seems to talk about > > what will come *after* Linux. Will Linus's kernel truly be the last > kernel > > anyone works on seriously? Somehow I very much doubt that. And yet, you > > don't see a lot of talk about evolutionary paths beyond Linux; it's a > sort > > of tunnel vision. > > You (specifically) don't see a lot of evolutionary paths beyond > Linux because you're not looking for them. Well, without knowing me or a thing about me, that's a strong statement. There is a lot of innovation happening in illumos and BSD. [snip] This is my point. s/Linux/(Illumos|.*BSD)/ and the point remains largely the same. These aren't new systems trying out fundamentally new ideas; they're making incremental improvements on things that have come before. That's all well and good (and it's nice to have an alternative to Linux specifically), but building on a nearly 50 year old framework isn't particularly innovative, despite claims to the contrary. Now don't get me wrong, that framework remains wildly useful, and so that work has value, but my question is more generally whether anyone has the kind of drive to come up with the sort of next generation system that Unix represented when Unix was new? Things like Plan 9 and Akaros are more along the lines of what I was thinking of: mentioning *BSD or other such systems reinforces my thesis. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140602/5f4f1904/attachment.html> ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Evolutionary Paths (was Gnu/Stallman (was Bugs in V6 'dcheck')) 2014-06-02 20:23 ` Dan Cross @ 2014-06-03 18:48 ` scj 2014-06-04 1:10 ` Larry McVoy 0 siblings, 1 reply; 56+ messages in thread From: scj @ 2014-06-03 18:48 UTC (permalink / raw) Well, I'm sure my biases are showing, but I see the Kernel as a means for supplying features for a model of computation, and the programming language as the delivery vehicle for that model of computation. And in my view, C/C++ is far more obsolete than Linux. Hardware has left software in the dust. It is quite feasible to produce a chip with 1000 or 10,000 processors on it, each with a bit of memory and a communication fabric. That's what tomorrow's technology is giving us. Multicore and named threads are just not going to cut it when using such a system. A central supplier of any service is a bottleneck. We've got to write our software to act more like an ant farm than a military hierarchy. Otherwise said, we have to learn to think different. Very different. And the hardest part of that is letting go of the old ways of thinking. Perhaps encroaching senility is help in this... Steve ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Evolutionary Paths (was Gnu/Stallman (was Bugs in V6 'dcheck')) 2014-06-03 18:48 ` [TUHS] Evolutionary Paths (was Gnu/Stallman (was Bugs in V6 'dcheck')) scj @ 2014-06-04 1:10 ` Larry McVoy 2014-06-04 3:42 ` Greg Chesson 0 siblings, 1 reply; 56+ messages in thread From: Larry McVoy @ 2014-06-04 1:10 UTC (permalink / raw) First, let me say how cool it is to be replying to the guy who did yacc. I've used it for decades, thank you for that. I was at SGI when they did the Origin servers, the architecture (as I remember it) was a board with 2 CPUS, some local memory, and an connection to a hypercube style of memory. An interesting aside is that this is where I learned that infinitely large packets in a network are infinitely stupid because you have to buffer a packet if the outgoing port is busy. I used to be a fan of big packets on ethernet, that system taught me that ethernet is just fine. The Origin "network" had ~32 byte packets. Buffering those was "easy". The problem with the lots-of-cpus design is that memory latency goes up. It was OK for local memory, it was not OK for remote memory. Don't get me wrong, SGI did a really great job at it, but when you compare a bunch of networked boxes with the SMP model SGI had, SGI won on jobs that needed shared memory, the bunch of networked boxes kicked ass on everything else. Cross reference: google. Intel's test harness. And a bunch of others. When you are benchmarking against a 10,000 node cluster and the cluster is winning, yeah, you need to rethink what you are doing. I've copied Greg Chesson, you guys should know him, he's ex Bell Labs, he can correct my ramblings, I worked for him at SGI. --lm On Tue, Jun 03, 2014 at 11:48:25AM -0700, scj at yaccman.com wrote: > Well, I'm sure my biases are showing, but I see the Kernel as a means for > supplying features for a model of computation, and the programming > language as the delivery vehicle for that model of computation. And in my > view, C/C++ is far more obsolete than Linux. > > Hardware has left software in the dust. It is quite feasible to produce a > chip with 1000 or 10,000 processors on it, each with a bit of memory and a > communication fabric. That's what tomorrow's technology is giving us. > Multicore and named threads are just not going to cut it when using such a > system. A central supplier of any service is a bottleneck. We've got to > write our software to act more like an ant farm than a military hierarchy. > > Otherwise said, we have to learn to think different. Very different. And > the hardest part of that is letting go of the old ways of thinking. > Perhaps encroaching senility is help in this... > > Steve ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Evolutionary Paths (was Gnu/Stallman (was Bugs in V6 'dcheck')) 2014-06-04 1:10 ` Larry McVoy @ 2014-06-04 3:42 ` Greg Chesson 2014-06-05 0:43 ` Larry McVoy 0 siblings, 1 reply; 56+ messages in thread From: Greg Chesson @ 2014-06-04 3:42 UTC (permalink / raw) Hi, I certainly know scj from Murray Hill. Not sure who is tubs. Distributed and parallel hardware has evolved far beyond the ability of most sw. Everyone agrees, I think; and, GPUs just make it more so. On the other hand, cpu architecture remains classic Von Neumann with registers, alus, and familiar memory hierarchies. Close to the hardware where instructions are visible, there is not much change. And I think there are compelling technical reasons on why that is so as a consequence of digital logic and transistor circuitry and electrical signalling. C/C++ remains a good fit at that level because it is still a reflection of the hardware. I agree with Steve - and so would Ken as I have heard him say it several times going back many years - the kernel is basically a multiplexor for memory, io, and time. What happens above that in terms of data representation and anything like intelligence is a higher-order function and demands higher-order programming than what works for most kernel tasks. I use the term "higher-order" in the same sense that Church's type theory (lambda calculus) is higher order than first order predicate logic. I've always liked what Knuth wrote long ago about the evolution of programming languages. He observed that languages have evolved first from binary, to assembly language, and then jumped to Fortran because programmers who found they were writing the same kind of stuff over and over, sometimes in the same program, looked for ways to express more with less. That still happens today and will continue. But wait, there's more. Imagine what would be needed to implement a human brain model with something like 10^11 neurons and 10^14 connections. Out of reach today. People are just now trying to emulate the 302 neurons in the nervous system of Caenorhabditis elegans. C/C++ and Von Neumann cpus are not a good match for such problems - and there are many computations (and searches) of stupendous enormous scale that would dwarf any supercomputer in the planning stages today. I hope I get to see some of what comes next, and maybe even help carry forward a few building blocks. What started this conversation? Greg On Tue, Jun 3, 2014 at 6:10 PM, Larry McVoy <lm at mcvoy.com> wrote: > First, let me say how cool it is to be replying to the guy who did yacc. > I've used it for decades, thank you for that. > > I was at SGI when they did the Origin servers, the architecture (as I > remember it) was a board with 2 CPUS, some local memory, and an connection > to a hypercube style of memory. An interesting aside is that this is > where I learned that infinitely large packets in a network are infinitely > stupid because you have to buffer a packet if the outgoing port is busy. > I used to be a fan of big packets on ethernet, that system taught me > that ethernet is just fine. The Origin "network" had ~32 byte packets. > Buffering those was "easy". > > The problem with the lots-of-cpus design is that memory latency goes up. > It was OK for local memory, it was not OK for remote memory. Don't get > me wrong, SGI did a really great job at it, but when you compare a bunch > of networked boxes with the SMP model SGI had, SGI won on jobs that needed > shared memory, the bunch of networked boxes kicked ass on everything else. > Cross reference: google. Intel's test harness. And a bunch of others. > When you are benchmarking against a 10,000 node cluster and the cluster > is winning, yeah, you need to rethink what you are doing. > > I've copied Greg Chesson, you guys should know him, he's ex Bell Labs, > he can correct my ramblings, I worked for him at SGI. > > --lm > > On Tue, Jun 03, 2014 at 11:48:25AM -0700, scj at yaccman.com wrote: > > Well, I'm sure my biases are showing, but I see the Kernel as a means for > > supplying features for a model of computation, and the programming > > language as the delivery vehicle for that model of computation. And in > my > > view, C/C++ is far more obsolete than Linux. > > > > Hardware has left software in the dust. It is quite feasible to produce > a > > chip with 1000 or 10,000 processors on it, each with a bit of memory and > a > > communication fabric. That's what tomorrow's technology is giving us. > > Multicore and named threads are just not going to cut it when using such > a > > system. A central supplier of any service is a bottleneck. We've got to > > write our software to act more like an ant farm than a military > hierarchy. > > > > Otherwise said, we have to learn to think different. Very different. > And > > the hardest part of that is letting go of the old ways of thinking. > > Perhaps encroaching senility is help in this... > > > > Steve > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140603/4f859092/attachment.html> ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Evolutionary Paths (was Gnu/Stallman (was Bugs in V6 'dcheck')) 2014-06-04 3:42 ` Greg Chesson @ 2014-06-05 0:43 ` Larry McVoy 0 siblings, 0 replies; 56+ messages in thread From: Larry McVoy @ 2014-06-05 0:43 UTC (permalink / raw) Hey Greg, It's "tuhs" not "tubs" and it stands for The Unix Historical Society so far as I know. Lots of Bell Labs and other folks on the list, it's a fun walk down memory lane, you should join. What started the conversation was someone musing on whether Linux is the end of OS development. Steve was talking about problems that SGI worked on so I wanted to point out that there might be something to mine there. --lm On Tue, Jun 03, 2014 at 08:42:56PM -0700, Greg Chesson wrote: > Hi, > > I certainly know scj from Murray Hill. Not sure who is tubs. > > Distributed and parallel hardware has evolved far beyond the ability > of most sw. Everyone agrees, I think; and, GPUs just make it more so. > > On the other hand, cpu architecture remains classic Von Neumann > with registers, alus, and familiar memory hierarchies. Close to the > hardware where instructions are visible, there is not much change. > And I think there are compelling technical reasons on why that > is so as a consequence of digital logic and transistor circuitry > and electrical signalling. C/C++ remains a good fit at that level > because it is still a reflection of the hardware. > > I agree with Steve - and so would Ken as I have heard him say > it several times going back many years - the kernel is basically > a multiplexor for memory, io, and time. What happens above that > in terms of data representation and anything like intelligence > is a higher-order function and demands higher-order programming > than what works for most kernel tasks. I use the term "higher-order" > in the same sense that Church's type theory (lambda calculus) > is higher order than first order predicate logic. > > I've always liked what Knuth wrote long ago about the evolution > of programming languages. He observed that languages > have evolved first from binary, to assembly language, and > then jumped to Fortran because programmers who found > they were writing the same kind of stuff over and over, > sometimes in the same program, looked for ways to express > more with less. That still happens today and will continue. > > But wait, there's more. > Imagine what would be needed to implement a human brain model > with something like 10^11 neurons and 10^14 connections. > Out of reach today. > > People are just now trying to emulate the 302 neurons in the nervous > system of Caenorhabditis elegans. C/C++ and Von Neumann cpus > are not a good match for such problems - and there are many > computations (and searches) of stupendous enormous scale that would dwarf > any supercomputer in the planning stages today. > > I hope I get to see some of what comes next, and maybe even > help carry forward a few building blocks. > > What started this conversation? > > Greg > > > On Tue, Jun 3, 2014 at 6:10 PM, Larry McVoy <lm at mcvoy.com> wrote: > > > First, let me say how cool it is to be replying to the guy who did yacc. > > I've used it for decades, thank you for that. > > > > I was at SGI when they did the Origin servers, the architecture (as I > > remember it) was a board with 2 CPUS, some local memory, and an connection > > to a hypercube style of memory. An interesting aside is that this is > > where I learned that infinitely large packets in a network are infinitely > > stupid because you have to buffer a packet if the outgoing port is busy. > > I used to be a fan of big packets on ethernet, that system taught me > > that ethernet is just fine. The Origin "network" had ~32 byte packets. > > Buffering those was "easy". > > > > The problem with the lots-of-cpus design is that memory latency goes up. > > It was OK for local memory, it was not OK for remote memory. Don't get > > me wrong, SGI did a really great job at it, but when you compare a bunch > > of networked boxes with the SMP model SGI had, SGI won on jobs that needed > > shared memory, the bunch of networked boxes kicked ass on everything else. > > Cross reference: google. Intel's test harness. And a bunch of others. > > When you are benchmarking against a 10,000 node cluster and the cluster > > is winning, yeah, you need to rethink what you are doing. > > > > I've copied Greg Chesson, you guys should know him, he's ex Bell Labs, > > he can correct my ramblings, I worked for him at SGI. > > > > --lm > > > > On Tue, Jun 03, 2014 at 11:48:25AM -0700, scj at yaccman.com wrote: > > > Well, I'm sure my biases are showing, but I see the Kernel as a means for > > > supplying features for a model of computation, and the programming > > > language as the delivery vehicle for that model of computation. And in > > my > > > view, C/C++ is far more obsolete than Linux. > > > > > > Hardware has left software in the dust. It is quite feasible to produce > > a > > > chip with 1000 or 10,000 processors on it, each with a bit of memory and > > a > > > communication fabric. That's what tomorrow's technology is giving us. > > > Multicore and named threads are just not going to cut it when using such > > a > > > system. A central supplier of any service is a bottleneck. We've got to > > > write our software to act more like an ant farm than a military > > hierarchy. > > > > > > Otherwise said, we have to learn to think different. Very different. > > And > > > the hardest part of that is letting go of the old ways of thinking. > > > Perhaps encroaching senility is help in this... > > > > > > Steve > > -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-02 18:52 ` Dan Cross ` (2 preceding siblings ...) 2014-06-02 19:47 ` Chris Nehren @ 2014-06-02 21:08 ` Charlie Kester 2014-06-03 0:37 ` Tim Newsham 4 siblings, 0 replies; 56+ messages in thread From: Charlie Kester @ 2014-06-02 21:08 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1078 bytes --] On Mon 02 Jun 2014 at 11:52:12 PDT Dan Cross wrote: > On Mon, Jun 2, 2014 at 2:27 PM, Brantley Coile <[1]brantley at coraid.com> > wrote: > > Isn't it part of the nostalgia? > > Perhaps. > But nostalgia aside, something I find interesting (and frankly a bit > distressing) is what seems to me to simply be an acceptance that it's all > going to end with Linux. That is to say, no one ever seems to talk about > what will come *after* Linux. Will Linus's kernel truly be the last > kernel anyone works on seriously? Somehow I very much doubt that. And > yet, you don't see a lot of talk about evolutionary paths beyond Linux; > it's a sort of tunnel vision. > For a while, it seemed like Plan 9 and/or Inferno could be the way > forward, but they seem to be all but dead. What will be the next step > forward? The recent dustup over systemd does seem to have many people looking for alternatives to the main Linux distros -- and perhaps to Linux itself. There's an opportunity, but it isn't clear that anyone is prepared to seize it. ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-02 18:52 ` Dan Cross ` (3 preceding siblings ...) 2014-06-02 21:08 ` [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') Charlie Kester @ 2014-06-03 0:37 ` Tim Newsham 4 siblings, 0 replies; 56+ messages in thread From: Tim Newsham @ 2014-06-03 0:37 UTC (permalink / raw) It would be nice if we end up moving towards something with a solid theoretical underpinning.. seL4 comes to mind. I'd be happy to trade off some performance for some security and strongly enforced modularity. There's still lots to be done (sel4 is just a small microkernel (needed: drivers, filesystems, memory subsystems, etc), and there's little point in having a proven microkernel if you don't keep building up strong software on top of that foundation). </increasinglyOffTopic> On Mon, Jun 2, 2014 at 8:52 AM, Dan Cross <crossd at gmail.com> wrote: > On Mon, Jun 2, 2014 at 2:27 PM, Brantley Coile <brantley at coraid.com> wrote: >> >> Isn't it part of the nostalgia? > > > Perhaps. > > But nostalgia aside, something I find interesting (and frankly a bit > distressing) is what seems to me to simply be an acceptance that it's all > going to end with Linux. That is to say, no one ever seems to talk about > what will come *after* Linux. Will Linus's kernel truly be the last kernel > anyone works on seriously? Somehow I very much doubt that. And yet, you > don't see a lot of talk about evolutionary paths beyond Linux; it's a sort > of tunnel vision. > > For a while, it seemed like Plan 9 and/or Inferno could be the way forward, > but they seem to be all but dead. What will be the next step forward? > > - Dan C. > > > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > -- Tim Newsham | www.thenewsh.com/~newsham | @newshtwit | thenewsh.blogspot.com ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-02 14:25 ` Clem Cole 2014-06-02 14:41 ` John Cowan @ 2014-06-02 20:06 ` Jacob Goense 1 sibling, 0 replies; 56+ messages in thread From: Jacob Goense @ 2014-06-02 20:06 UTC (permalink / raw) On 2014-06-02 16:25, Clem Cole wrote: > Linus this would eventually need a compiler and pulled rms' suite. > > The funny part is that his University has 386BSD (aka 4.2 for the > 386) at the time which did use the MMU, had networking and even the > first step at X11. At the time I had helped the guys get the AT disk > driver working as I had access to all the Western Digital > documentation. But to get the code from CRSG, you needed at BSD > license, which required an AT&T license. Linus' university had one, > but he did know know the magic ftp site to download or have access. > > I've often wondered what would have happened if he had known about it. AFAICT 386BSD port started out with 4.3BSD-Tahoe sources. Jolitz pulled in GCC[1], and Linus would have run into the same compiler. Did Jolitz even have much of a choice back in '89? [1] - From the original project proposal for 386BSD 3.1. Language tools: We will base our port on nascent language utilities from RMS's GNU project (GCC & GAS & LD), which are fairly well fleshed-out but have never been put to the acid test. Obviously, we will encounter and bypass and/or fix compiler bugs. Until we find a dedicated compiler participant who is familiar with GCC, the author will field all compiler problems and be responsible for fixes and/or workarounds. We think that GCC is an excellent compiler to work with, and hope that our use of it will provide FSF with much useful feedback on fixes and improvements. ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-02 14:11 ` Tim Bradshaw 2014-06-02 14:25 ` Clem Cole @ 2014-06-02 14:26 ` arnold 1 sibling, 0 replies; 56+ messages in thread From: arnold @ 2014-06-02 14:26 UTC (permalink / raw) Tim Bradshaw <tfb at tfeb.org> wrote: > > In particular I think the existence of GCC was critical to the existence > of Linux: Linus himself has said as much. I can't find the quote, but I'm pretty sure he acknowledges that. Arnold ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-02 13:28 ` Clem Cole 2014-06-02 14:11 ` Tim Bradshaw @ 2014-06-02 14:30 ` John Cowan 1 sibling, 0 replies; 56+ messages in thread From: John Cowan @ 2014-06-02 14:30 UTC (permalink / raw) Clem Cole scripsit: > Frankly, we have seen few developer suites that have been as lasting and I > might suggest that until the LLVM project there has been few (none) that > have had a chance of being so [Tannebaum's compiler kit maybe - but I never > same that it never really went anywhere]. "The university is free but the compiler is not", as Tanenbaum said to RMS. However, eventually he caught up, and it was BSD-licensed in 2003. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org Heckler: "Go on, Al, tell 'em all you know. It won't take long." Al Smith: "I'll tell 'em all we *both* know. It won't take any longer." ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-02 12:27 ` Ronald Natalie 2014-06-02 13:28 ` Clem Cole @ 2014-06-02 14:24 ` John Cowan 2014-06-02 14:29 ` Ronald Natalie ` (2 more replies) 1 sibling, 3 replies; 56+ messages in thread From: John Cowan @ 2014-06-02 14:24 UTC (permalink / raw) Ronald Natalie scripsit: > Still with all it's flaws, on the 286 and later UNIX actually did run in > protected mode, something it took ages for DOS/Windows (one can argue > backwards compatibility with the early processors) or Apple (no excuse > here, the early Macs were 68000's which had protection) to pick up upon. The original Mac 128K was a 68000 processor, and IIRC memory protection didn't arrive until the 68020. -- John Cowan http://www.ccil.org/~cowan cowan at ccil.org 'Tis the Linux rebellion / Let coders take their place, The Linux-nationale / Shall Microsoft outpace, We can write better programs / Our CPUs won't stall, So raise the penguin banner of / The Linux-nationale. --Greg Baker ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-02 14:24 ` John Cowan @ 2014-06-02 14:29 ` Ronald Natalie 2014-06-02 14:37 ` Clem Cole 2014-06-05 7:31 ` Arno Griffioen 2 siblings, 0 replies; 56+ messages in thread From: Ronald Natalie @ 2014-06-02 14:29 UTC (permalink / raw) On Jun 2, 2014, at 10:24 AM, John Cowan <cowan at mercury.ccil.org> wrote: > Ronald Natalie scripsit: > >> Still with all it's flaws, on the 286 and later UNIX actually did run in >> protected mode, something it took ages for DOS/Windows (one can argue >> backwards compatibility with the early processors) or Apple (no excuse >> here, the early Macs were 68000's which had protection) to pick up upon. > > The original Mac 128K was a 68000 processor, and IIRC memory protection > didn't arrive until the 68020. > > -- Yeah, you're right. You could get it off-chip with the -010 or it was integrated with the -020. ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-02 14:24 ` John Cowan 2014-06-02 14:29 ` Ronald Natalie @ 2014-06-02 14:37 ` Clem Cole 2014-06-05 7:31 ` Arno Griffioen 2 siblings, 0 replies; 56+ messages in thread From: Clem Cole @ 2014-06-02 14:37 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1562 bytes --] On Mon, Jun 2, 2014 at 10:24 AM, John Cowan <cowan at mercury.ccil.org> wrote: > The original Mac 128K was a 68000 processor, and IIRC memory protection > didn't arrive until the 68020. > Sort of. Did not arrive to >>Apple<< until the '020 based Mac-II. Les Crudele (one the 68k's designers) tells a great story about this. The original device had a PDP-11 base/limit register MMU as an external chip who's number I forget (and could not do demand paging by itself -- Masscomp and Apollo would use 2 of them and build their own MMU). According to Les, Moto offered to give Apple the MMU chip at a substantial discount (maybe even free) if they would use it for the Mac. But Jobs famously said it was a personal computer and did not need it (remember the Alto's did not have an MMU either). Later, Moto would release the '010 which could do demanding paging with help of an external MMU. The Stanford University Network Terminal (aka "SUN" board) could use the '10. I don't think Apple did themselves, but my memory is that the was an after market '010 mod for some of the Macs. At Masscomp, we retrofited the original CPU board to take a '010. In this mode, the 'fixer' 68K and the '010 could run in parallel during a page fault, which was slightly faster. But functionally, to the end user it was the same as two 68K's. I'm not sure if Apollo did a retrofit. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140602/4c960b2c/attachment.html> ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-02 14:24 ` John Cowan 2014-06-02 14:29 ` Ronald Natalie 2014-06-02 14:37 ` Clem Cole @ 2014-06-05 7:31 ` Arno Griffioen 2014-06-05 8:24 ` emu ` (2 more replies) 2 siblings, 3 replies; 56+ messages in thread From: Arno Griffioen @ 2014-06-05 7:31 UTC (permalink / raw) On Mon, Jun 02, 2014 at 10:24:48AM -0400, John Cowan wrote: > Ronald Natalie scripsit: > > > Still with all it's flaws, on the 286 and later UNIX actually did run in > > protected mode, something it took ages for DOS/Windows (one can argue > > backwards compatibility with the early processors) or Apple (no excuse > > here, the early Macs were 68000's which had protection) to pick up upon. > > The original Mac 128K was a 68000 processor, and IIRC memory protection > didn't arrive until the 68020. As mentioned by others the 68010 could, with additional external hardware, support memory management. The original 68000 (and 8-bit data bus 68008) did already have the full 32 bit instruction and data support of the complete family, but for MMU use it lacked one critical feature in the fact that it did not push enough page-fault information on the stack to re-start an instruction in case of an (externally signalled) page-fault. So even if you interfaced external MMU logic then a basic 68000 was still in trouble when a page fault occurred as it could not 'start over' the faulted instruction. The 68010 added the correct stack frames to be able to restart a faulted instruction and also added the first small performance enhancement in the form of a 'loop mode' where the CPU could basically cache a small loop and execute this without incurring addtional memory wait cycles. As a result the '010 was usually used in various *NIX machines of the era like some SUN2's and various machines (one-offs or low production) from other brands. Eg. I still have a machine in my collection which is from a small local production run that utilises an '010 with a custom, but quite rudimentary, MMU based on some simple logic chips and it used to run SVR2. Very slowly as it had a whopping 1 Mbyte of RAM and the MMU could give you a virtual memory size of 4 Mbyte. I did port MINIX to it and added memory management/protection support to the kernel. Ran a lot faster :) With the release of the '020 Motorola delivered their own full-blown (but still external) MMU in the shape of the MC68851 Many non-UNIX '020 based machines of the era did not have the MC68851 on board at all (eg. most Apples from the time) as it was relatively expensive and could incur extra memory latency/cycles being an external unit. With the '030 Motorola finally moved the MMU onto the same die as the CPU (reducing the latency and cost) and it became more prevalent on more platforms (although the cheaper 68EC030 was available without an MMU and used in many machines) Bringing this back to UNIX, I used to do some local supporting work at CBM for the Commodore UNIX'es that were Amiga, and of course M68k based. The official Amiga 2000 '020 turboboard (or one of the A2500UX'es like I have at home :) ) does have both the MC68851 MMU and the MC68881 FPU and these were used for a, mostly in-house at CBM, SVR3.2 based UNIX version. AmigaDOS of course also ran fine on it, but did not use the MMU. The later, general release, SVR4 UNIX version was desgined to run on the '030 based A3000UX'es, although it still ran on the '020+MMU cards in their limited (4Mb) DRAM. Bye, Arno. ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-05 7:31 ` Arno Griffioen @ 2014-06-05 8:24 ` emu 2014-06-05 9:17 ` Wesley Parish 2014-06-05 15:07 ` Clem Cole 2 siblings, 0 replies; 56+ messages in thread From: emu @ 2014-06-05 8:24 UTC (permalink / raw) Zitat von Arno Griffioen <arno.griffioen at ieee.org>: > As a result the '010 was usually used in various *NIX machines of the > era like some SUN2's and various machines (one-offs or low production) > from other brands. One "nice" machine, which actually ran Unix on the 68010 was: http://en.wikipedia.org/wiki/AT%26T_Unix_PC ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-05 7:31 ` Arno Griffioen 2014-06-05 8:24 ` emu @ 2014-06-05 9:17 ` Wesley Parish 2014-06-05 11:26 ` Brantley Coile 2014-06-11 12:10 ` Michael Parson 2014-06-05 15:07 ` Clem Cole 2 siblings, 2 replies; 56+ messages in thread From: Wesley Parish @ 2014-06-05 9:17 UTC (permalink / raw) Which of course raises the question: how did AmigaDOS manage context switches and the like for its brand of multitasking? I know BYTE explained it in the early 1990s, but I threw away all my BYTEs a couple of decades ago, and don't remember the details. Thanks Wesley Parish Quoting Arno Griffioen <arno.griffioen at ieee.org>: > On Mon, Jun 02, 2014 at 10:24:48AM -0400, John Cowan wrote: > > Ronald Natalie scripsit: > > > > > Still with all it's flaws, on the 286 and later UNIX actually did > run in > > > protected mode, something it took ages for DOS/Windows (one can > argue > > > backwards compatibility with the early processors) or Apple (no > excuse > > > here, the early Macs were 68000's which had protection) to pick up > upon. > > > > The original Mac 128K was a 68000 processor, and IIRC memory > protection > > didn't arrive until the 68020. > > As mentioned by others the 68010 could, with additional external > hardware, > support memory management. > > The original 68000 (and 8-bit data bus 68008) did already have the full > 32 > bit instruction and data support of the complete family, but for MMU use > it > lacked one critical feature in the fact that it did not push enough > page-fault > information on the stack to re-start an instruction in case of an > (externally > signalled) page-fault. > > So even if you interfaced external MMU logic then a basic 68000 was > still in > trouble when a page fault occurred as it could not 'start over' the > faulted instruction. > > The 68010 added the correct stack frames to be able to restart a > faulted > instruction and also added the first small performance enhancement in > the > form of a 'loop mode' where the CPU could basically cache a small loop > and execute this without incurring addtional memory wait cycles. > > As a result the '010 was usually used in various *NIX machines of the > era like some SUN2's and various machines (one-offs or low production) > from other brands. > > Eg. I still have a machine in my collection which is from a small local > > production run that utilises an '010 with a custom, but quite > rudimentary, > MMU based on some simple logic chips and it used to run SVR2. Very > slowly > as it had a whopping 1 Mbyte of RAM and the MMU could give you a virtual > > memory size of 4 Mbyte. > > I did port MINIX to it and added memory management/protection support to > > the kernel. Ran a lot faster :) > > With the release of the '020 Motorola delivered their own full-blown > (but > still external) MMU in the shape of the MC68851 > > Many non-UNIX '020 based machines of the era did not have the MC68851 on > > board at all (eg. most Apples from the time) as it was relatively > expensive > and could incur extra memory latency/cycles being an external unit. > > With the '030 Motorola finally moved the MMU onto the same die as the > CPU > (reducing the latency and cost) and it became more prevalent on more > platforms (although the cheaper 68EC030 was available without an MMU and > > used in many machines) > > Bringing this back to UNIX, I used to do some local supporting work at > CBM for > the Commodore UNIX'es that were Amiga, and of course M68k based. > > The official Amiga 2000 '020 turboboard (or one of the A2500UX'es like I > have > at home :) ) does have both the MC68851 MMU and the MC68881 FPU and > these > were used for a, mostly in-house at CBM, SVR3.2 based UNIX version. > > AmigaDOS of course also ran fine on it, but did not use the MMU. > > The later, general release, SVR4 UNIX version was desgined to run on > the > '030 based A3000UX'es, although it still ran on the '020+MMU cards in > their > limited (4Mb) DRAM. > > Bye, Arno. > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuh s > ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-05 9:17 ` Wesley Parish @ 2014-06-05 11:26 ` Brantley Coile 2014-06-05 13:34 ` Jesus Cea 2014-06-11 12:10 ` Michael Parson 1 sibling, 1 reply; 56+ messages in thread From: Brantley Coile @ 2014-06-05 11:26 UTC (permalink / raw) I ported Unix to the 68000 in the early 1980's and I did what I assume AmigoDOS did; getting a page fault for anything but a stack frame access was fatal to the process. In other worlds, no paging-in a process. The problem for paging was handling side effects from auto increment or decrement access modes. If the faulting instruction used one of those modes, the 68000 didn't provide enough information to do what we did on PDP-11's and simulate the faulted instruction. Nor could it automatically restart the instruction, which was done in the 68010. A process had to be loaded completely before being swtch'ed to, just like in 32v. This left only the fault resulting from the stack meeting to grow. To solve for that problem, we solicited help from the compiler. The function prologue of every function would fetch the farthest used word from the frame pointer. In most cases this would do nothing. For a frame that needed more stack allocated, this would cause a page fault. We looked at the instruction at the faulted program counter, verified it was a "grow me" instruction, allocated more core and put the process back on the run queue. The result of the instruction was ignored, so we didn't need to have the kernel restart it or simulate it. This method wasn't original to me. It was common practice at the time. I assume this the technique used by AmigaDOS. Sent from my iPad > On Jun 5, 2014, at 5:33 AM, "Wesley Parish" <wes.parish at paradise.net.nz> wrote: > > Which of course raises the question: how did AmigaDOS manage context switches > and the like for its brand of multitasking? I know BYTE explained it in the > early 1990s, but I threw away all my BYTEs a couple of decades ago, and don't > remember the details. > > Thanks > > Wesley Parish > > Quoting Arno Griffioen <arno.griffioen at ieee.org>: > >>> On Mon, Jun 02, 2014 at 10:24:48AM -0400, John Cowan wrote: >>> Ronald Natalie scripsit: >>> >>>> Still with all it's flaws, on the 286 and later UNIX actually did >> run in >>>> protected mode, something it took ages for DOS/Windows (one can >> argue >>>> backwards compatibility with the early processors) or Apple (no >> excuse >>>> here, the early Macs were 68000's which had protection) to pick up >> upon. >>> >>> The original Mac 128K was a 68000 processor, and IIRC memory >> protection >>> didn't arrive until the 68020. >> >> As mentioned by others the 68010 could, with additional external >> hardware, >> support memory management. >> >> The original 68000 (and 8-bit data bus 68008) did already have the full >> 32 >> bit instruction and data support of the complete family, but for MMU use >> it >> lacked one critical feature in the fact that it did not push enough >> page-fault >> information on the stack to re-start an instruction in case of an >> (externally >> signalled) page-fault. >> >> So even if you interfaced external MMU logic then a basic 68000 was >> still in >> trouble when a page fault occurred as it could not 'start over' the >> faulted instruction. >> >> The 68010 added the correct stack frames to be able to restart a >> faulted >> instruction and also added the first small performance enhancement in >> the >> form of a 'loop mode' where the CPU could basically cache a small loop >> and execute this without incurring addtional memory wait cycles. >> >> As a result the '010 was usually used in various *NIX machines of the >> era like some SUN2's and various machines (one-offs or low production) >> from other brands. >> >> Eg. I still have a machine in my collection which is from a small local >> >> production run that utilises an '010 with a custom, but quite >> rudimentary, >> MMU based on some simple logic chips and it used to run SVR2. Very >> slowly >> as it had a whopping 1 Mbyte of RAM and the MMU could give you a virtual >> >> memory size of 4 Mbyte. >> >> I did port MINIX to it and added memory management/protection support to >> >> the kernel. Ran a lot faster :) >> >> With the release of the '020 Motorola delivered their own full-blown >> (but >> still external) MMU in the shape of the MC68851 >> >> Many non-UNIX '020 based machines of the era did not have the MC68851 on >> >> board at all (eg. most Apples from the time) as it was relatively >> expensive >> and could incur extra memory latency/cycles being an external unit. >> >> With the '030 Motorola finally moved the MMU onto the same die as the >> CPU >> (reducing the latency and cost) and it became more prevalent on more >> platforms (although the cheaper 68EC030 was available without an MMU and >> >> used in many machines) >> >> Bringing this back to UNIX, I used to do some local supporting work at >> CBM for >> the Commodore UNIX'es that were Amiga, and of course M68k based. >> >> The official Amiga 2000 '020 turboboard (or one of the A2500UX'es like I >> have >> at home :) ) does have both the MC68851 MMU and the MC68881 FPU and >> these >> were used for a, mostly in-house at CBM, SVR3.2 based UNIX version. >> >> AmigaDOS of course also ran fine on it, but did not use the MMU. >> >> The later, general release, SVR4 UNIX version was desgined to run on >> the >> '030 based A3000UX'es, although it still ran on the '020+MMU cards in >> their >> limited (4Mb) DRAM. >> >> Bye, Arno. >> _______________________________________________ >> TUHS mailing list >> TUHS at minnie.tuhs.org >> https://minnie.tuhs.org/mailman/listinfo/tuh s > > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-05 11:26 ` Brantley Coile @ 2014-06-05 13:34 ` Jesus Cea 0 siblings, 0 replies; 56+ messages in thread From: Jesus Cea @ 2014-06-05 13:34 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1507 bytes --] On 05/06/14 13:26, Brantley Coile wrote: > This method wasn't original to me. It was common practice at the > time. I assume this the technique used by AmigaDOS. I have no direct knowledge of AmigaDOS, but since there was no hardware protection between processes and all processes shared the same address space, context switching COULD BE just "store process registers, including stack pointer and Program Counter, for process A", "restore process registers, including stack pointer and program counter from process B". Certainly I did this in the 8 bit era (well, 6502 CPU have the stack in a fixed position but only just 256 bytes long, so I just copy it around when doing context switching) and in Atari ST (68000 based computer). -- Jesús Cea Avión _/_/ _/_/_/ _/_/_/ jcea at jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ Twitter: @jcea _/_/ _/_/ _/_/_/_/_/ jabber / xmpp:jcea at jabber.org _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 538 bytes Desc: OpenPGP digital signature URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140605/fc3e0d8a/attachment.sig> ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-05 9:17 ` Wesley Parish 2014-06-05 11:26 ` Brantley Coile @ 2014-06-11 12:10 ` Michael Parson 2014-06-12 1:20 ` Wesley Parish 1 sibling, 1 reply; 56+ messages in thread From: Michael Parson @ 2014-06-11 12:10 UTC (permalink / raw) On Thu, 5 Jun 2014, Wesley Parish wrote: > Which of course raises the question: how did AmigaDOS manage context switches > and the like for its brand of multitasking? I know BYTE explained it in the > early 1990s, but I threw away all my BYTEs a couple of decades ago, and don't > remember the details. If you want to re-read the original article: https://archive.org/details/BYTE_Vol_10-08_1985-08_The_Amiga -- Michael Parson Austin, TX KF5LGQ ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-11 12:10 ` Michael Parson @ 2014-06-12 1:20 ` Wesley Parish 0 siblings, 0 replies; 56+ messages in thread From: Wesley Parish @ 2014-06-12 1:20 UTC (permalink / raw) Thanks. Will do. Quoting Michael Parson <mparson at bl.org>: > On Thu, 5 Jun 2014, Wesley Parish wrote: > > > Which of course raises the question: how did AmigaDOS manage context > switches > > and the like for its brand of multitasking? I know BYTE explained it > in the > > early 1990s, but I threw away all my BYTEs a couple of decades ago, > and don't > > remember the details. > > If you want to re-read the original article: > > https://archive.org/details/BYTE_Vol_10-08_1985-08_The_Amiga > > -- > Michael Parson > Austin, TX > KF5LGQ > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuh s > ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-05 7:31 ` Arno Griffioen 2014-06-05 8:24 ` emu 2014-06-05 9:17 ` Wesley Parish @ 2014-06-05 15:07 ` Clem Cole 2014-06-05 18:26 ` Ronald Natalie 2 siblings, 1 reply; 56+ messages in thread From: Clem Cole @ 2014-06-05 15:07 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 6339 bytes --] On Thu, Jun 5, 2014 at 3:31 AM, Arno Griffioen <arno.griffioen at ieee.org> wrote: The original 68000 (and 8-bit data bus 68008) did already have the full 32 bit instruction and data support of the complete family, But the original 68000 was actually a 16 bit internal architecture -- is was made with a 16 bit barrel shifter and any 32 bit op took two ticks. Yes, they (fortunately) did define the 32 bit data types and many of the 32 bit operations. There was an argument at the time was it a 16 bit or 32 bit chip and between people implementing compilers - should a C "int" be 16 bits or 32. Since I had hacked the Ritchie PDP-11 compiler for mine, I used 16 bits, while the MIT guys used 32 (I think they were hacking on Steve's if my memory is correct). The advantage of the later was int == ptr and that the time V6 and V7 was definitely pointer "dirty" the worst example being the Bourne shell and how break(2) was implemented. The advantage of the former was it was the natural size of the chip internals and so it made it easier for me to generate "optimal" (well let's just say "better") code plus that's what's Dennis's compiler "knew." Jeff Mogul ended up at Stanford around that time. He and I had a long argument about it when we first met. We each we sure the other was wrong - :-0 Years later when we became colleagues we reminded of the old argument, I think we agreed that other was "right." It was a tough choice and there were good arguments on both sides. BTW: I once asked Les about it during our Stellar time. He said they thought of it as a 16 bit chip - a PDP-11 like system without running into the problem that Cal Data did with "cloning" the 11. Les and team has been using PDP-11's before they joined Moto. But the reality is that UNIX code really wanted int==ptr for a long time [as well as: ptr = 0; *ptr == 0]. That really was not forced to be fixed until Alpha came on the scene and people cleaned up there code. but for MMU use it lacked one critical feature in the fact that it did not push enough page-fault information on the stack to re-start an instruction in case of an (externally signalled) page-fault. True that the original 68000 lacked the instruction restart ability, but the MMU could be made to not need restart. So even if you interfaced external MMU logic then a basic 68000 was still in trouble when a page fault occurred as it could not 'start over' the faulted instruction. As I said this is not completely true - you just never stopped the instruction. The fact is that a 68000 could do VM, but it took a bit of work a external logic. Forest Basket wrote a paper on how to do it and it was actually what both Apollo and Masscomp implemented in this first products. The trick was that the 68000 "CPU" could not complete the instruction when the fault occurred (or as you mentioned - the reason was that bad things happened was because the microcode did not correctly save the internal instruction state). So the "executor" 68000 CPU was sent wait states by the MMU -- in effect forcing it to have a very slow memory read. While it was waiting for the memory to fill, the fault had to be handled by something else. In Masscomp's case (and I believe Apollo also) the "fixer" was another second 68000 that ran in kernel code that handled the fault and refilled the MMU's TLB (or if you we schooled by Digital - the "TB"). At the time Dave Cane and Jeff ??? ( the logic designer sat Masscomp - Jeff's last name now escapes me) had been from the 11/34 and VAX projects previously. They were horrified to have to use a second processor just for memory refills, and spent weeks trying to find a way out but eventually relented to what the SW guys where telling them. As I said, when the '010 came out, Masscomp retrofitted the CPU card to allow the fault to occur and not wait state the CPU. The RTU kernel detected the actual chip being used, and when it was running on a ' 010, would immediately do a task switch on the executor and run some other code, while the fixer handled the fault. I've forgotten now, but my memory is that the fixer always ran out of the cache. BTW: the '010 originally still had VM issues that did not get fixed until the '020. The way Moto handled the fault was to dump the state of the internal microcode to the CPU stack, and when the instruction was restarted, was to suck the state back into the processor. The problem was that as that Moto was updating the microcode in manufacturing not thinking it was an issues for customers a processor with the step logic stepping might have different microcode - which was not a problem for 99% of their customers. However, Masscomp actually made the first dual processor UNIX box - the MC-500/DP which was released about 12 months after the MC-500 (they predated Sequent by about 2-3 years). A couple of months after we started shipping the DP, we started to see a strange failure in the field. The issues was that a fault would occur on one CPU and the kernel would try to restart to the instruction on a different processor, and unless both CPU boards had executor chips from the same manufacturing lot - you had to restart in the same physical chip that took the fault. Because the original RTU DP system was modeled on the Goble Vax, were kernel mode was on one processor at a time and the original DP had a NUMA memory system (the 5000 was SMP with UMA memory). Thus usually, processes tended to get started on one processor and not migrate to the other, but under they could migrate. All the test systems in engineering had matched processors - no problem. But when field service started to swap boards, around at customer sites, bad things started to happen. We had quite the panic figuring out what it was and then forced field service to ensure all CPU cards were matched -- what a pain in the tuckus. With the 5000 when we went full SMP, we screamed at Moto and got them to clean up their act so that what was dumped on the stack could be restarted on any '020 regardless of stepping/microcode etc. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140605/d296f057/attachment.html> ^ permalink raw reply [flat|nested] 56+ messages in thread
* [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') 2014-06-05 15:07 ` Clem Cole @ 2014-06-05 18:26 ` Ronald Natalie 0 siblings, 0 replies; 56+ messages in thread From: Ronald Natalie @ 2014-06-05 18:26 UTC (permalink / raw) On Jun 5, 2014, at 11:07 AM, Clem Cole <clemc at ccc.com> wrote: > We had quite the panic figuring out what it was and then forced field service to ensure all CPU cards were matched -- what a pain in the tuckus. With the 5000 when we went full SMP, we screamed at Moto and got them to clean up their act so that what was dumped on the stack could be restarted on any '020 regardless of stepping/microcode etc. > Sounds like our fun with Intel and their i860 RISC chips. Every chip stepping had it's own "INTEL PROPRIETARY" errata which had fun things like "A store followed by any number of instructions and then a load from the same location may ...." I loved the fact that Intel didn't think it was a good idea to tell people what they had to do to make the chips work. Even when we got the Errata, they were sometimes wrong. I spent a lot of time when stuck calling my contact at the factory and making discrete inquiries which led to things like: Intel: Remember those two NOP instructions we told you to put at the beginning of the ISR? Me: Yes, but the errata sheet says that ceased to be necessary after the B2 stepping of the chip. Intel: Well put them back and perhaps five or six more. Of course they weren't as bad as dealing with some aspects of IBM at the time. Me: There's a bug in the driver for this card. IBM: That's not possible, it's product. Oh, excuse me....there can't possibly be problems in the released product. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140605/06aa8616/attachment.html> ^ permalink raw reply [flat|nested] 56+ messages in thread
end of thread, other threads:[~2014-06-12 1:20 UTC | newest] Thread overview: 56+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-06-02 2:09 [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') Doug McIlroy 2014-06-02 2:24 ` John Cowan 2014-06-02 2:59 ` Warner Losh 2014-06-02 3:17 ` Greg 'groggy' Lehey 2014-06-02 3:37 ` John Cowan 2014-06-02 4:08 ` scj 2014-06-02 5:03 ` Greg 'groggy' Lehey 2014-06-02 12:31 ` Ronald Natalie 2014-06-02 4:04 ` Nick Downing 2014-06-02 4:43 ` John Cowan 2014-06-02 6:23 ` arnold 2014-06-02 17:35 ` John Cowan 2014-06-02 18:44 ` Warner Losh 2014-06-02 18:52 ` John Cowan 2014-06-02 3:18 ` John Cowan 2014-06-02 6:08 ` Steve Nickolas 2014-06-02 12:04 ` Clem Cole 2014-06-02 12:27 ` Ronald Natalie 2014-06-02 13:28 ` Clem Cole 2014-06-02 14:11 ` Tim Bradshaw 2014-06-02 14:25 ` Clem Cole 2014-06-02 14:41 ` John Cowan 2014-06-02 14:50 ` Armando Stettner 2014-06-02 18:27 ` Brantley Coile 2014-06-02 18:52 ` Dan Cross 2014-06-02 19:10 ` arnold 2014-06-03 1:45 ` Brantley Coile 2014-06-02 19:30 ` John Cowan 2014-06-02 19:54 ` Dan Cross 2014-06-02 23:37 ` John Cowan 2014-06-03 1:24 ` Dan Cross 2014-06-03 2:16 ` John Cowan 2014-06-03 2:18 ` Dan Cross 2014-06-02 19:47 ` Chris Nehren 2014-06-02 20:23 ` Dan Cross 2014-06-03 18:48 ` [TUHS] Evolutionary Paths (was Gnu/Stallman (was Bugs in V6 'dcheck')) scj 2014-06-04 1:10 ` Larry McVoy 2014-06-04 3:42 ` Greg Chesson 2014-06-05 0:43 ` Larry McVoy 2014-06-02 21:08 ` [TUHS] Gnu/Stallman (was Bugs in V6 'dcheck') Charlie Kester 2014-06-03 0:37 ` Tim Newsham 2014-06-02 20:06 ` Jacob Goense 2014-06-02 14:26 ` arnold 2014-06-02 14:30 ` John Cowan 2014-06-02 14:24 ` John Cowan 2014-06-02 14:29 ` Ronald Natalie 2014-06-02 14:37 ` Clem Cole 2014-06-05 7:31 ` Arno Griffioen 2014-06-05 8:24 ` emu 2014-06-05 9:17 ` Wesley Parish 2014-06-05 11:26 ` Brantley Coile 2014-06-05 13:34 ` Jesus Cea 2014-06-11 12:10 ` Michael Parson 2014-06-12 1:20 ` Wesley Parish 2014-06-05 15:07 ` Clem Cole 2014-06-05 18:26 ` Ronald Natalie
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).