Hi, I'll jump into this, as this is a major source of frustration and confusion for me. And seemingly also for others. Perhaps this could clarify. Firstly, I'm replying to mbanck's post. Then I'm abusing the thread, Because it bears the right subject for my post anyhow. I hope you'll bear with me, brittle reader, since I at least felt that I was making a point when I wrote this. I made some paragraphs for easing the ingestion of this mail. On 200707252235, Michael Banck wrote: > Debian will continue the Hurd/Mach port until a viable alternative > exists, which will likely take a few years, if there will ever be one. At least it exists, although barely-moving and support- and featurewise horribly behind. But its existence keeps up hopes. > As nobody knows how Hurd/NG will look like, a transition plan cannot be > made at this point, and whether or not a Hurd/Mach installation can be > migrated over is unknown. How unknown or unsure is it whether current development of the Hurd will be usable on a potential Hurdng? - Will current interfaces suffice in e.g. translators or device drivers, or will rewrites become necessary (How well did hardware work in Marcus' L4-attempts? And would that be forewarning for potential problems in other next generation microkernels?) - What about Hurd-specific glibc-specials? Are they of Mach-workarounding nature, or more of a non-Linux-dependency'ish nature? Obviously, the work on Mach won't be usable. That includes the device drivers (and glue code), I suppose. > Do you plan to help the Hurd development? Unless you are a microkernel > researcher, you can ignore Hurd/NG for the time being. I have come to understand that key individuals within the Hurd community are less than satisfied with patching up Mach. And with good reason. But also that there is a despair of heirs to Mach. Nothing adequate with a usable license seems available, right? While the L4 effort is dropped, Coyotos seemingly is undergoing heavy development. It has been mentioned as a viable choice for next-generation Hurd microkernel before. How are current opinions on that? I can't tell, but if I am not mistaken, it has been (is?) a design goal of the Hurd to be microkernel-independent. In these microkernel-dissatisfaction times, would it be the right time to consider refactoring towards microkernel-independence, and let Mach live on as a testbed? (In OO-lingo, a Standard implementation?) 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? -- end of reply, start of thread-abuse -- The Hurd's place in the future ============================== 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. (Disregarding Linus' own possible motives, here). This will -- if it is allowed to evolve -- cause Linux to slow down, as more and more speed will get lost in Linux' reportedly slow IPC. Which is where the Hurd comes in, being slow already, but at least having chosen the prudent (in the ``time has shown'' kind of way) method of implementing and maintaining drivers and other kernel features. (I'm guessing that) from this point on, multiprocessing and decoupled hardware will punish monolithic kernels and lessen the punishment on decoupled kernels and software. And wishes for maintainability, scalability and stability will gain momentum, when speed is plentiful. Which will favor the Hurd. Capability ========== Coyotos is gunning for being a capability-based system. That is an interesting take on systems design, and -- seemingly as always -- fine-grainedness of capabilities causes hair loss. I won't venture deeply into this, since I haven't followed it closely, but one discussion on coyotos-dev that I did get something out of was such technicalities as how to toss a capability object around. I say technicality, since it (from my novice eyesight) seems irrelevant to the system design. My first thought was to implement the quickest way of handling it -- typedef'ing a pointer type -- and simply write the improvement of that on the TODO. (But those guys and their discussions are a bit too hardcore for me to fully grasp, so I'll excuse for any misunderstandings on my part). Zooming further out =================== Picking up on my ``when speed is plentiful'' remark, I would assume that the world will (very) soon see a lot of parallel computing. Locking of resources, moving of tasks between processors and more exotic things like transparently networked IPC will become more widespread, not only in the Hurd. And consequently computers ought to get some hardware support for optimizing these tasks. Just like wireless technologies prompt for hardware acceleration of cryptographic routines, since it would otherwise be somewhat of a drawback to take the step to wireless. This should also lessen fear of performance issues with the Hurd. Linux already is big enough to have a certain umph in hardware design, and if stability-, scalability- and maintainability-oriented users start to use Hurd, support from the chip vendors will probably catch up. (Like it does with hardware virtualization technologies, these days). Continuing existence of the Hurd ================================ Two points that I'm noting: - What made Linux successful was its mere existence. When GNU was trying to grasp microkernels, Linux did ``monolithic'' and got through with reasonable success. It's proprietary competitors were (and are still) using somewhat the same schemes of kernel design, which doesn't put Linux in a totally unacceptable competitive position -- allowing Linux to flourish because of its other advantages. - The Hurd regularly gains the interest of newcomers. I've been lurking along for long enough to know that the lists regularly get bumped with some novice (arnuild being the latest, still fresh in memory) with lots of enthusiasm over the prospects of the Hurd's goals. Alas, it soon dawns on us newcomers that it's mostly toughlived vaporware, and even getting an everyday system running isn't feasible, perhaps not even doable on modern hardware. These two points tell me one thing, which I also commented above, about the Debian Hurd port: The Hurd needs to continuously exist to survive. It doesn't matter whether it sucks performance wise, or that there is no sound or accelerated graphics. It doesn't matter either, that it's based on an old-fashioned microkernel, from a user standpoint (albeit it does clog up on the development pace and -joy). That's a reason for forcing _some_ decision through, regarding the future direction of work on the Hurd. It'll be too hard to satisfy my thought-up existence requirement (assuming you concur it exists) if development is stuck at Mach and closed development groups. And this will scare off users and developers alike. DVCS and technical solutions to management problems =================================================== 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. What is however needed in my opinion, is, that development should be more playful implying that it should be less structural. An example of how this may be done can be seen in Linux' 2.4 vs. 2.5 series. 2.5 was never meant to be used in a production environment, but was meant to mature into 2.6, which would become usable in a production environment. While 2.5 was evolving, 2.4 was kept somewhat more stable. (This scheme has since been abolished, as a sidenote). This is not a technical issue, and DVCS'ing alone won't solve it. What's needed is a gust of boldness, or at least, loosening of resistances to do something not-necessarily-thought-through. Obviously, technical tools will help out, but we all seem to be computer scientists here, so using tools is the first thing that comes to mind. Development model, human resources ================================== While of course appreciating the work done, the needed development still mostly hangs on a few shoulders. Recently, there was a dispute about reluctance to patching on gnu-system-discuss that shed further light onto the lack of enthusiasm for development from the senior members of the community (not necessarily those of Hurd, I should add). In this setting, I'd like to point at Ubuntu. While Ubuntu and its derivatives still seem amateurish to me when I compare them with Debian, I got to acknowledge how Ubuntu has been able to facilitate much of its user base, no matter what level of expertise. When web-forums seem too... How do I put it... ``Fashionable'' for Debian, Ubuntu doesn't scare off its novice users with mailing lists. And when strict packaging- and licensing requirements improve the quality of Debian's packaged software, Ubuntu seemingly has (and allows for) a package for everything in its ``multiverse''. The Hurd wiki has been a source of documentation from user to user. While often its articles have been written by senior members of the community (since they understood the stuff first) success-stories and FAQ's may be added by junior members. Openbox has recently moved its website to MediaWiki for seemingly those reasons. Especially the Hurd wiki page for using Hurd on qemu has seen some use. Also, sources should be more up-front. It's not because I've been looking for it, but I still haven't got the cvs checkout command memorized. If I had, I might be more encouraged to check out the source tree and have a look around -- who knows what I might do? (Where ``I'' is someone mildly intertwined with Hurd development). All words but no action ======================= It's not the first time I'm posting my frustrations about the Hurd's state. And the previous times I'd get more-or-less assaulted for having a big mouth and no coding-creditability. ``If you think it's wrong, you fix it. But don't blame us, who made actual contributions''. My up-front answer to that is, that I've made no claims of being able to solve anything. I -- as all of us -- have no spare time for this project (which is a weird way of saying that it doesn't really interest me enough to sacrifice what ever time I have to the project -- because if enough interest was present, finding time wouldn't be a problem, right?). I however, am at the bottom of the hierarchy. I'm the pondering lurker, whose sole ability is to stir up stuff using arguments that hopefully will convince others to take action. What action is to be taken, in my opinion? It's easy. It's about realizing that problems exist (or, why I'm wrongfully frustrated). Good night, and thanks for reading, skrewz.
Attachment:
signature.asc
Description: Digital signature