Lots of commands are now little shells

Linux today is much more like the systems Unix displaced than it is like Unix

On Tuesday, 7 February 2017 at 15:38:40 -0800, Steve Johnson wrote: 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(a)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

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.

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(a)gmail.com> wrote: -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

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 &lt;jsteve(a)superglobalmegacorp.com&gt; wrote: > > > > > > >> On Wed, Feb 8, 2017 at 1:55 PM, Greg 'groggy' Lehey &lt;grog(a)lemis.com >> >>> >> >> >>

On 2017-02-08 12:21, Nick Downing wrote: 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.

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.

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.

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

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 &lt;ron(a)ronnatalie.com&gt; 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 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/f131f027b47937d651804c243cde86ec0…

On 2017-02-09 15:41, jsteve(a)superglobalmegacorp.com wrote: Looking at FreeBSD here.

Jacob Goense &lt;dugo(a)xs4all.nl&gt; wrote: 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. 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 &lt;dot(a)dotat.at&gt; 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.

On 2017-02-09 11:14, Warner Losh wrote: 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.

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 &lt;jsteve(a)superglobalmegacorp.com&gt; 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 > &lt;downing.nick(a)gmail.com&gt; 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 &lt;grog(a)lemis.com&gt; >> 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(a)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.