I tend to be a late adopter of operating systems. I went from Windows 95 to XP to 7, skipping Vista, Me, and a number of other dogs whose names I can't even remember. I would still be running XP except that when my son switched from Linux to Windows 7 I sat up and took notice.
When I switched back to the Mac we were on Leopard. I skipped Snow Leopard, upgraded to Lion, and skipped Mountain Lion.
I need a pretty good reason to upgrade.
Add to that: I have a 2013 MacBook Air with 4GB of RAM on which I routinely run Word, Chrome (typically with about a dozen tabs open), Mail, Calendar, Numbers, Evernote... and VMWare Fusion, with a Windows 7 VM running. Don't get me wrong, I love my Air, but it has seemed a liiiitle slllooow at times, e.g. booting up or suspending the VM and I've been kind of coveting the 8GB Air. And for a while I've been suspending the VM to try to keep things running better. So new OSes tend to have a bigger footprint and be a little more bloated, and I was afraid Mavericks would push me over a tipping point.
On the other hand, I've been using two monitors for a number of months now, and the fact that you can't switch them independently seemed entirely brain-dead to me. So Mavericks was supposed to do something about this, and I was very interested in that.
So I looked on line and a few people were complaining about it being slower... I asked around and nobody seemed to know much about it, until my buddy Tom told me he'd upgraded and his systems were actually running faster.
So over the Thanksgiving weekend, I decided to go for it. I've been very pleasantly surprised: things are noticeably faster and it has breathed new life into my 4GB Air.
But of course, there are pluses and minuses...
1. I love the multiple monitor support; it is making my life a lot easier. Rather than each "space" having two screens, you can create independent spaces on each monitor, and switch the monitors independently. This is heaven. Oddly, though, you seem to lose the ability to assign apps to individual spaces, it appears that you can just assign them to monitors. Oh, except that when you unplug the external display, all of a sudden you can assign apps to specific spaces, which persists when you plug the external display back in. (And, BTW, the spaces from the second display are assigned to Display 1 when Display 2 is unplugged and are re-assigned to Display 2... the way it should). But of course, there needs to be something bizarre: I have 6 spaces on Display 1, and 3 spaces on Display 2... but when I unplug Display 2 I somehow have only 8 spaces total, so there are still a few things to shake down on this cruise.
2. The first big problem I had was with Mail.app. All of a sudden I had 18 unread messages that would not appear in my supposed "smart" inbox. Eventually found a solution; I don't think I used this post but it was equivalent: https://discussions.apple.com/thread/5477662. You have to trash a bunch of files in your Library (I just trashed the EnvelopeIndex files, which did the trick... this particular post has you trash a few more). Once it rebuilt the indexes, I could find the 18 "unread" messages which turned out to have been read years ago, but at least I could now flag them as read. Next freak-out: my flagged messages were all gone, and this would have been a fairly serious problem for my life. Fortunately, they reappeared a few hours later. Or maybe it took overnight. But then again, I have 175,000 emails, apparently. Your mileage is likely to be better. By a lot.
3. The next problem: VMWare Fusion 4 told me there wasn't enough physical memory to start the VM. Ouch! But I quit a few apps, started the VM and it worked... and when I restarted the other apps, everything worked just fine and seemed faster than it was before. But then, it seemed to have problems connecting to the network. The network connection had been a little persnickety in the past (like, had to use NAT rather than bridged, or maybe the other way around). I love VMWare Fusion, so I bit the bullet and got VMWare 6 for $42. Networking works, things run faster... and with VMWare 6 I am not getting the "not enough physical memory" message.
4. I did the iWork '09 upgrade. Not so happy with that. It lost the autofill in tables, which I use a lot... and it broke scripting. Back to Numbers '09 for me. But there was some panic when my scripting files seemed to be corrupted. I tried reloading them from Time Machine and those seemed to be corrupted, too. I eventually figured out that the problem is that it forgets about the Numbers '09 Applescript dictionary. You need to quit Numbers 3, restart Numbers '09, then load the script. Maybe restart for good measure. Honestly, maybe skip the iWork upgrade. Although I kind of like the cleaner UI design.
5. My script for the Calendar works, except the the last step is suddenly veeerrrry sllloooowwww, like 30 seconds. No idea why. Very annoying. I like the new Calendar UI.
6. A couple more things: I used Time Machine and Carbon Copy Cloner to make my backup, but discovered that my new WD myPassport 1 TB external drive, which I really like, is formatted with MBR partitioning, so it can't be bootable, among other things. So: (a) every time you get a new hard drive for your Mac, don't just repartition it like I did, reformat it using GPT, and then partition. (b) CCC now costs money, SuperDuper looks like it is a more inexpensive solution to do the same thing... which is mostly irrelevant now, with Time Machine, though having a bootable backup looks like it could come in handy.
7. Oh, and somewhere in there my SSD went from 10 GB free space to 30 GB free space!
So: faster, better monitor support, and more free space on my SSD! Overall looks like a big win so far!
Update 8 December: still very happy with Mavericks... it (together I suppose with the VMWare Fusion upgrade to 6) is enough faster that I have gone back to leaving the Windows 7 VM running all the time rather than suspending it when I'm not using it, which is definitely more convenient. At the same time, browsing is noticeably faster, whether it's in Chrome or Safari.
Wednesday, December 4, 2013
Friday, July 26, 2013
The Land of Trac
In the third grade, our teacher Mrs. Smithy read us The Lion, the Witch and the Wardrobe, the first of C.S. Lewis's Chronicles of Narnia, in which a group of kids find a secret door in the back of a wardrobe and enter a fantastical, undreamed-of world.
In the fifth grade, in 1968, I became part of a group of kids that had found such a door. The group was called the RESISTORS, and the door led to the world of computers and what is now called "information technology."
The group met in the house and barn of Claude Kagan, an engineer at the Western Electric Research Center in Pennington, NJ, near Princeton, where I grew up. Claude was a complicated guy, by turns fun-loving, cantankerous, generous, childish, and more—but unswerving in his commitment to value of letting young people learn things and above all do things. The principles of the RESISTORS were "Hands On" and "Each One Teach One," and those principles have stood me in good stead for the last 45 years. (As I side note, last night I read a piece by Atul Gawande in the New Yorker in which he wrote that an essential realization in the dissemination of the medical miracle of oral rehydration was that when teachers fanned out to villages, the teaching was much more effective if the villagers made the solution under the teacher's instruction than if the teacher "showed them how." This was one of the first things we learned as RESISTORS: if you are teaching people things, THEY should sit at the Teletype [a primitive 100 bps terminal, which no self-respecting Bangladeshi villager would tolerate today] and YOU should sit next to them, talking them through it.)
We used a number of computers and computer languages, but the computational beating heart of the group was Claude's PDP-8 computer at Western Electric, which we would dial into from a Teletype in his house. It ran Trac, a computer language designed by Calvin Mooers, an independent thinker based in Cambridge, Mass. The PDP-8 had 4K of RAM. Yes, 4K, i.e. one one-millionth of the amount of RAM in the two-pound MacBook I'm typing on right now. RAM was insanely expensive because it was made of little magnetic "cores" which were hand-strung, reportedly by armies of Filipinos. OK, actually it had 4K of 12-bit words, so technically you could say it had 6K bytes. A "Trac processor" (interpreter) could fit on such a machine, with some room left over for user-written scripts (programs). There is really no computer today so minuscule that Trac makes sense as a language, and even fewer people would ever have heard of Trac today if Ted Nelson hadn't happened upon the RESISTORS and mentioned Trac in Computer Lib.
Eventually we had our own PDP-8 in the barn, donated by the manufacturer, DEC (Digital Equipment Corporation). For us, DEC was the Rebel Alliance to IBM's Empire, to use an anachronistic Star Wars metaphor. This was before Microsoft managed to suck the life out of IBM, and that was before... oh well. The PDP-8 was the size of a "small household refrigerator," maybe 3' x 3' x 4', and it cost around $10,000 1968 dollars, and to be on the safe side you should have four guys to carry it. And your digital watch now has a more powerful computer.
Interestingly, the one aspect of my RESISTORS experience that has been a part of my life ever since is the importance of teaching. Computers have been a part of my life to varying degrees since those days; recently I had another spate of exposure because I had to maintain and extend a Python program that my son Ben was good enough to write me for a book project I'm working on. It's a great program, but Ben is a busy guy and couldn't be at my beck and call to get it all spiffy, so I learned Python (which I really enjoyed, partly due to Norm Matloff's Fast Lane to Python, a great way to get started if you already know some programming).
So I finished the book draft and, unusually, had some free time while I wait for comments to come back. Somehow I ran across Jack Trainor's partial Trac implementation in Python. He followed Mooers' original instructions, which were designed to be implemented in assembly language, which is "goto-ful." It looks like quite a torturous experience to try to implement them in the modern "goto-less" style, but he did it. At the end of his post, he says "It would be interesting to rewrite this interpreter with modern techniques and to implement the rest of the primitives, as well as to set up TRAC to run interactively." Apparently I decided that's what I should do. I didn't notice that he had in fact made (two) other implementations with more modern techniques, but oh well... and they weren't full implementations, and they weren't interactive.
I got the basics going in a weekend, but implementing the full language involved some very fussy stuff with the "form pointer," some Trac features I'd never used (the boolean primitives), and one I'd never even heard of (the IN primitive). But after about 10 days, I wound up with what I believe is a full implementation of Mooers' "T-64" standard. Programming in a modern high-level language, especially Python, is really quite a breeze. Fellow RESISTOR and actual übergeek John Levine said (in an unguarded moment), "I have to say, it looks pretty good," which, if I recall correctly, is pretty much what he said when he read James Joyce's Ulysses, and which in any case is certainly the high-water mark for my programming chops. Ben encouraged me to post it on GitHub, and (in the somewhat bizarre event that you care) you can download it from there without signing up just by hitting the "Download ZIP" button. The README has a link to the language description and a Trac manual.
At some point, I thought, "My God, what am I doing... I'm like a crazy middle-aged guy spending all his time in the garage restoring a Yugo to pristine condition because the first car he ever owned was a Yugo, even though his original one was always kind of a junker..."
But I started to think about the fact that my interpreter made essential use of recursion and the associated stack. Somehow, the Mooers algorithm did all that without a stack. Eventually I realized that the "neutral string," consisting of already-processed characters, essentially encodes the stack—it's an incredibly economical way to implement recursion.
My grandmother was born in the early 1890s and told me that she learned to drive on a "one-cylinder REO." So after realizing how ingenious Mooers' Trac design was, I think of myself as the obsessive middle-aged guy in the garage restoring the 1906 REO, not the Yugo guy. For whatever that's worth...
In the fifth grade, in 1968, I became part of a group of kids that had found such a door. The group was called the RESISTORS, and the door led to the world of computers and what is now called "information technology."
The group met in the house and barn of Claude Kagan, an engineer at the Western Electric Research Center in Pennington, NJ, near Princeton, where I grew up. Claude was a complicated guy, by turns fun-loving, cantankerous, generous, childish, and more—but unswerving in his commitment to value of letting young people learn things and above all do things. The principles of the RESISTORS were "Hands On" and "Each One Teach One," and those principles have stood me in good stead for the last 45 years. (As I side note, last night I read a piece by Atul Gawande in the New Yorker in which he wrote that an essential realization in the dissemination of the medical miracle of oral rehydration was that when teachers fanned out to villages, the teaching was much more effective if the villagers made the solution under the teacher's instruction than if the teacher "showed them how." This was one of the first things we learned as RESISTORS: if you are teaching people things, THEY should sit at the Teletype [a primitive 100 bps terminal, which no self-respecting Bangladeshi villager would tolerate today] and YOU should sit next to them, talking them through it.)
We used a number of computers and computer languages, but the computational beating heart of the group was Claude's PDP-8 computer at Western Electric, which we would dial into from a Teletype in his house. It ran Trac, a computer language designed by Calvin Mooers, an independent thinker based in Cambridge, Mass. The PDP-8 had 4K of RAM. Yes, 4K, i.e. one one-millionth of the amount of RAM in the two-pound MacBook I'm typing on right now. RAM was insanely expensive because it was made of little magnetic "cores" which were hand-strung, reportedly by armies of Filipinos. OK, actually it had 4K of 12-bit words, so technically you could say it had 6K bytes. A "Trac processor" (interpreter) could fit on such a machine, with some room left over for user-written scripts (programs). There is really no computer today so minuscule that Trac makes sense as a language, and even fewer people would ever have heard of Trac today if Ted Nelson hadn't happened upon the RESISTORS and mentioned Trac in Computer Lib.
Eventually we had our own PDP-8 in the barn, donated by the manufacturer, DEC (Digital Equipment Corporation). For us, DEC was the Rebel Alliance to IBM's Empire, to use an anachronistic Star Wars metaphor. This was before Microsoft managed to suck the life out of IBM, and that was before... oh well. The PDP-8 was the size of a "small household refrigerator," maybe 3' x 3' x 4', and it cost around $10,000 1968 dollars, and to be on the safe side you should have four guys to carry it. And your digital watch now has a more powerful computer.
Interestingly, the one aspect of my RESISTORS experience that has been a part of my life ever since is the importance of teaching. Computers have been a part of my life to varying degrees since those days; recently I had another spate of exposure because I had to maintain and extend a Python program that my son Ben was good enough to write me for a book project I'm working on. It's a great program, but Ben is a busy guy and couldn't be at my beck and call to get it all spiffy, so I learned Python (which I really enjoyed, partly due to Norm Matloff's Fast Lane to Python, a great way to get started if you already know some programming).
So I finished the book draft and, unusually, had some free time while I wait for comments to come back. Somehow I ran across Jack Trainor's partial Trac implementation in Python. He followed Mooers' original instructions, which were designed to be implemented in assembly language, which is "goto-ful." It looks like quite a torturous experience to try to implement them in the modern "goto-less" style, but he did it. At the end of his post, he says "It would be interesting to rewrite this interpreter with modern techniques and to implement the rest of the primitives, as well as to set up TRAC to run interactively." Apparently I decided that's what I should do. I didn't notice that he had in fact made (two) other implementations with more modern techniques, but oh well... and they weren't full implementations, and they weren't interactive.
I got the basics going in a weekend, but implementing the full language involved some very fussy stuff with the "form pointer," some Trac features I'd never used (the boolean primitives), and one I'd never even heard of (the IN primitive). But after about 10 days, I wound up with what I believe is a full implementation of Mooers' "T-64" standard. Programming in a modern high-level language, especially Python, is really quite a breeze. Fellow RESISTOR and actual übergeek John Levine said (in an unguarded moment), "I have to say, it looks pretty good," which, if I recall correctly, is pretty much what he said when he read James Joyce's Ulysses, and which in any case is certainly the high-water mark for my programming chops. Ben encouraged me to post it on GitHub, and (in the somewhat bizarre event that you care) you can download it from there without signing up just by hitting the "Download ZIP" button. The README has a link to the language description and a Trac manual.
At some point, I thought, "My God, what am I doing... I'm like a crazy middle-aged guy spending all his time in the garage restoring a Yugo to pristine condition because the first car he ever owned was a Yugo, even though his original one was always kind of a junker..."
But I started to think about the fact that my interpreter made essential use of recursion and the associated stack. Somehow, the Mooers algorithm did all that without a stack. Eventually I realized that the "neutral string," consisting of already-processed characters, essentially encodes the stack—it's an incredibly economical way to implement recursion.
My grandmother was born in the early 1890s and told me that she learned to drive on a "one-cylinder REO." So after realizing how ingenious Mooers' Trac design was, I think of myself as the obsessive middle-aged guy in the garage restoring the 1906 REO, not the Yugo guy. For whatever that's worth...
Subscribe to:
Posts (Atom)