If he could get the drive eject button to unmount the SD card, this would actually be more functional that current tech.
It bugs me that unmounting SD cards / USB drives and physically removing it are two seperate actions. It's a regression in usability after floppies and CD-ROMs.
> If he could get the drive eject button to unmount the SD card, this would actually be more functional that current tech. It bugs me that unmounting SD cards / USB drives and physically removing it are two seperate actions.
To be fair, this was always a problem, also with old computers and OSes. There was no link between pressing eject and magical things happening in the machine to commit data. The data was simply already committed so there was no need to have any additional layers of security.
The difference between then and now is that new computers have enormous amounts of memory and use it to provide write-back caching. This means the OS can tell applications that data is committed when it's not. This is an OS level decision which is done for performance and has nothing to do with the physical eject-buttons on your devices.
You may call this a small nit, but I think it's an important one. The eject-button on old machines would suffer the exact same problems if it used an OS which offered write-back cache.
You could say old Macs didn't have this problem, which is true. But it didn't have an eject-button. It relied on the OS doing that. And then instead you had the problem of people not being able to get their disks out of their machines if the OS for some reason refused to release it (or that users didn't realize they had to drag the disk-icon to trash).
> the problem of people not being able to get their disks out of their machines if the OS for some reason refused to release it
My first time on a Mac, about 1990, I felt pretty confident having plenty of early PC experience. A graphic designer I shared a house with had left me alone with (and permission to use) her Mac.
I quickly discerned there was no software of interest actually installed, but found a floppy that looked something like a game. It wasn't, and I went to hit the ... wait, there's no eject button?
After a fruitless few minutes during which I failed to notice the eject key on the keyboard (of all places!) I eventually opted for tweezers, and gently teased the floppy out of the drive.
Imagine my surprise when I restarted the Mac to find it was unable to start, having apparently completely forgotten about it's own HD! The thing had to go back for servicing before it would even boot properly, iirc.
My reputation as the house's resident computer expert was severely impacted, needless to say.
One of the things that drove me nuts using the earlier Macs at my college was the lack of an eject button. Sure, I understand the reasoning now, but when some crappy Hypercard project I was bungling made the computer freeze, I had no way to remove the floppy short of rebooting the whole computer and waiting or hunting around for a paperclip to push into the little manual eject hole.
Still, seeing how many people in my office will just pull USB flash drives without ejecting them I almost see the appeal now.
I loved how only of my early optical drives had a notch tastefully designed into the front that allowed me to pry the drive open with any sufficiently rigid object, rather than deal with the "pointy thing into small hole" that everything later on had.
After hearing Woz talk about how the early Macs were resistant to malware because most of the OS lived in ROM, i find myself thinking that rather than the Amiga being the last of the "micros" the Mac ended up being so. This in that it was designed more like a C64 than a PC.
We also had that fixed with CDs/DVDs when the OS could lock the drive and handle the eject button any way it liked.
I didn't quite like the way Linux handled this though, not allowing the disk to be ejected as long as any file descriptors were still open, which meant you had to hunt down the processes keeping them open.
But it would be extremely helpful for writable media like flash to be able to do full write-back caching and only flush the cache when the eject button is pressed, then EBADF any further reads or writes to any open file descriptors.
This makes me wonder what those two holes in the shroud of USB A style connectors are for. After a bit of googling it looks as if they are to provide a bit of tension against removal. I'm sure you could repurpose them to lock the usb drive into a USB port.
Good catch! I had completely forgotten about that one.
For those completely oblivious to this: This was actually not about getting data written to disk, but to physically protect the drive from its own mechanical construction. The "park" command would cause the harddrive to move its magnetic read and write-heads away from the internal platters, so that when it was powered down and the disks stopped spinning, the platters would not be damaged or experience needless tear and wear.
Yeah, I'm glad we no longer have to do that exercise.
Always, always sync -r after writing to a zip drive on Windows. Even minutes after you think it is finished writing, do not trust the OS to have finished flushing to disk.
> The difference between then and now is that new computers have enormous amounts of memory and use it to provide write-back caching.
Also, not syncing to disk immediately can improve the lifetime of flash media, which wasn't a concern in the old days.
However, I'm somewhat disappointed by current filesystems not using journaling to make it possible to pull out a USB drive without harm (other than losing the latest writes).
You could select the disk and then "Eject". Dragging to the trash was a shortcut to unmount and eject.
As for Macs not having the problem, this doesn't require qualification. Not only did Macs not have the problem, they treated disks as logical _volumes_ rather than physical devices. If you ejected a disk mid-save on a Mac it would complain, and if you inserted the wrong disk it would reject it and ask for the right one. If you did the same thing on a DOS/Windows machine it would correct the new disk (and leave the old disk corrupted too).
Similarly, you could copy files from one disk to another without having two disk drives in Finder (it was a pain in the neck, swapping the disks, but it worked). Other computers needed special software and relied on the user to insert the correct disk.
This advantage continues to this day. Windows still refers to devices by physical location.
> Windows still refers to devices by physical location.
Nope, not since NT. I learned that the hard way when moving a HDD containing Win2k around. Even though it was hooked to IDE master it would come up as D: as that was what it was assigned after it got formated with NTFS.
You can go into disk manager and assign a partition any letter than is not already in use.
You can even mount a partition into a existing FHS, much like on unix, but i can't say i have seen it used often.
Basically the letters are there for backwards compatibility.
To be fair, this was always a problem, also with old computers and OSes. There was no link between pressing eject and magical things happening in the machine to commit data
There was on the Apple Lisa. Or rather ejecting a disk was something you did in the OS which made sure everything was written/closed before allowing the disk out.
Yeah I mentioned that in the end of my comment, together with the other issues that would typically lead to.
It was definitely confusing to new users: Insert a disk was something which anyone could do, since it only involved simple movement of a physical object, but ejecting it required you to know and understand the OS.
This was quite an "impedance mismatch" between what should ideally be two symmetrical actions, and I remember I had to help out my mother quite a few times :)
You're right - the only solution would be a captive eject button, which did all of the write resolutions before allowing the disc to physically eject. And that would come with other usability problems, like users getting angry when they push eject and their card doesn't come out immediately.
I remember when Apple had the soft-eject floppy drives that would only eject after the disk was properly unmounted, and then they even did soft-eject PCMCIA slots. I was surprised when their SD card slots weren't soft-eject.
Before resorting to a paper clip, the trick was to reboot while holding the mouse button. This still works today with CDs if the CD is damaged and the OS gets caught up trying to read it.
I actually remember frantically searching through my uncle's Mac manual after I inserted a corrupt boot disk (or possibly not a boot disk at all) and then couldn't get the thing to boot, which meant I couldn't use the soft eject.
I don't remember soft eject slots, my powerbook g4 had a button, and I think the expresscard slots on later macbooks just used the same kinda mechanism sd cards use.
I really wish there had been a bigger push towards some kind of standardized packet writing for DVDRW (CDRW had this issue with a one use calibration track), so that they could behave more like floppies (drag and drop file transfers etc).
The media itself is fully passive, while a SD card or thumbdrive have logic sitting between the USB interface and the raw flash. Thus optical media can be "rescued" by simply getting a new drive.
And you really need to mistreat a optical disc to make it completely unreadable.
Or perhaps someone could buy the minidisc tech off Sony and resurrect magnet-optical storage?
On Windows, they're mounted sync by default, so you can just remove them. Of course, if you do so while it's writing, you'll have a problem - though this was the same with floppies.
Windows used to require you to 'eject' but doesn't any more, which I think is due to the above. Please correct me if I'm wrong.
I have never done it, and never had any problems. I always assumed it was a feature that only was needed for devices that had some sort of physical requirement for safe shutdown (spinning rust or the like).
I recall some distros tried to mount USB drives with the sync option back in the early days of USB media.
Problem was that this, in combo with FAT, would basically kill cheap drives lacking wear leveling.
This because every write action was accompanies with a allocation table update. And thus whatever flash cells housed that table would see a massive amount of writes.
Actually i think the mount man file still have a warning about this in the sync option entry.
I think that it depends upon file system and the options selected when you format the drive. Windows defaults to options that mean you don't need to 'eject'. However, if you formatted on another OS you can select options that mean a safe unmount is required before yanking the drive out of the socket.
I am so paranoid now about removing USB drives after I accidentally removed one while it was still writing to the drive (which I had no idea because there was no LED on the drive) and it bricked the entire device.
I generally wait until my computer has shutdown completely now before removing any important drives, just to be sure.
Generally if I'm worried about completing a write, I'll just open a Terminal and type `sync` (with a `&& sudo purge` on OSX), and then, as soon as that returns, yank the drive.
I don't even bother to unmount it; what would unmounting add, if the OS can recognize that the device is gone and clean up its mount tables? Is there some filesystem that waits until unmount to recalculate indexes or something?
(Okay, sure, the OS could tell me the disk is in use because I've got an overlay filesystem mounted on top of it, and would I kindly wait forever for that to stop being the case. But screw you, OS, I need this USB. Just send the FUSE server or SMB daemon or whatever a SIGPIPE.)
Filesystems often have a 'dirty' flag which is cleared as the very last write when unmounting cleanly, to let the OS know whether the filesystem might need to be checked before mounting it next time.
Also, unmounting helps you to be confident that nothing's started doing more IO since you ran sync.
Although this is a fun idea, it's just putting an SD card into a 3.5" floppy disk case and then wiring up the read/write head with contacts to make it appear like an insertion of a normal mass storage SD card.
A more accurate title would be "putting an SD card in a floppy disk case"
Drat, I was hoping it was like a cassette tape adapter and would work in unmodified disk drives. Do floppy disks advertise their own size, or do systems assume that they can only hold 1.44mb? You might need special driver support I guess, which takes some fun away.
They advertise their size. Back in the day, there were programs that let you reformat disks with tweaked parameters -- sectors per track, interleaving, etc -- so you could get a greater capacity. Windows 95 was shipped on a disk formatted for 1680k, for example [1]. Off the shelf disks were hit or miss as far as how big you could reformat them to, with some able to handle close to two megs, and others not able to handle much more than 1.44mb.
Exactly, it reminds me of the time when I formatted a HD 3.5" floppy to 2M with the aforementioned excellent 2M3.0 tool by Ciriaco García de Celis (Facultad de Ciencias de Valladolid: Grupo Universitario de Informatica). It provided 500 Kb of more available data beyond the 1.44M (more then fdformat).
From a 2M dos bootdisk I launched a stripped version of win3.1, extracted the WIN3.UC2 archive to a ramdrive of 6M or so and launched it. In this way I could edit my assignments with wysywig WRITE.EXE instead of the dos based WP51 on the library computers. People were wondering how I could have windows running as it wasn't installed.
So nowaydays we have 100000M instead of 2M in a smaller package.
Before those, you had double density "DD" disks -- and extended density "ED" disks after that. With the sleeve encased floppies you could even throw in single-sided and double-sided variants. Growing up, we had a lot of 1200KB 5-1/4 disks. IIRC, they were enough cheaper than 1440KB 3-1/2 disks for close to the same storage.
It worked by combining two completely separate techniques; the first, using more tracks, is pretty self-explanatory --- a lot of floppy drives, despite officially supporting 80 tracks, could actually move the head to 81st and 82nd tracks (rarely, even higher), and since the media was in the form of a uniform magnetisable disk, that let an extra 2 tracks worth of data be accessed.
The second technique was to reduce the number of sectors per track and the gaps between them, by making each sector bigger. To ensure interoperability with different drives rotating at different speeds, there's actually quite a lot of "padding" between each sector, as well as ID/CRC data for each one. If I remember correctly, in the highest capacity mode, 2M wrote only one huge sector per track instead of over a dozen in the usual format. This is similar to how hard disks have transitioned to using 4KB sectors internally, instead of the traditional 512B.
Sort of yes, sort of no. Later drives were just black boxes with their own on-board logic that read metadata off the disk, sure. Early drives, though (of the 5.25" variety) relied on the first track of the disk to contain what was basically the disk controller firmware†.
As such, you could actually teach an old drive new tricks by coming up with a firmware that used a better encoding scheme, and then encoding the rest of your disk with that scheme.
† (though it ran on the CPU, rather than some microcontroller in the drive. "DOS" stands for Disk Operating System for a reason: a large part of it is a set of routines programs can call to make the CPU micromanage the read-head and stepping motor of the dumb disk-drive controller, with concepts like "files" being a mostly-optional thin wrapper above that, rather than some impenetrable abstraction layer.)
"and others not able to handle much more than 1.44mb"
My first experience installing Linux was using a bunch of disks which were unable to handle even 1.44MB (even though they were sold as 2HD). I couldn't tell, of course, and I had no idea why my install kept on failing or generating errors part way through the installation process :(
I would like to see the 3.5" floppy do a comeback, for instance as a 1TB+ flash drive. It is large enough that you can comfortably handle it physically and label it, maybe it could be a small throwback to the age of floppies and zip drives.
And nowadays the write back buffer could be on the device itself, and as you hit the 'eject' button it could use the power from a small capacitor to commit it to the disk. Thus no separate 'eject' in the operating system - pop it out and go.
They could replace Blu Ray with this new format, so all those sci-movies in the 80ies where there are films on floppys - those will turn out to be right.
At that size you could even get fancy and throw in an e-ink re-writable label, which could be used for anything from archive manifests to album art. No need for power on the disk, since that can be provided by the drive during write.
I love that we can fit tens of GB in a space the size of a fingernail, but it does get rather fiddly to pass around. USB thumbdrives are nice, but are thick enough that they don't really stack up well, or fit into folders and binders nicely.
The 3.5" form factor really is kind of a sweet spot for more than just nostalgia, IMO.
As cool as that'd be and my first thought as well. Then I realized the fat that most all laptops and tablets out there that Re too thin to ever handle something like that makes me think it's less likely to happen.
Ah, disappointing. I was expecting some giant array of them all running in unison and making beautiful "music". Sorta like the radiohead hardware hobbyist video https://youtu.be/pmfHHLfbjNQ
What would you expect the word "disappointing" to mean, other than that the speaker was disappointed, i.e. that their expectations, which are necessarily subjective, were not met? That's the exact thing the word means!
What is it about GP's comment that makes you think they assign blame?
Well OK, in Germany, telling others, that something was disappointing is most of the times not only a subjective statement, but also a negative rating/non-recommendation.
So if you wanna say, that things were not what one expected, one must say so explicitly, to make it clear, that this is not generalizable.
I was struck by a talk by Kirk Knoernschild in 2013 where he pointed out that there is now a generation of users who don't know what a floppy disk is... Yet it is still the "save" icon in nearly every application.
It would have never occurred to me, to hack something like this together. I really love it when someone comes up with creative ideas to reuse old stuff and mixing in some new things as well.
Would love to see a whole lot more of repurposed, upgraded old tech. VHS, audio tapes, you name it. My latest thrill is the pico8 project. Low res, 8bit games but with the extra compute power of today, it yields funny results.
I used to have a LS120 SuperDisk drive in my computer. I really liked the idea but it was useless because no one else had them. I think I still have the drive and several disks stashed away somewhere.
The 1GB was later or implied compression IIUC. First models, in the floppy disk era, were 300-400MB. Still would have been a beautiful computer storage device, but Sony sonied.
True, they called it HiMD. The drives could also up-format the older MD disks to get a bit more storage.
That said, i think there was a version of the original MD format sold as a data drive in Japan. I think Sony had a model or two of their Vaio laptops with it built in.
That said, what basically sunk the format was slow write speed and that the Sony Music tail was basically wagging the Sony Electronics dog. The MD was from day one laden with DRM, and the HiMD took it even further (want to put those MP3s on there? Had to format convert to Atrac via some crazy program. And the only way to get them back out was via the analog hole).
This just at the time as large capacity flash was coming to market, and you could dump any random MP3 onto them with a drag and drop operation.
> Had to format convert to Atrac via some crazy program
The HiMD machines did not make nice mp3 players because they really weren't meant to be that. Only the final HiMD decks had mp3 codec.
I never converted from mp3 to atrac because atrac was a better codec. I didn't like feeling like I was listening to computer files anyway, and usually dubbed from a cd player.
> the only way to get them back out was via the analog hole
The last SonicStage update lets you download audio. This is important because these devices were used to record original content.
On paper a simple flag, but stringently enforced by every program and consumer deck out there (professional decks where a different matter).
As for what was better or worse i will not get into. MP3 was already turning into the de-facto standard, and thus Sony did themselves no favors by having people go the long way round.
I guess i missed the news about the last Sonicstage release, as by that time i had given up on how Sony was handing tings.
Right, but on the CD side, Sony had no issues selling generic CD burners even if the Sony Music business probably had issues with that. I don't know how slow MW writes were, but I'd be surprised if they were slower than FD especially with the later seek time. Add weak material leading to regular data corruption and I'm really thinking that pure data MDs would have make a different world.
It bugs me that unmounting SD cards / USB drives and physically removing it are two seperate actions. It's a regression in usability after floppies and CD-ROMs.