If you plug your power-only USB cable into a modern charger, you'll find that your phone charges quite a bit slower than you'd expect. Modern chargers use the data pins to negotiate whether a charger supports higher currents.
You don't want a phone to try drawing 2A from a charger that's only designed for 500mA.
What's tuggin away at my trouserleg of concern is: How many other experients, with this cable in place, turned out as expected?
Bit of a poser, that one.
Likely none.
My understanding is that the GPS setup was designed specifically for this experiment. Most experiments conducted at the LHC (or Gran Sasso) would be done entirely on-site and therefore don't need a super-accurate global time source.
From what I understand, the Diginotor CRL isn't to be trusted at this point. Logs were deleted as part of the hack, and they're not completely sure which fraudulent certificates were issued.
Their OCSP servers were modified to consider all certificates as revoked, except for those on a whitelist. This is the opposite of how OCSP usually works, and the correct approach in this situation. However, CRLs can only be used as a blacklist.
It makes a big difference for web-based applications that are implemented primarily in JavaScript.
For example: If you're designing slides for a presentation, playing a 3D game, or editing a photo -- things that are graphics heavy and CPU intensive -- you want to get as much performance out of the JS interpreter as possible.
While I don't mean to dismiss your claim that GSM is more widespread than cdmaOne/CDMA2000, GSM certainly isn't used everywhere outside of the US. For instance, I just returned from a trip to Japan, and there is no GSM installation there. Instead, there's a mix of cdmaOne/CDMA2000, W-CDMA, PDC, and PHS.
Maybe I'm wrong, but I'm pretty sure the post I replied to was talking about RR's DNS, not OpenDNS.
Yes, of course the DNS server isn't tracking MAC addresses directly. After all, DNS sits on top of UDP/TCP. However, I don't think they're doing any tricks with DHCP, since the changes take effect way before my DHCP lease expires.
My guess is that the DNS server takes the current request's IP address, queries the DHCP server to see what MAC address it's currently assigned to, then uses that to check the preferences database. However, without knowing RR's architecture, this is all speculation.
All I was trying to get at is that it seems the preferences are keyed on the user's MAC address, rather than IP address, and therefore won't get reset when the user gets assigned a new address by DHCP (unlike OpenDNS, which requires that users on a dynamic IP use a dynamic DNS update client to keep their preferences associated with the right machine).
I'm sure a properly written Java app can come close to a native OS X app, but I've never seen one that fit in perfectly. There's just always some little things that don't feel right, even if the widgets behave properly.
It's not a fault of Java, I just think its the reality of cross platform programming. It's just plain hard to write an app that behaves properly in every environment.
Camino can't support extensions because it doesn't use XUL for rendering its UI. If they used XUL, then they'd no longer feel like a native Mac app.
Take a look at all of the cross platform frameworks out there. Qt+, Java, etc. I have never seen an app written with any of those frameworks that feels native on OS X. Widgets are ever so slightly different and are sized differently. Sheets don't exist on other systems. Tabs often appear as tabs rather than as a row of buttons. Apple's human interface guidelines differ from what would be expected on Windows. The keychain doesn't exist on other platforms. I could go on.
Quite simply, there's no good way to write a cross platform app and make it feel native everywhere.
Oh, and for what it's worth, Camino supports plugins. It just doesn't support Firefox's plugins.
Is the source code included? It says only "Solaris," not "OpenSolaris," so I'm guessing that it's not. If it were, that would be cool.
Yes, but how often does somebody want do development from a DVD? Especially with open source software, by the time you receive the disk your tree is out of date. Plus, there's no easy way to merge in new changes when they inevitably happen.
In principle, including the source on disk is a nice idea. In practice, just check it out from RCS.
Really, the ACID test is about using techniques as complicated (and pointless) as they get to break browsers, while real web dev is about making sites that work.
A browser that passes the test is not automatically better than one that doesn't.
I beg to differ. The whole idea behind standards is to provide a single target to develop for. While the Acid2 test just tests a small subset of those standards, it's still important. Quite frankly, I'm sick of seeing different resuls in MSIE whenver I develop a web page, and I'm sick of sites that break in anything except Internet Explorer just because they decided to cater to its bugs and deficiencies.
Yes, the ultimate test of a web browser is whether the page renders and works correctly. However, the closer browsers are to meeting the W3C standards, the less likely it is that a page will work in one browser and not another.
Oh, and for the record, a lot of tests are not "complicated and pointless". Sure, there's some stuff you probably won't take advantage of, but theres a lot of stuff in there that would make web developers' lives easier should browsers ever consistently support it. I suggest you read the Acid2 Guided Tour.
A similar article by zdnet.co.uk was brought up a few days ago on the DShield discussion list. One choice quote is from Johannes Ullrich, a member of the SANS Internet Storm Center and the developer of DShield:
We do receive reports from about 500-700k IP addresses each day. Including the full list would be hard (or make for a very large worm). In addition, many of these IPs are dynamic, so you have to exclude networks rather then individual IPs.
To put it down bluntly: If every IP is a sensor, there is nobody left to attack;-)
For those of you who don't know, DShield is precisely one of the 'early-warning sensor' networks the article is talking about.
I ask the same thing every time I hear about people being charged extra in order to place a call to a mobile number in certain countries. At least with the system in the US you don't inconvenience others if you elect not to use a landline phone or give out the number to your cellphone.
On the other hand, people would be sure to think twice before calling their friends all the time, resulting in less phones going off in the theater, which is definitely a good thing.
I think this is going to become more of an issue as software projects choose to target different versions of Apache.
For instance, recently I was setting up a Subversion server for a project I was working on. It turns out that if you want to run Subversion over WebDAV/DeltaV, you are forced to use the Apache 2 series. As many have pointed out, if you try to use PHP in this environment httpd will randomly die off since PHP isn't thread-safe. When you are using Apache to write information, rather than read it, this is a very troubling issue.
Of course, this is easy enough to work around, you can either use one of the other access methods that Subversion supports, or install both versions of Apache simultaneously, placing them on different ports, or simply choose not to use PHP, however these are all workarounds, not solutions. Imagine what happens if other software takes this approach, say for example jboss, and you need to use both for different parts of your site. Suddenly, the "run both servers concurrently" approach doesn't look very attractive.
Actually, installing most Mac software does not need an admin password to be installed, since/Applications is writable by the admin group. You do need to be logged in using a user with admin privileges, but you won't need to type your password. Only if your program is either modifying system files or has a poorly written installer will it ask for an admin password so that it can execute sudo and gain root access. For this reason, anytime somebody gets a window asking for an admin password while installing something they should probably be a bit suspicious.
That being said,/Library/StartupItems is not writable by the admin group, so as long as somebody doesn't already have the password for root or an admin user (at which point you're already in trouble), I can't see this magically appearing on your system. Still, you're right, it would be trivial to build an installer bundle that would prompt for an admin password, and most users would probably put it in without a second thought.
I think this is a good time to bring up Franklin's quote:
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety."
We're not just looking at people who have "broken the law." We're looking for people who, for one reason or another look "suspicious." Now, how do you tell who is a threat? Is it because of their job? What about their bank account? Maybe they attended some rally for a certain cause? Or maybe we look at their nationality?
I don't believe any of these can accurately determine who is more likely to be a "terrorist" then somebody else. That job is best performed by metal detectors, x-ray machines, and other measures which look for actual threats. Not by a database that says, in the eyes of the TSA, I just might happen to be a threat.
Sure, this system will give a green-light to most passengers, and some of those who are stopped may actually pose a threat. But in the end, I think this system will have the most impact on people who aren't really a threat, just happen to be a little more outspoken then everybody else. They are the people who are trying create change in the world, and they are the people a government tends to fear most of all.
Ummm, I don't know what you're talking about. Video on a mac is quite possibly one of the easiest things you can do. Let me break it down for you: 1. Turn camera on 2. Connect camera to your computer using a firewire cable 3. Open video software (iMovie or Final Cut Pro/Express) and use the capture command.
Thats it, no software, no device drivers. I've done it many times using different software and cameras, and I've never had a problem. I've even used an analog capture box without any problems (except for the fact that the capture box was set to PAL when it arrived in the mail, but that's not the mac's fault;)). True, you can't use a USB cable, but I don't know why you'd want to. USB 1.1 is far too slow to handle an NTSC video stream, and firewire has long been considered the standard for digital video transfer anyway.
According to Wolfram's MathWorld site, Perelman's proof is described in two papers, located online here and subsequently, here.
Of course, I'm pretty sure the reason they're not mentioned in the article is because the most people reading the article would probably have some difficulty trying to understanding them.;)
The difference between this and other programs is the quality of the files created. Other programs will allow you to capture analog audio output. While you can certainly save that output to a WAV or AIFF file without a loss of quality, file size will increase tremendously. On the other hand, if you decide to convert it back to aac, you'll lose qualilty when the song is recompressed. By capturing the raw AAC stream, this program allows you to output an exact copy of the original downloaded song without DRM, no size bloat and no loss of quality.
There are a few cases where this could be "legitimately" used. For example, if you bought your songs in the US, but later move to another country, as soon as you change your credit card address iTunes would supposedly disable access to your own songs. This program would prevent this. Unfortunately, it is far more likely that this will be used to enable outright piracy.
Actually, it would be next to impossible to burn, since GameCube discs actually spin backwards in the drive!
When Nintendo designed the system, they did this explicitly to stop piracy. I think that the GC's disc format has probably been one of the major reasons why nobody has seen any attempts to port Linux to GameCube yet.
Slashdot Mirror
If you plug your power-only USB cable into a modern charger, you'll find that your phone charges quite a bit slower than you'd expect. Modern chargers use the data pins to negotiate whether a charger supports higher currents.
You don't want a phone to try drawing 2A from a charger that's only designed for 500mA.
These boards have quite a bit of logic on them. If they were just cutting the data pins, that would all be unnecessary.
The product page is light on details, but I'd be surprised if that logic wasn't there precisely to negotiate charge rate.
Likely none.
My understanding is that the GPS setup was designed specifically for this experiment. Most experiments conducted at the LHC (or Gran Sasso) would be done entirely on-site and therefore don't need a super-accurate global time source.
From what I understand, the Diginotor CRL isn't to be trusted at this point. Logs were deleted as part of the hack, and they're not completely sure which fraudulent certificates were issued.
Their OCSP servers were modified to consider all certificates as revoked, except for those on a whitelist. This is the opposite of how OCSP usually works, and the correct approach in this situation. However, CRLs can only be used as a blacklist.
Source: http://isc.sans.edu/diary.html?storyid=11512
It makes a big difference for web-based applications that are implemented primarily in JavaScript.
For example: If you're designing slides for a presentation, playing a 3D game, or editing a photo -- things that are graphics heavy and CPU intensive -- you want to get as much performance out of the JS interpreter as possible.
The slides are here: http://www.openbsd.org/papers/asiabsdcon2009-release_engineering/
While I don't mean to dismiss your claim that GSM is more widespread than cdmaOne/CDMA2000, GSM certainly isn't used everywhere outside of the US. For instance, I just returned from a trip to Japan, and there is no GSM installation there. Instead, there's a mix of cdmaOne/CDMA2000, W-CDMA, PDC, and PHS.
Reference: http://euc.jp/misc/cellphones.en.html
According to Wikipedia, semi-annual reports need to be made to congress, including a non-classified count of National Security Letters issued.
The US Department of Justice also performed an audit in 2007 that contains some more statistics.
Maybe I'm wrong, but I'm pretty sure the post I replied to was talking about RR's DNS, not OpenDNS.
Yes, of course the DNS server isn't tracking MAC addresses directly. After all, DNS sits on top of UDP/TCP. However, I don't think they're doing any tricks with DHCP, since the changes take effect way before my DHCP lease expires.
My guess is that the DNS server takes the current request's IP address, queries the DHCP server to see what MAC address it's currently assigned to, then uses that to check the preferences database. However, without knowing RR's architecture, this is all speculation.
All I was trying to get at is that it seems the preferences are keyed on the user's MAC address, rather than IP address, and therefore won't get reset when the user gets assigned a new address by DHCP (unlike OpenDNS, which requires that users on a dynamic IP use a dynamic DNS update client to keep their preferences associated with the right machine).
They're tracking by the cable modem's MAC address. There's a page explaining this (and how it's insecure) here:
http://rgov.org/road-runners-dns-wildcard
But even if you hide it from Caller ID, telephone numbers still get transmitted via ANI.
Could you give some examples?
I'm sure a properly written Java app can come close to a native OS X app, but I've never seen one that fit in perfectly. There's just always some little things that don't feel right, even if the widgets behave properly.
It's not a fault of Java, I just think its the reality of cross platform programming. It's just plain hard to write an app that behaves properly in every environment.
Camino can't support extensions because it doesn't use XUL for rendering its UI. If they used XUL, then they'd no longer feel like a native Mac app.
Take a look at all of the cross platform frameworks out there. Qt+, Java, etc. I have never seen an app written with any of those frameworks that feels native on OS X. Widgets are ever so slightly different and are sized differently. Sheets don't exist on other systems. Tabs often appear as tabs rather than as a row of buttons. Apple's human interface guidelines differ from what would be expected on Windows. The keychain doesn't exist on other platforms. I could go on.
Quite simply, there's no good way to write a cross platform app and make it feel native everywhere.
Oh, and for what it's worth, Camino supports plugins. It just doesn't support Firefox's plugins.
Sorry, I meant to say SCM, not RCS.
Yes, but how often does somebody want do development from a DVD? Especially with open source software, by the time you receive the disk your tree is out of date. Plus, there's no easy way to merge in new changes when they inevitably happen.
In principle, including the source on disk is a nice idea. In practice, just check it out from RCS.
Yes, the ultimate test of a web browser is whether the page renders and works correctly. However, the closer browsers are to meeting the W3C standards, the less likely it is that a page will work in one browser and not another.
Oh, and for the record, a lot of tests are not "complicated and pointless". Sure, there's some stuff you probably won't take advantage of, but theres a lot of stuff in there that would make web developers' lives easier should browsers ever consistently support it. I suggest you read the Acid2 Guided Tour.
For those of you who don't know, DShield is precisely one of the 'early-warning sensor' networks the article is talking about.
I ask the same thing every time I hear about people being charged extra in order to place a call to a mobile number in certain countries. At least with the system in the US you don't inconvenience others if you elect not to use a landline phone or give out the number to your cellphone.
On the other hand, people would be sure to think twice before calling their friends all the time, resulting in less phones going off in the theater, which is definitely a good thing.
I think this is going to become more of an issue as software projects choose to target different versions of Apache.
For instance, recently I was setting up a Subversion server for a project I was working on. It turns out that if you want to run Subversion over WebDAV/DeltaV, you are forced to use the Apache 2 series. As many have pointed out, if you try to use PHP in this environment httpd will randomly die off since PHP isn't thread-safe. When you are using Apache to write information, rather than read it, this is a very troubling issue.
Of course, this is easy enough to work around, you can either use one of the other access methods that Subversion supports, or install both versions of Apache simultaneously, placing them on different ports, or simply choose not to use PHP, however these are all workarounds, not solutions. Imagine what happens if other software takes this approach, say for example jboss, and you need to use both for different parts of your site. Suddenly, the "run both servers concurrently" approach doesn't look very attractive.
Actually, installing most Mac software does not need an admin password to be installed, since /Applications is writable by the admin group. You do need to be logged in using a user with admin privileges, but you won't need to type your password. Only if your program is either modifying system files or has a poorly written installer will it ask for an admin password so that it can execute sudo and gain root access. For this reason, anytime somebody gets a window asking for an admin password while installing something they should probably be a bit suspicious.
/Library/StartupItems is not writable by the admin group, so as long as somebody doesn't already have the password for root or an admin user (at which point you're already in trouble), I can't see this magically appearing on your system. Still, you're right, it would be trivial to build an installer bundle that would prompt for an admin password, and most users would probably put it in without a second thought.
That being said,
I think this is a good time to bring up Franklin's quote:
We're not just looking at people who have "broken the law." We're looking for people who, for one reason or another look "suspicious." Now, how do you tell who is a threat? Is it because of their job? What about their bank account? Maybe they attended some rally for a certain cause? Or maybe we look at their nationality?
I don't believe any of these can accurately determine who is more likely to be a "terrorist" then somebody else. That job is best performed by metal detectors, x-ray machines, and other measures which look for actual threats. Not by a database that says, in the eyes of the TSA, I just might happen to be a threat.
Sure, this system will give a green-light to most passengers, and some of those who are stopped may actually pose a threat. But in the end, I think this system will have the most impact on people who aren't really a threat, just happen to be a little more outspoken then everybody else. They are the people who are trying create change in the world, and they are the people a government tends to fear most of all.
Ummm, I don't know what you're talking about. Video on a mac is quite possibly one of the easiest things you can do. Let me break it down for you:
;)). True, you can't use a USB cable, but I don't know why you'd want to. USB 1.1 is far too slow to handle an NTSC video stream, and firewire has long been considered the standard for digital video transfer anyway.
1. Turn camera on
2. Connect camera to your computer using a firewire cable
3. Open video software (iMovie or Final Cut Pro/Express) and use the capture command.
Thats it, no software, no device drivers. I've done it many times using different software and cameras, and I've never had a problem. I've even used an analog capture box without any problems (except for the fact that the capture box was set to PAL when it arrived in the mail, but that's not the mac's fault
According to Wolfram's MathWorld site, Perelman's proof is described in two papers, located online here and subsequently, here.
Of course, I'm pretty sure the reason they're not mentioned in the article is because the most people reading the article would probably have some difficulty trying to understanding them. ;)
The difference between this and other programs is the quality of the files created. Other programs will allow you to capture analog audio output. While you can certainly save that output to a WAV or AIFF file without a loss of quality, file size will increase tremendously. On the other hand, if you decide to convert it back to aac, you'll lose qualilty when the song is recompressed. By capturing the raw AAC stream, this program allows you to output an exact copy of the original downloaded song without DRM, no size bloat and no loss of quality.
There are a few cases where this could be "legitimately" used. For example, if you bought your songs in the US, but later move to another country, as soon as you change your credit card address iTunes would supposedly disable access to your own songs. This program would prevent this. Unfortunately, it is far more likely that this will be used to enable outright piracy.
Actually, it would be next to impossible to burn, since GameCube discs actually spin backwards in the drive! When Nintendo designed the system, they did this explicitly to stop piracy. I think that the GC's disc format has probably been one of the major reasons why nobody has seen any attempts to port Linux to GameCube yet.