On Monday 11 July 2005 09:36, Valery Reznic wrote: >> Yes, xwindows itself has come a long ways. Some >> teething pains here >> and there, but nothing that couldn't be fixed, and >> not much that >> needed it in my experience. > >Dealing with colormap was terrible and need >intrevention in source code. Brrr.
Mmm, sorry. I don't recall problems in that dept other than some were fixed. Perhaps those problems were being coded around in that application? > >> This sounds like a commercial/medical application, >> perhaps if that >> vendor who sold you the ultrasound application is >> still around, maybe > >Yes, vendor is still around, and ask me to add support >for disk-on-key. And (still) resist move to the new >distro :( So as Pogo would have said, they is the foot-dragger. You are aware I hope, of the limited write lifetimes of such flash based disk emulators? Given a filesystem that attempts to distribute the write wear and tear over the whole chip, decent liftimes can be had, 100k writes or so. No std filesystem does that, all prefering to keep the system somewhat defragmented by keeping active data near the start of the 'disk's surface to reduce seek times. That can wear out a flash memory chip in 500 writes or less. There are some horror stories on the mailing lists relating what the user felt was a premature failure of such an expensive device when used with the normal filesystems. If he is looking to put individual patient data on one so that it can then be stored with the rest of the patients records, I think I'd want to look to something else with more durability or less cost. Less cost is the easy part, use cdr's, < $1 each. How much data is to be stored on a per account basis? I'm sort of reading between the lines here I suppose in thinking Ultrasound movies could easily run to gigabytes unless made into mpeg2's. I made an 8 gigabyte, 20 minute wedding into about 370 megabytes by making a video cd from it just recently. With no noticeable loss of the 640x480 quality I started with. And the cd, while also fragile if miss-handled, is also dirt cheap, costing more in labor to burn it than the disk itself since most burns even in modern burners will take several minutes. Much of that drudgery can be automated with suitable bash scripts except for the burner loading, unloading, and fileing the cd's away where they go. There also the relatively expensive tyvec cd sleeves that are as expensive as the cdr itself, but that total is certainly less the a disk-on-a-key usb gizmo I'd think, by about 2 orders of magnitude. OTOH, the disk is also thinner, and would file in the patient record folder with considerably less bulk in terms of shelf space. Or have you already explored that possibility? And run into similar problems, possibly because the burner software (cdrtools) won't run on such an old version... If the os is that old, how about the hardware? A 66mhz Pentium will have a hard time keeping up with a modern cd writer. No problem here, but then theres an XP-2800 athlon to shovel the data around here. :) >Valery I'm running out of ideas here folks, can somebody toss me a lifesaver? -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.35% setiathome rank, not too shabby for a WV hillbilly Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. ------------------------------------------------------- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
