[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')

[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')

[Doug McIlroy]

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

[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')

[John Cowan]

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

[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')

[Warner Losh]

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

[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')

[Greg 'groggy' Lehey]

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>

[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')

[John Cowan]

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>

[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')

[scj]

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

[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')

[Greg 'groggy' Lehey]

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>

[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')

[Ronald Natalie]

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

[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')

[Nick Downing]

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>

[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')

[John Cowan]

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

[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')

[arnold]

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

[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')

[John Cowan]

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

[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')

[Warner Losh]

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

[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')

[John Cowan]

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

[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')

[John Cowan]

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

[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')

[Steve Nickolas]

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

[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')

[Clem Cole]

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

[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')

[Ronald Natalie]

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.

[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')

[Clem Cole]

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

[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')

[Tim Bradshaw]

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>

[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')

[Clem Cole]

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>

[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')

[John Cowan]

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] Gnu/Stallman (was Bugs in V6 'dcheck')

[Armando Stettner]

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] Gnu/Stallman (was Bugs in V6 'dcheck')

[Brantley Coile]

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

[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')

[Dan Cross]

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>

[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')

[arnold]

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

[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')

[Brantley Coile]

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

[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')

[John Cowan]

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_

[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')

[Dan Cross]

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>

[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')

[John Cowan]

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

[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')

[Dan Cross]

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>

[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')

[John Cowan]

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

[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')

[Dan Cross]

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>

[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')

[Chris Nehren]

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>

[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')

[Dan Cross]

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>

[TUHS] Evolutionary Paths (was Gnu/Stallman (was Bugs in V6 'dcheck'))

[scj]

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

[TUHS] Evolutionary Paths (was Gnu/Stallman (was Bugs in V6 'dcheck'))

[Larry McVoy]

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

[TUHS] Evolutionary Paths (was Gnu/Stallman (was Bugs in V6 'dcheck'))

[Greg Chesson]

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>

[TUHS] Evolutionary Paths (was Gnu/Stallman (was Bugs in V6 'dcheck'))

[Larry McVoy]

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 

[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')

[Charlie Kester]

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

[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')

[Tim Newsham]

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

[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')

[Jacob Goense]

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.

[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')

[arnold]

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

[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')

[John Cowan]

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

[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')

[John Cowan]

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

[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')

[Ronald Natalie]

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.

[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')

[Clem Cole]

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

[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')

[Arno Griffioen]

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] Gnu/Stallman (was Bugs in V6 'dcheck')

[emu]

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

[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')

[Wesley Parish]

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] Gnu/Stallman (was Bugs in V6 'dcheck')

[Brantley Coile]

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

[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')

[Jesus Cea]

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

[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')

[Michael Parson]

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] Gnu/Stallman (was Bugs in V6 'dcheck')

[Wesley Parish]

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
>  

[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')

[Clem Cole]

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

[TUHS] Gnu/Stallman (was Bugs in V6 'dcheck')

[Ronald Natalie]

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>