Felix Miata posted on Wed, 13 Nov 2013 12:36:30 -0500 as excerpted: > On 2013-11-13 12:08 (GMT) Duncan composed: > >>> https://bugs.kde.org/show_bug.cgi?id=318061 > >> The root problem is one of legacy hardware (lack of) features. Floppy >> drives are old enough they predate the hardware removable-media-detect > >> Making problems worse, there's no media-change-detect notification > > How is it that ancient DOS manages? It/they originated "plug & play".
IIRC (and I remember my MS DOS 6 tech reasonably well, along with the upgrade to MS Windows 95), it wasn't DOS that originated plug-n-play, but W95. DOS as such did have some support, but it was pretty basic, while the /real/ usage was in W95. And in both cases, they basically don't do auto-media-detect/change- detect in any form for floppies. They normally force synchronous writes (just as is recommended, tho not forced, with Linux, since Linux does have a separate mount/umount concept), and users quickly learn not to eject until the drive quits clicking and the I/O LED goes out. Then the user can eject, and because of the synchronous writes, the filesystem should be consistent. Each access either assumes the media hasn't changed and errors out or overwrites whatever's there if it has, or carefully checks at least the filesystem GUID and possibly re-walks the directory tree before writing a new file, depending on how paranoid the author is about assumptions that the user won't unexpectedly change media underneath him. For DOS, drivers were very low level and individual apps implemented much of the logic themselves. That's why each game came with its own configuration method for setting video, sound card, mouse support, etc, and why many generic soundcards for instance had modes that emulated more popular cards, since most games only implemented support for a few of the most popular cards. Win95 was the first widely used platform that presented a general hardware interface API to write to at a higher level, with mid-level driver layers between the actual hardware driver and the interface W95 presented to the app, such that apps could write only to the W95 hardware access API, instead of to a half-dozen or more individual hardware driver APIs. The existance of those middle layers and the fact that apps were now written to the W95 API made it easier to implement pnp as well, and that's where the technology really took off. >> In my opinion, probably the best way for software like kde's device >> notification is to ignore floppies entirely. > > Probably. Do devs need to actually have floppy drives to be able to > implement this eminently logical but currently missing option? Well, in that bug you see requests for and posts of the solid logs, which should (hopefully) give the kde devs the information they need to figure out what to actually ignore. However, at this point the focus is increasingly on kde frameworks five, with an early release of the base framework and initial 5-frameworks API freeze planned in early 2014, after which the app-level implementations will start to appear. (As discussed in other recent threads, frameworks five will likely have independent individual apps or category releases, which may or may not be version-synced to the core frameworks 5 releases. My guess is that some apps will version-sync, others won't. Apparently plasma is planning to roll out its frameworks-5 support as plasma2, for instance, with the plasma in kde4 being referred to as plasma1.) As a result, it's increasingly likely that particularly the more complex bugs will only be addressed for kde frameworks five. Given the interplay with solid in this case, and the fact that the device manager is a plasmoid and plasma for kde4 is already announced to be in feature-freeze pending 5/frameworks, bug-fix-only for kde4, my guess is that it's unlikely there'll every be a fix for this in kde4. Tho it may well be that a simple "ignore floppies" checkbox might still make it into kde4, if there's little actual code needed to parse the solid results and figure out what results are actually floppies so they can be ignored. If it's more complex than that, however, particularly if solid changes are needed in ordered to get the needed information, almost certainly 5/frameworks. >> What /is/ your actual use case for floppies? > > Floppies don't need software to allow removal/ejection. They have a > readily accessible button. They can be removed and inserted easily and > completely while the machine is powered down, so that when it's powered > up, the system doesn't jump right into an OS installed to non-removable > media that needs to be shut down before powering back down. Thank you. I won't go into each one but it was an honest question and I respect your equally honest answers. =:^) But I can't resist a comment on some of them, like this one. =:^) Rather than relying on the "hack" of an inserted floppy to prevent the system from booting all the way, when I need to, I either change the BIOS boot option (either one-time using the appropriate BIOS hotkey, or change the BIOS default), or hit a key in grub to stop its automatically booting the default, or change the grub default to something other than boot my main gentoo install. To me, that's far easier than fiddling with a floppy that I might not have used in a year, and that for all I know, might not even still work. (I have the cover off the machine far more often, and perhaps I bumped the floppy flat-cable or unplugged it for some reason and plugged it in backward when I replugged, or something. Not to mention the dust that has accumulated in the drive mechanism itself, making actually using it on a floppy a risky proposition of damaging the floppy.) But if you find it more convenient to use the floppy for that purpose, more power to you. I won't argue with what works for you on what is after all your machine, not mine! =:^) > Floppies can be made bootable in mere seconds, not requiring complicated > installation of a big operating system, or a big complicated application > and operating system to run it to perform the task. With an appropriate setup, making USB sticks bootable is just as trivial (basically format and copy a few files, or copy a pre-made image over, leaving the rest of the stick blank if desired), and while burning a CD does require an additional step to create the ISOFS before burning it to the actual media, with the appropriate tools that's entirely automated. Meanwhile, keeping floppies around is a pain, and the last thing I did use floppies for was to update the BIOS on my old system (2003 vintage) before its capacitors eventually popped, using FreeDOS, which I had to google for and then download an appropriate floppy image from the net for. Then I mounted that image as FAT on loopback to copy the BIOS updater executable and bin image to it, before umounting the loopback and using dd to copy the entire image to the floppy. To me that's /way/ more hassle than simply formatting a USB drive and copying a few files to it, or using something like k3b to build an ISO and burn it to CD, checking the make bootable option while I'm at it. But again, your work flow and machines, and I won't argue with what's easier for you. I'm simply noting alternatives here for others who may come across the thread via google or whatever. > Compared to OM drives, floppy drives have proven themselves far more > reliable on average long-term. Absolutely contrawise experience here, and this one's probably the thing that really killed floppies for me. But part of that very likely has to do with the environment one is doing their computing in. I'm in Phoenix, AZ, with summer high temps between 45 and 50C in the shade (~117-118 F normal summer high, 122F=50C record), and if I'm gone for the day I have the AC (and computer) off, saving gobs of electricity, but at the cost of exposing everything to temps that likely exceed 50C at times. In that environment, it wasn't unusual for me to pick up a floppy and find the disc inside was baked in-place. Even if it was still movable, exposure to those temps often damaged the data, such that after a couple summers, the floppy was no longer readable and could not hold new data either. By contrast, CDs kept in their case might degrade a bit faster at those temps, but if burned at a slow enough speed, the data will last several years. And of course there's those millennial disks, or whatever they're called, that are supposed to be good for 25 years or more, if I wanted long- lasting archive quality. But USB flash or portable hard drives are definitely a better choice there. I've had mp3 players and thumbdrives still give me readable data seven years later, and the same for hard drives. I believe flash read life is estimated to be in the decades, if you're not writing to it (that's flash's weakness, a limited number of writes) and you don't have the media physically falling apart due to simple wear by then. In a more reasonable environment, particularly in a temperature controlled environment where temps rarely exceed 30C (86F) or fall below 10C (50F), floppies are likely to be a far more reliable solution than they were for me here, and I do remember them being more reliable back in the day (when I lived elsewhere, with rather less extreme summer heat), but optical will degrade slower at those temps too (tho scratches will obviously still be an issue), such that I guess 3-5 years isn't unreasonable for a floppy. But flash-based drives still win this one, hands-down. Never-the-less, it appears floppies are quite reliable /enough/ for you. > Floppies, unlike common multifunction diagnostic media, having only one > utility installed, can be booted into to do their thing without working > keyboard or mouse. e.g. memtest THAT is a valid point. Of course, it's quite possible to burn a single utility CD or copy only one utility to your USB stick too, but because they're so much bigger capacity-wise, even if CDRs are cheaper and more commonly available, it still FEELS like more of a waste to just put that single utility on a CDR that will hold so much more, even if it's actually cheaper to do, than to put it on the floppy that won't /hold/ much more. > Virtually all my systems are multiboot. DOS is good enough, and faster, > for various things, does manage somehow to automount floppies when > inserted, and does not resist ejection via press of a physical button. Well, it's not so much automount, as DOS lacks the concept of mounting/ umounting at all, and without media-change detection, either simply blindly writes over whatever's there, or requires the app to do the filesystem GUID verification and/or rewalk the directory tree itself. And the fact that blocking physical eject on a floppy simply isn't possible, has I'm sure resulted in quite a few corrupted floppies over the decades, until the users involved learn the hard way not to do that. The same issue of course applies to USB attached devices... As for optical drives, the ones often found on laptops and in media player hardware (cd players, integrated display/dvd-players, etc), that DO have a physical eject button, are nice. But yes, I too have been frustrated with that CD still in the internal CD player on the computer, that I have to turn on (that's where the hotkey to go into BIOS or to cancel the grub autostart timer comes in) in ordered to properly extract the CD. So I can certainly appreciate that point. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman ___________________________________________________ This message is from the kde-linux mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde-linux. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
