Hurd Advocacy?
Hurd Advocate
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
> What can the Hurd community do to promote their favorite OS?
> 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
> 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?
>
> users?
> PPP?
> sound?
> USB?
> GNOME?
> journaled file system?
> OpenOffice?
>
> 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?
>
>
> had
> a headstart?)
>
>
>
> 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
> 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
> 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
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
> 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
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
> 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
> 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
> 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
> 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
> 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
>> 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
> 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
asubedi
>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
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
>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
> >===== 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
--
`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/
Barry deFreese
>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
> 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
--
`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/
Robert Millan
> 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.
> >
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
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.
Ognyan Kulev
> 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
> 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
> "- 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
--
`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/
Marco Gerards
> 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
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
> Should I ask DWN for a correction?
It's not important.
Ciaran O'Riordan
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
> 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
> 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
> 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.
>
>
>
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
> 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
> - 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
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
> 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
> 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
> 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
> 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
> 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
--
`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/
John Goerzen
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
> 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
--
`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/
Alfred M. Szmidt
Farid Hajji
> 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
> 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
> 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
--
`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/
deFreese, Barry
> > 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 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
> 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
--
`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/
Farid Hajji
> > 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.
--
Farid Hajji. http://www.farid-hajji.net/address.html
Timothy Rue
[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
> 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.
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. NetBSD sources, ...) to build the framework on which
a new Hurd could be build upon.
To attract talented developers (from both camps), we need
* a useable development environment: We have that, thanks to
debian-hurd, and Phil for the CDs.
* a modern microkernel that is at the bleeding edge of kernel
design. Mach is somewhat antiquated and if you look at HotOS
conferences, you'll know what I mean. OTOH L4 is being actively
developed, and many papers are being written on it right now.
The Hurd/L4 challenge will help a great deal to attract serious
hackers who are willing to test their skills against a truly
innovative OS/uKernel architecture combo.
* developers of user-space applications, distributions etc...,
which would port applications to the Hurd, extend the Hurd
by writing more translators, device drivers, ... People with
this set of skills are probably most represented in the Linux
community and I'm confident that we'll find enough hackers who
are willing to help (in addition to those already working on
debian-hurd).
The Hurd, and especially Hurd/L4 are both very stimulating
challenges. Everyone is invited to participate in the redesign
and implementation of Hurd/L4. You don't need to be a kernel
guru to start working on the project.
All you need to contribute to the core development, is code
reading skills. See "Code Reading: The open source perspective"
by Diomidis Spinellis. Then dig in Hurd sources and play around.
It is really fun to write a translator that generates a file system
on-the-fly using Hurd libraries. The more you dig in the Hurd,
the easier it will be to really appreciate what needs to be done
in the Hurd/L4 port.
If you're interested in contributing code to Hurd/L4, please consider
subscribing to the l4-...@gnu.org mailing list.
P.S.: As far as AROS is concerned: Did you have a look at NetBSD,
including their amiga port? Actually, I personally think that one
way to refactor the Hurd would be to do some kind of NetBSD/L4
port (or partial port) first and then use as much as possible from
NetBSD's very clean architecture (MD vs. MI code, drivers, ...)
as framework for the Hurd/L4.
Regards,
-Farid.
--
Farid Hajji. http://www.farid-hajji.net/address.html
Dave
> and has periodically looked into Hurd.
>
> Here are major concerns from this end:
I only have one thing to add, and that's that the Hurd needs a lawsuit from SCO.
;)
Marcus Brinkmann
> > 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:
> [snip]
>
> I only have one thing to add, and that's that the Hurd needs a lawsuit from SCO.
>
> ;)
Actually, this is an interesting point, as the FSF has long warned that the
copyright situation of Linux is so that it is difficult to defend the Linux
source code in court. This is why the FSF is so careful about requiering
copyright assignments and proper changelogs in the GNU project.
Chance is that no company would ever dare to claim that GNU code was taken
from them without a license unless it is really true, and in that case it
can be tracked down to the person who did that. This is also true for the
GNU Hurd.
SCO has realized that this is not true for Linux, and thus saw a chance to
take advantage of it. I think that SCO has correctly identified one of the
main weaknesses of Linux, and it should be a warning to any high profile
free software project.
Note also that the problem here is not the GPL, it is the lack of code
maintenance (proper history records) and copyright assignments. The GPL has
been defended successfully in the past (and that this has not happened in
a court, but outside of it, is a further prove that it is a strong license).
It has even been defended for the Linux source code, but in such cases the
origin of the Linux source code was not disputed, only the consequences for
a mix of Linux code and proprietary code.
I would still not want to be sued by SCO. It's a big hassle, and even the
threat of such a suit can be an effective tool to get a better deal in
negotiations. You have to choose your fights carefully.
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/
Daniel Sieger
[snip]
> including their amiga port? Actually, I personally think that one
> way to refactor the Hurd would be to do some kind of NetBSD/L4
> port (or partial port) first and then use as much as possible from
> NetBSD's very clean architecture (MD vs. MI code, drivers, ...)
> as framework for the Hurd/L4.
I don't know how it is actually with the Hurd, but such a policy of
clean architecture and preference of a correct implementation in
contrast to a early release or fast implementation is something I really
would like to see. IMHO, to state out this policy clearly and keeping it
in mind while coding and making design decisions would be a nice step
into the right direction. Just a small sentence like "It is developed
with the goal of a clean design, architecture and correct implementation
in mind" or something like that on the Hurd Web pages would be very
fine, I think. But, of course, I'm actually not really in the position
to judge to what extend you already do this, or how far away it is from
reality. It might also have some positive effects on how the Hurd is
actually seen in public and by interested people or developers. Just my 2c.
Greetings,
Daniel.
Farid Hajji
> > including their amiga port? Actually, I personally think that one
> > way to refactor the Hurd would be to do some kind of NetBSD/L4
> > port (or partial port) first and then use as much as possible from
> > NetBSD's very clean architecture (MD vs. MI code, drivers, ...)
> > as framework for the Hurd/L4.
>
> clean architecture and preference of a correct implementation in
> contrast to a early release or fast implementation is something I really
> would like to see. IMHO, to state out this policy clearly and keeping it
> in mind while coding and making design decisions would be a nice step
> into the right direction. Just a small sentence like "It is developed
> with the goal of a clean design, architecture and correct implementation
> in mind" or something like that on the Hurd Web pages would be very
> fine, I think. But, of course, I'm actually not really in the position
> to judge to what extend you already do this, or how far away it is from
> reality. It might also have some positive effects on how the Hurd is
> actually seen in public and by interested people or developers. Just my 2c.
We'll discuss this on l4-hurd. We're way off topic already :)
--
Farid Hajji. http://www.farid-hajji.net/address.html
PUYDT Julien
> 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.
1. Who works on that infrastructure?
2.a) Is there some draft text to read about design ideas?
2.b) Where is this draft?
JP
Marco Gerards
[...]
> 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).
How about NUMA? AFAIK it matter a lot for NUMA systems which page a
task gets. And will we support NUMA? (I'm sorry if this is a bit off-topic).
Thanks,
Marco
Marcus Brinkmann
> Le lun 18/08/2003 à 15:57, Marcus Brinkmann a écrit :
> > 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.
>
> 1. Who works on that infrastructure?
You should talk to Peter 'p2' De Schrijver <p...@mind.be> if you are
interested in helping.
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/
Timothy Rue
>me wrote:
>> 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.
:) &
3. User Space Freedom.
>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,..... [snips only to shorten response]
>... Sure, both projects contribute greatly to open source and free
>software, but they do so from different directions.
Not sure I follow you here. There is no "this vs. that" in what I'm on
about, there is only what can be done in the user space freedom, that
I'm .... advocating the Hurd.
>The Hurd, being work-in-progress, needs developers (and users to
>test and help spread the word) from both camps...... [snip] we also
>need innovative grass-roots developers, who are ready to jump in and
>contribute new ideas and code in a Linux-like manner.
The needing of developers is something even AROS needs, but spreading the
word about each to the other and beyond is what I've been doing, more so
spreading word about the Hurd in the larger scope of the "amiga like"
land. Telling Hurd development efforts about such things as AROS and the
V.I.C. tends to get wrongly preceived and results in a "don't distract us
from our development focus with what others are doing" and oddly enough I
understand the why of this error, and I'm even OK with it.... as long as
the development direction of the Hurd is staying on such a course that
will be technically supportive of these other efforts, when it is ready.
Again, my advocating the Hurd is in regards to what can be done in it's
user space. While pointing out that in a multi-user system there are
security issues that must be delt with. And the Hurd has to deal with
them, though the target is to remove the false constraints imposed upon
the user. Dealing with security issues of a multi-user system does
add code overhead, in comparison to a single user personal system. And
there are often tradeoffs in what is and is not part of an OS. If you do
not need multi-user security and are willing to give up real memory
protection then you can make a much smaller and faster OS that inherently
has no user access constraints.
The best of both worlds combined, not just one on top of the other, but
plugin integrated so to share resources, via user space freedom and IPC.
There may seem to be some redundancy here from a very general perspective,
but user freedom does go beyond removing false constraints in user space.
Ease of use contributes to improving user freedoms but even more important
is the ease of which the user can put things/functionality together, for
themselves. There are alot of resources, already built functionality,
created under the GPL and such. No physical reason why such resources/
functionality can't be presented to the users in a manner that allows the
user to easily put things/functionality together, for themselves and as
they see fit.
I say "physical" here meaning "Physics", but it's becomming more and more
apparent that there are often other reasons to create and/or maintain
false constraints. Job Security is one. Making people need you by
preventing them from easily (within the scope of their available
resources of time and knowledge) doing something without you (MS knows
this quite well.)
GNU/Hurd provides increased user freedoms in the scope and security of a
multi-user system while having access to a huge resource base of
functionality/applications. It has alot of overhead in comparison to the
needs of a single user personal system, a difference the user does have
to deal with, even though their focus is only in regards to doing stuff
in their user space. IE, file access and protection bits/flags. It's nice
to be able to see what you can of what all is out there in the "world",
but the only thing relevant to the user doing things is what they have
access to. It can be, and often is, extra work complexity, to determine
the difference between what you can see an what you can actually use, or
understanding in what ways you are allowed to use it. But to be using a
system within the user space, that has only what the user can actually
use, available to them.... (this does not exclude the ability of the user
to step outside of such a system to see what they may, from within their
user space of the Hurd).
A single user system is generally easier to use than a multi-user system
in very inherent ways. But the multi-user system of GNU has far more user
available resources than a typical single user system.
Who said we can't have our cake and eat it too?
And this is not the tool set for allowing the user to more easily put
things together for themselves, but only creating an environment that
inherently provides support for it, extending user freedom potential.
The tool set is around the corner and platform independant, but IPC is the
third user interface (CLI and GUI being the first two) that allows
"putting things together".
In sum:
Functioning resources fromthe "commons" available thru the security and
stability of a multi-user system, accessable in user space by the user
and thru a user friendly OS (smart terminal) where the available
functioning resoures can be integrated and controlled by the user, as
they see fit, without the concern of dealing with multi-user system
security issues.
Instead of a this OS vs. that OS it is a "this OS that inherently
provides these benefits (resources, security and stability) to this other
OS that inherently provides these (ease of use and ease of integration of
available resources, or putting things togeher) additional benefits.
>We've got a pretty good contact to L4 developers at l4ka.org as well.
>..... [snip]....... The complete infrastructure
>is finally in place (L4Ka::Pistachio, IDL4 compiler, a device framework
>from DROPS or e.g. NetBSD sources, ...) to build the framework on which
>a new Hurd could be build upon.
>To attract talented developers (from both camps), we need
*.... [snip].....
> * developers of user-space applications, distributions etc...,
> which would port applications to the Hurd, extend the Hurd
> by writing more translators, device drivers, ... People with
> this set of skills are probably most represented in the Linux
> community and I'm confident that we'll find enough hackers who
> are willing to help (in addition to those already working on
> debian-hurd).
.....[snip]....
>If you're interested in contributing code to Hurd/L4, please consider
>subscribing to the l4-...@gnu.org mailing list.
I may subscribe, probably will (is there a non-subscriber web based
archive I might use for monitoring the list?), but will pass the info
along to the AROS effort, that some may at least monitor the hurd L4
development that it may influence decissions they make with AROS
development. Especially as it relates to *running as a user-space*
*application on the Hurd*.
>P.S.: As far as AROS is concerned: Did you have a look at NetBSD,
>including their amiga port? Actually, I personally think that one
>way to refactor the Hurd would be to do some kind of NetBSD/L4
>port (or partial port) first and then use as much as possible from
>NetBSD's very clean architecture (MD vs. MI code, drivers, ...)
>as framework for the Hurd/L4.
FYI (To correct and clairfy your understanding of AmigaOS related works)
AmigaOS(TM) is only being ported to the PPC w/bios dongle.
(release uncertain)
The AmigaOS has a curse on it, which has been identified to be rooted in
its Intellectual Property Rights. All who become legally involved in its
IP or rely on it are hurt by it. (the apex example of why proprietary is
a bad thing, with a long list of those hurt and being hurt by the curse)
UAE (a GPL'd Amiga Emulator) is probably what you are refering to, but it
too requires proprietary Amiga ROM kernel images (*at this time - see
below *.)
MorphOS is an Amiga like clone, made free to Genesis Pegasos PPC hardware
owners as a default OS, but proprietary (closed source). May have Amiga
IP issues (Amiga curse).
Amithlon - was a popular mostly proprietary Amiga(tm) emulator that
required Amiga ROM Kernal Images. It was distroyed by the curse.
* AROS is a clean, from scratch, ground up portable clone of AmigaOS3.1
(starting target - to evolve beyond that). Its license is based on the
MOZILLA PUBLIC LICENSE Version 1.1. Because of its disconnection from the
Amiga IP curse, it is being considered as a replacment of the Amiga ROM
images used by UAE, which in turn would provide AROS with an emulator
able to run original (classic) Amiga third party applications "without
being recompiled to run natively on AROS". aros.sourceforge.net
(BTW - like the Hurd, AROS is also being ported to PPC)
-------
I hope I have clairified the difference between the values of a multi-user
system and a personal single user system enough that you can see the user
freedom advantages in connecting them. I also hope I've clairified any
faulty perception about what AROS is. That on the hurd, or otherwise
connected to the Hurd (via internet shell account) AROS would be
considered a user space application or smart terminal (depending on were
and how it is run.) External to the Hurd hardware, as smart terminal, it
would also help to reduce it's (and the users) load on the Hurd. At least
until people figure out how much functionality resources are available to
them to integrate and find a need to, as they see fit...)
When people better understand the potential of the Hurd, they will realize
the value of including a common end user accessible IPC side door to
applications, function libraries and devices, such that one can access
the functionality of such without having to access its CLI/GUI. Making it
commonly possible for the end user to put functionality together while
accessing the functionality from a smart terminal, perhaps remotely,
which may have it's own user definable GUI system for such integration.
Correct me if I'm wrong, but isn't this functionality accessability what
translators are all about? Not to mention the "server" nature of the hurd
to "serve functionality"....;)
How secure would something like AROS be, when running on the Hurd?
As secure as a user space directory on the hurd can be made to be, and
this might additionally mean the mounting of a USB micro ramdrive device
(car keys), a business card size CD (credit card) or other such device
(analogy). Security is handled by the Hurd and user possession of device.
As to being connected to the hurd as a smart terminal, that too, is a Hurd
security matter.
Hmmm, I wonder if you could use the hurd to set up a functionaly access
rental system???? (not that I'm interested, only looking at what is
possible)
---
Timothy Rue
Email @ mailto:tim...@mindspring.com
Web @ http://threeseas.net
Virtual Interaction Configuration (V.I.C.)
http://freshmeat.net/projects/victor1
Farid Hajji
> > > 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.
> >
> > 1. Who works on that infrastructure?
>
> You should talk to Peter 'p2' De Schrijver <p...@mind.be> if you are
> interested in helping.
Please Cc: l4-...@gnu.org as well.
--
Farid Hajji. http://www.farid-hajji.net/address.html
Farid Hajji
> There may seem to be some redundancy here from a very general perspective,
> but user freedom does go beyond removing false constraints in user space.
> Ease of use contributes to improving user freedoms but even more important
> is the ease of which the user can put things/functionality together, for
> themselves. There are alot of resources, already built functionality,
> created under the GPL and such. No physical reason why such resources/
> functionality can't be presented to the users in a manner that allows the
> user to easily put things/functionality together, for themselves and as
> they see fit.
The Hurd is one possible architecture which gives users the freedom
to implement and use their own semantics. Say, you want a special
kind of filesystem with custom ACLs etc.., all mounted on a
subdirectory of $HOME? No problem: Write or modify an FS translator
and you're set. You want to use an alternative network stack because
you're not happy with pfinet? No problem: Write your own and hook it
up in the global tree. You can do this even on a multi-user machine,
without being root. That much freedom is unthinkable in current
monolithic systems.
The Hurd is also about stability. Say, you want to write or test
a new device driver. In Linux or BSDs, you'd probably use kernel
modules. In the Hurd (once we've completed the transition to Hurd/L4
with drivers running as user-level tasks), all you need to do is
start a new device driver server in userland (we'll discuss
details on l4-hurd@). If there's a bug in a Linux or BSD kernel
module, you'll panic() the system. A bug in a user-land Hurd
device driver would simply cause that driver task to be terminated.
You get a much more stable system this way.
The Hurd has also potential for some kind of virtual machine.
Because it runs on top of a microkernel (like Mach now, L4 in
the future), it doesn't hog the hardware alone, but must access
it through a layer of abstraction (the microkernel). This is the
key to virtual machine architectures like IBM's S/390 and similar
OSs of parallel machines. The Hurd can run in parallel with other
OS servers simultaneously. Nothing prevents you from running
the Hurd, some sub-Hurds and e.g. Lites (an early BSD OS-Server)
at the same time on top of Mach. Some resources still have to be
synchronized, but that is not a show-stopper here.
The Hurd has very high potential for portability, as soon as
we get Hurd/L4 rolling. L4Ka::Pistachio already runs on multiple
CPU architectures (see http://l4ka.org/) and a port of Hurd/L4/x86
to, say, Hurd/L4/ppc, Hurd/L4/ia64, etc... is mainly a matter of
porting glibc and a very tiny amount of glue code. We don't have
to care of L4's internals if we don't have the resources to
do it: The L4 community is doing an excellent job at this.
> A single user system is generally easier to use than a multi-user system
> in very inherent ways. But the multi-user system of GNU has far more user
> available resources than a typical single user system.
Ack.
> The tool set is around the corner and platform independant, but IPC is the
> third user interface (CLI and GUI being the first two) that allows
> "putting things together".
My bogometer just triggered :-)
OS design is still complex engineering task. In the future, users may
be able to drag and drop modules, filesystems and other resources in a
nice flashy GUI environment (why not?), and they are also free to
shoot themselves in the foot. Multiple times. With a machine gun...
After all, it's all about user freedom. Nah, just kidding :-))
> >If you're interested in contributing code to Hurd/L4, please consider
> >subscribing to the l4-...@gnu.org mailing list.
>
> I may subscribe, probably will (is there a non-subscriber web based
> archive I might use for monitoring the list?), but will pass the info
> along to the AROS effort, that some may at least monitor the hurd L4
> development that it may influence decissions they make with AROS
> development. Especially as it relates to *running as a user-space*
> *application on the Hurd*.
http://mail.gnu.org/archive/html/l4-hurd/
Sure, AROS could one day run on top of Mach or L4, and coexist
peacefully with the Hurd on the same box. It may also run inside
the Hurd as a task (or set of tasks). You're welcome and encouraged
to put AROS on top of a microkernel (I'd really recommend
L4Ka::Pistachio for this) instead of the bare metal.
> >P.S.: As far as AROS is concerned: Did you have a look at NetBSD,
> >including their amiga port? Actually, I personally think that one
> >way to refactor the Hurd would be to do some kind of NetBSD/L4
> >port (or partial port) first and then use as much as possible from
> >NetBSD's very clean architecture (MD vs. MI code, drivers, ...)
> >as framework for the Hurd/L4.
>
> FYI (To correct and clairfy your understanding of AmigaOS related works)
>
> AmigaOS(TM) is only being ported to the PPC w/bios dongle.
> (release uncertain)
>
> The AmigaOS has a curse on it, which has been identified to be rooted in
> its Intellectual Property Rights. All who become legally involved in its
> IP or rely on it are hurt by it. (the apex example of why proprietary is
> a bad thing, with a long list of those hurt and being hurt by the curse)
>
> UAE (a GPL'd Amiga Emulator) is probably what you are refering to, but it
> too requires proprietary Amiga ROM kernel images (*at this time - see
> below *.)
No, I'm not referring to UAE or any other emulator, but to the port
of NetBSD to Amiga:
Current: http://www.netbsd.org/Ports/amiga/
Future : http://www.netbsd.org/Ports/amigappc/
This is NetBSD on an Amiga. AROS is AmigaOS clone.
Sure, that's absolutely different, but both projects
could cross-polineate as well :)
> * AROS is a clean, from scratch, ground up portable clone of AmigaOS3.1
> (starting target - to evolve beyond that). Its license is based on the
> MOZILLA PUBLIC LICENSE Version 1.1. Because of its disconnection from the
> Amiga IP curse, it is being considered as a replacment of the Amiga ROM
> images used by UAE, which in turn would provide AROS with an emulator
> able to run original (classic) Amiga third party applications "without
> being recompiled to run natively on AROS". aros.sourceforge.net
> (BTW - like the Hurd, AROS is also being ported to PPC)
> How secure would something like AROS be, when running on the Hurd?
How do you define "secure"?
--
Farid Hajji. http://www.farid-hajji.net/address.html
Timothy Rue
>[Timothy Rue]
>> There may seem to be some redundancy here from a very general perspective,
>> but user freedom does go beyond removing false constraints in user space.
>> Ease of use contributes to improving user freedoms but even more important
>> is the ease of which the user can put things/functionality together, for
>> themselves. There are alot of resources, already built functionality,
>> created under the GPL and such. No physical reason why such resources/
>> functionality can't be presented to the users in a manner that allows the
>> user to easily put things/functionality together, for themselves and as
>> they see fit.
>The Hurd is one possible architecture...
[snip - see thread for what I refering to]
I have no problems with anything you have written above (snip included).
It's all supportive of using a smart terminal OS in user space. No need
for each user to have to re-invent their own user space smart terminals
when something such as AROS can be used, hosted on the Hurd for the
advantages the Hurd provides, but also runnable independant or remote
from the Hurd.
>> A single user system is generally easier to use than a multi-user system
>> in very inherent ways. But the multi-user system of GNU has far more user
>> available resources than a typical single user system.
>Ack.
to which part or all?
>> The tool set is around the corner and platform independant, but IPC is the
>> third user interface (CLI and GUI being the first two) that allows
>> "putting things together".
>My bogometer just triggered :-)
>OS design is still complex engineering task. In the future, users may
>be able to drag and drop modules, filesystems and other resources in a
>nice flashy GUI environment (why not?), and they are also free to
>shoot themselves in the foot. Multiple times. With a machine gun...
>After all, it's all about user freedom. Nah, just kidding :-))
Be very careful how you treat the users, least you be preceived as an
arrogant fool if not also ignorant. And that would result in less
effective advocacy from you, for the hurd..
As things have been, the users have only been given two of the three
primary colors and additionally limited tools for those two colors, to
paint a picture. Why should anyone be supprised that all they see comming
from the users efforts look so bland, problematic and limited?
Like I said, I see the job security issue, just as such Roman numeral
"expertise" was there to stall out for 300 hundred years the integration
of the much easier and power hindu-arabic decimal system, so are there
those today who persist in preventing the needed changes in computing
that will provide the users with all three primary colors along with the
simple tool set that will allow them to better grasp the know how and do
with putting things together.
But the fundamental act of programming is to create automation of
complexity, which is made of simpler automations, in order to make the
complexity easy to use and reuse, by the user. A fundamental act that is
very recursive on multipule levels all the way up from the kernel to how a
user makes repetitive use in what they do, that given the tools to
automate what they recognize is repetitve enough for them to automate.
they will. And just like how GNU is built a small part at a time, so will
the resource base of available dynamic automations of complexity even
further expand the use of the GPL.
Just as the replacement of the Roman Numeral system by the Hindu-Arabic
decimal system allowed more to do more, including the experts that weren't
afraid to go into new territory, so shall providing the user with the full
three primary set of user interfaces and the simple (relatively speaking)
automation tools to put things together for themselves, more will get
done, including what the "experts" get done, who aren't afraid to go into
new automation territory.
Thru the Roman Numeral system usage, it would not have been possible to
invent computers, And that's not just the aspect of the Roman Numeral
system not have the all important "0". But in the advanced math needed to
create the machinery, for which the roman numeral system simply wasn't
capable of calculating.
Likewise, the fiction of a computer running a starship or even allowing a
child to program a complex holodeck like program, given todays programming
methology and elitism of expertise, these levels of programming will not
be reachable.
Of course it's important that we have the system designed with enough user
freedom and resources to allow such a change to happen.....
>> >If you're interested in contributing code to Hurd/L4, please consider
>> >subscribing to the l4-...@gnu.org mailing list.
>>
>> I may subscribe, probably will (is there a non-subscriber web based
>> archive I might use for monitoring the list?), but will pass the info
>> along to the AROS effort, that some may at least monitor the hurd L4
>> development that it may influence decissions they make with AROS
>> development. Especially as it relates to *running as a user-space*
>> *application on the Hurd*.
>http://mail.gnu.org/archive/html/l4-hurd/
Thanks.
>Sure, AROS could one day run on top of Mach or L4, and coexist
>peacefully with the Hurd on the same box. It may also run inside
>the Hurd as a task (or set of tasks). You're welcome and encouraged
>to put AROS on top of a microkernel (I'd really recommend
>L4Ka::Pistachio for this) instead of the bare metal.
I'm not the development party to do such a task, but as a matter of FYI,
MorphOS (closed source PPC Amiga Clone) does run on a microkernel and has
such future plans or roadmap that the Hurd with AROS (what I've been on
about) can actually achieve sooner and as non-proprietary.
[snip]
>No, I'm not referring to UAE or any other emulator, but to the port
>of NetBSD to Amiga:
> Current: http://www.netbsd.org/Ports/amiga/
> Future : http://www.netbsd.org/Ports/amigappc/
>This is NetBSD on an Amiga. AROS is AmigaOS clone.
>Sure, that's absolutely different, but both projects
>could cross-polineate as well :)
My mistake. But in this line of porting to the Amiga, there has long been
the Geek Gadgets project of porting GNU programs to the Amiga.
[snip]
>> How secure would something like AROS be, when running on the Hurd?
>How do you define "secure"?
Locks are for honest people, and we can break what we make.
Security as I define it is as the analogies I used of car keys and credit
cards, it is my physical possession of them that provides me with their
security. But security works both ways when dealing with a multi-user
system. Secure in the manner of preventing the user from tampering with
the functions that serve everyone as well as preventing others from
tampering with other peoples things, without permission.
---
Timothy Rue (3seas)
Email@ mailto:tim...@mindspring.com
WEB@ http://threeseas.net
VIC@ http://freshmeat.net/projects/victor1
Farid Hajji
> >> third user interface (CLI and GUI being the first two) that allows
> >> "putting things together".
>
> >be able to drag and drop modules, filesystems and other resources in a
> >nice flashy GUI environment (why not?), and they are also free to
> >shoot themselves in the foot. Multiple times. With a machine gun...
> >After all, it's all about user freedom. Nah, just kidding :-))
>
> Be very careful how you treat the users, least you be preceived as an
> arrogant fool if not also ignorant. And that would result in less
> effective advocacy from you, for the hurd..
Hey, I was joking here :) A user-friendly interface to OS resources
and management doesn't have to be limited to the Hurd. Many other
OSes could need such a thing as well.
The problem I'm having with this is very simple: You've got to
implement the basic underlying functionality before you can even
think of wrapping it in a nice GUI.
If a project decided to implement such an interface for, say, Linux,
it would be easy for them to extend it to support Hurd specific
features as well. There is nothing in the Hurd that prevents this and
in fact, I'd like to see this done. But, it is not part of the core
itself, it is an add-on application.
On a very general level, you're absolutely right: If our aim were
to attract absolute newbies (read: Windoze users), an user-friendly
and fool-proof interface to the OS is a must. If at all possible,
this interface should be optional, so as not to block access to
the regular command line interface (there's nothing worse than being
locked behind an nich flashy interface when you can't access more
powerful features).
Such an interface could run in newbie, advanced and wizard modes,
allowing less, more and absolute control over the resources that
are being managed by the user, depending on their skills level.
But let's repeat this again: it is not Hurd-specific at all.
If there is an X application which does this, let's port it :)
> Like I said, I see the job security issue, just as such Roman numeral
> "expertise" was there to stall out for 300 hundred years the integration
> of the much easier and power hindu-arabic decimal system, so are there
> those today who persist in preventing the needed changes in computing
> that will provide the users with all three primary colors along with the
> simple tool set that will allow them to better grasp the know how and do
> with putting things together.
This has nothing to do with job security. We're not getting paid
for developing open source or free software. It just happens that
this is the kind of user interface we are accustomed to and which
helps us being more productive. There's absolutely nothing that
prevents you from implementing or using a different system or
interface.
> Likewise, the fiction of a computer running a starship or even allowing a
> child to program a complex holodeck like program, given todays programming
> methology and elitism of expertise, these levels of programming will not
> be reachable.
Again, this is not Hurd-specific. Even a complex holodeck program
would still be multi-layered, with a basic OS at the bottom and
multiple layers of user-interfaces stacked on top of it.
> >> How secure would something like AROS be, when running on the Hurd?
>
> >How do you define "secure"?
>
> Locks are for honest people, and we can break what we make.
>
> Security as I define it is as the analogies I used of car keys and credit
> cards, it is my physical possession of them that provides me with their
> security. But security works both ways when dealing with a multi-user
> system. Secure in the manner of preventing the user from tampering with
> the functions that serve everyone as well as preventing others from
> tampering with other peoples things, without permission.
Security in kernelized systems is achieved through hierarchy.
The most basic level of security is implemented by the uKernel itself,
since it is the only one that accesses the bare metal hardware. The
kernel hands out resources according to a specific policy. An OS
that runs on top takes care of creating compartimentized (virtualized)
environments in which applications can run, without interfering with
each other.
The Hurd provides the same security protection that other POSIX systems,
including Linux, BSD, etc... If AROS runs as a user-level application
in the Hurd, it will be as secure as other user-level applications.
If it runs as a task (or set of tasks) directly on top of the microkernel
(Mach, L4, ...), it will be even more isolated from other tasks, including
Hurd tasks.
> Timothy Rue (3seas)
> Email@ mailto:tim...@mindspring.com
> WEB@ http://threeseas.net
> VIC@ http://freshmeat.net/projects/victor1
--
Farid Hajji. http://www.farid-hajji.net/address.html
Farid Hajji
> copyright situation of Linux is so that it is difficult to defend the Linux
> source code in court. This is why the FSF is so careful about requiering
> copyright assignments and proper changelogs in the GNU project.
SCO vs. FSF: http://www.theregister.co.uk/content/4/32393.html
--
Farid Hajji. http://www.farid-hajji.net/address.html
Marcus Brinkmann
> The Hurd provides the same security protection that other POSIX systems,
> including Linux, BSD, etc... If AROS runs as a user-level application
> in the Hurd, it will be as secure as other user-level applications.
> If it runs as a task (or set of tasks) directly on top of the microkernel
> (Mach, L4, ...), it will be even more isolated from other tasks, including
> Hurd tasks.
There are a couple of issues though you have to be aware of if you want to
do that. First of all, Mach is open to all sorts of DoS attacks. L4 isn't,
because all "global" effects are wrapped in system calls which require
privileges (ie, only the root task can call them). So the root task becomes
the aribter on such privileged operations. Of course we will have a generic
rootserver that allwos you to do that. The only other thing that you then
must be aware of is the DoS attack of bombarding other (server) threads with
messages (which they will reject of course). There is a feature in L4
(redirector) that can be used to prevent that, but it causes an overhead on
every IPC from that thread you use it for. Still you might have to use a
global redirector task in the system that controls which task is allowed to
send messages to which other tasks (or subsystem, if that's a feature you
want to have), for ultimate security.
This thread is not off-topic, but on the wrong list :)
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/
Farid Hajji
> > including Linux, BSD, etc... If AROS runs as a user-level application
> > in the Hurd, it will be as secure as other user-level applications.
> > If it runs as a task (or set of tasks) directly on top of the microkernel
> > (Mach, L4, ...), it will be even more isolated from other tasks, including
> > Hurd tasks.
>
> There are a couple of issues though you have to be aware of if you want to
> do that. First of all, Mach is open to all sorts of DoS attacks. L4 isn't,
> because all "global" effects are wrapped in system calls which require
> privileges (ie, only the root task can call them). So the root task becomes
> the aribter on such privileged operations. Of course we will have a generic
> rootserver that allwos you to do that. The only other thing that you then
> must be aware of is the DoS attack of bombarding other (server) threads with
> messages (which they will reject of course). There is a feature in L4
> (redirector) that can be used to prevent that, but it causes an overhead on
> every IPC from that thread you use it for. Still you might have to use a
> global redirector task in the system that controls which task is allowed to
> send messages to which other tasks (or subsystem, if that's a feature you
> want to have), for ultimate security.
Ummm... right. :-)
--
Farid Hajji. http://www.farid-hajji.net/address.html
Richard Smedley
> > Actually, this is an interesting point, as the FSF has long warned that the
> > copyright situation of Linux is so that it is difficult to defend the Linux
> > source code in court. This is why the FSF is so careful about requiering
> > copyright assignments and proper changelogs in the GNU project.
>SCO vs. FSF: http://www.theregister.co.uk/content/4/32393.html
Eben has written more about this here:
http://www.linuxuser.co.uk/articles/issue32/lud32-Managing_after_SCO.html
Which followed on from:
http://www.linuxuser.co.uk/articles/lud_special-free_software_matters.html
- Richard
--
Richard Smedley
http://www.linuxuser.co.uk/
The GNU/Linux magazine for IT decision makers
``The public have an insatiable curiosity to know everything.
Except what is worth knowing. Journalism, conscious of this,
and having tradesman-like habits, supplies their demands.''
-- Oscar Wilde
This email message may contain privileged or confidential information. The information is intended for the use of the individual or entity named above. If you are not the intended recipient, you are hereby notified that disclosure, copying, distribution or the taking of action in reliance on the contents of this electronic information is strictly prohibited. If you have received this email in error, please notify postm...@livepublishing.co.uk immediately via reply email. Any personal content in this email is that of the individual author and should not be interpreted as being endorsed by the company in whole or in part. Whilst care is taken, it is the responsibility of the recipient to ensure that this email is free from virus infection, and no responsibility is accepted by Live Publishing Group for any disruption, loss or damage arising from its receipt or use.
Marcus Brinkmann
> How about NUMA? AFAIK it matter a lot for NUMA systems which page a
> task gets. And will we support NUMA? (I'm sorry if this is a bit off-topic).
Even in NUMA you have classes of homogenous memory, and within a single
class all pages are the same. How to handle several classes of such memory
is an interesting problem, and would certainly have to be handled by
privileged system code to prevent DoS attacks or unfair treatment. But it
is orthogonal to the problems of how to manage sharing the memory resources
within a uniform memory.
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/
Timothy Rue
>> >> The tool set is around the corner and platform independant, but IPC is
>> >> the third user interface (CLI and GUI being the first two) that allows
>> >> "putting things together".
>>
>> >OS design is still complex engineering task. In the future, users may
>> >be able to drag and drop modules, filesystems and other resources in a
>> >nice flashy GUI environment (why not?), and they are also free to
>> >shoot themselves in the foot. Multiple times. With a machine gun...
>> >After all, it's all about user freedom. Nah, just kidding :-))
>>
>> Be very careful how you treat the users, least you be preceived as an
>> arrogant fool if not also ignorant. And that would result in less
>> effective advocacy from you, for the hurd..
>Hey, I was joking here :) A user-friendly interface to OS resources
>and management doesn't....
[snip - see thread]
>But let's repeat this again: it is not Hurd-specific at all.
>If there is an X application which does this, let's port it :)
Sounds to me like you are playing matrix agent and injecting a
distraction. In that case Hi, some know me as Neo, not the movie
character but the real thing. Yeah, the informant is REAL.
Do I need to recap why I'm watching two OS projects, the Hurd being one?
I don't know if you think you know what the details would be or are just
injecting distraction, in regards to the general automation functionality
I have only briefly mentioned or provided analogies in reference.
I'm aware Mach makes heavy use of IPC and that L4 doesn't so much, and I'm
pleased to know that L4 effort including improving the IPC availability on
L4. But my interest in what ukernel is used ..... considering the target
of the Hurd is to be portable over ukernels...
IPC is important as it provides the support needed for the third (and
final primary of three) user interface. Virtual Memory and Device drivers
are more in teh line of resources, than the primary interface of IPC.
To continue on with the analogy of the Hindu-Arabic Numeral system. The
element of it that provided the most useful for confusing the public and
maintaining Roman Numeral expertise was the concept of zero, nothingness
having value. How can Nothing have value, what fools? ..... etc...
In the same way.... the concept of nothing having value was hard enough
for the public to grasp, the experts wanting to protect their vested
interest in their roman numeral accounting career surely only
contributed to feeding the confusion and difficulty of the public
understanding (a public that probably had less say then they do today
about what tools the accountants used) , perhaps not understanding it
well enough themselves, but they were the experts ..... at roman
numerals... not the decimal system w/zero...
In that same way, we have experts today stalling out change, out of
arrogance and/or ignorance or job security?
There is plenty vested interest in doing things the way they are being
done today, even with GNU/Linux. Slash dot had this article link to the
other day --- http://www.pbs.org/cringely/pulpit/pulpit200330814.html
And there is this too --
http://www.cnn.com/2003/TECH/ptech/08/07/software.glitches/index.html
And I'm sure there is plenty more as well as plenty more excuses in effort
to dismiss such.
But the zero, it was really quite simple and would have been far more
quickly understood for the value it is, if it just wasn't for the
distractors in positions of official control as experts in teh field of
counting and math ... Like the position coders have today.
This thread is titled "Hurd Advocacy" and I wasn't the one who started it.
If it is on the wrong list...... then why was such a thread started here?
Preaching to the believers? I was simply saying why I'm interested in the
Hurd as a matter advocacy of the Hurd.
As to the tool set of general automation, what I have said about it has
been very limited and only as an ultimate target of the why of my interest
in the Hurd. There is plenty more I could say about it, even about its
current state of development....But what is relative to this thread is
what the hurd is providing in the way of functionality and resources that
can contribute to a friendlier environment for such a tool set. The why I
advocate the Hurd.
Seek and you shall find...
----
Timothy Rue (3seas)
Email@ mailto:tim...@mindspring.com
WEB@ http://threeseas.net
VIC@ http://freshmeat.net/projects/victor1
--
Mark Wilkinson
I'd like to take your message from December 2000 (msg 149) and copy it
pretty much verbatim into HTML so:
a) It's ready for posting onto any possible Hurd 'one-stop' website
b) I can also convert it to PDF so it would be available in a format
that would print consistently whatever system setup the potential viewer
had.
I just wanted your ok before my act of shameless plagiarism :)
Thanks,
Mark
Farid Hajji
>
> I'd like to take your message from December 2000 (msg 149) and copy it
> pretty much verbatim into HTML so:
>
> a) It's ready for posting onto any possible Hurd 'one-stop' website
>
> b) I can also convert it to PDF so it would be available in a format
> that would print consistently whatever system setup the potential viewer
> had.
>
> I just wanted your ok before my act of shameless plagiarism :)
Sure, go ahead. And thanks for asking ;-)
> Thanks,
>
> Mark
--
Farid Hajji. http://www.farid-hajji.net/address.html
Alfred M. Szmidt
format that would print consistently whatever system setup the
potential viewer had.
Instead of using PDF (which cannot be edited with free software, nor
be viewd on a console), could you make it into a info page instead?
That has the nice feature that it can be viewed on _any_ system, and
that it can be converted to whatever format the user would like (ps,
pdf, info, html, etc).
Mark Wilkinson
> b) I can also convert it to PDF so it would be available in a
> format that would print consistently whatever system setup the
> potential viewer had.
>
>Instead of using PDF (which cannot be edited with free software, nor
>be viewd on a console), could you make it into a info page instead?
>
>That has the nice feature that it can be viewed on _any_ system, and
>that it can be converted to whatever format the user would like (ps,
>pdf, info, html, etc).
>
>
>
Alfred,
I'm going to use Texinfo to create the documents, and am going to
provide them in editable and non-editable formats. The reason for using
.pdf is that *nix and M$ users know what to do with a .pdf file, while
for institutions that have become M$ only over the past few years (this
certainly has started to happen in Britain) they may be unfamiliar with
info files. IMO the aim has to be to give the user something they can
use immediately without needing to be converted or modified. Naturally
I will also be providing the documentation in formats that are both
editable, and conform to open standards.
Sorry I've been so quiet over the past week or so, I've just moved back
from Northern England to the South Coast, and I'm in the process of
running around trying to get some work. Once I have an income I can
relax a little bit, it's that or lynch the landlord. :)
Mark
Timothy Rue
> b) I can also convert it to PDF so it would be available in a
> format that would print consistently whatever system setup the
> potential viewer had.
>Instead of using PDF (which cannot be edited with free software, nor
>be viewd on a console), could you make it into a info page instead?
>That has the nice feature that it can be viewed on _any_ system, and
>that it can be converted to whatever format the user would like (ps,
>pdf, info, html, etc).
What ever happened to plain ol ascii .txt format
:)
----
Timothy Rue
Email @ mailto:tim...@mindspring.com
Web @ http://threeseas.net
VIC @ http://freshmeat.net/projects/victor1
Alfred M. Szmidt
If plain text is important to you then texi documents can also be
converted to plain text, you just use the --no-headers switch.
Cheerio.