* [TUHS] How Unix brings people together, or it's a small @ 2017-02-07 3:03 Doug McIlroy 2017-02-07 4:06 ` Marc Rochkind 0 siblings, 1 reply; 54+ messages in thread From: Doug McIlroy @ 2017-02-07 3:03 UTC (permalink / raw) > 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 ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] How Unix brings people together, or it's a small 2017-02-07 3:03 [TUHS] How Unix brings people together, or it's a small Doug McIlroy @ 2017-02-07 4:06 ` Marc Rochkind 2017-02-07 23:10 ` Clem Cole 0 siblings, 1 reply; 54+ messages in thread From: Marc Rochkind @ 2017-02-07 4:06 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] How Unix brings people together, or it's a small 2017-02-07 4:06 ` Marc Rochkind @ 2017-02-07 23:10 ` Clem Cole 2017-02-07 23:38 ` Steve Johnson 0 siblings, 1 reply; 54+ messages in thread From: Clem Cole @ 2017-02-07 23:10 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] How Unix brings people together, or it's a small 2017-02-07 23:10 ` Clem Cole @ 2017-02-07 23:38 ` Steve Johnson 2017-02-08 2:55 ` [TUHS] Code bloat (was: How Unix brings people together, or it's a small...) Greg 'groggy' Lehey 2017-02-08 12:16 ` [TUHS] How Unix brings people together, or it's a small ches@Cheswick.com 0 siblings, 2 replies; 54+ messages in thread From: Steve Johnson @ 2017-02-07 23:38 UTC (permalink / raw) [-- 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> ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] Code bloat (was: How Unix brings people together, or it's a small...) 2017-02-07 23:38 ` Steve Johnson @ 2017-02-08 2:55 ` Greg 'groggy' Lehey 2017-02-08 3:47 ` Nick Downing 2017-02-08 12:16 ` [TUHS] How Unix brings people together, or it's a small ches@Cheswick.com 1 sibling, 1 reply; 54+ messages in thread From: Greg 'groggy' Lehey @ 2017-02-08 2:55 UTC (permalink / raw) [-- 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> ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] Code bloat (was: How Unix brings people together, or it's a small...) 2017-02-08 2:55 ` [TUHS] Code bloat (was: How Unix brings people together, or it's a small...) Greg 'groggy' Lehey @ 2017-02-08 3:47 ` Nick Downing 2017-02-08 3:56 ` Jason Stevens 2017-02-08 5:37 ` Peter Jeremy 0 siblings, 2 replies; 54+ messages in thread From: Nick Downing @ 2017-02-08 3:47 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] Code bloat (was: How Unix brings people together, or it's a small...) 2017-02-08 3:47 ` Nick Downing @ 2017-02-08 3:56 ` Jason Stevens 2017-02-08 8:25 ` Wesley Parish 2017-02-08 11:21 ` Nick Downing 2017-02-08 5:37 ` Peter Jeremy 1 sibling, 2 replies; 54+ messages in thread From: Jason Stevens @ 2017-02-08 3:56 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] Code bloat (was: How Unix brings people together, or it's a small...) 2017-02-08 3:56 ` Jason Stevens @ 2017-02-08 8:25 ` Wesley Parish 2017-02-08 9:57 ` Steve Nickolas 2017-02-08 11:21 ` Nick Downing 1 sibling, 1 reply; 54+ messages in thread From: Wesley Parish @ 2017-02-08 8:25 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] Code bloat (was: How Unix brings people together, or it's a small...) 2017-02-08 8:25 ` Wesley Parish @ 2017-02-08 9:57 ` Steve Nickolas 0 siblings, 0 replies; 54+ messages in thread From: Steve Nickolas @ 2017-02-08 9:57 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] Code bloat (was: How Unix brings people together, or it's a small...) 2017-02-08 3:56 ` Jason Stevens 2017-02-08 8:25 ` Wesley Parish @ 2017-02-08 11:21 ` Nick Downing 2017-02-08 11:59 ` [TUHS] Code bloat (was: How Unix brings people together, or it'sa small...) jsteve ` (2 more replies) 1 sibling, 3 replies; 54+ messages in thread From: Nick Downing @ 2017-02-08 11:21 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] Code bloat (was: How Unix brings people together, or it'sa small...) 2017-02-08 11:21 ` Nick Downing @ 2017-02-08 11:59 ` jsteve 2017-02-08 12:24 ` Nick Downing 2017-02-08 12:29 ` [TUHS] Code bloat Jacob Goense 2017-02-08 13:56 ` [TUHS] Code bloat (was: How Unix brings people together, or it's a small...) Paul Ruizendaal 2 siblings, 1 reply; 54+ messages in thread From: jsteve @ 2017-02-08 11:59 UTC (permalink / raw) [-- 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> ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] Code bloat (was: How Unix brings people together, or it'sa small...) 2017-02-08 11:59 ` [TUHS] Code bloat (was: How Unix brings people together, or it'sa small...) jsteve @ 2017-02-08 12:24 ` Nick Downing 0 siblings, 0 replies; 54+ messages in thread From: Nick Downing @ 2017-02-08 12:24 UTC (permalink / raw) [-- 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. > > ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] Code bloat 2017-02-08 11:21 ` Nick Downing 2017-02-08 11:59 ` [TUHS] Code bloat (was: How Unix brings people together, or it'sa small...) jsteve @ 2017-02-08 12:29 ` Jacob Goense 2017-02-08 12:57 ` Nick Downing ` (2 more replies) 2017-02-08 13:56 ` [TUHS] Code bloat (was: How Unix brings people together, or it's a small...) Paul Ruizendaal 2 siblings, 3 replies; 54+ messages in thread From: Jacob Goense @ 2017-02-08 12:29 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] Code bloat 2017-02-08 12:29 ` [TUHS] Code bloat Jacob Goense @ 2017-02-08 12:57 ` Nick Downing 2017-02-08 13:10 ` jsteve 2017-02-08 16:25 ` Tony Finch 2 siblings, 0 replies; 54+ messages in thread From: Nick Downing @ 2017-02-08 12:57 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] Code bloat 2017-02-08 12:29 ` [TUHS] Code bloat Jacob Goense 2017-02-08 12:57 ` Nick Downing @ 2017-02-08 13:10 ` jsteve 2017-02-08 14:10 ` Jacob Goense 2017-02-08 16:25 ` Tony Finch 2 siblings, 1 reply; 54+ messages in thread From: jsteve @ 2017-02-08 13:10 UTC (permalink / raw) [-- 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> ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] Code bloat 2017-02-08 13:10 ` jsteve @ 2017-02-08 14:10 ` Jacob Goense 2017-02-08 14:34 ` Ron Natalie 2017-02-08 15:18 ` Jason Stevens 0 siblings, 2 replies; 54+ messages in thread From: Jacob Goense @ 2017-02-08 14:10 UTC (permalink / raw) [-- 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. ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] Code bloat 2017-02-08 14:10 ` Jacob Goense @ 2017-02-08 14:34 ` Ron Natalie 2017-02-08 14:43 ` Brantley Coile 2017-02-08 15:09 ` Dan Cross 2017-02-08 15:18 ` Jason Stevens 1 sibling, 2 replies; 54+ messages in thread From: Ron Natalie @ 2017-02-08 14:34 UTC (permalink / raw) Anybody have a copy of Rob Pike's "Cat -v considered harmful" paper? ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] Code bloat 2017-02-08 14:34 ` Ron Natalie @ 2017-02-08 14:43 ` Brantley Coile 2017-02-08 15:09 ` Dan Cross 1 sibling, 0 replies; 54+ messages in thread From: Brantley Coile @ 2017-02-08 14:43 UTC (permalink / raw) 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? > > ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] Code bloat 2017-02-08 14:34 ` Ron Natalie 2017-02-08 14:43 ` Brantley Coile @ 2017-02-08 15:09 ` Dan Cross 2017-02-08 15:26 ` Nick Downing 1 sibling, 1 reply; 54+ messages in thread From: Dan Cross @ 2017-02-08 15:09 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] Code bloat 2017-02-08 15:09 ` Dan Cross @ 2017-02-08 15:26 ` Nick Downing 0 siblings, 0 replies; 54+ messages in thread From: Nick Downing @ 2017-02-08 15:26 UTC (permalink / raw) 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? >> >> > ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] Code bloat 2017-02-08 14:10 ` Jacob Goense 2017-02-08 14:34 ` Ron Natalie @ 2017-02-08 15:18 ` Jason Stevens 1 sibling, 0 replies; 54+ messages in thread From: Jason Stevens @ 2017-02-08 15:18 UTC (permalink / raw) [-- 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> ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] Code bloat 2017-02-08 12:29 ` [TUHS] Code bloat Jacob Goense 2017-02-08 12:57 ` Nick Downing 2017-02-08 13:10 ` jsteve @ 2017-02-08 16:25 ` Tony Finch 2017-02-09 14:03 ` Jacob Goense 2 siblings, 1 reply; 54+ messages in thread From: Tony Finch @ 2017-02-08 16:25 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] Code bloat 2017-02-08 16:25 ` Tony Finch @ 2017-02-09 14:03 ` Jacob Goense 2017-02-09 14:41 ` jsteve 2017-02-09 15:30 ` Tony Finch 0 siblings, 2 replies; 54+ messages in thread From: Jacob Goense @ 2017-02-09 14:03 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] Code bloat 2017-02-09 14:03 ` Jacob Goense @ 2017-02-09 14:41 ` jsteve 2017-02-09 15:03 ` Jacob Goense 2017-02-09 15:30 ` Tony Finch 1 sibling, 1 reply; 54+ messages in thread From: jsteve @ 2017-02-09 14:41 UTC (permalink / raw) [-- 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> ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] Code bloat 2017-02-09 14:41 ` jsteve @ 2017-02-09 15:03 ` Jacob Goense 2017-02-09 15:08 ` Jason Stevens 0 siblings, 1 reply; 54+ messages in thread From: Jacob Goense @ 2017-02-09 15:03 UTC (permalink / raw) [-- 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. ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] Code bloat 2017-02-09 15:03 ` Jacob Goense @ 2017-02-09 15:08 ` Jason Stevens 0 siblings, 0 replies; 54+ messages in thread From: Jason Stevens @ 2017-02-09 15:08 UTC (permalink / raw) [-- 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> ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] Code bloat 2017-02-09 14:03 ` Jacob Goense 2017-02-09 14:41 ` jsteve @ 2017-02-09 15:30 ` Tony Finch 2017-02-09 16:14 ` Warner Losh 1 sibling, 1 reply; 54+ messages in thread From: Tony Finch @ 2017-02-09 15:30 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] Code bloat 2017-02-09 15:30 ` Tony Finch @ 2017-02-09 16:14 ` Warner Losh 2017-02-09 23:38 ` [TUHS] Free/NetBSD revision history (was Code bloat) Jacob Goense 0 siblings, 1 reply; 54+ messages in thread From: Warner Losh @ 2017-02-09 16:14 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] Free/NetBSD revision history (was Code bloat) 2017-02-09 16:14 ` Warner Losh @ 2017-02-09 23:38 ` Jacob Goense 2017-02-10 4:11 ` Warner Losh 2017-02-10 4:17 ` Warner Losh 0 siblings, 2 replies; 54+ messages in thread From: Jacob Goense @ 2017-02-09 23:38 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] Free/NetBSD revision history (was Code bloat) 2017-02-09 23:38 ` [TUHS] Free/NetBSD revision history (was Code bloat) Jacob Goense @ 2017-02-10 4:11 ` Warner Losh 2017-02-10 4:17 ` Warner Losh 1 sibling, 0 replies; 54+ messages in thread From: Warner Losh @ 2017-02-10 4:11 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] Free/NetBSD revision history (was Code bloat) 2017-02-09 23:38 ` [TUHS] Free/NetBSD revision history (was Code bloat) Jacob Goense 2017-02-10 4:11 ` Warner Losh @ 2017-02-10 4:17 ` Warner Losh 1 sibling, 0 replies; 54+ messages in thread From: Warner Losh @ 2017-02-10 4:17 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] Code bloat (was: How Unix brings people together, or it's a small...) 2017-02-08 11:21 ` Nick Downing 2017-02-08 11:59 ` [TUHS] Code bloat (was: How Unix brings people together, or it'sa small...) jsteve 2017-02-08 12:29 ` [TUHS] Code bloat Jacob Goense @ 2017-02-08 13:56 ` Paul Ruizendaal [not found] ` <CAH1jEzZqRPYenwzBbUwFVanA-NVvWMGzYiADVoAXCDOqnUrMrg@mail.gmail.com> 2 siblings, 1 reply; 54+ messages in thread From: Paul Ruizendaal @ 2017-02-08 13:56 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 54+ messages in thread
[parent not found: <CAH1jEzZqRPYenwzBbUwFVanA-NVvWMGzYiADVoAXCDOqnUrMrg@mail.gmail.com>]
* [TUHS] Fwd: Code bloat (was: How Unix brings people together, or it's a small...) [not found] ` <CAH1jEzZqRPYenwzBbUwFVanA-NVvWMGzYiADVoAXCDOqnUrMrg@mail.gmail.com> @ 2017-02-09 3:02 ` Nick Downing 2017-02-09 9:19 ` [TUHS] " Paul Ruizendaal 0 siblings, 1 reply; 54+ messages in thread From: Nick Downing @ 2017-02-09 3:02 UTC (permalink / raw) 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. > ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] Code bloat (was: How Unix brings people together, or it's a small...) 2017-02-09 3:02 ` [TUHS] Fwd: " Nick Downing @ 2017-02-09 9:19 ` Paul Ruizendaal 2017-02-09 9:58 ` Michael Kjörling ` (2 more replies) 0 siblings, 3 replies; 54+ messages in thread From: Paul Ruizendaal @ 2017-02-09 9:19 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] Code bloat (was: How Unix brings people together, or it's a small...) 2017-02-09 9:19 ` [TUHS] " Paul Ruizendaal @ 2017-02-09 9:58 ` Michael Kjörling 2017-02-09 10:08 ` Paul Ruizendaal 2017-02-09 16:36 ` Larry McVoy 2017-02-09 19:50 ` [TUHS] Code bloat (was: How Unix brings people together, or it's a small...) Clem Cole 2 siblings, 1 reply; 54+ messages in thread From: Michael Kjörling @ 2017-02-09 9:58 UTC (permalink / raw) [-- 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) ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] Code bloat (was: How Unix brings people together, or it's a small...) 2017-02-09 9:58 ` Michael Kjörling @ 2017-02-09 10:08 ` Paul Ruizendaal 0 siblings, 0 replies; 54+ messages in thread From: Paul Ruizendaal @ 2017-02-09 10:08 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] Code bloat (was: How Unix brings people together, or it's a small...) 2017-02-09 9:19 ` [TUHS] " Paul Ruizendaal 2017-02-09 9:58 ` Michael Kjörling @ 2017-02-09 16:36 ` Larry McVoy 2017-02-09 16:42 ` Warner Losh 2017-02-09 16:58 ` [TUHS] Code bloat William Pechter 2017-02-09 19:50 ` [TUHS] Code bloat (was: How Unix brings people together, or it's a small...) Clem Cole 2 siblings, 2 replies; 54+ messages in thread From: Larry McVoy @ 2017-02-09 16:36 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] Code bloat (was: How Unix brings people together, or it's a small...) 2017-02-09 16:36 ` Larry McVoy @ 2017-02-09 16:42 ` Warner Losh 2017-02-09 16:49 ` Larry McVoy 2017-02-09 16:58 ` [TUHS] Code bloat William Pechter 1 sibling, 1 reply; 54+ messages in thread From: Warner Losh @ 2017-02-09 16:42 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] Code bloat (was: How Unix brings people together, or it's a small...) 2017-02-09 16:42 ` Warner Losh @ 2017-02-09 16:49 ` Larry McVoy 2017-02-09 17:24 ` Steffen Nurpmeso ` (2 more replies) 0 siblings, 3 replies; 54+ messages in thread From: Larry McVoy @ 2017-02-09 16:49 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] Code bloat (was: How Unix brings people together, or it's a small...) 2017-02-09 16:49 ` Larry McVoy @ 2017-02-09 17:24 ` Steffen Nurpmeso 2017-02-09 17:27 ` [TUHS] offtopic: broadband (redirect from bloat) Larry McVoy 2017-02-09 19:54 ` [TUHS] Code bloat (was: How Unix brings people together, Corey Lindsly 2017-02-09 21:02 ` [TUHS] Code bloat (was: How Unix brings people together, or it's a small...) Joerg Schilling 2 siblings, 1 reply; 54+ messages in thread From: Steffen Nurpmeso @ 2017-02-09 17:24 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] offtopic: broadband (redirect from bloat) 2017-02-09 17:24 ` Steffen Nurpmeso @ 2017-02-09 17:27 ` Larry McVoy 2017-02-09 19:05 ` Steffen Nurpmeso 2017-02-09 22:48 ` Joerg Schilling 0 siblings, 2 replies; 54+ messages in thread From: Larry McVoy @ 2017-02-09 17:27 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] offtopic: broadband (redirect from bloat) 2017-02-09 17:27 ` [TUHS] offtopic: broadband (redirect from bloat) Larry McVoy @ 2017-02-09 19:05 ` Steffen Nurpmeso 2017-02-09 22:48 ` Joerg Schilling 1 sibling, 0 replies; 54+ messages in thread From: Steffen Nurpmeso @ 2017-02-09 19:05 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] offtopic: broadband (redirect from bloat) 2017-02-09 17:27 ` [TUHS] offtopic: broadband (redirect from bloat) Larry McVoy 2017-02-09 19:05 ` Steffen Nurpmeso @ 2017-02-09 22:48 ` Joerg Schilling 1 sibling, 0 replies; 54+ messages in thread From: Joerg Schilling @ 2017-02-09 22:48 UTC (permalink / raw) [-- 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/ ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] Code bloat (was: How Unix brings people together, 2017-02-09 16:49 ` Larry McVoy 2017-02-09 17:24 ` Steffen Nurpmeso @ 2017-02-09 19:54 ` Corey Lindsly 2017-02-09 20:08 ` pechter ` (2 more replies) 2017-02-09 21:02 ` [TUHS] Code bloat (was: How Unix brings people together, or it's a small...) Joerg Schilling 2 siblings, 3 replies; 54+ messages in thread From: Corey Lindsly @ 2017-02-09 19:54 UTC (permalink / raw) > 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 ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] Code bloat (was: How Unix brings people together, 2017-02-09 19:54 ` [TUHS] Code bloat (was: How Unix brings people together, Corey Lindsly @ 2017-02-09 20:08 ` pechter 2017-02-09 20:30 ` Arthur Krewat 2017-02-09 21:06 ` Larry McVoy 2 siblings, 0 replies; 54+ messages in thread From: pechter @ 2017-02-09 20:08 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] Code bloat (was: How Unix brings people together, 2017-02-09 19:54 ` [TUHS] Code bloat (was: How Unix brings people together, Corey Lindsly 2017-02-09 20:08 ` pechter @ 2017-02-09 20:30 ` Arthur Krewat 2017-02-09 23:47 ` Jacob Goense 2017-02-09 21:06 ` Larry McVoy 2 siblings, 1 reply; 54+ messages in thread From: Arthur Krewat @ 2017-02-09 20:30 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] Code bloat (was: How Unix brings people together, 2017-02-09 20:30 ` Arthur Krewat @ 2017-02-09 23:47 ` Jacob Goense 0 siblings, 0 replies; 54+ messages in thread From: Jacob Goense @ 2017-02-09 23:47 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] Code bloat (was: How Unix brings people together, 2017-02-09 19:54 ` [TUHS] Code bloat (was: How Unix brings people together, Corey Lindsly 2017-02-09 20:08 ` pechter 2017-02-09 20:30 ` Arthur Krewat @ 2017-02-09 21:06 ` Larry McVoy 2 siblings, 0 replies; 54+ messages in thread From: Larry McVoy @ 2017-02-09 21:06 UTC (permalink / raw) > 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 ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] Code bloat (was: How Unix brings people together, or it's a small...) 2017-02-09 16:49 ` Larry McVoy 2017-02-09 17:24 ` Steffen Nurpmeso 2017-02-09 19:54 ` [TUHS] Code bloat (was: How Unix brings people together, Corey Lindsly @ 2017-02-09 21:02 ` Joerg Schilling 2 siblings, 0 replies; 54+ messages in thread From: Joerg Schilling @ 2017-02-09 21:02 UTC (permalink / raw) [-- 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/ ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] Code bloat 2017-02-09 16:36 ` Larry McVoy 2017-02-09 16:42 ` Warner Losh @ 2017-02-09 16:58 ` William Pechter 1 sibling, 0 replies; 54+ messages in thread From: William Pechter @ 2017-02-09 16:58 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] Code bloat (was: How Unix brings people together, or it's a small...) 2017-02-09 9:19 ` [TUHS] " Paul Ruizendaal 2017-02-09 9:58 ` Michael Kjörling 2017-02-09 16:36 ` Larry McVoy @ 2017-02-09 19:50 ` Clem Cole 2 siblings, 0 replies; 54+ messages in thread From: Clem Cole @ 2017-02-09 19:50 UTC (permalink / raw) [-- 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> ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] Code bloat (was: How Unix brings people together, or it's a small...) 2017-02-08 3:47 ` Nick Downing 2017-02-08 3:56 ` Jason Stevens @ 2017-02-08 5:37 ` Peter Jeremy 1 sibling, 0 replies; 54+ messages in thread From: Peter Jeremy @ 2017-02-08 5:37 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] How Unix brings people together, or it's a small 2017-02-07 23:38 ` Steve Johnson 2017-02-08 2:55 ` [TUHS] Code bloat (was: How Unix brings people together, or it's a small...) Greg 'groggy' Lehey @ 2017-02-08 12:16 ` ches@Cheswick.com 1 sibling, 0 replies; 54+ messages in thread From: ches@Cheswick.com @ 2017-02-08 12:16 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 54+ messages in thread
* [TUHS] Code bloat (was: How Unix brings people together, or it's a small...) @ 2017-02-09 14:31 Noel Chiappa 0 siblings, 0 replies; 54+ messages in thread From: Noel Chiappa @ 2017-02-09 14:31 UTC (permalink / raw) > 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 ^ permalink raw reply [flat|nested] 54+ messages in thread
end of thread, other threads:[~2017-02-10 4:17 UTC | newest] Thread overview: 54+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-02-07 3:03 [TUHS] How Unix brings people together, or it's a small Doug McIlroy 2017-02-07 4:06 ` Marc Rochkind 2017-02-07 23:10 ` Clem Cole 2017-02-07 23:38 ` Steve Johnson 2017-02-08 2:55 ` [TUHS] Code bloat (was: How Unix brings people together, or it's a small...) Greg 'groggy' Lehey 2017-02-08 3:47 ` Nick Downing 2017-02-08 3:56 ` Jason Stevens 2017-02-08 8:25 ` Wesley Parish 2017-02-08 9:57 ` Steve Nickolas 2017-02-08 11:21 ` Nick Downing 2017-02-08 11:59 ` [TUHS] Code bloat (was: How Unix brings people together, or it'sa small...) jsteve 2017-02-08 12:24 ` Nick Downing 2017-02-08 12:29 ` [TUHS] Code bloat Jacob Goense 2017-02-08 12:57 ` Nick Downing 2017-02-08 13:10 ` jsteve 2017-02-08 14:10 ` Jacob Goense 2017-02-08 14:34 ` Ron Natalie 2017-02-08 14:43 ` Brantley Coile 2017-02-08 15:09 ` Dan Cross 2017-02-08 15:26 ` Nick Downing 2017-02-08 15:18 ` Jason Stevens 2017-02-08 16:25 ` Tony Finch 2017-02-09 14:03 ` Jacob Goense 2017-02-09 14:41 ` jsteve 2017-02-09 15:03 ` Jacob Goense 2017-02-09 15:08 ` Jason Stevens 2017-02-09 15:30 ` Tony Finch 2017-02-09 16:14 ` Warner Losh 2017-02-09 23:38 ` [TUHS] Free/NetBSD revision history (was Code bloat) Jacob Goense 2017-02-10 4:11 ` Warner Losh 2017-02-10 4:17 ` Warner Losh 2017-02-08 13:56 ` [TUHS] Code bloat (was: How Unix brings people together, or it's a small...) Paul Ruizendaal [not found] ` <CAH1jEzZqRPYenwzBbUwFVanA-NVvWMGzYiADVoAXCDOqnUrMrg@mail.gmail.com> 2017-02-09 3:02 ` [TUHS] Fwd: " Nick Downing 2017-02-09 9:19 ` [TUHS] " Paul Ruizendaal 2017-02-09 9:58 ` Michael Kjörling 2017-02-09 10:08 ` Paul Ruizendaal 2017-02-09 16:36 ` Larry McVoy 2017-02-09 16:42 ` Warner Losh 2017-02-09 16:49 ` Larry McVoy 2017-02-09 17:24 ` Steffen Nurpmeso 2017-02-09 17:27 ` [TUHS] offtopic: broadband (redirect from bloat) Larry McVoy 2017-02-09 19:05 ` Steffen Nurpmeso 2017-02-09 22:48 ` Joerg Schilling 2017-02-09 19:54 ` [TUHS] Code bloat (was: How Unix brings people together, Corey Lindsly 2017-02-09 20:08 ` pechter 2017-02-09 20:30 ` Arthur Krewat 2017-02-09 23:47 ` Jacob Goense 2017-02-09 21:06 ` Larry McVoy 2017-02-09 21:02 ` [TUHS] Code bloat (was: How Unix brings people together, or it's a small...) Joerg Schilling 2017-02-09 16:58 ` [TUHS] Code bloat William Pechter 2017-02-09 19:50 ` [TUHS] Code bloat (was: How Unix brings people together, or it's a small...) Clem Cole 2017-02-08 5:37 ` Peter Jeremy 2017-02-08 12:16 ` [TUHS] How Unix brings people together, or it's a small ches@Cheswick.com 2017-02-09 14:31 [TUHS] Code bloat (was: How Unix brings people together, or it's a small...) Noel Chiappa
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).