* [TUHS] Fwd: Code bloat (was: How Unix brings people together, or it's a small...) @ 2017-02-09 4:14 Noel Chiappa 2017-02-09 9:36 ` Brantley Coile 0 siblings, 1 reply; 3+ messages in thread From: Noel Chiappa @ 2017-02-09 4:14 UTC (permalink / raw) > From: Nick Downing > I'm much more of a V7 guy and I think I would find V6 strange and > compromised De gustibus. I used it for many years, and am quite at home in it. I think it's a marvel of functionality/size - at the time it came out, not much bigger than DEC PDP-11 OS's, but with a 'big system' feel to it (which they _definitely_ did not) - in fact, _better_ than most big systems of the day. But I can see it would be rather too simple (and in the kernel inelegant, code-wise, by today's standards - see below) for many. V7 is not that different, in terms of user experience, from V6, though. > I am thinking I will definitely have to apply some of these patches, or > at least check how much they increase the code size by. Sorry, that page is kind of a mish-mosh. Most of the stuff that's talked about there is for user commands, not the kernel. There are only a few kernel changes (lseek() and mdate(), and param.c so that the new 'si' command can get thing from param.h without having to have it compiled in), and they are all small. > But probably my preferred approach is to calculate a patch V6 -> Mini > Unix or V6 -> LSX and then try to apply that on top of V7. I'm a little confused as to what your goal is here. Get V6 running on some other architecture? Upgrade V6 for some goal which I am not aware of? I know you probably said something in an earlier email, sorry, I don't recall. Anyway, if you're going to do anything with V6 kernel code, you need to be aware that it's really idiosyncratic - a lot of its written in a very early dialect of C, and while things like 'a =+ b' -> 'a += b' and 'int a 1' -> 'int a = 1' are pretty easy to fix, there are lots of intances of int's being used as pointers to several different kinds of structures, etc, etc. If you want to move an early, small Unix to something other than a PDP-11, V7 is probably a much better bet. > As to moving to a V7 kernel and then adding TCP/IP I'm not sure if this > is adviseable, as I was saying earlier I think it might be best to keep > that functionality outboard from the kernel. There are a couple of early TCP/IP's which ran outside the kernel, but I think the standard Berkeley one might be a handful to move out. Noel ^ permalink raw reply [flat|nested] 3+ messages in thread
* [TUHS] Fwd: Code bloat (was: How Unix brings people together, or it's a small...) 2017-02-09 4:14 [TUHS] Fwd: Code bloat (was: How Unix brings people together, or it's a small...) Noel Chiappa @ 2017-02-09 9:36 ` Brantley Coile 0 siblings, 0 replies; 3+ messages in thread From: Brantley Coile @ 2017-02-09 9:36 UTC (permalink / raw) Regarding putting TCP/IP Into V7, I found it not that hard. First, it's not that hard to implement Dennis' streams in V7, and then, using the streams structure, do a straight forward TCP right from the pseudocode from the appendix of the RFC. I still have it around somewhere. If you're interested I can share it with you. Brantley Sent from my iPad On Feb 8, 2017, at 11:14 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote: >> From: Nick Downing > >> I'm much more of a V7 guy and I think I would find V6 strange and >> compromised > > De gustibus. I used it for many years, and am quite at home in it. I think > it's a marvel of functionality/size - at the time it came out, not much bigger > than DEC PDP-11 OS's, but with a 'big system' feel to it (which they > _definitely_ did not) - in fact, _better_ than most big systems of the day. > > But I can see it would be rather too simple (and in the kernel inelegant, > code-wise, by today's standards - see below) for many. V7 is not that > different, in terms of user experience, from V6, though. > > >> I am thinking I will definitely have to apply some of these patches, or >> at least check how much they increase the code size by. > > Sorry, that page is kind of a mish-mosh. Most of the stuff that's talked about > there is for user commands, not the kernel. > > There are only a few kernel changes (lseek() and mdate(), and param.c so that > the new 'si' command can get thing from param.h without having to have it > compiled in), and they are all small. > > >> But probably my preferred approach is to calculate a patch V6 -> Mini >> Unix or V6 -> LSX and then try to apply that on top of V7. > > I'm a little confused as to what your goal is here. Get V6 running on some > other architecture? Upgrade V6 for some goal which I am not aware of? I know > you probably said something in an earlier email, sorry, I don't recall. > > Anyway, if you're going to do anything with V6 kernel code, you need to be > aware that it's really idiosyncratic - a lot of its written in a very early > dialect of C, and while things like 'a =+ b' -> 'a += b' and 'int a 1' -> 'int > a = 1' are pretty easy to fix, there are lots of intances of int's being used > as pointers to several different kinds of structures, etc, etc. > > If you want to move an early, small Unix to something other than a PDP-11, V7 > is probably a much better bet. > > >> As to moving to a V7 kernel and then adding TCP/IP I'm not sure if this >> is adviseable, as I was saying earlier I think it might be best to keep >> that functionality outboard from the kernel. > > There are a couple of early TCP/IP's which ran outside the kernel, but I think > the standard Berkeley one might be a handful to move out. > > Noel ^ permalink raw reply [flat|nested] 3+ 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
0 siblings, 1 reply; 3+ 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] 3+ messages in thread
* [TUHS] How Unix brings people together, or it's a small 2017-02-07 23:10 [TUHS] How Unix brings people together, or it's a small 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 0 siblings, 1 reply; 3+ 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] 3+ 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 0 siblings, 1 reply; 3+ 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] 3+ 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 0 siblings, 1 reply; 3+ 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] 3+ 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 11:21 ` Nick Downing 0 siblings, 1 reply; 3+ 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] 3+ 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 11:21 ` Nick Downing 2017-02-08 13:56 ` Paul Ruizendaal 0 siblings, 1 reply; 3+ 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] 3+ 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 13:56 ` Paul Ruizendaal [not found] ` <CAH1jEzZqRPYenwzBbUwFVanA-NVvWMGzYiADVoAXCDOqnUrMrg@mail.gmail.com> 0 siblings, 1 reply; 3+ 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] 3+ 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 0 siblings, 0 replies; 3+ 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] 3+ messages in thread
end of thread, other threads:[~2017-02-09 9:36 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-02-09 4:14 [TUHS] Fwd: Code bloat (was: How Unix brings people together, or it's a small...) Noel Chiappa 2017-02-09 9:36 ` Brantley Coile -- strict thread matches above, loose matches on Subject: below -- 2017-02-07 23:10 [TUHS] How Unix brings people together, or it's a small 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 11:21 ` Nick Downing 2017-02-08 13:56 ` Paul Ruizendaal [not found] ` <CAH1jEzZqRPYenwzBbUwFVanA-NVvWMGzYiADVoAXCDOqnUrMrg@mail.gmail.com> 2017-02-09 3:02 ` [TUHS] Fwd: " Nick Downing
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).