Re: [kde-linux] stop empty floppy drive announcement
- Date: Wed, 13 Nov 2013 20:28:01 +0000 (UTC)
- From: Duncan <1i5t5.duncan@xxxxxxx>
- Subject: Re: [kde-linux] stop empty floppy drive announcement
Felix Miata posted on Wed, 13 Nov 2013 12:36:30 -0500 as excerpted:
> On 2013-11-13 12:08 (GMT) Duncan composed:
>> 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
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
>> 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
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
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,
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.
More info: http://www.kde.org/faq.html.