That your KVM/USB problems sounds very much like an old bug in mousedev.c itself. I've seen that bug in action myself. The problem was that mousedev.c wouldn't notice new devices when they were plugged in. At least while the mixer device was opened. There is no problem with them saying their switch works with Linux, or anything else for that matter, as all it should be doing is changing the electrical connections around. Beyond that it's up to the host systems to properly handle the situaition. With USB as soon as that electrical connection is gone, it's gone. Just like pulling the cord out of the plug. Switching back is just the reverse, plugging your device back into your computer. Also, I havn't seen any recent trafic concering USB KVM's on linux-usb. Nor in my searches of linux-usb-user and linux-usb-devel on sourceforge.
My cohorts and I are currently involved with Linux based computer labs in two schools, here in Tucson, AZ. One is a public elementary school(~800 students). The project here, I'm told, started because a local company donated a lab full of used computers to the school. The district tech department bas just going to dump it, becase it didn't fit into their plans. The systems are Compaq P75's and P90's(all at 90Mhz) with their RAM upgraded to 64M. SoundBlaster Vibra16's and cheap PCI 10/100 NIC's(~$6-12 now) were also added. The systems boot Debian GNU/Linux into a gdm login prompt. Once they login through gdm they get an icewm desktop. We're using icewm because it's small, fast, and comfortable. We run as much native(Linux) software as we can find, but the pickings are still a little slim. So, we have to use wine to run the windows educational software(It is an elementary school, you gotta have the educational software). The native apps run off the local harddrives(540M-1G), while the wine CD-ROM apps run over NFS, like the home direcoties, to the main server(PPro 200, 128M ram). We just brought up another PPro 200 server yesterday. We hope to use it to handle the bulk(wine) data better through multi-daemon, read-only NFS. Also today we figured out that the only reason we havn't had AppleTalk access to user data until now is the NIC in the server(s). We now have netatalk appearing to behave itself, on the new server. After a little more testing we'll let the teachers start using it, through the large quantity of Macs allready in the school. It all works pretty good. The students walk in and sit down at a station, any station. They login and have access to all their personal data and preferences. Even better is that OpenSSH is running on each and every workstation. So we can administer each and every system without having to go to the school. With a little script, we can also send commands, like halt, to all of the systems with one commandline. It's really handy for bringing the lab down at night, and for maintanace. Not to mention that it's incredibly neat to watch the screens flicker down to the console to halt, in sequence, through the whole lab of 31. To maintain homogeniaty, and sanity, in the lab we occationally reclone it. Meaning we update one system and do whatever work needs to be done on that systems, then copy it to the rest. Thanks to bootp there are no system specific config files
The other school is a charter middle school. It's conciderably smaller, and cleaner because of it. The lab itself is ten stations(Same PPro 200's), and a teachers station. With a big, scary, tree eating HP laser, and another PPro 200 server. The server at the charter school handles the internal school homepage, the caching/filtering squid proxy, and print queuing. But that's just the boring stuff. It also serves the etherboot images for the lab, and/the/ NFSroot. All eleven stations share the same NFS filesystem. Sharing the NFSroot gains us a lot of things. Not the least of which is being able to replace harddrives in the machines with $3 EEPROMS. It also means there is one *1* system to administer. Run and apt-get dist-upgrade on one system, and the entire lab is brought up to date. And thanks to Network Block Devices each station has 128M of swap space, without any moving parts in the case.(Well, ok, the CPU and power supply fans still spin). The entire network at the charter school is 10/100 switched ethernet(1 24port NetGear FS524). So, through the wonders of etherboot and NFSroot's the entire lab is ready and waiting at a tweaked gdm login in a little over a minute. Well, if you hit all the power strips on a once(we did to time it). The tweaked part of the gdm login is that it shows a picture of the classical composer that particular system was named after, using only the one shared config file. The whole lab runs off of one IBM 9G LVD SCSI drive. We also took one of the existing 4.3G ide drives and put classical music mp3s on it to be played in class. The net connection is a DSL line, thus the squid caching is very important. It also gives us the oportunity to keep the students from wandering into places on the net that can get the school sued. Oh yeah, banner ads are just as easy to filter, or at least redirect to a 1x1 transparent gif.
Both labs work great. The second a little better because it's smaller and all new hardware. I'm sure my cohorts can explain it a little better, and in more detail. They'll read this thread and answer any questions there might be. Anything I forgot, or just plain got wrong, etc.
- kimo_sabe -- Programming is like sex; one mistake and you have to support for a life time.
A lot of people seem to have trouble with how open source projects work. There are very few, if any public access, read/write CVS repositories available. Every patch by a non-trusted, non-core developer much be approved by the maintainer. That is where the quality control and accountability is. Just because everybody isn't fully qualified and willing to help you that is no reason to forbit anybody to help. There are LOTS of OSS developers, but how many dare/bother working on the kernel? Or X? Or any other project for that matter. This is one of the big advantages of OSS projects, people contribute where they can. Where they are competent and interested in, instead of where they are assigned. Concider it this way: Some person, or small group of people at one hospital start working on something for their hospital. They get to talking with an IT person at another hospital. The other person also needs a peice of software similar to what is being developed at the first hospital. What do they do? Does the second hospital buy a copy of the current software? Hell no, that would be STUPID. Instead the guy at the second hospital downloads the software, checks it out, and make it suitible for his task. He then submits his changes back to the first hospital, which is greatful for the help and they continue working together. Both hospitals enjoy the fruits of the labor of more people then they, themself, have on payroll for no extra cost. - kimo_sabe
Ok, a couple of minor technical notes: Swap files and partitions are NOT boundless, but they are not bound to 128M. That limit was done away with a while back. I beleive the current limit, on an i386, is 2G. I've tested that. It didn't care much for more than that. Of course I wasn't using the BigMem patch(64G Physical:)) Security: It's Plug 'n Play. If you don't like ext2's security you can always switch to a Kerberos/AFS or CODA security systems. That will give you much finer grain control. You would still need a traditional filesystem(or devfs) or/dev. But, with that type of setup you would only need to have administrators in/etc/passwd. Thus only they could access stuff in/dev once you remove other access. - kimo_sabe --- Free your software, and your ass will follow
Slashdot Mirror
That your KVM/USB problems sounds very much like an old bug in mousedev.c itself. I've seen that bug in action myself. The problem was that mousedev.c wouldn't notice new devices when they were plugged in. At least while the mixer device was opened.
There is no problem with them saying their switch works with Linux, or anything else for that matter, as all it should be doing is changing the electrical connections around. Beyond that it's up to the host systems to properly handle the situaition. With USB as soon as that electrical connection is gone, it's gone. Just like pulling the cord out of the plug. Switching back is just the reverse, plugging your device back into your computer.
Also, I havn't seen any recent trafic concering USB KVM's on linux-usb. Nor in my searches of linux-usb-user and linux-usb-devel on sourceforge.
- kimo_sabe
My cohorts and I are currently involved with Linux based computer labs in two schools, here in Tucson, AZ.
/the/ NFSroot. All eleven stations share the same NFS filesystem.
One is a public elementary school(~800 students). The project here, I'm told, started because a local company donated a lab full of used computers to the school. The district tech department bas just going to dump it, becase it didn't fit into their plans.
The systems are Compaq P75's and P90's(all at 90Mhz) with their RAM upgraded to 64M. SoundBlaster Vibra16's and cheap PCI 10/100 NIC's(~$6-12 now) were also added.
The systems boot Debian GNU/Linux into a gdm login prompt. Once they login through gdm they get an icewm desktop. We're using icewm because it's small, fast, and comfortable. We run as much native(Linux) software as we can find, but the pickings are still a little slim. So, we have to use wine to run the windows educational software(It is an elementary school, you gotta have the educational software). The native apps run off the local harddrives(540M-1G), while the wine CD-ROM apps run over NFS, like the home direcoties, to the main server(PPro 200, 128M ram).
We just brought up another PPro 200 server yesterday. We hope to use it to handle the bulk(wine) data better through multi-daemon, read-only NFS.
Also today we figured out that the only reason we havn't had AppleTalk access to user data until now is the NIC in the server(s). We now have netatalk appearing to behave itself, on the new server. After a little more testing we'll let the teachers start using it, through the large quantity of Macs allready in the school.
It all works pretty good. The students walk in and sit down at a station, any station. They login and have access to all their personal data and preferences. Even better is that OpenSSH is running on each and every workstation. So we can administer each and every system without having to go to the school. With a little script, we can also send commands, like halt, to all of the systems with one commandline. It's really handy for bringing the lab down at night, and for maintanace. Not to mention that it's incredibly neat to watch the screens flicker down to the console to halt, in sequence, through the whole lab of 31.
To maintain homogeniaty, and sanity, in the lab we occationally reclone it. Meaning we update one system and do whatever work needs to be done on that systems, then copy it to the rest. Thanks to bootp there are no system specific config files
The other school is a charter middle school. It's conciderably smaller, and cleaner because of it. The lab itself is ten stations(Same PPro 200's), and a teachers station. With a big, scary, tree eating HP laser, and another PPro 200 server.
The server at the charter school handles the internal school homepage, the caching/filtering squid proxy, and print queuing. But that's just the boring stuff. It also serves the etherboot images for the lab, and
Sharing the NFSroot gains us a lot of things. Not the least of which is being able to replace harddrives in the machines with $3 EEPROMS. It also means there is one *1* system to administer. Run and apt-get dist-upgrade on one system, and the entire lab is brought up to date. And thanks to Network Block Devices each station has 128M of swap space, without any moving parts in the case.(Well, ok, the CPU and power supply fans still spin).
The entire network at the charter school is 10/100 switched ethernet(1 24port NetGear FS524). So, through the wonders of etherboot and NFSroot's the entire lab is ready and waiting at a tweaked gdm login in a little over a minute. Well, if you hit all the power strips on a once(we did to time it). The tweaked part of the gdm login is that it shows a picture of the classical composer that particular system was named after, using only the one shared config file.
The whole lab runs off of one IBM 9G LVD SCSI drive. We also took one of the existing 4.3G ide drives and put classical music mp3s on it to be played in class. The net connection is a DSL line, thus the squid caching is very important. It also gives us the oportunity to keep the students from wandering into places on the net that can get the school sued. Oh yeah, banner ads are just as easy to filter, or at least redirect to a 1x1 transparent gif.
Both labs work great. The second a little better because it's smaller and all new hardware.
I'm sure my cohorts can explain it a little better, and in more detail. They'll read this thread and answer any questions there might be. Anything I forgot, or just plain got wrong, etc.
- kimo_sabe
--
Programming is like sex; one mistake and you have to support for a life time.
A lot of people seem to have trouble with how open source projects work. There are very few, if any public access, read/write CVS repositories available. Every patch by a non-trusted, non-core developer much be approved by the maintainer. That is where the quality control and accountability is. Just because everybody isn't fully qualified and willing to help you that is no reason to forbit anybody to help.
There are LOTS of OSS developers, but how many dare/bother working on the kernel? Or X? Or any other project for that matter. This is one of the big advantages of OSS projects, people contribute where they can. Where they are competent and interested in, instead of where they are assigned.
Concider it this way: Some person, or small group of people at one hospital start working on something for their hospital. They get to talking with an IT person at another hospital. The other person also needs a peice of software similar to what is being developed at the first hospital. What do they do? Does the second hospital buy a copy of the current software? Hell no, that would be STUPID. Instead the guy at the second hospital downloads the software, checks it out, and make it suitible for his task. He then submits his changes back to the first hospital, which is greatful for the help and they continue working together. Both hospitals enjoy the fruits of the labor of more people then they, themself, have on payroll for no extra cost.
- kimo_sabe
Ok, a couple of minor technical notes: Swap files and partitions are NOT boundless, but they are not bound to 128M. That limit was done away with a while back. I beleive the current limit, on an i386, is 2G. I've tested that. It didn't care much for more than that. Of course I wasn't using the BigMem patch(64G Physical :)) Security: It's Plug 'n Play. If you don't like ext2's security you can always switch to a Kerberos/AFS or CODA security systems. That will give you much finer grain control. You would still need a traditional filesystem(or devfs) or /dev. But, with that type of setup you would only need to have administrators in /etc/passwd. Thus only they could access stuff in /dev once you remove other access. - kimo_sabe --- Free your software, and your ass will follow