For a presentation I'm doing this summer on FreeBSD, I thought it would be
cool to get the kernel sizes for various old flavors of Unix. I see numbers
for v5, v6 and v7 in the tuhs tree view, and it appears these versions are
complete enough for me to extract the kernels themselves. However, I see
nothing prior to that. The archives seem to be somewhat incomplete, but I'm
wondering if people have sizes for earlier versions. Later versions are
more problematic because they move to new hardware, instruction sets, etc.
For this graph to be meaningful, it would need to be pdp-11 only, though
I'm of the opinion more data is better than less. I'll also be extracting
the different V7 commercial kernels: V7M, Ultrix and Venix and the BSD 2.x
releases, but those appear to be intact enough in the archives to extract
data on my own. I've heard rumors there's a SysV for the pdp-11, but I've
not been able to locate images for that. I don't need the actual images,
just sizes with some reference for the source of the data. It's just for
one slide in the talk, so I don't want to burn a ton of time on it...
The larger picture is that I've written what's effectively modprobe for
FreeBSD and will be talking about it in detail. How it's like modprobe, how
it's different, how all the pieces fit together, history of similar
efforts, etc. Part of the driving force here is the bloated FreeBSD GENERIC
kernel.
Of course, I'll share the final report I'm planning on sizes with the group.
Thanks for any data you can provide.
Warner
> A self-imposed limit of 16K held in v1, and was quite fully utilized.
> When the iernel was rewritten in C, the limit (perhaps larger by then)
> influenced the C compiler. More than one optimization was stimulated
> by the need to keep the kernel in bounds.
>
> Doug
The LSX kernel was kept within a self-imposed limit of 16KB as well.
I've often thought that LSX was V5 'regressed' to the concepts of
V1, which was facing similar hardware constraints. Is that a
reasonable view?
For example, LSX has a maximum of three processes that are swapped
in and out in a stack-like fashion. Only one process is ever in core.
Is that how V1 was organized?
I realize that LSX was API compatible with V5/V6 and I don't mean
'regressed' in that sense.
Paul
> I seem to remember that at some point early on, we spent some of our
> capital budget on buying another 16K bytes for the PDP-11. As I
> recall, the deal was that the OS got 8K and users got 8K. I also
> recall that that purchase was 20% of our capital budget for the
> year...
> Doug, did I remember this correctly?
> Steve
Things did happen that way. I don't specifically remember the
numbers, but those you state have the ring of truth.
Memory came in (expensive) 4K increments. When the keepers of
Unix in the Charlotte wire center wanted to add 4K, their
management consented only on the condition that the wizards
in Research would confirm that roposed new functionality
really required it.
doug
A self-imposed limit of 16K held in v1, and was quite fully utilized.
When the iernel was rewritten in C, the limit (perhaps larger by then)
influenced the C compiler. More than one optimization was stimulated
by the need to keep the kernel in bounds.
Doug
Sorry for the off topic post.
I'm hoping that someone here might have seen a (what I consider to be) a
computer lore type story about a contractor that was brought in part way
through a project to consolidate three DCs into one. - In the end he
managed to do it early and under budget. The kicker is that they quite
literally physically moved and re-connected everything the way that it
was. Meaning that there were still WAN circuits (local only of course)
between equipment that was previously in different DCs.
I would like to find a copy of this story and save it in my archive. But
I've not been able to do so. Thus I'm asking a wider audience to see if
anyone might be able to give me a pointer.
--
Grant. . . .
unix || die
We lost Ed Yourdon on this day in 2016; a computer pioneer, he helped to
design the underpinnings of relational databases, and pretty much wrote
the book.
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
Dr. Prof. John Lions was born on this day in 1937; I had the pleasure of
having him as one of my Computer Science lecturers in the early 70s, and
he drilled into us the Principle of Least Astonishment (or POLA), better
known as "why the fsck did it do that?" (but he was far too genteel to
express it that way). And yes, that's my name in the credits; I helped
with the proof-reading and provided the use of the high-quality printer in
the CSU.
You are not expected to understand this.
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
Scot Hacker has re-published his BeOS columns for Byte. BeOS was an interesting operating system with a clear Unix inheritance built for a dual-PowerPC system, similar to the Macs of that era.
http://birdhouse.org/beos/byte/
Its inheritance can be found in Haiku (https://www.haiku-os.org)
Arrigo
All,
While it's fresh, I thought I'd share some resources I've found helpful
in learning about the venerable v6 as a relative newb...
Learning Unix V6 in the modern era is an interesting and enormously
educational experience. In the process of using it I have had to learn
how to host it in a simulator (SimH in my case, but there are others),
install it, communicate with it, configure it, build special files for
it, attach devices to it, communicate with the devices attached to it
and to SimH, build a kernel, install the kernel, boot the kernel, work
with a variety of media intended to work with it, extend it, and so on.
In addition, I have had to learn a bit about the PDP-11 (as arguably the
most convenient architecture for learning about V6), about its
architecture, its instruction set, its devices, its memory structure,
and so on.
None of this exploration would have been possible without the excellent
work of Bob Supnik, Mark Pizzolato, and co. on the SimH pdp-11
simulator, the Simh mailing list, Warren Toomey and TUHS for making the
bits available, the TUHS mailing list, PUPS, Bitsavers, and a slew of
readily available documentation and texts including these notables:
Setting Up Unix 6th Edition from the V6 Programmer's Manual
The Unix V6 Programmer's Manual in its entirety
The SimH and SimH PDP-11 Manuals
A large number of blogs with SimH specific V6 installation logs
The V6 Source Code and man pages (don't forget to install man - the 1bsd
version works, and is superior)!
The DEC PDP-11/05-10-35-40 1973 Handbook (the 11/40 handbook is not as
detailed with respect to memory management)
Lions's Commentary on the Sixth Edition source code
Now that I'm over the beginner's hump, so to speak, I'm exploring things
differently and I thought I'd share some resources that I am currently
finding useful and interesting in my explorations...
To bone up on assembly language, Lions's commentary is exceptionally
helpful in explaining assembly as it is implemented in V6. The manual
itself is really thin, and the source is a bit cryptic, for the
newcomer. Lions explains the idioms used in the main source of V6.
However, without a background in assembly language, Lions is pretty
meaningless, so I went looking for something that was PDP specific that
would bridge the gap and help me understand Lions's words. I found a
number of texts that were really good. Most require a working RT11
instance to actually try out the coding examples and do the exercises
(SimH and Bitsavers to the rescue):
Arthur Gill - Machine and Assembly Language Programming of the Pdp-11
Charles A. Kapps and Robert L. Stafford - Assembly Language for the PDP-11
Glenn H. MacEwan - Introduction to Computer Systems: Using the PDP-11
and Pascal
James F. Peters - The Digital Way: Macro-11 Assembler Programming (PDP-11)
Michael G. Schneider - The Principles of Computer Organization: With
Assembly Language Programming for the PDP-11
PDP-11 Processor Handbook (pretty much any edition)
Thomas A. Frank - Introduction to the PDP-11 and its Assembly Language
All of these are useable with a running RT11 instance. But, I think the
Peters and Frank books are the standouts. Peters because all of the
exercises that I have tried (dozens) have worked as printed and Frank
because he is rigorous in his treatment of the subject and builds up
from digital logic all the way through program execution. Frank is an
excellent complement to Lions work because he explains the details that
Lions assumes.
To learn about digital logic, and a special thanks to Warren for his
work on Crazy Small CPU, I have been introduced to logisim. It is a
great playground for exploring digital logic. I had no idea that a
sketchpad for digital logic simulation was available and accessible to
the layperson. Logisim development stopped around 2014 and while there
are a number of successors out there, I am using logisim-evolution:
https://github.com/reds-heig/logisim-evolution
The rabbit trails never seem to end... in order to learn how to use
logisim, I went through the excellent tutorial and then went looking for
a book of experiments in digital logic and found:
digital computer lab workbook from 1969
http://bitsavers.trailing-edge.com/pdf/dec/handbooks/Digital_Computer_Lab_W…
digital equipment corporation computer lab teacher's guide from 1968
http://www.so-much-stuff.com/pdp8/pdf/ComputerLabTeachersGuide.pdf
These two are useable with very little modification as a source of
digital logic exercises that work great with logisim and are related to
the architectural lineage of the PDP-11.
These resources fit together nicely in my pursuit to better understand
digital logic, the pdp-11, assembly language, and unix v6. In sum:
Source code for v6 for what really is supposed to happen in v6 operation
Lions for understanding Unix V6 sources and for unix assembly language
information
PDP-11 Hanbook for quick reference on PDP-11 assembly language
instruction set
Frank for assembly language details and for details on digital logic and
its relationship to the PDP-11 architecture.
Logisim to test logic constructs
The digital lab workbook for practice with digital logic
Later,
Will
--
GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF
Hi all, Happy New Year. As it's now only eighteen months to the Unix 50th
Anniversary, I thought I'd poll you all to get an update of what is being
done to celebrate the anniversary, and/or what could we organise that has
not yet been organised.
Cheers, Warren
Sir Charles Antony Richard Hoare FRS FREng was born on this day in 1934; a
computer pioneer (one of the greats) he gave us things like the quicksort
algorithm and ALGOLW (a neat language).
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
Computer pioneer Donald Knuth was born on this day in 1938; amongst other
things he gave us the TeX typesetting language, and he's still working on
"The Art Of Computer Programming" fascicles (I only got as far as the
first two volumes).
I really must have a look at his new MMIX, too; I love learning new
programming languages (I've used about 50 the last time I looked, and I'm
happy to post a list for my coterie of disbelievers).
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
> I will be happy to forward pertinent suggestions.
Here's one. If Bell Labs holds some kind of symposium on
the lines of the dmr memorial, how about a plenary
session with TV participation from remote venues (think
Berkeley/Silicon Valley and Wollongong/Sydney--a nine-hour
span of time zones).
Any thoughts about this or other possibilities?
Doug
I don't think I'm violating anyone's confidentiality by revealing that
Marcus Weldon, current president of the Labs, at the suggestion of
Martin Carroll, expects the Labs to embark soon on plans to mark
the occasion. I, and no doubt Martin, will keep you posted. Meanwhile
I will be happy to forward pertinent suggestions.
Doug
We lost a co-inventor of ENIAC, John Mauchly, on this day (that's 8th
January like my headers say) in 1980. ENIAC is claimed to be the "first
general purpose electronic digital computer", but I guess it comes down to
a matter of definition[*], as every culture likes to be the "first" (just
ask the Penguins, for example); for "computer" you could go all the way
back to the Mk-I Antikythera (Hellenic variation, from about the 100BC
production run)...
[*]
Analogue/digital/hybrid
Mechanical/electrical/electronic/hybrid
General/special
Wired/programmable/Turing
Prototype/production
Harvard/Neumann/quantum
Etc...
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
> From: Andy Kosela
> it appears this is a fundamental Intel bug that exists in all x86_64
> CPUs.
I'm highly amused by the irony. Intel throws bazillions of transistors at
these hyper-complex CPUs in an attempt to make them as fast as possible - and
(probably because of the complexity) missed a bug, the fix for which
involves... slowing things way down!
I wonder how many other bugs are lurking in these hyper-complex designs?
Didn't anyone at Intel stop to think that complexity is bad, in and of itself?
But I guess the market demands for faster and faster machines outweighed that
- until it bit them in the posterior. The real question is 'how many more times
will it have to happen before they get a clue'?
There's an interesting parallel between this, and uSloth's struggle with
security and bugs. For a long time, it seemed it was more important to the
market to add features (i.e. complexity), and security be damned - until poor
security really started to become an issue.
So now they're trying to catch up - but seemingly still haven't got there, in
terms of the fundamental architecture of the OS, as the never-ending stream of
bug patches attests.
The sad thing is that how to provide good security (not perfect, but much,
much better than what we have) was worked out a long time ago, and Intel hired
Roger Schell to add the necessary hardware underpinnings when they did the
386:
http://conservancy.umn.edu/bitstream/11299/133439/1/oh405rrs.pdf
Mutatis mutandis.
Noel
Clem Cole:
IIRC this is part of the argument Dykstra made with the THE paper years
ago, Parnas in his information hiding paper -- i.e. why microkernels and
proper layering are a good idea. Keep is simple and do one thing
well/protect yourself against other subsystems not being 100%.
=====
Indeed. Complexity creates needless RISC, er, risk.
Norman Wilson
Toronto ON
http://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
Including here as it concerns Unix kernel and leaking memory from kernel
space to userland.
This is big -- it appears this is a fundamental Intel bug that exists in
all x86_64 CPUs.
It will be interesting to watch the ramifications and impact of this on the
industry as a whole.
--Andy
> A lingering gripe that explains my latent anti-Americanism goes back to
> when I had to support Uniplus 2.2/2.4 (sorta SysIII-ish) on the WICAT boxes
> in here in Australia. At installation time, we had to express the time
> offset as hours *west* of GMT; this left me with a lingering belief that
> Americans didn't want to be perceived as being backwards (yeah. it saved an
> entire keystroke out of the dozens that were otherwise required).
But east postive is an artifact of north up. I remember Australian
souvenir shops selling maps on "MacQuarrie's corrective projection",
in which south is up. In fact this orientation was not uncommon in
Europe between medieval maps that really were oriented, with east up,
and later convention that put north up and shoved Australia down under.
Surely an Aussie would prefer south up and west positive!
Doug
On Sun, Dec 31, 2017 at 7:15 PM, Dave Horsfall <dave(a)horsfall.org> wrote:
>
> A lingering gripe that explains my latent anti-Americanism goes back to
> when I had to support Uniplus 2.2/2.4 (sorta SysIII-ish) on the WICAT boxes
> in here in Australia. At installation time, we had to express the time
> offset as hours *west* of GMT; this left me with a lingering belief that
> Americans didn't want to be perceived as being backwards (yeah. it saved an
> entire keystroke out of the dozens that were otherwise required).
Dave I'm not so sure it's about being perceived as forward or backwards -
its just shallow, provincial and often lazy because the program did not
really knowing any better. The problem is too many American',
(particularly younger ones that experience our 'excellent' educational
system), have often never travelled that much and experiences other places,
cultures or social norms.
I admit this is extreme example, but about 8 years ago, my daughter had a
friend, who was approx 16 at the time, that we took to the big city
(Boston) to play in a orchestra concert at Symphony Hall when they both
were named 'All State' for the instruments. I don't remember why said
friends family did not/could not come - but it made sense and we said we
would take her with us. On the drive in-town, we were talking with her and
I discovered that she had never gone to Boston before ... ever -- she was
excited to see it (we live less than 1hr North mind you. Note quite the
boon-docks). She had not gone to a 'Bo Sox' game or anything. Never went
to the Science Museum, etc. She grew up in her town (mind you happy) and
using TV as her window to world.
Which brings me to >>my complaint<<. We, as American's, project so much
about 'us' via TV. The said truth is most Americans are not like what they
see on TV [e.g. Rice-A-Roni is made up!!, Benihana's is an American
invention, and "the big yellow school bus" is dirty/noisy and usually
without seat belts]. Sadly, many Americans do not know any better - queue
the famous quote about never under-estimating the taste of the American
public. But think about what folks outside the US see and think? Many of
my European friends in particular all want to visit NYC. [I tell them all,
visit Boston or Philadelphia first if you can. Those cities are much more
representative of America then LA, NYC or Dallas; if for no other reason
they are more 'European' in feel].
When I run into things like what you just described (and I seem to run into
then most often with MicroSoft based tools), I think to myself, it must
have been a cold day in Redmond, WA and some programmer did not want to
make an effort to do make her/his solution really general ;-)
Clem
FWIW: Not only did we take my kids all over the world as children, we
brought the world to them by sponsoring kids from all sorts of countries.
But I fear, my wife and I are less the norm then I would wish.
ᐧ
ᐧ
> From: Dave Horsfall
> What timezone did you say you were in again?
Ah; didn't realize you wanted the exact time, not just a date! :-)
Well, according to this:
http://www.rfc-editor.org/rfc/museum/ddn-news/ddn-news.n19.1
it was _planned_ to happen at "00:01 (EST) 1 Jan 1983". Whether it did happen
at that moment, or if in reality there was some variance, I don't know (IIRC,
I was off sailing in the Caribbean when it actually happened :-).
Noel