Date: Sat, 22 Jan 2000 14:55:38 +0800 From: Greg Lehey <grog@lemis.com> To: Albert Yang <albert@achtung.com> Cc: small@FreeBSD.ORG Subject: Re: New approach to picobsd Message-ID: <20000122145538.A390@mojave.worldwide.lemis.com> In-Reply-To: <3888D5CF.329989@achtung.com>; from albert@achtung.com on Fri, Jan 21, 2000 at 01:55:27PM -0800 References: <3888D5CF.329989@achtung.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, 21 January 2000 at 13:55:27 -0800, Albert Yang wrote: > Hey there fellow Picobsd'ers! > > I like the fact that I'm seeing development on picobsd again. I know, > we all have that things called "a job" that takes up most of our time, > but I think we can keep picobsd alive. > > My suggestion though was that there is currently no clear outline > (as far as I can tell) of the structure and development of picobsd. > What I mean is, actually making this into a well defined project > instead of a loosely held patch kit. There's a good reason for this. I'll discuss further down. > The thing I was thinking about most, was defining what "flavors" of > picobsd should have what functionality. Documentation is sparce, > and I would like that to change as well. I put in a man page recently; at the moment it's only in -CURRENT. > You people are obviously more technical than I am, and as much as I > would love to help on the technical side, I'm not that great of a > programmer, I do webpages and graphics design, but I want to see > this thing work. You can certainly help if you can give us good directions. My last update to PicoBSD based on a particular need from a customer, but at the same time I tried to make it as general as possible. In particular, I put all the functionality of the fixit disk in the configuration, as well as some things which didn't fit on fixit. The real issue is: do we want a one-disk PicoBSD or a two-disk PicoBSD (in fact, it's one-disk or multi-disk)? One disk is becoming increasingly difficult to manage; as Andrzej pointed out, he has not been able to get things to work on -CURRENT. I think we could create a *really* minimal -CURRENT version if we omitted all hard disk support, but the direction is clear: the kernel is getting bigger, and the feasibility of getting both a kernel and a file system on one floppy is diminishing. I think the answer here is: we want both, which is what we currently have. If we have only one disk, space is *very* tight, and it's likely that everybody will need his own configuration. If we have two disks, things look a whole lot better. The version I have still has space. Jordan Hubbard has asked for nethack, but possibly there would still be space after that for things that might interest you; but you need to define them. The way the current 2 disk configuration works, you can have as many floppies as you like. The first one boots and asks you to insert additional floppies. You can stop whenever you want, but obviously the more you read in, the more functionality you have. > I'm more business oriented and so I would not mind at all keeping a > list of what feature requests are suggested, what feature designs > are suggested, improvements, patches etc... I have my own webpage if > that is what it takes to keep this thing cranking. Andrzej has a web page on www.FreeBSD.org. It's not well linked; we need to attend to that (Wolfram, are you listening?). Thanks for the offer, but we've found in the past that URLs starting with www.FreeBSD.org are easier for most people to find. > For example, we say that the networking version needs natd, ssh, etc.. > and we list out what consitutes a network version, and the same for the > dialup etc.. I can't even recall how much of this is in the current /custom subdirectory. Certainly I agree that ssh should be in there; natd is more the sort of thing you would want to run on a server, which might then be allowed to have its own disk. On the other hand, I frequently travel (I'm currently in the air between India and Singapore) and I can recognize the advantage of being able to hijack some machine somewhere and use it to connect to the net without overwriting its disk. > Trinux has taken a modular approach to all this. I don't think that > is neccessary, but at the same time, a more well grouped development > effort might make it better with quicker turnaround time. We have a modular approach, too. It's so modular that it looks completely unstructured :-) You go into the crunch and crunch2 directories and choose your programs. > It's just a thought, and again, if you guys need some pretty looking > website, let me know, I can cough that up. > > BSD currently doesn't recognize my modem, and so if I wanted to use the > ppp picobsd, then I have to use one of my old 28.8 ones. Ouch. Does > the network version support DSL? I think that depends on which version you use. My understanding is that DSL is an Ethernet interface, so you don't even need ppp. If you're using the custom version and having trouble, I'd be interested in knowing what problems you're seeing. But don't confuse interest with a commitment to fix it :-) In summary: what else do we need in PicoBSD? Do we need to do it in one disk? Otherwise, what is a good base 2-disk solution? And if that isn't enough, what could be on the third disk? Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers 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?20000122145538.A390>