Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 07 Oct 1998 00:15:24 +0200
From:      Jeroen Ruigrok/Asmodai <asmodai@wxs.nl>
To:        Andrzej Bialecki <abial@nask.pl>, Peter Wallace <pcw@mesanet.com>
Cc:        freebsd-small@FreeBSD.ORG
Subject:   Re: Command-line i/f (Re: PicoBSD) 
Message-ID:  <Version.32.19981007000952.010412c0@pop.wxs.nl>
In-Reply-To: <Pine.BSF.4.02A.9810061243090.3751-100000@korin.warman.org. pl>
References:  <Pine.BSF.3.96.981005164517.7183A-100000@freeby.mesanet.com>

next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

At 14:19 06-10-98 , Andrzej Bialecki wrote:
>On Mon, 5 Oct 1998, Peter Wallace wrote:
>> On Mon, 5 Oct 1998, Mike Smith wrote:
>> 
>> > > 	Whats the big deal about cramming this onto a single floppy...
>> > > Wouldn't a real embedded FreeBSD application use a small flash
drive? The
>> > > smallest chips that we use now are 4 M Bytes and about $12.00, cheaper
>> > > than a floppy drive! 
>> > 
>> > Lots of "embedded" stuff involves an ordinary PC bolted to the inside 
>> > of a big wooden box or similar.
>> 
>> 	But I think lots _more_ embedded stuff will be:  higher reliability
>> / wider ambient temperature range / smaller size / and lower cost than can
>> be achieved with a floppy for boot device...
>
>You're of course right. The truly embedded solution would be to use an SBC
>with DiskOnChip and no moving parts. But that's much more expensive...
>
>> 	I guess it depends on what the imagined target for PicoBSD is.
>
>OTOH, there are many people who want to use their spare, old PCs as a
>turnkey networking device. For them, ability to boot the system from such
>inferior (but standard) device as floppy is very important. So is for me -
>and as long as this is possible (without twisting our brains in knots :-)
>I'd like to keep the size of picobsd below 1.44MB.

Aye, isn't there a mechanism that allows us to boot from one disk and then
work on the second one? Caching everything we need from disk #1 into memory
and then load the actual UI from the second disk. This solution is based on
the fact that we might end up with a kickass picoBSD that beats IOS and
SpiderSoftware's router software, but requires two disks for all the stuff
*dreaming now* =)

Another advantage this set-up might have is that the config files are safe
on disk #2 and might be easily upgraded by the new software on disk#1
should it become available.

>Of course, this is also a matter of how flexible is the building
>procedure, so that you could easily change the size parameters if you have
>enough space on the target media. I'd say it's pretty easy even with
>current building process. It can be improved, of course... patches are
>welcome :-)

Well, one thing me could add (didn't see it in the current version) is a
sort of script that takes advantage of the local HD (if it is there) and
prepares a native FreeBSD slice to be used by the system...

As always, reactions please =)

Jeroen Ruigrok van der Werven / Asmodai <asmodai(at)wxs.nl>
ICQ-UIN: 1564317 .:. Ninth Circle Enterprises
Network/Security Specialist
    /==|| FreeBSD and picoBSD, the Power to Serve ||==\

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.0 for non-commercial use <http://www.pgp.com>;

iQA/AwUBNhqIbYY752GnxADpEQL0/wCgsUOdtJhezHCNkmhkXVa4BmReE0sAn04x
Vd01Uf0BQ3RdK6plRnWddkQA
=1fHr
-----END PGP SIGNATURE-----


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-small" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Version.32.19981007000952.010412c0>