Hi.
Can a modern BSD guru please contact me off-list? I have a set of related
tests in the gawk test suite that consistently fail on just about every
*BSD system. It has me stumped, and I'd like to see these tests working
if possible.
(They've been not working for quite a while. That I get no complaints
from BSD users tells me that gawk isn't popular in that world, but that's
another story. :-)
Thanks,
Arnold
Re: [TUHS] Kernel Sizes
> 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?
> 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?
The rocess limit was higher in V1. And V1 was a time-sharing
system; for which LIFO swapping is inappropriate. So LSX
seems to have "regressed" to some pre-Unix state.
doug
16K kernels?
Well, I came late to the UNIX world. I only remember getting a SCO
UNIX 3.2V4.2 kernel onto a single 3-1/2" diskette and still have all I
wanted including (with scripts on a second diskette of course :-) ).
That was 25 years ago.
Mind you, from there I moved to Digital UNIX /vmunix 9,613.712, Tru64
17.930.976 to HP-UX 11iv2 66.161.464 and HP-UX 11iv3 127.929.032
Of course, I also got lots more functionality I'm supposed to want and need :-)
Cheers,
rudi
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."