Date: Tue, 28 Jan 1997 21:49:02 -0500 From: "Brian J. McGovern" <mcgovern@spoon.beta.com> To: hackers@freebsd.org Subject: Constructive criticism (was: bashing everyone for fun and profit) Message-ID: <199701290249.VAA04040@spoon.beta.com>
next in thread | raw e-mail | index | archive | help
Sorry about the title. I figured it would catch some attention, although the prior part is truely what I hope this will be... constructive criticism. Its roughly 9:30pm, and I'll be heading off to bed soon, as I have to get up at 5am tomorrow, so if this sounds half witted, blame the brain thats half asleep. Now the criticism.... I've been noticing, more an more, that FreeBSD has been/is being divided in to two camps. Basically, the "has", and the "has not". What I mean by this, is that there appears to be the core team, who kick butt making this stuff all work, then the people like me, who'd like to help out where they can, but seem to have an incredible time getting started. Lets take, for instance, the case of ports. I currently have a port of an older version of xtrek running on my box here at home, albiet you can't beam armies up to your ship, but I digress... I'd like to submit it in to the "games" section of the ports. However, I notice this great little file structure that allows you to type "make install clean", and bam! the application is made, installed, and the working space is cleaned up. Pretty slick. However, the bulk of the people I've dealt with using FreeBSD (most of them newbies, albiet, but...) just don't get it. I still have a hard time (which is why I haven't bothered doing it with xtrek) finding a "cookbook" way to set these up. I suspect that if I had a more straight forward way to do one, I'd probably pump about one out per week, and would be willing to take ports on request, and see if I could hack one in to shape (allowing a relative newbie to have his widget X that hasn't already been done). The second major area of concern in my eyes is device drivers. Someone pointed me to a section of handbook that dealt with doing it (supposedly), but it was terribly out of date. Back to ground zero. I hate to say it, but I'll never write the great american device driver, because I can't get the one that returns "A quick brown fox..." when you read from it installed and working. Not because the device driver wouldn't work. Its just that, in my limited experience, it'll take me hours to figure it out - hours that I could be spending writing the great american device driver. To make matters worse, the next version might have a completely different interface. Net result? I do nothing, because I feel my efforts will be obsoleted before I stand a chance in hell of finishing. I guess what I'm driving at is that although the documentation has been getting much better lately, several critical areas are lacking (mostly the technical-weenie stuff). Now, I also realize that the people best suited to writing these documents are the ones that are hard at work actually doing the work. However, on the flip side of the coin, if one were to take a modest 25% of their development time to write this documentation, and then a person (or group of people) could then work a project, being capable of no more than 25% of the work the original person would have done, you still haven't lost anything. If you could make this person or group 50% as efficient, you're now gaining 50% development for a 25% investment in cost (net gain, 25%). I guess what I'm getting at is this: There are a lot of us out here who would write man pages if we knew how to typeset them, those who would write neat utilities if we knew how to poll the information from the kernel (hell, I know about zillion people who'd love to know how to pull IO/up-down, config statistics from their Ethernet interfaces, for instance), those who would write drivers for widget X if they knew how to get them in to the kernel (there are a million books on writing drivers, but none that I know of that speak especially about FreeBSD)... Is it possible to get a commit from the right people to do this, so I can get rid of the conversation flow that looks like: Me: I have X, and would like to do Y. Where can I find docs on it? Them: Look at handbook section X.Y.Z. Me: It doesn't work. Them: Oh, yeah. Its out of date. Me: Then where can I get recent documentation. Them: There isn't any. Try looking at <insert some piece of obscure, already out of date code here>. Me: <gives up>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701290249.VAA04040>