Slashdot Mirror
GNU/Hurd Gets POSIX Threads
An anonymous reader writes "Neal Walfield announced the first release of RMGPT, which is (or rather, aspires to one day be) a complete, portable implementation of IEEE Std 1003.1-2001 threads also known as POSIX threads. With this new pthreads library, it will soon be possible to run complex software packages on the Hurd, including the GNOME and KDE desktops, the OpenOffice suite, and the Mozilla web browser. Find more information here, including the humorous meaning behind RMGPT, and insight into a future Hurd release..."
Looks like the Hurd server collection is starting to lift off. Since Debian is working on Debian GNU/Hurd, and now this new ability, all the Hurd developers need is some more driver developers.
:)
If they get that Hurd will start to become a world usable kernel, and it's always good to have some competition in kernel land
I read a long time back that The HURD would be "ready" very soon. However, The HURD just keeps chugging along at a slow pace... how many people really care about it? I know there's a Debian GNU/HURD, but does anyone use it? Hopefully this is a big step to more widespread adoption of the thing.
Happy New Year, it's 1984!
What is the relationship between GNU/Hurd, Darwin and MKLinux? All is based around a Mach-kernel. Are there any familiarity between them that have any relevance? Does the continuing work on Darwin and GNU/Hurd benefit from one another, and if so, in what respect?
- Henrik
- when the Shadows descend -
Regarding the name, RMGPT, Neal explains, "Most new program names are a bunch
of letters stuck together. Only later does it become an acronym and the words
become bound. This is boring; each new release of RMGPT will offer a fresh, new and
exciting expansion of the 'acronym'." For this first release, RMGPT stands for
"Rubbish, I asked for mine with Minced Garlic, Please Take this back".
Yeah, but equally you could say "Why didn't all the Linux developers join the HURD project".
It's good to have variety. I don't care if Windows gets destroyed or not. It's rubbish, but I don't care, I don't want to see billg thrown to the lions, I just want to use softs that don't suck.
Sooner or later, we will have machines that work properly - and it might even be that the HURD is the first one to get there.
Fitness through diversity, my friend.
Justin.
You're only jealous cos the little penguins are talking to me.
There are numerous very fundamental differences between Hurd and Linux/*BSD.
As for rallying around Linux, that would also be a bad idea. If you know anything about software development, youll know that the progress of a project is NEVER proportional to the number of developers. Infact, often its inversely proportional.
Also, there are a range of applications for which I would not consider Linux but would consider FreeBSD ideal.
I dont think this is a wasted effort by any stretch.
loply.com
I won't even go into the overhead inherent in a micro kernel message passing architecture.
That, and rest, means you are not aware of the research done in the last 5 or 10 years in the field of micro-kernel, with what we called the 'second generation micro-kernels', like L4. The cost of "message-passing" (or IPC to use a correct term) can be minimised and reduced by a factor of 10. With fast IPC, a lot things become possible, that are not in monolithic kernels, and even in many micro-kernel based systems. Look at some papers on http://www.l4ka.org/publications/ for more informations.
From what I have read, the HURD tries to go to a direction that no other O/S has gone before. This is good because innovation is needed, but they should get rid of all the notions of the past: processes, filesystems, users, groups etc. all these things are for O/Ses of the past. A computer is primarily a deposit for information. We put information in it, we exctract information from it, we process information (and we play games!). They should do the following design: each computer shall have a global tree of information nodes, where as each information node can act as a repository for other information nodes. The system shall be object-oriented, where each node has a specific interface that must implement. Each information node will be an object with all OO shit on it: property querying, run-time type id, message passing, etc. If you sit down and think of it, everything is an object and a repository: there are files, some files are databases, some databases contain records, some records contain entries...an executable contains code, data, resources...a font contains metrics...a window contains other windows...a network contains other computers...etc. By ditching the notion of 'program/task/process', we can get rid of re-usability once and for all. Let me describe an example. Let's suppose that I want to make a bitmap processing application. Here is the traditional way: 1) design the gui 2) find/implement some lib which manages most formats 3) implement a nice C++ framework for working with those formats 4) implement drawing and other operations Here is the new way: 1) use the global 'Bitmap' class as an interface for manipulating bitmap objects; jpeg, tiff, and other formats know the internals of themselves; all I need to know as a programmer is the bitmap API: draw line, put pixel, get width, get height, resize, etc. Suppose that I wanted to search for a photo which is like another photo, possibly with some pattern matching. With traditional operating system: 1) must use special program 'cause I can't do this operation on the system level 2) must use database 3) must use digital imaging app 4) most propably I will not have all this so I will do it by hand The new way: 1) having a handle to the 'bitmap' in hand that I want to compare with, I scan the object tree and call operator '==' for each bitmap. Or use an API like 'patternMatch' which is common to all 'bitmap' types. Another example: lets say I want to browse my MP3 collection for songs of a specific artist The traditional O/S: 1) can't do it (well, except on BeOS) The new O/S: 1) search and return a list for all objects that are subclasses of 'mp3' and where 'artist == Madonna'. Only one browser whould be needed. Custom browsers could be embedded within a master interface. An app could be one object with all its data (code, resources, dlls, etc) in one object repository. The HURD follows some of the above logic, but not completely. They are trying to implement traditional things (filesystems, proccesses, etc) but with a microkernel architecture. But this is not a big deal, because monolithic kernel customization has become very easy, even for non-programmers. They should be doing something for the future.
I've always found myself intrigued by that fact that Windows NT has a POSIX subsystem. However, security folks always tell you to disable it so I've gotten the distinct impression it isn't really used for anything (I've never personally seen a program that uses it.). Now this post comes along and it becomes obvious to me that POSIX is a big deal in the UNIX-like-OS world. Did MS just screw up their implementation or is it something potentially useful that nobody happens to use? TW
Hi! I don't think any of us is working on the Hurd "because RMS says so". The Hurd already provides many things that other systems will never be able to to. I love being able to add root privileges to a running Emacs when I quickly want to edit a system, configuration file. This is possible on GNU/Hurd, as are many other cute thinks. Cheers, GNU/Wolfgang
Bottom line is that both of them and their "followers" (if this term can even be used in this context) have done a lot for free software. The RMS camp will continue to exert an important influence within the community and their work will be highly valued, but as you say "business seems to have and apathy for ideals."
Pragmatism is very important for bringing useful things into the market quickly, and naturally that is where many people are coming from. On the other hand, in the long run, ideas (and ideals) do matter.
It is important that the GPL is widely adopted, and there isn't a lot of confusion from variations on license terms, but that doesn't mean you should get religious about it. In the long run, these things will settle out, and they already are.
The microkernel ideas behind Mach and all of its derivatives are an important advance in Computer Science, and the HURD project is where these ideas are being devoloped in full. They are not ready for full scale deployment, but when they are, they will be adopted quickly. That is the beauty of a single clear Free license (GPL), because there is no reason that these two projects can't exchange large pieces of code. If the Linux team wants to pull in the HURD microkernel in a major release cycle, there is no licensing issue. The only issue is whether it make technical sense. Nobody should worry that the HURD doesn't have many drivers, since it should be possible to import drivers from Linux. In fact it should be possible to import them wholesale if the interfaces can be matched.