[kde-linux] stop empty floppy drive announcement

[Duncan]

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