Anyone who thought about it for more than a second or two would have realised that it was never going to be a vulnerability in the default MacBook Pro hardware or drivers. If it wasn't, why would they need to introduce a third-party wireless adapter at all?
Frankly, the disclosure here was pretty amateurish. Surely they would have known that demoing the vulnerability on Apple hardware would have implicated Apple. In fact based on the "aura of smugness on security" comment it looks like they deliberately *chose* Apple hardware to be falsely implicated.
Another use: OS Installers
on
GTK+ TTY Port
·
· Score: 1
Didn't see this one mentioned.
Assuming that the runtime requirements can be made small enough, this would be an ideal way to rewrite the long-suffering FreeBSD systinsall! (and others)
Re:We need everything rolled into one device
on
Cisco's Wi-Fi Phone
·
· Score: 1
What they need to do now is create a hybrid cell/wi-fi/VoIP phone with bluetooth that can auto-sense where it is in relation to your desk and/or office building.
I don't think you're going to get a one-size-fits-all solution for all your data, but the following might give you something to think about.
For a while now I have been using CVS to store my commonly-shared data like.rc files, scripts, etc. It's easy to set up a repository, and very easy to get at the data from anywhere, over ssh. Cygwin is the ssh/cvs client of choice on windows.
The biggest effort I have found is in writing portable data that can be shared on all machines. And even then this problem can probably be avoided with branching or similar...
Slashdot Mirror
Anyone who thought about it for more than a second or two would have realised that it was never going to be a vulnerability in the default MacBook Pro hardware or drivers. If it wasn't, why would they need to introduce a third-party wireless adapter at all?
Frankly, the disclosure here was pretty amateurish. Surely they would have known that demoing the vulnerability on Apple hardware would have implicated Apple. In fact based on the "aura of smugness on security" comment it looks like they deliberately *chose* Apple hardware to be falsely implicated.
Do these guys have *any* credibility left?
http://www.gotfuturama.com/Multimedia/EpisodeSound s/4ACV11/
Summary Here
Didn't see this one mentioned.
Assuming that the runtime requirements can be made small enough, this would be an ideal way to rewrite the long-suffering FreeBSD systinsall! (and others)
Like everyone says, cygwin is the winner.
You might want to check here for some hints on installation. (In addition to the user guide and readmes of course).
I don't think you're going to get a one-size-fits-all solution for all your data, but the following might give you something to think about.
.rc files, scripts, etc. It's easy to set up a repository, and very easy to get at the data from anywhere, over ssh. Cygwin is the ssh/cvs client of choice on windows.
For a while now I have been using CVS to store my commonly-shared data like
The biggest effort I have found is in writing portable data that can be shared on all machines. And even then this problem can probably be avoided with branching or similar...
Food for thought anyway.