Date: Tue, 30 Mar 1999 15:28:23 -0500 (EST) From: "John S. Dyson" <toor@dyson.iquest.net> To: tlambert@primenet.com (Terry Lambert) Cc: unknown@riverstyx.net, dyson@iquest.net, freebsd-chat@FreeBSD.ORG Subject: Re: Linux vs. FreeBSD: The Storage Wars Message-ID: <199903302028.PAA16589@dyson.iquest.net> In-Reply-To: <199903301839.LAA15833@usr06.primenet.com> from Terry Lambert at "Mar 30, 99 06:39:52 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Don't be intentionally ignorant. As I stated above, there are patches. > > > Logically, one might take that to mean that Linux developers can indeed > > > figure out how to do it. Fanaticism is soooo irritating. > > > > Well, why isn't it in the distribution? Why has it taken soooo long? The > > key is that I listened to the user base, and did some seriously grungy > > programming. There was little elitism, but simply to do what was needed. > > Why doesn't FreeBSD FS stacking work? > It never did, and there hasn't been much demand. It actually would be worthwhile to totally remove the stacking, or fix it with a VM approach. It is totally wrong to use buffer/VP approach, but there are those who advocate it (too many people are "bp" heads -- bp's are good only for I/O, not object or caching representation.) FS stacking will not help to gain commercial work, but properly working reasonbly sized file I/O does. > > Why was X.25 broken, and then > not fixed? > I don't know. I guess that it is an orphan, where the implementation hasn't been commercially interesting (or the companies aren't contributing the work back.) It certainly isn't interesting from a research or fun standpoint. Since companies like Whistle do networking, it would be nice to see a contribution in that area? (I know that there is supposedly alot of X.25 stuff out there, but why hasn't it been supported? Answer: apparently other types of X.25 interfacing methods are being used.) > > Why was LFS broken, and then not fixed? > It was always broken, and has always been basically a festering mess. LFS wasn't rewritten because softupdates has been the better answer for most of what LFS can do. It is totally wrong to implement a bp based LFS anyway, note the hacks in vfs_bio to support that travesty. > > Why does the VM > system like to write password database pages back to the crontab, if > you stress the system by running newsyslog once a minute from a cron > that modifes copy-on-write pages mmap'ping the password database into > code, as if the pointers in the pwent pointed back to static buffers > in the C library? > Which version? and please PR it. I have *never* seen it in person recently, and locally hacked kernels can cause unexpected brokenness. The problem of modified programs has been fixed a long time ago. Also, it has taken awhile to find someone competent to work on the VM/VFS code. There is a possibility now, but most of the people with the "balls" to work on the code with commit frenzies, are often not careful enough to do so. Time for cowboys is LONG LONG gone, and it seems that cowboys are the most commonly available resource. > > In a more general sense: Why are most of the Usenix papers scheduled > this year not about work done on FreeBSD, if FreeBSD is the premeire > research OS? Where is the research? > Alot of work is done privately. Research != papers, there is NO advantage for a FreeBSD team member to give away the mechanisms for FreeBSD's behavior. > > FreeBSD has it's own problems in the "show me the money" vein. > > > > made, and FreeBSD development being mired in short term expediency. In > > fact, the FreeBSD solution has been being discussed on the Linux mailing > > lists, and wonder if they looked at what we did? It is much easier to > > copy a design, than to actually think... > > Linux has shown a willingness to implement design that FreeBSD has > only given lip service to, time and again. Linux is, unfortunately, > where research is taking place. > The ones doing real work will continue to use BSD for now. I don't consider the catchup game that you have alluded to as "research", but only catchup. You are confusing "catchup" with research. Do you see the difference? (Linux's VM research is a very entertaining example: can you say lots of knobs that you need to tweak?) FreeBSD's VM has lots of knobs, but those knobs are only desirable for atypical configurations. > > > It seems that fanaticism is where an inferior decision is being made, > > whilst a correct solution already exists :-). A little verbal sparring > > is nowhere near the insanity of wasting effort with reimplementation. > > E.g., FreeBSD's implementation of a kernel linker *after* Linux? I > tried to implement a kernel linker for FreeBSD, and was met with a > "not in *my* kernel". I had to settle for an inferior external > linker mechanism; and viola, LKM's were born. Similar stories exist > elsehwere in the history of the project: POSIX threads, the addition > of system calls, like "issetuid" (or whatever). > > You can talk a good talk, but I would have adopted your work if it was worthwhile to do so (I wanted to, in fact.) I didn't have the energy to maintain the mess that your changes would have caused. It is better to deal with the mess one knows, rather than the mess that one doesn't :-). The changes that did get adopted were good, but did require support. (Sometimes your stuff was good, but much of the time, not complete enough.) > > Julian's right; someone needs to do real architectural work. > Time for Julian/Terry BSD. I am not really interested in armchair quarterbacks unless they are willing and able to help solve the problems. One reason why my code hadn't made it into FreeBSD's tree when I left, was because of QC issues. It takes restraint to keep from hacking the tree, and yet there is the need for architectural work. But who? There are precious few people available to do the FreeBSD architectural work (who are competent enough.) I do not include myself in that group, but would support someone who is willing and able. If my work would not be wasted, I would aggressively support such a developer (and continually do in the background.) John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903302028.PAA16589>