In most fields of engineering (electrical engineering is what I am most familiar with), there isn't a requirement for an engineer to be licensed. The PE organization would beg to differ in that regard, but in general you rarely see EEs, MechEs working in non-civil fields, etc licensed as PEs:
Within the field of civil engineering, nearly all states require any project to be signed off by a licensed civil engineer with a PE certification. In general, I believe most civil engineers need a PE certification or they simply can't function in the current regulatory environment. One should assume in this case that "engineering = civil engineering" when a civil engineer talks about engineering.
The claim here is that supposedly a non-licensed person practiced civil engineering in generating this work product. However: 1) It was not an official work product, it was a complaint to an organization that DOES contain licensed engineers 2) There were no claims made that anyone involved in the document preparation were civil engineers, licensed or otherwise
An idle cell phone causes far less interference to the towers than one in the middle of a call.
Also the baggage section of an aircraft is significantly better shielded (no windows for signals to leak out of) than the passenger section. Your phone probably just went into "no signal" and ate your battery.
The problem is that the capacity of the terrestrial cellular network is dependent on the ability to divide the network into small range-based cells - the assumption is that a handset talking to one cell will be far enough away from the next closest cell that uses the same frequencies/channels.
An airborne handset nullifies this basic assumption, it is seen by a large number of cells on the same frequency. There was supposedly a point where it would actually communicate with all the cells and if you made a call you'd be billed for the call once for every tower in range (If this were actually the case, I wish they hadn't fixed it, it would be a good deterrent from using cell phones while airborne except in the most dire of emergencies), now you communicate with one and interfere with many others, degrading their performance. Again - probably something OK in the most dire of emergencies, but most of the time, if you use a cell phone while airborne (exception: aircraft with microcells that cause phones to drop their transmit power) you're just being a douchebag and interfering with numerous cell sites on the ground.
No, it's perfectly kosher to have GPLed source code but non-GPLed game data.
See the various Quake GPL releases - it has NEVER been legal to use that GPL code to play the original game unless you legitimately owned the data.
It took quite a while before "standalone" games were created based on the Quake1/2/3 GPL release code, in these cases ALL of the game data was replaced with new (typically Creative Commons-licensed) data.
I don't think anyone would have an issue here if the Lugaru HD engine were being used with all-new artwork. The problem here is that the Lugaru HD artwork/data is being re-released by the pirates at a much lower price, and Apple is supporting this piracy by not responding to the emails from the owner of the original artwork/data.
TFA implies that their comm/tracking system used a cell phone. In the USA, FCC regulations prohibit use of cell phones while airborne in general. (There are exceptions for situations where measures have been taken to eliminate interference with terrestrial networks, such as a microcell within an aircraft cabin that causes the handsets to drop their transmitter power). However, it has never been legal in the USA for an airborne cell phone to communicate with the terrestrial cell network.
This hasn't stopped numerous USA-based HAB projects from looking at the FAA regs on balloons, saying "we're legal!", then using a cell phone for their comm system without bothering to check the FCC rules and licensing for cell phones. I think one of the few HAB projects I know of that did things legitimately was Project Blue Horizon - All of their comms are in the amateur (ham) bands and every year the project has at least 2-3 licensed hams.
Actually your information is the incorrect information. The fact that the system keys are unchangeable in hardware (hence the stories of the PS3 being irrevocably compromised) requires them to be the root for any firmware update. That DOES force Sony to keep using them.
Which means that any firmware update can be decrypted, unpacked, and analyzed to obtain any authentication secrets that might be hidden within the update. In fact that's probably how knowledge of this backdoor exists (again, can't access TFA at the moment), but I'm guessing it isn't from Wiresharking PS3s, but from reverse engineering the 3.56 update.
A key thing to consider here - Since the firmware updates have been broken "wide open", there are no authentication secrets for this backdoor that Sony is in possession of that other parties are not.
Basically - Sony has access to this backdoor but SO DOES EVERYONE ELSE.
(If it exists, since the evidence supposedly a convo from bash.org - can't read TFA from my current location.)
Well, many people have already addressed the flaws with your argument (such as the energy costs of manufacturing replacements for all this equipment), but more critically, you've failed to realize that this is at such an early stage of discovery that it's still highly likely to fizzle without going anywhere.
Just because you can make a few samples that perform well in a lab doesn't mean you can produce products with it in a consistent and energy-efficient manner. Just look at gallium arsenide - Two decades ago everyone was predicting GaAs to be the future of the semiconductor industry, two decades later it is only seen in a few niche RF devices (and those manufacturers are STILL having yield problems), much of it due to the simple fact that GaAs doesn't form a nice insulating layer when it oxidizes and other manufacturability issues.
That's a good idea. Tagged traffic makes QoS a lot easier, however, there has always been the risk of people "gaming" the system, such as tagging bulk traffic as high-priority.
However, people won't game the system if there are disincentives to doing so, possibilities: 1) More than a certain amount of "high priority" usage causes your "high priority" flags to get ignored and all your traffic for the rest of the month/week/whatever tagged as bulk. Note: Thresholds MUST be documented and auto-expire within a reasonable amount of time. (OptimumOffline's undocumented stealth-perma-capping-upstream policies are NOT acceptable.) 2) Tiered caps - X gigabytes of "high priority", 10X gigabytes of "normal priority", unlimited "low priority"
Unfortunately, after thinking further, I think that there is no way to regulate this in a way that isn't susceptible to someone gaming the system.
For example, treating all traffic of a given protocol identically means an ISP can screw a content provider that uses a custom protocol. (e.g. most online gaming).
Banning QoS altogether means "BT-hogs" screw the light web users and VoIPers.
I think the problem is that oversold backhauls is a fact of life - our broadband costs would be FAR higher if the ISP's backhaul weren't oversold.
Obviously, right now the level of overselling is too high, but even if overselling is reduced, QoS is highly beneficial if implemented properly
Thus ISP-level QoS really needs to be in place, HOWEVER: The user needs to be fully informed of all QoS methods and tuning parameters in place (not currently done) QoS methods shall NOT implement a specific throttle rate per protocol (e.g. a particular protocol is throttled to a given rate regardless of time of day or network utilization - Comcast Sandvining did this) QoS methods shall NOT explicitly force connections to close (Comcast Sandvining violated this rule) QoS methods shall NOT differentiate based on source or destination (This is, I believe, the fundamental rule for "network neutrality") QoS methods shall treat all traffic of a given protocol identically (Note: HTTP streaming vs. web browsing can be "differentiated" by having a QoS rule that gives burst traffic a higher priority than steady-state traffic.)
This could screw up, for example, packaging systems when the file gets deleted in a manner other than what the installer/packaging system expects.
And of course, there is the issue of rights - Privilege escalation is a dangerous thing, and I get the impression that at the moment, it's something the Mozilla team hasn't touched and probably doesn't want to touch. The annoyance of "Greyed-out" system addons is nowhere near as bad as the problems adding a privilege escalation mechanism could cause.
That's why I think there is an increasing trend to try and find alternate methods of monetization of the content.
Product placement seems to be a returning trend. Of course, it is harder for some genres than others. (Anything with a setting other than present-day Earth for example.)
Heroes clearly had product placement - many episodes were Nissan commercials in a way that managed to be blatantly obvious yet still nonintrusive.
I think content providers screwed up when the blocked Google TV. Google are the proven masters at advertising in such a way as to be effective WITHOUT pissing off the user. Advertisers need to learn that some techniques for attracting attention (animation in web ads, popups/popunders, raising volume in TV commercials) are antagonistic enough that people actively seek methods of blocking them. Meanwhile, other techniques (such as Google's text ads) are nonintrusive enough that they rarely trigger a "how do I block this shit?" thought.
You've got to be really careful with anything that requires user escalation... I'm not sure if there is a clean way to do this. However, this is the reason there are some "uninstallable" addons - They're addons that were installed system-wide.
Just deleting files from Firefox unfortunately screws up uninstaller apps.
I don't think there is a clean way to do what you want in a cross-platform manner.
I mean, fewer and fewer people watch TV live any more, except for actual live events.
Obviously, it is hard to collect metrics on DVR viewership (and it is still something they're trying to figure out), but really what matters is: 1) Are you in a conflict-heavy slot? Then you might lose if you exceed the typical number of tuners on people's DVRs (dual-tuner is getting pretty common...) 2) Are you in a slot that often gets its schedule broken? I disagree that Friday night is a "death slot" for this reason. Think "sci-fi Fridays" back before Sci-Fi became SyFy and started sucking. Sunday, however, is a "death slot" because half the time someone's DVR catches the previous show because football shifted the damn schedule back. (CSI: Miami went from "Record and watch at my convenience" to "Don't even bother recording" because of this. CSI: Miami recordings became a simple waste of hard drive space because 3/4 of them were of Undercover Boss instead.)
Save photos to a RAID-enabled NAS, and for offsite backups use some form of online storage.
I'm a SmugMug user and SmugMug provides EXCELLENT value - you can even store RAW images with SmugVault if you have a Premium account (If you don't shoot in RAW, Standard will be fine for you most likely.) If you don't shoot RAW, Flickr might be a good alternative.
As to, "And yes — before you ask — I do know that the first thing to do is to go through your collection and dump what is not worthwhile keeping."
NO. The definition of "worthwhile" can change. I do exposure/focus weeding initially (An initial run in digiKam on import for the most obvious, then a second weeding during RAW conversion in ufraw), but after that I never delete anything.
Yeah... This is a configuration management and interoperability nightmare.
I assume it's due to concerns that HTML revisions have come at intervals that are too long (Think Linux 2.4 to 2.6 - it took a LONG time and people considered it too long)- but dropping versioning completely is NOT the solution.
Changing the release schedule to involve smaller chunks per revision is more sensible. (See Linux development after the release of 2.6)
Some companies file lots of patents, many of which are VERY specific or just plain weak, in order to have "my stack is bigger than yours" bragging rights, and also for PR purposes. It seems to have succeeded in this case.
Someone I know used to work for a company that had a HUGE patent stack. Some were very strong and made the company quite a lot of money, but many were for PR/"my stack is bigger than yours" purposes. They had a patent rating system for applications, from 1 (business critical, put the best lawyers onto writing/cleaning up the application and file it in as many jurisdictions as possible) to 5 ("patently stupid", have it drafted by a wino of the street, but file it anyway for bragging rights and/or keep the eccentric Nobel Prize winner happy because he also pops out patents rated 1.)
Google, on the other hand, could be focusing more on quality. The title says "Are Google's patents too weak?" but then talks about numbers.
The strength of your patents has NOTHING to do with how many patents you hold. On strong, broad patent is far more valuable than 100 weak, easily avoidable, narrow patents.
I agree here. Early versions of WinCE were awful. Same with trying to actually shove Windows into a phone.
But later revisions of Windows Mobile, along with Windows Phone 7, have no real connection to Windows other than riding the marketing coattails of Windows.
I've been using Windows Mobile since WM5 (original AT&T Tilt) and it is actually a great operating system for power users. It was one of the better choices until Android matured (Android 2.x).
My next phone will be Android based, since Microsoft saw fit to utterly cripple WP7. It has a shiny UI but it is missing nearly all of the features, power, and flexibility that made me like WM5/6.
Slashdot Mirror
Ah, that makes sense. It's consistent with what I've read regarding "industrial exemption".
Well, I think the issue here is:
In most fields of engineering (electrical engineering is what I am most familiar with), there isn't a requirement for an engineer to be licensed. The PE organization would beg to differ in that regard, but in general you rarely see EEs, MechEs working in non-civil fields, etc licensed as PEs:
Within the field of civil engineering, nearly all states require any project to be signed off by a licensed civil engineer with a PE certification. In general, I believe most civil engineers need a PE certification or they simply can't function in the current regulatory environment. One should assume in this case that "engineering = civil engineering" when a civil engineer talks about engineering.
The claim here is that supposedly a non-licensed person practiced civil engineering in generating this work product. However:
1) It was not an official work product, it was a complaint to an organization that DOES contain licensed engineers
2) There were no claims made that anyone involved in the document preparation were civil engineers, licensed or otherwise
An idle cell phone causes far less interference to the towers than one in the middle of a call.
Also the baggage section of an aircraft is significantly better shielded (no windows for signals to leak out of) than the passenger section. Your phone probably just went into "no signal" and ate your battery.
The problem is that the capacity of the terrestrial cellular network is dependent on the ability to divide the network into small range-based cells - the assumption is that a handset talking to one cell will be far enough away from the next closest cell that uses the same frequencies/channels.
An airborne handset nullifies this basic assumption, it is seen by a large number of cells on the same frequency. There was supposedly a point where it would actually communicate with all the cells and if you made a call you'd be billed for the call once for every tower in range (If this were actually the case, I wish they hadn't fixed it, it would be a good deterrent from using cell phones while airborne except in the most dire of emergencies), now you communicate with one and interfere with many others, degrading their performance. Again - probably something OK in the most dire of emergencies, but most of the time, if you use a cell phone while airborne (exception: aircraft with microcells that cause phones to drop their transmit power) you're just being a douchebag and interfering with numerous cell sites on the ground.
No, it's perfectly kosher to have GPLed source code but non-GPLed game data.
See the various Quake GPL releases - it has NEVER been legal to use that GPL code to play the original game unless you legitimately owned the data.
It took quite a while before "standalone" games were created based on the Quake1/2/3 GPL release code, in these cases ALL of the game data was replaced with new (typically Creative Commons-licensed) data.
I don't think anyone would have an issue here if the Lugaru HD engine were being used with all-new artwork. The problem here is that the Lugaru HD artwork/data is being re-released by the pirates at a much lower price, and Apple is supporting this piracy by not responding to the emails from the owner of the original artwork/data.
TFA implies that their comm/tracking system used a cell phone. In the USA, FCC regulations prohibit use of cell phones while airborne in general. (There are exceptions for situations where measures have been taken to eliminate interference with terrestrial networks, such as a microcell within an aircraft cabin that causes the handsets to drop their transmitter power). However, it has never been legal in the USA for an airborne cell phone to communicate with the terrestrial cell network.
This hasn't stopped numerous USA-based HAB projects from looking at the FAA regs on balloons, saying "we're legal!", then using a cell phone for their comm system without bothering to check the FCC rules and licensing for cell phones. I think one of the few HAB projects I know of that did things legitimately was Project Blue Horizon - All of their comms are in the amateur (ham) bands and every year the project has at least 2-3 licensed hams.
Actually your information is the incorrect information. The fact that the system keys are unchangeable in hardware (hence the stories of the PS3 being irrevocably compromised) requires them to be the root for any firmware update. That DOES force Sony to keep using them.
Which means that any firmware update can be decrypted, unpacked, and analyzed to obtain any authentication secrets that might be hidden within the update. In fact that's probably how knowledge of this backdoor exists (again, can't access TFA at the moment), but I'm guessing it isn't from Wiresharking PS3s, but from reverse engineering the 3.56 update.
That brings up a good point - does this have better thermal management than its predecessors?
They had enough problems with overheating with a single gigabit port.
And some sort of I/O expansion header would have been nice. If it broke out a high speed SPI port I would've gone right for it.
A key thing to consider here - Since the firmware updates have been broken "wide open", there are no authentication secrets for this backdoor that Sony is in possession of that other parties are not.
Basically - Sony has access to this backdoor but SO DOES EVERYONE ELSE.
(If it exists, since the evidence supposedly a convo from bash.org - can't read TFA from my current location.)
Well, many people have already addressed the flaws with your argument (such as the energy costs of manufacturing replacements for all this equipment), but more critically, you've failed to realize that this is at such an early stage of discovery that it's still highly likely to fizzle without going anywhere.
Just because you can make a few samples that perform well in a lab doesn't mean you can produce products with it in a consistent and energy-efficient manner. Just look at gallium arsenide - Two decades ago everyone was predicting GaAs to be the future of the semiconductor industry, two decades later it is only seen in a few niche RF devices (and those manufacturers are STILL having yield problems), much of it due to the simple fact that GaAs doesn't form a nice insulating layer when it oxidizes and other manufacturability issues.
I see a LOT of version number gaps there.
Nearly all of 3.50 onward, with the exception of 3.55, have been primarily anti-piracy releases.
That's a good idea. Tagged traffic makes QoS a lot easier, however, there has always been the risk of people "gaming" the system, such as tagging bulk traffic as high-priority.
However, people won't game the system if there are disincentives to doing so, possibilities:
1) More than a certain amount of "high priority" usage causes your "high priority" flags to get ignored and all your traffic for the rest of the month/week/whatever tagged as bulk. Note: Thresholds MUST be documented and auto-expire within a reasonable amount of time. (OptimumOffline's undocumented stealth-perma-capping-upstream policies are NOT acceptable.)
2) Tiered caps - X gigabytes of "high priority", 10X gigabytes of "normal priority", unlimited "low priority"
Unfortunately, after thinking further, I think that there is no way to regulate this in a way that isn't susceptible to someone gaming the system.
For example, treating all traffic of a given protocol identically means an ISP can screw a content provider that uses a custom protocol. (e.g. most online gaming).
Banning QoS altogether means "BT-hogs" screw the light web users and VoIPers.
I think the problem is that oversold backhauls is a fact of life - our broadband costs would be FAR higher if the ISP's backhaul weren't oversold.
Obviously, right now the level of overselling is too high, but even if overselling is reduced, QoS is highly beneficial if implemented properly
Thus ISP-level QoS really needs to be in place, HOWEVER:
The user needs to be fully informed of all QoS methods and tuning parameters in place (not currently done)
QoS methods shall NOT implement a specific throttle rate per protocol (e.g. a particular protocol is throttled to a given rate regardless of time of day or network utilization - Comcast Sandvining did this)
QoS methods shall NOT explicitly force connections to close (Comcast Sandvining violated this rule)
QoS methods shall NOT differentiate based on source or destination (This is, I believe, the fundamental rule for "network neutrality")
QoS methods shall treat all traffic of a given protocol identically (Note: HTTP streaming vs. web browsing can be "differentiated" by having a QoS rule that gives burst traffic a higher priority than steady-state traffic.)
This could screw up, for example, packaging systems when the file gets deleted in a manner other than what the installer/packaging system expects.
And of course, there is the issue of rights - Privilege escalation is a dangerous thing, and I get the impression that at the moment, it's something the Mozilla team hasn't touched and probably doesn't want to touch. The annoyance of "Greyed-out" system addons is nowhere near as bad as the problems adding a privilege escalation mechanism could cause.
In the event that it is made law that a site must respect the "do not track" header, many sites may simply refuse to serve those who have it enabled.
That's why I think there is an increasing trend to try and find alternate methods of monetization of the content.
Product placement seems to be a returning trend. Of course, it is harder for some genres than others. (Anything with a setting other than present-day Earth for example.)
Heroes clearly had product placement - many episodes were Nissan commercials in a way that managed to be blatantly obvious yet still nonintrusive.
I think content providers screwed up when the blocked Google TV. Google are the proven masters at advertising in such a way as to be effective WITHOUT pissing off the user. Advertisers need to learn that some techniques for attracting attention (animation in web ads, popups/popunders, raising volume in TV commercials) are antagonistic enough that people actively seek methods of blocking them. Meanwhile, other techniques (such as Google's text ads) are nonintrusive enough that they rarely trigger a "how do I block this shit?" thought.
You've got to be really careful with anything that requires user escalation... I'm not sure if there is a clean way to do this. However, this is the reason there are some "uninstallable" addons - They're addons that were installed system-wide.
Just deleting files from Firefox unfortunately screws up uninstaller apps.
I don't think there is a clean way to do what you want in a cross-platform manner.
I mean, fewer and fewer people watch TV live any more, except for actual live events.
Obviously, it is hard to collect metrics on DVR viewership (and it is still something they're trying to figure out), but really what matters is:
1) Are you in a conflict-heavy slot? Then you might lose if you exceed the typical number of tuners on people's DVRs (dual-tuner is getting pretty common...)
2) Are you in a slot that often gets its schedule broken? I disagree that Friday night is a "death slot" for this reason. Think "sci-fi Fridays" back before Sci-Fi became SyFy and started sucking. Sunday, however, is a "death slot" because half the time someone's DVR catches the previous show because football shifted the damn schedule back. (CSI: Miami went from "Record and watch at my convenience" to "Don't even bother recording" because of this. CSI: Miami recordings became a simple waste of hard drive space because 3/4 of them were of Undercover Boss instead.)
Save photos to a RAID-enabled NAS, and for offsite backups use some form of online storage.
I'm a SmugMug user and SmugMug provides EXCELLENT value - you can even store RAW images with SmugVault if you have a Premium account (If you don't shoot in RAW, Standard will be fine for you most likely.) If you don't shoot RAW, Flickr might be a good alternative.
As to, "And yes — before you ask — I do know that the first thing to do is to go through your collection and dump what is not worthwhile keeping."
NO. The definition of "worthwhile" can change. I do exposure/focus weeding initially (An initial run in digiKam on import for the most obvious, then a second weeding during RAW conversion in ufraw), but after that I never delete anything.
Um, no.
Once you start doing, for example, HDR panoramas in a RAW format, it eats up space FAST.
Yeah... This is a configuration management and interoperability nightmare.
I assume it's due to concerns that HTML revisions have come at intervals that are too long (Think Linux 2.4 to 2.6 - it took a LONG time and people considered it too long)- but dropping versioning completely is NOT the solution.
Changing the release schedule to involve smaller chunks per revision is more sensible. (See Linux development after the release of 2.6)
Depends on how good/well funded their lawyers are.
If your target is weak, you can inundate them with a thousand papercuts.
If your target has their shit together, then you need to slam them with one big singular stick.
Quality vs. Quantitity.
Some companies file lots of patents, many of which are VERY specific or just plain weak, in order to have "my stack is bigger than yours" bragging rights, and also for PR purposes. It seems to have succeeded in this case.
Someone I know used to work for a company that had a HUGE patent stack. Some were very strong and made the company quite a lot of money, but many were for PR/"my stack is bigger than yours" purposes. They had a patent rating system for applications, from 1 (business critical, put the best lawyers onto writing/cleaning up the application and file it in as many jurisdictions as possible) to 5 ("patently stupid", have it drafted by a wino of the street, but file it anyway for bragging rights and/or keep the eccentric Nobel Prize winner happy because he also pops out patents rated 1.)
Google, on the other hand, could be focusing more on quality. The title says "Are Google's patents too weak?" but then talks about numbers.
The strength of your patents has NOTHING to do with how many patents you hold. On strong, broad patent is far more valuable than 100 weak, easily avoidable, narrow patents.
I agree here. Early versions of WinCE were awful. Same with trying to actually shove Windows into a phone.
But later revisions of Windows Mobile, along with Windows Phone 7, have no real connection to Windows other than riding the marketing coattails of Windows.
I've been using Windows Mobile since WM5 (original AT&T Tilt) and it is actually a great operating system for power users. It was one of the better choices until Android matured (Android 2.x).
My next phone will be Android based, since Microsoft saw fit to utterly cripple WP7. It has a shiny UI but it is missing nearly all of the features, power, and flexibility that made me like WM5/6.
2GB is now the standard (and I think LARGEST) plan you can get on AT&T.
1GB seems odd - think AT&T's were 250M and 2GB last I checked.