Rick Trouton documents some of the powerful new FileVault features in OS X Yosemite.
Apple recognized that there would be situations where Mac admins would need to set up FileVault 2 for a person where the admin would not have the password for that person’s user account. To avoid the immediate need to enter a password, fdesetup has a -defer flag in Mountain Lion, Mavericks and Yosemite that can be used with fdesetup‘s enable verb to delay enabling FileVault 2 until after the current (or next) user logs out. With the -defer flag, the user will be prompted for their password at their next logout or restart. The recovery key information is not generated until the user password is obtained, so the -defer option requires a file location where this information will be written to as a plist file.
The new commands allow system administrators to enforce FileVault 2 at login and logout with the use of both institutional and personal recovery keys.
Brant Sears, Newton developer, on the Newton’s powerful APIs.
I was a Newton programmer for a few years writing medical records software. The persistent storage solution on the newton was really wonderful. I remember working with it very fondly. It was my first real job as a professional programmer. Our company made versions of our software for Newton and Windows CE. We only had one Newton engineer (me) and many Windows engineers. I was always able to keep the newton product ahead of CE despite working alone because of the tremendously powerful APIs of the the Newton. Even a year after cancelation our Newton software was far outselling the Windows version. I am a professional software developer today because I truly fell in love with the Newton and I like to think that a little bit of the design philosophy of the Newton rubbed off on me.
The Newton was never marketshare leader in units sold, or the number of developers required to support the platform.
Anyone who has used a Newton to enter data, and then returned to that data months or years later, knows how rebust the storage system is.
But it wasn’t always this way.
Landon Dyer, Newton developer, on why the Newton needed a strong storage system.
One afternoon Michael Culbert, the Newton Technologist, came into my office to discuss battery contact bounce. I’d been nervous about the robustness of the storage system and had talked with him about it before, and now he confirmed my worst fears.
Battery contact bounce is the jiggling of the power connectors when you toss a device onto a hard surface; the device can easily momentarily lose power and reset, and if the Newton was in the middle of a storage update all the data would be lost.
In order to fight battery contact bounce, and other forms of data corruption, Landon came up with a transaction-based storage system for the Newton.
Here’s how it worked:
Imagine that you have a notepad entry, with a bunch of text. The NewtonScript storage layer breaks up the notes into a bunch of small objects, including the text itself, plus some extra objects for searching. There are objects containing structures that allow the text to be quickly searched, and so on.
Now say your original note was, “Buy milk,” and that you add “Bread, too!” to it. What the Newton does is create a whole set of shadow objects, just like the old ones but with your changes applied. Then, with a single write to a single byte somewhere in the store the storage system commits your changes, then goes back and deletes the outdated objects.
If the power fails before the commit point, the Newton just deletes the new objects and you haven’t lost much work (you just have to remember to buy bread). If the power fails after the commit point, the Newton just ensures that all of the old objects have been gotten rid of (so it can re-use the space they take up).
This sounds simple in principle, but in fact it’s quite difficult to get correct. Additionally, the flash storage we were using had the amusing characteristic that bits could go bad, which is a little like having to design a car with an engine that might lose a gear or two and still have to maintain freeway speeds without the driver even noticing.
Due to Landon’s efforts I can’t say my Newton has ever lost data, or thrown a gear while driving at highway speeds.
Today, even with the benefits of desktop sync and cloud backup, we still take the integrity of our devices’ data for granted.
The Newton, although often remembered as a failure, did bring the reliability of handwritten notes to our digital world.
As for the original PalmPilot, well you just had to hope there was a up-to-date HotSync before your batteries ran out.
Speaking of Graffiti, Phil Gyford attempts to answer the age old question, which is mightier the stylus, the pen, or virtual keyboard?
For some time I’ve been meaning to test my small collection of PDA/smartphone gadgets to see which of their methods of input was quickest. The iPhone’s software keyboard? The Newton’s handwriting recognition? Palm’s Graffiti?
Here is what Phil had to say about the Newton.
This method was easier than I expected and it felt like it was as quick as handwriting recognition could be — there is some delay in translating my scribble into text, but it’s no slower than the speed of my writing, so the device didn’t get behind. Once I got into it, correcting mistakes was also easy: tapping a word brings up alternative spellings and capitalisation, and one further tap away are two ways to manually correct the characters.
Here is what Phil has to say about the Palm.
In theory this simpler method is less error-prone than having to interpret normal handwriting, although I remember that even when I was using the Vx every day I found it at least as frustrating. Small mistakes mean letters are mis-interpreted and, then and now, I was forever having my ‘Y’s appear as ‘X’s.
The results are not far off from what I expected.
I still feel he could have done better with the Newton, and the Palm given more practice.
Read the full account to find out which handwriting recognition method came in first.
Landon Dyer, Newton developer, gives us five reasons why the Newton failed compared to the Palm Pilot.
Ultimately the Newton was a market failure. If you look at the competition at the time we did maybe five things wrong that the other guys got right or chose not to try to address:
One. Price point. The Newton was about a thousand dollars. Ouch. The Palm Pilot was about $300.
The Newton’s technical advantages worked against it when competing against the Palm, that had many of the same features but sold for a third of the price.
Two. Form factor. The Newton was large and weighed about a pound. The other guy fit in a shirt pocket.
Before creating the Palm Pilot, Jeff Hawkins whittled down a piece of wood and carried it around in his shirt pocket in order to approximate the size and weight of his future digital assistant.
While the Newton’s technical advantages gave it unnecessary bulk compared to its competitors.
The Palm Pilot was just more portable in a time when mobility over specs mattered.
Three. Handwriting recognition wasn’t quite there (and the production Newton had a digitizer noise issue that we found out about only later that Fall, which dramatically reduced the recognition rate). The Pilot used a much more primitive letter-by-letter system, but people got it and it worked well after a little training.
The beauty of Graffiti, the Palm’s letter recognition system, “is that is doesn’t work like handwriting recognition. It actually works like a keyboard.”
It is easier to get people to write in a way a computer can read, than get a computer to read the way people write.
The Palm Pilot made the most of limited technology.
Although the Newton’s handwriting recognition got better, it was always trying to decipher bad handwriting, something even us humans have a hard time reading.
No wonder it got a bad rap.
Four. No real apps … and you had to pay Apple a commission. For a totally new platform, charging your developers to develop software is an uphill battle. (Of course, all this changed with the iPhone, but the demand was very high). The commission idea was just another stupid and reality-disconnected idea from upper management; instead of attracting developers (who already had to pony up over a thousand bucks for a dev kit) I think it discouraged folks from even considering developing for the Newton.
Combine that with the fact that most software was distributed via expensive PCMCIA card, and syncing software between the computer and Newton was complicated.
Without a viable software distribution model, and a flourishing development community, the Newton didn’t stand a chance.
Developing on the Pilot was a lot like programming a 68000-based Mac, and pretty familiar to many programmers, while NewtonScript was something from another world (even if it did have many cool aspects).
Five. The “MessagePad” wasn’t all that good at actually messaging anything. It was awkward to connect a Newton to anything (via a cable or PCMCIA card), and the modes of communication were either inconvenient or expensive (wireless pay-by-the-kilobyte). The Newton was about 15 years ahead of the technology curve here.
One of the miracles of the Palm Pilot was the reliability and ease of use of the out-of-box HotSync.
The Newton came with a lot of features advertised on its box, faxing, beaming, emailing, and placing phone calls, but often those tasks were obstructed by the purchase of additional hardware and the required complication of the day.
What might have hurt the Newton most of all was the “magic date” for which it was released.
The Newton probably needed another three months or so of bake time before we shipped it. By November or so we’d patched nearly all of the software issues that critics (rightly) complained about, and I like to think that the reception would have been much kinder if we’d worked just a little longer.
John Sculley insisted on a strict ship date for the Newton, because he saw the project falling behind.
Ship dates are important.
They help constrain feature creep.
But releasing the Newton before it was ready, gave the Newton a poor reputation.
The rest is Egg Freckles.