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
|1.||19 Feb 2000 - 21 Feb 2000||(3 posts)||NFS On The Hurd|
|2.||19 Feb 2000||(2 posts)||Hurd GNUstep Porting Effort|
|3.||21 Feb 2000 - 23 Feb 2000||(9 posts)||New Developer; Apache Patch|
|4.||22 Feb 2000||(2 posts)||Next Regular IRC Meeting|
|5.||23 Feb 2000||(2 posts)||Developer Difficulties|
|6.||23 Feb 2000 - 26 Feb 2000||(3 posts)||Username Security|
Mailing List Stats For This Week
We looked at 34 posts in 90K.
There were 23 different contributors. 7 posted more than once. 8 posted last week too.
The top posters of the week were:
1. NFS On The Hurd
19 Feb 2000 - 21 Feb 2000 (3 posts) Archive Link: "nfs on Hurd"
Topics: FS: NFS
People: Bill White
Abdul Aziz wanted to set NFS up between his Linux and Hurd boxes. He'd done
it before between two Linux systems, but he wasn't sure how the procedure
would translate. Ben Harris suggested that, for the client, Abdul should try
/hurd/nfs --help'; and Bill White added:
At one time, not so very long ago, I made the nfsd work on the Hurd. However, it was not terribly reliable. On my GNU/Linux machine I mounted my Hurd machine's root directory on /mnt/hurd, and ran something like:
find /mnt/hurd -type f | xargs sum > /dev/null
just to see how far it got. The poor nfsd hung about 1/2 way through the file system. It's not clear what this test shows, except that the nfsd has some problems. But, you can mount file systems and it will work for awhile. Unfortunately, other things got in the way, and I haven't looked at it since just before Christmastime.
As far as I know, the daemon is in the same state it was when I last looked at it.
End Of Thread.
2. Hurd GNUstep Porting Effort
19 Feb 2000 (2 posts) Archive Link: "GNUstep"
People: Roland McGrath, Lucas C. Wagner
Lucas C. Wagner badly wanted GNUstep on the Hurd, and asked what would be involved. He also offered to fund a Hurd GNUstep port. Roland McGrath replied:
As a starting place for porting, you can think of GNU/Hurd as not very different from GNU/Linux and just port the various pieces you need in straightforward ways as you would port them to any new unix-like platform. The substantial thing missing now for proceeding that way is the X server, but you can just ignore that issue by not trying to use it. That is, you can't right now easily get an X server running on your Hurd. The reasons for this are not deep or very interesting, and certainly not what I would recommend thinking about for an introduction to Hurd programming issues. The X server will run fine just as soon as someone gets around to doing the various bits of moderately dull work involved, but when it does it will just be an X server and you know what that gets you. The approach I would recommend for now is to just port GNUstep and the pieces it needs (windowmaker and whatever) that are part of the X client side, and test/debug that using another X server over the ethernet (an X terminal, your linux box, whatever). There may well be little bumps along the way in terms of smaller features the Hurd lacks, those will come out in the wash. Once you have all the pieces working as X clients like they do on GNU/Linux, then we can start thinking about places you could do things differently to take advantage of the Hurd's architecture.
The active Hurd community (such as it is) is now pretty Debian-oriented. So with anything being ported from GNU/Linux to GNU/Hurd, the path we'll recommend is starting with the debian source packages for the packages you're interested in, and getting those ported and running to the point of making a binary hurd-i386 debian package. (If you're not into debian, you can just get your porting changes into the sources and make patches available or whatever is convenient for you, and leave the debianizing to someone else. But you're not likely to get much in the way of user testing until there is a debian binary package for people to install.)
End Of Thread.
3. New Developer; Apache Patch
21 Feb 2000 - 23 Feb 2000 (9 posts) Archive Link: "Another User!"
People: Neal H Walfield, Adam Farrell
Adam Farrell made a blanket offer to help on any aspect of Hurd development. He invited everyone to email him with anything that needed doing. Neal H Walfield welcomed him aboard, gave a link to the Task List (http://www.debian.org/ports/hurd/hurd-devel-tasks) , and added, "Feel free to polish that off. Then you can check the debian bug tracking system for bugs on all of the hurd specific packages."
Adam had also announced, "BTW i created an apache patch for 1.3.11 to compile under HURD, and will email it upon request." Jens Sander screamed with delight, and wanted the patch immediately. Adam gave a link to it (ftp://ftp.unixpower.org/pub/hurd) .
4. Next Regular IRC Meeting
22 Feb 2000 (2 posts) Archive Link: "Next IRC chat... cannot transcript."
People: Adam Farrell
This was first covered in Issue #35, Section #1 (4 Feb 2000: Regular IRC Meetings For Debian Hurd) . Bodor Denis reported that he wouldn't be able to record the next regular IRC session because he'd be at CEBIT, and asked if someone else could do it and send the transcript to him. Adam Farrell offered to do it, although he hadn't heard about the chat sessions and was intrigued. There was no reply on the list.
5. Developer Difficulties
23 Feb 2000 (2 posts) Archive Link: "A stable setup"
People: Igor Khavkine, Roland McGrath
Igor Khavkine was having a terrible time doing development for the Hurd. He complained, "With my current setup it's nearly impossible to build anything. For example if I want to build gnumach, I have to run the configure script something like 3 times to make sure it doesn't fail at some point, and then running make produces a flurry of errors due to random single character changes in input files. Note these changes are not permanent since viewing the "corrupted" files does not reproduce these changes, plus they are different every time. As a result I have not even been able to rebuild gnumach, I haven't even tried to build something new." Roland McGrath replied that this was unlike any known problem he was aware of. In particular, the only data-corruption problems he'd heard of involved chunks of zero blocks, which didn't sound like what Igor was reporting. He asked Igor for some more detailed reports, but there was no reply.
6. Username Security
23 Feb 2000 - 26 Feb 2000 (3 posts) Archive Link: "Small Bug"
People: Marcus Brinkmann
Alan P. Laudicina noticed that the Hurd would not ask for a password if a user tried to log in with the wrong username. He pointed out that this helped potential crackers guess user names, which was why most systems asked for the password anyway. Marcus Brinkmann replied:
In general, security through obscurity is not sufficient as a protection strategy.
The user login name is often very exposed, for example in email addresses, log files etc. If you already have an account, you can usually just list /home to get all user names of a system.
If knowing any user name is a worthful information for an attacker, I would suggest to rework the password mechanism ;) Luckily, the password mechanism we have is sufficient if you choose your password carefully.
So, in short, it's not a security problem at all, though some sites might wish for a tighter security policy (you could easily call this paranoid, though). (Also: Did you remove the root account and replaced it with a different one? Did you make sure that your email transport agent does not accept mail at username@host? Did you disable finger and other services?)
Sharon And Joy
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.