It's certainly true that proprioception (the ability to sense joint location) and sensation of muscle tension are useful feedback systems in coordinating limb movements. It's well known in the field (I'm a neuroscientist), however, that several neurological conditions rob patients of these sensations and they're still able to move their limbs effectively (though not perfectly). I'd guess that a patient who was paralyzed wouldn't mind being able to move their arms again, even if they couldn't feel where they were without looking.
Playing video games is the standard way to teach monkeys tasks such as this. After all, we're monkeys and we don't seem to have any trouble plopping down in front of a video game for thousands of hours.
No one broke the monkeys' spines. The article states that the spinal neurons innervating the wrist muscles were temporarily blocked using a local anesthetic. What's particularly amazing about this study is that the monkeys were able to quickly learn to control their wrists using the cortical neurons that the computer was monitoring, even if those neurons were not involved in control of the wrist before paralysis.
I'm a friend of the paper's author and am certain that neither the researchers nor any sane review board would have allowed monkeys to be permanently injured to perform this study; it just wouldn't be necessary.
It seems that the Bush administration released this information to bolster their case that the newly gutted FISA (Federal Intelligence Service Act, the legislation that banned domestic spying and requires a warrant from a special FISA court to conduct evesdropping on US citizens). They claim that the intelligence gathering that lead to the arrest of the terrorism suspects in Germany happend only because of their new powers. I've seen nothing about whether they could have done the same evesdropping under the older (and some would argue, much better) FISA law. In particular, the NY Times article on the subject references intercepting email and phone traffic between non-US citizens who were not on US soil. I'm not sure that the restrictions of FISA would even apply in this case. Once again, this story may be just a bunch of smoke an mirrors from the Bush administration (though it is heartening to hear that the US intelligence agencies have managed to do one thing right in the "war on civil liber^D^D^D terror").
Given that new Macs run Windows (and Apple's BootCamp includes windows drivers for much of the Apple-specific hardware), and that most of Apple's (or other vendor's) peripherals also work with Windows (it's all USB now, anyways), I'd be surprised if you could walk into an Apple store and find much that didn't work with Windows.
Well, Charles Parnot who is the creator and manager of xgrid@stanford (and a major contributer to the Apple Xgrid community) is also a major player in this project. So, it's not really that curious.
As other posters have noted, many large applications can now be written in a combination of native and interpreted code. Web apps are a classic example, but in our neurophysiology lab, we're just completing a new data acquisition system that does real-time data acquisition from several types of A/D converters at up to 20kHz, writing all data to an SQLite database. The system is written on OS X and the combination of Objective-C and Python with PyObjC has let us pick at will between native and interpreted code. The real-time loop at the core of the system is written in C, the more stable parts of the system are written in Objective-C (along with the Cocoa framework, the most productive language/framework combo I've ever used for desktop apps) and the more quickly changing aspects of the system are written in Python and wrapped as OS X bundles by py2app. Our users are physiology researchers and they can now write code in python to customize the operation, including stimulus generation and experimental protocol; they don't need to ever touch native code. Development was a breeze and the users' productivity in changing the setup between experiments has increased as well.
Adding to the mix, most of our users do their data analysis in Matlab (another interpreted language). We've written a set of Matlab MEX files (loadable libraries that allow native code to be called from within the Matlab environment) with a similar scheme (a mix of Objective-C and PyObjC) to allow users to retrieve data from the SQLite database.
So the original poster's question could more accurately be summed up as, what ratio of native versus interpreted code is best for your application? The next question is not whether native or interpreted code is coming or going, but what each is going to do to make integratino of the two easier.
Why don't you put up some flyers at a local university? There are lots of competent unergrad C.S. majors who would love to get their hands dirty, given a little guidance. If you're not near a university with a C.S. department, I wouldn't worry. I'd expect you'll get a few offers from your post here.
The code examples, especially the rule-based GUI coding looks a lot like the Cocoa Bindings system in OS X. I wouldn't be suprised if this library was using something similar to Cocoa's controller layer under the hood. What's impressive is that they're able to do this in C++. Objective-C's more dynamic calling system makes this a lot easier.
I disagree that CS courses should be teaching "practical" programming. After courses in the fundamentals, I feel confident that I can pickup the details of a new API, a new toolkit, etc. with very little trouble. In fact, without knowing about algorithmic complexity, or the fundamentals of a hash table (to use the previous poster's example), I think I would have a much harder time evaluating and understanding these new "practical" technologies. Continuing with the same example, a collection toolkit nowadays (Java, Apple's Cocoa,.NET, etc.) has many more options than just a hashtable, perhaps even multiple implementations of a hashtable collection. Without the fundamentals, it would be much harder to choose the appropriate collection (for algorithmic running time or memory use or any other constraint) than it would be to learn the API for the collection after learning the fundamentals.
Having worked both in academia and business, I would always hire the graduate who understood the fundamentals. There's a reason why a CS degree takes most people a few years -- it takes a long time to learn the fundamentals and why you can learn Java (or insert your favorite API/toolkit here) in a couple of days.
I'd like to see the Microsoft Office for Mac OS X team use the UNIX knowledge to develop a supported version of Microsoft Office for Linux.
Although OS X is based on a BSD subsystem, I don't think the Mac Office code base will be very useful in developing a UNIX version of Office. Although OS X includes a BSD subsystem, the BSD API is only one of the available APIs on OS X. Office on OS X is written to the Carbon API (a rewrite of the old Mac OS APIs) and includes use of OS X-specific technologies such as Quartz (a display-PDF 2D graphics architecture). Using the Mac Office as a basis for a Linux port would require porting the proprietary Carbon/Quartz system to Linux.
The fact that so many people are willing to pay for our National Public Radio system in the states suggests that there are plenty of people willing to pay for radio--if the quality is there.
iCal 1.5.1 would be a real Entourage killer (in combination with AddressBook and Mail.app, of course) if Apple would implement recurring ToDo's. Reminders to pay the bills, etc., are the only think that remains in Entourage I can't live without.
It breaks the system because you either have to purposefully make your window narrower, or the side bar will be offscreen when it "pops up" (or out, rather).
This isn't necessarily true in Aqua. Although it's a little more work, it is possible to program the window to shrink by the required amount to keep the drawer on screen, then expand back to its original size when the drawer is put away. IIRC, Camino/Chimera used to do this with their old bookmark drawer (it's now Safari-style, in-window)
That these scientists downloaded their instructions off the net and used ordered the sequence mail order is not at all the shock that this story portrays it as. Virtually every common technique in molecular biology can be accomplished with a pre-made "kit" from one of several major vendors (e.g. Sigma, BioRad, Qiagen). These kits contain all the necessary reagents and instructions for completing the procedure. Most of the companies that produce these kits also post the instructions on their websites in case you loose the printed copy. Any trained molecular biologist would have a pretty easy time recreating the "kit" from the directions and the ingredient list.
As for getting DNA by mail, that's standard practice at most research labs I've been involved with. It's more expensive than producing it yourself, but a hell of a lot more convenient. Many universities even have their own, "in house", sequence generation facilities that labs interact with by, you guessed it, inter-departmental mail.
I'd say the poster of this story was taken by the shock value of these statements (and perhaps they are more shocking in our terrorist-paranoid times), but in reality, there's nothing to be suprised by.
Alcohol and Calculus don't mix. Never drink and derive!
I have to take exception to this! Beerculus, aka beer-enhanced-calculus, has been an integral part of my college education. Those long hours deriving useless theorems go much faster when you're buzzed.
What does a fingerprint or retinal scanner cost? Biometric passwords are definitely easy to remember and would take pretty serious effort to crack (though I've heard it's possible).
I know this wouldn't work in every situation. It seems that a lot of places where I use passwords would be amenable, though. Certainly if I'm physically located at the terminal, this is an easy solution (and there are many devices already on the market). If I'm not at the terminal, like accessing a website, why couldn't my biometric password be used as my public key for SSL et al.?
Rather than having the same arguments again and again about easy vs. secure text passwords, why don't we start using something better?
makes a lot more sense now. I was a bit surprised that they were going to be doing their rendering on a huge field of desktops. I wonder if they had any inside info that the Xserver was coming soon;)
Apple's newly released Remote Desktop [apple.com] allows remote access from any OS X box from any Mac OS >8.6 (i think). In addition it has a slew of remote administration features to boot.
Like other posters have said though, this won't get around your requirement of extreme availability (there is still a single point of failure).
Running the script hosed my system unrepairably. It would no longer boot into OS X AT ALL! Only a full reformat & re-install fixed it.
Definitely a YMMV is in order.
Being a Stanford student, I was currious how well it did on me and my friends. The output is pretty much dead on. It picks out my roomate as my as the person closest to me, and most of my friends as well. Not particularly suprising, given that we are all on similar listserv lists (and all residence in each dorm are on a dorm list). Nevertheless, pretty striking.
I'd be currious how it did in a less highly connected (in terms of listserv and homepage connectivity) community.
While TAing courses for the introductory CS sequence at Stanford, I had several students ask me if they could use gcc instead of VC++ or CodeWarrior. Our standard answer was that support was only officiallyoffered for the supported platforms, but that if they were up for the challenge of figuring it out to go for it. Of course, I offered to help whenever I could (and was actually quite happy to be helping someone on Linux instead of Windows and VC++). To be fair, I did ask them to submit code that compiled under one of the supported platforms. Again, I offered my assistance if they ran into any problems "porting" their code between compilers.
So, my suggestion is to talk to your TA. More likely than not, he or she will be happy to help you work it out.
Well, Solaris has handled many more than 48 cores for years. Too bad Solaris' future looks grim at the best, following Oracle's acquisition of Sun.
It's certainly true that proprioception (the ability to sense joint location) and sensation of muscle tension are useful feedback systems in coordinating limb movements. It's well known in the field (I'm a neuroscientist), however, that several neurological conditions rob patients of these sensations and they're still able to move their limbs effectively (though not perfectly). I'd guess that a patient who was paralyzed wouldn't mind being able to move their arms again, even if they couldn't feel where they were without looking.
Playing video games is the standard way to teach monkeys tasks such as this. After all, we're monkeys and we don't seem to have any trouble plopping down in front of a video game for thousands of hours.
No one broke the monkeys' spines. The article states that the spinal neurons innervating the wrist muscles were temporarily blocked using a local anesthetic. What's particularly amazing about this study is that the monkeys were able to quickly learn to control their wrists using the cortical neurons that the computer was monitoring, even if those neurons were not involved in control of the wrist before paralysis.
I'm a friend of the paper's author and am certain that neither the researchers nor any sane review board would have allowed monkeys to be permanently injured to perform this study; it just wouldn't be necessary.
It seems that the Bush administration released this information to bolster their case that the newly gutted FISA (Federal Intelligence Service Act, the legislation that banned domestic spying and requires a warrant from a special FISA court to conduct evesdropping on US citizens). They claim that the intelligence gathering that lead to the arrest of the terrorism suspects in Germany happend only because of their new powers. I've seen nothing about whether they could have done the same evesdropping under the older (and some would argue, much better) FISA law. In particular, the NY Times article on the subject references intercepting email and phone traffic between non-US citizens who were not on US soil. I'm not sure that the restrictions of FISA would even apply in this case. Once again, this story may be just a bunch of smoke an mirrors from the Bush administration (though it is heartening to hear that the US intelligence agencies have managed to do one thing right in the "war on civil liber^D^D^D terror").
With a market cap of $284.17 Billion, and approx. $49 Billion in assets [1], I'd say quite a few.
[1] http://finance.google.com/finance?q=MSFT
Given that new Macs run Windows (and Apple's BootCamp includes windows drivers for much of the Apple-specific hardware), and that most of Apple's (or other vendor's) peripherals also work with Windows (it's all USB now, anyways), I'd be surprised if you could walk into an Apple store and find much that didn't work with Windows.
Well, Charles Parnot who is the creator and manager of xgrid@stanford (and a major contributer to the Apple Xgrid community) is also a major player in this project. So, it's not really that curious.
As other posters have noted, many large applications can now be written in a combination of native and interpreted code. Web apps are a classic example, but in our neurophysiology lab, we're just completing a new data acquisition system that does real-time data acquisition from several types of A/D converters at up to 20kHz, writing all data to an SQLite database. The system is written on OS X and the combination of Objective-C and Python with PyObjC has let us pick at will between native and interpreted code. The real-time loop at the core of the system is written in C, the more stable parts of the system are written in Objective-C (along with the Cocoa framework, the most productive language/framework combo I've ever used for desktop apps) and the more quickly changing aspects of the system are written in Python and wrapped as OS X bundles by py2app. Our users are physiology researchers and they can now write code in python to customize the operation, including stimulus generation and experimental protocol; they don't need to ever touch native code. Development was a breeze and the users' productivity in changing the setup between experiments has increased as well.
Adding to the mix, most of our users do their data analysis in Matlab (another interpreted language). We've written a set of Matlab MEX files (loadable libraries that allow native code to be called from within the Matlab environment) with a similar scheme (a mix of Objective-C and PyObjC) to allow users to retrieve data from the SQLite database.
So the original poster's question could more accurately be summed up as, what ratio of native versus interpreted code is best for your application? The next question is not whether native or interpreted code is coming or going, but what each is going to do to make integratino of the two easier.
Why don't you put up some flyers at a local university? There are lots of competent unergrad C.S. majors who would love to get their hands dirty, given a little guidance. If you're not near a university with a C.S. department, I wouldn't worry. I'd expect you'll get a few offers from your post here.
The code examples, especially the rule-based GUI coding looks a lot like the Cocoa Bindings system in OS X. I wouldn't be suprised if this library was using something similar to Cocoa's controller layer under the hood. What's impressive is that they're able to do this in C++. Objective-C's more dynamic calling system makes this a lot easier.
I disagree that CS courses should be teaching "practical" programming. After courses in the fundamentals, I feel confident that I can pickup the details of a new API, a new toolkit, etc. with very little trouble. In fact, without knowing about algorithmic complexity, or the fundamentals of a hash table (to use the previous poster's example), I think I would have a much harder time evaluating and understanding these new "practical" technologies. Continuing with the same example, a collection toolkit nowadays (Java, Apple's Cocoa, .NET, etc.) has many more options than just a hashtable, perhaps even multiple implementations of a hashtable collection. Without the fundamentals, it would be much harder to choose the appropriate collection (for algorithmic running time or memory use or any other constraint) than it would be to learn the API for the collection after learning the fundamentals.
Having worked both in academia and business, I would always hire the graduate who understood the fundamentals. There's a reason why a CS degree takes most people a few years -- it takes a long time to learn the fundamentals and why you can learn Java (or insert your favorite API/toolkit here) in a couple of days.
Although OS X is based on a BSD subsystem, I don't think the Mac Office code base will be very useful in developing a UNIX version of Office. Although OS X includes a BSD subsystem, the BSD API is only one of the available APIs on OS X. Office on OS X is written to the Carbon API (a rewrite of the old Mac OS APIs) and includes use of OS X-specific technologies such as Quartz (a display-PDF 2D graphics architecture). Using the Mac Office as a basis for a Linux port would require porting the proprietary Carbon/Quartz system to Linux.
The fact that so many people are willing to pay for our National Public Radio system in the states suggests that there are plenty of people willing to pay for radio--if the quality is there.
iCal 1.5.1 would be a real Entourage killer (in combination with AddressBook and Mail.app, of course) if Apple would implement recurring ToDo's. Reminders to pay the bills, etc., are the only think that remains in Entourage I can't live without.
This isn't necessarily true in Aqua. Although it's a little more work, it is possible to program the window to shrink by the required amount to keep the drawer on screen, then expand back to its original size when the drawer is put away. IIRC, Camino/Chimera used to do this with their old bookmark drawer (it's now Safari-style, in-window)
That these scientists downloaded their instructions off the net and used ordered the sequence mail order is not at all the shock that this story portrays it as. Virtually every common technique in molecular biology can be accomplished with a pre-made "kit" from one of several major vendors (e.g. Sigma, BioRad, Qiagen). These kits contain all the necessary reagents and instructions for completing the procedure. Most of the companies that produce these kits also post the instructions on their websites in case you loose the printed copy. Any trained molecular biologist would have a pretty easy time recreating the "kit" from the directions and the ingredient list.
As for getting DNA by mail, that's standard practice at most research labs I've been involved with. It's more expensive than producing it yourself, but a hell of a lot more convenient. Many universities even have their own, "in house", sequence generation facilities that labs interact with by, you guessed it, inter-departmental mail.
I'd say the poster of this story was taken by the shock value of these statements (and perhaps they are more shocking in our terrorist-paranoid times), but in reality, there's nothing to be suprised by.
I have to take exception to this! Beerculus, aka beer-enhanced-calculus, has been an integral part of my college education. Those long hours deriving useless theorems go much faster when you're buzzed.
What does a fingerprint or retinal scanner cost? Biometric passwords are definitely easy to remember and would take pretty serious effort to crack (though I've heard it's possible).
I know this wouldn't work in every situation. It seems that a lot of places where I use passwords would be amenable, though. Certainly if I'm physically located at the terminal, this is an easy solution (and there are many devices already on the market). If I'm not at the terminal, like accessing a website, why couldn't my biometric password be used as my public key for SSL et al.?
Rather than having the same arguments again and again about easy vs. secure text passwords, why don't we start using something better?
makes a lot more sense now. I was a bit surprised that they were going to be doing their rendering on a huge field of desktops. I wonder if they had any inside info that the Xserver was coming soon ;)
Apple's newly released Remote Desktop [apple.com] allows remote access from any OS X box from any Mac OS >8.6 (i think). In addition it has a slew of remote administration features to boot. Like other posters have said though, this won't get around your requirement of extreme availability (there is still a single point of failure).
Running the script hosed my system unrepairably. It would no longer boot into OS X AT ALL! Only a full reformat & re-install fixed it.
Definitely a YMMV is in order.
Being a Stanford student, I was currious how well it did on me and my friends. The output is pretty much dead on. It picks out my roomate as my as the person closest to me, and most of my friends as well. Not particularly suprising, given that we are all on similar listserv lists (and all residence in each dorm are on a dorm list). Nevertheless, pretty striking. I'd be currious how it did in a less highly connected (in terms of listserv and homepage connectivity) community.
While TAing courses for the introductory CS sequence at Stanford, I had several students ask me if they could use gcc instead of VC++ or CodeWarrior. Our standard answer was that support was only officiallyoffered for the supported platforms, but that if they were up for the challenge of figuring it out to go for it. Of course, I offered to help whenever I could (and was actually quite happy to be helping someone on Linux instead of Windows and VC++). To be fair, I did ask them to submit code that compiled under one of the supported platforms. Again, I offered my assistance if they ran into any problems "porting" their code between compilers. So, my suggestion is to talk to your TA. More likely than not, he or she will be happy to help you work it out.