One really great thing about living in our tiny little city is every year there is a huge car show on the second Saturday of June. This means that the whole week leading up to the show you start seeing all kinds of cool, rare, unusual cars around town. Just now we saw a Pontiac G8 GXP, a BMW-looking (and performing) little rocket. The GXP is the extra-special version with a 415 hp Corvette engine and 6 speed manual tranny, along with Brembo brakes and a tighter suspension. This is an awesome car all around; don't make the mistake of getting in a stoplight drag race with it, because it'll get to 60 in 4.5 seconds; not bad for a ~$40,000 car.
The car only was brought to the U.S. in 2008 and 2009 (and maybe 2010 according to this article at topspeed.com), imported from Australia as a re-badged Holden Commodore. The run-of-the-mill ones are going for about $18,000 used right now, and I imagine if you can even find a GXP for sale it would be for significantly more.
Tuesday, June 07, 2011
Sunday, May 22, 2011
Distributed Applications
I read an article by Cory Doctorow in volume 26 of Make Magazine about two interrelated topics: distributed denial of service (DDoS) attacks, and the difficulty of finding a willing hosting provider for your site when it comes under scrutiny from and legal pressure by government agencies seeking information and data by force. In each case, your site, or one upon which you rely, can be slowed or stopped, either by a person or group who apply brute-force technology (whether governmental or otherwise), or by the equally overwhelming force of law. The result in either case is a chilling effect upon the willingness of hosting providers to host your site once it becomes more trouble than it is worth.
It got me thinking about what might be done to prevent or frustrate such attacks; is there a way to distribute not only the network itself, but the applications that run on it as well? Server farms and load balancers don't go far enough because they still concentrate application resources at one provider, even if they have multiple locations, backups, alternate internet backbones, and all the rest of the safeguards that go toward giving them the ability to guarantee uptime.
What comes to mind is a protocol like BitTorrent where resources are distributed not in a client-server way but in a peer-to-peer topology, providing redundancy and distribution of data in a way that would be much more difficult to stop or interrogate than the traditional internet server model. Imagine a DDoS attempt on a BitTorrent "hosted" application: there is no single choke point to attack. What about a subpoena requesting hosting information when the peer hosts are so varied in number and location?
Of course there is a major flaw in this simplistic approach: how do you trust the peers who are hosting part of your application not to poison the torrent, examine incoming and outgoing traffic, etc? Also, the nature of applications today is that they are interactive and real-time, not "download once and run," and even if you did choose to use application logic that lives solely on the client once it is obtained, in most cases in order to be useful at all the application will need to communicate with network resources and possibly persist data in the cloud.
But, in terms just of redundancy, distribution, and the lack of a central hosting provider, that kind of model seems like a step in the right direction.
It got me thinking about what might be done to prevent or frustrate such attacks; is there a way to distribute not only the network itself, but the applications that run on it as well? Server farms and load balancers don't go far enough because they still concentrate application resources at one provider, even if they have multiple locations, backups, alternate internet backbones, and all the rest of the safeguards that go toward giving them the ability to guarantee uptime.
What comes to mind is a protocol like BitTorrent where resources are distributed not in a client-server way but in a peer-to-peer topology, providing redundancy and distribution of data in a way that would be much more difficult to stop or interrogate than the traditional internet server model. Imagine a DDoS attempt on a BitTorrent "hosted" application: there is no single choke point to attack. What about a subpoena requesting hosting information when the peer hosts are so varied in number and location?
Of course there is a major flaw in this simplistic approach: how do you trust the peers who are hosting part of your application not to poison the torrent, examine incoming and outgoing traffic, etc? Also, the nature of applications today is that they are interactive and real-time, not "download once and run," and even if you did choose to use application logic that lives solely on the client once it is obtained, in most cases in order to be useful at all the application will need to communicate with network resources and possibly persist data in the cloud.
But, in terms just of redundancy, distribution, and the lack of a central hosting provider, that kind of model seems like a step in the right direction.
Saturday, February 05, 2011
Unresponsive Mac Mini at login or blue screen
I just resolved a very long-standing problem with our Mac Mini that has been dogging me ever since upgrading to Snow Leopard. The problem was that the machine would stick on the blue screen when logging off one user and before displaying the login screen. Then, even after displaying the login screen mouse clicks were unresponsive, although the mouse pointer still moved in response to user input.
I tried a lot of fixes, some expensive:
1) Install new RAM, taking it from 1gb to 4gb
2) Install a larger hard disk drive, taking it from 120gb to 320gb (now using the 120 on a Linux machine and it reports as being perfectly healthy, as it did within OSX)
3) Added the entire HDD to the "privacy" list in Spotlight to prevent indexing of the entire disk
4) Disabled indexing from the command line (and did not turn it back on)
5) Ran Disk Utility | Repair Disk Permissions
All of those are things that various posters in various forums suggested as a fix to what sounded like the same or very similar problems, but none of them worked. Finally I had an idea to search on terms related to the login screen and fast user switching rather than things like "slow," "unresponsive," and the like. Something I saw caught my eye relating to fast user switching and a difference in the way the Accounts utility presents the options for fast user switching between newer versions of OSX and older ones. Most interesting is the fact that we were not using fast user switching; if I was logged in and my wife wanted to use the computer, I had to log out and then she could log in. I think at one point I may intentionally have disabled fast user switching, thinking that it was a way to conserve system resources and therefore improve performance.
It turns out that with Snow Leopard you don't so much get to choose between *whether* to use fast user switching and single-user-only mode, you just get to choose *how* OSX goes about it by choosing an option in the "Show fast user switching menu as:" dropdown list, which has a checkbox next to it that controls whether you actually use fast user switching. On our machine that option was unchecked, so I checked it and left the default option of "Name" in the list. Here's what it looks like in the Accounts screen:
The difference is like night and day: no more lag, no more wondering if the screen ever will come back, it just works. So far I have tested by locking my screen, logging in as a different user, locking that screen, switching back to my screen, and other tests like that. I also have logged completely off a user and back on as an already logged-on user, and a couple of other combinations that fit the pattern of our normal, regular usage of the machine, and they all still work. What I haven't tried yet (because I wanted to post this blog entry and not risk being unable to log back in immediately) is powering the computer all the way down and turning it back on, which also exhibited the same frustrating behavior.
At the moment I'm not feeling brave enough to test the negative by unchecking the box to see if the behavior returns, but that's my hypothesis. Looking at things from a black box perspective, it would seem that there is some kind of hangup within OSX where it lags like crazy when switching users if you are in Snow Leopard and if you have unchecked the "Show fast user switching menu as:" checkbox. Rather than letting the user check the checkbox that causes all the trouble and does not otherwise seem to control any option, perhaps that checkbox should just go away.
If you are having the horribly frustrating behavior like we were having and have tried everything else to no avail, take a look at your Accounts settings and see if the fast user switching checkbox is unchecked; it's about as simple a solution as you can get to an incredibly frustrating problem, it's just not at all obvious or even intuitive how to go about finding the fix.
I tried a lot of fixes, some expensive:
1) Install new RAM, taking it from 1gb to 4gb
2) Install a larger hard disk drive, taking it from 120gb to 320gb (now using the 120 on a Linux machine and it reports as being perfectly healthy, as it did within OSX)
3) Added the entire HDD to the "privacy" list in Spotlight to prevent indexing of the entire disk
4) Disabled indexing from the command line (and did not turn it back on)
5) Ran Disk Utility | Repair Disk Permissions
All of those are things that various posters in various forums suggested as a fix to what sounded like the same or very similar problems, but none of them worked. Finally I had an idea to search on terms related to the login screen and fast user switching rather than things like "slow," "unresponsive," and the like. Something I saw caught my eye relating to fast user switching and a difference in the way the Accounts utility presents the options for fast user switching between newer versions of OSX and older ones. Most interesting is the fact that we were not using fast user switching; if I was logged in and my wife wanted to use the computer, I had to log out and then she could log in. I think at one point I may intentionally have disabled fast user switching, thinking that it was a way to conserve system resources and therefore improve performance.
It turns out that with Snow Leopard you don't so much get to choose between *whether* to use fast user switching and single-user-only mode, you just get to choose *how* OSX goes about it by choosing an option in the "Show fast user switching menu as:" dropdown list, which has a checkbox next to it that controls whether you actually use fast user switching. On our machine that option was unchecked, so I checked it and left the default option of "Name" in the list. Here's what it looks like in the Accounts screen:
The difference is like night and day: no more lag, no more wondering if the screen ever will come back, it just works. So far I have tested by locking my screen, logging in as a different user, locking that screen, switching back to my screen, and other tests like that. I also have logged completely off a user and back on as an already logged-on user, and a couple of other combinations that fit the pattern of our normal, regular usage of the machine, and they all still work. What I haven't tried yet (because I wanted to post this blog entry and not risk being unable to log back in immediately) is powering the computer all the way down and turning it back on, which also exhibited the same frustrating behavior.
At the moment I'm not feeling brave enough to test the negative by unchecking the box to see if the behavior returns, but that's my hypothesis. Looking at things from a black box perspective, it would seem that there is some kind of hangup within OSX where it lags like crazy when switching users if you are in Snow Leopard and if you have unchecked the "Show fast user switching menu as:" checkbox. Rather than letting the user check the checkbox that causes all the trouble and does not otherwise seem to control any option, perhaps that checkbox should just go away.
If you are having the horribly frustrating behavior like we were having and have tried everything else to no avail, take a look at your Accounts settings and see if the fast user switching checkbox is unchecked; it's about as simple a solution as you can get to an incredibly frustrating problem, it's just not at all obvious or even intuitive how to go about finding the fix.
Subscribe to:
Posts (Atom)