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

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

[Noel Chiappa]

    > From: Paul Ruizendaal

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

I've gotta get the MIT V6 one online.

Incoming demux is in the kernel; all of the TCP, and everything else, is in
processes along with the application - one process per application instance.
It sounds like it might be clunky, but it's not: there are a couple of
different TCP's (a small, low performance one for things like User TELNET,
timer servers, yadda-yadda; a bigger, higher-performance one for things like
FTP), and the application just calls them as subroutine libraries
(effectively). Since there's no IPC overhead, the performance is pretty good.

Unfortumately, a lot of the stuff never migrated from personal directories to
the system folder, so I have to go curate out the personal files (or, more
likely, move them all to a system folder) before I can release it all.


    > Perhaps economizing on fragmentation and and window management is
    > better.

Fragmentation, perhaps - but good window management is a must.

    > 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 don't think that's a good idea; cutting the TCP in two parts, which have to
communicate over an interface is going to be _really_ ugly: do you have one
copy of the connection state data (in which case one them has to go through an
interface to get to it), or two (synchronization issues). If you want a small
kernel footprint, take the MIT approach.

       Noel

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

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

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

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

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

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

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

[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] 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'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...)

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

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

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

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