GUUG mal, Beitrag 003 (Januar 2000)


Vorheriger BeitragBeitrag abspielenNächster Beitrag

In the meantime, I got a ``fresh'' set of batteries for the camera and I was able to record a few of the answers Alan gave to the audience after the talk.


Questions after the talk at the 2nd Linux-Kongress

Question: What is your favourite window manager?

Alan: Are you trying to start a fight with someone? I don't know. Mostly I used fvwm. On the small machines, until recently, I ran wmx, which is a very small windowmanager. On the very small palmtop machine I had, I was running a customized version specifically designed for that machine. It really had a horrible mouse, so this [?] to avoid to use the mouse very much. Currently I'm using enlightment. I still have RedHat 6.1 and I figured ``oh give enlightment a chance'' and run it until it crashed and unlike the previous version, this one has [?]. I don't particulary have a specific choice of window manager I really really like. What I probably think is the neatest window manager, which I don't run, is window maker.

Question: What do you think about the device filesystem (devfs)?

Alan: It is an [?]. Devfs is a very nice piece of code. I think the big issue is whether Devfs is a solution looking for a problem. It is not clear that we need devfs or that devfs is the right way of handling things like dynamic devices. There are people [?] fairly [?] about whether it is the right answer or not.

Question: Can devfs help to handle USB devices?

Alan: We don't need devfs for that. That is all managed with the existing device system. Your /dev/usbmouse, for example, the first one is a sum of all your USB mice on that machine. The others are signed as you plugin and assign mice. We are doing similar things with block devices. With stuff |like mass storage, it is not enough to just query the device about its |serial information. And you can do this with SCSI and most ID devices. This |kind of volume location and device location is currently single machine, which devfs handles. When you get to what we call storage area networks. On these very fast networks, you have some of your I/O devices, some of your disks remote to your machine. It becomes a multi-machine problem. Because you say ``mount me the /home for this group of users''. And it could be, that this /home volume is on 2 km away on the end of a fibre optic network. So devfs alone isn't enough to solve the bigger problem. Even the mount one, for example. You could say: check the disks for this volume name, I haven't got it. You can add an NFS service [to that imaginary setup], where you can broadcast saying ``who on my local network has a volume with this identity?''. So you can take a disk from the local machine, plug it in remotely and use it. Or somebody borrowed your CD, for example. You can say ``mount the CD with this name''. And it will walk around the network for your and find out who borrowed it and mount it remotely. There is a lot more to volume management than just assigning device names.

Question: Is anybody thinking about sharing disks between two machines and what kind of locking it would need?

Alan: The Linux clustering combo is working about this kind of thing. There are people already doing this with the network block device. You run RAID-1 mirroring and you use [?] only one system you use the disk directely but you can fail over to the other machine.

The second one is called the global filesystem (gfs project). They have got a fibre channel based filesystem, which multiple machines can read and write at the same time, all connected directely to the disk. That we hopefully will see generally available in time. At the moment it is still a research project, so there is work to be done there.