You're looking at the Changelog. The README is next door, and it explains:
> This repository began as a GitHub fork of joyent/node.
> io.js contributions, releases, and contributorship are under an open governance model. We intend to land, with increasing regularity, releases which are compatible with the npm ecosystem that has been built to date for Node.js.
That doesn't tell me anything. It assumes the reader is somehow familiar with the context and shares the authors' sentiment, although that is not true.
This is what should be explained there:
1. What is the problem with Node.js?
2. What is wrong with Joyent?
3. Why the fork was the only adequate solution?
4. How come this is beneficial (and not harmful) to the community?
5. Is it a drop-in replacement? How does it affect existing projects?
6. How the future looks like from this point of view?
However hard I look at that paragraph in Readme, I still can't see these questions answered.
I think the article is too verbose when knowing the context the bug is trivial: you intercepted meta+s and ctrl+s and in the way you broke alt+s.
I find the save dialog useless for web browsers as well, but I think preventing its use is a bad idea in general. Overriding the browser's shortcut is uncomfortable. For example, wordpress likes to capture cmd+<number> to change the font style, but that's how I usually change the active tab. It also disables ctrl+tab, the other way I use to escape while the text area is active.
People use their browsers and have their workflow in them. Breaking them needs to have a really good excuse. http://xkcd.com/1172/
But the article explains why they override ctrl-s. It is because the users had muscle memory to keep hitting ctrl-s to save, since they were used to not having an auto-save function built in. But more than that, is the idea of a web browser as an app delivery platform. If a web browser is running an app (such as a word processor, or spreadsheet, or anything but browsing the web) it is sometimes necessary and beneficial to turn over browser-reserved keystrokes to the app in question. The only time to expect browser shortcut keys to work normally is when browsing a web page (vs. using the browser to run an application).
Indeed, allowing the browser's default Ctrl+S action to take effect would be actively harmful. It'd trigger a behavior that's completely useless to the user (saving the active web page as HTML), but which could easily be mistaken for doing something useful.
Pfft. Or you could just press Alt-Space, M, and then the arrow keys to "bind" the move to the mouse movement. This will let you bring the dialog back onscreen.
On second thought, I'll be glad when I don't have to know that.
The actual bug was trivial, the backstory was really interesting - it's the kind of thing you'd hear about on the 99% Invisible podcast. Sometimes verbosity is nice, after all, who doesn't like to share a good bug-hunt story?
Not mention the sites that hijack "/" for their search. I don't think there's a single site that hijacked keys which ended up being a good idea (at least from my experience).
I think browsers need option to disable key hijacking.
It'd drive me crazy if Gmail _didn't_ do that. Love the keyboard shortcuts, including and especially the ones that override. Highly productive compared to the alternative.
I dunno; I really preferred the alternative I used to have: reading email in a proper email client. The only reason I use the web client now is that it's easier when I'm also using my phone to read mail away from my computer. And I'm strongly considering just returning to desktop-only email; that's how much I miss reading mail in gnus.
At the time I was heavily using local groups (folders) to organise the emails, and of course those weren't living on Google's servers—and if I were going to leave them up on the server, I might as well choose to organise them differently, since I wouldn't have gnus filtering them for me.
And I think there was some trouble with IMAP at the time too, so the path of least resistance was to just use the web client on my desktop. But, as I noted, I'm thinking of going back.
Surprising finding 99% invisible here, but more surprising is the chosen episode, considering its latest is completely computer related, even talks about Steve Jobs.
It closes with a great quote that summarize the episode: "User friendliness has its drawbacks".
In some countries the price per SMS is not null. Also you have received verification. And group messaging with some features that are not available in MMS. Also end to end encryption.
The data is written twice when using WAL. From the same link you pasted:
> The original content is preserved in the database file and the changes are appended into a separate WAL file.
The difference is whether the journal keeps the new data (WAL) or the old data (not WAL). If you are writing big chunks of data, WAL will probably be more I/O intensive.
Taking a wild guess I'll say that if you are adding data to the database, and not using WAL, the data will only be written once since the journal won't keep a reference to old data if no pages is being overwritten.
