[TUHS] How Unix brings people together, or it's a small

[TUHS] How Unix brings people together, or it's a small

[Doug McIlroy]

>  Lots of commands are now little shells
...
> Linux today is much more like the systems
> Unix displaced than it is like Unix

So depressingly true!

Doug

[TUHS] How Unix brings people together, or it's a small

[Marc Rochkind]

Of course. Linux is:

1. old,
2. designed by a huge group,
3. intended to serve many purposes

UNIX was, at least in its early days, the opposite in all three ways. But,
after 15 years or so, it also was numbers 1 - 3. (Speaking of System V
here.)

There have been OSes that remained beautifully sleek and uncluttered
forever. Such as BeOS. However, all such systems failed to achieve critical
mass. Which is why they remained true.

No way out of this trap.

--Marc

On Mon, Feb 6, 2017 at 8:03 PM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:

>
> >  Lots of commands are now little shells
> ...
> > Linux today is much more like the systems
> > Unix displaced than it is like Unix
>
> So depressingly true!
>
> Doug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170206/1c64496f/attachment.html>

[TUHS] How Unix brings people together, or it's a small

[Clem Cole]

And I think it has been peed on by many different people trying to leave
their own mark on it along the way.

On Mon, Feb 6, 2017 at 11:06 PM, Marc Rochkind <rochkind at basepath.com>
wrote:

> Of course. Linux is:
>
> 1. old,
> 2. designed by a huge group,
> 3. intended to serve many purposes
>
> UNIX was, at least in its early days, the opposite in all three ways. But,
> after 15 years or so, it also was numbers 1 - 3. (Speaking of System V
> here.)
>
> There have been OSes that remained beautifully sleek and uncluttered
> forever. Such as BeOS. However, all such systems failed to achieve critical
> mass. Which is why they remained true.
>
> No way out of this trap.
>
> --Marc
>
> On Mon, Feb 6, 2017 at 8:03 PM, Doug McIlroy <doug at cs.dartmouth.edu>
> wrote:
>
>>
>> >  Lots of commands are now little shells
>> ...
>> > Linux today is much more like the systems
>> > Unix displaced than it is like Unix
>>
>> So depressingly true!
>>
>> Doug
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170207/c4150dfc/attachment.html>

[TUHS] How Unix brings people together, or it's a small

[Steve Johnson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2851 bytes --]

Looking back, the social dynamics of the Unix group helped a lot in
keeping the bloat small.   The rule was, whoever touches something
last becomes its owner.  Of course, we were all free to complain
about things, and did, but the amalgamation of tinkerings that
characterizes most of the Linux commands just didn't happen.  At
times this hot-potato activity worked very well.  In a moment of
inspiration I thought up the syntax for the 'at' command  (  "at 3am
cc -o *.c", etc. ).  I implemented it as a shell script and it was
pretty feeble.  My implementation lasted about a week -- I came in on
a Monday and Dennis had plugged the majority of the holes -- got the
permissions right, saved the search path and current directory, etc. 
I think we were both happy with the process...

I think the other thing we understood was that if you added an on/off
option to your application you had a choice of either doing twice as
much testing as previously, or testing both configurations of the code
half as much.   If you look at the gcc manual, you can see the
result -- many dozen pages just listing the options.  It's probably
up around the age of the universe now to reliably test the whole
thing.   And it seems like if you set the options differently than
usual, thing break, can't be debugged reliably, or something else
surprising.  One rule with Linux: do it vanilla or go home...

Steve

----- Original Message -----
From:
 "Clem Cole" <clemc at ccc.com>

To:
"Marc Rochkind" <rochkind at basepath.com>
Cc:
"TUHS main list" <tuhs at minnie.tuhs.org>
Sent:
Tue, 7 Feb 2017 18:10:52 -0500
Subject:
Re: [TUHS] How Unix brings people together, or it's a small

And I think it has been peed on by many different people trying to
leave their own mark on it along the way.

On Mon, Feb 6, 2017 at 11:06 PM, Marc Rochkind <rochkind at basepath.com
[1]>
 wrote:
Of course. Linux is:

1. old,
2. designed by a huge group,
3. intended to serve many purposes

UNIX was, at least in its early days, the opposite in all three ways.
But, after 15 years or so, it also was numbers 1 - 3. (Speaking of
System V here.)

There have been OSes that remained beautifully sleek and uncluttered
forever. Such as BeOS. However, all such systems failed to achieve
critical mass. Which is why they remained true.

No way out of this trap.

--Marc

On Mon, Feb 6, 2017 at 8:03 PM, Doug McIlroy <doug at cs.dartmouth.edu
[2]>
 wrote:

 >  Lots of commands are now little shells
 ...
 > Linux today is much more like the systems
 > Unix displaced than it is like Unix

 So depressingly true!

 Doug

 

Links:
------
[1] mailto:rochkind at basepath.com
[2] mailto:doug at cs.dartmouth.edu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170207/3866b843/attachment.html>

[TUHS] Code bloat (was: How Unix brings people together, or it's a small...)

[Greg 'groggy' Lehey]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1031 bytes --]

On Tuesday,  7 February 2017 at 15:38:40 -0800, Steve Johnson wrote:
> Looking back, the social dynamics of the Unix group helped a lot in
> keeping the bloat small.   The rule was, whoever touches something
> last becomes its owner.  Of course, we were all free to complain
> about things, and did, but the amalgamation of tinkerings that
> characterizes most of the Linux commands just didn't happen. 

Out of interest: where do you (or others) consider that the current
BSD projects it in this comparison?

Greg
--
Sent from my desktop computer.
Finger grog at lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170208/0c1ee58e/attachment.sig>

[TUHS] Code bloat (was: How Unix brings people together, or it's a small...)

[Nick Downing]

This is an issue that interests me quite a bit, since I was running
FreeBSD in an effort to get around Linux bloat problems discussed.
Well not that I really mind Linux as a user interface / runtime
environment / main development machine, but I think it probably
shouldn't be used as a "least common denominator" for development
since you end up introducing unwanted dependencies on a whole lot of
stuff.

So I was running FreeBSD as a more minimal *nix. I did quite a lot of
interesting stuff with FreeBSD such as setting up diskless
workstations in my home, etc. I spent a lot of time tinkering around
in the kernel code. I was planning to do some serious development on
4.4BSDLite or FreeBSD to create an operating system more to my liking.
So, I was looking carefully at differences since ancient *nixes.

And, I can say that FreeBSD is pretty bloated. Umm well they've added
SMP, at the time it was using the Giant Lock although that could be
fixed by now. They've added VFS and NFS of course. They've added an
entire subsystem for block devices IIRC that handles partitioning and
possibly some other sophisticated stuff, which I believe is their own
design. Umm the kqueues and I believe they have their own
implementation of kernel threading or lightweight processes including
some sort of idle daemon. The network stack is heavily upgraded, to
the extent I looked into it, the added features are things you would
want (syncookies = DOS protection, etc) but also could not possibly be
called minimal, and would preclude running it on other than a
multi-megabyte machine. They have multiple ABIs so the kernel can
accept Linux or BSD syscalls or whatever else (I used it to run
Acrobat Reader Linux on my FreeBSD desktop). Umm I am pretty sure they
have kernel modules ala Linux. Lots and lots and lots of stuff... and
that's only considering the kernel. If you look in the ports
collection you see they have incredible amounts of bloat there too...
for instance GNOME, Libreoffice, LATEX, gcc, python... not that I'm
denigrating these tools, since they do invaluable work and I use them
every day, but the point is, you CANNOT call them minimal.

The quest for a clean minimal system goes on ->. FreeBSD is not the
answer. In fact I believe 4.3BSD-Reno and 4.4 go strongly offtrack.

cheers, Nick

On Wed, Feb 8, 2017 at 1:55 PM, Greg 'groggy' Lehey <grog at lemis.com> wrote:
> On Tuesday,  7 February 2017 at 15:38:40 -0800, Steve Johnson wrote:
>> Looking back, the social dynamics of the Unix group helped a lot in
>> keeping the bloat small.   The rule was, whoever touches something
>> last becomes its owner.  Of course, we were all free to complain
>> about things, and did, but the amalgamation of tinkerings that
>> characterizes most of the Linux commands just didn't happen.
>
> Out of interest: where do you (or others) consider that the current
> BSD projects it in this comparison?
>
> Greg
> --
> Sent from my desktop computer.
> Finger grog at lemis.com for PGP public key.
> See complete headers for address and phone numbers.
> This message is digitally signed.  If your Microsoft mail program
> reports problems, please read http://lemis.com/broken-MUA

[TUHS] Code bloat (was: How Unix brings people together, or it's a small...)

[Jason Stevens]

What about NetBSD 1.1 or even 386BSD?

There never was a 4.2 or 4.3 for i386 was there?

I'd guess the 32v userland could be built on early 4.4BSD Lite/NET2 greatly reducing its footprint.



On February 8, 2017 11:47:03 AM GMT+08:00, Nick Downing <downing.nick at gmail.com> wrote:
>This is an issue that interests me quite a bit, since I was running
>FreeBSD in an effort to get around Linux bloat problems discussed.
>Well not that I really mind Linux as a user interface / runtime
>environment / main development machine, but I think it probably
>shouldn't be used as a "least common denominator" for development
>since you end up introducing unwanted dependencies on a whole lot of
>stuff.
>
>So I was running FreeBSD as a more minimal *nix. I did quite a lot of
>interesting stuff with FreeBSD such as setting up diskless
>workstations in my home, etc. I spent a lot of time tinkering around
>in the kernel code. I was planning to do some serious development on
>4.4BSDLite or FreeBSD to create an operating system more to my liking.
>So, I was looking carefully at differences since ancient *nixes.
>
>And, I can say that FreeBSD is pretty bloated. Umm well they've added
>SMP, at the time it was using the Giant Lock although that could be
>fixed by now. They've added VFS and NFS of course. They've added an
>entire subsystem for block devices IIRC that handles partitioning and
>possibly some other sophisticated stuff, which I believe is their own
>design. Umm the kqueues and I believe they have their own
>implementation of kernel threading or lightweight processes including
>some sort of idle daemon. The network stack is heavily upgraded, to
>the extent I looked into it, the added features are things you would
>want (syncookies = DOS protection, etc) but also could not possibly be
>called minimal, and would preclude running it on other than a
>multi-megabyte machine. They have multiple ABIs so the kernel can
>accept Linux or BSD syscalls or whatever else (I used it to run
>Acrobat Reader Linux on my FreeBSD desktop). Umm I am pretty sure they
>have kernel modules ala Linux. Lots and lots and lots of stuff... and
>that's only considering the kernel. If you look in the ports
>collection you see they have incredible amounts of bloat there too...
>for instance GNOME, Libreoffice, LATEX, gcc, python... not that I'm
>denigrating these tools, since they do invaluable work and I use them
>every day, but the point is, you CANNOT call them minimal.
>
>The quest for a clean minimal system goes on ->. FreeBSD is not the
>answer. In fact I believe 4.3BSD-Reno and 4.4 go strongly offtrack.
>
>cheers, Nick
>
>On Wed, Feb 8, 2017 at 1:55 PM, Greg 'groggy' Lehey <grog at lemis.com>
>wrote:
>> On Tuesday,  7 February 2017 at 15:38:40 -0800, Steve Johnson wrote:
>>> Looking back, the social dynamics of the Unix group helped a lot in
>>> keeping the bloat small.   The rule was, whoever touches something
>>> last becomes its owner.  Of course, we were all free to complain
>>> about things, and did, but the amalgamation of tinkerings that
>>> characterizes most of the Linux commands just didn't happen.
>>
>> Out of interest: where do you (or others) consider that the current
>> BSD projects it in this comparison?
>>
>> Greg
>> --
>> Sent from my desktop computer.
>> Finger grog at lemis.com for PGP public key.
>> See complete headers for address and phone numbers.
>> This message is digitally signed.  If your Microsoft mail program
>> reports problems, please read http://lemis.com/broken-MUA

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170208/22bf1237/attachment-0001.html>

[TUHS] Code bloat (was: How Unix brings people together, or it's a small...)

[Wesley Parish]

IIRC, 386BSD was based on 4.3BSD, though I forget which one. Anyone have a
better memory than me?

Again, IIRC, Bill Jolitz in his DDJ articles mentions how the 386BSD kernel is
smaller than the Mach microkernel.

Thanks

Wesley Parish

Quoting Jason Stevens <jsteve at superglobalmegacorp.com>:

> What about NetBSD 1.1 or even 386BSD?
> 
> There never was a 4.2 or 4.3 for i386 was there?
> 
> I'd guess the 32v userland could be built on early 4.4BSD Lite/NET2
> greatly reducing its footprint.
> 
<snip>



"I have supposed that he who buys a Method means to learn it." - Ferdinand Sor,
Method for Guitar

"A verbal contract isn't worth the paper it's written on." -- Samuel Goldwyn

[TUHS] Code bloat (was: How Unix brings people together, or it's a small...)

[Steve Nickolas]

On Wed, 8 Feb 2017, Wesley Parish wrote:

> IIRC, 386BSD was based on 4.3BSD, though I forget which one. Anyone have a
> better memory than me?
>
> Again, IIRC, Bill Jolitz in his DDJ articles mentions how the 386BSD kernel is
> smaller than the Mach microkernel.

Net/2, wasn't it?

I suppose if it's close to any complete release of BSD it's probably 
4.3-Reno...

-uso.

[TUHS] Code bloat (was: How Unix brings people together, or it's a small...)

[Nick Downing]

Yes, NetBSD and 386BSD are interesting. They could well form a good
basis for a minimal but fully functional OS for a modern platform. One
reservation I have though, is as follows: When 386BSD and its
derivatives like OpenBSD, NetBSD, FreeBSD came out, Unix was still
encumbered and thus they had to be based on 4.4BSD Lite (not even
NET/2 was safe). Nobody made an unencumbered version of say 4.3BSD or
even NET/2, even though it was theoretically possible, by examining
what had to be taken out/added to produce 4.4BSD Lite.

Given that Unix is now unencumbered I believe there is no point
adopting 4.4, or even 4.3Reno, because the main thing done in those
releases as far as I know, is to add partial POSIX compliance. But if
you want POSIX compliance you will not achieve minimality. As an
example consider the BSD sigvec() routine. POSIX calls this
sigaction(), the old SV_ONSTACK flag becomes SA_ONSTACK, the old
integer mask becomes a sigset_t and so on... and in any reasonable
POSIX compliant BSD the two calls are gonna have to coexist, etc.

As to 32V, I appreciate your idea, as I was having some similar
thoughts myself. However I personally wouldn't use 32V as a basis for
any serious porting work, because I would assume V7 and 4.3 are much
more stable and well tested, since they ran in a lot of installations
over a long time. That's not to denigrate the huge achievement in
porting V7 to the VAX and producing 32V, but it probably has some
rough edges that were smoothed out over time to produce the 4BSDs. The
situation is a bit different for kernel/toolchain/other userspace.

As to the kernel I have been trying to make a detailed comparison
between 32V and the BSDs, but have been a bit put off by the fact that
all files moved around and may have been renamed, I will figure it all
out eventually though. As to the toolchain I have compared it quite
carefully with 4.3BSD, and I conclude you should use the later
toolchain as there is no disadvantage and some advantages to doing so.
As to the rest of the userspace, I BELIEVE that it's stock V7 with any
32-bit issues fixed, but I suspect somewhat hastily and superficially.

Producing a 32V-like kernel from 4.3BSD sources would probably be
quite difficult, it would be relatively easy to disable added system
calls, but harder to disable things like setpgrp() or the associated
support in the TTY drivers. More seriously the memory management would
have to change, I am planning however to make virtual memory optional
in the 4.3BSD kernel, by maybe putting the 32V code back in, protected
by #ifndef VM or some such (somewhat like Steven Schultz has done in
porting 4.3BSD to PDP-11 to produce 2.11BSD).

On the other hand producing a 32V-like userland from the 4.3BSD
sources would be pretty easy, I think just delete the sources for any
executables that weren't distributed with 32V and possibly, if any of
the tools seem particularly bloated, comment out any command line
switches or features that weren't in 32V. Going to this level of
effort would likely be pointless though. Another option would be
taking V7 and re-porting it (except the toolchain) over to a 32-bit
environment and kernel. I have developed over the past months, tools
that make this relatively straightforward, and in the process would
rediscover any 32-bit issues that were fixed in creating 32V. So I
wouldn't use 32V.

On a slightly different tack, I also have been for some time
investigating the idea of an Apple II port of Unix, there are massive
technical issues to be solved, but I think I got a bit closer the
other night when I decided to collect all information and resources I
could find about Mini-Unix and LSX (LSI Unix). Both are
self-supporting V6-based environments, the compiler can only compile
small programs but it is nonetheless possible for each Unix to
recomple itself. LSX I believe could run from floppies (dunno about
140K floppies) in less than 64K.

So, you know, true minimality is a relative term. We want something
LSX-like for an Apple II, something 2.11BSD-like for an IBM PC/XT or
286 (as Peter Jeremy noted, it's a good fit, and I'd be interested to
know more), something 4.3BSD-like for a VAX or 386... something a bit
more fully featured for a modern 64-bit multi-gigabyte system... but
just not as bloated as what we currently rely on. Hmm well it's hard.
What I do know, is that I have a lot of old hardware with <16M RAM and
Linux won't run on it anymore, and this annoys me very greatly.

In talking about FreeBSD/Linux bloat I forgot to mention the packet
filter, iptables (Linux) or pf (FreeBSD). I have a bit of experience
with this, since I regularly used to put 2 Ethernet cards in my home
server and make it Internet facing through one of them and share the
connection using NAT through the other card. But I've come to the
conclusion this is stupid, and moreover, that putting a complete
mini-language into the kernel just for this purpose is utterly stupid.
Programming the thing from userspace is incredibly intricate, and all
this complexity serves no purpose.

I recently found out about SLIRP (userspace packet rewriting) and I
think this would be a good way to implement NAT on servers or routers
that actually need to do NAT -- just make a userspace process that
runs something SLIRP-like and has a raw socket to the second Ethernet
card, and Bob's your uncle.

But this got me thinking along pretty productive lines in terms of the
tiny Apple II port -- I have been wanting to put the 2.11BSD network
stack into an Apple II for a long time, but I've now realized this is
not necessary. A much better approach for those Mini-Unix or LSX or
even V7 systems, would be to have a userspace library that does SLIP
and contains its own TCP, UDP, IP drivers, resolver and so on. Then if
you run a userspace program like say, ftp, which is linked to the
userspace TCP library, it would basically just open /dev/ttyXX, bring
up the SLIP link itself, do any necessary downloads etc, then close
the TTY and stop responding to any IP stuff coming over the SLIP link
whilst you quit to the prompt, until another program reopens it.

cheers, Nick

On Wed, Feb 8, 2017 at 2:56 PM, Jason Stevens
<jsteve at superglobalmegacorp.com> wrote:
> What about NetBSD 1.1 or even 386BSD?
>
> There never was a 4.2 or 4.3 for i386 was there?
>
> I'd guess the 32v userland could be built on early 4.4BSD Lite/NET2 greatly
> reducing its footprint.
>
>
>
>
> On February 8, 2017 11:47:03 AM GMT+08:00, Nick Downing
> <downing.nick at gmail.com> wrote:
>>
>> This is an issue that interests me quite a bit, since I was running
>> FreeBSD in an effort to get around Linux bloat problems discussed.
>> Well not that I really mind Linux as a user interface / runtime
>> environment / main development machine, but I think it probably
>> shouldn't be used as a "least common denominator" for development
>> since you end up introducing unwanted dependencies on a whole lot of
>> stuff.
>>
>> So I was running FreeBSD as a more minimal *nix. I did quite a lot of
>> interesting stuff with FreeBSD such as setting up diskless
>> workstations in my home, etc. I spent a lot of time tinkering around
>> in the kernel code. I was planning to do some serious development on
>> 4.4BSDLite or FreeBSD to create an operating system more to my liking.
>> So, I was looking carefully at differences since ancient *nixes.
>>
>> And, I can say that FreeBSD is pretty bloated. Umm well they've added
>> SMP, at the time it was using the Giant Lock although that could be
>> fixed by now. They've added VFS and NFS of course. They've added an
>> entire subsystem for block devices IIRC that handles partitioning and
>> possibly some other sophisticated stuff, which I believe is their own
>> design. Umm the kqueues and I believe they have their own
>> implementation of kernel threading or lightweight processes including
>> some sort of idle daemon. The network stack is heavily upgraded, to
>> the extent I looked into it, the added features are things you would
>> want (syncookies = DOS protection, etc) but also could not possibly be
>> called minimal, and would preclude running it on other than a
>> multi-megabyte machine. They have multiple ABIs so the kernel can
>> accept Linux or BSD syscalls or whatever else (I used it to run
>> Acrobat Reader Linux on my FreeBSD desktop). Umm I am pretty sure they
>> have kernel modules ala Linux. Lots and lots and lots of stuff... and
>> that's only considering the kernel. If you look in the ports
>> collection you see they have incredible amounts of bloat there too...
>> for instance GNOME, Libreoffice, LATEX, gcc, python... not that I'm
>> denigrating these tools, since they do invaluable work and I use them
>> every day, but the point is, you CANNOT call them minimal.
>>
>> The quest for a clean minimal system goes on ->. FreeBSD is not the
>> answer. In fact I believe 4.3BSD-Reno and 4.4 go strongly offtrack.
>>
>> cheers, Nick
>>
>> On Wed, Feb 8, 2017 at 1:55 PM, Greg 'groggy' Lehey <grog at lemis.com>
>> wrote:
>>>
>>>  On Tuesday,  7 February 2017 at 15:38:40 -0800, Steve Johnson wrote:
>>>>
>>>>  Looking back, the social dynamics of the Unix group helped a lot in
>>>>  keeping the bloat small.   The rule was, whoever touches something
>>>>  last becomes its owner.  Of course, we were all free to complain
>>>>  about things, and did, but the amalgamation of tinkerings that
>>>>  characterizes most of the Linux commands just didn't happen.
>>>
>>>
>>>  Out of interest: where do you (or others) consider that the current
>>>  BSD projects it in this comparison?
>>>
>>>  Greg
>>>  --
>>>  Sent from my desktop computer.
>>>  Finger grog at lemis.com for PGP public key.
>>>  See complete headers for address and phone numbers.
>>>  This message is digitally signed.  If your Microsoft mail program
>>>  reports problems, please read http://lemis.com/broken-MUA
>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.

[TUHS] Code bloat (was: How Unix brings people together, or it'sa small...)

[jsteve]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 11625 bytes --]

I love SLiRP, it’s insanely easy to integrate into other programs/emulators to get that fun TCP/IP networking with no device drivers... I’ve put it into all kinds of fun things.

My latest one was integrating with a cisco router via IPIP tunnelling.  Just slap on a MAC frame from the encapsulated packet, and feed it into SLiRP, and likewise, strip the MAC frame, and feed it back to IPIP.  Where I live I get throttled across international links all the time, SSH/PPTP/IPSEC/OpenVPN all seem to be detected and throttled down to 64kb/sec or less which is really disappointing, meanwhile I can pull files via HTTP for a good 10Mb/sec.  So eventually Im going to try to mix it in with .net remoting so I can host SLiRP on Windows/IIS and have a Windows machine on my LAN grab the IPIP tunnel from my cisco and send it off via HTTP...  That way the packet inspectors see proper HTTP traffic.. Then add in some compression and encryption and I’ve made yet another VPN, although one that’ll interface a router to SLiRP.

But I’ve plugged it into SIMH, although they use a much more involved, and newer one now, PCem, Previous, Basilisk II, and I got the ball rolling on WinUAE.  I may have left a few off, but yes, it’s an incredibly versatile library.

From: Nick Downing
Sent: Thursday, 9 February 2017 7:35 PM
To: Jason Stevens
Cc: TUHS main list; Greg 'groggy' Lehey
Subject: Re: [TUHS] Code bloat (was: How Unix brings people together, or it'sa small...)

Yes, NetBSD and 386BSD are interesting. They could well form a good
basis for a minimal but fully functional OS for a modern platform. One
reservation I have though, is as follows: When 386BSD and its
derivatives like OpenBSD, NetBSD, FreeBSD came out, Unix was still
encumbered and thus they had to be based on 4.4BSD Lite (not even
NET/2 was safe). Nobody made an unencumbered version of say 4.3BSD or
even NET/2, even though it was theoretically possible, by examining
what had to be taken out/added to produce 4.4BSD Lite.

Given that Unix is now unencumbered I believe there is no point
adopting 4.4, or even 4.3Reno, because the main thing done in those
releases as far as I know, is to add partial POSIX compliance. But if
you want POSIX compliance you will not achieve minimality. As an
example consider the BSD sigvec() routine. POSIX calls this
sigaction(), the old SV_ONSTACK flag becomes SA_ONSTACK, the old
integer mask becomes a sigset_t and so on... and in any reasonable
POSIX compliant BSD the two calls are gonna have to coexist, etc.

As to 32V, I appreciate your idea, as I was having some similar
thoughts myself. However I personally wouldn't use 32V as a basis for
any serious porting work, because I would assume V7 and 4.3 are much
more stable and well tested, since they ran in a lot of installations
over a long time. That's not to denigrate the huge achievement in
porting V7 to the VAX and producing 32V, but it probably has some
rough edges that were smoothed out over time to produce the 4BSDs. The
situation is a bit different for kernel/toolchain/other userspace.

As to the kernel I have been trying to make a detailed comparison
between 32V and the BSDs, but have been a bit put off by the fact that
all files moved around and may have been renamed, I will figure it all
out eventually though. As to the toolchain I have compared it quite
carefully with 4.3BSD, and I conclude you should use the later
toolchain as there is no disadvantage and some advantages to doing so.
As to the rest of the userspace, I BELIEVE that it's stock V7 with any
32-bit issues fixed, but I suspect somewhat hastily and superficially.

Producing a 32V-like kernel from 4.3BSD sources would probably be
quite difficult, it would be relatively easy to disable added system
calls, but harder to disable things like setpgrp() or the associated
support in the TTY drivers. More seriously the memory management would
have to change, I am planning however to make virtual memory optional
in the 4.3BSD kernel, by maybe putting the 32V code back in, protected
by #ifndef VM or some such (somewhat like Steven Schultz has done in
porting 4.3BSD to PDP-11 to produce 2.11BSD).

On the other hand producing a 32V-like userland from the 4.3BSD
sources would be pretty easy, I think just delete the sources for any
executables that weren't distributed with 32V and possibly, if any of
the tools seem particularly bloated, comment out any command line
switches or features that weren't in 32V. Going to this level of
effort would likely be pointless though. Another option would be
taking V7 and re-porting it (except the toolchain) over to a 32-bit
environment and kernel. I have developed over the past months, tools
that make this relatively straightforward, and in the process would
rediscover any 32-bit issues that were fixed in creating 32V. So I
wouldn't use 32V.

On a slightly different tack, I also have been for some time
investigating the idea of an Apple II port of Unix, there are massive
technical issues to be solved, but I think I got a bit closer the
other night when I decided to collect all information and resources I
could find about Mini-Unix and LSX (LSI Unix). Both are
self-supporting V6-based environments, the compiler can only compile
small programs but it is nonetheless possible for each Unix to
recomple itself. LSX I believe could run from floppies (dunno about
140K floppies) in less than 64K.

So, you know, true minimality is a relative term. We want something
LSX-like for an Apple II, something 2.11BSD-like for an IBM PC/XT or
286 (as Peter Jeremy noted, it's a good fit, and I'd be interested to
know more), something 4.3BSD-like for a VAX or 386... something a bit
more fully featured for a modern 64-bit multi-gigabyte system... but
just not as bloated as what we currently rely on. Hmm well it's hard.
What I do know, is that I have a lot of old hardware with <16M RAM and
Linux won't run on it anymore, and this annoys me very greatly.

In talking about FreeBSD/Linux bloat I forgot to mention the packet
filter, iptables (Linux) or pf (FreeBSD). I have a bit of experience
with this, since I regularly used to put 2 Ethernet cards in my home
server and make it Internet facing through one of them and share the
connection using NAT through the other card. But I've come to the
conclusion this is stupid, and moreover, that putting a complete
mini-language into the kernel just for this purpose is utterly stupid.
Programming the thing from userspace is incredibly intricate, and all
this complexity serves no purpose.

I recently found out about SLIRP (userspace packet rewriting) and I
think this would be a good way to implement NAT on servers or routers
that actually need to do NAT -- just make a userspace process that
runs something SLIRP-like and has a raw socket to the second Ethernet
card, and Bob's your uncle.

But this got me thinking along pretty productive lines in terms of the
tiny Apple II port -- I have been wanting to put the 2.11BSD network
stack into an Apple II for a long time, but I've now realized this is
not necessary. A much better approach for those Mini-Unix or LSX or
even V7 systems, would be to have a userspace library that does SLIP
and contains its own TCP, UDP, IP drivers, resolver and so on. Then if
you run a userspace program like say, ftp, which is linked to the
userspace TCP library, it would basically just open /dev/ttyXX, bring
up the SLIP link itself, do any necessary downloads etc, then close
the TTY and stop responding to any IP stuff coming over the SLIP link
whilst you quit to the prompt, until another program reopens it.

cheers, Nick

On Wed, Feb 8, 2017 at 2:56 PM, Jason Stevens
<jsteve at superglobalmegacorp.com> wrote:
> What about NetBSD 1.1 or even 386BSD?
>
> There never was a 4.2 or 4.3 for i386 was there?
>
> I'd guess the 32v userland could be built on early 4.4BSD Lite/NET2 greatly
> reducing its footprint.
>
>
>
>
> On February 8, 2017 11:47:03 AM GMT+08:00, Nick Downing
> <downing.nick at gmail.com> wrote:
>>
>> This is an issue that interests me quite a bit, since I was running
>> FreeBSD in an effort to get around Linux bloat problems discussed.
>> Well not that I really mind Linux as a user interface / runtime
>> environment / main development machine, but I think it probably
>> shouldn't be used as a "least common denominator" for development
>> since you end up introducing unwanted dependencies on a whole lot of
>> stuff.
>>
>> So I was running FreeBSD as a more minimal *nix. I did quite a lot of
>> interesting stuff with FreeBSD such as setting up diskless
>> workstations in my home, etc. I spent a lot of time tinkering around
>> in the kernel code. I was planning to do some serious development on
>> 4.4BSDLite or FreeBSD to create an operating system more to my liking.
>> So, I was looking carefully at differences since ancient *nixes.
>>
>> And, I can say that FreeBSD is pretty bloated. Umm well they've added
>> SMP, at the time it was using the Giant Lock although that could be
>> fixed by now. They've added VFS and NFS of course. They've added an
>> entire subsystem for block devices IIRC that handles partitioning and
>> possibly some other sophisticated stuff, which I believe is their own
>> design. Umm the kqueues and I believe they have their own
>> implementation of kernel threading or lightweight processes including
>> some sort of idle daemon. The network stack is heavily upgraded, to
>> the extent I looked into it, the added features are things you would
>> want (syncookies = DOS protection, etc) but also could not possibly be
>> called minimal, and would preclude running it on other than a
>> multi-megabyte machine. They have multiple ABIs so the kernel can
>> accept Linux or BSD syscalls or whatever else (I used it to run
>> Acrobat Reader Linux on my FreeBSD desktop). Umm I am pretty sure they
>> have kernel modules ala Linux. Lots and lots and lots of stuff... and
>> that's only considering the kernel. If you look in the ports
>> collection you see they have incredible amounts of bloat there too...
>> for instance GNOME, Libreoffice, LATEX, gcc, python... not that I'm
>> denigrating these tools, since they do invaluable work and I use them
>> every day, but the point is, you CANNOT call them minimal.
>>
>> The quest for a clean minimal system goes on ->. FreeBSD is not the
>> answer. In fact I believe 4.3BSD-Reno and 4.4 go strongly offtrack.
>>
>> cheers, Nick
>>
>> On Wed, Feb 8, 2017 at 1:55 PM, Greg 'groggy' Lehey <grog at lemis.com>
>> wrote:
>>>
>>>  On Tuesday,  7 February 2017 at 15:38:40 -0800, Steve Johnson wrote:
>>>>
>>>>  Looking back, the social dynamics of the Unix group helped a lot in
>>>>  keeping the bloat small.   The rule was, whoever touches something
>>>>  last becomes its owner.  Of course, we were all free to complain
>>>>  about things, and did, but the amalgamation of tinkerings that
>>>>  characterizes most of the Linux commands just didn't happen.
>>>
>>>
>>>  Out of interest: where do you (or others) consider that the current
>>>  BSD projects it in this comparison?
>>>
>>>  Greg
>>>  --
>>>  Sent from my desktop computer.
>>>  Finger grog at lemis.com for PGP public key.
>>>  See complete headers for address and phone numbers.
>>>  This message is digitally signed.  If your Microsoft mail program
>>>  reports problems, please read http://lemis.com/broken-MUA
>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170208/1639d009/attachment-0001.html>

[TUHS] Code bloat (was: How Unix brings people together, or it'sa small...)

[Nick Downing]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 13109 bytes --]

I have done something like that in order to access internet through
uni wireless that only allowed HTTP. I used the htc/hts tools which
are apparently from a package called httptunnel that's pretty popular,
when I searched just now most of the top results involved httptunnel.
When I did it (about 5 years ago) I found these tools incredibly basic
and not very convenient to use, however they did work. What I would
suggest for you is to buy a virtual server, I have one, it costs $4
per quarter (in Hong Kong but this provider also has US locations for
the same price). I think the amount of data per month is pretty decent
but you might have to pay extra depending on usage. Anyway, you run
hts on it, so you connect from home through your broken ISP that
throttles non-HTTP traffic, and have it download and forward you
stuff.
cheers, Nick

On Wed, Feb 8, 2017 at 10:59 PM,  <jsteve at superglobalmegacorp.com> wrote:
> I love SLiRP, it’s insanely easy to integrate into other programs/emulators
> to get that fun TCP/IP networking with no device drivers... I’ve put it into
> all kinds of fun things.
>
>
>
> My latest one was integrating with a cisco router via IPIP tunnelling.  Just
> slap on a MAC frame from the encapsulated packet, and feed it into SLiRP,
> and likewise, strip the MAC frame, and feed it back to IPIP.  Where I live I
> get throttled across international links all the time,
> SSH/PPTP/IPSEC/OpenVPN all seem to be detected and throttled down to
> 64kb/sec or less which is really disappointing, meanwhile I can pull files
> via HTTP for a good 10Mb/sec.  So eventually Im going to try to mix it in
> with .net remoting so I can host SLiRP on Windows/IIS and have a Windows
> machine on my LAN grab the IPIP tunnel from my cisco and send it off via
> HTTP...  That way the packet inspectors see proper HTTP traffic.. Then add
> in some compression and encryption and I’ve made yet another VPN, although
> one that’ll interface a router to SLiRP.
>
>
>
> But I’ve plugged it into SIMH, although they use a much more involved, and
> newer one now, PCem, Previous, Basilisk II, and I got the ball rolling on
> WinUAE.  I may have left a few off, but yes, it’s an incredibly versatile
> library.
>
>
>
> From: Nick Downing
> Sent: Thursday, 9 February 2017 7:35 PM
> To: Jason Stevens
> Cc: TUHS main list; Greg 'groggy' Lehey
> Subject: Re: [TUHS] Code bloat (was: How Unix brings people together, or
> it'sa small...)
>
>
>
> Yes, NetBSD and 386BSD are interesting. They could well form a good
>
> basis for a minimal but fully functional OS for a modern platform. One
>
> reservation I have though, is as follows: When 386BSD and its
>
> derivatives like OpenBSD, NetBSD, FreeBSD came out, Unix was still
>
> encumbered and thus they had to be based on 4.4BSD Lite (not even
>
> NET/2 was safe). Nobody made an unencumbered version of say 4.3BSD or
>
> even NET/2, even though it was theoretically possible, by examining
>
> what had to be taken out/added to produce 4.4BSD Lite.
>
>
>
> Given that Unix is now unencumbered I believe there is no point
>
> adopting 4.4, or even 4.3Reno, because the main thing done in those
>
> releases as far as I know, is to add partial POSIX compliance. But if
>
> you want POSIX compliance you will not achieve minimality. As an
>
> example consider the BSD sigvec() routine. POSIX calls this
>
> sigaction(), the old SV_ONSTACK flag becomes SA_ONSTACK, the old
>
> integer mask becomes a sigset_t and so on... and in any reasonable
>
> POSIX compliant BSD the two calls are gonna have to coexist, etc.
>
>
>
> As to 32V, I appreciate your idea, as I was having some similar
>
> thoughts myself. However I personally wouldn't use 32V as a basis for
>
> any serious porting work, because I would assume V7 and 4.3 are much
>
> more stable and well tested, since they ran in a lot of installations
>
> over a long time. That's not to denigrate the huge achievement in
>
> porting V7 to the VAX and producing 32V, but it probably has some
>
> rough edges that were smoothed out over time to produce the 4BSDs. The
>
> situation is a bit different for kernel/toolchain/other userspace.
>
>
>
> As to the kernel I have been trying to make a detailed comparison
>
> between 32V and the BSDs, but have been a bit put off by the fact that
>
> all files moved around and may have been renamed, I will figure it all
>
> out eventually though. As to the toolchain I have compared it quite
>
> carefully with 4.3BSD, and I conclude you should use the later
>
> toolchain as there is no disadvantage and some advantages to doing so.
>
> As to the rest of the userspace, I BELIEVE that it's stock V7 with any
>
> 32-bit issues fixed, but I suspect somewhat hastily and superficially.
>
>
>
> Producing a 32V-like kernel from 4.3BSD sources would probably be
>
> quite difficult, it would be relatively easy to disable added system
>
> calls, but harder to disable things like setpgrp() or the associated
>
> support in the TTY drivers. More seriously the memory management would
>
> have to change, I am planning however to make virtual memory optional
>
> in the 4.3BSD kernel, by maybe putting the 32V code back in, protected
>
> by #ifndef VM or some such (somewhat like Steven Schultz has done in
>
> porting 4.3BSD to PDP-11 to produce 2.11BSD).
>
>
>
> On the other hand producing a 32V-like userland from the 4.3BSD
>
> sources would be pretty easy, I think just delete the sources for any
>
> executables that weren't distributed with 32V and possibly, if any of
>
> the tools seem particularly bloated, comment out any command line
>
> switches or features that weren't in 32V. Going to this level of
>
> effort would likely be pointless though. Another option would be
>
> taking V7 and re-porting it (except the toolchain) over to a 32-bit
>
> environment and kernel. I have developed over the past months, tools
>
> that make this relatively straightforward, and in the process would
>
> rediscover any 32-bit issues that were fixed in creating 32V. So I
>
> wouldn't use 32V.
>
>
>
> On a slightly different tack, I also have been for some time
>
> investigating the idea of an Apple II port of Unix, there are massive
>
> technical issues to be solved, but I think I got a bit closer the
>
> other night when I decided to collect all information and resources I
>
> could find about Mini-Unix and LSX (LSI Unix). Both are
>
> self-supporting V6-based environments, the compiler can only compile
>
> small programs but it is nonetheless possible for each Unix to
>
> recomple itself. LSX I believe could run from floppies (dunno about
>
> 140K floppies) in less than 64K.
>
>
>
> So, you know, true minimality is a relative term. We want something
>
> LSX-like for an Apple II, something 2.11BSD-like for an IBM PC/XT or
>
> 286 (as Peter Jeremy noted, it's a good fit, and I'd be interested to
>
> know more), something 4.3BSD-like for a VAX or 386... something a bit
>
> more fully featured for a modern 64-bit multi-gigabyte system... but
>
> just not as bloated as what we currently rely on. Hmm well it's hard.
>
> What I do know, is that I have a lot of old hardware with <16M RAM and
>
> Linux won't run on it anymore, and this annoys me very greatly.
>
>
>
> In talking about FreeBSD/Linux bloat I forgot to mention the packet
>
> filter, iptables (Linux) or pf (FreeBSD). I have a bit of experience
>
> with this, since I regularly used to put 2 Ethernet cards in my home
>
> server and make it Internet facing through one of them and share the
>
> connection using NAT through the other card. But I've come to the
>
> conclusion this is stupid, and moreover, that putting a complete
>
> mini-language into the kernel just for this purpose is utterly stupid.
>
> Programming the thing from userspace is incredibly intricate, and all
>
> this complexity serves no purpose.
>
>
>
> I recently found out about SLIRP (userspace packet rewriting) and I
>
> think this would be a good way to implement NAT on servers or routers
>
> that actually need to do NAT -- just make a userspace process that
>
> runs something SLIRP-like and has a raw socket to the second Ethernet
>
> card, and Bob's your uncle.
>
>
>
> But this got me thinking along pretty productive lines in terms of the
>
> tiny Apple II port -- I have been wanting to put the 2.11BSD network
>
> stack into an Apple II for a long time, but I've now realized this is
>
> not necessary. A much better approach for those Mini-Unix or LSX or
>
> even V7 systems, would be to have a userspace library that does SLIP
>
> and contains its own TCP, UDP, IP drivers, resolver and so on. Then if
>
> you run a userspace program like say, ftp, which is linked to the
>
> userspace TCP library, it would basically just open /dev/ttyXX, bring
>
> up the SLIP link itself, do any necessary downloads etc, then close
>
> the TTY and stop responding to any IP stuff coming over the SLIP link
>
> whilst you quit to the prompt, until another program reopens it.
>
>
>
> cheers, Nick
>
>
>
> On Wed, Feb 8, 2017 at 2:56 PM, Jason Stevens
>
> <jsteve at superglobalmegacorp.com> wrote:
>
>> What about NetBSD 1.1 or even 386BSD?
>
>>
>
>> There never was a 4.2 or 4.3 for i386 was there?
>
>>
>
>> I'd guess the 32v userland could be built on early 4.4BSD Lite/NET2
>> greatly
>
>> reducing its footprint.
>
>>
>
>>
>
>>
>
>>
>
>> On February 8, 2017 11:47:03 AM GMT+08:00, Nick Downing
>
>> <downing.nick at gmail.com> wrote:
>
>>>
>
>>> This is an issue that interests me quite a bit, since I was running
>
>>> FreeBSD in an effort to get around Linux bloat problems discussed.
>
>>> Well not that I really mind Linux as a user interface / runtime
>
>>> environment / main development machine, but I think it probably
>
>>> shouldn't be used as a "least common denominator" for development
>
>>> since you end up introducing unwanted dependencies on a whole lot of
>
>>> stuff.
>
>>>
>
>>> So I was running FreeBSD as a more minimal *nix. I did quite a lot of
>
>>> interesting stuff with FreeBSD such as setting up diskless
>
>>> workstations in my home, etc. I spent a lot of time tinkering around
>
>>> in the kernel code. I was planning to do some serious development on
>
>>> 4.4BSDLite or FreeBSD to create an operating system more to my liking.
>
>>> So, I was looking carefully at differences since ancient *nixes.
>
>>>
>
>>> And, I can say that FreeBSD is pretty bloated. Umm well they've added
>
>>> SMP, at the time it was using the Giant Lock although that could be
>
>>> fixed by now. They've added VFS and NFS of course. They've added an
>
>>> entire subsystem for block devices IIRC that handles partitioning and
>
>>> possibly some other sophisticated stuff, which I believe is their own
>
>>> design. Umm the kqueues and I believe they have their own
>
>>> implementation of kernel threading or lightweight processes including
>
>>> some sort of idle daemon. The network stack is heavily upgraded, to
>
>>> the extent I looked into it, the added features are things you would
>
>>> want (syncookies = DOS protection, etc) but also could not possibly be
>
>>> called minimal, and would preclude running it on other than a
>
>>> multi-megabyte machine. They have multiple ABIs so the kernel can
>
>>> accept Linux or BSD syscalls or whatever else (I used it to run
>
>>> Acrobat Reader Linux on my FreeBSD desktop). Umm I am pretty sure they
>
>>> have kernel modules ala Linux. Lots and lots and lots of stuff... and
>
>>> that's only considering the kernel. If you look in the ports
>
>>> collection you see they have incredible amounts of bloat there too...
>
>>> for instance GNOME, Libreoffice, LATEX, gcc, python... not that I'm
>
>>> denigrating these tools, since they do invaluable work and I use them
>
>>> every day, but the point is, you CANNOT call them minimal.
>
>>>
>
>>> The quest for a clean minimal system goes on ->. FreeBSD is not the
>
>>> answer. In fact I believe 4.3BSD-Reno and 4.4 go strongly offtrack.
>
>>>
>
>>> cheers, Nick
>
>>>
>
>>> On Wed, Feb 8, 2017 at 1:55 PM, Greg 'groggy' Lehey <grog at lemis.com>
>
>>> wrote:
>
>>>>
>
>>>>  On Tuesday,  7 February 2017 at 15:38:40 -0800, Steve Johnson wrote:
>
>>>>>
>
>>>>>  Looking back, the social dynamics of the Unix group helped a lot in
>
>>>>>  keeping the bloat small.   The rule was, whoever touches something
>
>>>>>  last becomes its owner.  Of course, we were all free to complain
>
>>>>>  about things, and did, but the amalgamation of tinkerings that
>
>>>>>  characterizes most of the Linux commands just didn't happen.
>
>>>>
>
>>>>
>
>>>>  Out of interest: where do you (or others) consider that the current
>
>>>>  BSD projects it in this comparison?
>
>>>>
>
>>>>  Greg
>
>>>>  --
>
>>>>  Sent from my desktop computer.
>
>>>>  Finger grog at lemis.com for PGP public key.
>
>>>>  See complete headers for address and phone numbers.
>
>>>>  This message is digitally signed.  If your Microsoft mail program
>
>>>>  reports problems, please read http://lemis.com/broken-MUA
>
>>
>
>>
>
>> --
>
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
>

[TUHS] Code bloat

[Jacob Goense]

On 2017-02-08 12:21, Nick Downing wrote:
> Yes, NetBSD and 386BSD are interesting. They could well form a good
> basis for a minimal but fully functional OS for a modern platform. One
> reservation I have though, is as follows: When 386BSD and its
> derivatives like OpenBSD, NetBSD, FreeBSD came out, Unix was still
> encumbered and thus they had to be based on 4.4BSD Lite (not even
> NET/2 was safe). Nobody made an unencumbered version of say 4.3BSD or
> even NET/2, even though it was theoretically possible, by examining
> what had to be taken out/added to produce 4.4BSD Lite.

The 386BSD porting started on 4.3BSD-Reno with patches being fed back
to BSD. Stuff was being thrown out of BSD at the same time for the Net
releases. Must have been difficult. First release was Net/2 + missing
bits and pieces. ftp://ftp.funet.fi/pub/unix/4.3bsd/i386-jolitz/diffs/
Note that Jolitz was never sued for using Net/2 ;)

NetBSD and FreeBSD started as 386bsd 0.1 + patchkits. To "unencumber"
NetBSD the 0.8 release was scrubbed from the net and a pile of files
in cvs were replaced with the text "revision x.y intentionally removed"
and rewritten or taken from a cleaner BSD release.
List of files at http://oldbsd.org/removed.txt

FreeBSD claiming to be 4.4BSD-Lite based is, I think, a legal fiction.
I could be wrong, but it is far more likely they did it the same way
as NetBSD after the FreeBSD 1.1.5.1 release. I don't believe they
restarted with a clean 4.4BSD-Lite tape, but the FreeBSD handbook
claims that is what they did for the 2.0 release.

[TUHS] Code bloat

[Nick Downing]

Yes, thanks Jacob, I realized after posting that I had oversimplified
things since definitely 386BSD was based on NET/2 as you say. Anyway,
it's a very good thing that all is now unencumbered, I remember
working on 2.11BSD 6~8yrs back and always having a strong concern in
the back of my mind that it would be enormously complicated to sort
out the licensing should I ever have an actual release.

Warren, I hadn't realized that DoctorWkt = Dr Warren K. Toomey haha.
Yes well actually I was aware of Xinu although I didn't realize there
was an already-done Apple II port or that you had created it. I will
certainly load it up. However the idea in my mind is to have the OS
written in C, since I have some ideas for a simple but globally
optimizing compiler which I hope makes 6502 a bit more C-friendly.

I hadn't heard of xv6 but I will look into it. However, for me,
compatibility is a huge concern, and there are so many little corner
cases -- what happens if XXX signal arrives during YYY, does it
ERESTART or EINTR... what happens if a directory is setgid and sticky
and XXX operation is performed... I guess for V7 these kinds of
questions are not too vexing, but when you get to BSD with process
groups and job control and EUIDS and so on... it's just too hard to
try to recreate it and have it still be compatible in all these tiny
details. If I was happy with that, I would have persevered with UZI
(Unix Z-80 Implementation), but I kept finding little bugs and/or
differences.

As to Contiki, yes it's quite an amazing piece of software, I picked
it up when I first got into 2.11BSD (maybe 6~8 yrs ago) which is also
when I started to realize UZI would be too much work to make
acceptably Unix-like. I briefly got excited about Contiki. The reason
I did not persevere with Contiki, was to do with its proto-threads
concept. It's basically event-driven, a task proceeds through the
system by receiving callbacks in which it does a bit of processing and
then goes to sleep by registering for some other callback at a later
time.

But, there's a compatibility issue, since you have to rewrite all your
software. Ordinary code like say, an ftp client with a main() function
that calls socket() and read() and write(), doesn't work under this
model, and can't be made to work without a complete rewrite. More
seriously though, it's a pretty unfriendly way to write code, at least
without significant compiler support. I know this because as a
teenager I used to do work for local SysOps running TheMajorBBS, which
was also stackless in order to serve hundreds of incoming modem
connections on 286 or (later on) 386 hardware. Every MajorBBS app or
menu was written like a state machine and it got really tedious after
a while. Thinking about it, Ken Thompson and Dennis Ritchie could
certainly have chosen this model for implementing the Unix syscalls,
to save on the space required for the kernel stack, however they did
not, and as a result the system is vastly simplified.

However, given the TCP/IP stack is nearly always implemented as a
state machine, the Contiki TCP/IP stack could be useful to my project.
Thanks a lot for the alert. I am not even sure if it had TCP/IP at all
when I last looked at it, although it definitely had windowing.

cheers, Nick

On Wed, Feb 8, 2017 at 11:29 PM, Jacob Goense <dugo at xs4all.nl> wrote:
> On 2017-02-08 12:21, Nick Downing wrote:
>>
>> Yes, NetBSD and 386BSD are interesting. They could well form a good
>> basis for a minimal but fully functional OS for a modern platform. One
>> reservation I have though, is as follows: When 386BSD and its
>> derivatives like OpenBSD, NetBSD, FreeBSD came out, Unix was still
>> encumbered and thus they had to be based on 4.4BSD Lite (not even
>> NET/2 was safe). Nobody made an unencumbered version of say 4.3BSD or
>> even NET/2, even though it was theoretically possible, by examining
>> what had to be taken out/added to produce 4.4BSD Lite.
>
>
> The 386BSD porting started on 4.3BSD-Reno with patches being fed back
> to BSD. Stuff was being thrown out of BSD at the same time for the Net
> releases. Must have been difficult. First release was Net/2 + missing
> bits and pieces. ftp://ftp.funet.fi/pub/unix/4.3bsd/i386-jolitz/diffs/
> Note that Jolitz was never sued for using Net/2 ;)
>
> NetBSD and FreeBSD started as 386bsd 0.1 + patchkits. To "unencumber"
> NetBSD the 0.8 release was scrubbed from the net and a pile of files
> in cvs were replaced with the text "revision x.y intentionally removed"
> and rewritten or taken from a cleaner BSD release.
> List of files at http://oldbsd.org/removed.txt
>
> FreeBSD claiming to be 4.4BSD-Lite based is, I think, a legal fiction.
> I could be wrong, but it is far more likely they did it the same way
> as NetBSD after the FreeBSD 1.1.5.1 release. I don't believe they
> restarted with a clean 4.4BSD-Lite tape, but the FreeBSD handbook
> claims that is what they did for the 2.0 release.

[TUHS] Code bloat

[jsteve]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2655 bytes --]

After I had pasted a bunch of 386BSD pl0.24 + a CVS export of 0.8 I did get a booting system.  Then I found an old ftp site that had 0.8  I made a mirror of it, then it disappeared.

So I mirrored it here:

http://vpsland.superglobalmegacorp.com/ install/NetBSD/NetBSD-0.8/Original/NetBSD-0.8/

Although I had some idiot saying that hosting nethack was a virus had I was then blacklisted for a while so if you try to browse or download you’ll have to input a username password.. It’s on the 404 page.

I did some minor work on installing it on Bochs years ago, and VMware, from what I recall, NetBSD 1.0/1.1 can boot 386BSD’s kernel, while the 386BSD boot diskette didn’t work under emulation, NetBSD’s does, and I used that to kickstart an installation.  Same with the boot blocks on the harddisk image.


From: Jacob Goense
Sent: Thursday, 9 February 2017 8:43 PM
To: tuhs at minnie.tuhs.org
Subject: Re: [TUHS] Code bloat

On 2017-02-08 12:21, Nick Downing wrote:
> Yes, NetBSD and 386BSD are interesting. They could well form a good
> basis for a minimal but fully functional OS for a modern platform. One
> reservation I have though, is as follows: When 386BSD and its
> derivatives like OpenBSD, NetBSD, FreeBSD came out, Unix was still
> encumbered and thus they had to be based on 4.4BSD Lite (not even
> NET/2 was safe). Nobody made an unencumbered version of say 4.3BSD or
> even NET/2, even though it was theoretically possible, by examining
> what had to be taken out/added to produce 4.4BSD Lite.

The 386BSD porting started on 4.3BSD-Reno with patches being fed back
to BSD. Stuff was being thrown out of BSD at the same time for the Net
releases. Must have been difficult. First release was Net/2 + missing
bits and pieces. ftp://ftp.funet.fi/pub/unix/4.3bsd/i386-jolitz/diffs/
Note that Jolitz was never sued for using Net/2 ;)

NetBSD and FreeBSD started as 386bsd 0.1 + patchkits. To "unencumber"
NetBSD the 0.8 release was scrubbed from the net and a pile of files
in cvs were replaced with the text "revision x.y intentionally removed"
and rewritten or taken from a cleaner BSD release.
List of files at http://oldbsd.org/removed.txt

FreeBSD claiming to be 4.4BSD-Lite based is, I think, a legal fiction.
I could be wrong, but it is far more likely they did it the same way
as NetBSD after the FreeBSD 1.1.5.1 release. I don't believe they
restarted with a clean 4.4BSD-Lite tape, but the FreeBSD handbook
claims that is what they did for the 2.0 release.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170208/4aa9a69e/attachment.html>

[TUHS] Code bloat

[Jacob Goense]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1248 bytes --]

On 2017-02-08 14:10, jsteve at superglobalmegacorp.com wrote:
> After I had pasted a bunch of 386BSD pl0.24 + a CVS export of 0.8 I
> did get a booting system.

I remember that Victor Frankenstein ;) Proved how close these 2 were.

> Then I found an old ftp site that had 0.8
> I made a mirror of it, then it disappeared.

Very glad that piece of history got unearthed.

> I did some minor work on installing it on Bochs years ago, and VMware,
> from what I recall, NetBSD 1.0/1.1 can boot 386BSD’s kernel, while
> the 386BSD boot diskette didn’t work under emulation, NetBSD’s
> does, and I used that to kickstart an installation.  Same with the
> boot blocks on the harddisk image.

386BSD is now bootable in Bochs, with very, very specific settings.
One that works at:
https://raw.githubusercontent.com/dugoh/tobochs/master/bochsrc

Back then it required a patch against bochs too as the boot blocks
do some truly weird stuff with the PIC (polling OCW3?), something
most emulators don't implement or even barf on.

These 2 little marvels didn't have much bloat, but the Bostification
had already set in. My idea of a true diet x86 UNIX system would be
a report of Tahoe without resorting to gcc/gas or anything else that
smells like RMS.

[TUHS] Code bloat

[Ron Natalie]

Anybody have a copy of Rob Pike's "Cat -v considered harmful" paper?

[TUHS] Code bloat

[Brantley Coile]

https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&cad=rja&uact=8&ved=0ahUKEwivluKK3oDSAhVKgiYKHeDFD3kQFgghMAI&url=http%3A%2F%2Fharmful.cat-v.org%2Fcat-v%2Funix_prog_design.pdf&usg=AFQjCNGKqCcaE00loEzM9pR_IafihhfqbQ&bvm=bv.146496531,d.eWE


> On Feb 8, 2017, at 9:34 AM, Ron Natalie <ron at ronnatalie.com> wrote:
> 
> Anybody have a copy of Rob Pike's "Cat -v considered harmful" paper?
> 
> 

[TUHS] Code bloat

[Dan Cross]

Here you are: http://harmful.cat-v.org/cat-v/unix_prog_design.pdf

On Wed, Feb 8, 2017 at 9:34 AM, Ron Natalie <ron at ronnatalie.com> wrote:

> Anybody have a copy of Rob Pike's "Cat -v considered harmful" paper?
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170208/f4ec780b/attachment.html>

[TUHS] Code bloat

[Nick Downing]

Interesting, in my 4.3BSD experiments recently I have missed
readline.so a lot, but in my implementation I was thinking of building
it into the kernel or the TTY driver (well actually I was thinking of
making it a filter driver, but that's another story). I thought I was
possibly being a bit of a crank (deliberately swimming against the
current to "prove" the current way of doing things is wrong) but this
paper basically suggests the same thing. That's really encouraging.
And, I often find it really annoying that programs like gdb don't have
readline ability.
cheers, Nick

On Thu, Feb 9, 2017 at 2:09 AM, Dan Cross <crossd at gmail.com> wrote:
> Here you are: http://harmful.cat-v.org/cat-v/unix_prog_design.pdf
>
> On Wed, Feb 8, 2017 at 9:34 AM, Ron Natalie <ron at ronnatalie.com> wrote:
>>
>> Anybody have a copy of Rob Pike's "Cat -v considered harmful" paper?
>>
>>
>

[TUHS] Code bloat

[Jason Stevens]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2370 bytes --]

I had a bizarre side project to re-host old GCC 1.x on Windows so I could cross compile early Linux kernels (it actually works too!)

I was going down the path of cross compiling 386BSD when I ran into the boot block hell of it being really inconvenient to stage any kernel in a way to boot test.

Anyway PCC is more or less alive these days, and supports both i386 and AMDx64.  I'd suppose cross compiling from that may be doable.  I'd shoved Tahoe through GCC 1.42 for the i386, and most of the C actually built.  Of course no assembly, no boot/stand and I gave up just as quickly as the low stuff is well over my head.  But my point being that it ought to be something that could be done, there was even that Quasijarous VAX which was Tahoe with POSIX removed.....

On February 8, 2017 10:10:24 PM GMT+08:00, Jacob Goense <dugo at xs4all.nl> wrote:
>On 2017-02-08 14:10, jsteve at superglobalmegacorp.com wrote:
>> After I had pasted a bunch of 386BSD pl0.24 + a CVS export of 0.8 I
>> did get a booting system.
>
>I remember that Victor Frankenstein ;) Proved how close these 2 were.
>
>> Then I found an old ftp site that had 0.8
>> I made a mirror of it, then it disappeared.
>
>Very glad that piece of history got unearthed.
>
>> I did some minor work on installing it on Bochs years ago, and
>VMware,
>> from what I recall, NetBSD 1.0/1.1 can boot 386BSD’s kernel, while
>> the 386BSD boot diskette didn’t work under emulation, NetBSD’s
>> does, and I used that to kickstart an installation.  Same with the
>> boot blocks on the harddisk image.
>
>386BSD is now bootable in Bochs, with very, very specific settings.
>One that works at:
>https://raw.githubusercontent.com/dugoh/tobochs/master/bochsrc
>
>Back then it required a patch against bochs too as the boot blocks
>do some truly weird stuff with the PIC (polling OCW3?), something
>most emulators don't implement or even barf on.
>
>These 2 little marvels didn't have much bloat, but the Bostification
>had already set in. My idea of a true diet x86 UNIX system would be
>a report of Tahoe without resorting to gcc/gas or anything else that
>smells like RMS.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170208/62f77fbb/attachment.html>

[TUHS] Code bloat

[Tony Finch]

Jacob Goense <dugo at xs4all.nl> wrote:
>
> FreeBSD claiming to be 4.4BSD-Lite based is, I think, a legal fiction.
> I could be wrong, but it is far more likely they did it the same way
> as NetBSD after the FreeBSD 1.1.5.1 release. I don't believe they
> restarted with a clean 4.4BSD-Lite tape, but the FreeBSD handbook
> claims that is what they did for the 2.0 release.

The history is slightly harder to see now than it used to be.

When FreeBSD was developed in CVS, the repository only went back to the
4.4BSD import, basically around what is now
https://github.com/freebsd/freebsd/commit/8b2b31265d61a703f6043fef964fcf90bec23fcd

The FreeBSD 1.x changes were re-imported on top of 4.4BSD, instead of
4.4BSD being incorporated into the previous repo (which is what NetBSD
did).

The previous CVS repo from the 386BSD+patchkit days was hidden away
because of old copyright worries, though some time after 2000 it became
available to most committers. (I have a copy in my home directory on
freefall.freebsd.org which I stashed away in 2007 because at that time I
think there still wasn't a conveniently accessible copy.)

It looks like after the uplift to SVN the two repositories were combined,
so you can now see the 386BSD import at
https://github.com/freebsd/freebsd/commit/f131f027b47937d651804c243cde86ec0bf87e67

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Lundy, Fastnet, Irish Sea: Variable 3 or 4 at first in Lundy and Irish Sea,
otherwise south or southeast 5 or 6, occasionally 7 later. Moderate or rough,
occasionally very rough. Mainly fair. Good.

[TUHS] Code bloat

[Jacob Goense]

On 2017-02-08 17:25, Tony Finch wrote:
> The previous CVS repo from the 386BSD+patchkit days was hidden away
> because of old copyright worries, though some time after 2000 it became
> available to most committers. (I have a copy in my home directory on
> freefall.freebsd.org which I stashed away in 2007 because at that time 
> I
> think there still wasn't a conveniently accessible copy.)

Does that have eg. sys/kern/tty.c in it? Or is also missing piles of 
files?

> It looks like after the uplift to SVN the two repositories were 
> combined,
> so you can now see the 386BSD import at
> https://github.com/freebsd/freebsd/commit/f131f027b47937d651804c243cde86ec0bf87e67

Not without being butchered first. A lot of essential source files are 
missing
from the start until they magically appear in the 4.4BSD-Lite upload.

I'll take another look if I can make sense of how Lite was folded in.

[TUHS] Code bloat

[jsteve]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1514 bytes --]

386BSD is available here:
http://oldlinux.org/Linux.old/distributions/386BSD/

The 0.0 distribution tree is there, and files for 0.1 , and the few patchkits that survived.

I’m 99% sure this is that I took to take 0.1 to 0.1-p23 to 0.1-p24 and used that to fill in the missing CVS from NetBSD 0.8 ... before finding it.

From: Jacob Goense
Sent: Friday, 10 February 2017 10:18 PM
To: tuhs at minnie.tuhs.org
Subject: Re: [TUHS] Code bloat

On 2017-02-08 17:25, Tony Finch wrote:
> The previous CVS repo from the 386BSD+patchkit days was hidden away
> because of old copyright worries, though some time after 2000 it became
> available to most committers. (I have a copy in my home directory on
> freefall.freebsd.org which I stashed away in 2007 because at that time 
> I
> think there still wasn't a conveniently accessible copy.)

Does that have eg. sys/kern/tty.c in it? Or is also missing piles of 
files?

> It looks like after the uplift to SVN the two repositories were 
> combined,
> so you can now see the 386BSD import at
> https://github.com/freebsd/freebsd/commit/f131f027b47937d651804c243cde86ec0bf87e67

Not without being butchered first. A lot of essential source files are 
missing
from the start until they magically appear in the 4.4BSD-Lite upload.

I'll take another look if I can make sense of how Lite was folded in.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170209/bec2a538/attachment-0001.html>

[TUHS] Code bloat

[Jacob Goense]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 244 bytes --]

On 2017-02-09 15:41, jsteve at superglobalmegacorp.com wrote:
> I’m 99% sure this is that I took to take 0.1 to 0.1-p23 to 0.1-p24
> and used that to fill in the missing CVS from NetBSD 0.8 ... before
> finding it.

Looking at FreeBSD here.

[TUHS] Code bloat

[Jason Stevens]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 759 bytes --]

Oops sorry. Haven't gotten around to hunting that one down yet...  

I was always under the impression that it also diverged from pl24, then rebased from 4.4BSD Lite 2, post lawsuit...

On February 9, 2017 11:03:17 PM GMT+08:00, Jacob Goense <dugo at xs4all.nl> wrote:
>On 2017-02-09 15:41, jsteve at superglobalmegacorp.com wrote:
>> I’m 99% sure this is that I took to take 0.1 to 0.1-p23 to 0.1-p24
>> and used that to fill in the missing CVS from NetBSD 0.8 ... before
>> finding it.
>
>Looking at FreeBSD here.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170209/f5864753/attachment.html>

[TUHS] Code bloat

[Tony Finch]

Jacob Goense <dugo at xs4all.nl> wrote:
> On 2017-02-08 17:25, Tony Finch wrote:
> > The previous CVS repo from the 386BSD+patchkit days was hidden away
> > because of old copyright worries, though some time after 2000 it became
> > available to most committers. (I have a copy in my home directory on
> > freefall.freebsd.org which I stashed away in 2007 because at that time I
> > think there still wasn't a conveniently accessible copy.)
>
> Does that have eg. sys/kern/tty.c in it? Or is also missing piles of files?

Yes, rev 1.1 has a comment in the header

 * PATCHES MAGIC                LEVEL   PATCH THAT GOT US HERE
 * --------------------         -----   ----------------------
 * CURRENT PATCH LEVEL:         3       00163
 * --------------------         -----   ----------------------
 *
 * 11 Dec 92    Williams Jolitz         Fixed tty handling
 * 28 Nov 1991  Warren Toomey           Cleaned up the use of COMPAT_43
 *                                      in the 386BSD kernel.
 * 27 May 93    Bruce Evans             Sign Ext fix for TIOCSTI from the net
 *                                      Kludge to hook in RTS/CTS flow control
 *                                      Avoid sleeping on lbolt, it slows down
 *                                      output unnecessarily.

> > It looks like after the uplift to SVN the two repositories were combined,
> > so you can now see the 386BSD import at
> > https://github.com/freebsd/freebsd/commit/f131f027b47937d651804c243cde86ec0bf87e67
>
> Not without being butchered first. A lot of essential source files are missing
> from the start until they magically appear in the 4.4BSD-Lite upload.

Ah, I see you are right :-/ The early commits are not very easy to dig
through because of a combination of broken-up commits and source control
conversion artefacts, and SVN being incredibly slow.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Sole: Southeast 6 to gale 8, occasionally severe gale 9 at first, backing east
5 or 6 later. Very rough or high. Occasional rain. Good, occasionally
moderate.

[TUHS] Code bloat

[Warner Losh]

I thought someone had posted a github project to merge the history of
all publicly available sources of unix.

Ah, yes, here it is

https://github.com/dspinellis/unix-history-repo

Maybe that would be easier to follow than dealing with svn...

I'll note that searching the TUHS archives throws all kinds of ugly errors:

Failed to seek to properties located at 222966803301099891 for file
number 8645 : Invalid argument

Warner

On Thu, Feb 9, 2017 at 8:30 AM, Tony Finch <dot at dotat.at> wrote:
> Jacob Goense <dugo at xs4all.nl> wrote:
>> On 2017-02-08 17:25, Tony Finch wrote:
>> > The previous CVS repo from the 386BSD+patchkit days was hidden away
>> > because of old copyright worries, though some time after 2000 it became
>> > available to most committers. (I have a copy in my home directory on
>> > freefall.freebsd.org which I stashed away in 2007 because at that time I
>> > think there still wasn't a conveniently accessible copy.)
>>
>> Does that have eg. sys/kern/tty.c in it? Or is also missing piles of files?
>
> Yes, rev 1.1 has a comment in the header
>
>  * PATCHES MAGIC                LEVEL   PATCH THAT GOT US HERE
>  * --------------------         -----   ----------------------
>  * CURRENT PATCH LEVEL:         3       00163
>  * --------------------         -----   ----------------------
>  *
>  * 11 Dec 92    Williams Jolitz         Fixed tty handling
>  * 28 Nov 1991  Warren Toomey           Cleaned up the use of COMPAT_43
>  *                                      in the 386BSD kernel.
>  * 27 May 93    Bruce Evans             Sign Ext fix for TIOCSTI from the net
>  *                                      Kludge to hook in RTS/CTS flow control
>  *                                      Avoid sleeping on lbolt, it slows down
>  *                                      output unnecessarily.
>
>> > It looks like after the uplift to SVN the two repositories were combined,
>> > so you can now see the 386BSD import at
>> > https://github.com/freebsd/freebsd/commit/f131f027b47937d651804c243cde86ec0bf87e67
>>
>> Not without being butchered first. A lot of essential source files are missing
>> from the start until they magically appear in the 4.4BSD-Lite upload.
>
> Ah, I see you are right :-/ The early commits are not very easy to dig
> through because of a combination of broken-up commits and source control
> conversion artefacts, and SVN being incredibly slow.
>
> Tony.
> --
> f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
> Sole: Southeast 6 to gale 8, occasionally severe gale 9 at first, backing east
> 5 or 6 later. Very rough or high. Occasional rain. Good, occasionally
> moderate.

[TUHS] Free/NetBSD revision history (was Code bloat)

[Jacob Goense]

On 2017-02-09 11:14, Warner Losh wrote:
> I thought someone had posted a github project to merge the history of
> all publicly available sources of unix.

That's the thing, it banks on what is publicly available.

NetBSD and FreeBSD both started out from 386BSD + patchkits. They threw
it is cvs, and engineered a release.

This was all, in essence, Net/2 based, then the USL vs. BSDi lawsuit
kicked in and was settled by a.o. "encumbering" Net/2 by agreement.

Panic ensued and the NetBSD and FreeBSD teams took a chainsaw against
what they had released until then.

The publicly available repos from that period are butchered.

The number of people on earth trying to curate stuff like the history
of locore.s/tty.c between 386BSD and the reboots of Net/FreeBSD is a
handfull, and I'm being optimistic here.

This stuff has been deliberately purged and hard to find. Jason Stevens
went as far as reconstructing a NetBSD 0.8 kernel because the complete
sources where nowhere to be found. Then he ran into the proverbial
coughing, chain smoking guy in a raincoat in a parking garage with
a manilla folder of a CD-ROM of 
ftp://agate.berkeley.edu/pub/NetBSD/NetBSD-0.8,
or was it a forgotten ftp site?

Anyway, the revision history of the "encumbered" pieces in NetBSD is
probably lost, but at least the 0.8 checkpoint was unearthed.

If you take a close look at the publicly available revision history of
FreeBSD you'll notice some serious gaps as well. Someone went through
that cvs with an axe or surgical knife for legal reasons (and made a 
mess
teleporting AMD64 to the early 90s).

What dspinellis did with git is truly awesome. But I see the scars the
USL vs. BSDi lawsuit made. I have no idea why I care, but I do. I 
respect
that not everything can be made publicly available, but I pray stuff
such as an original FreeBSD revision history is at least dumped into
hidden archives like Warren and friends keep until the time is right.

[TUHS] Free/NetBSD revision history (was Code bloat)

[Warner Losh]

On Thu, Feb 9, 2017 at 4:38 PM, Jacob Goense <dugo at xs4all.nl> wrote:
> On 2017-02-09 11:14, Warner Losh wrote:
>>
>> I thought someone had posted a github project to merge the history of
>> all publicly available sources of unix.
>
>
> That's the thing, it banks on what is publicly available.
>
> NetBSD and FreeBSD both started out from 386BSD + patchkits. They threw
> it is cvs, and engineered a release.
>
> This was all, in essence, Net/2 based, then the USL vs. BSDi lawsuit
> kicked in and was settled by a.o. "encumbering" Net/2 by agreement.
>
> Panic ensued and the NetBSD and FreeBSD teams took a chainsaw against
> what they had released until then.

That was actually part of the agreement with AT&T to end the hostilities.

NetBSD did it by butchery. FreeBSD did it by reimporting from 4.4lite,
basically (the basically part is a bit messy).

> The publicly available repos from that period are butchered.

True. I had thought the original FreeBSD 1 repo was now publicly
available. I know I can get copies of it as a FreeBSD project member.

> The number of people on earth trying to curate stuff like the history
> of locore.s/tty.c between 386BSD and the reboots of Net/FreeBSD is a
> handfull, and I'm being optimistic here.

Yea, the FreeBSD CVS tree I think has that history. It started out
life trying to make the patch-kit to 386BSD make sense as dealing with
a boatload of patches soon grew unwieldy as the number proliferated
and you started getting patches on patches.

> This stuff has been deliberately purged and hard to find. Jason Stevens
> went as far as reconstructing a NetBSD 0.8 kernel because the complete
> sources where nowhere to be found. Then he ran into the proverbial
> coughing, chain smoking guy in a raincoat in a parking garage with
> a manilla folder of a CD-ROM of
> ftp://agate.berkeley.edu/pub/NetBSD/NetBSD-0.8,
> or was it a forgotten ftp site?

Don't know anything about that... But the Truth is Out There.

> Anyway, the revision history of the "encumbered" pieces in NetBSD is
> probably lost, but at least the 0.8 checkpoint was unearthed.

I thought it was just shielded from public view and many of the NetBSD
folks had copies. Could be wrong though.

> If you take a close look at the publicly available revision history of
> FreeBSD you'll notice some serious gaps as well. Someone went through
> that cvs with an axe or surgical knife for legal reasons (and made a mess
> teleporting AMD64 to the early 90s).

Yea, CVS doesn't support repo-copying for crap. But it was done to go
from i386 to amd64.

> What dspinellis did with git is truly awesome. But I see the scars the
> USL vs. BSDi lawsuit made. I have no idea why I care, but I do. I respect
> that not everything can be made publicly available, but I pray stuff
> such as an original FreeBSD revision history is at least dumped into
> hidden archives like Warren and friends keep until the time is right.

The old CTM archives might have stuff, it that was up and running
before the lawsuit.

I know that the FreeBSD 1 archive exists in multiple places.
Compressed it is 18MB, or 185MB uncompressed (clang's history is
bigger than that, though checked out it is only about 131MB).

Warner

[TUHS] Free/NetBSD revision history (was Code bloat)

[Warner Losh]

On Thu, Feb 9, 2017 at 4:38 PM, Jacob Goense <dugo at xs4all.nl> wrote:
> That's the thing, it banks on what is publicly available.

A google search finds

https://github.com/jonathangray?tab=repositories

has CVS trees from the 1.1.5 FreeBSD CD-ROM, 386BSD + patchkit and the
csrg sources converted from SCCS to git. Are any of these useful in
filling in the gaps?

Warner

[TUHS] Code bloat (was: How Unix brings people together, or it's a small...)

[Paul Ruizendaal]

Nick,

If you want to work with LSX, you might have a look at the LSX port I did for the TI990 mini computer: http://1587660.websites.xs4all.nl/cgi-bin/9995/dir?ci=1c38b1fc8792c80b&name=lsx
It is a further development from the work that was done for BKUNIX by Leonid Broukhis (https://sourceforge.net/p/bkunix/code/HEAD/tree/).

You get stuff converted to a dialect of C acceptable by modern compilers, and some kludges like using 'char*' for 'unsigned' and 'int a[2]' for 'long a' are cleaned up.

The repository also has a V6 kernel with similar clean up and some V7 compatibility ('lseek' instead of 'seek', etc.). My next step would be to move to a V7 kernel and add TCP/IP capability. This is how I got interested in the history of sockets and TCP/IP. I have found that the BSD stack (as found in e.g. ULTRIX-11) will not fit in 64KB (note: just the network stack). The BBN stack appears to fit in 56KB, with 15KB of buffers available; I think it could be integrated with a V7 kernel as a second kernel process.

Paul

On 8 Feb 2017, at 12:21 , Nick Downing wrote:

> Yes, NetBSD and 386BSD are interesting. They could well form a good
> basis for a minimal but fully functional OS for a modern platform. One
> reservation I have though, is as follows: When 386BSD and its
> derivatives like OpenBSD, NetBSD, FreeBSD came out, Unix was still
> encumbered and thus they had to be based on 4.4BSD Lite (not even
> NET/2 was safe). Nobody made an unencumbered version of say 4.3BSD or
> even NET/2, even though it was theoretically possible, by examining
> what had to be taken out/added to produce 4.4BSD Lite.
> 
> Given that Unix is now unencumbered I believe there is no point
> adopting 4.4, or even 4.3Reno, because the main thing done in those
> releases as far as I know, is to add partial POSIX compliance. But if
> you want POSIX compliance you will not achieve minimality. As an
> example consider the BSD sigvec() routine. POSIX calls this
> sigaction(), the old SV_ONSTACK flag becomes SA_ONSTACK, the old
> integer mask becomes a sigset_t and so on... and in any reasonable
> POSIX compliant BSD the two calls are gonna have to coexist, etc.
> 
> As to 32V, I appreciate your idea, as I was having some similar
> thoughts myself. However I personally wouldn't use 32V as a basis for
> any serious porting work, because I would assume V7 and 4.3 are much
> more stable and well tested, since they ran in a lot of installations
> over a long time. That's not to denigrate the huge achievement in
> porting V7 to the VAX and producing 32V, but it probably has some
> rough edges that were smoothed out over time to produce the 4BSDs. The
> situation is a bit different for kernel/toolchain/other userspace.
> 
> As to the kernel I have been trying to make a detailed comparison
> between 32V and the BSDs, but have been a bit put off by the fact that
> all files moved around and may have been renamed, I will figure it all
> out eventually though. As to the toolchain I have compared it quite
> carefully with 4.3BSD, and I conclude you should use the later
> toolchain as there is no disadvantage and some advantages to doing so.
> As to the rest of the userspace, I BELIEVE that it's stock V7 with any
> 32-bit issues fixed, but I suspect somewhat hastily and superficially.
> 
> Producing a 32V-like kernel from 4.3BSD sources would probably be
> quite difficult, it would be relatively easy to disable added system
> calls, but harder to disable things like setpgrp() or the associated
> support in the TTY drivers. More seriously the memory management would
> have to change, I am planning however to make virtual memory optional
> in the 4.3BSD kernel, by maybe putting the 32V code back in, protected
> by #ifndef VM or some such (somewhat like Steven Schultz has done in
> porting 4.3BSD to PDP-11 to produce 2.11BSD).
> 
> On the other hand producing a 32V-like userland from the 4.3BSD
> sources would be pretty easy, I think just delete the sources for any
> executables that weren't distributed with 32V and possibly, if any of
> the tools seem particularly bloated, comment out any command line
> switches or features that weren't in 32V. Going to this level of
> effort would likely be pointless though. Another option would be
> taking V7 and re-porting it (except the toolchain) over to a 32-bit
> environment and kernel. I have developed over the past months, tools
> that make this relatively straightforward, and in the process would
> rediscover any 32-bit issues that were fixed in creating 32V. So I
> wouldn't use 32V.
> 
> On a slightly different tack, I also have been for some time
> investigating the idea of an Apple II port of Unix, there are massive
> technical issues to be solved, but I think I got a bit closer the
> other night when I decided to collect all information and resources I
> could find about Mini-Unix and LSX (LSI Unix). Both are
> self-supporting V6-based environments, the compiler can only compile
> small programs but it is nonetheless possible for each Unix to
> recomple itself. LSX I believe could run from floppies (dunno about
> 140K floppies) in less than 64K.
> 
> So, you know, true minimality is a relative term. We want something
> LSX-like for an Apple II, something 2.11BSD-like for an IBM PC/XT or
> 286 (as Peter Jeremy noted, it's a good fit, and I'd be interested to
> know more), something 4.3BSD-like for a VAX or 386... something a bit
> more fully featured for a modern 64-bit multi-gigabyte system... but
> just not as bloated as what we currently rely on. Hmm well it's hard.
> What I do know, is that I have a lot of old hardware with <16M RAM and
> Linux won't run on it anymore, and this annoys me very greatly.
> 
> In talking about FreeBSD/Linux bloat I forgot to mention the packet
> filter, iptables (Linux) or pf (FreeBSD). I have a bit of experience
> with this, since I regularly used to put 2 Ethernet cards in my home
> server and make it Internet facing through one of them and share the
> connection using NAT through the other card. But I've come to the
> conclusion this is stupid, and moreover, that putting a complete
> mini-language into the kernel just for this purpose is utterly stupid.
> Programming the thing from userspace is incredibly intricate, and all
> this complexity serves no purpose.
> 
> I recently found out about SLIRP (userspace packet rewriting) and I
> think this would be a good way to implement NAT on servers or routers
> that actually need to do NAT -- just make a userspace process that
> runs something SLIRP-like and has a raw socket to the second Ethernet
> card, and Bob's your uncle.
> 
> But this got me thinking along pretty productive lines in terms of the
> tiny Apple II port -- I have been wanting to put the 2.11BSD network
> stack into an Apple II for a long time, but I've now realized this is
> not necessary. A much better approach for those Mini-Unix or LSX or
> even V7 systems, would be to have a userspace library that does SLIP
> and contains its own TCP, UDP, IP drivers, resolver and so on. Then if
> you run a userspace program like say, ftp, which is linked to the
> userspace TCP library, it would basically just open /dev/ttyXX, bring
> up the SLIP link itself, do any necessary downloads etc, then close
> the TTY and stop responding to any IP stuff coming over the SLIP link
> whilst you quit to the prompt, until another program reopens it.
> 
> cheers, Nick
> 
> On Wed, Feb 8, 2017 at 2:56 PM, Jason Stevens
> <jsteve at superglobalmegacorp.com> wrote:
>> What about NetBSD 1.1 or even 386BSD?
>> 
>> There never was a 4.2 or 4.3 for i386 was there?
>> 
>> I'd guess the 32v userland could be built on early 4.4BSD Lite/NET2 greatly
>> reducing its footprint.
>> 
>> 
>> 
>> 
>> On February 8, 2017 11:47:03 AM GMT+08:00, Nick Downing
>> <downing.nick at gmail.com> wrote:
>>> 
>>> This is an issue that interests me quite a bit, since I was running
>>> FreeBSD in an effort to get around Linux bloat problems discussed.
>>> Well not that I really mind Linux as a user interface / runtime
>>> environment / main development machine, but I think it probably
>>> shouldn't be used as a "least common denominator" for development
>>> since you end up introducing unwanted dependencies on a whole lot of
>>> stuff.
>>> 
>>> So I was running FreeBSD as a more minimal *nix. I did quite a lot of
>>> interesting stuff with FreeBSD such as setting up diskless
>>> workstations in my home, etc. I spent a lot of time tinkering around
>>> in the kernel code. I was planning to do some serious development on
>>> 4.4BSDLite or FreeBSD to create an operating system more to my liking.
>>> So, I was looking carefully at differences since ancient *nixes.
>>> 
>>> And, I can say that FreeBSD is pretty bloated. Umm well they've added
>>> SMP, at the time it was using the Giant Lock although that could be
>>> fixed by now. They've added VFS and NFS of course. They've added an
>>> entire subsystem for block devices IIRC that handles partitioning and
>>> possibly some other sophisticated stuff, which I believe is their own
>>> design. Umm the kqueues and I believe they have their own
>>> implementation of kernel threading or lightweight processes including
>>> some sort of idle daemon. The network stack is heavily upgraded, to
>>> the extent I looked into it, the added features are things you would
>>> want (syncookies = DOS protection, etc) but also could not possibly be
>>> called minimal, and would preclude running it on other than a
>>> multi-megabyte machine. They have multiple ABIs so the kernel can
>>> accept Linux or BSD syscalls or whatever else (I used it to run
>>> Acrobat Reader Linux on my FreeBSD desktop). Umm I am pretty sure they
>>> have kernel modules ala Linux. Lots and lots and lots of stuff... and
>>> that's only considering the kernel. If you look in the ports
>>> collection you see they have incredible amounts of bloat there too...
>>> for instance GNOME, Libreoffice, LATEX, gcc, python... not that I'm
>>> denigrating these tools, since they do invaluable work and I use them
>>> every day, but the point is, you CANNOT call them minimal.
>>> 
>>> The quest for a clean minimal system goes on ->. FreeBSD is not the
>>> answer. In fact I believe 4.3BSD-Reno and 4.4 go strongly offtrack.
>>> 
>>> cheers, Nick
>>> 
>>> On Wed, Feb 8, 2017 at 1:55 PM, Greg 'groggy' Lehey <grog at lemis.com>
>>> wrote:
>>>> 
>>>> On Tuesday,  7 February 2017 at 15:38:40 -0800, Steve Johnson wrote:
>>>>> 
>>>>> Looking back, the social dynamics of the Unix group helped a lot in
>>>>> keeping the bloat small.   The rule was, whoever touches something
>>>>> last becomes its owner.  Of course, we were all free to complain
>>>>> about things, and did, but the amalgamation of tinkerings that
>>>>> characterizes most of the Linux commands just didn't happen.
>>>> 
>>>> 
>>>> Out of interest: where do you (or others) consider that the current
>>>> BSD projects it in this comparison?
>>>> 
>>>> Greg
>>>> --
>>>> Sent from my desktop computer.
>>>> Finger grog at lemis.com for PGP public key.
>>>> See complete headers for address and phone numbers.
>>>> This message is digitally signed.  If your Microsoft mail program
>>>> reports problems, please read http://lemis.com/broken-MUA
>> 
>> 
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.

[TUHS] Fwd: Code bloat (was: How Unix brings people together, or it's a small...)

[Nick Downing]

Thanks a lot for the tip Paul. It's great that others are working in
this area. Although I must say that as a kind of a "historian" I try
to go to primary sources where possible. Although I had already
converted a fair bit of code in the manner you describe, I am actually
re-converting a fair bit of it since I now have a semi-automated
system for doing so, that way I get pretty consistent results that
aren't reliant on ad-hoc decisions made during porting. Well, good
judgement is still needed, but I have a set of mental algorithms for
fixing exactly the kinds of questionable constructs you describe,
which lead to pretty consistent results. Using my scripts I converted
bin, usr.bin and lib of 4.3BSD in a few weeks, although a fair bit of
that time was spent on "bin/as" and "bin/sh" and "bin/csh" and other
pathological cases. When I have time I will proceed to ucb. I did all
subdirectories of bin (things like sed which are multi-module
programs) but not usr.bin yet.

So what I'll probably do when I get to looking at LSX is to re-convert
and then compare against your work, since either of us could quite
well have found questionable constructs missed by the other. Also,
earlier today I was looking at Noel's page about improving V6:
http://mercury.lcs.mit.edu/~jnc/tech/ImprovingV6.html
Anyway, I'm much more of a V7 guy and I think I would find V6 strange
and compromised, so I am thinking I will definitely have to apply some
of these patches, or at least check how much they increase the code
size by. At the very least, lseek() and mdate() have to go in, I'm not
sure about stdio since having a suite of the standard commands that
don't use stdio and hence are smaller/slower might be OK. But probably
my preferred approach is to calculate a patch V6 -> Mini Unix or V6 ->
LSX and then try to apply that on top of V7. Hmm.

As to moving to a V7 kernel and then adding TCP/IP I'm not sure if
this is adviseable, as I was saying earlier I think it might be best
to keep that functionality outboard from the kernel. The question in
my mind is (1) does the Mini Unix / LSX system have to be a fully
participating node on the network or can it be a leaf node without any
routing, and (2) does it have to respond to ping or incoming
connections at any time. Since my scenario is a simple SLIP link to my
home server, (1)=No for me. As to (2), I see two scenarios, (a) the
machine is used as a development machine, where I run "ed" and "cc"
and so on, and occasionally "ftp" or "rcp" as a client only, or (b)
the machine is used as a remote node for something like say data
logging or web serving, where it runs the same application all the
time, and I connect to it to retrieve results and/or download software
updates. In case (a) there are only outgoing connections. In case (b)
there are incoming connections, but the machine runs the same
application all the time, so there's no disadvantage to having TCP in
userspace. I don't envisage a more complicated scenario where it runs
inetd in the background and a console in the foreground, due to RAM
limits.

cheers, Nick

On Thu, Feb 9, 2017 at 12:56 AM, Paul Ruizendaal <pnr at planet.nl> wrote:
> Nick,
>
> If you want to work with LSX, you might have a look at the LSX port I did for the TI990 mini computer: http://1587660.websites.xs4all.nl/cgi-bin/9995/dir?ci=1c38b1fc8792c80b&name=lsx
> It is a further development from the work that was done for BKUNIX by Leonid Broukhis (https://sourceforge.net/p/bkunix/code/HEAD/tree/).
>
> You get stuff converted to a dialect of C acceptable by modern compilers, and some kludges like using 'char*' for 'unsigned' and 'int a[2]' for 'long a' are cleaned up.
>
> The repository also has a V6 kernel with similar clean up and some V7 compatibility ('lseek' instead of 'seek', etc.). My next step would be to move to a V7 kernel and add TCP/IP capability. This is how I got interested in the history of sockets and TCP/IP. I have found that the BSD stack (as found in e.g. ULTRIX-11) will not fit in 64KB (note: just the network stack). The BBN stack appears to fit in 56KB, with 15KB of buffers available; I think it could be integrated with a V7 kernel as a second kernel process.
>
> Paul
>
> On 8 Feb 2017, at 12:21 , Nick Downing wrote:
>
>> Yes, NetBSD and 386BSD are interesting. They could well form a good
>> basis for a minimal but fully functional OS for a modern platform. One
>> reservation I have though, is as follows: When 386BSD and its
>> derivatives like OpenBSD, NetBSD, FreeBSD came out, Unix was still
>> encumbered and thus they had to be based on 4.4BSD Lite (not even
>> NET/2 was safe). Nobody made an unencumbered version of say 4.3BSD or
>> even NET/2, even though it was theoretically possible, by examining
>> what had to be taken out/added to produce 4.4BSD Lite.
>>
>> Given that Unix is now unencumbered I believe there is no point
>> adopting 4.4, or even 4.3Reno, because the main thing done in those
>> releases as far as I know, is to add partial POSIX compliance. But if
>> you want POSIX compliance you will not achieve minimality. As an
>> example consider the BSD sigvec() routine. POSIX calls this
>> sigaction(), the old SV_ONSTACK flag becomes SA_ONSTACK, the old
>> integer mask becomes a sigset_t and so on... and in any reasonable
>> POSIX compliant BSD the two calls are gonna have to coexist, etc.
>>
>> As to 32V, I appreciate your idea, as I was having some similar
>> thoughts myself. However I personally wouldn't use 32V as a basis for
>> any serious porting work, because I would assume V7 and 4.3 are much
>> more stable and well tested, since they ran in a lot of installations
>> over a long time. That's not to denigrate the huge achievement in
>> porting V7 to the VAX and producing 32V, but it probably has some
>> rough edges that were smoothed out over time to produce the 4BSDs. The
>> situation is a bit different for kernel/toolchain/other userspace.
>>
>> As to the kernel I have been trying to make a detailed comparison
>> between 32V and the BSDs, but have been a bit put off by the fact that
>> all files moved around and may have been renamed, I will figure it all
>> out eventually though. As to the toolchain I have compared it quite
>> carefully with 4.3BSD, and I conclude you should use the later
>> toolchain as there is no disadvantage and some advantages to doing so.
>> As to the rest of the userspace, I BELIEVE that it's stock V7 with any
>> 32-bit issues fixed, but I suspect somewhat hastily and superficially.
>>
>> Producing a 32V-like kernel from 4.3BSD sources would probably be
>> quite difficult, it would be relatively easy to disable added system
>> calls, but harder to disable things like setpgrp() or the associated
>> support in the TTY drivers. More seriously the memory management would
>> have to change, I am planning however to make virtual memory optional
>> in the 4.3BSD kernel, by maybe putting the 32V code back in, protected
>> by #ifndef VM or some such (somewhat like Steven Schultz has done in
>> porting 4.3BSD to PDP-11 to produce 2.11BSD).
>>
>> On the other hand producing a 32V-like userland from the 4.3BSD
>> sources would be pretty easy, I think just delete the sources for any
>> executables that weren't distributed with 32V and possibly, if any of
>> the tools seem particularly bloated, comment out any command line
>> switches or features that weren't in 32V. Going to this level of
>> effort would likely be pointless though. Another option would be
>> taking V7 and re-porting it (except the toolchain) over to a 32-bit
>> environment and kernel. I have developed over the past months, tools
>> that make this relatively straightforward, and in the process would
>> rediscover any 32-bit issues that were fixed in creating 32V. So I
>> wouldn't use 32V.
>>
>> On a slightly different tack, I also have been for some time
>> investigating the idea of an Apple II port of Unix, there are massive
>> technical issues to be solved, but I think I got a bit closer the
>> other night when I decided to collect all information and resources I
>> could find about Mini-Unix and LSX (LSI Unix). Both are
>> self-supporting V6-based environments, the compiler can only compile
>> small programs but it is nonetheless possible for each Unix to
>> recomple itself. LSX I believe could run from floppies (dunno about
>> 140K floppies) in less than 64K.
>>
>> So, you know, true minimality is a relative term. We want something
>> LSX-like for an Apple II, something 2.11BSD-like for an IBM PC/XT or
>> 286 (as Peter Jeremy noted, it's a good fit, and I'd be interested to
>> know more), something 4.3BSD-like for a VAX or 386... something a bit
>> more fully featured for a modern 64-bit multi-gigabyte system... but
>> just not as bloated as what we currently rely on. Hmm well it's hard.
>> What I do know, is that I have a lot of old hardware with <16M RAM and
>> Linux won't run on it anymore, and this annoys me very greatly.
>>
>> In talking about FreeBSD/Linux bloat I forgot to mention the packet
>> filter, iptables (Linux) or pf (FreeBSD). I have a bit of experience
>> with this, since I regularly used to put 2 Ethernet cards in my home
>> server and make it Internet facing through one of them and share the
>> connection using NAT through the other card. But I've come to the
>> conclusion this is stupid, and moreover, that putting a complete
>> mini-language into the kernel just for this purpose is utterly stupid.
>> Programming the thing from userspace is incredibly intricate, and all
>> this complexity serves no purpose.
>>
>> I recently found out about SLIRP (userspace packet rewriting) and I
>> think this would be a good way to implement NAT on servers or routers
>> that actually need to do NAT -- just make a userspace process that
>> runs something SLIRP-like and has a raw socket to the second Ethernet
>> card, and Bob's your uncle.
>>
>> But this got me thinking along pretty productive lines in terms of the
>> tiny Apple II port -- I have been wanting to put the 2.11BSD network
>> stack into an Apple II for a long time, but I've now realized this is
>> not necessary. A much better approach for those Mini-Unix or LSX or
>> even V7 systems, would be to have a userspace library that does SLIP
>> and contains its own TCP, UDP, IP drivers, resolver and so on. Then if
>> you run a userspace program like say, ftp, which is linked to the
>> userspace TCP library, it would basically just open /dev/ttyXX, bring
>> up the SLIP link itself, do any necessary downloads etc, then close
>> the TTY and stop responding to any IP stuff coming over the SLIP link
>> whilst you quit to the prompt, until another program reopens it.
>>
>> cheers, Nick
>>
>> On Wed, Feb 8, 2017 at 2:56 PM, Jason Stevens
>> <jsteve at superglobalmegacorp.com> wrote:
>>> What about NetBSD 1.1 or even 386BSD?
>>>
>>> There never was a 4.2 or 4.3 for i386 was there?
>>>
>>> I'd guess the 32v userland could be built on early 4.4BSD Lite/NET2 greatly
>>> reducing its footprint.
>>>
>>>
>>>
>>>
>>> On February 8, 2017 11:47:03 AM GMT+08:00, Nick Downing
>>> <downing.nick at gmail.com> wrote:
>>>>
>>>> This is an issue that interests me quite a bit, since I was running
>>>> FreeBSD in an effort to get around Linux bloat problems discussed.
>>>> Well not that I really mind Linux as a user interface / runtime
>>>> environment / main development machine, but I think it probably
>>>> shouldn't be used as a "least common denominator" for development
>>>> since you end up introducing unwanted dependencies on a whole lot of
>>>> stuff.
>>>>
>>>> So I was running FreeBSD as a more minimal *nix. I did quite a lot of
>>>> interesting stuff with FreeBSD such as setting up diskless
>>>> workstations in my home, etc. I spent a lot of time tinkering around
>>>> in the kernel code. I was planning to do some serious development on
>>>> 4.4BSDLite or FreeBSD to create an operating system more to my liking.
>>>> So, I was looking carefully at differences since ancient *nixes.
>>>>
>>>> And, I can say that FreeBSD is pretty bloated. Umm well they've added
>>>> SMP, at the time it was using the Giant Lock although that could be
>>>> fixed by now. They've added VFS and NFS of course. They've added an
>>>> entire subsystem for block devices IIRC that handles partitioning and
>>>> possibly some other sophisticated stuff, which I believe is their own
>>>> design. Umm the kqueues and I believe they have their own
>>>> implementation of kernel threading or lightweight processes including
>>>> some sort of idle daemon. The network stack is heavily upgraded, to
>>>> the extent I looked into it, the added features are things you would
>>>> want (syncookies = DOS protection, etc) but also could not possibly be
>>>> called minimal, and would preclude running it on other than a
>>>> multi-megabyte machine. They have multiple ABIs so the kernel can
>>>> accept Linux or BSD syscalls or whatever else (I used it to run
>>>> Acrobat Reader Linux on my FreeBSD desktop). Umm I am pretty sure they
>>>> have kernel modules ala Linux. Lots and lots and lots of stuff... and
>>>> that's only considering the kernel. If you look in the ports
>>>> collection you see they have incredible amounts of bloat there too...
>>>> for instance GNOME, Libreoffice, LATEX, gcc, python... not that I'm
>>>> denigrating these tools, since they do invaluable work and I use them
>>>> every day, but the point is, you CANNOT call them minimal.
>>>>
>>>> The quest for a clean minimal system goes on ->. FreeBSD is not the
>>>> answer. In fact I believe 4.3BSD-Reno and 4.4 go strongly offtrack.
>>>>
>>>> cheers, Nick
>>>>
>>>> On Wed, Feb 8, 2017 at 1:55 PM, Greg 'groggy' Lehey <grog at lemis.com>
>>>> wrote:
>>>>>
>>>>> On Tuesday,  7 February 2017 at 15:38:40 -0800, Steve Johnson wrote:
>>>>>>
>>>>>> Looking back, the social dynamics of the Unix group helped a lot in
>>>>>> keeping the bloat small.   The rule was, whoever touches something
>>>>>> last becomes its owner.  Of course, we were all free to complain
>>>>>> about things, and did, but the amalgamation of tinkerings that
>>>>>> characterizes most of the Linux commands just didn't happen.
>>>>>
>>>>>
>>>>> Out of interest: where do you (or others) consider that the current
>>>>> BSD projects it in this comparison?
>>>>>
>>>>> Greg
>>>>> --
>>>>> Sent from my desktop computer.
>>>>> Finger grog at lemis.com for PGP public key.
>>>>> See complete headers for address and phone numbers.
>>>>> This message is digitally signed.  If your Microsoft mail program
>>>>> reports problems, please read http://lemis.com/broken-MUA
>>>
>>>
>>> --
>>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>

[TUHS] Code bloat (was: How Unix brings people together, or it's a small...)

[Paul Ruizendaal]

On 9 Feb 2017, at 4:02 , Nick Downing wrote:

> As to moving to a V7 kernel and then adding TCP/IP I'm not sure if
> this is adviseable, as I was saying earlier I think it might be best
> to keep that functionality outboard from the kernel.

That approach was taken in various early implementations, with varying
degrees of success.

The best one seems to have been the 3Com stack, which puts IP in the
kernel and TCP in a daemon. By the way, this implementation is also
where SLIP seems to have originated.

http://bitsavers.informatik.uni-stuttgart.de/pdf/3Com/3Com_UNET_Nov80.pdf

> and (2) does it have to respond to ping or incoming
> connections at any time.

I'm not sure economizing on ICMP support is the best approach. Perhaps
economizing on fragmentation and and window management is better. For
example, the 1979 Wingfield implementation discards out of order packets
and simply waits for retransmission of the expected packet; this
simplifies the code and greatly reduces the need for buffer space.

Arguably, the handling of incoming connections does not require much code
or data.

---

A TCP connection spends most of its time in the 'established' state. I
wonder if just putting the code for this state in the kernel and handling
only the state changes and other states in a daemon is perhaps the best
split on constrained hardware. I'm not aware of any historical
implementation having that design, so perhaps it is flawed thinking.

Paul

[TUHS] Code bloat (was: How Unix brings people together, or it's a small...)

[Michael Kjörling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1790 bytes --]

On 9 Feb 2017 10:19 +0100, from pnr at planet.nl (Paul Ruizendaal):
> A TCP connection spends most of its time in the 'established' state. I
> wonder if just putting the code for this state in the kernel and handling
> only the state changes and other states in a daemon is perhaps the best
> split on constrained hardware. I'm not aware of any historical
> implementation having that design, so perhaps it is flawed thinking.

Wouldn't the state change code need to be executable, even if it
technically isn't in the kernel? I can see no _obvious_ reason why you
_couldn't_ have a daemon handling state changes and non-established
TCP connections, but I'm having a hard time seeing what it would save
you in terms of code size. If anything, it seems like the code would
need to be a little larger in total, because now you have two
components interacting where previously there was just one component
doing all of the work.

One benefit I can see though would be to reduce the incidence of bugs
in the established-state code; less code running privileged means less
things to screw up so badly that the system panics (or scribbles over
the wrong data). A crashed TCP daemon would be an annoyance, but would
at least allow you to restart it or to reboot the system at leisure
rather than having the whole system come to a screeching halt.

You'd need some amount of synchronization either way, to prevent two
connections changing state at the same time from stepping on each
other's toes, but that would hardly be unheard of in the kernel of a
multitasking OS...

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

[TUHS] Code bloat (was: How Unix brings people together, or it's a small...)

[Paul Ruizendaal]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 341 bytes --]


On 9 Feb 2017, at 10:58 , Michael Kjörling wrote:

> [...] but I'm having a hard time seeing what it would save
> you in terms of code size.

The main benefit would be that one would not have to copy
all data packets into the daemon and then back into the
kernel again. Normal data packets would flow straight to
the user process.

Paul

[TUHS] Code bloat (was: How Unix brings people together, or it's a small...)

[Larry McVoy]

> The best one seems to have been the 3Com stack, which puts IP in the
> kernel and TCP in a daemon. By the way, this implementation is also
> where SLIP seems to have originated.

As much as I love all the nostalgia, and as cool as SLIP was, if I never
have to experience the pain of trying to run TCP/IP over a modem again,
I'll be happy.  For me, SLIP was just not worth it.  Too much overhead
when bandwidth was too precious.  A dial up terminal emulator was a
better answer in my experience.

Don't get me wrong, SLIP was cool.   Modems were slow.

[TUHS] Code bloat (was: How Unix brings people together, or it's a small...)

[Warner Losh]

On Thu, Feb 9, 2017 at 9:36 AM, Larry McVoy <lm at mcvoy.com> wrote:
>> The best one seems to have been the 3Com stack, which puts IP in the
>> kernel and TCP in a daemon. By the way, this implementation is also
>> where SLIP seems to have originated.
>
> As much as I love all the nostalgia, and as cool as SLIP was, if I never
> have to experience the pain of trying to run TCP/IP over a modem again,
> I'll be happy.  For me, SLIP was just not worth it.  Too much overhead
> when bandwidth was too precious.  A dial up terminal emulator was a
> better answer in my experience.
>
> Don't get me wrong, SLIP was cool.   Modems were slow.

Let's not forget the latency. 128ms of latency over modems was
awesomely low... That changed relatively little, even as the speeds
went from 1200 baud up to 57.6k.

While I am nostalgic for my early coding days on a 1200 baud video
screen and a 300 baud printer, I do not miss the speed or the latency
issues...

Warner

[TUHS] Code bloat (was: How Unix brings people together, or it's a small...)

[Larry McVoy]

On Thu, Feb 09, 2017 at 09:42:09AM -0700, Warner Losh wrote:
> On Thu, Feb 9, 2017 at 9:36 AM, Larry McVoy <lm at mcvoy.com> wrote:
> >> The best one seems to have been the 3Com stack, which puts IP in the
> >> kernel and TCP in a daemon. By the way, this implementation is also
> >> where SLIP seems to have originated.
> >
> > As much as I love all the nostalgia, and as cool as SLIP was, if I never
> > have to experience the pain of trying to run TCP/IP over a modem again,
> > I'll be happy.  For me, SLIP was just not worth it.  Too much overhead
> > when bandwidth was too precious.  A dial up terminal emulator was a
> > better answer in my experience.
> >
> > Don't get me wrong, SLIP was cool.   Modems were slow.
> 
> Let's not forget the latency. 128ms of latency over modems was
> awesomely low... That changed relatively little, even as the speeds
> went from 1200 baud up to 57.6k.
> 
> While I am nostalgic for my early coding days on a 1200 baud video
> screen and a 300 baud printer, I do not miss the speed or the latency
> issues...

Exactly.  I live in the Santa Cruz mountains, which is awesome (well,
mostly, right now we're having tons of mudlsides, too much rain).  I'm
quite remote, we have a mountain lion that comes through here nightly
(I know because I lost a dog to it and they showed me the radio collar
tracking, on a map it looks like someone took a pencil and scribbled 
back and forth as hard as they could through our place).

In spite of that, I'm typing away to you all, I'm 3ms away from 8.8.8.8
(Google's dns server).  Go wireless.  It's pretty remarkable to be here
and have decent net connectivity.

I do not yearn for the days of SLIP.
-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

[TUHS] Code bloat (was: How Unix brings people together, or it's a small...)

[Steffen Nurpmeso]

Larry McVoy <lm at mcvoy.com> wrote:
 |Exactly.  I live in the Santa Cruz mountains, which is awesome (well,
 ...
 |quite remote, we have a mountain lion that comes through here nightly

That is pretty cool!  Some are still alive!!

 |(I know because I lost a dog to it and they showed me the radio collar

That is .. not so cool.  There is quite some sympathy from
Darmstadt, Germany.  (But, mind you, these are all street pissers!)

 |tracking, on a map it looks like someone took a pencil and scribbled 
 |back and forth as hard as they could through our place).
 |
 |In spite of that, I'm typing away to you all, I'm 3ms away from 8.8.8.8
 |(Google's dns server).  Go wireless.  It's pretty remarkable to be here
 |and have decent net connectivity.

America is first world.  This statement declassifies most of
Germanies countryside as second world, at maximum.  I for one am
happy if i get a constant stream equivalent to ISDN.  In the outer
region of a city in one of the richest parts of Germany, that is.

--steffen

[TUHS] offtopic: broadband (redirect from bloat)

[Larry McVoy]

On Thu, Feb 09, 2017 at 06:24:12PM +0100, Steffen Nurpmeso wrote:
> Larry McVoy <lm at mcvoy.com> wrote:
>  |Exactly.  I live in the Santa Cruz mountains, which is awesome (well,
>  ...
>  |quite remote, we have a mountain lion that comes through here nightly
> 
> That is pretty cool!  Some are still alive!!

Good lord, tons and tons are alive.  I wanted the one that got my dog
moved and Fish & Game flat out told me there was no place to move it 
that didn't already have other mountain lions.  

>  |In spite of that, I'm typing away to you all, I'm 3ms away from 8.8.8.8
>  |(Google's dns server).  Go wireless.  It's pretty remarkable to be here
>  |and have decent net connectivity.
> 
> America is first world.  This statement declassifies most of
> Germanies countryside as second world, at maximum.  I for one am
> happy if i get a constant stream equivalent to ISDN.  In the outer
> region of a city in one of the richest parts of Germany, that is.

Really?  I thought that America was trailing in broadband.  And in
Germany?  I'm stunned, usually we're looking at Germany and sighing
about how much better run it is than our country.  You guys are very
efficient.  How is it possible that you have crappy internet, are you
sure that's normal?

[TUHS] offtopic: broadband (redirect from bloat)

[Steffen Nurpmeso]

Larry McVoy <lm at mcvoy.com> wrote:
 |On Thu, Feb 09, 2017 at 06:24:12PM +0100, Steffen Nurpmeso wrote:
 |> Larry McVoy <lm at mcvoy.com> wrote:
 |>|Exactly.  I live in the Santa Cruz mountains, which is awesome (well,
 |>  ...
 |>|quite remote, we have a mountain lion that comes through here nightly
 |> 
 |> That is pretty cool!  Some are still alive!!
 |
 |Good lord, tons and tons are alive.  I wanted the one that got my dog
 |moved and Fish & Game flat out told me there was no place to move it 
 |that didn't already have other mountain lions.  

At least it didn't get you.  Very frightening.  It surely will not
help you or your dog, we even loose our last little wildcats these
days...  For cameras of the white some african bushmen steal fresh
meat directly from Lions, which can be fooled so much, completely
bewildered.  Also that young French girl which simply talked to
all animals and became accepted, in Africa that is, i forgot her
name.  Your dog did not know all that.. i am really sorry.

 |>|In spite of that, I'm typing away to you all, I'm 3ms away from 8.8.8.8
 |>|(Google's dns server).  Go wireless.  It's pretty remarkable to be here
 |>|and have decent net connectivity.
 |> 
 |> America is first world.  This statement declassifies most of
 |> Germanies countryside as second world, at maximum.  I for one am
 |> happy if i get a constant stream equivalent to ISDN.  In the outer
 |> region of a city in one of the richest parts of Germany, that is.
 |
 |Really?  I thought that America was trailing in broadband.  And in
 |Germany?  I'm stunned, usually we're looking at Germany and sighing
 |about how much better run it is than our country.  You guys are very
 |efficient.  How is it possible that you have crappy internet, are you
 |sure that's normal?

Clean Diesel is only a paper moon.  To quote Monty Python, and
that piece of shit that life is, if you look at it.  [Smile]

But this is an everlasting story it seems, already at ISDN times
some villages connected themselves via privately funded fast
point-to-point wireless, for example.  Just recently (one or two
years ago) a complete region not more than about 10 kilometres
away (eastwards) from the "hot" north-south line Frankfurt
/ Darmstadt / Mannheim|Ludwigshafen / Heidelberg had to use
private money in order to become connected to i think DSL.  Must
be two years, i remember seeing a lot of advertisment posters
plastered all over the region last summer, where the telecom
companies now offered pretty cheap service even in this region!
But running on environment payed by people has always been the
base, anyway.  But that on top of normal taxes, that makes you
feel second-class it seems to me: votes show up which suggest just
that.  Have i told this already, by the way?  Uh, i hope not.

All this is nothing against the worldwide phenomenon of
urbanisation, of course.  Here we have villages which ran out of
doctors, and even bakeries.  Very much of a problem given that
many villages consist only of old people.  In Spain and Italy many
small villages even turned to ghost towns.  Well, so it is.
And at least most of us still have enough freshwater for plants,
animals and humans.  How about that, where will i get my almonds
from if California has no more water nor these brown-skinned farm
workers?  I am also in fear for this excellent organic olive oil
from Crete, it will become a desert hopefully not to soon.
Oh what a life you had, with those six meter Cadillacs without
a roof, and then the Californian sun.  grrrrrrrr.

Hm.  Wireless will get better (i am ~550 msec away from my --
right now), and lesser people can steal copper cable from out of
the grounds.  What will they do.

--steffen

[TUHS] offtopic: broadband (redirect from bloat)

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2052 bytes --]

Larry McVoy <lm at mcvoy.com> wrote:

> > America is first world.  This statement declassifies most of
> > Germanies countryside as second world, at maximum.  I for one am
> > happy if i get a constant stream equivalent to ISDN.  In the outer
> > region of a city in one of the richest parts of Germany, that is.
>
> Really?  I thought that America was trailing in broadband.  And in
> Germany?  I'm stunned, usually we're looking at Germany and sighing
> about how much better run it is than our country.  You guys are very
> efficient.  How is it possible that you have crappy internet, are you
> sure that's normal?

What technology is available depends on where you are located.

Around 1980, I designed and build a 300 Baud modem and used it together with a 
VT50a (12x80 uppercase only) from home. Then in 1991 we designed and build an 
ISDN adaptor for a Sun-3/50 with some friends (I had plenty of them from 
H.Berthold AG at that time). We installed some of them in the TU-Berlin and 
this way could use the internet from home.

I got my own ISDN at home in 1992 and switched from DSL to VDSL in march 2008.

From an offer from German Telekom, I could get ADSL with 16Mbit even in my 
weekend house 60 km from the center of Berlin. The property is in a nature 
conservation area. 5km from this place, wolves have been seen.....

German Telekom will shut down ISDN in Germany to the end of this year and my
ISDN connection has been converted into SIP two months ago...

But hey, on November 12 1877, the worlds first phone company started their 
services in Berlin and in 1923 the first auto-dial phone system opened in 
Berlin.

I am not sure where Steffen exactly lives and why he has problems.

What is hard to get and expensive (iff) in Germany is internet over optical.

Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

[TUHS] Code bloat (was: How Unix brings people together,

[Corey Lindsly]

> In spite of that, I'm typing away to you all, I'm 3ms away from 8.8.8.8
> (Google's dns server).  Go wireless.  It's pretty remarkable to be here
> and have decent net connectivity.
> 
> I do not yearn for the days of SLIP.
> -- 
> ---
> Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

3ms? Really? I'm impressed, and I'd like to see your traceroute. We peer 
directly with Google and I get 4-5ms. Do share.

[root at daytona ~]# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=59 time=5.43 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=59 time=5.39 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=59 time=5.43 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=59 time=5.02 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=59 time=5.30 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=59 time=5.35 ms


Pittock7206A#trace 8.8.8.8

Type escape sequence to abort.
Tracing the route to 8.8.8.8

  1 198.32.195.34 4 msec 4 msec 4 msec
  2 108.170.245.113 [AS 15169] 4 msec
    108.170.245.97 [AS 15169] 8 msec 4 msec
  3 209.85.246.217 [AS 15169] 4 msec
    209.85.246.219 [AS 15169] 4 msec
    209.85.245.67 [AS 15169] 8 msec
  4 8.8.8.8 [AS 15169] 4 msec 4 msec 4 msec
Pittock7206A#


--corey

[TUHS] Code bloat (was: How Unix brings people together,

[pechter]

7.9 ms to my wifi in FIOS in NJ. 

It's not the ping time... It's the throughput that is often lacking in real world use. No matter the pipe size. 

Bill
Sent from my android device.

-----Original Message-----
From: Corey Lindsly <corey@lod.com>
To: Larry McVoy <lm at mcvoy.com>
Cc: TUHS main list <tuhs at minnie.tuhs.org>
Sent: Thu, 09 Feb 2017 14:55
Subject: Re: [TUHS] Code bloat (was: How Unix brings people together,


> In spite of that, I'm typing away to you all, I'm 3ms away from 8.8.8.8
> (Google's dns server).  Go wireless.  It's pretty remarkable to be here
> and have decent net connectivity.
> 
> I do not yearn for the days of SLIP.
> -- 
> ---
> Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

3ms? Really? I'm impressed, and I'd like to see your traceroute. We peer 
directly with Google and I get 4-5ms. Do share.

[root at daytona ~]# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=59 time=5.43 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=59 time=5.39 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=59 time=5.43 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=59 time=5.02 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=59 time=5.30 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=59 time=5.35 ms


Pittock7206A#trace 8.8.8.8

Type escape sequence to abort.
Tracing the route to 8.8.8.8

  1 198.32.195.34 4 msec 4 msec 4 msec
  2 108.170.245.113 [AS 15169] 4 msec
    108.170.245.97 [AS 15169] 8 msec 4 msec
  3 209.85.246.217 [AS 15169] 4 msec
    209.85.246.219 [AS 15169] 4 msec
    209.85.245.67 [AS 15169] 8 msec
  4 8.8.8.8 [AS 15169] 4 msec 4 msec 4 msec
Pittock7206A#


--corey

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170209/520086eb/attachment.html>

[TUHS] Code bloat (was: How Unix brings people together,

[Arthur Krewat]

WAY off-topic. Sorry.

On 2/9/2017 2:54 PM, Corey Lindsly wrote:
> 3ms? Really? I'm impressed, and I'd like to see your traceroute. We peer
> directly with Google and I get 4-5ms. Do share.
>
>

Two fiber connections here to Verizon FIOS, one business, one residential:

FIOS business fiber 50M/50M in New York, Long Island to be exact, low 
4's, high 3's:

root at hnet1:/data/tmp# ping -s 8.8.8.8
PING 8.8.8.8: 56 data bytes
64 bytes from google-public-dns-a.google.com (8.8.8.8): icmp_seq=0. 
time=4.167 ms
64 bytes from google-public-dns-a.google.com (8.8.8.8): icmp_seq=1. 
time=3.871 ms
64 bytes from google-public-dns-a.google.com (8.8.8.8): icmp_seq=2. 
time=4.062 ms
64 bytes from google-public-dns-a.google.com (8.8.8.8): icmp_seq=3. 
time=4.093 ms
64 bytes from google-public-dns-a.google.com (8.8.8.8): icmp_seq=4. 
time=4.050 ms
64 bytes from google-public-dns-a.google.com (8.8.8.8): icmp_seq=5. 
time=3.900 ms

root at hnet1:/data/tmp# traceroute -t 2 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 40 byte packets
  1  <removed> (<removed>)  0.598 ms  0.615 ms 0.559 ms
  2  B3384.NYCMNY-LCR-22.verizon-gni.net (100.41.217.224) 2.884 ms  
3.137 ms  3.903 ms
  3  * * *
  4  0.ae11.GW13.NYC1.ALTER.NET (140.222.234.191)  2.719 ms 
0.ae13.GW13.NYC1.ALTER.NET (140.222.234.193)  2.560 ms 
0.ae11.GW13.NYC1.ALTER.NET (140.222.234.191)  2.377 ms
  5  google-gw.customer.alter.net (204.148.18.206)  62.332 ms  56.885 
ms  55.203 ms
  6  209.85.247.33 (209.85.247.33)  2.885 ms  2.771 ms 2.735 ms
  7  108.170.233.235 (108.170.233.235)  2.936 ms 108.170.235.13 
(108.170.235.13)  3.490 ms 108.170.233.233 (108.170.233.233)  3.152 ms
  8  google-public-dns-a.google.com (8.8.8.8)  3.495 ms * *

FIOS residential 150/150M, low 3's:

medusa# ping -s 8.8.8.8
PING 8.8.8.8: 56 data bytes
64 bytes from google-public-dns-a.google.com (8.8.8.8): icmp_seq=0. 
time=3.497 ms
64 bytes from google-public-dns-a.google.com (8.8.8.8): icmp_seq=1. 
time=3.286 ms
64 bytes from google-public-dns-a.google.com (8.8.8.8): icmp_seq=2. 
time=3.368 ms
64 bytes from google-public-dns-a.google.com (8.8.8.8): icmp_seq=3. 
time=3.315 ms

Traceroute not available without altering my Cisco ASA config.

I think it's entirely possible that 8.8.8.8 is more than one host, and 
depending on geographical location you're being routed to any of a 
number of actual hosts ;)

Speed of light from New York to California is approximately 1.3ms. I 
can't imagine all these routers don't add SOMETHING to do the latency... 
so I can't see how I can ping a California hosts in the low 3 ms area.

[TUHS] Code bloat (was: How Unix brings people together,

[Jacob Goense]

On 2017-02-09 15:30, Arthur Krewat wrote:
> I think it's entirely possible that 8.8.8.8 is more than one host, and
> depending on geographical location you're being routed to any of a
> number of actual hosts ;)

This is an old trick, no!? Spread out a bunch of boxen w/ the same
IP and let them announce using eg. routed/zebra. BGP takes care of the 
rest.

[TUHS] Code bloat (was: How Unix brings people together,

[Larry McVoy]

> 3ms? Really? I'm impressed, and I'd like to see your traceroute. We peer 
> directly with Google and I get 4-5ms. Do share.

My kids are home and watching netflix or something so right now it is 
4-50ms, just varies.   When I said 3, it was 3.something, I didn't really
look.  Here's some pings (couple of 2.somethings in there):

64 bytes from 8.8.8.8: icmp_seq=60 ttl=57 time=3.67 ms
64 bytes from 8.8.8.8: icmp_seq=61 ttl=57 time=37.6 ms
64 bytes from 8.8.8.8: icmp_seq=62 ttl=57 time=3.88 ms
64 bytes from 8.8.8.8: icmp_seq=63 ttl=57 time=3.40 ms
64 bytes from 8.8.8.8: icmp_seq=64 ttl=57 time=3.81 ms
64 bytes from 8.8.8.8: icmp_seq=65 ttl=57 time=11.6 ms
64 bytes from 8.8.8.8: icmp_seq=66 ttl=57 time=48.4 ms
64 bytes from 8.8.8.8: icmp_seq=67 ttl=57 time=14.6 ms
64 bytes from 8.8.8.8: icmp_seq=68 ttl=57 time=2.85 ms
64 bytes from 8.8.8.8: icmp_seq=69 ttl=57 time=3.19 ms
64 bytes from 8.8.8.8: icmp_seq=70 ttl=57 time=3.78 ms
64 bytes from 8.8.8.8: icmp_seq=71 ttl=57 time=2.94 ms

traceroute:

                             My traceroute  [v0.86]
slovax.mcvoy.com (0.0.0.0)                             Thu Feb  9 13:05:52 2017
Resolver: Received error response 2. (server failure)er of fields   quit
                                       Packets               Pings
 Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. pf-lm.mcvoy.com                   0.0%     9    0.2   0.2   0.2   0.2   0.0
 2. 192.169.23.249.static.etheric.ne  0.0%     9    0.5   0.6   0.4   0.9   0.0
 3. 208.74.178.193.static.etheric.ne  0.0%     9    6.2  15.6   3.9  52.8  16.6
 4. 10.10.112.1                       0.0%     9    2.3   8.6   1.8  28.3   8.0
 5. 10.11.109.1                       0.0%     9    2.7   5.4   2.5  16.5   4.7
 6. 10.11.110.6                       0.0%     8    9.8  12.0   3.0  36.0  10.7
 7. eqixsj-google-gige.google.com     0.0%     8    7.3   8.0   2.8  27.3   7.8
 8. 108.170.242.81                    0.0%     8    5.9   5.5   3.1  10.4   2.2
 9. 216.239.49.93                     0.0%     8    7.8   9.2   3.6  22.6   6.7
10. google-public-dns-a.google.com    0.0%     8    4.0   8.1   3.3  18.3   4.9

[TUHS] Code bloat (was: How Unix brings people together, or it's a small...)

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 659 bytes --]

Larry McVoy <lm at mcvoy.com> wrote:

> In spite of that, I'm typing away to you all, I'm 3ms away from 8.8.8.8
> (Google's dns server).  Go wireless.  It's pretty remarkable to be here
> and have decent net connectivity.

Is this a one way time or a ping roundtrip time?

What kind of technology is this based on?

My VDSL connection offers a ping round trip time of 15ms to the next hop.

Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

[TUHS] Code bloat

[William Pechter]

Larry McVoy wrote:
>> The best one seems to have been the 3Com stack, which puts IP in the
>> kernel and TCP in a daemon. By the way, this implementation is also
>> where SLIP seems to have originated.
> As much as I love all the nostalgia, and as cool as SLIP was, if I never
> have to experience the pain of trying to run TCP/IP over a modem again,
> I'll be happy.  For me, SLIP was just not worth it.  Too much overhead
> when bandwidth was too precious.  A dial up terminal emulator was a
> better answer in my experience.
>
> Don't get me wrong, SLIP was cool.   Modems were slow.
Back in the day when slip was just starting to get traction (and before PPP)
I was happy with a dial-up connection to read news and work remotely
and a 9600 baud telebit for UUCP file transfer to home for work that
could be sent home and done off-line.

Bill

-- 

Digital had it then.  Don't you wish you could buy it now!
pechter-at-gmail.com  http://xkcd.com/705/

[TUHS] Code bloat (was: How Unix brings people together, or it's a small...)

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1359 bytes --]

On Thu, Feb 9, 2017 at 4:19 AM, Paul Ruizendaal <pnr at planet.nl> wrote:

>
> The best one seems to have been the 3Com stack, which puts IP in the
> kernel and TCP in a daemon.

​This is true.​





> By the way, this implementation is also
> ​ ​
> where SLIP seems to have originated.

​hmmm...   I'm not so sure I see that leap/where you came to that
conclusion.  I'm guessing you are thinking same from the picture on page 37
where Bob shows an RS-232 driver in the architectural diagram.  FYI:   The
code base came with a 3Cxxx driver for their Ethernet board only and as I
said, the Steve Glaser wrote the second driver for the Unibus HyperChannel
and I think there was a driver for the Xerox 3Meg ethernet controller but I
don't remember ever seeing it in the source kit.

FYI: If my memory serves me, the first SLIP implementations for any IP
stack were done I thought for some reason at Harvard with some hacks to the
BBN/MIT tcp stack on the DZ drivers as an alternative to the Berknet stack
(not IP).  FYI: Berknet was very low costs, 9600baud serial point to point
to links, primarily for moving mail and small files, we can take this off
line if you need to know more.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170209/e123f85b/attachment.html>

[TUHS] Code bloat (was: How Unix brings people together, or it's a small...)

[Peter Jeremy]

On 2017-Feb-08 14:47:03 +1100, Nick Downing <downing.nick at gmail.com> wrote:
[FreeBSD bloat]
>that's only considering the kernel. If you look in the ports
>collection you see they have incredible amounts of bloat there too...

Note the the ports system is not a core part of FreeBSD - it's for bits
that have deliberately been left out of the core/base system.

>The quest for a clean minimal system goes on ->. FreeBSD is not the
>answer. In fact I believe 4.3BSD-Reno and 4.4 go strongly offtrack.

I believe someone has ported 2.11BSD to the x86

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170208/55ad5618/attachment.sig>

[TUHS] How Unix brings people together, or it's a small

[ches@Cheswick.com]

These modern systems desperately need a Doug-like editor for their low-bit rate man pages.

Also, it would be nice to see people throwing away code, especially in the kernel.

And the netpbm library, which tried to follow the unix filter module, still has programs which write useless stuff to stderr.

ches

[TUHS] Fwd: Code bloat (was: How Unix brings people together, or it's a small...)

[Noel Chiappa]

    > From: Nick Downing

    > I'm much more of a V7 guy and I think I would find V6 strange and
    > compromised

De gustibus. I used it for many years, and am quite at home in it. I think
it's a marvel of functionality/size - at the time it came out, not much bigger
than DEC PDP-11 OS's, but with a 'big system' feel to it (which they
_definitely_ did not) - in fact, _better_ than most big systems of the day.

But I can see it would be rather too simple (and in the kernel inelegant,
code-wise, by today's standards - see below) for many. V7 is not that
different, in terms of user experience, from V6, though.


    > I am thinking I will definitely have to apply some of these patches, or
    > at least check how much they increase the code size by.

Sorry, that page is kind of a mish-mosh. Most of the stuff that's talked about
there is for user commands, not the kernel.

There are only a few kernel changes (lseek() and mdate(), and param.c so that
the new 'si' command can get thing from param.h without having to have it
compiled in), and they are all small.


    > But probably my preferred approach is to calculate a patch V6 -> Mini
    > Unix or V6 -> LSX and then try to apply that on top of V7.

I'm a little confused as to what your goal is here. Get V6 running on some
other architecture? Upgrade V6 for some goal which I am not aware of? I know
you probably said something in an earlier email, sorry, I don't recall.

Anyway, if you're going to do anything with V6 kernel code, you need to be
aware that it's really idiosyncratic - a lot of its written in a very early
dialect of C, and while things like 'a =+ b' -> 'a += b' and 'int a 1' -> 'int
a = 1' are pretty easy to fix, there are lots of intances of int's being used
as pointers to several different kinds of structures, etc, etc.

If you want to move an early, small Unix to something other than a PDP-11, V7
is probably a much better bet.


    > As to moving to a V7 kernel and then adding TCP/IP I'm not sure if this
    > is adviseable, as I was saying earlier I think it might be best to keep
    > that functionality outboard from the kernel.

There are a couple of early TCP/IP's which ran outside the kernel, but I think
the standard Berkeley one might be a handful to move out.  

	Noel

[TUHS] Fwd: Code bloat (was: How Unix brings people together, or it's a small...)

[Brantley Coile]

Regarding putting TCP/IP Into V7, I found it not that hard. First, it's not that hard to implement Dennis' streams in V7, and then, using the streams structure, do a straight forward TCP right from the pseudocode from the appendix of the RFC. I still have it around somewhere. 

If you're interested I can share it with you. 

  Brantley 

Sent from my iPad

On Feb 8, 2017, at 11:14 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:

>> From: Nick Downing
> 
>> I'm much more of a V7 guy and I think I would find V6 strange and
>> compromised
> 
> De gustibus. I used it for many years, and am quite at home in it. I think
> it's a marvel of functionality/size - at the time it came out, not much bigger
> than DEC PDP-11 OS's, but with a 'big system' feel to it (which they
> _definitely_ did not) - in fact, _better_ than most big systems of the day.
> 
> But I can see it would be rather too simple (and in the kernel inelegant,
> code-wise, by today's standards - see below) for many. V7 is not that
> different, in terms of user experience, from V6, though.
> 
> 
>> I am thinking I will definitely have to apply some of these patches, or
>> at least check how much they increase the code size by.
> 
> Sorry, that page is kind of a mish-mosh. Most of the stuff that's talked about
> there is for user commands, not the kernel.
> 
> There are only a few kernel changes (lseek() and mdate(), and param.c so that
> the new 'si' command can get thing from param.h without having to have it
> compiled in), and they are all small.
> 
> 
>> But probably my preferred approach is to calculate a patch V6 -> Mini
>> Unix or V6 -> LSX and then try to apply that on top of V7.
> 
> I'm a little confused as to what your goal is here. Get V6 running on some
> other architecture? Upgrade V6 for some goal which I am not aware of? I know
> you probably said something in an earlier email, sorry, I don't recall.
> 
> Anyway, if you're going to do anything with V6 kernel code, you need to be
> aware that it's really idiosyncratic - a lot of its written in a very early
> dialect of C, and while things like 'a =+ b' -> 'a += b' and 'int a 1' -> 'int
> a = 1' are pretty easy to fix, there are lots of intances of int's being used
> as pointers to several different kinds of structures, etc, etc.
> 
> If you want to move an early, small Unix to something other than a PDP-11, V7
> is probably a much better bet.
> 
> 
>> As to moving to a V7 kernel and then adding TCP/IP I'm not sure if this
>> is adviseable, as I was saying earlier I think it might be best to keep
>> that functionality outboard from the kernel.
> 
> There are a couple of early TCP/IP's which ran outside the kernel, but I think
> the standard Berkeley one might be a handful to move out.  
> 
>    Noel