Possible, but Apple provides in-house app store configurations for the enterprise if they want to go that route and Apple takes non of that for a cut except for the developer program itself.
If the Windows UI was usable on the desktop, they might have a good idea since the 'app store' paradigm seems to be easily understood by consumers and business people alike. That said, if the UI sucks and you try to throw something on top of that, you are basically still stuck with the least common denominator (the UI sucks).
No matter what, I think MS in in for a bag full of hurt on this one.
I think the telling point there that is even with the various women on birth control, not ovulating, etc, that there were still 5% (or higher) that still managed to get pregnant after one unwanted sexual encounter.
For example, all things being equal, a computer connected to a hub via a stock ethernet cable with a guaranteed link speed up and down should produce a result that's generally in the same area each time (hence the 'real world').
It's not a difficult concept. We're not asking for a rating for every conceivable configuration, but best case real world numbers. WiFi theoreticals are nowhere near their real world numbers.
Yes, but knowing that overhead will always reduce the throughput by a specific amount, they could simply exclude that. Wireless is a good example of what you are saying as it would vary so much depending on location, interference, etc, but it should be based on the best possible 'real world' values, rather than a non-achievable theoretical limit.
I would be happy just to have speeds shown at 'real world' results, rather than 'theoretical' limits. What good are these ratings if people in the real world never actually see them?
I'm not sure how smaller companies do it, but I don't know of any decent sized enterprises that rely on a hosts file to restrict access to certain sites.
That said, this is some really stupid shit from the MS gene pool. Hosts should always take priority and simple visiting a site should never modify hosts as a result.
That said, I wonder if the old trick of setting 'System' to read only works?
These are idiot proof, but not maglock. They can connect with either side 'up'. Maglock is not really required for a device this small though since the connectors can actually hold the weight of the phone (at least on the old connector).
Agree. If it ever gets to the point where we are stripped of our protection from the Sun, then worrying about your code for a project is probably a little 'out of scope' in the scheme of things...
To prevent the possibility of adverse effects, products containing DEET should not be used on children younger than 2 months of age. For children over 2 months and for adults, the use of a product with a concentration no greater than 30% DEET is advised. Use the lowest concentration DEET product that will provide adequate protection. Reapply the repellent only after effectiveness diminishes with time.
Studies have also shown that anything above 50% provided no additional protection (but did provider longer protection). In other words, it was no more effective, but lasted longer.
For most, they won't even know they are exposed. This is a lot like SARS in that respect. It only severely effects about 1% of those infected. About 20% get mild symptoms, headaches, etc.
It does adversely affect those with compromised immune systems though (the elderly, immunocompromised, etc).
30% concentration of DEET is recommended for adults. Certainly NOT 90%. 10% DEET concentration for children.
The concentrations the poster above is suggesting would be toxic.
No, they teach the fundamentals of HTML, CSS and Javascript, not the entire language (or markup as the case may be). Unless someone has perfect recall, and a thorough understanding of coding structures, there is no way you could possibly teach them to code well in an hour.
You CAN teach someone basic coding fundamentals, some basic structures, and where the index is on their 'coding for dummies' book, but hoping for some to spit out a complex, complete program after an hour of teaching is not realistic in any sense of the word.
Temporarily deactivate the steering wheel? You're kidding right?
The obvious answer is voice recognition. It's already headed there with navigation systems since they are attention intensive without voice feedback. Simple commands like "set the temperature to 70" or "turn the fan to high", or "tune to station 97.1", etc.
Coming up with multi-function devices on top of current device screens just compounds the problem. They all take attention away (primarily your eyes) from the road. Steering wheel controls are a small step in the right direction, but adding more and more buttons requires someone to memorize them, and each successive button adds a higher chance that someone will mis-remember a button, look down to try and find it among the numerous controls already there, and again you are in the same bad situation.
Voice commands allow true independence from moving your feet or hands from the controls (assuming a successful implementation).
Considering both the cloud topic, and the device topic aren't discussing 'device to device communication', then your point isn't really relevant. Any data stored on RIM's servers is subject to subpoena just like any of these service providers.
The iPhone always supported a PIN lock, but the PIN wasn't a deterrent to a serious attacker until the iPhone 3GS. Because those early phones didn't use their hardware to perform encryption, a skilled investigator could hack into the phone, dump its flash memory, and directly access the phone's address book, e-mail messages, and other information. But now, with Apple's more sophisticated approach to encryption, investigators who want to examine data on a phone have to try every possible PIN. Examiners perform these so-called brute-force attacks with special software, because the iPhone can be programmed to wipe itself if the wrong PIN is provided more than 10 times in a row. This software must be run on the iPhone itself, limiting the guessing speed to 80 milliseconds per PIN. Trying all four-digit PINs therefore requires no more than 800 seconds, a little more than 13 minutes. However, if the user chooses a six-digit PIN, the maximum time required would be 22 hours; a nine-digit PIN would require 2.5 years, and a 10-digit pin would take 25 years. That's good enough for most corporate secrets—and probably good enough for most criminals as well.
FYI, this is the source of the summary quotes (adhoc as they are) and also addresses other questions regarding device security as opposed to iCloud security which has nothing to do with the linked articles.
"I can tell you from the Department of Justice perspective, if that drive is encrypted, you're done," Ovie Carroll, director of the cyber-crime lab at the Computer Crime and Intellectual Property Section in the Department of Justice, said during his keynote address at the DFRWS computer forensics conference in Washington, D.C., last Monday. "When conducting criminal investigations, if you pull the power on a drive that is whole-disk encrypted you have lost any chance of recovering that data."
At the heart of Apple's security architecture is the Advanced Encryption Standard algorithm (AES), a data-scrambling system published in 1998 and adopted as a U.S. government standard in 2001. After more than a decade of exhaustive analysis, AES is widely regarded as unbreakable. The algorithm is so strong that no computer imaginable for the foreseeable future—even a quantum computer—would be able to crack a truly random 256-bit AES key. The National Security Agency has approved AES-256 for storing top-secret data.
Apple did not respond to requests for comment on this story. But the AES key in each iPad or iPhone "is unique to each device and is not recorded by Apple or any of its suppliers," the company said in a security-related white paper. "Burning these keys into the silicon prevents them from being tampered with or bypassed, and guarantees that they can be access only by the AES engine."
It also notes the key here, that while the device is powered on, it is still possible to obtain the key from memory, but once the device is turned off, the key is lost. It also notes that the decryption key itself is encrypted by the device pin, meaning an easy pin is an easily decrypted device. This is true for any mobile device, and a good reason to enable a strong ping instead of the default 4 char code seen on most devices.
What I found curious about the article is that they didn't emphasize this point. Video's of police decrypting a device due to a weak 4 pin character lock within a matter of seconds are available for any number of devices. I am curious how much additional computing power is needed to decrypt a device for each character added to the unlock sequence.
I'm not sure how those things are relevant. The article talks about device security, not cloud security. Lest everyone forget, the same subpoena can get the same data from Google, Microsoft, RIM, etc.
If you decide to not use the cloud and the police get your device, it's currently more secure on Apple's phone. Must every article turn into a religious war?
If such was the case, the proper corse from google would have been to notify the user so they could visit the third party site, or inform them how to disable the setting. Hacking around it and as a result forcing all users to be tracked isn't a good answer.
The easy fix would to be a button the user could click to submit a real user initiated form to the site in question, hence no longer making it a 3rd Party Site:)
Because the Safari settings wasn't just 'asking' not to be tracked, but rather was supposed to prevent cookies from being placed by 3rd parties (essentially web sites you hadn't directly visited). What google did was to simulate a fake form submission to this third party site in order to set a cookie.
Not similar at all to the honor system 'do not track' setting.
I'm fortunate to have an environment where upper management understands and supports that sometimes deprecating a codebase is more desirable than supporting two code bases in parallel. It can take a LOT of pressure off of a development team to allow them to focus properly on the task at hand. All code eventually gets 'dirty' as it ages. A clean slate with an eye for the big picture (hindsight) can prove invaluable for supportability.
In my opinion, when you are spending more time trying to make code work within the existing framework than just adding enhancements, it's time to evaluate a major release.
A break-fix policy is simply stating you will support code to fix any breaks in functionality, while denying any enhancement requests. In short, the only changes you make to the old code would be to fix production issues.
It lets you focus efforts on implementing new code while avoiding supporting enhancements on the old code.
Yes and no. Part of the complexity of a new program is missing here. The full functionality is mapped out, albeit they will have to have to glean some functionality from the code and most from the end users. That's a huge boon as long as the end users can effectively comminicate or demonstrate that functionality.
In short, the map is already written and scope creep can be largely minimized with some proper expectations and management.
I disagree. For 200K lines of code, You immediately start a new project to produce the next major release of said code.
200,000 lines of code is a large project, but very do-able for even with a small team or one person. Although you could go in an attempt to tighten up code in smaller chunks, the very fact that this code was written over the course of many years, probably by many authors and styles, means it probably follows no standard to general layout, declarations, etc. (hence the spaghetti).
I would simply support what's there with only a break-fix policy, and immediately start documenting all aspects of it's functionality to rebuild it from the bottom up. The very fact that this code would have so many styles would mean most of it would have to be re-written and documented anyway.
Document the functionality, re-implement with standard code to guidelines, include any feature enhancements that may exist, release new version.
Slashdot Mirror
Possible, but Apple provides in-house app store configurations for the enterprise if they want to go that route and Apple takes non of that for a cut except for the developer program itself.
If the Windows UI was usable on the desktop, they might have a good idea since the 'app store' paradigm seems to be easily understood by consumers and business people alike. That said, if the UI sucks and you try to throw something on top of that, you are basically still stuck with the least common denominator (the UI sucks).
No matter what, I think MS in in for a bag full of hurt on this one.
I think the telling point there that is even with the various women on birth control, not ovulating, etc, that there were still 5% (or higher) that still managed to get pregnant after one unwanted sexual encounter.
I'm talking about protocol overhead.
For example, all things being equal, a computer connected to a hub via a stock ethernet cable with a guaranteed link speed up and down should produce a result that's generally in the same area each time (hence the 'real world').
It's not a difficult concept. We're not asking for a rating for every conceivable configuration, but best case real world numbers. WiFi theoreticals are nowhere near their real world numbers.
Yes, but knowing that overhead will always reduce the throughput by a specific amount, they could simply exclude that. Wireless is a good example of what you are saying as it would vary so much depending on location, interference, etc, but it should be based on the best possible 'real world' values, rather than a non-achievable theoretical limit.
I would be happy just to have speeds shown at 'real world' results, rather than 'theoretical' limits. What good are these ratings if people in the real world never actually see them?
I'm not sure how smaller companies do it, but I don't know of any decent sized enterprises that rely on a hosts file to restrict access to certain sites.
That said, this is some really stupid shit from the MS gene pool. Hosts should always take priority and simple visiting a site should never modify hosts as a result.
That said, I wonder if the old trick of setting 'System' to read only works?
These are idiot proof, but not maglock. They can connect with either side 'up'. Maglock is not really required for a device this small though since the connectors can actually hold the weight of the phone (at least on the old connector).
Agree. If it ever gets to the point where we are stripped of our protection from the Sun, then worrying about your code for a project is probably a little 'out of scope' in the scheme of things...
Look here:
http://www.atsdr.cdc.gov/consultations/deet/guidelines.html
Studies have also shown that anything above 50% provided no additional protection (but did provider longer protection). In other words, it was no more effective, but lasted longer.
http://www.cdc.gov/malaria/toolkit/DEET.pdf
And another.
http://www.nyc.gov/html/doh/html/wnv/wnvfaq4.shtml
You should probably let the CDC know that...
http://www.cdc.gov/ncidod/dvbid/westnile/qa/insect_repellent.htm
Unlikely ;)
For most, they won't even know they are exposed. This is a lot like SARS in that respect. It only severely effects about 1% of those infected. About 20% get mild symptoms, headaches, etc.
It does adversely affect those with compromised immune systems though (the elderly, immunocompromised, etc).
30% concentration of DEET is recommended for adults. Certainly NOT 90%.
10% DEET concentration for children.
The concentrations the poster above is suggesting would be toxic.
No, they teach the fundamentals of HTML, CSS and Javascript, not the entire language (or markup as the case may be). Unless someone has perfect recall, and a thorough understanding of coding structures, there is no way you could possibly teach them to code well in an hour.
You CAN teach someone basic coding fundamentals, some basic structures, and where the index is on their 'coding for dummies' book, but hoping for some to spit out a complex, complete program after an hour of teaching is not realistic in any sense of the word.
"Hello World" yes. Beyond that? Not so much...
Hence the last sentence of my post....
Temporarily deactivate the steering wheel? You're kidding right?
The obvious answer is voice recognition. It's already headed there with navigation systems since they are attention intensive without voice feedback. Simple commands like "set the temperature to 70" or "turn the fan to high", or "tune to station 97.1", etc.
Coming up with multi-function devices on top of current device screens just compounds the problem. They all take attention away (primarily your eyes) from the road. Steering wheel controls are a small step in the right direction, but adding more and more buttons requires someone to memorize them, and each successive button adds a higher chance that someone will mis-remember a button, look down to try and find it among the numerous controls already there, and again you are in the same bad situation.
Voice commands allow true independence from moving your feet or hands from the controls (assuming a successful implementation).
Considering both the cloud topic, and the device topic aren't discussing 'device to device communication', then your point isn't really relevant. Any data stored on RIM's servers is subject to subpoena just like any of these service providers.
Ah, the other link provides that info...
FYI, this is the source of the summary quotes (adhoc as they are) and also addresses other questions regarding device security as opposed to iCloud security which has nothing to do with the linked articles.
It also notes the key here, that while the device is powered on, it is still possible to obtain the key from memory, but once the device is turned off, the key is lost. It also notes that the decryption key itself is encrypted by the device pin, meaning an easy pin is an easily decrypted device. This is true for any mobile device, and a good reason to enable a strong ping instead of the default 4 char code seen on most devices.
What I found curious about the article is that they didn't emphasize this point. Video's of police decrypting a device due to a weak 4 pin character lock within a matter of seconds are available for any number of devices. I am curious how much additional computing power is needed to decrypt a device for each character added to the unlock sequence.
I'm not sure how those things are relevant. The article talks about device security, not cloud security. Lest everyone forget, the same subpoena can get the same data from Google, Microsoft, RIM, etc.
If you decide to not use the cloud and the police get your device, it's currently more secure on Apple's phone. Must every article turn into a religious war?
If such was the case, the proper corse from google would have been to notify the user so they could visit the third party site, or inform them how to disable the setting. Hacking around it and as a result forcing all users to be tracked isn't a good answer.
The easy fix would to be a button the user could click to submit a real user initiated form to the site in question, hence no longer making it a 3rd Party Site :)
Because the Safari settings wasn't just 'asking' not to be tracked, but rather was supposed to prevent cookies from being placed by 3rd parties (essentially web sites you hadn't directly visited). What google did was to simulate a fake form submission to this third party site in order to set a cookie.
Not similar at all to the honor system 'do not track' setting.
I'm fortunate to have an environment where upper management understands and supports that sometimes deprecating a codebase is more desirable than supporting two code bases in parallel. It can take a LOT of pressure off of a development team to allow them to focus properly on the task at hand. All code eventually gets 'dirty' as it ages. A clean slate with an eye for the big picture (hindsight) can prove invaluable for supportability.
In my opinion, when you are spending more time trying to make code work within the existing framework than just adding enhancements, it's time to evaluate a major release.
A break-fix policy is simply stating you will support code to fix any breaks in functionality, while denying any enhancement requests. In short, the only changes you make to the old code would be to fix production issues.
It lets you focus efforts on implementing new code while avoiding supporting enhancements on the old code.
Yes and no. Part of the complexity of a new program is missing here. The full functionality is mapped out, albeit they will have to have to glean some functionality from the code and most from the end users. That's a huge boon as long as the end users can effectively comminicate or demonstrate that functionality.
In short, the map is already written and scope creep can be largely minimized with some proper expectations and management.
I disagree. For 200K lines of code, You immediately start a new project to produce the next major release of said code.
200,000 lines of code is a large project, but very do-able for even with a small team or one person. Although you could go in an attempt to tighten up code in smaller chunks, the very fact that this code was written over the course of many years, probably by many authors and styles, means it probably follows no standard to general layout, declarations, etc. (hence the spaghetti).
I would simply support what's there with only a break-fix policy, and immediately start documenting all aspects of it's functionality to rebuild it from the bottom up. The very fact that this code would have so many styles would mean most of it would have to be re-written and documented anyway.
Document the functionality, re-implement with standard code to guidelines, include any feature enhancements that may exist, release new version.