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.||27 Jul 2000 - 7 Aug 2000||(7 posts)||New GRUB Available|
|2.||1 Aug 2000||(15 posts)||PPP: The Saga Continues|
|3.||2 Aug 2000 - 8 Aug 2000||(24 posts)||Documentation Format|
|4.||6 Aug 2000 - 7 Aug 2000||(4 posts)||Problems With 'e2fsprogs'|
|5.||6 Aug 2000 - 10 Aug 2000||(5 posts)||Hurd On The Alpha: The Saga Heats Up|
|6.||7 Aug 2000||(2 posts)||Improving Locales|
|7.||7 Aug 2000 - 11 Aug 2000||(32 posts)||'init' For The Hurd|
|8.||8 Aug 2000||(2 posts)||Midnight Commander|
|9.||8 Aug 2000 - 11 Aug 2000||(3 posts)||Dearth Of Docs On Internals|
|10.||9 Aug 2000 - 11 Aug 2000||(2 posts)||/etc/issue Success|
|11.||9 Aug 2000||(1 post)||Small 'init' For The Hurd|
Mailing List Stats For This Week
We looked at 134 posts in 453K.
There were 40 different contributors. 19 posted more than once. 18 posted last week too.
The top posters of the week were:
New GRUB Available
27 Jul 2000 - 7 Aug 2000 (7 posts) Archive Link: "GNU GRUB 0.5.95 boot image available"
People: Gordon Matzigkeit, Marcus Brinkmann, Ognyan Kulev
Gordon Matzigkeit announced:
I've updated the GRUB boot image to 0.5.95. You can get it from:
Sorry I didn't do this earlier, but this should solve all the problems new folks were seeing because they were using grub-0.5.93.1.
Marcus Brinkmann pointed out that the 'Easy Guide' explicitly directed people to the wrong package, and suggested:
As we don't have access to the master copy at ucam.org, and Matthew is away for a couple of weeks, we should by community ruling rogue the install doc and keep a corrected copy at gnu.org, and change all references we have under our control to this one. And we should give Matthew all help he needs to be able to modify the copy at gnu org in the future.
I am willing to spend the time necessary to get the install instructions up to date. I can host them at debian.org, too, but gnu.org is probably better(?)
I am now going to move the above grub disk out of the way.
Ognyan Kulev replied, "Installation instructions are for Debian GNU/Hurd, so I think they should be in debian.org."
PPP: The Saga Continues
1 Aug 2000 (15 posts) Archive Link: "PPP for Hurd requirements"
People: Marcus Brinkmann, Roland McGrath, Daniel E. Baumann
PPP was first covered in Issue #26, Section #3 (28 Nov 1999: PPP Under The Hurd) , then again in Issue #28, Section #3 (13 Dec 1999: FTP And PPP On The Hurd) and then in Issue #34, Section #1 (21 Jan 2000: Porting PPP) . By Issue #38, Section #6 (4 Mar 2000: PPP Saga Continues) there had still been almost no progress; Issue #39, Section #2 (4 Mar 2000: PPP/pfinet Saga Continues) looked more hopeful, as did Issue #45, Section #1 (16 Apr 2000: PPP: Saga Continues) ; but in Issue #49, Section #4 (19 May 2000: PPP: Saga Continues) it was clear that very little had actually been done, although most recently in Issue #55, Section #8 (20 Jul 2000: Developers Join Forces For PPP) Daniel E. Baumann was planning on devoting himself in a serious way to the problem, though not right away.
This week Eric Gibson gave a link to his Hurd/PPP page (http://lyonfyre.net/hurd/) and suggested trying to get some basic functionality working even if it meant cutting corners; which a more robust, long-term solution could eventually replace. Daniel was interested in this, but still had no time at the moment. He offered to help later on with the robust solution. Marcus Brinkmann suggested looking at 'trans/pump.c' in the Hurd CVS tree, "which can sit on top of a hurdish socket node and initiate a connection and pass it on to pfinet. It might be useful for PPP, too." Roland McGrath objected that this was definitely not a long term solution, as it would only work in the case of exactly one interface. Marcus replied, "Do you have better ideas? It would be great if you, Thomas et al could discuss various approaches a bit, just so that people have a foot in the door and can try to tackle that issue. Currently, there is a huge black cloud hanging over this, with nobody(?) really knowing what to do." Roland replied:
The basic shape of the better plan is well understood. There needs to be some kind of interface to attach to pfinet and provide it with new interfaces via ports. Then daemons a la pppd can be written in similar fashion as using the tun device on BSD.
I have some complex ideas on how to do this in a clean and flexible way for the long term, but I have not had the time to have discussion of the details. (My basic notion is a "channel" abstraction parallel to the "store" abstraction and with similar support in libraries and protocols a la file_get_storage_info and libstore. This is a general way towards efficiently dealing with things like keyboard devices and printers, etc.)
But it would be pretty straightforward without a whole lot of thought to add a simple RPC interface to pfinet for adding tun style interfaces. I guess the quickest WRONG hack would be for pfinet's command-line handling to grok pseudo-devices specified by a file name it would look up. Then you could add one of those with fsysopts as well as at translator startup. From the hurd server hacking I've seen you doing lately, I think you know enough to whip that hack out, Marcus. You know, actually an even easier and still egregious and WRONG hack might be to have pfinet know how to create some new weirdo flavor of socket that then would act as an packet source/sink. Then a pppd could just open one of these sockets, set its interface addresses via bind/connect/setsockopt or something nutty like that, and start shoving packets. Muwahaha. We will eventually rip out any hack like this, I guarantee you, but until we have time to work out a pretty solution, what the hell.
There followed a bit of implementation discussion that looks as though it was partially done in private.
2 Aug 2000 - 8 Aug 2000 (24 posts) Archive Link: "Docs format"
People: Juli-Manel Merino Vidal, Marcus Brinkmann, Matthew Emmett, Mark Kettenis
Juli-Manel Merino Vidal wanted to write some Hurd documentation, but asked what the preferred format was. He wondered, "I mean if I should use SGML, LinuxDoc, DocBook, Latex or just plain HTML... (Maybe we could make a HurdDoc :) I don't know which of these use to write proper documentation. I think latex could be cool because there are translators to tex and html. But, is it there any way to customize the HTML output of these translators ?" Marcus Brinkmann took the GNU party line and recommended 'texinfo (http://www.gnu.org/manual/texinfo/) ', adding:
(la)tex is a good printing system, but a poor choice for a docformat. It doesn't convert very well either (except to printouts).
And if we are limited to tex and html, we can get nice print outs, and poor web sites, but no form in which we can read it on a simple text terminal without a browser.
texinfo is not only the GNU format, it also has a decent viewer, and converts nicely to all sort of formats.
SGML is also a good choice for content storing, but the existing converters are in the medium range, and jadetex gives me shivers down my spine.
Close by, Matthew Emmett extolled, "It is my opinion that texinfo is much better than HTML. The "info" program for viewing .info files is much more advanced than lynx, and the info mode of emacs is wonderful. Printed texinfo documentes are a dream compared to printed HTML. I also, personally, feel that texinfo is easier to author than HTML." [...] "I think authoring documentation in texinfo is better for "information distribution" becase it is so easy to convert texinfo into different formats, including HTML. However, converting HTML is a bit of a pain -- to say the least."
Not everyone was in favor of 'texinfo'. Some folks suggested HTML, some preferred DocBook, and one person even suggested plain text. But as pointed out by Mark Kettenis, 'texinfo' was the preferred format for documentation in the GNU project, of which Debian Hurd was a part.
Problems With 'e2fsprogs'
6 Aug 2000 - 7 Aug 2000 (4 posts) Archive Link: "WARNING don't install e2fsprogs 1.19"
Topics: FS: ext2
People: Marcus Brinkmann, Matthew Vernon
Marcus Brinkmann cautioned:
e2fsprogs 1.19 is broken for the Hurd, because it thinks we don't support the filetype feature and complains loudly if it is used. But we support it just fine, we don't set it, though, and generally ignore it.
This needs to be fixed, but in the meanwhile: stay away.
He replied to himself, suggesting that the 'Easy Guide' include the command 'mke2fs -O sparse_super -o hurd /dev/xxx' which would avoid the problem for the moment, at least for the root filesystem. He replied to himself again, saying, "Actually, this is the correct thing anyway, so it should be the default. I mailed such a request to the e2fsprogs author, we'll see what comes out of this." Matthew Vernon replied that he'd updated the 'Easy Guide', but wouldn't have much access to it for the next few weeks, on account of poor home connectivity; so any less important changes would have to wait.
(After this issue of KC Debian
Hurd came out, Marcus emailed me privately, saying that further discussion
in the bug-hurd mailing list (the developer list for the Hurd kernel itself)
had revealed that he was wrong about the whole report. Actually, he told me,
ext2fs 1.19 is perfectly fine and has the
correct defaults. Apparently he'd just been up really late and
zigged when he should have zagged. So cool! ext2fs 1.19 works after all.
Thanks for the correction, Marcus! -- Ed: [17 Aug 2000 22:10:00 -0800]
Hurd On The Alpha: The Saga Heats Up
6 Aug 2000 - 10 Aug 2000 (5 posts) Archive Link: "gnu mach/hurd on Alpha, update!"
People: Ron Farrer, Christopher C. Chimelis, Niels Möller
In Issue #21, Section #2 (15 Oct 1999: Porting The Hurd To Alphas) , it was clear that not even 'gnumach' would work yet under the Alpha. By Issue #40, Section #5 (19 Mar 2000: Hurd On The Alpha) it was clear that not only had no progress been made, but there was even talk of starting fresh with an entirely new microkernel underneath the Hurd servers. Most recently in Issue #55, Section #4 (17 Jul 2000: The Hurd Under Alpha) , there was still very little progress, but an increased sense of determination.
This week saw the first real progress. Ron Farrer announced:
"Some of you may remember me inquiring about gnu hurd/mach on the Alpha. I have recently started working on it (after finding the original CMU sources) and am now working with Christopher C. Chimelis <email@example.com (mailto:firstname.lastname@example.org) >on it. Currently we are just working on gnumach (fiddle with the rest once this much is done). We are also looking to probably setup CVS some place soon."
Christopher C. Chimelis added, "Qualifying remark: we're only going to set up a different CVS until we're ready to merge our changes with upstream :-) It doesn't look like a long uphill battle, but we've got enough stuff to do that shouldn't pollute the upstream CVS at this point."
Niels Möller asked if they were starting from the OSKit branch of gnumach, and Ron replied, "Not at this time. Mostly because we have been unable to locate *any* Alpha specific work."
Elsewhere, under the Subject: Alpha port FYI (http://www.debian.org/Lists-Archives/debian-hurd-0008/msg00172.html) , Ron updated, "Just as an FYI we've created a page at http://lully.debian.org/~chris/ that contains some info, links, and status of the port to Alpha. Hopefully that will help reduce some of the "how far along are you?" type emails. :)"
7 Aug 2000 (2 posts) Archive Link: "cross-install needs C locale to work properly."
People: Santiago Vila, Marcus Brinkmann
Santiago Vila reported:
cross-install does not work properly if the locale is different than C, because it considers every non-english dpkg message as "unusual", and it fails.
Either LANG=C (or LC_ALL=C) is added to cross-install, or else it should not consider unusual messages as a fatal error.
Note: This is the reason boot/servers.boot.dpkg-new was not renamed to boot/servers.boot last time I used cross-install. The reason I did not notice there was indeed an error is that the unsual messages list was so large that I missed the initial lines:
ERROR: dpkg did return unusual messages, please investigate: INSTALLATION ABORTED!
Marcus Brinkmann replied, "I am currently patching cross-install and producing a new tar file. Expect more tomorrow (as I have just finished most of the work, the other changes you mailed me will have to wait a few days)."
'init' For The Hurd
7 Aug 2000 - 11 Aug 2000 (32 posts) Archive Link: "rc"
People: Mo McKinlay, Brian Gajdos, Juli-Manel Merino Vidal, Tomasz Wegrzanowski, Marcus Brinkmann
Juli-Manel Merino Vidal had been trying to customize his system, and complained that the boot script did not follow System V init, as Linux did. Marcus Brinkmann replied that System V had some limits that the Hurd didn't need to be bound by, such as having a fixed number of runlevels. Tomasz Wegrzanowski suggested a Makefile-based init system, which he said already existed for Linux; and Mo McKinlay replied:
I had an idea about developing this for Linux (I wasn't aware some such thing existed) - actually inspired by WinNT's "service" handling. The way it worked was (briefly):
- Every service had several states:
- Every service could be controlled by a pretty standard command (I used the name 'svc' for my test program), which took the syntax:
- svc NAME [OPERATION]
Without the OPERATION, it displayed the current state of the service, otherwise, OPERATION must be one of:
And the configuration was managed by makefile-style files so that services could depend on one another - the 'starting' and 'stopping states were used primarily when starting/stopping dependencies, in order to prevent startup/shutdown loops.
'Runlevels', as they exist now, were effectively pseudo-services, with every service that ran in them being dependencies (I didn't quite get as far as doing this bit, so things are still a bit hazy). I decided on named runlevels, though, which was a) less confusing for the user b) allowed more flexibility (init graphical, init multiuser, etc), and thinking about it, c) is more fitting with how HURD goes (imho).
There followed some discussion of various aspects of the proposal, and at one point Brian Gajdos asked, "What structure will these 'makefiles' have? I think it would be very practical to be able effectively change them using "automatic" scripting if we want this kind of init to be widely used by package managers." Mo replied that it definitely should use plain-text files; and proceeded to analyze possible examples of init code, though he acknowledged, "I need to sit down and think about exactly what the available keywords would be and so on, and I'm sure there'll be plenty of discussion about how crappy my config files are (just so long as people say it *now* and not in 3 month's time when I've done a nice library interface to them, I'm happy :>)" Elsewhere and later on, he remarked, "The beauty of hurd-init's design is that you don't actually need scripts in a lot of cases. If a 'service' is just a single command to start up/shut down, then you can reduce it to a small package config file (4-5 lines, at most). While it's not necessary to do so in some cases, and would be redundant with SysV-style init, you can tie translators to dependencies with hurd-init, and provide a single interface ('svc') to starting/stopping subsystems, be they daemons, translators or something else. This way, the user doesn't have to remember many different commands to perform the effectively the same task with different subsystems, without adding unnecessary complexity. I think :)"
8 Aug 2000 (2 posts) Archive Link: "mc"
People: Tomasz Wegrzanowski, Juli-Manel Merino Vidal
Juli-Manel Merino Vidal couldn't find a deb package for 'midnight commander' for the Hurd, and asked if he should compile from the sources. Tomasz Wegrzanowski replied, "I have one compiled from sources. There is no deb as you would have to compile GNOME version alos."
Dearth Of Docs On Internals
8 Aug 2000 - 11 Aug 2000 (3 posts) Archive Link: "gnumach and hurd source code"
People: Roland McGrath, Juli-Manel Merino Vidal, Tomasz Wegrzanowski
Juli-Manel Merino Vidal asked about Mach and Hurd server internals, specifically where any documentation could be found. Roland McGrath replied, "Such documentation is a fine thing. In the free software world, it gets written by people like you. If you make a serious effort to read and understand the code, then any specific questions you have about how a particular part of the implementation, you can ask here and we will be happy to answer them. If you take what you learn and work on improving the manual, then it will be easier for the next person to get started." Tomasz Wegrzanowski added that even the best existing docs were all from the 1980's.
9 Aug 2000 - 11 Aug 2000 (2 posts) Archive Link: "/etc/issue, now usable"
People: Juli-Manel Merino Vidal
Juli-Manel Merino Vidal announced:
I've modified hurd/daemons/getty.c to be able to print the file /etc/issue just before /etc/motd is print. The new getty allows escape secuences as linux getty does, but only a few of them.
I've attached the patch file and an example issue file, which prints the same as the original message of the hurd, but in green color :) Ah, if /etc/issue is not found, this new version prints the original message instead.
There was no reply to this, but later under the Subject: issue (2) (http://www.debian.org/Lists-Archives/debian-hurd-0008/msg00178.html) , he added, "I've modified my patch about /etc/issue support for getty.c. It's now faster, and the code is cleaner. (Thanks to Niels!) I attach here the diff file and a single issue file to be used in GNU."
Small 'init' For The Hurd
9 Aug 2000 (1 post) Archive Link: "poor man's init for Debian GNU/Hurd (10 lines)"
People: Marcus Brinkmann
Marcus Brinkmann posted some code and announced, "here is poor man's init for Debian GNU/Hurd. This will be in the next Hurd Debian package, because it works well enough for now." There was no reply.
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.