Re: Confusion about where to go in Hurd
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-
Reply to: