Date: Thu, 11 Mar 2004 19:35:28 -0800 (PST) From: "Bruce R. Montague" <brucem@mail.cruzio.com> To: freebsd-small@freebsd.org Cc: current@freebsd.org Subject: Re: "nanobsd" prototype Message-ID: <200403120335.i2C3ZSFR000834@mail.cruzio.com>
next in thread | raw e-mail | index | archive | help
Regarding the remarks: Poul-Henning Kamp: > As I understand it picoBSD has never managed the 4.x->5.x transition... Luigi Rizzo: > what do you mean ? it builds happily last time i tried (sometime > in january) except for the usual bloat issues that the boot > floppies have too. Up until the last few months I routinely built picobsd under 5.x, PicoBSD seemed to work fine under 5.x for me. Things seemed pretty indistinguishably from building it under 4.x. You have to use your own configurations, which for many (most?) interesting projects you have to do anyway. I'll have to test it with the latest -current as soon as I have a chance... What DOESN'T work -- in the sense of not fitting on a floppy -- are the old "reference configurations" other than "release/picobsd/bridge" (and even there you may need to remove ssh, or build the picobsd-ssh port first). (I think "router" may work as well, it is important because it does not use "init). The core problem is the images are just too big to fit on floppy because the underlying FreeBSD system has grown. There's been size growth everywhere. I think, didn't the last version of DHCP not even fit on a floppy? The MII NIC driver stuff alone made the drivers questionably large, IIRC... splitfs will likely make a lot of this moot. However, it is nice to have everything fit on a floppy, because then you can run a ancient floppy PC as a cheap firewall and just leave the flopy in and it will automatically reboot unattended on power failure. However, you can build a picobsd system of any size and pxeboot it, or heck, just copy it to your "/" and boot it. Nice if your "/" is a small flash device. The old reference configurations that don't work for version 5.x also don't work for versions of 4.x past FreeBSD 4.4. I believe it was 4.4 when most of the ref configs ran out of space to fit on floppy. The most likely use of the configurations currently are as examples of what works and doesn't in syntax of crunch files, "floppy.tree.exclude" files, and the like. Given current directions with respect to small-sensor nets, embedded mobile devices, and flash-based systems, picobsd is a capability that FreeBSD should definitely retain. This doesn't mean it's not a very specific tool. Something like NanoBSD is definitely what's needed for folks that want to run Java off of Compact Flash (I was talking to one such just today...) and otherwise use FreeBSD in full. PicoBSD is still a good way to get a functioning TCP/IP stack off a very small boot device. And I have used the ability to conveniently e-mail entire PicoBSD systems as bootable e-mail attachments to folks across the country to debug (hardware) under hardware ICE machines. I had some students play with PicoBSD a few months ago, playing with small firewall configurations building on floppies under 4.8(?). You could tell it was one of the most exciting things they'd done on FreeBSD. Also, the picobsd rc scripts are very small and easy to customize. Much easier for an EE-type embedded engineer to understand and get into than full FreeBSD. An interesting place for some grad-student types to start. Also (it's not so pronounced in this day and age of loadable modules), the picobsd development cycle, if you are not using floppies (netbooting or using flash) can be very fast compared to working with FreeBSD. Having both picobsd and nanobsd, visibly used at different points in the low-end compact flash space, provide a viable FreeBSD rationale when in the Linux Embedded world.... so it would be nice if they were somehow rooted in the same place in src. BTW, I have consistently run into confusion about PicoBSD (and already about nanobsd) being an alternate "Distribution". To emphasize that they are alternate system build procedures and not distributions, I'd like to suggest revising an old name, and perhaps calling them "sysgen tools", or "sysgen scripts". But that's just one opinion and term, maybe something else would fit better. - bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200403120335.i2C3ZSFR000834>