Kernel Traffic
Latest�|�Archives�|�People�|�Topics
Wine
Latest�|�Archives�|�People�|�Topics
GNUe
Latest�|�Archives�|�People�|�Topics
Czech
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

Hurd Traffic #31 For 12�Jan�2000

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

This issue is dedicated to my mother, Marie-Annick Brown, whose birthday is today. Happy birthday, Marie!

BTW, If anyone wants to get email announcements of new KC Debian Hurd (or other KC) issues, check out the mailing lists page.

Mailing List Stats For This Week

We looked at 105 posts in 331K.

There were 34 different contributors. 23 posted more than once. 10 posted last week too.

The top posters of the week were:

1. Suggestions For New Translators

29�Dec�1999�-�7�Jan�2000 (32 posts) Archive Link: "Random idea:"

Topics: FS: ext2

People: Dirk Ritter,�Marcus Brinkmann,�Niels Moller,�Adam Sampson,�Niels Moller,�Niels M�ller

Chen Shapira had a couple of suggestions. First, she suggested a transparent HTTP translator, along the lines of the well-known transparent FTP translator. She added that it would be great if this translator could handle CGI requests as well. Adam Sampson pointed out later, that now that there was a Hurd server written in Perl, it should be easy to implement transparent HTTP.

Shapira also suggested adding mime types to the file information in the file system, which would make the 'file' command easy to implement, and would allow a number of other useful features, such as writing a program that would invoke 'gimp' for a graphics file or 'vi' for a text file. Dirk Ritter pointed out that there were some pitfalls to be avoided in such a feature: for one thing, since other filesystems could conceivably modify the data, the Hurd translator would not be able to rely on any meta-information within the files themselves, so it would have to generate the needed information on the fly. Also, file information would have to be determined by the data alone (as opposed to filename extension). There was also the problem of how to interpret a compressed file -- was an instance of compression, or of the file being compressed.

Dirk added that a similar idea had been considered and rejected a long time ago by one of the Hurd developers. Dirk offered two avenues of investigation that Chen might be interested in. He said, "ESR once wanted to work on a library that implements file type identification - the state of this project is unknown to me, the information predates his 'political career'." He also suggested, "once upon a time there existed an X desktop called GREAT that used file type identification based on magic numbers and such but it seems like the project died a long time ago (It looked promising, though, and I even got it running some time ago for the fun of it...)"

He offered some pointed reminiscence:

Admittedly I once used OS/2. It offered extended attributes on the native file system and an emulation of extended attributes on other file systems where such Information got stored in files '\wp root. sf' and '\ea data. sf' or something similar. Cute as it looked - I don't want it back.

The Workplace shell used to store icons inside those attributes, but I don't see how anyone would benefit from that since this way you end up with lots of duplicated bitmap data - a waste of space and resources and maybe it even gets in the way occasionally, perhaps if kids want to replace their old icons with new, cute looking 3-D like icons.

There also used to be mechanisms to associate data and programs with file types in addition to the types provided by the stock OS/2 installation. Cute as it seemed - it always broke down after - say - a new installation of OS/2, i.e. even though the data remained untouched somewhere on the native file system the newly installed system didn't know anything about the meaning of file type associations you defined yourself. It was the same problem if you moved data from one OS/2 box to another. This could easily be solved by using MIME types, but I guess it should be done inside some library - any programmer interested in file type definitions should then use that library to determine the proper type on the fly - maybe it even becomes standard practise but the OS should not be forced to offer it on the file system level since not every application will need it.

The remaining question is if applications should be provided with means to store data related to a file inside resource forks (Mac speak) or extended attributes (OS/2 terminology). I guess there is no real need for it - OS/2 EA's look like the environment with 'Key=VALUE' pairs and as appealing as it might seem - I found it essentially useless, especially since this did lead to unwanted side effects (double clicking a template for instance could lock the system considerably since the Workplace shell did not ignore this action for templates, thereby rendering the template useless - fortunately I knew how to back up and copy EA's, so that I could spare a friend of mine at least four re-installations of OS/2.).

I hope this is not too boring but let's illustrate the problem a bit further - standard GNU/Linux distributions have a huge number of files or directories under standard locations such as '/usr/bin/index.html' and '/usr/doc/index.html' for example. I once had the ability to mount my ext2 file systems as OS/2 drive letters under OS/2 and I found that the cute icons that were useful on small OS/2 systems got in the way on GNU/Linux file systems just because a shell with filename completion features does a much better job for you than icons representing hundreds of files. I guess the same holds true under a lot of other circumstances where tools designed to do a certain job just require different approaches if the job gets beyond the limited capabilities of the tool in question. (Another example would be 'xfontsel' - the list can handle a certain number of fonts but the implementation with simple drop down menus breaks horribly if you installed lots of fonts.)

This leads me to a final question - maybe you want your shell's interpreter hack to decide what interpreter to run based on the file type? Of course - text files can be made executable and if you write '#/bin/emacs' in the first line you will be able to start emacs and load the file you want to edit. This is ugly since it will break under GNU/Linux where emacs is under '/usr/bin/index.html' and of course it would corrupt JPEG data, so the mechanism needs to be extended. Since some people might just want to prefer different applications for their work this needs to be made configurable at least on a per user base - something that is an ideal job for something like gnome core components or similar applications - do you still feel that it is beneficial to offer such functionality inside core OS components such as file systems or exec servers? I doubt it.

Marcus Brinkmann pointed out that since any user could use their own filesystem or exec translators, these were not core OS components anymore. He added that Shapira's server "probably wouldn't be the system default anyway, but the whole purpose of the Hurd is to make the default core OS unimportant to the users."

Shapira also replied to Dirk, explaining that her idea had been to record the file type at creation time. To change a file's type would take a command, 'chtype filename type'. If a program was invoked with an incorrect file type, Shapira assumed the program would give an error, which was acceptable. And as for how to treat compressed files, she felt they should be considered as compressed files. Dirk was still skeptical, saying the idea was too simple and too weak, in his opinion.

Niels M�ller added:

In a discussion some time ago, I proposed keeping a property list with each inode. I think that would be cute, useful and general way to extend the information about an inode.

Examples of systems using property lists to keep auxillary information about objects include emacs' text- and symbol-properties, X's window properties (e.g. window titles and icon-bitmaps), and lisp systems.

I don't think anyone of the people actually hacking on the HURD have liked the idea. Cooking up an interface for it should not be difficult, but I have no idea how much work it would take to get the information into, say, the ext2 filesystem.

There was a bit more discussion over the relative merits and possible implementation details of such a server.

2. Purging Directories; Catting /dev/log

1�Jan�2000�-�3�Jan�2000 (5 posts) Archive Link: "cleaning up left over files..."

People: Marcus Brinkmann

Wolfgang Jehrling noticed the message "cleaning up left over files..." and a several minute delay at boot-up, and asked about it. Marcus Brinkmann pointed him to /libexec/rc and asked if he'd had anything unusual in /tmp. Wolfgang couldn't think of anything that might have been in there, and Marcus explained, "Well, if there were large or lot of left over files... the Hurd is very slow in purging directory hierarchies."

Earlier in the thread, Wolfgang also reported that 'cat /dev/log' would return the error, "cat: /dev/log: Not a directory". Marcus confirmed that this was a bug, and invited Wolfgang to investigate it, but Wolfgang replied that he had no time for bug-hunting.

3. X Under The Hurd

2�Feb�2000�-�3�Feb�2000 (4 posts) Archive Link: "X does not work"

People: Michael Thaler,�Michail Issakov

Michael Thaler downloaded X from ftp://alpha.gnu.org/gnu/hurd/contrib/XFree/X3323-Hurd.tar.gz, and translators for kbd, mouse, and pfinet, and installed them using the following commands:

$ cd /
$ tar -xzf /path-to-X3323-Hurd.tar.gz

he copied the translators into /hurd, and set them up with:

$ settrans -cg /dev/kbd
$ chown root /dev/kbd
$ chmod 444 /dev/kbd
$ settrans /dev/kbd /hurd/kbd /dev/kbd
$ settrans -cg /dev/mouse
$ chown root /dev/mouse
$ chmod 444 /dev/mouse
$ settrans /dev/mouse /hurd/mouse --protocol=ps/2

He also set the variables:

$ export LD_LIBRARY_PATH=/usr/X11R6/lib
$ export DISPLAY=localhost:0.0

Trying to start X, he would get the errors:

_XSERVTransSocketOpen: socket() failed for tcp
_XSERVTransSocketOpenCOTSServer: Unable to open socket for tcp
_XSERVTransOpen: transport open failed for tcp/hurd:0
_XSERVTransMakeAkkCOTSServerListeners: failed to open listener for tcp
Fatal server error:
Cannot establish any listening sockets - Make sure an X server isn't
already running

Michail Issakov gave a pointer to a more recent X version, as well as a pointer to some online info.

Michael Thaler downloaded the more recent files and tried again. But when starting X, he would get a permission denied error on the keyboard. He offered, "I think it's a problem with the translators and I downloaded the patch hurd-xfree86.patch. But how can I install this patch on the HURD? There's a patchls command which lists the contents of the patchfile, bur no patch-command. I did not find a packet patch. I tried to install it within linux wit patch -p0 hurd-xfree86.patch, but it did not work. What do I have to do to install the patch?"

Michail gave a pointer to the 'patch' .deb file. End of Thread.

4. Maximum Partition Sizes For Grub And Hurd

2�Jan�2000�-�3�Jan�2000 (2 posts) Archive Link: "can grub boot from >8G"

Topics: Bootloaders

People: Pavel Roskin

Someone asked if 'grub' could boot from a disk that was larger than 8GB. They seemed to remember a warning about that in an old 'grub' manual. Pavel Roskin replied that GRUB 0.5.93.1 would support partitions up to 128GB, though the Hurd itself would not support filesystems larger than 1GB. He also said that 'grub' bug reports should go to bug-grub@gnu.org

5. Emacs Installation

4�Jan�2000�-�5�Jan�2000 (4 posts) Archive Link: "emacs install problem"

People: Marcus Brinkmann

Abdul Aziz tried to install emacs20_20.3.5, but ran into dependency problems with emacsen-common 1.4.9 depending on bsdmainutils, which in turn conflicted with textutils 2.0-2; and he wasn't sure it was safe to remove textutils. Marcus Brinkmann replied, "Just force install everything. The bsdmainutils situation is a bit tough, but I don't think any dependency on it is crucial." Abdul replied that this worked, but he reported a new, apparently unrelated problem: the mailbox in /var/spool/mail was read-only when used by 'mutt', making it impossible to delete mail from 'mutt'. Marcus replied, "I experience the same problem. If you can investigate that, great. I am afraid I don't have the time to track it down right now. I don't even know if it is a bug in mutt or hutd/glibc or permissions."

6. Anacron

5�Jan�2000 (2 posts) Archive Link: "Anacron problem"

People: Marcus Brinkmann

Abdul Aziz reported that 'anacron' was returning errors from cron.daily: "nice: cannot set priority:Permission denied." Marcus Brinkmann replied:

That's a known "issue" (read: bug). Priorities don't work right. IIRC, there are Mach issues that make it difficult to implement priorities correctly.

See also http://bugs.debian.org/44039

To work around remove all calls to "nice" in the cron scripts under /etc/cron.{daily,monthly,weekly}

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.