So basically they suck. I shouldn't need to tweak my os thread scheduler just so a cpu can suck less. AMD needs to fix their shit instead of lame excuses.
I've got some very bad news for you: While I have no particular knowledge of, or interest in, today's architecture pissing match, the days when the OS was allowed to ignore architectural details and expect things to just work optimally are good and over(if they ever existed in the first place).
Dynamic processor clocks? Why should I have to deal with some performance governor shit when Intel can just make a CPU that either uses almost no power at 3GHz or runs like a bat out of hell at 800MHz? Oh, because they actually can't. Sorry. Multiple cores? WTF? Why do they expect me to program in parallel for 2 3GHz cores instead of just giving me a 6GHz core? Oh, because they actually can't. Sorry. NUMA? Memory access times already blow! Now you want to make them unpredictable? Well, we can either repeal the speed of light and restrict every system to a single memory controller or deal with nonuniform access times and cry into our 128GB of RAM... The list just goes on. Hyperthreading can provide anything from less than zero improvement, if it increases contention for resources that were already being fully used, to fairly substantial improvement, if the CPU was being starved at times under a single thread. Now the Bulldozer cores have implemented something between full multi-core(with 100% duplication of resources per core) and hyperthreading(with virtually zero additional resources for the HT 'core'). Shockingly, performance depends on whether the two semi-independent cores are stepping on one another's shared toes or not...
Even if, in this specific instance, AMD happens to have fucked up and made the wrong architectural choice, that doesn't change the fact that you can't escape architectural oddities unless you are willing to stay quite far from the forefront of performance, or deal with some sort of hardware/firmware abstraction layer that ends up being at least as complex as the OS-level hackery would have been, but more likely to be vendor specific and have its cost spread across far fewer units. It certainly isn't the case that all architectural deviations are good, some are ghastly hacks best forgotten, some are perfectly OK ideas dragged down by products that overall aren't much good; but the path of progress has been liberally sprinkled with oddities that have to be accounted for somewhere in the overall stack.
It does still have the potential to pretty substantially change the game, though:
Goofy hacks like custom SPD fields and PCI-ID checks are effective enough to spoil the day of Joe User; but most of the implementations in the wild are pitifully weak: SPD data, for instance, are stored on a totally normal little SMBUS eeprom chip. Cloning a vendor-lockout SPD field onto a generic chip of similar capability is not terribly demanding. The proposed cryptographic mechanisms, designed from the ground up for the purpose and given considerably more resources to work with, should be a great deal tougher.
Also, since the objective of this "secure boot" is to establish a 'trusted' chain of execution from power-on to porn browsing, properly rigorous applications will likely require verification by default, rather than having verification be a hacky special case for wifi or RAM. After all, most modern peripherals contain pretty substantial onboard processing power, some amount of onboard flash and firmware, and quite possibly DMA, kernel drivers, or other potentially threatening abilities to make a nuisance of themselves elsewhere in the system...
"UEFI" doesn't mean just one thing. It is a sprawling specification with a wide variety of possible capabilities(architecturally, it should really be thought of as an entire OS, plus OEM preload apps and drivers, lurking in your motherboard, it's at a pretty similar level of complexity and potential power).
To the best of my knowledge, none of the present UEFI boards implement the feature being discussed.
Admittedly, the lower arm contains a number of muscles, it isn't just deadweight, so operations involving manipulation of the hand relative to the elbow joint might well be more difficult in the prosthetic case if the prosthesis weighs more than it has to. Operations from the perspective of the shoulder, moving the whole arm, though, should be(approximately) similar, assuming the distribution of weight along the arm isn't too disrupted.
The C7 is a Symbian^3 device. If reviews are to be believed, that probably means that he would love WinMo 7. Or Android, or the sweet embrace of death, or just about anything, really.
Apparently the roughly approximate arm of a roughly approximate man would run in the 3.5-6.5 kg range.
If, in the spirit of wild-ass guessing and general laziness, we assume that your amputee-at-the-elbow loses half their arm mass and needs some, but not a whole lot, of headroom for purely structural replacement, you are still looking at 1.5-3ish kg of battery. A good Li-ion or Li-polymer will give you ~200Wh/kg, so 300-600Wh.
By comparison, the Nokia BL-5K battery in the C7 is a 3.7v, 1.2Ah unit: ~4.5Wh. An arm-battery would be somewhere between 65 and 130 times the capacity...
People who've had motorbike crashes and soldiers? Is that what comes to people's minds when they think amputees?
I can't speak for the public perception; but the stats differ pretty significantly depending on the type amputation you are talking about. Since this phone graft is an arm thing, and wouldn't be nearly as useful in a leg(especially just the lower bit), upper limb amputations are presumably more relevant. Those are majority trauma cases, especially once you remove the congenital cases, as he does for some reason.
Circulatory issues(including but not limited to diabetes related ones) more often hit lower limbs and trauma less often does. Cancer-related and congenital issues are more evenly distributed.
While I'd agree that the patent system is pretty fucked, as one of the relatively few members of the 'powers explicitly made available to the feds in the constitution' club it is on fairly firm ground in general principle...
The two actions are approximately similar(since a.app is a specially named directory, the equivalence might be slightly greater if you nuked the entire Internet Explorer directory):
Each will remove the user-visible browser, and probably result in some fun errors when other programs try to hand off a URL; but deleting Internet Explorer won't have any effect on MSHTML.dll, and deleting Safari won't remove the Webkit framework from OSX. With some further digging you could probably strip those out as well; but that isn't really relevant.
MSHTML and Webkit aren't considered "unremovable" because of some super DRM, they are considered functionally unremovable because they are expected features of their respective OSes and 3rd party applications routinely depend on them without any sort of graceful fallback...
While I have no great love for IE or Microsoft, this alleged "change" seems a bit overblown: In Windows 8, as in past versions, there is a switch that removes any mention of iexplore.exe from obvious view; but the rendering components aren't touched, and are still available for use by any other program that wishes to invoke them.
Also, given that they are going to be implementing these functions in something, more-or-less-vaguely-standardish HTML5 is about the least proprietary thing one could hope for:.NET is pretty sketchy on non-Windows platforms, and is more or less entirely an MS leads, Mono has to precisely duplicate, game. Win32, despite team WINE's significant efforts, is also an uphill battle. HTML is the only one that MS would conceivably touch(it isn't going to be in Java, after all...) that is actually multi-vendor to a reasonable degree.
I'm a bit surprised that Amazon made it past prior art. Although not applied to gifts(because those are, y'know, supposed to please the recipient) similar prepaid-purchase-widget-with-restrictions capabilities show up in some POS systems for paternalistic applications. This one, for instance, is designed to automate K-12 cafeteria systems, and allows parents to impose restrictions on the use of stored funds. And, of course, various welfare schemes have been using payment-instrument-with-limitations-on-use scrip of various flavors for pretty much as long as they have existed.
Amazon's idea seems novel only in that it is applied to people you ostensibly like, rather than children or paupers...
Why would you avoid sex offenders on Halloween? They always have the best candy!
On a more serious note, while "knowledge is power"; garbage in still means garbage out. "Level 1", "Level 2" and "Level 3" are practically designed to tell you fuck all of actual use. Is a "level 3" forcible rapist with no interest in children more dangerous than a "level 1" pedophile? Well, that sort of depends on who you are, doesn't it? Are sex offenders(those who actually target strangers, rather than the common-but-less-polite-to-discuss trusted adults known to the victim) actually dumb enough to do their re-offending on their own doorsteps, rather than at less obvious locations?
This application seems like a fantastic tool for people afflicted with nebulous anxiety who feel the need to refine that into focused, concrete fear; but it seems magnificently ill-suited to any actual public safety objective...
Not consciously; but wealth is suprisingly reliable at lowering fertility rates(shockingly, constant breeding is apparently not actually what people want) and poverty is less surprisingly reliable at raising mortality rates...
For roughly the reasons you give, the initial vaccination recommendation was aimed at female patients(younger preferred, since the vaccine is preventative, rather than curative, for the strains that it covers). My understanding is that it has never been contraindicated for male patients; but that an explicit recommendation was much later in coming; because the direct health effects of HPV infection in males are, on average, less serious.
The safety record, so far, has been quite good, so if the cost would come down a bit I'd expect it to become a routine childhood vaccination(outside of "I won't have my child injected with the sex devil virus!" regions, where there has been some downright ghoulish opposition to the idea that the wages of sin don't actually have to be cancer, with a little bit of applied science...)
Given that these sorts of features are increasingly implemented in pure software, or in hardware where every unit has all the features(because spinning a new mask is crazy expensive), but only some features are firmware-enabled, for price-discrimination or IP reasons, it will be interesting to see whether the "cheap DVD player" phenomenon crops up...
In the US, at least, back when DVD players were something people cared about, there arose a curious little wrinkle in the market: The pricier hardware, with the traditionally respectable brand badges(Sony, etc.) had nicer build quality, and was more likely to include features that were genuinely expensive in hardware(DACs that didn't suck, absurd numbers of outputs); but also enforced the various region locking, macrovision, and other user-hostile features of the DVD spec to the letter.
The cheap seats tended to have the usual downsides(somewhat... functional... build quality, dadaist user interfaces, a bit of scrimping and saving on BOM); but tended to enforce user-hostile requirements rather tepidly. There would either be some trivial 'debug code' that you could tap into the remote, or a 'test firmware' would 'leak' about 10 seconds after release that would remove all DRM features. The cheapies also tended to have the cheap-because-it's-software pirate-friendly features, like support for assorted audio and video codecs in files just burned to data DVDs and the like.
If the patent wars become too hot, a similar phenomenon could theoretically crop up in other electronics markets. The "US Firmware" version would be oh-so-bare-and-legally-compliant; but the hardware would be identical because SKU proliferation is expensive, and there would be a strong incentive for players, particularly the weaker players, to 'accidentally' suffer from a 'bootloader verification bug' that allows the least-crippled English-language firmware, *cough*easily available for download from our Hong Kong TLD's support page, 'only for our customers in the region'*cough* to be flashed to US devices...
Unless you are much more diligent with the little microfiber cloth than everybody else, or some kind of desiccated reptile-man, there is probably a grease trail on your screen containing a significant percentage of your unlock pattern for much of your phone's life...
It's certainly incrementally more secure than slide to unlock, since that is merely supposed to protect against spurious unlocks; but touchscreens bleed usage data if they aren't cleaned obsessively.
Ford was arguably more of a 'Compaq' figure than an OSS one. The latter arguably depends on the former(if computing were still split between IBM mainframes and 'cheap' $120,000 PDPs, software licenses would be basically irrelevant to almost everybody because they couldn't afford hardware; and if cars were still low-volume boutique items, we certainly wouldn't have millions of weekend mechanics tinkering in their garages); but Ford didn't really look to change the nature of the relationship between the producer and the consumer, he just walked into a cozy little market and blew the bottom out of the price and the top off the volume.
This does not diminish the magnitude of his achievement; but it was arguably a different genre of achievement.
Re:John Henry, please answer the white courtesy ph
on
The Real Job Threat
·
· Score: 1
Aside from people placing the date too early, out of excessive optimism about the capabilities of machines, what is "economically illiterate" about the notion?
Automation replaces, or increases the productivity of, human workers. This reduces the amount of labor, per unit product, required.
This makes goods cheaper which is good so long as you still enjoy access to a cut of the pie. However, there is nothing in "economic literacy" that requires us to assume that humans, especially the bulk of them, will continue to beat robots in the race for a wage-based slice of the economic output. And, if they don't, the fact that productivity is shooting through the roof won't help them very much unless they gain access to a slice by different means, which pretty much either means "rentier" or "charity case".
Slashdot Mirror
So basically they suck. I shouldn't need to tweak my os thread scheduler just so a cpu can suck less. AMD needs to fix their shit instead of lame excuses.
I've got some very bad news for you: While I have no particular knowledge of, or interest in, today's architecture pissing match, the days when the OS was allowed to ignore architectural details and expect things to just work optimally are good and over(if they ever existed in the first place).
Dynamic processor clocks? Why should I have to deal with some performance governor shit when Intel can just make a CPU that either uses almost no power at 3GHz or runs like a bat out of hell at 800MHz? Oh, because they actually can't. Sorry. Multiple cores? WTF? Why do they expect me to program in parallel for 2 3GHz cores instead of just giving me a 6GHz core? Oh, because they actually can't. Sorry. NUMA? Memory access times already blow! Now you want to make them unpredictable? Well, we can either repeal the speed of light and restrict every system to a single memory controller or deal with nonuniform access times and cry into our 128GB of RAM... The list just goes on. Hyperthreading can provide anything from less than zero improvement, if it increases contention for resources that were already being fully used, to fairly substantial improvement, if the CPU was being starved at times under a single thread. Now the Bulldozer cores have implemented something between full multi-core(with 100% duplication of resources per core) and hyperthreading(with virtually zero additional resources for the HT 'core'). Shockingly, performance depends on whether the two semi-independent cores are stepping on one another's shared toes or not...
Even if, in this specific instance, AMD happens to have fucked up and made the wrong architectural choice, that doesn't change the fact that you can't escape architectural oddities unless you are willing to stay quite far from the forefront of performance, or deal with some sort of hardware/firmware abstraction layer that ends up being at least as complex as the OS-level hackery would have been, but more likely to be vendor specific and have its cost spread across far fewer units. It certainly isn't the case that all architectural deviations are good, some are ghastly hacks best forgotten, some are perfectly OK ideas dragged down by products that overall aren't much good; but the path of progress has been liberally sprinkled with oddities that have to be accounted for somewhere in the overall stack.
It does still have the potential to pretty substantially change the game, though:
Goofy hacks like custom SPD fields and PCI-ID checks are effective enough to spoil the day of Joe User; but most of the implementations in the wild are pitifully weak: SPD data, for instance, are stored on a totally normal little SMBUS eeprom chip. Cloning a vendor-lockout SPD field onto a generic chip of similar capability is not terribly demanding. The proposed cryptographic mechanisms, designed from the ground up for the purpose and given considerably more resources to work with, should be a great deal tougher.
Also, since the objective of this "secure boot" is to establish a 'trusted' chain of execution from power-on to porn browsing, properly rigorous applications will likely require verification by default, rather than having verification be a hacky special case for wifi or RAM. After all, most modern peripherals contain pretty substantial onboard processing power, some amount of onboard flash and firmware, and quite possibly DMA, kernel drivers, or other potentially threatening abilities to make a nuisance of themselves elsewhere in the system...
"UEFI" doesn't mean just one thing. It is a sprawling specification with a wide variety of possible capabilities(architecturally, it should really be thought of as an entire OS, plus OEM preload apps and drivers, lurking in your motherboard, it's at a pretty similar level of complexity and potential power).
To the best of my knowledge, none of the present UEFI boards implement the feature being discussed.
Admittedly, the lower arm contains a number of muscles, it isn't just deadweight, so operations involving manipulation of the hand relative to the elbow joint might well be more difficult in the prosthetic case if the prosthesis weighs more than it has to. Operations from the perspective of the shoulder, moving the whole arm, though, should be(approximately) similar, assuming the distribution of weight along the arm isn't too disrupted.
Far too hazardous: the closed app store makes installing a trojan unacceptably difficult.
The C7 is a Symbian^3 device. If reviews are to be believed, that probably means that he would love WinMo 7. Or Android, or the sweet embrace of death, or just about anything, really.
Apparently the roughly approximate arm of a roughly approximate man would run in the 3.5-6.5 kg range.
If, in the spirit of wild-ass guessing and general laziness, we assume that your amputee-at-the-elbow loses half their arm mass and needs some, but not a whole lot, of headroom for purely structural replacement, you are still looking at 1.5-3ish kg of battery. A good Li-ion or Li-polymer will give you ~200Wh/kg, so 300-600Wh.
By comparison, the Nokia BL-5K battery in the C7 is a 3.7v, 1.2Ah unit: ~4.5Wh. An arm-battery would be somewhere between 65 and 130 times the capacity...
People who've had motorbike crashes and soldiers? Is that what comes to people's minds when they think amputees?
I can't speak for the public perception; but the stats differ pretty significantly depending on the type amputation you are talking about. Since this phone graft is an arm thing, and wouldn't be nearly as useful in a leg(especially just the lower bit), upper limb amputations are presumably more relevant. Those are majority trauma cases, especially once you remove the congenital cases, as he does for some reason.
Circulatory issues(including but not limited to diabetes related ones) more often hit lower limbs and trauma less often does. Cancer-related and congenital issues are more evenly distributed.
"Apparently, Apple refused to have an iPhone suitably customized for the job."
We all know Apple's position on people who hold it wrong...
While I'd agree that the patent system is pretty fucked, as one of the relatively few members of the 'powers explicitly made available to the feds in the constitution' club it is on fairly firm ground in general principle...
The two actions are approximately similar(since a .app is a specially named directory, the equivalence might be slightly greater if you nuked the entire Internet Explorer directory):
Each will remove the user-visible browser, and probably result in some fun errors when other programs try to hand off a URL; but deleting Internet Explorer won't have any effect on MSHTML.dll, and deleting Safari won't remove the Webkit framework from OSX. With some further digging you could probably strip those out as well; but that isn't really relevant.
MSHTML and Webkit aren't considered "unremovable" because of some super DRM, they are considered functionally unremovable because they are expected features of their respective OSes and 3rd party applications routinely depend on them without any sort of graceful fallback...
While I have no great love for IE or Microsoft, this alleged "change" seems a bit overblown: In Windows 8, as in past versions, there is a switch that removes any mention of iexplore.exe from obvious view; but the rendering components aren't touched, and are still available for use by any other program that wishes to invoke them.
.NET is pretty sketchy on non-Windows platforms, and is more or less entirely an MS leads, Mono has to precisely duplicate, game. Win32, despite team WINE's significant efforts, is also an uphill battle. HTML is the only one that MS would conceivably touch(it isn't going to be in Java, after all...) that is actually multi-vendor to a reasonable degree.
Also, given that they are going to be implementing these functions in something, more-or-less-vaguely-standardish HTML5 is about the least proprietary thing one could hope for:
I must say, rarely in the history of bullshit-acronymed bills do you see one so honestly named...
It's just the minor matter that the name refers to the bill's friends, and not to their enemies. A pity, that.
I'm a bit surprised that Amazon made it past prior art. Although not applied to gifts(because those are, y'know, supposed to please the recipient) similar prepaid-purchase-widget-with-restrictions capabilities show up in some POS systems for paternalistic applications. This one, for instance, is designed to automate K-12 cafeteria systems, and allows parents to impose restrictions on the use of stored funds. And, of course, various welfare schemes have been using payment-instrument-with-limitations-on-use scrip of various flavors for pretty much as long as they have existed.
Amazon's idea seems novel only in that it is applied to people you ostensibly like, rather than children or paupers...
At this point, would it be fair to describe the Playbook as the "RIM Foleo"?
Well, it does have a web browser, so Gmail should be good to go...
Why would you avoid sex offenders on Halloween? They always have the best candy!
On a more serious note, while "knowledge is power"; garbage in still means garbage out. "Level 1", "Level 2" and "Level 3" are practically designed to tell you fuck all of actual use. Is a "level 3" forcible rapist with no interest in children more dangerous than a "level 1" pedophile? Well, that sort of depends on who you are, doesn't it? Are sex offenders(those who actually target strangers, rather than the common-but-less-polite-to-discuss trusted adults known to the victim) actually dumb enough to do their re-offending on their own doorsteps, rather than at less obvious locations?
This application seems like a fantastic tool for people afflicted with nebulous anxiety who feel the need to refine that into focused, concrete fear; but it seems magnificently ill-suited to any actual public safety objective...
Are you keyword triggered or something?
In order to Support Our Troops, could we try to have a few more sinister foreign policy developments in places with nice, temperate climates?
Not consciously; but wealth is suprisingly reliable at lowering fertility rates(shockingly, constant breeding is apparently not actually what people want) and poverty is less surprisingly reliable at raising mortality rates...
For roughly the reasons you give, the initial vaccination recommendation was aimed at female patients(younger preferred, since the vaccine is preventative, rather than curative, for the strains that it covers). My understanding is that it has never been contraindicated for male patients; but that an explicit recommendation was much later in coming; because the direct health effects of HPV infection in males are, on average, less serious.
The safety record, so far, has been quite good, so if the cost would come down a bit I'd expect it to become a routine childhood vaccination(outside of "I won't have my child injected with the sex devil virus!" regions, where there has been some downright ghoulish opposition to the idea that the wages of sin don't actually have to be cancer, with a little bit of applied science...)
Given that these sorts of features are increasingly implemented in pure software, or in hardware where every unit has all the features(because spinning a new mask is crazy expensive), but only some features are firmware-enabled, for price-discrimination or IP reasons, it will be interesting to see whether the "cheap DVD player" phenomenon crops up...
In the US, at least, back when DVD players were something people cared about, there arose a curious little wrinkle in the market:
The pricier hardware, with the traditionally respectable brand badges(Sony, etc.) had nicer build quality, and was more likely to include features that were genuinely expensive in hardware(DACs that didn't suck, absurd numbers of outputs); but also enforced the various region locking, macrovision, and other user-hostile features of the DVD spec to the letter.
The cheap seats tended to have the usual downsides(somewhat... functional... build quality, dadaist user interfaces, a bit of scrimping and saving on BOM); but tended to enforce user-hostile requirements rather tepidly. There would either be some trivial 'debug code' that you could tap into the remote, or a 'test firmware' would 'leak' about 10 seconds after release that would remove all DRM features. The cheapies also tended to have the cheap-because-it's-software pirate-friendly features, like support for assorted audio and video codecs in files just burned to data DVDs and the like.
If the patent wars become too hot, a similar phenomenon could theoretically crop up in other electronics markets. The "US Firmware" version would be oh-so-bare-and-legally-compliant; but the hardware would be identical because SKU proliferation is expensive, and there would be a strong incentive for players, particularly the weaker players, to 'accidentally' suffer from a 'bootloader verification bug' that allows the least-crippled English-language firmware, *cough*easily available for download from our Hong Kong TLD's support page, 'only for our customers in the region'*cough* to be flashed to US devices...
Unless you are much more diligent with the little microfiber cloth than everybody else, or some kind of desiccated reptile-man, there is probably a grease trail on your screen containing a significant percentage of your unlock pattern for much of your phone's life...
It's certainly incrementally more secure than slide to unlock, since that is merely supposed to protect against spurious unlocks; but touchscreens bleed usage data if they aren't cleaned obsessively.
Ford was arguably more of a 'Compaq' figure than an OSS one. The latter arguably depends on the former(if computing were still split between IBM mainframes and 'cheap' $120,000 PDPs, software licenses would be basically irrelevant to almost everybody because they couldn't afford hardware; and if cars were still low-volume boutique items, we certainly wouldn't have millions of weekend mechanics tinkering in their garages); but Ford didn't really look to change the nature of the relationship between the producer and the consumer, he just walked into a cozy little market and blew the bottom out of the price and the top off the volume.
This does not diminish the magnitude of his achievement; but it was arguably a different genre of achievement.
Aside from people placing the date too early, out of excessive optimism about the capabilities of machines, what is "economically illiterate" about the notion?
Automation replaces, or increases the productivity of, human workers. This reduces the amount of labor, per unit product, required.
This makes goods cheaper which is good so long as you still enjoy access to a cut of the pie. However, there is nothing in "economic literacy" that requires us to assume that humans, especially the bulk of them, will continue to beat robots in the race for a wage-based slice of the economic output. And, if they don't, the fact that productivity is shooting through the roof won't help them very much unless they gain access to a slice by different means, which pretty much either means "rentier" or "charity case".