Slashdot Mirror
Is the Save Button Obsolete?
Luther Blissett asks: "I've wondered this for awhile now: why do we still have a Save button? Why isn't it always automatic? Why isn't 'Save As' called 'Name and File'? I understand that in ancient history, when Save was a hit on system resources (e.g. when saving to your 5.25 inch floppy disk), we might give control to the user. Also, the average user then was probably more technically adept (out of necessity) and knew the difference between RAM and storage. But now? Why?"
- Transitory unsalvageable states (e.g., you just selected all and cut)
- Prohibitively large data sets (e.g., bioinformatics, movies)
For modest domains, however, a form of automatic versioning control ("save tree") would solve the first case.Since day one, "SAVE" has been obsolete along with a myriad of abstractions offered end users (what the heck is the notion of a "FILE" menu anyway? -- What the heck is the notion of "FILE"? I know I've read every beginner's book about getting familiar with computers, and they always go into excruciatingly dull detail about the file abstraction (it's a collection of bytes the comprise a document, blah, blah, blah.)). Users don't care what a file is, they don't want to know what a file is, they just want to do work.
(I will admit caution when absolving users of any responsibility to learn, but generally speaking, end users have enough on their plate without having to incorporate geek-speak to do their work.)
I was in a design meeting one day discussing the appropriateness of the "FILE" menu for the application we were delivering. One of the anointed Golden Boys of the team had sketched the layout and included the "FILE" menu. I asked why we needed it, there was NO notion of "FILE" in our application, there was no notion of "SAVE FILE", etc. in our application.
He said, "cuz they expect it, it's a standard menu." I said, "standard cuz they expect it, or standard cuz it's always been there?" I finally gave up on the chicken and egg discussion, let it be resolved the end users "expect" "FILE" (NOT!).
That said, I could (and may) go through the menu selections in virtually any application and find half of the "options" are abstractions that have bubbled up either historically, or were just never "translated" for end userdom. It's a mess, and it's a presentation piece of software I am constantly explaining, and apologizing for.
It's toothpaste out of the tube, I wish it could go back in. But, it's a great lesson in humility when you actually take a lay-step back and actually try to interpret what we see as normal-speak on a daily basis. It isn't normal, and it isn't transparent.
Short answer to the poster's question: yes
Most of the crap we throw the users' way is artifact crap that never went away. (Does anyone know or remember the story about cutting away 1/3 or the Thanksgiving Ham when preparing it for Thanksgiving Dinner?)
There is nothing in the technology that requires a save button for typical programs and uses. KJots is my preferred "scribble a note" repository for that reason: I can't forget to save the note. However, with larger files the delay of doing a "full save" may be an issue. It only takes a second to save most reasonable sized files, but if poorly implemented that second could make the software appear unresponsive. Still, it doesn't require rocket science to save during pauses (if the user stops for more than five seconds, they probably have stopped for long enough that a second to save won't hurt anything).
For larger, more complex document types, a "transactional" file where you only write out the changes since the last save point may be appropriate. Apparently this is harder than it would seem though, as almost every program I have seen with this kind of technology seems to be more apt to corrupt the document than standard saves (actual databases not included). For efficiency, closing the document could cause a final version to be automatically composed and the transaction history removed. This would also be good for security and privacy (so a recipient doesn't see how the document got the way it is.)
Of course the new problem becomes "how do I forget the giant mess I just turned the document into". With a transactional file, reverting to a prior edit should be a snap, but if it was just background saving you would run the risk of saving a version that the user didn't really want. In KJots it is a non issue because of the type of document it is, but in a "real" application backing up the original version would be mandatory.
Another adjustment would be asking for file name and location at the start of a new document... minor but potentially jarring for those used to the old methods.
Perhaps the *real* reason is laziness on the part of programmers. Backing up documents, allowing restore to a prior version, transactional formats... that is all more work than "dump the data on request".
Sig under construction since 1998.
Mainly it is not obsolete because you don't want to make a major mistake, save it and be unable to undo that mistake.
Erutangis ym si siht.
Quite a lot of time I make a first draft of a document, save it and print it out. Then I go and edit it and then save this as another copy, the finial version. If it automatically saved then it would end up with the draft not being a draft but half way between draft and finial (I only save every five minutes or so).
I open up files all the time tofiddle with some numbers without affecting the actual file. My bosses come up to me with little questions all the time - I just open the file with the data, do some minor manipulations, give them their answer and then close it. I care to retain that information.
Then again, I could have wildly misunderstood the question - wouldn't be the first time.
Original poster suggests that saving files isn't a hit on system resources, but of course it is under many circumstances. For my day-to-day activities, here are file types that, when saved, slow my machine down and/or make me wait:
Photoshop files -- they get quite large, after all;
Flash source files -- they get quite large, after all;
Premiere and other video/DVD editing software -- the biggest files of all;
Reason/Sonar (music) files -- they get large, and they also negatively impact system performance when you're playing back complex compositions in real time.
It's even worse if I'm saving to a network share.
So, that may be the case for large files, but what about text files?
Well, I'm a web developer by trade, and when I'm troubleshooting broken code, I often use this convenient and pain-free system to narrow down the bug location:
Step one: cut a chunk of code out of my source document;
Step two: save the file (without the chunk of code);
Step three: paste the chunk of code back into the source document;
Step four: refresh the browser to see if the bug is still present;
Step five: save the file (with the chunk of code restored).
Automatic saves would interfere with what I find to be a very convenient workflow.
Since the US is a Christian nation, having a "Save" button helps keep Jesus constantly on our minds. Now if we could only get the "Delete" button changed to "Damn to the Flames of Hell for All Eternity".
And don't even get me started on the obviously Freudian "Cut" and "Paste".
"It's a wonderful idea. But it doesn't work." -- Tad Danielewski
Every day I work with word docs that are 30+ megs in size. All of our saving is done on network shares across a WAN link. Depending on network traffic, a normal save can stall the system for a quite a bit. Something tells me that if a few hundred engineers were constantly sending save data across that link, things wouldn't be looking so good. So, it is still very much a hit to system resources.
Also, as far as the auto save feature goes, I don't want it to. Ever opened a MS Office file (doc, ppt, xls, etc), go to close it without touching a single thing, and it asks you to save? Not to mention that when you work with baselined documents, if they ever change it has to be sent off for approval, resubmitted to higher ups, etc. If the modified date shows anything other than the baselined date, ruh roh. No thanks on the auto save.
All information is automatically stored as soon as you are done entering it. Still, we have a save button. Because otherwise people would ask where the save button is.
/something/. But I'm also the kind of person who compulsively clicks "save" (or :w) every now and then, so maybe I'm the target. .. or something)
I dont really like this feature, I'd prefer the save button do
Actually, our save button does do one thing: it disabled itself after being clicked until something else changes. I argue against that because I feel I should always be able to click buttons whose function is not being blocked by something else. (oh no! He wants to noop in a place it doesnt make sense to noop! Calling our noop would only waste valueable cycles!
-- 'The' Lord and Master Bitman On High, Master Of All
How is it obsolete?
There still is a difference between RAM and storage and there's no indication that that will change any time soon. A Save button gives us the control that we still need. In a word processor, for example, a quick typer could generate as many as 15 or more individual changes to the document per second. Yes, you could save at predefined intervals, but that number would need to be tweaked depending on the software and hardware situation. There's no one save interval that would fit all needs.
There is another possible reason for the save button to exist... occasionally there are situations where I want to open a document and even possibly modify it but not save it. Rare, I know, but automatic saving would be a drawback in this case.
In the end, removing the Save button from applications would only introduce more problems than it would cure. In an ideal world, I can see where it would work (Apple would be the first to do it), but with today's hardware, software, and users as error-prone as they are, it's much better to just leave it there.
I see lots of people(.. two, but I dont know many people) use "not saving" instead of undo. Always makes me want to hit them. But then sometimes I'm on somebody else's system and all that's available is some version of vi with one level of undo and terminal settings which convert "@" to a destructive backspace (seriously, wtf?)
Sometimes closing and re-opening is the best shot until you can figure out where you are.
-- 'The' Lord and Master Bitman On High, Master Of All
1. Lots of people work with larger data sets than you do.
2. Lots of people (photographers, lawyers, accountants, etc.) might want to share their work without sharing all the steps that went into creating that work.
3. Lots of people might see a need to share data using something with limited bandwidth/storage.
Sure, I could Undo back to the previous state, but I've seen so many programs with broken or unreliable Undo that I simply could never trust that. Or what if the editor crashed before I could Undo?
The only way you can do away with user-directed saving is with some sort of automatic versioning system. But then, how often do you version? Whenever a single byte of information changes? Less often? How do you determine it?
What a pain in the ass. I'll keep my Save function, thanks.
I suppose the "save as" button is analogous to "dialing" a telephone. You would be hard pressed to find an actualy pulse type dial phone in the USA, but you don't "press" a phone number, you "dial" it. Things things make sense because of something in the past.
We have the save button for the same reason that we drive on the right (in the US) and stop at red lights -- its just the way it is, it works and everyone is used to it.
Conformity is the jailer of freedom and enemy of growth. -JFK
This is a pretty stupid question, I think. For example, if you make changes to a document that you don't want to save, then an autosave feature would kind of suck. Also, relying on some sort of autosave feature exclusinvely means it will have to be saving constantly, for fear of losing things (especially if you don't have the option to have it save exactly when you want), which greatly increases disk I/O's. It might not get used a lot, but I'd say "Save" still has it's uses.
Version Control
Consider one-off templating.
You want to make a new document based on your old one (maybe it'll use a similar structure or something). You open it up, make some changes, then save it as a new file, leaving the old one unchanged.
With continuous save (by which I don't mean the auto-save that current apps like MS Office do, where it saves to a temp file), you have to hit "Save as..." or the new-paradigm equivalent immediately, or else your old document is going to end up looking just like the new one. This is only really a problem during the transition phase, while people get used to the new procedure, and it's arguable that it's better in the long run, since as things stand right now you can easily forget that you haven't already branched a new file and save over the old one.
Then there's the issue where you load something and want to make a temporary change, say, for printing or in prep for a screencap or copying and pasting into another app. Or you start typing in the wrong window. If the document is saved continuously, not only do you have to undo the changes before you close the application, but you end up changing the file modification date. Maybe it's not critical for the data, but if you're sorting by when you changed something...
Microsoft's oneNote (the new notetaking app bundled with office) has no 'save' function to speak of. It looks like the industry is taking the hint, and it's already being phased out where it can.
many RAW image editing apps also do not have a save function for the simple reason that all RAW manipulations are nondestructive, and thus, nothing is potentially lost by saving every step along the way.
-- If you try to fail and succeed, which have you done? - Uli's moose
To me, it seems that this is one of the UI items that has worked out pretty well. You have automatic saves going on to a temporary file in case of system crash / power loss / whatever, and you have the save option to explicitly save your changes to the original document. Sounds like a pretty good setup to me.
Also, you don't have to use the save command at all if you hate it so much. Just make your changes, exit, and answer yes to save.
Ignore anything I said above, I actually agree with everything you believe - mod accordingly.
Having a machine overwrite the original copy of the file opened seems like a really bad idea. MS Office and I believe OpenOffice have features like this, but it does not overwrite the original. I prefer to manage multiple backups of data myself rather than let a machine do it, plus it keeps me in good practice.
But honestly, I don't see how the concept of 'files in folders' seems to elude so many people.
...don't fix it.
(yes, yes, Mod: Redundant this may be, but you cannot argue that I am wrong)
please people, demote him from editor.
I use some things to create momentary onscreen storage -- sort of a clipboard proxy, if you will. For instance, if I want to copy & paste from one app to another, but decide that it's easier to fix the formatting in a plain text editor first. So I copy from app A, paste into the editor, fix it up, copy from the editor, paste into app B. Then I close the editor without saving. There is no reason to keep that plain text file -- none whatsoever. A setup that automatically saves every doc would, on my computer, result in an irritating trashpile of transitory text docs.
Moreover, I have occasionally at work opened a text editor or word processor and started a nasty flaming reply to something or other. As I work on it, I calm down and put the doc into more diplomatic language, or realize that the best response in the case is no response. I wouldn't want some snoop (my boss, for instance) trolling my hard drive or my network folders finding the first seventeen profanity-riddled versions of the elegantly tactful e-mail I sent last week protesting a change in policy.
I would hate to see the loss of the Save option (not the button per se -- being a dinosaur who hates mouses, I tend to use keyboard shortcuts or file menu functions whenever possible). I would especially hate to see it replaced with a version tree or a default autosave that would require me actively to track down and expunge everything I didn't want to leave a record of.
How can a post be modded "overrated" or "underrated" when it hasn't been rated yet?
Windows CE had this as a part of the recommended practices for programmers. For the most part, you never do bring stuff into RAM if you can help it- you leave it and edit it in storage memory instead of in program memory. Thus, no "Save" function is ever neccessary- because the data is already in storage memory. Save As is neccessary for setting file format and file name- but that's it.
SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
If you do away with the concept of 'files', the operating system then has to handle every possible type of document. You wouldn't have had the MP3 revolution because there would be no such thing as an 'MP3' since the OS didn't support it. You also wouldn't be able to organize data in directories, like having all of a game's data in one directory. Grand Theft Auto would have it's application wherever applications are, sounds wherever sounds are kept, textures wherever pictures are kept, movies wherever they are kept, settings files wherever they are kept, and their proprietary data files wherever they are kept, if the OS even allows it because it knows the type of file and where it should go. Then you could be scanning your pictures one day and see a texture not knowing what it is and delete it, then you can't play the game anymore.
And how exactly is 'save' obsolete? How often are you going to write the file to the disk? Every 10 minutes? Every 1 minute? Every keystroke? I would argue that having a 'save' button or menu item is the best way to handle this. If they close down the application with a modified document, the application can warn them as most applications do. Good luck saving a big spreadsheet every keystroke with OO when a save can take minutes. I don't think you'd get much work done. What if you want to just play around? Do you want to have to create a copy of the 'document' before opening it if you want to make changes you may not want to keep? It's also inefficient to save every keystroke when you may be making a lot of changes before saving.
The notion of a 'FILE' menu is there because applications work with FILES. If you have an application that doesn't work with FILES then don't use a file menu.
On that note, why does every freaking office app ask me if I want to "save, discard, cancel" when I close the program or shut down the pc?
I want neither! I just want out of here!
Maybe I am in a hurry. Maybe I already walked away after hitting "shutdown". So dont ask useless questions.
Just keep everything as it is, save to some temporary location if you must, and the next time i boot the pc and open the app i want everything just as I left it.
So you can send your users humorous little messages like "Slow Down, Cowboy!"
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
There's a save button for the same reason we wrap SQL statements in BEGIN TRANSACTION ... COMMIT TRANSACTION. Sometimes you want changes to be all-or-none, and not in some unknown state where some of your intended edits are in place but not others. Maybe the answer to that argument is to save the entire edit history in some kind of infinite undo buffer, but personally I like Ctrl-S. There's autosave, but I still like to save things manually to reflect the states in which I'd actually want the document to exist.
rooooar
I don't think that "saving" is quite the high-level abstraction you're making it out to be, and it's shorter than saying "write contents to permanent storage". I don't see the concept of files going away any time soon, and as long as we have them, users will need to write to them.
In your defense, I don't think that using unsaved files as a convenient "undo buffer", as mentioned here by others, adds functionality that a good bookmarking system couldn't achieve (albeit with much greater overhead and fragility).
Dewey, what part of this looks like authorities should be involved?
Storage efficiency.
Mostly, 'save' just pushes things from fast but volatile memory onto safer but slower disk storage. IMO, the bigger and more interesting question is why we haven't yet got a single storage solution that can be used both as efficient temporary non-volatile swap space, making RAM obsolete, and still be used for permanent storage, replacing hard drives.
Stability.
Going off on a tangent a little, I've often wondered why executable code and data are still put in the same memory address space. We seem to be monkeying around trying separate them, what with NX flags and new safer programming languages and plugging the holes with buffer overflow patches, yet programmers, at the application level, are always shouting about abstraction and modularity and keeping your logic separate from your data etcetera. Isn't it time we ported some of the application level methods down to a lower level? Databases for example.
Some fundamental advancements in computing need to occur before i'll feel comfortable enough to let my machine decide when to commit my work to storage.
'Name and File' seems pretty ambiguous to me. I prefer something like 'Save copy as...' or the title of the post, 'Save a copy with name...'
We have the screen real estate to be a little more generous with our names :)
antipaucity
The problem is that many applications don't properly implement undo. As a result you could end up saving over data that you really wanted to retain.
I'm not sure if the quibble is about the word "Save" itself or the feeling that details of the system are being exposed in the application unneccessarily.
Operation systems commonly use the "file cabinet" metaphor for persistent data storage and I personally think that if "File" were used as both a verb and a noun, that would be more confusing than staying with the "Save" verb.
The user of a software application is typically doing work with some sort of data model. They usually expect the data in the model to have persistence between application sessions and they want to have control over that persistence.
The conventions that have developed around the notion of a "file" and the "save" function are not just historical oddities or operating system details the user shouldn't be forced to understand. They are a realization of application requirements.
A user typically operates many applications on a system. When the applications re-use the operating system's presentation of data persistence it is easier to switch between applications because the use cases for working with data are similar.
Which is easier? Explaining to a computer illiterate how Word saves their text to a "file" in an imaginary file cabinet or explaining to someone how a web browser retrieves pages from the internet and what it would mean to make an offline copy of the page (and whether that is even possible for a specific page)?
If all of our operating systems suddenly presented persistent data storage to the users using a different abstraction, then the applications would have to adjust.
But I don't think the conventions of File and Save are cumbersome nor anachronistic.
Jesus saves....And takes 1/2 damage.
I've searched and searched and I can't find it anywhere on my Palm.
It is most likely psychological dependency that has developed within the larger community of users. Donald A. Norman a CS professor at Northwestern developed a psychological model called the Human Action Cycle, he identifies the psychological process while humans interact with computers systems is primarily result oriented.
In summary, when we work with computer systems we are goal oriented; if we achieve our goal then we are succesful. In other words, if it aint broke don't fix it.
One problem I've noticed with every implementation of "Undo" that I've ever seen is that there is never any indication of what it is that you are about to "Undo". You hit Ctrl-Z and the cursor jumps to some unexpected part of the page -- what did it undo? No way to know, 'cuz it's not there, so now you have to "Redo" to compare, then "Undo" again.
I'm not sure what the best way of implementing an improved "Undo" function would be. Perhaps "Undo" would just use strikeout and redlining to show what it is about to do, then you would hit "Undo" again to get it to actually do it.
How long have we had the telephone now? How about we get rid of those pesky buttons on the Telephone? Shouldn't we be able to just pick up the phone and have it know who we want to talk to? (said with dripping sarcasm...)
I guess I could just drag and drop all my files, who needs pesky pull down menus. (sarcasm)
The OS is file based, even if the file system (note name) is database driven or a plain journaled file system, its files. Even unix is entirely made up of files pointing at files!
Soon as the user knows what a file is, its easier for them to know about backups, copying files or working on files. Even in school the first thing they teach you is how to save your work, and revisions of your work per FILE.
A question like "Why is Save As needed?" shows that the user has no real hands on experience.
Since you seem to know something about coyotos, why is it taking so long to bring this out? I sort of followed the discussions on Eros with interest for years and have been waiting to see capability computing brought back. In the meanwhile Unix is adding it (and interesting enough NT is sort of taking it out). Oracle has continued to use this model but there has been little discussion of the pros and cons based on Oracle's experiences.
Do you have idea what the big holdup is?
Here's a thought: the versions of a file match the undo states. So, as you edit the file, the program journals it to disk. Crash and resume, and you get your undo history back. Save, and your undo history is collapsed and the file stored in its native (un-journalled) form. So "save" transforms from a storage operation, to a render operation.
This has the advantage that a quit or crash and restart from a temporary change will allow you to back out the change. It also works for large datasets, because you aren't continually saving the whole thing, only journalling the changes.
For modern applications I would argue: "save" -- no, but "checkpoint" -- yes!!!
I often open files just to look at them, and inadvertently hit a key that modifies the file. I don't WANT such changes to be saved automatically, especially if I am not aware that I made them. If this mode were to be adopted, I would at least want two kinds of Open commands - Open to view, and Open to edit. Unfortunately given the feature-poor point-and-click interface most people use these days, this becomes more cumbersome, for example double-click = view, shift+double-click = edit. (You can specify an object with your mouse, but are restricted in what verb to apply to it by gestures and shift keys, or less convenient pop-up menus). I like having programs automatically save temporary changes (useful in case of program crashes), as long as it is understood that such changes are not "official" until explicitly saved. Microsoft Word does this, and now so does Gmail.
REAL men use vim in console
I copy part of a file to a notepad window. I have no intention of saving this data, but want to view it in notepad and not vi. Maybe I'm going to use notepads find / replace, because I find it easier than vi ( personal opinion ), or for some other reason. Why they hell would I want notepad to just save this data without me telling it to?
PDA's do what you ask already and so do phones. It is a case by case thing. When using a phone or pda you may want to save your files, but you don't always want to do that when using a computer. BTW: Word and outlook already do this.
Only 'flamers' flame!
Does slashdot hate my posts?
When I work on a new version of a file, I open the most recent, then save as a new name (if I want to save the old)
/. just so they can get their name in lights? ;)
Also, sometimes I want to make a test change, but not keep it.
Sometimes I want to revert back to the original, but some programs have very limited undo (excel, older photoshops)
Sometimes when I'm just writing something very temporary, like a fax cover page, I NEVER want to save it.
Is posting this to
Do not meddle in the affairs of sysadmins, for they are subtle, and quick to anger.
The concept of "document" would still be valid.
You would have a "spreadsheet", a "letter", etc.
The "all files should be known to the OS" thing is BS, that's what plugins, kparts/automation-servers are for. MP3 never meant jacksh*t to linux; but inside KDE, you click on one of those, and voila, noatun is loaded with it.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
130 pages. About 30 pages filled with equations. Lots of photos, figures, tables, listings, indexes etc.
Pentium 4 3GHZ, 1GB RAM.
Over a minute to load/save. During saves system slows down to a crawl, what you type appears some 10 seconds later. You just have to wait through.
Thank you, I'd better decide when to save by myself. Give the systems another 10 years of Moore's law and we can talk about removing 'save' again.
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
Sure, if you assume you ONLY use small text files or other documents, ONLY edit tiny, thumbnail-sized images, and never make a single mistake that you want to revert out of (i.e. enough edits have flooded the original state of the document out of Undo), the poster may have a point. In my opinion, it's still not that good a point, but it's still a point.
However, I know I work with somewhat largish GIMP images on a somewhat routine basis. Images which take anywhere from 5-35 seconds (sometimes more) to save, depending on the size and complexity. And this IS to the local hard drive, not a 5-1/4" disk. So, I'd rather not have GIMP itself deciding when it wants to block out edits for half a minute. And I'm not even a professional in this respect. My images are only in the 300dpi range and roughly comic-sized. I'm certain there's people out there with much, much larger things to work with.
That's not even considering project-managed filesets, like IDEs and such. Where "Save" could mean "Save this current code file", which SHOULD be somewhat small and quick, or it could mean "Save all the code files in this project and update all the controlling files so it can be opened in this IDE properly later". With a big project, that could mean rifling through thousands of little files, each one requiring its own file operation which, depending on the OS and underlying filesystem, could add up to massive amounts of time. Having an autosave mechanism that would do that entirely outside my control would be a pain and a half, to say the least.
Add to that the fact that I'd rather not rely on the program "knowing" when to save (i.e. "I want this saved NOW, before the storm outside kills power, not in the next five minutes when autosave decides to wake up"), and the nightmare that things like Microsoft Word's autosave throws into files, and I'm afraid I'll have to disagree with the poster's sentiments nearly entirely. Save can easily be a major hit on system resources even in these non-ancient days.
Demanding constant attention will only lead to attention.
I've been in a situation that I only needed to revert a certain part of the document. I would hate to reverse all the changes only to redo most of them.
ayottesoftware.com
if you automatically save for the customer, you run the risk of becomming responsible for the data in their eyes. Meaning very p.o.'d customer's when the system crashes and they lose everything. I've seen this happen with email programs and office messeging software where people call tech support asking for the 'backup' of their data. I guess there are ways around this, but most of them involve having a 'file' menu with prominent export or backup buttons so the user understands that it's their responsibility to ensure their data is safe.
It's not a good idea to completely abstract users from the system unless you're prepared to do it completely, e.g. using web services to take their data our of their hands.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
I know that at one point, it was considered necessary and useful to understand things, and people generally were expected to really think things through before posing stupid ideas and thinking we need to change the whole world without any reason every so often.
For every problem, there is at least one solution that is simple, neat, and wrong.
No.
I don't know the early laws anywhere else in the world but in Europe ( countries I used to support ) there were laws to save every production verion in 70's. So - anytime you made one of the thousands production versions of an application it had to be saved for next 6-7 years, you were required to reproduce the same results later if the auditing required that or lose your business license. The systems did that authomatically - as a systems programmer / contractor I was responsible some of them and it worked. There were many ways to do that ( thanks to home grown or other systems like Pansofic Panvalet/Panexec or IBM file generations, etc.. ) So - nothing new, the toy systems are catching up (IMHO).
And we can call the "discrete little packages", uh, we can call them, uh, I know, "files"!
And the "larger, concrete objects" can be called "directories"!
What a revolutionary concept!
On a more serious note, a filesystem is a database; it's just accessed differently than, say, an SQL or ISAM database.
In addition, there are some experimental filesystems whose underlying implementations are SQL or ISAM databases.
Take a look at a standard POSIX filesystem.
It has records (i-nodes) indexed by i-numbers.
The records have fields like "last-accessed-date", "number-of-links", etc., as well as a BLOB that is the i-node's content.
For ordinary files, the BLOB contains the file's data.
For directories, the BLOB contains a table of i-numbers and filenames corresponding to the contents of the directory.
Essentially, a filesystem is an object-oriented database (or, at least, can be viewed that way).
All of this is hidden by an abstraction layer (e.g. "creat" [sic], "open", "stat", etc.), but it's there, underneath the surface.
Journalling filesystems add a kind of transaction capability to filesystems.
Other filesystem types (e.g., Reiser) aim to expose some of the lower-level functionality, or to add other "fields" (e.g., "mime-type", ACLs, etc.), or to add indexing methods other than i-numbers, to the filesystem database.
To get (somewhat) back on topic, a "save" can be considered to be a "change" of a record (file) in the database (filesystem).
I don't know about others, but there are times that I don't want to save what I have done.
The reason that vi has ":q!", "ZZ", and ":e!" is because sometimes I want to quit without saving, sometimes I want to save and quit, and somtimes I want to revert back to the last save and keep editing.
So, no, "Save" is not obsolete.
Those who sacrifice security to condemn liberty deserve to repeat history or something. - Benjamin Santayana
This was for hard-copy terminals (e.g., ASR-33 teletypes and DecWriters), where you didn't want to actually backspace and overtype, because it could get pretty messy.
(In fact, IIRC, ASR-33s couldn't backspace at all.)
However, I could sometimes get quite annoyed when typing in C preprocessing statements, especially when switching between a DecWriter, which used # for character delete, and a VT-100, which used backspace.
(Really quite annoyed.
Really, really, really quite annoyed.)
Those who sacrifice security to condemn liberty deserve to repeat history or something. - Benjamin Santayana
Ah, yes, it was line-delete, not character-delete.
too bad the phrase "thanks for the history lesson" has implied sarcasm.
-- 'The' Lord and Master Bitman On High, Master Of All
Those who sacrifice security to condemn liberty deserve to repeat history or something. - Benjamin Santayana
If you smoke a lot of dope, probably most of your friends smoke a lot of dope, too. This by no means indicates such behavior is a societal norm. By the same token, if you are a PC maven, then most of your friends are knowledgeable about PCs, too. Please trust me on this; by and large, the great majority of PC users can best be described as chimps, and should not have access to any administrative PC functions. A friend or relative who is educated in such things should set up the unskilled user's PC giving the user a limited account, and visiting once in a while to solve problems or add software with an administrator account.
Goddamned kids! Get off my lawn!
That's not fine-grained enough to be useful. How much composition of records can you do if a majority of the data is locked up in BLOB columns?
See, I frequently work on things and don't want to save them. I also frequently don't want to save any changes. It's a lot easier to click "save" when I want to save a file than to click "don't save" and wait while the program undoes whatever overcomplicated steps it took to keep me from having to press "save".
I can't remember how often I've been typing something for a while and I've made so many changes that I can't undo all of them, and then I have to revert back to the saved copy.
www.linuxpenguin.net
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
is the name of the file -- there was no folder called "arquivo" on /tmp
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
Although it doesn't have the failure recovery, recent versions of Photoshop work like this. Undo information is stored in the temp space, and then is wiped out and the file is baselined when you do a manual Save. I think there might be an autosave feature in there someplace (got knows it's got everything else) but the files I work with are big enough that I wouldn't want to use it, because saving is a fairly heavy I/O draw, and takes a few seconds to complete at least.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
... But will it come with a "Smite" button?
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
You don't want "save". If people don't "save" something, that means that they lose it. Instead, you want people to commit their changes.
-russ
Don't piss off The Angry Economist
However, as I suspected, KDE can't guess the file type of every sort of file - which is why it couldn't figure out what to do with the Quicktime video clip I had originally tried this on. I knew this sort of thing was possible but I had correctly assumed that this can't be done for every file (and since most programs still use file extensions, I had assumed that no one would ever bother to try to program this functionality into the GUI).
www.linuxpenguin.net
file(1) and /etc/magic is not a new thing at all.
unices never needed file extensions, it's the fact that they make things more recognizable that make them so "handy".
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
Personally, I prefer having a save button because it's easier to code a "dump contents to location" function than it is to code a "keep an infinate number of named previous states stored at random intervals" automated function and a user controlled function "keep current state, revert to user selected previous state". Using such a revision history would also be insanely wasteful of RAM and would greatly reduce system performance with contstant or extended use.
Besides, what do you do when you exit the program? If we assume the program uses the auto-save model I just listed above than the program would have to do one of 4 things (other options exist, but would be less than totally reasonable):
[1] Save, overwritting the original file and clearing the revision history on close. (saves disk space, strong posibility of unwanted data loss due to overwrite, does not require any other save features)
[2] Save the entire revision history to some file that is somehow directly linked to the original file. (maintains original data and revision history, will become enormously wasteful of storage space; also raises the question of how the original file came to exist to begin with, would probably require that some other save feature be available)
[3] Prompt the user for action. Assume that options will include Overwrite, Save as new, Discard changes. (allows for discarding the change history, grants the user control of final actions, but requires user interaction to close, could act as the only save feature)
[4] Discard everything, original file remains as is. (insures original data safety, easy to implement, requires that some other save feature be available)
Based on this, it's probably best to have a save feature available in program regardless.