Hi, On Thu, Jul 26, 2007 at 03:43:57AM +0200, Anders Breindahl wrote:
> How unknown or unsure is it whether current development of the Hurd > will be usable on a potential Hurdng? Nobody knows, really. > - Will current interfaces suffice in e.g. translators or device > drivers, or will rewrites become necessary Whether translators will have to be rewritten, depends on how much the design of the new variant will deviate from the existing design -- but this is not clear at all. > (How well did hardware work in Marcus' L4-attempts? Not at all. Neal and Marcus avoided considering device drivers as much as they could. > Obviously, the work on Mach won't be usable. That includes the device > drivers (and glue code), I suppose. Yes, if we switch to a totally different microkernel. > While the L4 effort is dropped, Coyotos seemingly is undergoing heavy > development. The Hurd/L4 effort is dropped, not L4. There are several L4 variants in more or less active development. > It has been mentioned as a viable choice for next-generation Hurd > microkernel before. How are current opinions on that? I think Marcus has more or less discareded it as an option; but I'm not sure. > I can't tell, but if I am not mistaken, it has been (is?) a design > goal of the Hurd to be microkernel-independent. This is not really possible. The lower-level system parts are very closely related to the microkernel; it doesn't make any sense to be portable at this level. If the higher-level design is kept intact, most translators should work without much change however. > By the way, from the name, a microkernel seems to be something easy to > write. Could somebody please outline to me (and others with my > knowledge of the field) why this isn't the case? I suspect that it > isn't so much about actually writing the thing, but more about knowing > what it is that one wants to write? Yeah, that pretty much sums it up. A microkernel has very few and minimalistic mechanisms, but as these are fundamental to the whole system, it's extremely hard to get them right. > In recent news, Linus has made a move toward a userspace driver > environment, which someone at coyotos-dev commented was to be > ``hitting the monolithic complexity wall''. In other words, they've > come to (or are at the verge of) preferring maintainability over > speed. No, that's not what this framework is about. The issue this framework addresses is that vendors of very specialized hardware (which is never generally distributed) tend to hack some kludges into the kernel so they can run their specialized drivers in user space -- but they are generally doing it wrong. The new framework is meant to provide them with the necessary mechanisms done right. AFAIK it's meant exclusively for these specialized drivers; not for anything getting wide circulation. > - What made Linux successful was its mere existence. When GNU was > trying to grasp microkernels, Linux did ``monolithic'' and got through > with reasonable success. Well, that's one of the reasons for Linux' success compared to the Hurd; but not the only one. > Alas, it soon dawns on us newcomers that it's mostly toughlived > vaporware, I don't think it's really appropriate to call the Hurd vaporware. While some people get disappointed by the lack of some relatively basic things, a great many actually err on the other side -- they are quite surprised how complete the system already is... Some people are even asking whether it is self-hosting (i.e. can compile itself) -- which it has for more than a decade (!) What really causes frustration is how close the Hurd seems to be to general usability, but at the same time isn't able to take that last step... In spite of all shortcomings of the Hurd, I'm not aware of any other general-purpose operating system that uses a true (multiserver) microkernel architecture, and comes even close to the level of usability the Hurd offers. Depending on what you want to do and how high your expectations are, it's in fact possible to regularily use the Hurd right now. > and even getting an everyday system running isn't feasible, perhaps > not even doable on modern hardware. The problem of hardware support is actually not that fundamental. I can't claim any real knowledge on that topic, but from what I've seen so far, it seems to me that an experienced developer could update gnumach to use a recent set of drivers within a couple of weeks, or a few months at most. Of course that won't automatically bring things like USB; that requires implementing additional components... But making it basically work on current hardware shouldn't be that hard. > It was recently suggested that upstream CVS should be > semi-transparently be mapped onto some distributed version control > system, so that experimental development could find a home (or homes, > for that matter). While generally upgrading the VCS is sensible, I > can't say that I agree that this is a needed step. Which Alfred also > mentioned in that the ams-branch -- in his opinion -- didn't get any > effect upstream. The fact that a CVS branch didn't do much good, is hardly proof that no better VCS is necessary... The whole point of using a distributed VCS is that you no longer need to care about upstream: It's not a problem at all to do development with changes not going upstream for a long time; while in CVS (or SVN) it's a real pain to work with stuff not on the trunk. -antrik- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
