The latest upload of the Debian hurd package features a patch by Ognyan Kulev which has support for ext2 partitions larger than 2 GB on 32bit systems. Over the last years, this limit had become an annoying issue of the GNU/Hurd system, so this change represents an important milestone for the Debian GNU/Hurd port with respect to user expectations. Although the patch has not yet been integrated by the upstream GNU Hurd maintainers, the Debian package maintainers consider it (after thorough testing) stable enough to warrant its inclusion into the Debian hurd package.
The original implementation of the ext2 file system translator simply mmap'ed the whole file system into its address space, which limited support to filesystems of no greater than approximately 2 GB on 32 bit architectures. At that time (the early 90s), this limit was no practical issue and the much simpler implementation strongly outweighed this shortcoming.
There have been several discussions on the re-design of the ext2fs translator among the Hurd developers over the years. The earlier ones were not held on publically archived lists, but summaries and reposts of the proposals by Thomas Bushnell, BSG and Roland McGrath can be found here and here. Later discussions included a proposal by Neal Walfield and subsequently a concrete implementation proposal hashed out at a Hurd developer meeting in Karlsruhe in early 2003. In April 2003, Ognyan Kulev posted the first alpha version of his patch. He released several more alpha versions after input from Neal Walfield over the summer and then a first beta in late October. During that time, Ognyan also published an extensive write-up of the design and implementation details of his patch, based on an early version. The general approach has been summarized by Neal as follows:
"By mapping the entire file system into memory, ext2fs was able to trivially calculate where metadata was located by simply adding the offset of the data on the partition to the base address of the memory map. In order to allow ext2fs to scale to larger partition sizes (i.e. those in which the partition could not be memory mapped in its entirety), a level of indirection has been introduced in the form of two hashes which map partition offsets to memory addresses and vice versa. When a block of metadata is accessed, the partition offset is looked up in the hash. If a corresponding address is not found, a mapping is created. In this way, the virtual address space is better used. This additional level of indirection is not neccessary on architectures where an address space is really sparse as the original implementation is sufficient and marginally faster."
After the beta release of the patch, things slowed down a bit until Neal took up Hurd development again last summer and began to thoroughly review the interface changes in libpager, as well as comparing them to Thomas' and Roland's proposals, which resulted in further discussion. Ognyan changed his implementation slightly according to Neal's advice and later fixed some more bugs which surfaced when people starting to stress-test the code.
Although the details of the current implementation have not yet been approved (or even reviewed) by the Hurd maintainers (Thomas, Roland and Marcus Brinkmann) and thus the interface changes to libpager are not final, the Debian GNU/Hurd porters have decided that the practical gain in having support for large partitions outweighs the risks of diverging from upstream with respect to the well contained libpager interface.
Ognyan has also worked on an ext3fs translator as subject of his master thesis (in bulgarian) and already released the first version some tima ago, so further improvements can be expected in the future.
Yay!
Stay tuned! soon enough, the Hurd is getting a mouse driver! ;-)
Do you mean the mouse repeate
Do you mean the mouse repeater so that you can use the mouse in both X and the console? You can get a patch that does that here:
https://savannah.gnu.org/patch/?func=detailitem&item_id=3386
Otherwise, mice have been supported under X for ages.
You fell for the bait. :-)
You fell for the bait. :-)
Why is development on the Hur
Why is development on the Hurd so slow? Didn't Linux support 2GB+ file systems almost 10 years ago? The HURD was started before Linux. Is it just not managed well or something?
Hurd = vehicle for Stallman's
Hurd = vehicle for Stallman's politics
Politically motivated, committee assembled, projects move slowly.
Re "Hurd = vehicle for Stallman's"
Of course, the fact that creating a microkernel and all the servers needed for useful operation is a difficult task, with only a small team working on it, might have something to do with it as well...
I should have been clearer: t
I should have been clearer: the immediate reason dev is so slow is -- of course -- lack of people to work on it. But the reason why it doesn't die and go away is political, not practical. It *is* practically dead; at the rate of current development, global warming may end civilization as we know it, before GNU/Hurd is a functional OS.
It should be be clear that the opposite is true of GCC and many elements of the GNU toolset -- whatever RMS's politics, they serve a valuable *practical* role, and so remain alive.
According to you, the whole G
According to you, the whole GNU project should be a vehicle for Stallman's politics, so you should insert into the list GCC, GNU libc and thousand other libraries and software you are using everyday. Have they a slow development? No.
And btw, look at mailing list before commenting stuff, since RMS has nothing to do with current Hurd development. Real reason is lack of developers.
Real Reason?
I want to see a viable version of the hurd as much as the next guy, but blaming the lack of developers seems like a cop-out. Because it just changes the question to "Why there is a lack of developers?".
Why Hurd lacks devels ??
Damn, it's really a good question.
Of course, thats true - Hurd lacks developers.
You must have a fuck-huge amount of enthusiasm to develop
for Hurd these days. Ppl want things done fast and easy.
And they do this by running Linux.. based, BSD.. systems
(i found this phenomenon much in common as with the Windows and all
other comercial OS'es). If one runs windows, and you try to push
him/her toward GNU/Linux, BSD's.., you'll fail in most cases. And as i see the
circumstance around Linux.. migrationg to Hurd(witch is a real
GNU OS) is a _reflection_ in a mirror of one above.
Very rare type of ppl easily migrating from one system to another.
First thing is of couse because GNU/Hurd(on Mach) is _verry_ slow.
Yes, now it has more-or-less stable distribution on four CD's, but
still, system is hard to configure, it don't have Drivers of its own..
But it is a system with _HUGE_ oportunities for developer.
You must try Hurd, and get in common with it. Because Hurd is being
ported to L4 micro kernel now, it will have unbelievable score in
perfomance and everything else. Many protocols and system parts are
about to be _created_, just use your imagination, if your idea is
good, it will probablly find its used. And you better hurry to go and
contribute for it, it is a great chance to escort and be part of
something big, something witch one day will be in a wide use.
So, developers welcome.
Nice.
I have some questions:
"it don't have Drivers of its own.."
Is it have another (Linux?) drivers?
Where can I find good docs for understand what is L4 and why it so great?
Where can I find update docs on Hurd/Mach/L4?
Thanks.
Help on Hurd doces.
I have some questions:
"it don't have Drivers of its own.."
Is it have another (Linux?) drivers?
Where can I find good docs for understand what is L4 and why it so great?
Where can I find update docs on Hurd/Mach/L4?
At the moment, Hurd-on-Mach uses Linux drivers.
http://savannah.gnu.org/projects/hurd/ -- Here you go,
from CVS Repository there you can download hurd-l4 source
tree. Documentation is build when you compile it.
http://www.l4ka.org/projects/pistachio/ -- And here you'll find
L4::Pistachio, with is L4 u-kernel Hurd is being ported on, with documentation..
So, have fun.
The fact that HURD is being p
The fact that HURD is being ported to L4 doesn't entirely answer the performance question for me - although L4 does provide some very fast primitives, performance will still be highly dependant on the servers running on top.
I'm not saying the servers in HURD aren't efficient, just that the system structure as a whole is important, regardless of the underlying microkernel.
HURD
"Ppl want things done fast and easy."
As opposed to slow and difficult?
"Because Hurd is being ported to L4 micro kernel now, it will have unbelievable score in perfomance and everything else."
And by the time that port is finished, Linux will be using next-generation schedulers, with next-generation filesystems together with ultra-low-latency kernel. HURD developers (both of them) notice that their performance is not competetive anymore, and they decide to port HURD to even better microkernel. And after that's finished, Linux and other OS'es have moved even further ahead.
"Many protocols and system parts are about to be _created_"
They have been working on HURD for... what, 15 years? And they STILL haven't created the necessary system-parts??
"And you better hurry to go and contribute for it, it is a great chance to escort and be part of something big, something witch one day will be in a wide use."
They said the same thing in 1991, and look what happened.
> "Ppl want things done fast
> "Ppl want things done fast and easy."
> As opposed to slow and difficult?
Here i ment _migration_. You can go to any other GNU system
without facing problems that you will in GNU/Hurd.
I can get a SuSe, Mandrake.. whatever.. CD's. Push mouse
button few times in installation process. And it's done.
I'll have a great pool of help information online, probably all
hardware i have will work for me, i can write document's, listen
music, watch TV.. or whatever.
> They have been working on HURD for... what, 15 years?
> And they STILL haven't created the necessary system-parts??
Hurd on Mach has all what you can need.
To port Hurd to L4, all Hurd servers must be rewriten. _But_,
rewriten, the way so they can take all advantages of L4.
And thats where you can come, and do the thing.
So, don't watch. Act.
And by the time that port is
And by the time that port is finished, Linux will be using next-generation schedulers, with next-generation filesystems together with ultra-low-latency kernel.
But still it will be a monolithic kernel (i'm not saying it's good or bad... =)
Learn To Die!!!
Hurd IS DEAD!!! The developers just haven't caught on yet!?!
Thanks for the info
Thanks for the info on Hurd. I'm looking up info on L4 development.
I hope hurd soon realy takes of. I like micro kernel idea. Maybe porting wil be easyer.
Lack of Developers, Maybe...
As one who follows the Debian-Hurd list, "lack of developers" is a common complaint, but I would turn attention in a few additional directions:
1. Sheer difference of design - most implementations drawing on microkernel technology graft the functionality tightly to the kernel rather than translators out in userspace where each user could run their own choices.
2. Kernel agnostic - the system isn't supposed to be tied to any specific kernel, but rather be able to work with whichever is preferred for the system.
3. Lack of focus - when I mentioned this on Debian-Hurd, I wasn't popular, but there are people hacking to have Gnome implemented when X11 isn't reliable, and people working on other such "eventually useful" aspects when key libraries or translators need essential work - such as the 2 GB partition issue.
4. Lack of focus 2 - Linux kernel development has Linus Torvalds, with Alan Cox, Andrew Morton and a few others working closely to make decisions that get things done, and they know kernel design (definitely by now they know it!) They have helped define the core and get less functional parts re-opened to solve problems. The various BSDs have core teams setting goals. The Hurd has large sweeping concepts and philosophies, but hasn't yet finished the foundation in some areas and lack of blueprints in others, and doesn't have people stepping into roles comparable to Linus or the leaders of the BSDs.
The Hurd has conceptual value at this point - the Mach implementation does provide a proof of concept example that a system *can* be built. However, we have seen NeXTStep and MacOS X both built on the Mach microkernel and perform viably (mind you, by grafting functionality onto the kernel rather than leaving it as a microkernel) - when the developers of the Hurd point to Mach as the problem with that system's slow performance, and that the L4 microkernel will solve the performance problems, I am tempted to potentially suspect that the problem may be more with the concept of userspace implementation of various core aspects.
A couple decades ago, I worked for Watcom, and one of the systems we worked with there was the Port OS. No, I didn't think you would have heard about it. It was a research spin-off from the University of Waterloo on i86 that had a "room" interface where you could create doors to other rooms, enter commands anywhere, select them, and execute them, and carry data about from program to program to work on it. Interesting concepts and approaches - the first functional system we had was out after the Xerox Star but before the Apple LISA, forerunner to the Macintosh. It was a great research exercise, but, similar to various other development efforts of operating systems, applications and hardware, not a marketable success.
The Hurd, at this point, is a great research exercise. Faced with Linux and the BSDs as viable operating systems that currently function and scale much better to equipment with largely similar interfaces for most end users (and substantively less complex to implement compared to the current state of the Hurd,) some may say that it is at risk of losing the mindspace to be anything but a research exercise. For many others, it has lost that mindspace. For the vast majority, they either don't know it exists or forgot about it, and might find their first hearing of the conceptual goals to see it be the next generation o/s intriguing, but talking about it as though that state is just a few months away is unfair both to the project and to potential users. At this point, the Hurd doesn't need potential users, but developers that want to build its foundation. Maybe it even needs a fork to people willing to focus on that foundation to implement a solid subset of the concepts, to provide at least a base for the development of the rest of the system.
GCC and glibc
Sorry to add to the possible flame war, but:
GCC and glibc are in the current state despite the FSF "maintainance". Just don't forget the work that the egcs team did when gcc development seemed to be dead, and years of work H.J.Lu did on Linux libc, and of course Ulrich Drepper's work on glibc2, even though RMS and FSF tried to do many things to force him to work on Hurd instead of Linux (details here, see the bottom part of the text).
Keep in mind the above next time when you see RMS requesting to use the name "GNU/Linux" instead of "Linux", claiming the main parts of the system (glibc and gcc) are part of GNU project. Both gcc and glibc are there despite of RMS and FSF efforts.
-Yenya
Re: GCC and glibc
As a pretty active GCC hacker, I can only say the
parent comment is *so* true. Had it been up to the
FSF to manage GCC, like it was until GCC 2.8, the
project as a whole would have spilled into oblivian
by now, and some other compiler would have replaced
it. In fact, even *today* the FSF is nothing but a
problem for GCC because RMS will not allow GCC to
stream the intermediate representation to a database,
which makes any serious work on interprocedural close
to impossible. RMS is a man from the past who has
turned into a dangerous delusional control freak.
This is not true
To say that the rest of GNU is as much a platform for Stallman's politics as Hurd is completely bogus.
Have you looked at the design of the Hurd? The whole thing is the engineering extension of Stallman. Stallman didn't have a password on his user account at MIT because he wanted democratic access to the machines. Hurd provides a way to make all users administrators within their own domains. It's even possible under the Hurd for users to run an additional authentication server, which makes it possible for them to provide a series of subusers, all without root privs. If you own a file, you can change that file, not just at the level of content, but down to the turning it into a Mach port (which has behaviour much like a device node in Linux, only more general).
In the first announcement of GNU, Stallman stated that he was copying Unix, not because it was good, but because he hadn't run anything better. Expanding, rewritting, and enhancing Unix semantics has always been his goal, whereas, say, Linus's goal is to incrementally grow Unix up.
And not just that. Stallman doesn't like Linux - he feels that it is ethical, because of its licence, and perhaps even technically strong, but the whole attitude of Linus is very offensive to him. The Hurd replaces not only the kernel, but Linus, and the Linux development model (GNU favoring democratic commitees of tight developers, with Stallman as distant dictator for life).
The reason development of the Hurd is slow is because:
The develoment model doesn't discourage new developers, unlike the BSD/Linux model which actively encourages them.
The Hurd has a big upfront design. This makes it hard for new developers to get involved (and hooked on the project) one patch at a time.
Many people find GNU's politics distasteful, and the Hurd is the epitome of that. The other GNU utilities grew rapidly in quality because people needed them to do real work, right now, and patched when they could, regardless of the politics. No one needs Hurd to do real work, right now, and so the politics is more a barrier.
See previous comment about no one needing it to do real work. Linux came along when the BSD was in legal trouble, and Minix was development was halted (for some good reasons, technically, and some bad ones, legally), and so Linux took off.
RE: Hurd = vehicle for Stallman's politics
Are you saying that not all things are politally motivated? I can't think of a single one that isn't, even breathing is in my books.
Re: Why is development on the Hur
Mostly because the offers no practical advantage to existing OS implementations. Need a free OS (as in freedom); Linux is 100x more useful. Need a free (as in beer) OS; there are dozens that work better. Need lots of functionality; oops the Hurd is no good to you. Need a functional Unix implementation on an x86 hardware platform; try Solaris x86, BSD, or Linux. Need an embedded platform with a good development toolkit; no Hurd here. etc.. etc.. etc..
As to why the Hurd didn't take off as quickly as Linux. Linux was started as a practical OS implementation by developers for developers. Although not entirely true any longer (remember that RMS fired a Hurd developer in the last year or so); the Hurd was started as a political vehicle. Developers respond better to code then they do to ideologly... which is why gcc and emacs worked out better for RMS than the Hurd.
Bobby
Why Hurd Development is So Slow
In a nutshell:
a) It has (practically) no users
therefore
b) it has (practically) no developers
because
c) it has (virtually) no reason to exist anymore
because
d) the need for a free, useful Unix-like kernel and OS was fulfilled years ago by Linux/BSD and now also Darwin
and
e) the microkernel concept is no longer the sexy new technology that it was in 1992, making Hurd seem like an old rotary-engine Mazda that nobody could ever get to work quite right.
It's hardly surprising that it has become the Duke Nukem Forever of the free software world.
a little offtopic
ammm mazda RX-8 isn't very old and... it seems that they made enguine to work right www.mazdarx8.co.uk
Sure
If you don't mind being plauged by engine flooding and the complete lack of torque at RPMs less than 5000, that is. It's nice that they reworked the exhaust ports so these ones don't blow up, but you still can't put forced induction on one for any substantial length of time.;-)
Yes, the microkernel concept
Yes, the microkernel concept is no longer a buzzword. However, it is still superior to the big-kernel concept in a lot of ways. Look at what QNX can do! Linux also moves slowly in this direction, too. And if the Windows kernel has any advantages, they stem exactly from its microkernel concept... Microkernels have weaknesses, too, but the FS community needs a good microkernel.
In my view, Hurd needs advertizing among the developers. Yes, much can be said about users, performance, politicality etc. etc. However, the FS community still needs a microkernel, and Hurd is still the one closest to maturity. If once released in a stable and well-performing distro, it will get users, then more developers, and will finally bootstrap. :-)
The problem is, how to advertize it effectively. Random opinions across some board won't help much, very few people read them. An organized campaign may be needed.
For example, some of its developers work in universities. If they start looking for ambitious and capable students, and put Hurd and the opportunity it represents before their eyes, this might add a developer here and there. Talking more about Hurd in public places might add another one. It won't be quick and easy, but if enough of efforts are invested, enough of developers may finally be attracted.
(Hint: The Linux kernel attracts a lot of programmers, but many are turned back by the behaviour of the ones already in. Some of these chased away are capable and talented. It would be a waste of resources for the FS community to lose them. Some combing through and around the Linux development may help bringing them back to FS... and Hurd. It may even create a healthy competition between Linux and Hurd. :-))
You have fallen prey to Micro
You have fallen prey to Microsoft propaganda. Windows certainly does not embody microkernel concepts. Although that may have been one of the early goals of the NT project, Gates essentially disposed of the microkernel design in favor of performance. Do not be fooled. The Windows kernel is a monolithic one where all the major "subsystems" reside in the kernel address space and freely call functions in each other.
I don't like it. this form
I like microkernel, but i don't like how hurd is, or better, I don't like gnumach. Hurd staff are very interesting, but what make interesting a microkernel is micro.
I like L4-hurd project, but it move very slowly. Maybe they can attract more developer if they switch to L4, but there isn't a lot agrement in this field (too many L4, and how to make transition).
Also IBM has a good microkernel, sawmill, very similar to hurd, developed some time ago and there was rumors about IBM donating it to OSS community .. too much hope here?
2GB? You mean 2TB?
2GB? You mean 2TB?
2 GB it is.
:-) No, 2 GB is correct. That wasn't a big deal in 1990, but lately it has been a major stumbling block to making any practical use of the HURD kernel. Too bad it's not the only one.
re: microkernel
closest to development? I guess you've never heard of DARWIN or DRAGONFLY BSD... both of which use a microkernel, and both of which are under free licenses. Hell with Dragonfly you get full 3d nvidia support! Hurd won't get that for 50 years at it's current development rate!
Dragonfly BSD isn't a microke
Dragonfly BSD isn't a microkernel-based system, it uses a monolithic kernel like FreeBSD.
Darwin is as much of a microk
Darwin is as much of a microkernel as linux.
re: re: microkernel
...and Darwin doesn't really use a microkernel either. Sure, it uses Mach but in a conventional, monolithic way. Device drivers, filesystems, etc run in kernel space just like a normal monolithic kernel.
Woot!
Woot! Now I finally will be able to get rid of the 200 partitions on my 400 GB harddisk...