The Hurd Gets Support For Large Filesystems 58
latroM writes "Finally, after many years of waiting, the Hurd has got support for partitions larger than 2GB. The patch is told to be very stable and its development was started about a year and a half ago. Michael Bank writes: 'I hacked the Debian package so far that I make it build a statically
compiled ext2fs with Ogi's patch (20041029) for partitions > 2GB. For
now, I decided to just copy libpager, libdiskfs and ext2fs to
libpager-ogi, libdiskfs-ogi and ext2fs-ogi, apply his patch and dump the
result as a new patch. Another patch modifies the Makefiles accordingly.' I did some basic tests with those packages and they work fine for me so
far. Any comments on how they work for people and how to possibly improve the packaging and integration of the patch are very welcome."
Take that, Microsoft! (Score:4, Funny)
Re:Moderation question. (Score:1)
Hurd development (Score:2, Interesting)
Doesn't exactly look as if development is proceeding at a roaring pace.
Re:Hurd development (Score:1)
Re:Hurd development (Score:2, Informative)
Re:Hurd development (Score:2, Funny)
Turns out they have trouble maintaining websites...
And they're trying to code a kernel?
Re:Hurd development (Score:2)
Actually the Hurd pages are in CVS and AMS (the guy who normally does the web site edits) had his ability to edit the pages revoked while Marcus was busy and didn't notice until recently (AMS can now edit pages again, hooray).
Coding and maintaining web pages are different tasks. If you read the mailing lists and hang out on the IRC channel you'll be kept up to date.
Re:Hurd development (Score:2)
"Finally, after many years of waiting" (Score:3, Funny)
Good Job! Now, what's next... (Score:3, Funny)
Let's see what we still need...
Out of memory
Segmentation fault
Evolution of HURD (Score:3, Interesting)
While Linux, Windows, etc. have had 2Gb filesystems for a long time, it is nice that HURD supports larger files now.
I'll probably never use it, but I respect the HURD crew for continuing to stay committed to their project, despite HURD being so far behind other kernels.
Re:Evolution of HURD (Score:2, Insightful)
Re:Evolution of HURD (Score:1)
Instead of starting up all of these projects that are well known to fall into neverland or trickle like rain in the desert, it would be great if more people wouldn't, and instead get behind a single project in order to keep it alive.
Forks or fresh code that parallel each other idea-wise only go so far (generally), but patches and branched development can live forever.
Re:Evolution of HURD (Score:1)
s/files/filesystems/
It may or may not support large files yet, that could be another few years
Sure (Score:2)
Kind of like reinventing the wheel, only you just finally made one of stone while everyone else is driving cars. And people are offering you free cars. Don't know what the point is, other than their ideology. But then, for GNU, ideology is the end and the means.
Patches (Score:1)
Future (Score:2, Funny)
Large filesystems are great
Re:Future (Score:1)
Next Up... (Score:4, Funny)
They've GOT to fix that 640K thing though...like, gag me with a spoon...
how can one most easily check out the HURD? (Score:1)
If I'm intruiged in trying out "GNU" what is the best way to get and install it? Is there a "distribution" of a completely GNU system running the HURD with an installer that's user-friendly and fairly straightforward yet? Or is a totally GNU system still in the state that "SNU / Linux" was back when lots of reading and domain knowledge was require
Re:how can one most easily check out the HURD? (Score:3, Informative)
Re:how can one most easily check out the HURD? (Score:4, Interesting)
In terms of differences - Hurd has very different models of doing things. For example, non-root users can effectively mount filesystems if they have all the permissions needed. There are these things called "translators" which is a bit like FUSE or the other user-space filesystem things you get - essentially, generating a filesystem via a program, so you could mount anything you can script really.
There are lots of other interesting differences. Hurd isn't terribly similar to Linux, and does allow you to do some rather cool things.
Re:how can one most easily check out the HURD? (Score:1)
The entire idea with HURD though is quite a lot different from Linux (and other monolithic designs). The biggest one being that HURD uses user space for almost everything. Ultimately this gives the OS a lot more flexibility and stability.
On the whole I think that the design behind the HURD is a more interesting than other current OSes. I guess we'll just wait until it's gotten a bit furt
Re:how can one most easily check out the HURD? (Score:2)
Actually, they are very different, even on the surface, because the surface of the kernel is not the surface of the OS. GNU/Linux and GNU/Hurd on the other hand are very similar. This is exactly why RMS is telling people to call it GNU[/Linux], not Linux. Because it's the OS people see, not the kernel. And the OS is GNU.
Re:how can one most easily check out the HURD? (Score:1)
As to non-root users can effectively mount filesystems if they have all the permissions needed, how is that different than GNU/Linux, where I can use the
Re:how can one most easily check out the HURD? (Score:2)
Of course, emacs runs fine. As to the other stuff, I believe Ruby is there as well, as is the current XFree86 Debian package from unstable (we have not tried building X.Org yet). Regarding GNOME, it mostly builds fine but there are some runtime issues which need to be sorted out first, it does not startup correctly right now
Re:how can one most easily check out the HURD? (Score:1)
Interesting about the mounting. Better to have the permissions on the resource itself rather than on a combination of the resource and the mount point.
Actually, you're thinking of Plan 9. (Score:1)
Re:how can one most easily check out the HURD? (Score:2)
My advice? Only try HURD if you're specifically interested in it. If you just want to know what a GNU system is like, look at GNU/Linux. Even one of the BSDs or a commercial Unix will give you a feeling for what GNU is like; after all, GNU's Not U
Actually, we went down a slightly different road (Score:4, Informative)
Instead, after some more testing, we decided to fully apply Ognyan Kulev's patch so that every translated ext2 file system will use it. I committed the code to the Debian Hurd package svn repository yesterday and we will probably upload it by the end of this week.
Michael
Oh, and my last name is 'Banck' not 'Bank' (Score:3, Informative)
I am called Michael Banck, actually.
but what else do you expect? =)
Michael
Re:Oh, and my last name is 'Banck' not 'Bank' (Score:2)
Who actually uses HURD and what for? (Score:1)
Soo.. what's better?? (Score:1)
Lemee see.. A monolithic free kernel versus a microkernel with darn near everything as userspace
Touch the source and the Linux kernel might as well put (TAINTED) by your name.
Anyways, just cause HURD isnt usable right now doesnt mean it wont mbe in 5 years. Nobody says I have to choose only
Re:Soo.. what's better?? (Score:1)
And Mach. And QNX.
Re:Soo.. what's better?? (Score:2)
Actually, the GNU Hurd is no kernel. It rather builds upon a microkernel, which happens to be GNU Mach for the time being (work is underway to port it to the L4 microkernel)
Michael
Re:Soo.. what's better?? (Score:1)
told to (Score:2)
Can someone comment on this as a design methodology? How does this work, exactly? "Listen, patch: you be stable, now. You hear me? Be stable!"
Is this still relevant for AMD64 ? (Score:1)
Re:Is this still relevant for AMD64 ? (Score:1)
Re:Is this still relevant for AMD64 ? (Score:2)
Indeed, the old implementation jut mmap()'d the whole file system into memory, resulting in the 2GB limit. This would not be the case on 64-bit architectures; however, I am not aware that GNU Mach runs on AMD64 natively with 64 bits.
Michael
How 'bout large files? (Score:2)