Hurd Traffic #21 For 27 Oct 1999

By Zack Brown

Do you pine for the nice days of minix-1.1, when men were men and wrote their own device drivers?
Are you without a nice project and just dying to cut your teeth on an OS you can try to modify for your needs?
Are you finding it frustrating when everything works on minix? No more all-nighters to get a nifty program working?
Then this post might be just for you :-)
 
-- Linus Torvalds, 1991

Table Of Contents

Introduction

It was nice to get some praise on the list from Marcus Brinkmann this week. He said:

I also want to use this chance to remind everyone of kernel cousins, who are writing _excellent_ summaries of the threads on this list. They are al available on:

http://kt.zork.net/debian-hurd/index.html

There are 20 issues now (congratulations and thanks a lot!), and they are worth a read for new people but also if you want to rehash particular issues. It's also a nice overview on our progress (they have some stats, too, for our number theorists :)

High praise from the project leader. Thanks a lot Marcus!! :-) :-)

Mailing List Stats For This Week

We looked at 75 posts in 196K.

There were 21 different contributors. 12 posted more than once. 10 posted last week too.

The top posters of the week were:

 

1. Stale Files Could Pollute Upgrades
14 Oct 1999 - 18 Oct 1999 (7 posts) Archive Link: "make install over the Debian package"
Topics: Apt
People: Kalle Olavi NiemitaloBrent FulghamRoland McGrathDaniel BurrowsMarcus Brinkmann

Kalle Olavi Niemitalo asked, "Is there any danger in overwriting the files of the Debian "hurd" package by doing "make install" in a Hurd build tree?" Brent Fulgham replied:

Generally this should not be a problem. However, there are a few potential pitfalls that you should be aware of:

  1. If you are installing libraries (and even executables) that are not part of the standard Debian package, the uninstall features of dselect/apt will not know to remove them. This is most likely not going to be a big issue for you (if you know how to build your own programs, you can most likely figure out what belongs and what can be removed later).
  2. If any executables or scripts installed by your new version have different interfaces (need different command line flags, etc.), this may have an impact on the ability of dselect to install or update because it will expect some set of inputs to be valid. If the program dies or does something unexpected, dselect will view it as an error and barf on you. Again, this can be worked around without much effort.

So, for an able person like yourself, I can't think of any real danger in doing a 'make install' over the running Hurd.

In his original post, Kalle added that doing a 'make install' would add profiling libraries which didn't exist in the Debian package, and which might cause problems later if a package is upgraded and the profiling libraries remain on the disk. To this, Brent replied, "I've been wondering about this myself. Since the Hurd is in such a changing state, I wonder if there is any advantage is building all of our libraries and executables with debug information present so that we can easily get useful information about a failure without first having to rebuild all the components in question."

Roland McGrath replied, "You'd sure get more and faster debugging out of me that way. But I think I am also on the high end of the scale for network throughput and disk space among people on the list. Debugging symbols do get big." Daniel Burrows suggested, "Maybe the hurd source package could build -dbg versions of the core libraries which have the debugging symbols compiled in? Eg, hurd-dbg, lib0.2-dbg, etc. I notice that there appears to be a libc6-dbg (and libglib1.2-dbg, and libstdc++2.10-dbg, and...) for the i386 port, so there is precedent :)" and Marcus Brinkmann replied, "Yes, I was planning a hurd-dbg package (not only for the libs, but also for the executables), but just did not come to it yet."

 

2. Porting The Hurd To Alphas
15 Oct 1999 - 18 Oct 1999 (5 posts) Archive Link: "Mach microkernel development - porting to Alpha"
People: Erik Verbruggen

Shaun Cloherty came into possession of a couple Alphas, and wanted to get the Hurd working on them. He figured the first step was to port gnumach, and asked if there was such a project already in progress. Goswin Brederlow recommended he check out the Fiasco Project (http://os.inf.tu-dresden.de/fiasco/) . Erik Verbruggen suggested sticking with gnumach and just porting it, pointing out that Alpha's used much the same hardware as x86 machines, and there were a lot of drivers already available for gnumach.

 

3. Boston Hurd User Group
16 Oct 1999 - 21 Oct 1999 (27 posts) Archive Link: "Easy Guide / new tarball"
People: Bill WhiteRoland McGrathJohn Tobey

In the course of discussion, it came up that John Tobey and Roland McGrath lived in Cambridge, MA, so John could go over to Roland with his computer problem. At one point, John suggested forming a Boston Hurd User Group. Marc D. Bumble liked the idea, and Bill White agreed.

Elsewhere, under the Subject: Hurd installation problem - semisolved (http://www.debian.org/Lists-Archives/debian-hurd-9910/msg00176.html) , Bill said, "There was some interest expressed in having a meeting of Hurd folk in the Boston MA area. If anyone is interested, I will try to coordinate it, though I don't have any leads about space. If the numbers are small enough we could meet in my living room, but more than 5 or 6 people would be more than its carrying capacity." Roland McGrath replied, "For a group less than several dozen, there is ample space that can be made available evenings (or weekends) at MIT. If folks would like to set up a boston-hurd mailing list to avoid bothering the pancontinental hurd community with such arrangements, one could get set up at gnu.or or at MIT (though if someone else wants to set one up, please go right ahead)."

 

4. Bad Tar File
19 Oct 1999 - 20 Oct 1999 (4 posts) Archive Link: "gnu-19991019.tar.gz"
People: Marcus BrinkmannChris Lingard

Marcus Brinkmann announced gnu-19991019.tar.gz (http://www.debian.org/~brinkmd/alpha/gnu-19991019.tar.gz) and asked for testers. Chris Lingard reported some initial success, but Marcus came back and warned him off, with, "Please leave your existing installation. the tar file is screwed. It has not the permissions and owner information from the real files. I delete it from the web immediately, and will upload a new one later."

 

5. Documentation
20 Oct 1999 - 21 Oct 1999 (6 posts) Archive Link: "documentation"
People: John TobeyPavel RoskinOKUJI Yoshinori

Someone was collecting documentation, and asked for some on learning to install and develop the Hurd. John Tobey gave some vague references ( "Instructions are somewhere on the GNU site" ), but Pavel Roskin had trouble finding them, and suggested they be added to http://www.gnu.org/software/hurd/hurd.html. OKUJI Yoshinori suggested checking out http://www.gnu.org/software/devel.html, and elsewhere gave another link, to http://www.gnu.org/software/hurd/learning-more-about-hurd.html.

 

6. httpfs; Porting 'apt'
22 Oct 1999 (3 posts) Archive Link: "ftpfs --> httpfs?"
Topics: Apt, FS: FTPFS
People: Roland McGrathBrent Fulgham

Brent Fulgham asked if anyone was working on an httpfs to go with the ftpfs, pointing out that this would greatly simplify porting 'apt' to the Hurd, because 'apt' could use the translators to make its own interface a mere matter of 'cd'ing to the proper URL. Regarding the prospects of httpfs, Roland McGrath replied, "To be sure there eventually will be. But noone is working on it, and it is not something we are planning per se. This is the kind of thing that anyone can take up and work on if they want to teach themselves the hurd, and hack freely on without risking the stability of their hurd system. There are enough other things to be done that only those of us with a lot of expert knowledge about the hurd can really do (and aren't very easy to start dabbling in for someone less experienced) that we are likely to focus on those things for the foreseeable near future."

Regarding using these methods for 'apt', he went on:

That is a nice idea, but I suspect that it is not in fact the simple way to go. There is not likely to be a whole lot of effort required to get any program that runs on linux and uses the network (sockets) in usual ways ported to the Hurd. For anyone (including Thomas and myself) it is probably easier to get such a program working in its usual ways on the Hurd than to do any substantial work on a new translator or debugging on ftpfs. This is not to say that working on translators is hard--it's just that porting most programs from linux to hurd is really quite easy.

Furthermore, there are more complex "design" kind of issues in using a hurd filesystem vs the direct uses of the network that things like apt do now. Until we have a design for giving such hurd filesystems other kinds of features they can't now have, using "plain" apt is probably in fact preferable in terms of functionality. Specifically, apt-get will show you error messages from the ftp/http server, track progress of downloads and show you estimated throughput and download times, etc. We don't currently have even a design really worked out for how an ftpfs/httpfs would deliver that kind of information to users.

 

 

 

 

 

 

We Hope You Enjoy Hurd Traffic
 

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License, version 2.0.