Date: Wed, 07 Oct 1998 22:24:38 +0200 From: Jeroen Ruigrok/Asmodai <asmodai@wxs.nl> To: Andrzej Bialecki <abial@nask.pl> Cc: FreeBSD Small <freebsd-small@FreeBSD.ORG> Subject: Re: picoBSD Goals Message-ID: <771898F08C1.AAB41E8@smtp04.wxs.nl> In-Reply-To: <Pine.BSF.4.02A.9810070911330.13552-100000@korin.warman.org .pl> References: <Version.32.19981006233741.010123a0@pop.wxs.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
At 09:39 07-10-98 , Andrzej Bialecki wrote:
>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...
My idea of small is as in small memory footprint, small code yer powerful
and strong.
>> 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...
Lemme finish up my other partition for STABLE then... Then I can work on
both CURRENT as well as STABLE (2.2.7 declared STABLE yet?)
>> 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...
I already raised my voice for that on the Networking list. Except it's hard
to get documentation about XNS and X.25 without paying, any pointers are
welcome, or at least where I can order them.
IPX/SPX is still widely used...
>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).
Dunno, do we? Could we open a seperate CVS directory in which we could put
stripped down versions of the /sys-sources? Just a suggestion...
>So, for the nearest future we'll stick with IP (perhaps IPX and ATM).
IP sounds good =)
> > 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.
That's what I said ;)
>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":
Aye, but often the most obvious things that stare us in the face are
forgotten...
>4a) Use of widely accepted protocols for distributed authentication (such
>as Radius, Tacacs, Kerberos).
Yeah been scoping up some docs about them. Got any more reference URL's? I
have two RFCs about TACACS, plus a draft from Cisco about XTACACS. Also
isn't Kerberos resticted? Radius? Know the name, there ends my
understanding =)
>> 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
>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.
Indeed, it's just a global cut. As far as I see it, certain commands alter
certain files for the reasons I stated in another mail (too long a config
file/one command needs to rewrite the whole file)
[reply to point 6, WWW interface]
>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...
My idea exactly.
>> 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.
Offcourse, yet again, the obvious might have to be restated for all to know
the how and what.
>> 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.
Aye, I realized that as I wrote it, but I felt the need to split them up so
they wouldn't be too crowded...
Btw, if people want me to, I could write a text file that carries these
point and to which we could draft other ideas/goals as to make it publicaly
available to allow 'outsiders' to see what we are up to, apart from our
secret missions offcourse ;) Imagine the Linux people getting air of the
revolution we are planning *G* =)
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 ||==\
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?771898F08C1.AAB41E8>