Date: Wed, 7 Oct 1998 09:39:24 +0200 (CEST) From: Andrzej Bialecki <abial@nask.pl> To: Jeroen Ruigrok/Asmodai <asmodai@wxs.nl> Cc: FreeBSD Small <freebsd-small@FreeBSD.ORG> Subject: Re: picoBSD Goals Message-ID: <Pine.BSF.4.02A.9810070911330.13552-100000@korin.warman.org.pl> In-Reply-To: <Version.32.19981006233741.010123a0@pop.wxs.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 6 Oct 1998, Jeroen Ruigrok/Asmodai wrote: > Clear goals and ideas for picoBSD: > > 1) Small OS with emphasis on networking and all related to networking such > as routing, bridging & dial solutions, but not limited to those afore > mentioned topics. I understand "small" as "limited and predictable resource consumption". With this definition, a system which uses 40MB flash disk running on a 4MB SBC also fits within our interests... > 2) Use of the FreeBSD STABLE, RELEASE and CURRENT/BETA kernels for picoBSD > basis. Yes. BTW. If anyone wants to take care of producing -STABLE floppies, step up, please :-) - all machines within my reach are running -current... > 3) Addition of wide accepted routing protocols at first, maybe expanded > with lesser used protocols in traditional *NIX environments, IPX/SPX, XNS, > X.25 and what else spring to mind. Your point 2) contradicts with 3), unless you are willing to resurrect support for these protocols in the standard FreeBSD kernel... Do we have enough people to work exclusively on making a _PICO_ BSD specific kernel? I don't think so. Let's better stick with the standard /sys (providing necessary patches and features, of course). So, for the nearest future we'll stick with IP (perhaps IPX and ATM). > 4) Security is a prerequisite for configuration safeguarding. Wellll... yes (though I'm not sure I understand the above... :-) Let me rephrase it. 4) Security measures should be such that prevent unauthorized users to either change it's configuration and/or operation, or gain access to sensitive data (passwords, SNMP community strings etc..), while at the same time allowing for convenient access for authorized users. Well, but I'd say it's true in every situation, isn't it? Here's what I think should be added, and what's specific to our target "market": 4a) Use of widely accepted protocols for distributed authentication (such as Radius, Tacacs, Kerberos). > 5) Hierarchical grouping structure of command set that allows for clear > and useful configuration. Starting from toplevel generic classifications > down to very specific configurations. Also, command set versioning > independant from kernel versioning. > > E.g.: --- Dialing > | > --- User > | > --- Networking > | | > | --- IP > | | > | --- IPX > | > --- Miscellaneous > > (Note, above is a very rough idea of how it COULD be, this is going to be > one of the better discussions on the list which I foresee in near future ;) Yes, definitely. The above describes only how it could look from the user's perspective, and doesn't say anything about how to translate the UI commands to the actual configuration requests for the underlying subsystems. > 6) Webbased interface for configuration. In my opinion a nice addition to > the whole, except in my eyes not that high a priority at this moment, but > if/when we are going to start work on the command set we need to check the > usefulness on the webinterface too, although that might work totally > independant of the command set. Well, I think we can keep in mind that perhaps some day we will want to present the config data via WWW. But we need to resolve the more basic issues first... > 7) Deletion of many subdirectories and commands and a restructuring of the > remaining directories in order to create some order for the picoBSD kernel. s/kernel/userland/. With this change - yes. But it's natural consequence of different configuration scheme. > 8) Make online configuration easy to retrieve info from, not like IOS' > list of data, but instead grouped and formatted. > > 9) Decide on configuration file formats, filenames and directories. > > 10) Getting rid of *sh's and implement own UI/shell for configuration. I think 8 and 9 are just consequences of 10. Andrzej Bialecki -------------------- ++-------++ ------------------------------------- <abial@nask.pl> ||PicoBSD|| FreeBSD in your pocket? Go and see: Research & Academic |+-------+| "Small & Embedded FreeBSD" Network in Poland | |TT~~~| | http://www.freebsd.org/~picobsd/ -------------------- ~-+==---+-+ ------------------------------------- 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?Pine.BSF.4.02A.9810070911330.13552-100000>