On Fri, Feb 29, 2008 at 5:05 AM, Matthew Dillon <[EMAIL PROTECTED]> wrote: > Well, I'll give you my 5-second opinion. > > What I am not worried about: > ... > * Ports and packages. This was a huge worry of mine at the beginning > of the project. I no longer worry about it.
Yeah, pkgsrc is a real life saver. I discovered NetBSD around the same time DragonFly was picking up pkgsrc, so it was very pleasant for me to have a reasonably uniform administrative strategy across the two operating systems. > What I am worried about: > > * The big-ticket items that we have traditionally compared ourselves > against, SMP primarily, have developed slowly, primarily because > up until recently I was the only person working on it. > > It an issue of man-hours more then anything else. FreeBSD simply > has more developers working on SMP then we do. > > We have the infrastructure and the abstraction, we now need to get > down to the brass balls and finish it. Well yeah, that's my point. FreeBSD's vast developer base lets it get away with relatively unclean code and still remain relevant in performance and functionality. Stability has picked up a lot too, although that's hard to measure with hard evidence. > * I really want to see someone take up the ball on getting the > network stack MP safe. It's important to the project but I can't > do that and HAMMER at the same time. It's the easiest thing > to make MP safe in the project. Wasn't it "almost done" years ago, and then virtually untouched thereafter? I haven't been keeping up with source-level changes like that, but I got the impression the last 10% takes 99.99% of the time which is why it's still not done. > * Similarly with AMD64. We need it. I've developed the > infrastructure separation required and we even have a fully > virtualized kernel (vkernel) which demonstratres the infrastructure > separation. Most of the generic kernel code can easily support > a 64 bit architecture. The compiler supports it. It's a project > waiting for someone to take up the ball. > > * Our interrupt routing subsystem really needs a major upgrade. > (i.e. a major port from FreeBSD). That's pretty much a showstopper for a lot of deployments. It's things like that which I believe bring the project down. Even if it's only a problem for 6 months, that's 6 months worth of new users which may be discouraged from using the system, or use another system "temporarily" that never gets replaced with DragonFly again. This has brought down Linux and other projects a lot in the past, where a critical bug was left unchecked long enough that hundreds or thousands of users took years to try again. I contend that fixing major problems must come before implementing new technology, especially if that new technology is likely to add new problems. If somebody installs DragonFly just to try HAMMERFS and discovers half of his hardware fails because of an interrupt bug, what good does that do? > Where I think the future is: > > * SMP, Storage, and SSI. Real time mirroring at the logical level. > HAMMER is a major component for the storage, SSI, and mirroring > components, and I believe HAMMER will be a large interest magnet. I for one don't like to speculate about the future like that, because such gambles often cost a lot even to companies who have a lot of information from which to predict. Although it's been said the best way to know the future is to invent it, a lot of inventors have had their efforts wasted because of the lack of marketability of their inventions. > Our project goals have not changed, but if I had it all to do over > again I would have started work on HAMMER much earlier then I did. > > I spent more time then I should have perfecting the low level > infrastructure, trying to build a base upon which all the other > work could occur. No, I agree with everyone who says the low level stuff is what makes this project great in the first place. I'm just concerned it's nowhere near enough to take enough market share that SSI becomes truly useful. If it's just 1000 hardcore geeks in the whole world split into a few SSIs, what practical benefit is there? They may as well SSH in to a few powerful machines, and even consumer machines are becoming ludicrously powerful lately. The security and efficiency of shell access is a much more mature field than the security and efficiency of SSI in general, saying nothing of any specific implementation. And then, application clustering for web serving, databases, etc. is already largely solved on the application level, often much more optimally than a general approach could ever be. SSI doesn't help there either, unfortunately. > -Matt -- Dmitri Nikulin Centre for Synchrotron Science Monash University Victoria 3800, Australia