Hurd Advocacy?

12 views
Skip to first unread message

Hurd Advocate

unread,
Aug 15, 2003, 5:00:15 PM8/15/03
to

What can the Hurd community do to promote their favorite OS?

It seems like the Hurd doesn't really have a critical mass of
users to spur the growth we'd all like to see. So I was wondering what
everyone thought was the best way to attract more developers/users to
the Hurd. The reason I initially looked into the hurd is the BitKeeper
fiasco. I found it unpalatable for free software to be beholden to a
proprietary master. I thought it would't hurt to look at the
alternatives. And I came across the Hurd. From what I could initially
find out, it seemed like it had interesting and modern architecture,
one
which could solve the "Linus doesn't scale" problem more cleanly than
the BitKeeper solution. (And here I'm assuming that things like
userspace device drivers and the fact that any part of the system can
theoretically be replaced on the fly really does solve that problem).
I
was, of course, also attracted just because it was something new and
different. So I wonder what attracts everyone else to the Hurd. To
that end here are a couple of questions I have.

- Is there any killer-app for the Hurd (available now or in the future)
that we think will bring the masses in? Or phrased a different way,
is there any one feature that people would be willing to think about
converting over for.
translators?
distributed OS?
better security model?
more customizable? (is that a word?)

- Are hardware compatibility problems more of a problem for newbies, or
is it the lack of software which stifles adoption. (And for the
record, I think the killer-app would be Linux and the Hurd running
side by side on top of the same micro-kernel. That would make
migration easier, since you could still have access to your important
hardware and software that hadn't been ported over yet)

- Is it hard to attract developers because the project is too complex.
Instead of just learning one system, you have to learn about two: the
hurd and mach. And who would want to learn about mach when it's
scheduled for removal whenever the L4 kernel gets traction (3-5 years
out?)? Or is it the "multi- threaded servers are hard to debug"
problem still.

- Is a lack of documentation the real hard thing for new developers to
overcome?

- Are we nice enough to newbs? (I tend to think so, but there was a
little hissy-fit about change-log colon-placement for hello.c on
bug-hurd last month)

- Do we suffer from a lack of charasmatic leadership and direction?

- Is there any one thing which could be fixed to attact a lot more
users?
PPP?
sound?
USB?
GNOME?
journaled file system?
OpenOffice?

- Is advertising our problem? Do we not get enough exposure to
potential developers? (And here I'm thinking CS undergrads) I'm
thinking that a new developer could have a lot more influence on the
design of the Hurd (since it's still in flux) than say a more mature
project like Linux or FreeBSD.

- Does anyone think that companies like RedHat or IBM might think about
funding some summer college internships to work on something like the
Hurd?

- Is there any future development that might drive people to the Hurd?
Like the SCO garbage or DRM binaries/signatures in the Linux kernel?

- Is our installation proceedure/Debian system overly obtuse?

- Are we always destined to play catch up with Linux? (eventhough we
had
a headstart?)

Anyways, I'd like to hear your thoughts.


The Hurd Advocate

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


--
To UNSUBSCRIBE, email to debian-hu...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Lee Braiden

unread,
Aug 15, 2003, 5:40:10 PM8/15/03
to
On Friday 15 Aug 2003 9:31 pm, Hurd Advocate wrote:
> What can the Hurd community do to promote their favorite OS?
> - Is there any one thing which could be fixed to attact a lot more
> users?
> PPP?
> sound?
> USB?
> GNOME?
> journaled file system?
> OpenOffice?
>

For me, sound is crucial. I don't mind hacking on a system all day to get
something working, but if I can't play an MP3 while I do that, then it
suddenly gets a LOT less fun. REALLY :)

I think my network card works now (DLink 530tx?), but good nic support is
crucial for lots of people. How can they use an OS in the modern age if they
can't even check their mail on it? :)

Next, I'd say GNOME and OpenOffice, in that order. It's hard to believe
they're not already supported, actually ;)

> - Is our installation proceedure/Debian system overly obtuse?

Yep :)

> - Are we always destined to play catch up with Linux? (eventhough we
> had
> a headstart?)

Probably. Perhaps someday, people will talk of free/opensource operating
systems, instead of just 'linux'.

If not, perhaps a common driver SDK for all free/os platforms would help.
Hell, that would help immensely. I'm surprised no one's done it yet :)

--
- Lee.

deFreese, Barry

unread,
Aug 15, 2003, 5:50:06 PM8/15/03
to
> -----Original Message-----
> From: Hurd Advocate [mailto:hurd_a...@yahoo.com]
> Sent: Friday, August 15, 2003 1:55 PM
> To: debia...@lists.debian.org
> Subject: Hurd Advocacy?
>
>
>
> What can the Hurd community do to promote their favorite OS?
>
> - Is there any one thing which could be fixed to attact a lot more
> users?
> PPP?
> sound?
> USB?
> GNOME?
> journaled file system?
> OpenOffice?
>
> - Is advertising our problem? Do we not get enough exposure to
> potential developers? (And here I'm thinking CS undergrads) I'm
> thinking that a new developer could have a lot more influence on the
> design of the Hurd (since it's still in flux) than say a more mature
> project like Linux or FreeBSD.
>
> - Does anyone think that companies like RedHat or IBM might
> think about
> funding some summer college internships to work on
> something like the
> Hurd?
>
> - Is there any future development that might drive people to the Hurd?
> Like the SCO garbage or DRM binaries/signatures in the Linux kernel?
>
> - Is our installation proceedure/Debian system overly obtuse?
>
> - Are we always destined to play catch up with Linux? (eventhough we
> had
> a headstart?)
>
> Anyways, I'd like to hear your thoughts.
>
>
> The Hurd Advocate
>

Here is my worthless 2 cents:

1. One of the biggest problems is probably the < 2Gb limit for ext2fs. I
think many people see that as a sign of antiquation even if the size doesn't
necessarily bother them.

2. Another is somewhat of a chicken and egg problem. The current user base
is too small to advocate/assist new users. Most of the most knowledgeable
people are busy with their real lives and Hurd development that they don't
have much time to spend with n00bs like me.

3. From a purely user standpoint, I think lack of good X support, desktop
environments, and the X type apps. (Mozilla for example). Most of the
purist/hardcore users and developers don't care about this but most "users"
do.

4. The lack of Marcus's console being the default. I think most users
expect multiple virtual terminals these days.

5. Stability.

6. Kernel issues. GNUMach 1.x is antiquated, slow, and has issues. Very
few (if any) are working on GNUMach 2.x (oskit-mach) and it has issues, and
L4 isn't ready and probably won't be for quite some time.

7. Hardware support. This could be somewhat alleviated from item 6 with
oskit but as I said, not many if any are working with it.

8. Direction. (And I am probably going to get blasted for this). This
somewhat ties into number 6 also. There seems to be lacking clear direction
from the on high of where Hurd needs to be. I realize that there are few
developers in the upper echelon of the Hurd but I don't see a clear figure
head. Linux had Linus as the spokesperson/figurehead. Hell even if Linus
never contributed a line of code after kicking it off there was
someone/something to rally around. I don't hear a voice for the Hurd. I
realize that this is an open source project and you cannot "make" anyone do
specific tasks. However, I believe that if there were some clear directions
laid out for the Hurd, it may gain some developers. That is merely
speculation on my part. Maybe the thing to do at the moment is somewhat
freeze development to a degree. Concentrate what few resources you have on
getting to L4 and then state some clear direction. Fix ext2fs next, work on
X, etc. etc.


Finally please just take these as my opinions. They are not meant to
criticize anyone and may not even be valid as I am predominanty a n00b user.
I hang out on #hurd a lot and I know that many people are doing a lot of
hard work for the Hurd so it isn't meant as a slam, just my thoughts on some
issues.

Thanks!

Oh, I forgot one. Good documentation. I hear many complaints about n00b
developers not being able to find good documentation on how/where to get
started. I know some of that again stems from the smaller user/developer
base but much of what is out there is either old or incorrect.

Barry deFreese
Technology Services Manager
Nike Team Sports
(949)-616-4005
Barry.d...@nike.com

--
"Technology doesn't make you less stupid; it just makes you stupid faster."
Jerry Gregoire - Former CIO at Dell

Marco Gerards

unread,
Aug 15, 2003, 6:00:07 PM8/15/03
to
Hurd Advocate <hurd_a...@yahoo.com> writes:

> What can the Hurd community do to promote their favorite OS?
>
> It seems like the Hurd doesn't really have a critical mass of
> users to spur the growth we'd all like to see. So I was wondering what
> everyone thought was the best way to attract more developers/users to
> the Hurd. The reason I initially looked into the hurd is the BitKeeper
> fiasco. I found it unpalatable for free software to be beholden to a
> proprietary master. I thought it would't hurt to look at the
> alternatives. And I came across the Hurd. From what I could initially
> find out, it seemed like it had interesting and modern architecture,
> one

It is scary to find out bitkeeper is good for something ;).

> which could solve the "Linus doesn't scale" problem more cleanly than
> the BitKeeper solution. (And here I'm assuming that things like
> userspace device drivers and the fact that any part of the system can
> theoretically be replaced on the fly really does solve that problem).

There are not much userspace drivers yet, but this is the
feature. Everything in the Hurd can be replaced on the fly
AFAIK. Think about the TCP/IP stack, filesystems, etc.

> I
> was, of course, also attracted just because it was something new and
> different. So I wonder what attracts everyone else to the Hurd. To
> that end here are a couple of questions I have.

1) Political reasons. AFAIK all Hurd hackers care more about freedom
than about technology. (Like bitkeeper vs. CVS).

2) Technological reasons. Did you read the papers on
http://hurd.gnu.org. I can also advise you to install GNU/Hurd and
have a look what is possible with GNU/Hurd and what wasn't with
UNIX.

3) New technology, new possibilities. Users can do more, but the
system is more secure.

4) The community.

5) It's fun. :)

> - Is there any killer-app for the Hurd (available now or in the future)
> that we think will bring the masses in? Or phrased a different way,
> is there any one feature that people would be willing to think about
> converting over for.
> translators?

This works perfectly for me.

> distributed OS?

This is not possible yet. Because the Hurd runs on top of a
microkernel and uses RPC for almost everything this is really easy to
add as a feature for the Hurd. (Easy compared to monolithic kernels).

> better security model?

One thing I can think of is no, one or more UIDs.

> more customizable? (is that a word?)

For my feeling it is. Can you give me an example of what you want to
customize?

>
> - Are hardware compatibility problems more of a problem for newbies, or
> is it the lack of software which stifles adoption. (And for the
> record, I think the killer-app would be Linux and the Hurd running
> side by side on top of the same micro-kernel. That would make
> migration easier, since you could still have access to your important
> hardware and software that hadn't been ported over yet)

Running GNU/Linux and GNU/Hurd simultaneously is really easy to add as
a feature on some architectures. For example the mklinux distribution
uses a hacked linux kernel that runs on top of Mach.

It is already possible to run multiple GNU/Hurd installations
simultaneously (this is called a neighbourhurd). For mklinux such
support is easy to add. IIRC someone already wrote some code for this.

There are many packages for Debian GNU/Hurd available. Of course much
more programs should be ported to the Hurd. (porting = fixing bugs in
the program or in the Hurd most of the time).

The driver support is ok I think. It isn't really great, but most
commonly used ethernet cards are supported by GNUMach.

> - Is it hard to attract developers because the project is too complex.
> Instead of just learning one system, you have to learn about two: the
> hurd and mach. And who would want to learn about mach when it's
> scheduled for removal whenever the L4 kernel gets traction (3-5 years
> out?)? Or is it the "multi- threaded servers are hard to debug"
> problem still.

I think it is hard to learn about the Hurd (that's what others say).
I think it is better to learn not everything, but just start hacking
and you will learn. Not everyone will agree with me about this, but it
works for me.

The multi threaded servers is not a problem for me while
debugging. Actually it is easy to develop stuff like translators
because everything is in userspace.

>
> - Is a lack of documentation the real hard thing for new developers to
> overcome?

There is very little documentation. Luckily the comments are really good.

> - Are we nice enough to newbs? (I tend to think so, but there was a
> little hissy-fit about change-log colon-placement for hello.c on
> bug-hurd last month)

It's just like any project. A lot of different people, a lot of
different attitudes. :)

> - Do we suffer from a lack of charasmatic leadership and direction?

I don't think so.

> - Is there any one thing which could be fixed to attact a lot more
> users?
> PPP?

Absolutely.

> sound?

I doubt if this is a requirement for an OS still in development.

> USB?

I think this won't ever be added to Mach. I'm sure it will be done for L4-Hurd.

> GNOME?

Does it work? Doesn't it?

> journaled file system?

I agree. IIRC ext3 is on Ognyans todo list. :)

> OpenOffice?

IIRC there was a problem with pthreads...

>
> - Is advertising our problem? Do we not get enough exposure to
> potential developers? (And here I'm thinking CS undergrads) I'm
> thinking that a new developer could have a lot more influence on the
> design of the Hurd (since it's still in flux) than say a more mature
> project like Linux or FreeBSD.

I agree we need more developers. I think the project looks a bit dead
to the outside world. Perhaps a release can help us, and releasing
more frequently. Also news sites like kerneltraffic and kerneltrap and
even slashdot can help.

> - Does anyone think that companies like RedHat or IBM might think about
> funding some summer college internships to work on something like the
> Hurd?

I'm afraid they are only interested in things that works in production
environments. :(

> - Is there any future development that might drive people to the Hurd?
> Like the SCO garbage or DRM binaries/signatures in the Linux kernel?

I don't hope such things happen. But I would like it that people will
have a look at GNU/Hurd. It is a good thing that people care about
free software and switch to (or keep using) free software because of
that. I'm sure about one thing, GNU/Hurd will always be completely
free.

> - Is our installation proceedure/Debian system overly obtuse?

I don't really understand your question. Debian GNU/Hurd cannot be
easily installed like Debian GNU/Linux is. (I hope that answers your question).

> - Are we always destined to play catch up with Linux? (eventhough we
> had a headstart?)

the Hurd should be capable of doing everything Linux can I think.

For me the following things need to be done before I will use it on my
desktop all the time:

- The port to L4 must be done.
- The 2GB limit should be fixed.
- PPP should work

--
Marco

Shawn Boyette

unread,
Aug 15, 2003, 6:20:09 PM8/15/03
to
On Fri, Aug 15, 2003 at 02:43:21PM -0700, deFreese, Barry wrote:

> 6. Kernel issues. GNUMach 1.x is antiquated, slow, and has issues. Very
> few (if any) are working on GNUMach 2.x (oskit-mach) and it has issues, and
> L4 isn't ready and probably won't be for quite some time.

> 8. Direction. (And I am probably going to get blasted for this). This


> somewhat ties into number 6 also. There seems to be lacking clear direction
> from the on high of where Hurd needs to be. I realize that there are few
> developers in the upper echelon of the Hurd but I don't see a clear figure
> head. Linux had Linus as the spokesperson/figurehead. Hell even if Linus
> never contributed a line of code after kicking it off there was
> someone/something to rally around. I don't hear a voice for the Hurd. I
> realize that this is an open source project and you cannot "make" anyone do
> specific tasks. However, I believe that if there were some clear directions
> laid out for the Hurd, it may gain some developers. That is merely
> speculation on my part. Maybe the thing to do at the moment is somewhat
> freeze development to a degree. Concentrate what few resources you have on
> getting to L4 and then state some clear direction. Fix ext2fs next, work on
> X, etc. etc.

This is exactly the conclusion I reached a few days ago when I read
about L4 through Debian Weekly News. I keep wanting to play with the
HURD, but it keeps on not existing. This is almost farsical,
announcing a switch to a new kernel architecture (which, I might add,
is already deprecated by its developers -- Pistachio is the current
branch of L4Ka, not Hazelnut) before the previous new kernel
architecture (OSKit) migration is even completed.

Is this a project to produce a kernel for a GNU OS, or is it some sort
of never-ending, ivory tower, trans-academic wankfest for kernel
geeks? Can you imagine where GNU would be if gcc and emacs had been
produced this way?

Second on my list would be the 2G limitation, followed by everything
else.

--
Shawn Boyette
md...@collapsar.net

Marco Gerards

unread,
Aug 15, 2003, 6:30:14 PM8/15/03
to
Shawn Boyette <md...@collapsar.net> writes:

L4-Hurd will run on Pistachio. I think the person who wrote the
article (or whatever it was) made a mistake.



> Is this a project to produce a kernel for a GNU OS, or is it some sort
> of never-ending, ivory tower, trans-academic wankfest for kernel
> geeks? Can you imagine where GNU would be if gcc and emacs had been
> produced this way?

I don't agree with the image you create. The Hurd is not an ivory
tower.

--
Marco

deFreese, Barry

unread,
Aug 15, 2003, 6:30:18 PM8/15/03
to

> Shawn Boyette <md...@collapsar.net> writes:
>
> > This is exactly the conclusion I reached a few days ago when I read
> > about L4 through Debian Weekly News. I keep wanting to play with the
> > HURD, but it keeps on not existing. This is almost farsical,
> > announcing a switch to a new kernel architecture (which, I
> might add,
> > is already deprecated by its developers -- Pistachio is the current
> > branch of L4Ka, not Hazelnut) before the previous new kernel
> > architecture (OSKit) migration is even completed.
>
> L4-Hurd will run on Pistachio. I think the person who wrote the
> article (or whatever it was) made a mistake.
>
> > Is this a project to produce a kernel for a GNU OS, or is
> it some sort
> > of never-ending, ivory tower, trans-academic wankfest for kernel
> > geeks? Can you imagine where GNU would be if gcc and emacs had been
> > produced this way?
>
> I don't agree with the image you create. The Hurd is not an ivory
> tower.
>
> --
> Marco
>
>

Shawn,

While I moderately understand your sentiment, in the fact that there is a
lot of design and theory behind Hurd, I have to agree with Marco for one
main reason. There is actually very little kernel development taking place
in the Hurd itself. L4 is being developed by another group, GNUMach 1.x is
dead, and very little if any work is being done on GNUMach 2.x. :-)

Barry deFreese
Technology Services Manager
Nike Team Sports
(949)-616-4005
Barry.d...@nike.com

--
"Technology doesn't make you less stupid; it just makes you stupid faster."
Jerry Gregoire - Former CIO at Dell

--

asubedi

unread,
Aug 15, 2003, 6:40:05 PM8/15/03
to
I think the issue about kernel is bothering many people. I would myself like
to see HURD on L4 as soon as possible. Right now, the HURD/L4 cvs contains few
header files and two or three idl source files. The thing that I really am not
understanding is will the GNU people develop their own L4 kernel or are they
going to use one developed by L4ka project? Most of of the kernels in L4ka
projects seem to either writen in C++ or are under non-GNU license.

-subedi

Shawn Boyette

unread,
Aug 15, 2003, 6:50:08 PM8/15/03
to
On Fri, Aug 15, 2003 at 03:29:28PM -0700, deFreese, Barry wrote:

> in the fact that there is a
> lot of design and theory behind Hurd, I have to agree with Marco for one
> main reason.

I do apologize for getting flamey, but it was an honest (if visceral)
response to "what do you think needs to be done to the
HURD?". Besides, it's not like I'm known for anythinig or my opinions
actually carry any weight :)

I'm a good enough programmer to know that I'm nowhere near good enough
to be a kernel developer; my point being that I know how involved and
complex OS design is. It's just that for the months I've been quietly
reading this list, it seems that nothing ever moves forward except via
the announcement of yet another transition to yet another platform
which will Totally Fix Everything, No Really This Time.

I also retract my statement about the 2G limit being
second-most-annoying. The fact that the HURD must be bootstrapped from
Linux (on install) is #2. Then the 2G limit. Then everything else.

--
Shawn Boyette
md...@collapsar.net


Marco Gerards

unread,
Aug 15, 2003, 7:00:07 PM8/15/03
to
asubedi <asu...@DEPAUW.EDU> writes:

> I think the issue about kernel is bothering many people. I would myself like
> to see HURD on L4 as soon as possible. Right now, the HURD/L4 cvs contains few
> header files and two or three idl source files. The thing that I really am not
> understanding is will the GNU people develop their own L4 kernel or are they
> going to use one developed by L4ka project? Most of of the kernels in L4ka
> projects seem to either writen in C++ or are under non-GNU license.

The kernel is developed by the L4KA project. Does it matter that it is
written in C++ or isn't GPLed? (Ofcourse what matters is that it is
free software).

--
Marco

Marco Gerards

unread,
Aug 15, 2003, 7:00:13 PM8/15/03
to
"deFreese, Barry" <Barry.d...@nike.com> writes:

> While I moderately understand your sentiment, in the fact that there is a
> lot of design and theory behind Hurd, I have to agree with Marco for one
> main reason. There is actually very little kernel development taking place
> in the Hurd itself. L4 is being developed by another group, GNUMach 1.x is
> dead, and very little if any work is being done on GNUMach 2.x. :-)

The port to L4 is top priority for most hackers. Because of that
GNUMach isn't just that important anymore, and that is really a good
thing!

Another issue is that the Hurd is microkernel independent (or will be,
depends on how you think of this). All work done for the Hurd will be
useful, despite of which microkernel will be used. If the 2GB limit
will be fixed it will will work on all microkernels, same for mozilla,
etc,etc.

--
Marco

Marco Gerards

unread,
Aug 15, 2003, 7:00:18 PM8/15/03
to
Shawn Boyette <md...@collapsar.net> writes:

> I'm a good enough programmer to know that I'm nowhere near good enough
> to be a kernel developer; my point being that I know how involved and
> complex OS design is. It's just that for the months I've been quietly
> reading this list, it seems that nothing ever moves forward except via
> the announcement of yet another transition to yet another platform
> which will Totally Fix Everything, No Really This Time.

Perhaps the bug-...@gnu.org and hurd-deve...@gnu.org are
interesting lists for you. debian-hurd is not really the list where
things about the Hurd itself are discussed. And I think many things
are not discussed but just done. :). (Like new packages, etc.)



> I also retract my statement about the 2G limit being
> second-most-annoying. The fact that the HURD must be bootstrapped from
> Linux (on install) is #2. Then the 2G limit. Then everything else.

AFAIK that is a debian issue. Am I right about that or is there
another reason?

Thanks,
Marco

Marcus Brinkmann

unread,
Aug 15, 2003, 8:00:14 PM8/15/03
to
On Fri, Aug 15, 2003 at 06:06:25PM -0400, Shawn Boyette wrote:
> This is exactly the conclusion I reached a few days ago when I read
> about L4 through Debian Weekly News. I keep wanting to play with the
> HURD, but it keeps on not existing.

Well, if you only want to play, there are enough toys out there that are
more existing than the Hurd. The current existing Debian GNU/Hurd should
nevertheless be enough to play with the Hurd. As a proof of concept, it
works quite nicely.

> This is almost farsical,
> announcing a switch to a new kernel architecture (which, I might add,
> is already deprecated by its developers -- Pistachio is the current
> branch of L4Ka, not Hazelnut) before the previous new kernel
> architecture (OSKit) migration is even completed.

We never considered Hazelnut to be a platform for the Hurd, it is way too
limited for that. Not sure where you got it from that Hazelnut is a target.
Our is Pistachio.

The OSKit integration into GNU Mach is not related to the Hurd at all. It
is just a different set of drivers in GNU Mach. Not many people are
interested in hacking on that, and this is for good reason. Although it
would make the device glue code in GNU Mach more sane, it wouldn't change
much from the user experience in the Hurd (in other words: it would still be
slow and unstable). The main features you would get with GNU Mach v2 are a
couple of drivers (like, a random device, and better serial port support for
PPP).

> Is this a project to produce a kernel for a GNU OS, or is it some sort
> of never-ending, ivory tower, trans-academic wankfest for kernel
> geeks?

The Hurd is not interesting at all from the perspective of producing yet
another unix core. There is BSD, there is Linux, and between the two of
them there is absolutely no niche for yet another monolithical kernel
intended to be used in production systems.

So what the Hurd is about is indeed its user-space design. However, just as
the Hurd on GNU Mach as a proof of concept is a good success, it is, as a
production system, a fantastic failure. There are several fundamental flaws
that absolutely must be addressed to hopefully make the Hurd competitive in
performance, stability, security and features. When looking at the options,
L4 seemed to be the logical conclusion, because it furthers the fundamental
design concepts of the Hurd and implements them more consequently than Mach
did.

Going to L4 will, unlike OSKit, require a complete redesign of the Hurd.
Much of this redesign has already been done on the conceptual level, and we
are slowly working towards the actual implementation. There are a couple of
interesting issues to solve on the way. All this is going on without a
guarantee that the final result will work better than the Hurd works now.
Although we have the feature-component of it under control, nobody can
predict if the performance and stability will improve and become
competitive, or if it turns out that it won't. Nobdoy can tell because
nobody attempted to implement a system like the Hurd before at this scale.

The Hurd is one of the few innovative free software projects. While most
other projects are "more of the same" in that they reimplement well known
and proven concepts, the Hurd is walking on new grounds, with all the
problems that this implies. And it is lacking some very experienced
developers with lots of spare time and motivation. We won't attract such
developers with GNU Mach, though, I can tell you that.

Now, about the ivory tower comment. Actually, most people on the earth have
stopped believing in a microkernel approach a long time ago. I think that
the history of operating systems has as much to contribute to the history of
the Hurd as other factors. However, if history is any judge, there is a
good chance that the hype curve will bend the other way some time in the
future. Hopefully we will then be able to profit from that. But that
requires us to find answers to questions so we can offer them to interested
parties at that time.

Thanks,
Marcus


--
`Rhubarb is no Egyptian god.' GNU http://www.gnu.org mar...@gnu.org
Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/
Marcus.B...@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/

Kent West

unread,
Aug 15, 2003, 8:40:10 PM8/15/03
to
The Hurd Advocate wrote:

>> What can the Hurd community do to promote their favorite OS?
>>
>>
>>

deFreese, Barry wrote:

>
>1. One of the biggest problems is probably the < 2Gb limit for ext2fs. I
>think many people see that as a sign of antiquation even if the size doesn't
>necessarily bother them.
>
>

Yes!

>3. From a purely user standpoint, I think lack of good X support, desktop
>environments, and the X type apps. (Mozilla for example). Most of the
>purist/hardcore users and developers don't care about this but most "users"
>do.
>
>

Yes.

>4. The lack of Marcus's console being the default. I think most users
>expect multiple virtual terminals these days.
>
>

Yes.

>5. Stability.
>
>
Yes.

>6. Kernel issues. GNUMach 1.x is antiquated, slow, and has issues. Very
>few (if any) are working on GNUMach 2.x (oskit-mach) and it has issues, and
>L4 isn't ready and probably won't be for quite some time.
>
>

Yes!

>Oh, I forgot one. Good documentation.
>

Yes.

--
Kent

Mark L. Kahnt

unread,
Aug 15, 2003, 9:50:06 PM8/15/03
to
On Fri, 2003-08-15 at 18:39, Shawn Boyette wrote:
> On Fri, Aug 15, 2003 at 03:29:28PM -0700, deFreese, Barry wrote:
>
> > in the fact that there is a
> > lot of design and theory behind Hurd, I have to agree with Marco for one
> > main reason.
>
> I do apologize for getting flamey, but it was an honest (if visceral)
> response to "what do you think needs to be done to the
> HURD?". Besides, it's not like I'm known for anythinig or my opinions
> actually carry any weight :)
>
> I'm a good enough programmer to know that I'm nowhere near good enough
> to be a kernel developer; my point being that I know how involved and
> complex OS design is. It's just that for the months I've been quietly
> reading this list, it seems that nothing ever moves forward except via
> the announcement of yet another transition to yet another platform
> which will Totally Fix Everything, No Really This Time.
>
> I also retract my statement about the 2G limit being
> second-most-annoying. The fact that the HURD must be bootstrapped from
> Linux (on install) is #2. Then the 2G limit. Then everything else.
>
> --
> Shawn Boyette
md...@collapsar.net

I would have to point out that the Hurd isn't presented as being today
absolutely ready and totally polished to outshine all other operating
systems available or even merely theoretically proposed. It is still
under development, although to a thoroughly designed concept, which
can't be said about many other o/ses (including that Microsoft stuff.)
However, because it is under development, there are certain things that
haven't as yet been completed, such as an installation procedure as
complete as boot-floppies. Don't view it as being beta software - some
parts may be that far along, while others are working to be alpha, and
some fortunately have become effectively complete.
--
Mark L. Kahnt, FLMI/M, ALHC, HIA, AIAA, ACS, MHP
ML Kahnt New Markets Consulting
Tel: (613) 531-8684 / (613) 539-0935
Email: ka...@hosehead.dyndns.org

signature.asc

asubedi

unread,
Aug 15, 2003, 10:10:08 PM8/15/03
to
>===== Original Message From Marco Gerards <metge...@student.han.nl> =====

>The kernel is developed by the L4KA project. Does it matter that it is
>written in C++ or isn't GPLed? (Ofcourse what matters is that it is
>free software).

I had noticed that some of the L4 kernels were licensed commercially while I
was browsing L4 website sometime ago. The concern of the choice of language
being that I had read in some paper that g++ is not really fine tuned as
compared to gcc (plus other GNU philosophies; sorry true GNU fanatic :).

-subedi


>--
>Marco

Glenn McGrath

unread,
Aug 15, 2003, 10:20:15 PM8/15/03
to
On Fri, 15 Aug 2003 13:31:37 -0700 (PDT)
Hurd Advocate <hurd_a...@yahoo.com> wrote:

> - Are we nice enough to newbs? (I tend to think so, but there was a
> little hissy-fit about change-log colon-placement for hello.c on
> bug-hurd last month)

One of the things that drove me away last time was being refused help on
irc because of how i phrased a question. (re GNU/Hurd naming
conventions)
Some tolerance would be nice.

> - Is there any one thing which could be fixed to attact a lot more
> users?
> PPP?
> sound?
> USB?
> GNOME?
> journaled file system?
> OpenOffice?

Stability, longer uptime.

> Anyways, I'd like to hear your thoughts.

Is the random number generator issue solved ? (it used to be a problem
when running ssh)

I look forward to L4-Hurd, seems like GNUMach is a ball and chain.

Glenn

Barry deFreese

unread,
Aug 15, 2003, 10:20:18 PM8/15/03
to
Mark L. Kahnt wrote:

>md...@collapsar.net
>
>I would have to point out that the Hurd isn't presented as being today
>absolutely ready and totally polished to outshine all other operating
>systems available or even merely theoretically proposed. It is still
>under development, although to a thoroughly designed concept, which
>can't be said about many other o/ses (including that Microsoft stuff.)
>However, because it is under development, there are certain things that
>haven't as yet been completed, such as an installation procedure as
>complete as boot-floppies. Don't view it as being beta software - some
>parts may be that far along, while others are working to be alpha, and
>some fortunately have become effectively complete.
>
>

Mark,

Not to be argumentative but then why does www.gnu.org say the following:

*it exists*
The Hurd is real software that works Right Now. It is not a research
project or a proposal. You don't have to wait at all before you can
start using and developing it.

Wouldn't that imply to the user that it is usable, not necessarily
alpha/beta? I'm not tryint to troll, start a flame, or downplay the
Hurd. In fact, I would like to see the Hurd prosper as an alternative
OS but I think it suffers from image problems.

--
Barry deFreese
Debian 3.0r1 "Woody"
Registered Linux "Newbie" #302256 - Debian Developer Wannabe

"Programming today is a race between software engineers striving
to build bigger and better idiot-proof programs, and the Universe
trying to produce bigger and better idiots. So far, the Universe is
winning." Rich Cook.

Marcus Brinkmann

unread,
Aug 15, 2003, 10:30:14 PM8/15/03
to
On Fri, Aug 15, 2003 at 09:04:07PM -0500, asubedi wrote:
> >===== Original Message From Marco Gerards <metge...@student.han.nl> =====
> >The kernel is developed by the L4KA project. Does it matter that it is
> >written in C++ or isn't GPLed? (Ofcourse what matters is that it is
> >free software).
>
> I had noticed that some of the L4 kernels were licensed commercially while I
> was browsing L4 website sometime ago. The concern of the choice of language
> being that I had read in some paper that g++ is not really fine tuned as
> compared to gcc (plus other GNU philosophies; sorry true GNU fanatic :).

Pistachio is Free Software, although not under copyleft, but more like the
revised BSD license. The documentation is unfortunately not freely
licensed.

It's written in a subset of C++, and the L4 people know exactly what
features they can use without running into problems and which should be
avoided.

The external interface of L4, the ABI, is of course language independent and
specified down to the assembler and bit level. There are convenience
interfaces for various languages, too.

Thanks,
Marcus

Barry deFreese

unread,
Aug 15, 2003, 10:40:05 PM8/15/03
to
Glenn McGrath wrote:

>On Fri, 15 Aug 2003 13:31:37 -0700 (PDT)
>Hurd Advocate <hurd_a...@yahoo.com> wrote:
>
>
>
>>- Are we nice enough to newbs? (I tend to think so, but there was a
>> little hissy-fit about change-log colon-placement for hello.c on
>> bug-hurd last month)
>>
>>
>
>One of the things that drove me away last time was being refused help on
>irc because of how i phrased a question. (re GNU/Hurd naming
>conventions)
>Some tolerance would be nice.
>
>
>
>

>Glenn
>
>
>
>
Hmm, how many guesses do I get to figure out who that was??? ;-)

--
Barry deFreese
Debian 3.0r1 "Woody"
Registered Linux "Newbie" #302256 - Debian Developer Wannabe

"Programming today is a race between software engineers striving
to build bigger and better idiot-proof programs, and the Universe
trying to produce bigger and better idiots. So far, the Universe is
winning." Rich Cook.

Marcus Brinkmann

unread,
Aug 15, 2003, 10:40:07 PM8/15/03
to
On Fri, Aug 15, 2003 at 12:27:49PM -0700, Barry deFreese wrote:
> Not to be argumentative but then why does www.gnu.org say the following:
>
> *it exists*
> The Hurd is real software that works Right Now. It is not a research
> project or a proposal. You don't have to wait at all before you can
> start using and developing it.
>
> Wouldn't that imply to the user that it is usable, not necessarily
> alpha/beta? I'm not tryint to troll, start a flame, or downplay the
> Hurd. In fact, I would like to see the Hurd prosper as an alternative
> OS but I think it suffers from image problems.

It all depends on your definition of various words, of course. But the
point of this item on the web page is to make clear that the Hurd is not
vapour ware in the sense that it's all talk and no code.

Thanks,
Marcus

Robert Millan

unread,
Aug 16, 2003, 12:10:08 AM8/16/03
to
On Fri, Aug 15, 2003 at 12:38:50PM -0700, Barry deFreese wrote:
> Glenn McGrath wrote:
> >
> >One of the things that drove me away last time was being refused help on
> >irc because of how i phrased a question. (re GNU/Hurd naming
> >conventions)
> >Some tolerance would be nice.
> >
> Hmm, how many guesses do I get to figure out who that was??? ;-)

Say it.

--
Robert Millan

"[..] but the delight and pride of Aule is in the deed of making, and in the
thing made, and neither in possession nor in his own mastery; wherefore he
gives and hoards not, and is free from care, passing ever on to some new work."

-- J.R.R.T, Ainulindale (Silmarillion)

Mark L. Kahnt

unread,
Aug 16, 2003, 3:10:08 AM8/16/03
to

I'm going to refer back to an email I sent back on 1 June to you (Barry)
when we were discussing the state of the Hurd:

"it exists


The Hurd is real software that works Right Now. It is not a
research project or a proposal. You don't have to wait at all
before you can start using and developing it.

"- I'll leave you to assess whether what you get now constitutes "works
Right Now". I wouldn't use it for a production system yet, or even as
the system on which I did development work, but testing code being
targeted to or ported to it, it seems to be "getting by". I know that I
wouldn't use it on a headless server, as I honestly don't know if it is
reliable enough to be able to log in via telnet whenever desired. I know
that while ssh is *somewhat* on the system, it isn't secure because the
key used isn't built with random numbers drawn from entropy."

In retrospect, the reference to logging in via telnet isn't really
expressing the point I wanted to make - I don't get the impression from
what I hear thus far that the Hurd is ready to be a production server,
maintained remotely by telnet or ssh.

I am not personally ready to dedicate a box to the Hurd to invest the
sort of time needed to realise its strengths, and file bug reports on
its weaknesses. I am left with the impression that there is too much
comfort waiting for someone else to patch what has been noted repeatedly
as problem aspects, such as the infamous 2GB partition size limit. When
such points are left to linger, the impression to a new investigator of
possibly exploring the Hurd, based on the write-up quoted on the gnu.org
website, is that when confronted with problems like the lingering 2 GB
limit, doubt arises regarding many of the other statements.

A similar consideration, as I mentioned in the 1 June email, and later
in discussions via email with Kent West was Kent's encounter with
mounting partitions. I understand that there is a mount script, but it
reportedly hangs the system. The write-ups from various Hurd sites,
however, imply that to the user, the common system usage should "seem"
like a common POSIX interface (the parts dealing with command line
utilities.) While the mount script is probably meant to do that for file
system translators, it apparently has been left seriously unfixed at
least with respect to the most commonly encountered file systems on
GPL'd operating systems.

So does "it exists" ring true to me? Aspects do, but not a complete core
system that I can trust as a functional information processing engine,
as the statement leads one to believe. When the core is done (kernel,
basic servers and translators to provide a reliable server - be that
web, print, file, database or whatever) that could be left running on
its own and trusted and secure, I'd agree with the statement from a
user's perspective. It is past being a research project, but it isn't
quite what I understand to be ready for a beta release candidate of a
distribution. From the perspective of a codebase to work on and a vision
being reached to, it exists. From a user-ready distribution perspective,
not this week.

This fits with the entry before it on the list - "its stable". It's
conceptual design is stable, but the binaries aren't necessarily
resulting in a system that runs with the level of stability comparable
to the BSDs or Linux in comparable breadths of configurations. With some
attention to core aspects, both of those could change - essentially
focussing on getting a kernel, a core set of translators and servers,
and the appropriate aspects of the GNU software suite to provide a
functional system that can host its own development and administration
(most of which I understand now exists,) a viable base for assembling a
distribution, or at least a reliably operational, installable o/s on
which the distribution can be ported as necessary.

Otherwise, the Hurd is limited to being an "aside" in the broader
mindset, comparable to BeOS, OS/2 and RSX-11, with respect to the other
free operating systems (Linux, the BSDs.) That would be squandering the
effort already put into the project.

signature.asc

Ognyan Kulev

unread,
Aug 16, 2003, 4:10:07 AM8/16/03
to
Marco Gerards wrote:
> I agree we need more developers. I think the project looks a bit dead
> to the outside world. Perhaps a release can help us, and releasing
> more frequently. Also news sites like kerneltraffic and kerneltrap and
> even slashdot can help.

My personal opinion about release goals of 0.3 is that they must focus
on stability. Not ext2fs, PPP, consoles or other new stuff. For
example, alpha 3 patch of ext2fs has reached a state where I can hardly
distinguish if computer hanging is caused by ext2fs or something else.
Using unstable system is very uncomfortable.

And about ext2fs: I believe that by the end of the year we'll have a
very stable filesystem as part of the Hurd.

Regards
--
Ognyan Kulev <ogi@{fmi.uni-sofia.bg,fsa-bg.org}>
7D9F 66E6 68B7 A62B 0FCF EB04 80BF 3A8C A252 9782

Ognyan Kulev

unread,
Aug 16, 2003, 4:10:06 AM8/16/03
to
Glenn McGrath wrote:
> One of the things that drove me away last time was being refused help on
> irc because of how i phrased a question. (re GNU/Hurd naming conventions)
> Some tolerance would be nice.

Zealots ;-)

--
Ognyan Kulev <ogi@{fmi.uni-sofia.bg,fsa-bg.org}>
7D9F 66E6 68B7 A62B 0FCF EB04 80BF 3A8C A252 9782

Marcus Brinkmann

unread,
Aug 16, 2003, 9:40:07 AM8/16/03
to
On Sat, Aug 16, 2003 at 03:07:27AM -0400, Mark L. Kahnt wrote:
> "- I'll leave you to assess whether what you get now constitutes "works
> Right Now". I wouldn't use it for a production system yet, or even as
> the system on which I did development work, but testing code being
> targeted to or ported to it, it seems to be "getting by".

That is a fair assessment.

> I know that I
> wouldn't use it on a headless server, as I honestly don't know if it is
> reliable enough to be able to log in via telnet whenever desired. I know
> that while ssh is *somewhat* on the system, it isn't secure because the
> key used isn't built with random numbers drawn from entropy."

You could set up egd to provide secure random on the system via a fifo.

> A similar consideration, as I mentioned in the 1 June email, and later
> in discussions via email with Kent West was Kent's encounter with
> mounting partitions. I understand that there is a mount script, but it
> reportedly hangs the system. The write-ups from various Hurd sites,
> however, imply that to the user, the common system usage should "seem"
> like a common POSIX interface (the parts dealing with command line
> utilities.)

Mounting and unmounting is not part of POSIX.

> It is past being a research project, but it isn't
> quite what I understand to be ready for a beta release candidate of a
> distribution. From the perspective of a codebase to work on and a vision
> being reached to, it exists. From a user-ready distribution perspective,
> not this week.

Definitely not. Beside the fact that large scale fixes and redesigns are
not happening timely enough (or don't happen at all), I believe it is not
possible to work out the tiny quirks and buglets like those in "mount" with
a small core team of developers. Beside actually finding these problems,
fixing them is very time consuming. This is something that can so easily done
by contributors even if they are not core developers (and the bug finding
can be done by users), and even if they don't want to make a long term
committment.

Savannah at sv.gnu.org/projects/hurd has a bug database and a patch
database. There have been 7 bugs files, some by me as a reminder. This is
ridiculous. Someone (hi bdd) is working on gathering bug reports from the
mailing list and put them into the database. There have been filed 32 patches,
a third by me, and then the rest by a small handful of people who are already
long term contributors. Only 15 patches (including most I filed) are not
yet applied, 17 have been applied. It could be 18 if there had been a patch
for mount.

How hard is it for someone like you who can C and knows Unix to fix mount
and submit a patch, or at least submit a bug report? Probably as hard as
it is for me. Maybe 5 minutes more to figure out some of the specific
Hurd aspects. If nobody except the core people are willing to put up this
effort, then why should the core people do it? Apparently it is not at all
urgent, and time is better spent elsewhere (ie, on the hard problems, which
are also there).

A volunteer based free software project of this scale can not be successful
with only core developers and end users waiting in the line. There needs to
be a solid middle ground. This didn't exist at all before 1998. It got
somewhat better, and now we have a middle which is quite productive, at
least more productive than any of the core developers with regards to short
term fixes etc. ;)

> This fits with the entry before it on the list - "its stable". It's
> conceptual design is stable, but the binaries aren't necessarily
> resulting in a system that runs with the level of stability comparable
> to the BSDs or Linux in comparable breadths of configurations. With some
> attention to core aspects, both of those could change - essentially
> focussing on getting a kernel, a core set of translators and servers,
> and the appropriate aspects of the GNU software suite to provide a
> functional system that can host its own development and administration
> (most of which I understand now exists,) a viable base for assembling a
> distribution, or at least a reliably operational, installable o/s on
> which the distribution can be ported as necessary.

Well, that's the idea. The problem is that of the people who did the
outstanding work of implementing the Hurd as it is today (mainly Thomas,
Roland and Miles), only one (Roland) is somewhat active at all still, while
Thomas only jumps in with a crazy idea or two from time to time.

People like me and Neal (and some other folks who have jumped in since then)
are targetting the big rewrite of the Hurd. But we are "new" in the OS
writing business, and have to learn a lot of things, and solve problems for
which cookbooks do not exist.

So while we are trying to do that, who is fixing mount?

Thanks,
Marcus

Marco Gerards

unread,
Aug 16, 2003, 10:10:11 AM8/16/03
to
Glenn McGrath <bu...@optushome.com.au> writes:

> On Fri, 15 Aug 2003 13:31:37 -0700 (PDT)
> Hurd Advocate <hurd_a...@yahoo.com> wrote:
>
> > - Are we nice enough to newbs? (I tend to think so, but there was a
> > little hissy-fit about change-log colon-placement for hello.c on
> > bug-hurd last month)
>
> One of the things that drove me away last time was being refused
> help on irc because of how i phrased a question. (re GNU/Hurd naming
> conventions) Some tolerance would be nice.

/ignore is a really nice feature of IRC :)

Just ask your question a bit later on IRC when more/other people are
online, people who are willing to help.



> > - Is there any one thing which could be fixed to attact a lot more
> > users?
> > PPP?
> > sound?
> > USB?
> > GNOME?
> > journaled file system?
> > OpenOffice?
>
> Stability, longer uptime.

Absolutely the most important.

> > Anyways, I'd like to hear your thoughts.
>
> Is the random number generator issue solved ? (it used to be a problem
> when running ssh)

I always copy a binary (/bin/bash for example) to /dev/urandom. It is
really ugly, but ssh works. :)

--
Marco

Hurd Advocate

unread,
Aug 16, 2003, 1:00:19 PM8/16/03
to
Okay maybe more than two words, but how would you try to convey the
excitement of the Hurd in a sentance? When I first started using Linux
and people asked me why, I said something like, "If it breaks, I can
fix it!". Summing up for the Hurd it might be something like, "It'll
be free -- even tomorrow!" But that seems at least a little bit
boring. So what catch-phrase would you use to explain why you use the
Hurd (and why they should too)? And I want to hear from you lurkers
out there as well as the regulars.


The Hurd Advocate


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

Marcus Brinkmann

unread,
Aug 16, 2003, 1:30:08 PM8/16/03
to
On Sat, Aug 16, 2003 at 06:10:35PM +0100, Ciaran O'Riordan wrote:
> Should I ask DWN for a correction?

It's not important.

Ciaran O'Riordan

unread,
Aug 16, 2003, 1:30:19 PM8/16/03
to
I haven't read this entire thread but the Hazelnut announcment
was made in my name by Debian Weekly News.

As a side comment in another thread, I mistakenly said Hazelnut
instead of Pistachio. Farid Hajji corrected me on this list but
the Debian Weekly News mustn't have seen his post.

I was going to ask DWN to mention this mistake in the next issue
but I figured anyone involved with the Hurd would know the deal.

Should I ask DWN for a correction?

Ciaran O'Riordan

On Sat, Aug 16, 2003 at 01:53:24AM +0200, Marcus Brinkmann wrote:
> On Fri, Aug 15, 2003 at 06:06:25PM -0400, Shawn Boyette wrote:
> > This is almost farsical,
> > announcing a switch to a new kernel architecture (which, I might add,
> > is already deprecated by its developers -- Pistachio is the current
> > branch of L4Ka, not Hazelnut) before the previous new kernel
> > architecture (OSKit) migration is even completed.
>
> We never considered Hazelnut to be a platform for the Hurd, it is way too
> limited for that. Not sure where you got it from that Hazelnut is a target.
> Our is Pistachio.

Kent West

unread,
Aug 16, 2003, 1:50:14 PM8/16/03
to
Hurd Advocate wrote:

> Okay maybe more than two words, but how would you try to convey the
>excitement of the Hurd in a sentance? When I first started using Linux
>and people asked me why, I said something like, "If it breaks, I can
>fix it!". Summing up for the Hurd it might be something like, "It'll
>be free -- even tomorrow!" But that seems at least a little bit
>boring. So what catch-phrase would you use to explain why you use the
>Hurd (and why they should too)? And I want to hear from you lurkers
>out there as well as the regulars.
>
>

"Tomorrow's OS"

--
Kent

deFreese, Barry

unread,
Aug 16, 2003, 2:30:18 PM8/16/03
to
> -----Original Message-----
> From: Hurd Advocate [mailto:hurd_a...@yahoo.com]
> Sent: Saturday, August 16, 2003 9:55 AM
> To: debia...@lists.debian.org
> Subject: Hurd Advocacy -- two words or less
>
>
> Okay maybe more than two words, but how would you try to convey the
> excitement of the Hurd in a sentence? When I first started
> using Linux
> and people asked me why, I said something like, "If it breaks, I can
> fix it!". Summing up for the Hurd it might be something like, "It'll
> be free -- even tomorrow!" But that seems at least a little bit
> boring. So what catch-phrase would you use to explain why you use the
> Hurd (and why they should too)? And I want to hear from you lurkers
> out there as well as the regulars.
>
>
> The Hurd Advocate
>

I'll sum up mine.

Because it's different/unique and I find it intriguing.


Barry deFreese
Technology Services Manager
Nike Team Sports
(949)-616-4005
Barry.d...@nike.com

--
"Technology doesn't make you less stupid; it just makes you stupid faster."
Jerry Gregoire - Former CIO at Dell

--

Wolfgang Jaehrling

unread,
Aug 16, 2003, 7:40:08 PM8/16/03
to
On Sat, Aug 16, 2003 at 09:55:03AM -0700, Hurd Advocate wrote:
> Okay maybe more than two words, but how would you try to convey the
> excitement of the Hurd in a sentance?

Maybe "login and get stoned"? Or "2 GB should be enough for anybody"?
Ok, seriously, here is my preferred description of the essence of the
Hurd:

"The GNU Hurd - giving freedom to users!"

As this applies to both the technological and non-technological
aspects of the Hurd, I find this very nice. I also came up with "it
lacks TCPA drivers", which is slighly self-ironic (bad driver support)
and indicates that we consider freedom to be highly important
(anti-TCPA).

Cheers,
GNU/Wolfgang

--
"A good programming language should have features that make the kind
of people who use the phrase `software engineering' shake their heads
disapprovingly." -- Paul Graham

Wolfgang Jaehrling

unread,
Aug 16, 2003, 7:40:07 PM8/16/03
to
On Fri, Aug 15, 2003 at 01:31:37PM -0700, Hurd Advocate wrote:
> - Do we suffer from a lack of charasmatic leadership and direction?

If there is anything that the Hurd does _not_ lack, then it is
direction. It seems to me that it actually has too much direction. :)

> - Is advertising our problem? Do we not get enough exposure to
> potential developers?

The advertising has been improved significantly in the last couple of
years. But we need to continue being active in this area. We need to
give talks, distribute flyers (I started some work on this a while ago
and will finish it this or next year), talk to people at conferences,
write articles for magazines and web sites, etc. As Paul Graham
noted, people will not listen to you when they see that you are there;
they will listen to you when they see that you are _still_ there. I
think we've been around long enough now that people start to believe
that the Hurd actually is a project worth developing, so I'd expect
the problem of having too few developers to become smaller and
smaller. However, we should make it as easy as possible for people to
make an initial contribution, because if someone has made something
once, it's very likely that the person will do it again (a concept
also used by drug dealers, the church and many others). Maybe asking
people who are merely interested in the Hurd (e.g. on IRC) for advice
or about their opinions on implementation or design details could help
here.

When we tell people about the Hurd, we should not waste time with
telling them about technological details or things which are unusual
about the Hurd. Someone who is interested will figure these things
out anyway. Instead, we need to tell people about advantages. This
means that to promote the Hurd, one needs to know not only *how*
things are done, but *why* things are done this way, so probably one
needs to know a lot about the Hurd before being able to effectively
promote it. A danger that needs to be avoided is that people can
easiely get the impression that the Hurd is hard to learn when you
tell them what is different about it (as opposed to saying what its
advantages are). Remember, people are lazy and want to reuse their
existing knowledge; so always mention that the Hurd is not only very
flexible, but also very _compatible_. (I think the Fresco people have
the problem that their project looks too different.)

I could go on for hours about this...

Alfred M. Szmidt

unread,
Aug 17, 2003, 6:50:06 AM8/17/03
to
This applies to anyone participating in this stupid thread--including
me. And yes, it is flameish, but frankly I'm fed up with all this
whinning.

What can the Hurd community do to promote their favorite OS?

We can hack and not waste our time on useless discussions about "what
we think we might do in some far away land". Find something that
annoys you in the Hurd and fix it instead!

I really can't figure out what has changed since 1991 when Linus put
up a copy of linux-0.1 for people to play with. Nobody whined about
"Oh, but I need sound! Its not fun hacking without sound, so I won't
touch this", instead they _did_ the decent thing and that was to
shutup and add sound support. Do people really have such selective
memories that they think that Linux had all the bells and whistles
that it does today once it was first released? Or that things just
"get done" by some imaginary ghost? Please...

Heck, we even have half the road paved by those who did actually write
sound drivers, network drivers and what not. They didn't have the
luxury of having working drivers, or specs that are freely avaiable
(and specs are still sometimes hard to get) like we do. Sure, you
can't just copy and paste the code and have it working (in some cases
you can actually), but half the grunt work is already done.

Now someone will say that "OS design is complex", who ever asked
anyone to design an operating system from scratch? That work is
already done. Don't like kernel hacking? Hack the Hurd then, thats
just a bunch of user-space programs and libraries; nothing strange
there. Can't code at all? Fine, report bugs, write documentation,
lots of things can be done without writting a single line of code.

So please, stop complaning that this and that doesn't work. Instead
do what will benefit everyone, and fix the things that annoy you.

n e d

unread,
Aug 17, 2003, 8:20:09 AM8/17/03
to
Wolfgang Jaehrling disait (le 17/08/03 à 01:57) :

> On Sat, Aug 16, 2003 at 09:55:03AM -0700, Hurd Advocate wrote:
> > Okay maybe more than two words, but how would you try to convey the
> > excitement of the Hurd in a sentance?

i like

* "free, even tomorrow"
* "giving freedom"
* "it lacks TCPA drivers"

but also something like :

* "modular, multi-headed, de-centralized"

--
... dans dix ans, "sarkozy" sera le nom d'un syndrôme ...

Mark Wilkinson

unread,
Aug 17, 2003, 12:40:04 PM8/17/03
to
Hurd Advocate wrote:

> What can the Hurd community do to promote their favorite OS?
>

> It seems like the Hurd doesn't really have a critical mass of
>users to spur the growth we'd all like to see. So I was wondering what
>everyone thought was the best way to attract more developers/users to
>the Hurd. The reason I initially looked into the hurd is the BitKeeper
>fiasco. I found it unpalatable for free software to be beholden to a
>proprietary master. I thought it would't hurt to look at the
>alternatives. And I came across the Hurd. From what I could initially
>find out, it seemed like it had interesting and modern architecture,
>one
>which could solve the "Linus doesn't scale" problem more cleanly than
>the BitKeeper solution. (And here I'm assuming that things like
>userspace device drivers and the fact that any part of the system can
>theoretically be replaced on the fly really does solve that problem).
>I
>was, of course, also attracted just because it was something new and
>different. So I wonder what attracts everyone else to the Hurd. To
>that end here are a couple of questions I have.
>
>- Is there any killer-app for the Hurd (available now or in the future)
> that we think will bring the masses in? Or phrased a different way,
> is there any one feature that people would be willing to think about
> converting over for.
> translators?
> distributed OS?
> better security model?
> more customizable? (is that a word?)
>
>
No killer app as such, people just want to be able to use the hardware
that comes with their machine, and mostly perform everyday tasks.
You're more likely to work on something you can use, and without
printing, sound, CD/DVD-RW support and a browser/mail/office suite,
HURD's only going to appeal to a very limited subset of people.

>- Are hardware compatibility problems more of a problem for newbies, or
> is it the lack of software which stifles adoption. (And for the
> record, I think the killer-app would be Linux and the Hurd running
> side by side on top of the same micro-kernel. That would make
> migration easier, since you could still have access to your important
> hardware and software that hadn't been ported over yet)
>
>
A mixture of the two (see above for my points on software) but hardware
compatibility issues will always be a problem with a fledgeling O/S that
doesn't have hardware manufacturer support. All you can do is try to
write some kind of hardware/software interaction layer that would make
driver writing as easy as possible. And most importantly, document it.

>- Is it hard to attract developers because the project is too complex.
> Instead of just learning one system, you have to learn about two: the
> hurd and mach. And who would want to learn about mach when it's
> scheduled for removal whenever the L4 kernel gets traction (3-5 years
> out?)? Or is it the "multi- threaded servers are hard to debug"
> problem still.
>
>

If the decision has been made to go to L4, IMHO work should have halted
on Mach. Forgive my ignorance, but why is L4 3-5 years away? If the
decision has been made to move to a kernel structure that doesn't exist
yet, that strikes me as an *interesting* decision.


>- Is a lack of documentation the real hard thing for new developers to
> overcome?
>
>
It's one of many challenges for the newcomer, yes.

>- Are we nice enough to newbs? (I tend to think so, but there was a
> little hissy-fit about change-log colon-placement for hello.c on
> bug-hurd last month)
>
>

Speaking as one, I think so :) see below for my only other comments on
that...

>- Do we suffer from a lack of charasmatic leadership and direction?
>

I've occasionally noticed posts on this list that could have been
phrased more politely, a little more encouragement for newbies/casual
contributors would probably help them become regular contributors.

>
>- Is there any one thing which could be fixed to attact a lot more
>users?
> PPP?
> sound?
> USB?
> GNOME?
> journaled file system?
> OpenOffice?
>
>

I think the following things are essential for people to want to get
involved:
X-Windows & some kind of Window Manager (fluxbox or whatever)
Networking - a browser and mail program (it's essential to have the
ability to send/recieve e-mail and browse the web)
Printing - CUPS or whatever, anything so long as it works. I appreciate
that this really needs USB working for most modern printers
Stability - What people really want, is for the very basic
infrastructure to be solid and reliable. If it falls over twice a day,
people are going to get frustrated very quickly. It's the old chicken
and egg thing, if no-one is using it then no bugs will get reported, but
no-one wants to use something that is percieved as unstable.

Sound would be a nicety rather than an essential, as someone else
responded 'it's better to hack with sounds'

>- Is advertising our problem? Do we not get enough exposure to

> potential developers? (And here I'm thinking CS undergrads) I'm
> thinking that a new developer could have a lot more influence on the
> design of the Hurd (since it's still in flux) than say a more mature
> project like Linux or FreeBSD.
>
>

I only ever found out about HURD because of a two page article in Linux
Format, I hadn't heard of it before that, and outside of here I haven't
heard it since.

>- Does anyone think that companies like RedHat or IBM might think about
> funding some summer college internships to work on something like the
> Hurd?
>
I suspect not, the companies mentioned have put an awful lot of
marketing and R&D spend into Linux, and even then IBM only really bought
in when Linux had gotten stable on its own. This is a shame, but most
large organisations aren't particularly philanthropic.

>
>- Is there any future development that might drive people to the Hurd?
> Like the SCO garbage or DRM binaries/signatures in the Linux kernel?
>
I can't tell, but having no commercial pressures really is a blessing
that shouldn't be underestimated.

>
>- Is our installation proceedure/Debian system overly obtuse?
>
>
Tried it, failed, have been waiting for CD images to re-appear and an
empty weekend before I try again. See, I'm such a newbie I haven't even
got HURD running yet! And I've been reading this list for months...

>- Are we always destined to play catch up with Linux? (eventhough we
>had
> a headstart?)
>
>

No, just until we have the fundamentals of filesystem, hardware support,
stability sorted out, then we should be able to build quickly and take
account of what's already happened with Linux to influence how we
approach problems. We could easily come out ahead.

>Anyways, I'd like to hear your thoughts.
>
>

>The Hurd Advocate
>
>
>
This is just a view from someone who currently considers themselves
'outside' of the project but looks in regularly. I really want the HURD
to succeed, I hope this feedback doesn't come across as negative, and I
look forward to reporting successful HURD installation any weekend soon. :)

Mark

Patrick Strasser

unread,
Aug 17, 2003, 7:00:14 PM8/17/03
to
Hurd Advocate wrote:
> I
> was, of course, also attracted just because it was something new and
> different. So I wonder what attracts everyone else to the Hurd.

Thinking about it, I was searching for different operating systems, and
I found the Hurd interesting because it was not that "omplete" and
finished as Linux. It looked like great things might happen in the future.

> - Is there any killer-app for the Hurd (available now or in the future)
> that we think will bring the masses in? Or phrased a different way,
> is there any one feature that people would be willing to think about
> converting over for.
> translators?

I was thinking about a SMB/CIFS translator for quite a while. Samba 3.0
seems to have new libraries that reduce glue code to a minimum. The
translator could present something like a "network neighbourhood". This
could be set up in a single line and demonstrate capabilities, aside
from being just great use.

> distributed OS?

Somthing like openMosix-enabled Knoppix would be just about the limit
;-) Ok, That won't happen in the Near Future...

> - Are hardware compatibility problems more of a problem for newbies, or
> is it the lack of software which stifles adoption.

Real users won't be getting happy with GNUMach. No active driver
development is don, so you better get supported hardware. Software is no
problem -> Debian.

How do maintainers react on patches for the Hurd? I there any direction
noticalbe? Do poeple know about the Hurd and it's idiosyncrasies?

> - Is it hard to attract developers because the project is too complex.
> Instead of just learning one system, you have to learn about two: the
> hurd and mach. And who would want to learn about mach when it's
> scheduled for removal whenever the L4 kernel gets traction (3-5 years
> out?)? Or is it the "multi- threaded servers are hard to debug"
> problem still.

I don't think people find it too complex. Of course at a first glimpse
one could have the impression to see something complex, but I found out
where to draw lines, and seperate things that are orthogonal or have
good defined and used interfaces.
If you tell people that the whole thing consist of a microkernel, which
has a lot of servers running on top of it, but that there exist two
microkernels you can use and a third that is comming soon, and that you
should know about IPC (which you could or could not explain to people)
and that you need a seperate compiler to process your interface
definition, then reading all this will be the last thing before they
tell anyone that the Hurd will never come near to anything that a normal
human can understand.

> - Is a lack of documentation the real hard thing for new developers to
> overcome?

In deed. And I like to read documentation in pdf. Others like it in info.

> - Do we suffer from a lack of charasmatic leadership and direction?

Just to have on leader leads us to Linux (nice alliteration :-) ). Of
course you can't say A is our new leader or the man for this and that.
You'd rather give them titles when it makes sense (our X-expert, the
Mach-expert, the networking-expert). more structure would be nice.

> - Is there any one thing which could be fixed to attact a lot more
> users?

I don't see a point in attracting non-developer users to the Hurd. It's
not production stable, not polihed in any way. So I see this as a wishlist.

> sound?

As this system is work in progress luxuries are rare. I think sound is a
sign of matureness and available time for followings one's pleasure.

> USB?

New hardware is more and more USB-enabled. Here the driver-problem comes
in. AFAIK no hardware driver has bee written for GNUMach. And noone
expects one to be ever written. That lack probaly won't be fixed.

> OpenOffice?

Luxury. Users want a stable system in first place.

> - Is advertising our problem? Do we not get enough exposure to
> potential developers? (And here I'm thinking CS undergrads) I'm
> thinking that a new developer could have a lot more influence on the
> design of the Hurd (since it's still in flux) than say a more mature
> project like Linux or FreeBSD.

Often I saw Hurders react than rather act. When I talk to people to find
out what they think about the Hurd, I often get back some vague
scepticalness.
Image is the problem. People think to know what to think about the Hurd,
but don't have good information at hand. User-reports are rare on the
outer world.

> - Is our installation proceedure/Debian system overly obtuse?

Debians biggest problem _is_ installation IMHO.

> - Are we always destined to play catch up with Linux? (eventhough we
> had
> a headstart?)

It's an image thing. Allways comparing the Hurd to Linux is suicidal.
The Hurd is different.

Regarding stability:
I expect to see people hop on the train when the Hurd is more stable.
Features are not the problem. But noone wants to use a system that has
lots of features that work only 95% ot the time (Although most people
do... ;-> )
If installation of ssh takes some steps of carefull handcraft and have a
day, the dropout rate is naturally high.
"You are at the third gate. The gatekeeper tells you to go down the
whole hill to the house of the whitch, sing her a nice tune and dance
and ask for the Secret Word. Then you can come back. Maybe he will let
you in then."

Regarding release:
I don't think a fast release will do any good. We have snapshots that
work well and are widely available. People should be pointed at those.

Regarding Chicken & Egg:
A lot has been said about the chicken-egg-problem. Nothing will happen
while there are always the same number of chicken and eggs. Other things
have to be done to increase the number of active developers and tester,
this will not happen by itself. What about a "Hurd advocacy task force"
that activley tries to attract new people?


Another thing that somtimes puzzles me: What is the role of RMS in the
Hurd? I sometimes read posts about features or releases anounced by RMS,
which noone on the lists has ever heard of. Lot's of people keep an eye
of what RMS says.

Patrick

--
Engineers motto: cheap, good, fast: choose any two
Patrick Strasser <pstrasser at sbox dot tugraz dot at>
Student of Telematik, Techn. University Graz, Austria

Niels Möller

unread,
Aug 18, 2003, 7:10:10 AM8/18/03
to
Patrick Strasser <pa...@sbox.tugraz.at> writes:

> I was thinking about a SMB/CIFS translator for quite a while. Samba
> 3.0 seems to have new libraries that reduce glue code to a minimum.
> The translator could present something like a "network neighbourhood".
> This could be set up in a single line and demonstrate capabilities,
> aside from being just great use.

That would be a nice excellent example. I don't use samba much, but
last time I installed smbfs om linux, the documentation said that the
samba developers considered smbfs an ugly and unsupported hack. An smb
translator could probably avoid the problems they saw in smbfs.

Regards,
/Niels

Marcus Brinkmann

unread,
Aug 18, 2003, 10:30:10 AM8/18/03
to
On Mon, Aug 18, 2003 at 12:37:05AM +0200, Patrick Strasser wrote:
> How do maintainers react on patches for the Hurd? I there any direction
> noticalbe? Do poeple know about the Hurd and it's idiosyncrasies?

Most often they are accepted without hassle. Usually this is because the
Hurd is pretty POSIX compatible, and the bugs fix problems with the source
code to make it run on more POSIX systems.

Sometimes we have issues, because the Hurd makes some drastic decisions.
For example, we don't define a global PATH_MAX, and some maintainers believe
that this is ridiculous :) But for every maintainer like this there is also
a maintainer who is very happy to see the patch, or even does some
non-trivial amount of work to help us to get there.



> >- Is a lack of documentation the real hard thing for new developers to
> > overcome?
>
> In deed. And I like to read documentation in pdf. Others like it in info.

You can convert texinfo manuals into pdf, though.

> Regarding stability:
> I expect to see people hop on the train when the Hurd is more stable.
> Features are not the problem. But noone wants to use a system that has
> lots of features that work only 95% ot the time (Although most people
> do... ;-> )

I agree a lot. This is why I was working bugs and crashes for a very long
time before I even considered working on Hurd projects like translators or
design issues. I got a lot of bugs fixed, even if that required nagging
Roland more often than I could provide a fix myself.

More people who actually try things and learn how to use gdb to figure out
why it crashes are always helpful.

> Regarding Chicken & Egg:
> A lot has been said about the chicken-egg-problem. Nothing will happen
> while there are always the same number of chicken and eggs. Other things
> have to be done to increase the number of active developers and tester,
> this will not happen by itself. What about a "Hurd advocacy task force"
> that activley tries to attract new people?

Mmh. Some advocacy is good, but it can also be counterproductive. If the
advocacy makes promises that the active developers can not fulfill, people
will get a bad impression. So I would rather see advocacy done by people
who are also, at least in a minimal way, active, for example in helping with
installation problems, bug finding etc.

> Another thing that somtimes puzzles me: What is the role of RMS in the
> Hurd? I sometimes read posts about features or releases anounced by RMS,
> which noone on the lists has ever heard of. Lot's of people keep an eye
> of what RMS says.

RMS is our spiritual guide. He never wrote a line of code for the Hurd, but
he has given input on the design in many stages of the Hurd. The FSF has
employed people to work on the Hurd in the past, and I think it could happen
again. The post about the release was taken out of context and wildly
exaggerated. I think that RMS maybe was on the edge of giving up on the Hurd,
but we were able to demonstrate that the Hurd is somewhat working as a
prototype and is worth working on and supporting.

Thanks,
Marcus

John Goerzen

unread,
Aug 18, 2003, 10:40:07 AM8/18/03
to
OK, I think I can comment here, as I'm someone that's used Linux for years
and has periodically looked into Hurd.

Here are major concerns from this end:

1. Basics like filesystems >2GB need to be fixed pronto. The limitation
is under-documented and is serious these days.

2. The installer is rather buggy and misleading (even refers to Linux
in several places). Debian GNU/Hurd needs an installer of at least
the quality of Debian GNU/Linux.

3. The post-installer .sh script is also rather buggy, and should
not be necessary at all given dpkg/apt-get. It's also under-documented.

4. Hardware support. 'Nuff said.

5. X.

One note: I've heard people ragging on the Hurd's performance. I personally
don't care much about that at this stage. I want something I can install,
tinker with, discover all the cool things about it, and actually use. I
understand if it's slow for now.

On Fri, Aug 15, 2003 at 01:31:37PM -0700, Hurd Advocate wrote:
>
> What can the Hurd community do to promote their favorite OS?
>
> It seems like the Hurd doesn't really have a critical mass of
> users to spur the growth we'd all like to see. So I was wondering what
> everyone thought was the best way to attract more developers/users to
> the Hurd. The reason I initially looked into the hurd is the BitKeeper
> fiasco. I found it unpalatable for free software to be beholden to a
> proprietary master. I thought it would't hurt to look at the
> alternatives. And I came across the Hurd. From what I could initially
> find out, it seemed like it had interesting and modern architecture,
> one
> which could solve the "Linus doesn't scale" problem more cleanly than
> the BitKeeper solution. (And here I'm assuming that things like
> userspace device drivers and the fact that any part of the system can
> theoretically be replaced on the fly really does solve that problem).

> I
> was, of course, also attracted just because it was something new and

> different. So I wonder what attracts everyone else to the Hurd. To
> that end here are a couple of questions I have.
>

> - Is there any killer-app for the Hurd (available now or in the future)
> that we think will bring the masses in? Or phrased a different way,
> is there any one feature that people would be willing to think about
> converting over for.
> translators?

> distributed OS?
> better security model?
> more customizable? (is that a word?)
>

> - Are hardware compatibility problems more of a problem for newbies, or

> is it the lack of software which stifles adoption. (And for the
> record, I think the killer-app would be Linux and the Hurd running
> side by side on top of the same micro-kernel. That would make
> migration easier, since you could still have access to your important
> hardware and software that hadn't been ported over yet)
>

> - Is it hard to attract developers because the project is too complex.
> Instead of just learning one system, you have to learn about two: the
> hurd and mach. And who would want to learn about mach when it's
> scheduled for removal whenever the L4 kernel gets traction (3-5 years
> out?)? Or is it the "multi- threaded servers are hard to debug"
> problem still.
>

> - Is a lack of documentation the real hard thing for new developers to
> overcome?
>

> - Are we nice enough to newbs? (I tend to think so, but there was a
> little hissy-fit about change-log colon-placement for hello.c on
> bug-hurd last month)
>

> - Do we suffer from a lack of charasmatic leadership and direction?
>

> - Is there any one thing which could be fixed to attact a lot more
> users?

> PPP?
> sound?
> USB?
> GNOME?
> journaled file system?
> OpenOffice?
>

> - Is advertising our problem? Do we not get enough exposure to
> potential developers? (And here I'm thinking CS undergrads) I'm
> thinking that a new developer could have a lot more influence on the
> design of the Hurd (since it's still in flux) than say a more mature
> project like Linux or FreeBSD.
>

> - Does anyone think that companies like RedHat or IBM might think about
> funding some summer college internships to work on something like the
> Hurd?
>

> - Is there any future development that might drive people to the Hurd?
> Like the SCO garbage or DRM binaries/signatures in the Linux kernel?
>

> - Is our installation proceedure/Debian system overly obtuse?
>

> - Are we always destined to play catch up with Linux? (eventhough we
> had
> a headstart?)
>

> Anyways, I'd like to hear your thoughts.
>
>
> The Hurd Advocate
>

> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com
>
>

Marcus Brinkmann

unread,
Aug 18, 2003, 10:40:10 AM8/18/03
to
On Sun, Aug 17, 2003 at 05:27:32PM +0100, Mark Wilkinson wrote:
> If the decision has been made to go to L4, IMHO work should have halted
> on Mach.

People have halted on Mach long before L4 even entered the picture.

> Forgive my ignorance, but why is L4 3-5 years away?

L4 was released a month ago or so. But it is not a drop in replacement for
Mach.

> If the
> decision has been made to move to a kernel structure that doesn't exist
> yet, that strikes me as an *interesting* decision.

The L4 kernel is truly minimal. The Hurd depends on a couple of features in
Mach that simply don't exist in L4. The three core issues:

* Device drivers
* Virtual memory management
* A capability based IPC system

L4 does not have any device drivers. Some people are working on a new
device driver infrastructure for GNU Hurd/L4, and drivers for that
infrastructure. It's a huge task, but it is also an interesting challenge.
Device drivers will be in user space and thus can be multi-threaded. This
allows to keep state about a device active in the thread, and can greatly
simplify a driver.

L4 does not have any Virtual memory management, just some primitives to
recursively map pages into other address spaces. The physical memory is
provided directly to the user space. So we have to implement a VM system.
Neal has some great and ambitious ideas about doing VM management locally in
every task, instead of a global server. This is a dramatic departure from
traditional OS design (even from Mach and the Hurd as it is now), and thus
needs to be fleshed out from scratch (there are some academic papers on it,
but I don't know of a production system doing it this way).

L4 provides a minimal IPC system, that allows direct thread-to-thread
message sending. But it only gives a single protection primitive. So it is
not usable for a user space multi server system as the Hurd, where untrusted
communication is happen on a frequent basis. This is why a more featureful
capability system is needed. Instead doing it in a central global server
(like the port system in Mach is centralized), we want, again, do it locally
in each task. This seems to be a new design to me, and I have worked on the
protocols and data srtuctures for that in the last weeks. I am currently
working on an implementation, which is needed very early in any porting
effort to L4.

So you see, it is not about L4, but about glueing Hurd to L4. Mach did a
lot of things for us that L4 is not doing, and we take the chance to try to
more consequently implement the Hurd's fundamental design ideas. Freedom to
the users! Freedom to map your physical memory as you want it, freedom to
use the IPC policy you want, and the freedom to have functional device
drivers without getting them approved by a kernel master geek ;)

Thanks,
Marcus

Alfred M. Szmidt

unread,
Aug 18, 2003, 11:40:08 AM8/18/03
to
Would you like to work on any of these?

Farid Hajji

unread,
Aug 18, 2003, 11:50:20 AM8/18/03
to
Marcus Brinkmann wrote:
> So you see, it is not about L4, but about glueing Hurd to L4. Mach did a
> lot of things for us that L4 is not doing, and we take the chance to try to
> more consequently implement the Hurd's fundamental design ideas. Freedom to
> the users! Freedom to map your physical memory as you want it, freedom to
> use the IPC policy you want, and the freedom to have functional device
> drivers without getting them approved by a kernel master geek ;)

L4 also provides for user-space scheduling, besides the standard
in-kernel scheduler. Putting the scheduling policy out of the
kernel opens up new interesting possibilities, like, perhaps
real-time threads and better support for SMP systems as well.

As Marcus said, it's all about freedom. And it's fun too!

--
Farid Hajji. http://www.farid-hajji.net/address.html

deFreese, Barry

unread,
Aug 18, 2003, 12:20:15 PM8/18/03
to
> -----Original Message-----
> From: Alfred M. Szmidt [mailto:a...@kemisten.nu]
> Sent: Monday, August 18, 2003 8:18 AM
> To: jgoe...@complete.org
> Cc: hurd_a...@yahoo.com; debia...@lists.debian.org
> Subject: Re: Hurd Advocacy?
>
>
> Would you like to work on any of these?
>

Yes.. ;-)

Barry deFreese
Technology Services Manager
Nike Team Sports
(949)-616-4005
Barry.d...@nike.com

--
"Technology doesn't make you less stupid; it just makes you stupid faster."
Jerry Gregoire - Former CIO at Dell

--

Marcus Brinkmann

unread,
Aug 18, 2003, 1:00:21 PM8/18/03
to
On Mon, Aug 18, 2003 at 05:38:33PM +0200, Farid Hajji wrote:
> Marcus Brinkmann wrote:
> > So you see, it is not about L4, but about glueing Hurd to L4. Mach did a
> > lot of things for us that L4 is not doing, and we take the chance to try to
> > more consequently implement the Hurd's fundamental design ideas. Freedom to
> > the users! Freedom to map your physical memory as you want it, freedom to
> > use the IPC policy you want, and the freedom to have functional device
> > drivers without getting them approved by a kernel master geek ;)
>
> L4 also provides for user-space scheduling, besides the standard
> in-kernel scheduler. Putting the scheduling policy out of the
> kernel opens up new interesting possibilities, like, perhaps
> real-time threads and better support for SMP systems as well.

Yeah, but it is not at all obvious to me how to do this, and happily, the
Hurd itself doesn't need real time. We will use some of the scheduling
interfaces in the device driver, in particular preemption control for
interrupt handlers. As about SMP support, we certainly want to do that, but
it will not be possible to do it at a local level like memory. Neal gave
the heuristic argument to me at Oslo. He said, to paraphrase him, that all
memory pages are equal (ie it doesn't matter which page you get), but all
time slices are not. In particular, it does indeed matter if you get the
next, let's say, one million time slices, or if you get only one and then
have to wait a bit until everybody else got a chance to run, and that one
million times. Also, time is consumed and then useless to anybody else,
while access to memory can be revoked temporarily without too much problems
(there is still the issue of caching etc, but it's controllable).

The choice of the processor to run on is also not free for the user, because
that would open the system to DoS attacks. For example, let's say you run
an important task on processor A. Then N users tasks can cooperate in that
they all choose to run on processor A.

So although the scheduling parameters in L4 are interesting, and will make
it possible to provide exciting user level features like real time, it is
still entirely open how this could be done "the Hurd way". ;)

Thanks,
Marcus

deFreese, Barry

unread,
Aug 18, 2003, 1:10:12 PM8/18/03
to
> > L4 also provides for user-space scheduling, besides the standard
> > in-kernel scheduler. Putting the scheduling policy out of the
> > kernel opens up new interesting possibilities, like, perhaps
> > real-time threads and better support for SMP systems as well.
>
> The choice of the processor to run on is also not free for
> the user, because
> that would open the system to DoS attacks. For example,
> let's say you run
> an important task on processor A. Then N users tasks can
> cooperate in that
> they all choose to run on processor A.
>
> So although the scheduling parameters in L4 are interesting,
> and will make
> it possible to provide exciting user level features like real
> time, it is
> still entirely open how this could be done "the Hurd way". ;)
>
> Thanks,
> Marcus
>
> --
> `Rhubarb is no Egyptian god.' GNU http://www.gnu.org
> mar...@gnu.org
> Marcus Brinkmann The Hurd
http://www.gnu.org/software/hurd/
Marcus.B...@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/


Speaking of SMP. If (when?) we shoot for SMP support would we shoot for
processor affinity or leave it up to the scheduler like in Linux?

Thanks,

Barry deFreese
Technology Services Manager
Nike Team Sports
(949)-616-4005
Barry.d...@nike.com

--
"Technology doesn't make you less stupid; it just makes you stupid faster."
Jerry Gregoire - Former CIO at Dell

--

Marcus Brinkmann

unread,
Aug 18, 2003, 1:20:13 PM8/18/03
to
On Mon, Aug 18, 2003 at 10:01:40AM -0700, deFreese, Barry wrote:
> Speaking of SMP. If (when?) we shoot for SMP support would we shoot for
> processor affinity or leave it up to the scheduler like in Linux?

Rapidly getting off topic, but as a general rule of thumb we want all the
great features that you'd expect from a modern OS.

Thanks,
Marcus

Farid Hajji

unread,
Aug 18, 2003, 3:00:19 PM8/18/03
to
> > L4 also provides for user-space scheduling, besides the standard
> > in-kernel scheduler. Putting the scheduling policy out of the
> > kernel opens up new interesting possibilities, like, perhaps
> > real-time threads and better support for SMP systems as well.
>
> Yeah, but it is not at all obvious to me how to do this, and happily, the
> Hurd itself doesn't need real time. We will use some of the scheduling
> interfaces in the device driver, in particular preemption control for
> interrupt handlers.

Ack.

The obvious application is when you run multiple OS servers on top of
L4 in parallel, each one with its own scheduler. Say, we could run a
BSD server with a BSD-like user-level scheduler, a Linux server with
its own scheduler, and multiple Hurd servers, which could be allocated
CPU time slices from a Hurd schedule-server. All user-level
schedulers will of course have to be derived from a higher-level
scheduler or the in-kernel scheduler of L4 itself.

I'm just speculating here, so please don't take this to the letter:

In Hurd/L4, some servers can't have the same scheduling requirements.
As you've pointed out, a device driver task which contains drivers
that poll interfaces would run at a different priority than a "normal"
translator or user-level task. In monolithic kernels, drivers are
often being scheduled implicitely through ISR calls (when hardware
interrupts the CPU or a timer expires). This means that the drivers
run at highest priority, bypassing the regular scheduler. In Hurd/L4,
with separate driver tasks, we must ensure that interrupts are being
delivered _and_ _quickly_ accepted by interrupt threads in the driver
task(s). Those threads may (and probably will) need to run at higher
priority than the rest of the (Hurd) gang. The interrupt-threads could
run on a higher-priority L4 queue, but that would be dangerous,
because L4 ensures strict order scheduling [if a higher-priority
thread livelocks, all threads running at normal priority will never
again have a chance to run]. So we'll have to do our own scheduling,
so as not to lock up the system.

Anyway, this is getting technical, and we should probably discuss
this on l4-hurd@ rather than in this advocacy thread.

> As about SMP support, we certainly want to do that, but
> it will not be possible to do it at a local level like memory. Neal gave
> the heuristic argument to me at Oslo. He said, to paraphrase him, that all
> memory pages are equal (ie it doesn't matter which page you get), but all
> time slices are not. In particular, it does indeed matter if you get the
> next, let's say, one million time slices, or if you get only one and then
> have to wait a bit until everybody else got a chance to run, and that one
> million times. Also, time is consumed and then useless to anybody else,
> while access to memory can be revoked temporarily without too much problems
> (there is still the issue of caching etc, but it's controllable).

Yes, I think I understand what Neal means here. Although very
different, similar issues arise in FreeBSD 5.x KSEs. But I admit that
I don't yet fully understand what's going on there.

> The choice of the processor to run on is also not free for the user, because
> that would open the system to DoS attacks. For example, let's say you run
> an important task on processor A. Then N users tasks can cooperate in that
> they all choose to run on processor A.

Ensuring fairness in the use of the available CPUs is a typical scheduling
problem, which would be dealt with by in-kernel or user-level scheduler.
Mach had processor sets to which you could assign threads, and Mach
switched CPUs in the processor set according to its own internal scheduler.
So it's nothing new, it just pops up again in different cloths (or APIs).

> So although the scheduling parameters in L4 are interesting, and will make
> it possible to provide exciting user level features like real time, it is
> still entirely open how this could be done "the Hurd way". ;)

Yes, absolutely. I guess that we will have to experiment with real code,
once we have some drivers to work on. From what we observe, we may then
come up with a more Hurd-ish solution.

Thanks,

-Farid.

Timothy Rue

unread,
Aug 18, 2003, 6:50:10 PM8/18/03
to
On 18-Aug-03 08:57:36 Marcus Brinkmann <Marcus.B...@ruhr-uni-bochum.de> wrote:

[snip]


>The L4 kernel is truly minimal. The Hurd depends on a couple of features in
>Mach that simply don't exist in L4. The three core issues:

>* Device drivers
>* Virtual memory management
>* A capability based IPC system

[snipped - see thread for interesting info]

>So you see, it is not about L4, but about glueing Hurd to L4. Mach did a
>lot of things for us that L4 is not doing, and we take the chance to try to
>more consequently implement the Hurd's fundamental design ideas. Freedom to
>the users! Freedom to map your physical memory as you want it, freedom to
>use the IPC policy you want, and the freedom to have functional device
>drivers without getting them approved by a kernel master geek ;)

On the advocacy issue it is the above which is a good part of the reasons
I'm watching two OS development projects. The Hurd of course being one of
them, and by far the larger. The other, and to use the analogy of a smart
terminal vs. dumb terminal... the other is the Amiga clone project AROS
which besides being targeted to be a standalone, is currently running
hosted on Linux. But I think the two (The Hurd and AROS) can make for an
interesting pair running together. AROS of course running in user space of
the Hurd but like a smart terminal it can be used alone. The IPC of Amiga
(and clone) has been standard (though not with full use of the three basic
communications of IPC) and it is thru this IPC that I believe AROS can tap
into the larger application and other functionality of the GNU base. It
has been determined that Amiga/AROS is such a trade off of functionality
that memory protection is to difficult to do within, but externally
there are possibilities. Device drivers are another thing that is always
an issue with new OSs....

Ok, why use an OS on top of an OS? It's simply a matter of the user not
really needing to deal with all the multi-user based security along with
the ability of "taking with you" the "smart terminal" on something small
like a business card CD or memory stick, etc.. that you can customize your
own personal interface smart terminal and plug it into the GNU
functionality when and perhaps where you need the larger base of such.

the Hurd in my eyes is higher on the priority list than AROS, but to be
able to use and take with me such a smart terminal..... well that is
something the Hurd makes possible.


---
*3 S.E.A.S - Virtual Interaction Configuration (VIC) - VISION OF VISIONS!*
*~ ~ ~ Advancing How we Perceive and Use the Tool of Computers!*
Timothy Rue What's *DONE* in all we do? *AI PK OI IP OP SF IQ ID KE*
Email @ mailto:tim...@mindspring.com >INPUT->(Processing)->OUTPUT>v
Web @ http://threeseas.net ^<--------<----9----<--------<

Farid Hajji

unread,
Aug 18, 2003, 8:10:10 PM8/18/03
to
> On the advocacy issue it is the above which is a good part of the reasons
> I'm watching two OS development projects. The Hurd of course being one of
> them, and by far the larger. The other, and to use the analogy of a smart
> terminal vs. dumb terminal... the other is the Amiga clone project AROS
> which besides being targeted to be a standalone, is currently running
> hosted on Linux. But I think the two (The Hurd and AROS) can make for an
> interesting pair running together.
[snip]

The Hurd's project's objectives can be seen from two perspectives:
1. being technically superior, innovative, bleeding-edge, ...
2. being popular among mainstream (Linux?-)users.

This is similar to BSDs vs. Linux. Both are excellent projects and I
like using both kinds of OSes. Both are also excellent cultures, which
cross-polineate each other, and personally I feel pretty much at home
in both. However, they are not the same and their objectives are quite
different. They are both very strong open source (or free software)
representatives, but their approaches differ somewhat. While BSDs focus
more on technicalities (and have a culture of their own), Linux
has a broader user-base with more diverse interests. Sure, both
projects contribute greatly to open source and free software, but
they do so from different directions.

The Hurd, being work-in-progress, needs developers (and users to
test and help spread the word) from both camps. We need kernel hackers
which are paying very close attention to architectural issues, because
the Hurd needs a redesign, not only to adapt it to L4, but also to
get rid of some crippling assumptions which have been made in the past,
before we learned more on OS design and implementation. OTOH, we also
need innovative grass-roots developers, who are ready to jump in and
contribute new ideas and code in a Linux-like manner.

We've got a pretty good contact to L4 developers at l4ka.org as well.
While the Hurd has been a long time in limbo, we now have a very good
potential to use the experiences learned from Hurd/Mach to create a
new and much better version of the Hurd (here: Hurd/L4) which could
even be quite uKernel independent (the Holy Grail of OS design...).
Now would be a really good time to jump in. The complete infrastructure
is finally in place (L4Ka::Pistachio, IDL4 compiler, a device framework
from DROPS or e.g. Ne