SoylentNews is people
SoylentNews
Submitted via IRC for Bytram
How did MS-DOS decide that two seconds was the amount of time to keep the floppy disk cache valid?
MS-DOS 2.0 contained a disk read cache, but not a disk write cache. Disk read caches are important because they avoid having to re-read data from the disk. And you can invalidate the read cache when the volume is unmounted.
But wait, you don't unmount floppy drives. You just take them out.
IBM PC floppy disk drives of this era did not have lockable doors. You could open the drive door and yank the floppy disk at any time. The specification had provisions for reporting whether the floppy drive door was open, but IBM didn't implement that part of the specification because it saved them a NAND gate. Hardware vendors will do anything to save a penny.
[...] Mark Zbikowski led the MS-DOS 2.0 project, and he sat down with a stopwatch while Aaron Reynolds and Chris Peters tried to swap floppy disks on an IBM PC as fast as they could.
They couldn't do it under two seconds.
So the MS-DOS cache validity was set to two seconds. If two disk accesses occurred within two seconds of each other, the second one would assume that the cached values were still good.
I don't know if the modern two-second cache flush policy is a direct descendant of this original office competition, but I like to think there's some connection.
(Score: 2) by Rich on Wednesday September 25 2019, @01:56PM (39 children)
The simple rule back then was "don't touch the drive while the red light is on" - because it might also have been writing. Personally, I'd prefer the Mac solution with motorized eject (and of those the early Sony variant where the eject also spring-loaded the insertion), but if that is a no-go because of overwhelming installed hardware base, I think the red-light variant does just fine. There is the race condition of the user longing for the medium while a write starts, but that could be migitated by first switching on the light, waiting a bit and then writing. But mostly it wasn't a thing, because the semantics were to say "Save to disk" and then the user would diligently wait until the program had written its data. Computers just didn't want to access floppies between loads and saves.
We got the whole mount/unmount heap of problems because the heritage of the multitasking systems did not consider the possibility of interactive hot-plugging. Remember how hard it was for early Linux to deal with that, and the kludges like "Supermount"? It would be easy for today's technology to make the whole media swapping totally transparent, plug & play at will, with transaction safe journaling storage (rather than FAT-descendants), except maybe that certain media with "smart" controllers (e.g.USB sticks) might be upset if they suddenly lose power with a pending write. In that case, still, after all these years, the red light seems to be a totally cromulent solution.
(Score: 2) by RS3 on Wednesday September 25 2019, @02:23PM (37 children)
You're giving me some ideas. It would be easy to include a capacitor in a USB stick to provide power long enough to finish a write of whatever is in a RAM buffer. However, filesystem might still be corrupted if you interrupt things like FAT table writes, which usually happen last.
I like USB sticks with LEDs so you have some idea that there is activity and don't yank it (if you're too lazy / ignorant of the "remove safely" thing).
The floppy light showed that the motor was spinning. The controller / OS always spins up the motor, waits, then reads or writes, then waits, then shuts off the motor.
My unhappiness with the motorized eject was disks getting stuck in defective drives / dead computers. I don't remember them having an eject hole like optical drives do (remember them?) and more than once someone would ask me to rescue their important disk from a MAC. For some reason a 12 lb. sledge hammer was always my first thought.
(Score: 1, Insightful) by Anonymous Coward on Wednesday September 25 2019, @03:04PM (4 children)
MAC is a hardware address. A Mac is a computer.
(Score: 2) by RS3 on Wednesday September 25 2019, @03:33PM (3 children)
My first ATM card was called MAC: Money Access Center. It's good we have pedants like you to keep the world running smoothly. /s
(Score: 2) by EEMac on Wednesday September 25 2019, @04:24PM (2 children)
I've always wondered why people call Apple computers "MAC"s. "Mac" is short for Macintosh, not an acronym. But enough people do it (and have always done it) that there's some mental quirk there . . .
(Score: 1) by MindEscapes on Wednesday September 25 2019, @06:47PM
Macintosh
Apple
Computer
:)
Need a break? mindescapes.net may be for you!
(Score: 2) by RS3 on Friday September 27 2019, @01:43AM
It's possible that people who are Mac fans are also more high-strung, very detail-oriented, maybe almost persnickety. And that's okay, but don't expect everyone to be like that.
I don't care so much. All my life I've had to learn that there are no absolute rules in English. In some cases it seems there are more exceptions than rule-abiding.
Mac, MAC, who cares- it's an abbreviation anyway. I would think the pedants would be more annoyed with "Mac" rather than fully "Macintosh".
(Score: 2) by DannyB on Wednesday September 25 2019, @03:05PM (17 children)
They did have the eject hole to be used by a bent paper clip. At least on macs. I can't speak for PCs.
I avoided the entire early PC era and was using classic Macs. I loved the motorized ejects. They rarely failed. And if so, or even if a box was powered off and someone then inserted a disk which spring-locks into the drive -- you can always use a bent paper clip poked into a tiny hole near the eject button to pop the disk back out.
An idea for a new design of USB sticks. But I'll post that as a separate reply.
The lower I set my standards the more accomplishments I have.
(Score: 2) by RS3 on Wednesday September 25 2019, @04:00PM (16 children)
As I posted, I'm aware of and have used many times the said holes and straightened paper clips in optical drives, but I don't remember them in early Macs (and it's been far too long ago). I actually have a Mac Classic, and an original iMac, so I'll investigate them and post my findings. I just remember having a difficult time getting people's disks out of dead Macs. I certainly didn't know of eject holes' existence in those days, so it's possible I missed them, or had no clue what they were.
I guess I'm too much of an engineer- I did not like the motorized ejects because 1) you have to ask the computer to do it for you (mouse clicks or KB shortcuts), 2) more things to go wrong, and 3) I just like pushing the button when I want the disk out- UI, human in control.
I generally loath over-automation, and machines having the power over humans, and if you read any of my comments on 737MAX MCAS here and on /., you'll know how much and why (it gets carried too far and people literally die.)
A small first-hand example: I consulted briefly on helping someone with a 60-ton press in a small company. The press was fully open to human body parts, no light-beams, dead-man switches, doors, gates, etc. It was fully controlled by a crappy PC running a very kludgey LabView- wiring very poorly done, programming even more haywired. Oh, but there's a nice big red E-STOP button. Great, right? No, the E-STOP button does NOT shut off the pump and open the relief valve, rather it asks the software if it's not too busy or hung in a loop, if it wouldn't mind opening the press. Yes, these things are big issues for me. Where's OSHA when you need them.
(Score: 3, Insightful) by DannyB on Wednesday September 25 2019, @04:18PM (15 children)
I remember the original Mac having the paper clip hole from the very beginning. In this image [wikipedia.org] you can see the tiny paper clip hole near the drive opening.
In 1984, at least in my world, we thought the Mac had amazing potential to change things. Lots of great ideas. One of which was that the software had to eject the disk -- but that there was an emergency mechanical way if needed.
Aside: once I became a classic Mac developer the rest of the 80's and most of the 90's were a blast. Especially the late 80's where I lived in an R&D playground. The 68000 series of microprocessors were a pleasure to program in assembler. Long file names. No drive letters (drive C). Files having extended attributes. Actual plug and play long before PC's got that as a trademark to describe a feature that actually didn't live up to that name. And I could go on and on. Fun days.
The lower I set my standards the more accomplishments I have.
(Score: 2) by RS3 on Thursday September 26 2019, @02:53AM (7 children)
Thanks for that link and the pic there. Yep, there's the hole! I don't remember being aware that the hole was for an eject rod / pin.
No question- MacOS was way ahead of its time. But really that's not true- it was correct for its time- everything else was far behind. And still lags!
I was bummed when Apple abandoned MacOS at 9.22. I wish I knew why. I still have some older disks with an updated 9.22 that are loaded with tons of apps.
That's cool you did Mac development. I never got into it. When I first heard about the metadata and some other aspects it seemed too confusing, and I was doing other kinds of work- I never worked anywhere that was anyone was doing Mac app development. I had a friend from college who worked for one of the Mac app companies that made a suite including drawing... Oh yeah- Cricket Draw. Sadly Cricket doesn't even have a wiki page.
(Score: 3, Interesting) by DannyB on Thursday September 26 2019, @02:16PM (6 children)
I'll just say: ever hear of a screen sharing product called Timbuktu? (think VNC) Just a few years back, I got an email to join some of the old developers from long ago for a "wake" for that product, which was finally dead. It was a fun reunion. I wrote that code from August 1987 to Dec 1 1987 when it shipped 1.0. I wrote the entire back end "system service" you would call it today. Another co-worker wrote the "desk accessory" part with the UI since he was new to Mac development. I, at that point, could write the system service, since I had a few years under my belt and knew the inner workings quite well. I had to patch every single QuickDraw call, with the potential to capture every drawing operation and send a message for it over the wire to a remote machine which would draw the same things. The 68000 was wonderful. Nice 24 bit clean flat address space. Later 32-bit. Meanwhile we were always laughing at the PC guys hamstrung by Intel's segment registers. But the list of ways MacOS was superior was so long I have forgotten many of them. I was a card carrying Mac fanboy and we were all very smug indeed.
Aside: this is one of the reasons why, today, I snicker at guys (especially on SN who should know better) who think I don't understand low level things just because I now use and enjoy Java, Lisp and other higher order abstract languages. Back in the day I spent $495 of my personal money (probably $1000 in today's money) to buy Macintosh Common Lisp -- and I loved it! I got more enjoyment for years out of that single purchase than I could have imagined. And you could write Mac GUI code in it. :-)
I still have tons of old Mac disks, and a dusty but last known to be working PowerMac G3 (not tower, but desktop box style with monitor sitting on top). It belongs to my company, is in my office, but probably would be mine for the mere asking.
I was also bummed about OS X. That is when Apple and I parted ways. I do understand why though. Apple was already on its third attempt at developing a modern OS. I wish they had acquired BeOS instead of NeXT. But I guess they just had to get Jobs back. Which IMO was a mistake. That is when Apple turned into a fashion company instead of a technology company. There WAS A REASON why Jobs was stripped of power. He had goals that limited things like color Macs, or having a separate CPU / separate monitor on top, or plug in slots, and quite a few other things -- which Jobs then went right out and did anyway with his NeXT computer. Right at the time of OS X, as Steve Jobs made all my expensive hardware instantly obsolete, I was already studying all about Linux. The timing was perfect. About a year later, in June 1999, after extensive reading, I got my first Linux PC. SuSE Linux 5.1.
The lower I set my standards the more accomplishments I have.
(Score: 2) by RS3 on Friday September 27 2019, @02:02AM (5 children)
I do remember Timbuktu, but I don't think I ever had my hands on it. I salute you, thank you, you did a great thing.
And very cool you're doing Lisp. I have not, but I think I'm missing out.
I did a tiny bit of Forth- in Open Firmware. Someday someone please tell me how someone ate mushrooms and instead of Alice in Wonderland, they invented Forth.
You know what's also funny? The Intel CPU can run in flat mode too, but we kept it a secret. It was too funny hearing the Moto guys' smugness about flat model. :)
Novell's Netware OS ran in pure flat model for speed, and it really was fast.
And truth be told, I actually like the segment (selector) model, but I'm a divide-and-conquer guy so it fits. I dunno, the math never bothered me, and compilers do it for you.
It was all about memory protection, as you know. I'm still not sure why there are problems with memory protection, other than people not coding OS kernels (MS) correctly.
The 68000 had an MMU, iirc. Did that have a memory protection mechanism? Maybe I'll go look it up ... Hmmm, lookee thar, segmented protection. Ahem. Cough cough.
(Score: 2) by DannyB on Friday September 27 2019, @03:25PM (4 children)
If you ever get your hands on Timbuktu, or Timbuktu/Remote, especially in the earlier years from 1987 to about 1993. Just check the About box.
I started dabbling with Lisp in 1986. XLisp on classic Mac. I had purchased a Lisp book, and was learning it. It was fascinating. Then it was amazing. I had to know more. (downloaded XLisp from CompuServe if you know what that is.)
A few years later Apple stopped shipping a monthly gigantic stack of bound paper documentation along with some floppy disks to each developer. Every month. Apple started shipping a smaller stack of paper, maybe only about 1/2 to 1 inch thick along with a CD-ROM. At one point during this time was include a free Perl Lisp. (forerunner to Macintosh Common Lisp (MCL)). That was more amazing than XLisp, so I started using it. When I learned that MCL was based on Perl, I had to buy it for $495, along with CLtL 1. I started buying every decent CL book I could find. The things I learned was amazing. The last, but best book I got was from Peter Norvig: Paradigms of Artificial Intelligence in Common Lisp. (Title was something like that, I hope I'm not mangling it to badly, that was about 1992 ish) Learned about unification matchers. I built my own pattern match compiler which didn't execute the pattern match, but generated a LAMBDA expression which would match. I was working on a similar compiler for a unification matcher, but life called and I never got around to finishing it. At that point, with a kid, I was too busy to play with lisp quite so much.
I wish I had known that at the time. But everything in PC land seemed to be segment registers all the way down. Probably Microsoft is to blame since Netware could do it right.
I wouldn't complain if it were full 32-bit. But compilers just never did quite seem to give you a transparent higher level view. There were always various silly 64 K limitations on either strings, array lengths, procedure sizes, etc. I'm sure a compiler could make these unlimited to the higher level language, and some probably did, that I don't know about.
I seem to think it did but Apple didn't use it. Their new OS would have used it. Apple did use MMU for virtual memory, but NOT for memory protection. Just a consequence of classic Mac OS single process beginnings with no notion of multi-user or even multi process. A bug in any single application could bring the entire system down, and often did. In this case, I could more often than not recover the system in order to save things and do an orderly shutdown. I would push the Debug switch. (A little plastic insert thingy a developer would snap on the side of the machine.) Then type two commands:
SM 0 A9F4
G 0
That would do an "ExitToShell" in the crashed program, and other running programs could often then be saved and shut down orderly before restarting.
Those were fun, fun days.
The lower I set my standards the more accomplishments I have.
(Score: 3, Interesting) by DannyB on Friday September 27 2019, @03:29PM (3 children)
BTW, that SM 0 A9F4 trick was something I figured out. I tried to pass that knowledge around. But this was pre intarwebs days.
The lower I set my standards the more accomplishments I have.
(Score: 2) by RS3 on Saturday September 28 2019, @01:58AM (2 children)
Very cool trick! I never dug into the Mac Classic OS. Wanted to, no time. I rarely had app crashes. :) I can't really remember any. I mostly used it for audio recording, editing, mixing, etc. Probably some video editing too, but I think I had something hotter by then (dual G5 on OS/X).
Yeah, one of the big gripes about Netware was that with Intel in flat-memory mode, there's no memory protection (IIRC). But instruction execution clock cycles are far fewer in flat mode. ("Real" mode is fastest and great if you need less than 1 MB RAM...)
I guess people are unaware, but Intel CPUs have had "PAE" - Physical Address Extension, for a very long time- early Pentiums, or P-II. It's 36-bits of address. Linux finally started using it in "huge" memory mode. Win 7 still won't use it. There's a patch, and I tried it, but it doesn't seem to work, probably because the NT kernel has been updated many times and the patch is old.
So in Mac Classic, "exit to shell" - was it a CLI? Or just that Finder somehow survives and you can restart? (all this is bringing back some very faint dusty memories... of all kinds of cool tools and utilities and tweaks...)
Come to think of it, I rarely ran more than one Mac app at a time.
https://www.ebay.com/sch/58058/i.html?_nkw=Timbuktu [ebay.com]
(Score: 3, Interesting) by DannyB on Monday September 30 2019, @03:16PM
As a developer, I had plenty of crashes.
I am vaguely aware of PAE. My understanding is that it allows a 64-bit OS, with more than 4 GB of memory to map multiple 32-bit processes to a "full" 4 GB of physical memory -- located at different pages in physical 64-bit space. If I had 16 GB of memory, and two 32-bit processes running, they could each get 4 GB of physical RAM. Of course, userland processes get some part of their address space mapped to kernel space as I understand things.
Classic Mac did not have any build in command line shell. In this sense Shell probably meant The Finder. Consistent with Windows terminology (but which came first?) The only CLI was if you installed a (rather large) application called MPW (Macintosh Programmer's Workshop). How this was implemented was very interesting. It was clearly inspired by Unix, but on the single-process cooperative multitasking Mac OS. There wasn't a "terminal" type interface. It was all "Notepad" style editor windows. Hitting Ctrl-Enter would execute the current line as a command. Or you could select any range of text and Ctrl-Enter to execute all of the selection as text. You had pipes and Std IO/Err redirection. Using any Apple or third party compilers you could write simple plain jane text programs in Pascal, or C/C++ and they would work with no GUI -- within the MPW environment. This is how all of the Unix-like tools worked. There was make, link, res and deres. (pronounced rez and derez, like Tron the movie) These were the resource compiler an decompiler. Every Mac file could potentially have a 2nd fork that contained a database of resources. Resources were addressible by type (4 chars) and ID (integer). So a program could use a simple API to load, say, ICON 128, or JPEG 314, or CODE 81. Developers could invent their own resource type with their own custom binary format. There was a language to define binary formats for resources, very powerful, including iterated arrays of binary subtypes with zero or one based indexes -- this made it easy to write high level Rez source code to be compiled into binary resources and added to a file's resource database.
Before PowerPC, all 680x0 apps code were CODE resources within the resource fork. The "data" fork part of the application file was empty. So if you tried to read the bytes out of an application, it had zero bytes of data. When PowerPC was introduced, Apple used some industry standard binary format (COFF? my memory might be fuzzy) and stored that binary format into the data fork of the application -- like Windows and Linux would do. Thus it was possible to build "fat" applications that had 680x0 code AND PowerPC code. But 680x0 code would run on PowerPC (emulated) but PowerPC code would not run on a 680x0 Mac.
Other interesting things about MPW. Pathnames on Mac were the Disk name first, then other pathname elements separated by colons. So if disk icon on the desktop was named "Hard Disk", then a path might look like "Hard Disk:My Letters:Dear Aunt Jane 6/13/1987". Note no filename suffixes. Ever. Every file had a Type and Creator attribute -- again both 4 characters (eg, a 32-bit integer to a developer). The TYPE indicated what kind of data a file contained. But the CREATOR indicated which application should be launched. Unlike Windows and Linux, you could have several TEXT files, but one of those might open in Notepad, and another might open in MPW. You could still open ANY TEXT file in, say, MPW, but double clicking that file's icon might launch it to a different application depending on the file's CREATOR attribute. Think of it like if Linux and Widows had TWO file extensions such as MyFile.txt.notepad, or YourFile.txt.mpw. The 2nd suffix indicates which app gets launched, while the first suffix indicates what type of data the file contains. Two different JPEG files might launch into say, Paint or Photoshop. Also the Finder would display the file's Icon based on BOTH the Type and Creator together. The app that is the file's creator would have resources specifying what a Photoshop JPEG icon should be, where Paint would have its own resources specifying what a Paint JPEG file should be. Yet Photoshop might also open GIF files, and would have it's own notion of what a Photoshop GIF icon should be. While, say, GraphicConverter would have it's own unique branded family of icons indicating what it's GIF icons should look like. So all Photoshop icons looked like they went with that app. But all GIF icons looked like they contained a GIF. I hope that makes sense.
I can't say I recognize that bag. But that doesn't mean it wasn't created after I went with the accounting software -- which in hindsight was a great move.
During the Timbuktu days, I went to trade shows, etc. Went to a MacWorld award show to receive the MacWorld annual award for Timbuktu/Remote 2nd place -- I think that was Jan 1993 as I recall. I had to have someone at home tape (vhs) Babylon 5 pilot movie so I wouldn't miss it. Or maybe that was a separate trade show. It's somewhat blurry now. But I do remember that when Kosh first meets Sinclair in the hangar bay, Kosh greets him as "Enteelza Valen".
Mac developers had all kinds of cool utilities. It was very easy to change simple things like a file's type/creator, for example. Or even in batch -- by drag dropping all of their icons onto the icon of a utility program that did this. It was really cool stuff. Sadly Microsoft couldn't copy more of it into Windows because they were locked into the drive letter scheme, and the MS-DOS compatibility, short file names, etc.
The lower I set my standards the more accomplishments I have.
(Score: 3, Informative) by DannyB on Monday September 30 2019, @03:30PM
A bit more about MPW.
On a command line you could of course use file names, much like you would in Bash on Linux.
Text files in MPW would remember their "selection". That is, if you selected a range of text, then saved the file; when you re-opened that file later, it would still have that range of text selected.
Now, on a command, if you referred to a named pathname of a file, and suffixed that with .S (eg, dot S), but the S wasn't really the letter S, but some other squiggly unicode character. (But before unicode) This syntax didn't refer to the text within the named file, but rather to the selected text within the file. So, suppose I used I/O redirection to redirect Std In, Std Out or Std Err to/from some file name with the ".S" suffix, it redirected into our out of the selected text. When writing to the selected text, the text selection range would collapse into zero characters, and then expand with the written characters replacing what was the selection. This inserted what was written into the space occupied by the selection. I hope that made sense. It was very cool.
Example: I have a large file of text. I select one line (or indeed only one character, such as a space). Save the file. Now use a command like:
foobar > myfile.S
Then the single line or space selected in myfile expands and grows to however much text the foobar command generates. Got that? When I later open 'myfile', that single selected space character is now a large amount of selected text, but all other text within the file, both before and after the selection remains fully intact.
And remember a C or Pascal program would just read/write to Std IO/Err. No magic within your program. MPW trapped the I/O operations of command programs and implemented this magic.
It was also handy to write MPW commands in source code comments. You could be reading a Pascal program, then within a comment, select an MPW command and hit Ctrl-Enter to execute it. It's StdOut would be written right into the comment of your code, after the command you had selected. This is very different than using a "terminal" type interface. But you could just type commands and hit Ctrl-Enter like using a TTY. Thing is, since it's all in a text file, you just hit File->Save to save your "history". In fact, you could have as many text files as you want with commands or templates of commands. So to use the "command line" you simply open (or create a new scratch) text file and start typing, using Ctrl-Enter to execute.
And of course you could write powerful scripts in MPW's bash-like sorta language. With utilities like compilers, make, link, rez, and generate an application.
The lower I set my standards the more accomplishments I have.
(Score: 2) by RS3 on Thursday September 26 2019, @03:12AM (6 children)
BTW, not sure if you still run any MacOS Classic machines, but one interesting site: https://www.macintoshrepository.org/ [macintoshrepository.org]
(Score: 2) by DannyB on Thursday September 26 2019, @02:35PM (5 children)
That's cool. I've long since moved on. I look back fondly at those days. I probably would still be interested in that up until about ten years ago.
The lower I set my standards the more accomplishments I have.
(Score: 2) by RS3 on Friday September 27 2019, @01:49AM (4 children)
Ah, but wait, I have, in writing, you admitting coveting a Beige G3! I have one! It can be yours! I had even bought a speedup CPU for it (I forget the name but you'd know it...) I have a dual G4 MDD!! That too can be yours!!
(Score: 2) by DannyB on Friday September 27 2019, @03:10PM (3 children)
> Ah, but wait, I have, in writing, you admitting coveting a Beige G3!
Really? I don't seem to recall that.
I have a gray G3. Collecting dust. But last known to be working. It's a desktop style box with a monitor on top of it.
The lower I set my standards the more accomplishments I have.
(Score: 2) by RS3 on Saturday September 28 2019, @01:30AM (2 children)
> Really? I don't seem to recall that.
Okay, you win. But you were thinking it.
I'm pretty sure my Beige G3 is the same as your gray one. Pretty cool machine. I liked the interior layout- very efficient, compact. I modded the HD mounting so I could put up to 4 HDs in it. I had a Macintosh PCI IDE (ATAPI) controller. I can't remember when I last booted it, but it should still boot. Last time might have been 5 years ago to read some older Mac formatted floppies. I miss the boot chime. Yeah, I could download it, but it's way cooler when it's from a booting Mac.
(Score: 2) by DannyB on Monday September 30 2019, @03:50PM (1 child)
The interior layout of later Macs like these, and also of the 1983 Lisa, was amazing.
Without a single tool, just your bare hands, you could open up the machine and access any and everything.
PC's in contrast, required tools to open. And tools once you got inside. And further, I swear that PC manufacturers must have paid a staff of people to sharpen all of the edges on the inside of the case to ensure you would cut your bare hands bloody.
The lower I set my standards the more accomplishments I have.
(Score: 2) by RS3 on Tuesday October 01 2019, @02:36AM
I never saw inside a Lisa, but overall I always thought Macs were designed, not cobbled. Some, like my MDD, require screwdrivers to remove hard disks.
Dell started doing tool-less cases, for the most part, and with fairly well marked release tabs, etc. Others followed suit.
> And further, I swear that PC manufacturers must have paid a staff of people to sharpen all of the edges on the inside of the case to ensure you would cut your bare hands bloody.
They had, let's call it, a special working relationship with a secret medical organization. ;-}
But seriously, one of my biggest pet peeves in life is sharp metal edges. GRRRRR!!!!!!! I literally think there should be a law, and I've felt that way since childhood.
I love when they fold sheetmetal back on itself rather than leave sharp edges, and again, newer machines have finally been doing that, esp. Dells.
(Score: 2) by DannyB on Wednesday September 25 2019, @03:14PM (11 children)
USB sticks expose their storage the way hard drives do. As an array of blocks.
It is entirely up to the CPU of the device the USB stick is plugged in to to organize those blocks into some kind of a file system.
The flash storage of USB sticks is not well matched with this idea of presenting the storage as an array of blocks. So the microcontroller on the USB stick jumps through all kinds of hoops to manage the storage and try to keep the wear even across the actual storage, which has a limited but large number of writes before it wears out. Tricks are even done to recognize when you are reformatting or repartitioning.
What if there could be a new USB standard that presented a storage device at a higher level API more like a file server. Say NFS or CIFS. Now the "filesystem" is whatever the USB stick's firmware wants to use. Including journaling. As I (mis?)understand, USB sticks now have a capacitor to allow completing internal operations when the USB stick is abruptly removed while writing. That could continue to happen to ensure the filesystem is left in a safe state.
USB sticks can now use different filesystem designs, different techniques and basically now have a lot of flexibility to choose different approaches to how to best manage the life and reliability of the storage. Yet all OSes could have an implementation of this API to access the storage. Even pocket sized hard drives could decide to implement this "NFS" type of API instead of presenting an array of blocks.
In a nutshell: turn USB storage into a file server instead of a block server.
I'm old enough to remember early LAN storage systems that were block servers, before there were any file servers. (eg, Corvus Constellation, and others)
The lower I set my standards the more accomplishments I have.
(Score: 3, Interesting) by Rich on Wednesday September 25 2019, @03:24PM (10 children)
There is. It's called MTP, Media Transfer Protocol. I haven't throughly investigated on how complete it is, but phones and cameras use it to expose their contents without having to unmount their primary storage. Maybe a bit of Embrace & Extend?!
(Score: 2) by DannyB on Wednesday September 25 2019, @03:33PM (9 children)
So basically an MTP USB stick. Or drive. These things would need to be properly branded so you were quite clear about what you were buying.
I was vaguely aware of MTP, and even thought about it as I wrote. But I've never looked into it.
I remember when it was not possible for a phone to be operable while it was connected to a computer. And that the computer could corrupt the phone's storage. And I remember when it was fixed, but it took a while for everything to catch up.
The lower I set my standards the more accomplishments I have.
(Score: 2) by RS3 on Wednesday September 25 2019, @04:04PM (8 children)
Sorry- in a rush- no time to read- maybe later. My concept is: the USB Flash drive manages the filesystem, which is the simplest form of a "server". But please don't make them all that way, and please allow us to choose the filesystem from the many fine ones available.
You're still going to need power to allow the managing CPU to flush caches and close files, write FAT, inodes, journals, whatever.
(Score: 2) by DannyB on Wednesday September 25 2019, @04:22PM (7 children)
I think your choice could be in which brand of USB sticks you buy.
Brand X happens to use FAT32 while Brand Y happens to use ext4, internally. I would probably avoid Brand X.
I doubt manufacturers are going to provide a mechanism to allow you to manipulate the internal workings of their firmware.
The lower I set my standards the more accomplishments I have.
(Score: 2) by RS3 on Thursday September 26 2019, @03:01AM
Those are good possibilities. I was thinking of a higher-level of abstraction where the USB stick acts like a simple Flash drive, but in fact virtualizes the block device, and internally stores however it wants to, but now I'm not sure why bother doing all of that... unless there was another mechanism (protocol) to move data to the stick.
> I doubt manufacturers are going to provide a mechanism to allow you to manipulate the internal workings of their firmware.
Sure, but maybe there's a market for something better, with a simple tool to let you do things like change the internal filesystem for some reason, so maybe someone will make something for such a market.
AFAIK, most USB sticks / Flash storage are FAT32 formatted by default.
(Score: 2) by dry on Thursday September 26 2019, @05:25AM (5 children)
My understanding is that using journaling file systems on USB sticks should be discouraged as the journal involves so much writing.
(Score: 2) by DannyB on Thursday September 26 2019, @01:57PM (4 children)
As long as no single failed write can corrupt anything, which is a topic about file system design, then you make sure there is enough power on board the stick to complete each individual write before starting it.
The lower I set my standards the more accomplishments I have.
(Score: 2) by dry on Thursday September 26 2019, @03:14PM (3 children)
I was thinking more of preventing too much wear on the stick.
(Score: 2) by DannyB on Thursday September 26 2019, @06:07PM (1 child)
That is a problem confined to the design of the filesystem and firmware on the stick. Something "under the hood" from the POV of the person using the stick.
The lower I set my standards the more accomplishments I have.
(Score: 2) by dry on Friday September 27 2019, @03:55AM
Unluckily most sticks firmware is designed to use some form of FAT and doesn't even consider something as simple as aligning a file systems 4kb sectors with the sticks sectors.
(Score: 2) by RS3 on Friday September 27 2019, @02:04AM
Stick wear is never a good thing, but I hear there are remedies.
(Score: 2) by Rich on Wednesday September 25 2019, @03:20PM (1 child)
Macs always have had little eject holes, and Mac power users (almost) always had a beefy bent-up paperclip next to their computer. The regular kind of paperclip was too weak for the spring loading of the Sony drives, and the large ones were too thick. (It was easy with the later drives, where the eject energy had to be pushed in with the disk, and the eject just needed to be triggered, though) The right kind of paper clip was quite a coveted item among classic Mac users. :)
Your ideas would require hacking the onboard controller of the stick, but good luck with that as the manufacturers are certainly not keen to expose their firmware tricks on how to keep your data stable until at least one day past the warranty period.
If you don't want to roll your own, Shenzhen-startup-style, maybe there's an upmarket manufacturer where the stick actually acts faithfully to commands and a "sync" is a "sync" and it will _guarantee_ that it is stable to the extent of being in some safe state with modifications only possible from writes after the last sync. Then you could add the LED to the port and use a journaling (or better a logging) file system from the host.
(Score: 2) by RS3 on Thursday September 26 2019, @03:09AM
I'm not suggesting hacking- I mean real product development (grown-ups). I'm just saying it might be a good idea for someone in that market, or someone who wants to try that.
I like your "sync" and LED ideas. Wish I could start a company! You'd get your cut. :)
Maybe just a "sync" button on the thing, and an LED would go out when done syncing. But I dunno- it all depends on the OS, USB speed, buffer size / speed, FLASH / controller speed...
(Score: 0) by Anonymous Coward on Wednesday September 25 2019, @11:13PM
I'm not aware enough to read the responses before posting my own. I'd prefer to stay away from the Mac solution of "delete all files on the disk to eject".