But these 'best performers' will not accept a contract that ties pay to performance!
You don't really want pay-for-performance contracts for executives, you only think you do. When your contract is heavily weighted towards performance metrics, you get avaricious CEOs who slash and burn company assets one day and initiate nonsensical mergers the next, all to make the next quarter's revenue look a bit better on Wall Street.
If you want to work at companies led by Carly Fiorina-type executives, then yes, by all means, pay them with nothing but stock options.
The FCC puts strict limits on the amount of energy from a handheld device that may be absorbed by the body. We call this Specific Absorbtion Rate, or SAR. In the olden days, when I walked ten miles to school in three feet of snow, uphill in both directions, cell phones had pull-up antennas. This allowed the designer to use a half-wave antenna variant, and put the point of maximum radiation somewhat away from the user's cranium. Of course, most people did not think it was necessary and kept the antenna stowed. Motorola's flip phone acutally had a second helical antenna that was switched into place when this was the case. But, more importantly, SAR rules were not yet in effect.
Flip phones became yesterday's style, and phones were becoming more monolithic. Some phones, like the early Treo, kept the antenna in the traditional location at the top of the phone, near one edge, but reduced it to a short stub. Whips became stubs, stubs became bumps, and finally antennas were embedded into the rectangular volume of the phone. The trouble was SAR; if you left the antenna at the top, the user was now pressing it into their head, insuring lots of tissue heating. Enter the bottom-located cellphone antenna.
Just about every cell phone in current production has the antenna located at the bottom. This insures that the radiating portion of the antenna is furthest from the head. Apple was not the first to locate the antenna on the bottom, and certainly won't be the last. The problem is that humans have their hands below their ears, so the most natural position for the hand is covering the antenna. This can't be a good design decision, can it? How can we be stuck with this conundrum? It's the FCC's fault. You see, when the FCC tests are run, the head is required to be in the vicinity of the phone. But, the hand is not!! And the FCC's tests are not the only tests that must be passed by a candidate product. AT&T has their own requirements for devices put on their network, and antenna efficiency is one of them. I know because I have designed quad-band GSM antennas for the AT&T network. The AT&T test similarly does not require the hand to be on the phone.
So, naturally, the design evolved to meet requirements - and efficient transmission and reception while being held by a human hand are simply not design requirements!
Want phones to continue to get smaller and lighter? This goofy bullshit is what ultimately determines the limit. Don't want phones to continue to get smaller and lighter? Then why are you even reading this thread?
And the "tinfoil-hat crowd" is not responsible for that. Using a "tinfoil-hat crowd" is a straw-man argument trying to divert attention away from bad design decisions.
Hello, reality calling. Nokia and RIM don't have Apple's problems, so what you're saying is that Apple has to meet regulations they do not have to meet. Can you back that up with facts? Or did you don your own tin-foil hat?
The "reality," as you like to put it, is that Nokia and RIM had the good judgment not to try what Apple did. Their phones are bigger and clunkier as a result. If Apple had succeeded, you can bet that the other manufacturers would be studying their patents for a partitioned external antenna, trying to figure out a way around them.
The other "reality," as you like to put it, is that users of all phones could get better coverage from fewer cell sites if the regulations permitted more flexibility in antenna design.
As Apple is learning, in consumer electronics you have to design for the worst case, and this particular worst case is much worse than it needs to be.
... and I'm sure that Nokia and the other manufacturers will agree, is to get the Oprah and Jenny Show out of the regulatory process. RF radiation does not cause brain cancer or anything else, and there is absolutely no reason to force consumer electronics manufacturers to design their antennas as if it does.
Where there is no demonstrable physical mechanism or repeatable empirical evidence for health effects, the burden of proof should rest firmly with the tinfoil-hat crowd. That's the only way we can move forward as a civilization, scientifically or otherwise. But instead, it's necessary for the wireless manufacturers to prove a negative. What Jobs should have said was, "Even though there is no physical mechanism or explanation for such a phenomenon, we have to assume our device will give you brain cancer if we don't use a really crappy antenna that's designed specifically to send most of the outgoing signal energy into the palm of your hand."
It's one of those elephants in the room that nobody seems to want to talk about. It would be great if a cellular carrier or handset manufacturer would take one for the team, and put the issue of faith-based RF exposure regulations on the table for discussion. We'd all get better phones as a result... and that's all we'd get.
Exactly. NASA is the Microsoft of government agencies. The engineers are capable of building great things, but any project worth doing is worth doing right, and any project worth doing right will probably take longer than the tenure of whatever politician or administrator sponsored it. When the new head honcho comes in, or the next election is held, the old administration's pet projects are put in a box and gassed.
This must be Bare Assertion Wednesday. I thought they were going to start holding those on the first and third Fridays of the month, but about half the replies I've received in this thread suggest otherwise.
Who exactly are the interests who will receive political benefits from setting dioxin-exposure limits low?
Trial lawyers. If dioxin is the new asbestos, there is a vast amount of money to be made from identifying any conceivable hazards, however unlikely they are to manifest themselves in practice, and playing them to the hilt.
Basic best practices (stretching back decades) is the first and foremost reason. Reducing the risk of trojans, virus infections and general data loss three more. Separation of binaries and configuration information a fourth.
Translation: "I can't think of a single reason why.INI files in the Program Files hierarchy are a bad thing, so I'll mumble some stuff about trojans, viruses, and data loss, and wrap up with a tautology."
Except, here in the US (which is where babies are ingesting 1200 times the safe level of dioxin) we don't live as long as many other developed countries.
You can't make this statement without comparing infant/early-childhood mortality rates, as well as the different policies governments use to determine what a "live birth" actually means. Average lifespan is one of those statistics that becomes fuzzier and fuzzier the more you look at it.
Are you aware that you have a 30% chance of getting cancer, mostly due to the level of dioxin and other carcinogens in your body? That this rate is expected to rise to 50% in the next two decades? I would consider this a reasonable description of "unsafe".
Yeeeeahhh, I think we're going to need to, um, see a citation on that one, mmmkay.
On the other hand, it could be a contributor to the fact that people living in industrial countries are much more likely to live long enough to get cancer.
No, it's the app vendor's fault for not writing their program properly in the first place.
It was fine 10 years ago when it was written.
That "one time" was in the early '90s, when Windows *3.1* was mainstream. By the time of Windows 98 you should have had fixed your software to do the right thing years earlier.
In this particular case the vendor was long since absorbed into a larger company, leaving the product unsupported. Again this wasn't a problem (for me, at least) until MS decided to give their B-team access to the Windows source tree.
The good reason was not having program directories writable by regular users. Would you store your.ini files in/usr/bin on a UNIX machine ?
What problem is solved by not having program directories writable by regular users? I keep asking that every time this subject comes up on Slashdot, and the answer always sounds a lot like dead silence. If I have a device connected to a serial port that is accessed directly by the program, there is absolutely no reason for the.ini file that specifies that COM port to live in a user-specific directory, or anywhere else besides the application's own install directory.
Windows is not Unix. Unix was designed from day one to be a multiuser operating system. Windows runs on personal computers, and 99.999% of use cases for Windows will always involve a single user.
Windows 95 was the most successful release in Microsoft's history because nothing was taken more seriously than the idea that existing applications, even 16-bit DOS apps from the Jurassic period, had to keep running. Vista failed (well, if you don't count encouraging millions of high-margin retail purchases of Windows 7 as 'failure') because the company abandoned that ideal at every level, from driver support to the filesystem.
(Shrug) Take it up with National Instruments, and every other vendor who's had to document this nutty scheme.
The way you describe it may be how it works now, post-Vista, but the fact is, different.exes could not share writable.ini files when Vista came out. Those applications simply would not work unless the user knew to mark all of the.exes to run with admin privileges. The virtualization scheme basically did not work as advertised, and it was a big part of why people hated Vista.
Of course, the INI files are under either ProgramData or Users where they belong - not under Program Files.
You can say they "belong" wherever, and maybe they do, but if an application that was built in the Win98 era that would otherwise have run perfectly on Vista/Win7 fails because of a misguided attempt to turn Windows into a strict multiuser OS, that's more the OS vendor's fault than the app developer's.
The problem happens when one executable, like a hardware configuration program, writes to an.INI file that other apps in the same directory are expected to be able to read. A virtualized copy of the.INI file is written under \Users\username\AppData\Local\VirtualStore\Program Files\[application name]\whatever.ini. The mistake Microsoft made was including [application name] in that path, because it means that an.INI file written by one.exe won't be accessible to another.exe in the same software package. This was an extremely common practice at one time, especially among developers (such as myself) who never drunk the Registry kool-aid.
Since.INI files are not executable and have thus been responsible for precisely zero OS exploits, it can be concluded that this was just a case of Microsoft fixing something that wasn't broken. This particular change sounds obscure and trivial, but it broke a large number of legacy apps for no good reason.
It really is a shame that Microsoft has such lethal corporate politics impacting their every decision...
Exactly. Microsoft is the NASA of technology companies. The engineers are capable of building great things, but any project worth doing is worth doing right, and any project worth doing right will probably take longer than the tenure of whatever politician or administrator sponsored it. When the new head honcho comes in, or the next election is held, the old administration's pet projects are put in a box and gassed.
Vista got a lot of flack from lazy development houses because they would not bother making their stuff UAC compatible
UAC wasn't the problem. Goofy, spurious changes with no security-related justifications, like breaking.INI files shared between different.exes in an application, were bigger compatibility concerns.
You can only live in one house, cruise around in one boat and drive one car at a time. At a certain point, bigger and bigger salaries for top CEO's stop increasing the real quality of life of an executive and instead just becomes a way of keeping track of how much better than the next CEO they are - ie. the marginal utility of every extra dollar a CEO earns approaches zero, but it is in our nature to always want more, so the salaries grow way beyond the point at which further increases are meaningless.
There are many pathways to financial success, but they all involve paying more attention to the contents of your own bank account and less attention to the contents of other peoples' bank accounts.
There were rumors that piracy was a big factor in the demise of LookingGlass Studios (Ultima Underworld, System Shock, Flight Unlimited... basically a lot of respected labor- and technology-intensive PC games that saw very widespread play but low sales.)
Slashdot Mirror
But these 'best performers' will not accept a contract that ties pay to performance!
You don't really want pay-for-performance contracts for executives, you only think you do. When your contract is heavily weighted towards performance metrics, you get avaricious CEOs who slash and burn company assets one day and initiate nonsensical mergers the next, all to make the next quarter's revenue look a bit better on Wall Street.
If you want to work at companies led by Carly Fiorina-type executives, then yes, by all means, pay them with nothing but stock options.
Do you, by chance, know what the difference between the terms sell-in and sell-through is?
From http://www.antennasys.com/antennasys-blog/2010/6/24/apple-iphone-4-antennas.html
Want phones to continue to get smaller and lighter? This goofy bullshit is what ultimately determines the limit. Don't want phones to continue to get smaller and lighter? Then why are you even reading this thread?
And the "tinfoil-hat crowd" is not responsible for that. Using a "tinfoil-hat crowd" is a straw-man argument trying to divert attention away from bad design decisions.
Take your Adderall, then read, then post.
Hello, reality calling. Nokia and RIM don't have Apple's problems, so what you're saying is that Apple has to meet regulations they do not have to meet. Can you back that up with facts? Or did you don your own tin-foil hat?
The "reality," as you like to put it, is that Nokia and RIM had the good judgment not to try what Apple did. Their phones are bigger and clunkier as a result. If Apple had succeeded, you can bet that the other manufacturers would be studying their patents for a partitioned external antenna, trying to figure out a way around them.
The other "reality," as you like to put it, is that users of all phones could get better coverage from fewer cell sites if the regulations permitted more flexibility in antenna design.
As Apple is learning, in consumer electronics you have to design for the worst case, and this particular worst case is much worse than it needs to be.
Hey, since you seem to have two laptops - how about giving your extra one to a Nigerian?
I think we've all seen what these people do when we give them access to computers.
Who cares how many sell in the weekend ? That's not a measure of anything besides marketing Hype
Um, no, that's a measure of how many units sold through in a given period of time.
Any company that disparages that metric is not long for the market.
People bought the iPhone because it was Apple and they wanted to have a stylish phone. They wanted to look marvelous.
Keep telling yourself that, Mr. Ballmer.
... and I'm sure that Nokia and the other manufacturers will agree, is to get the Oprah and Jenny Show out of the regulatory process. RF radiation does not cause brain cancer or anything else, and there is absolutely no reason to force consumer electronics manufacturers to design their antennas as if it does.
Where there is no demonstrable physical mechanism or repeatable empirical evidence for health effects, the burden of proof should rest firmly with the tinfoil-hat crowd. That's the only way we can move forward as a civilization, scientifically or otherwise. But instead, it's necessary for the wireless manufacturers to prove a negative. What Jobs should have said was, "Even though there is no physical mechanism or explanation for such a phenomenon, we have to assume our device will give you brain cancer if we don't use a really crappy antenna that's designed specifically to send most of the outgoing signal energy into the palm of your hand."
It's one of those elephants in the room that nobody seems to want to talk about. It would be great if a cellular carrier or handset manufacturer would take one for the team, and put the issue of faith-based RF exposure regulations on the table for discussion. We'd all get better phones as a result... and that's all we'd get.
19.8 dBm while "holding normally" is a lot of loss. One-tenth the field strength in volts/meter is making it to the phone's electronics at that point.
It's rare that I get 20 dB of link margin on an AT&T cell site around here.
Exactly. NASA is the Microsoft of government agencies. The engineers are capable of building great things, but any project worth doing is worth doing right, and any project worth doing right will probably take longer than the tenure of whatever politician or administrator sponsored it. When the new head honcho comes in, or the next election is held, the old administration's pet projects are put in a box and gassed.
This must be Bare Assertion Wednesday. I thought they were going to start holding those on the first and third Fridays of the month, but about half the replies I've received in this thread suggest otherwise.
Who exactly are the interests who will receive political benefits from setting dioxin-exposure limits low?
Trial lawyers. If dioxin is the new asbestos, there is a vast amount of money to be made from identifying any conceivable hazards, however unlikely they are to manifest themselves in practice, and playing them to the hilt.
Basic best practices (stretching back decades) is the first and foremost reason. Reducing the risk of trojans, virus infections and general data loss three more. Separation of binaries and configuration information a fourth.
Translation: "I can't think of a single reason why .INI files in the Program Files hierarchy are a bad thing, so I'll mumble some stuff about trojans, viruses, and data loss, and wrap up with a tautology."
Except, here in the US (which is where babies are ingesting 1200 times the safe level of dioxin) we don't live as long as many other developed countries.
You can't make this statement without comparing infant/early-childhood mortality rates, as well as the different policies governments use to determine what a "live birth" actually means. Average lifespan is one of those statistics that becomes fuzzier and fuzzier the more you look at it.
Are you aware that you have a 30% chance of getting cancer, mostly due to the level of dioxin and other carcinogens in your body? That this rate is expected to rise to 50% in the next two decades? I would consider this a reasonable description of "unsafe".
Yeeeeahhh, I think we're going to need to, um, see a citation on that one, mmmkay.
And not one from tinfoil.org.
On the other hand, it could be a contributor to the fact that people living in industrial countries are much more likely to live long enough to get cancer.
FTFY, no charge this time, drive through
... if the official dioxin-exposure limits are set unreasonably low, perhaps for political reasons unrelated to human or animal health.
No, it's the app vendor's fault for not writing their program properly in the first place.
It was fine 10 years ago when it was written.
That "one time" was in the early '90s, when Windows *3.1* was mainstream. By the time of Windows 98 you should have had fixed your software to do the right thing years earlier.
In this particular case the vendor was long since absorbed into a larger company, leaving the product unsupported. Again this wasn't a problem (for me, at least) until MS decided to give their B-team access to the Windows source tree.
The good reason was not having program directories writable by regular users. Would you store your .ini files in /usr/bin on a UNIX machine ?
What problem is solved by not having program directories writable by regular users? I keep asking that every time this subject comes up on Slashdot, and the answer always sounds a lot like dead silence. If I have a device connected to a serial port that is accessed directly by the program, there is absolutely no reason for the .ini file that specifies that COM port to live in a user-specific directory, or anywhere else besides the application's own install directory.
Windows is not Unix. Unix was designed from day one to be a multiuser operating system. Windows runs on personal computers, and 99.999% of use cases for Windows will always involve a single user.
Windows 95 was the most successful release in Microsoft's history because nothing was taken more seriously than the idea that existing applications, even 16-bit DOS apps from the Jurassic period, had to keep running. Vista failed (well, if you don't count encouraging millions of high-margin retail purchases of Windows 7 as 'failure') because the company abandoned that ideal at every level, from driver support to the filesystem.
(Shrug) Take it up with National Instruments, and every other vendor who's had to document this nutty scheme.
The way you describe it may be how it works now, post-Vista, but the fact is, different .exes could not share writable .ini files when Vista came out. Those applications simply would not work unless the user knew to mark all of the .exes to run with admin privileges. The virtualization scheme basically did not work as advertised, and it was a big part of why people hated Vista.
Of course, the INI files are under either ProgramData or Users where they belong - not under Program Files.
You can say they "belong" wherever, and maybe they do, but if an application that was built in the Win98 era that would otherwise have run perfectly on Vista/Win7 fails because of a misguided attempt to turn Windows into a strict multiuser OS, that's more the OS vendor's fault than the app developer's.
The problem happens when one executable, like a hardware configuration program, writes to an .INI file that other apps in the same directory are expected to be able to read. A virtualized copy of the .INI file is written under \Users\username\AppData\Local\VirtualStore\Program Files\[application name]\whatever.ini. The mistake Microsoft made was including [application name] in that path, because it means that an .INI file written by one .exe won't be accessible to another .exe in the same software package. This was an extremely common practice at one time, especially among developers (such as myself) who never drunk the Registry kool-aid.
Since .INI files are not executable and have thus been responsible for precisely zero OS exploits, it can be concluded that this was just a case of Microsoft fixing something that wasn't broken. This particular change sounds obscure and trivial, but it broke a large number of legacy apps for no good reason.
It really is a shame that Microsoft has such lethal corporate politics impacting their every decision...
Exactly. Microsoft is the NASA of technology companies. The engineers are capable of building great things, but any project worth doing is worth doing right, and any project worth doing right will probably take longer than the tenure of whatever politician or administrator sponsored it. When the new head honcho comes in, or the next election is held, the old administration's pet projects are put in a box and gassed.
Vista got a lot of flack from lazy development houses because they would not bother making their stuff UAC compatible
UAC wasn't the problem. Goofy, spurious changes with no security-related justifications, like breaking .INI files shared between different .exes in an application, were bigger compatibility concerns.
You can only live in one house, cruise around in one boat and drive one car at a time. At a certain point, bigger and bigger salaries for top CEO's stop increasing the real quality of life of an executive and instead just becomes a way of keeping track of how much better than the next CEO they are - ie. the marginal utility of every extra dollar a CEO earns approaches zero, but it is in our nature to always want more, so the salaries grow way beyond the point at which further increases are meaningless.
There are many pathways to financial success, but they all involve paying more attention to the contents of your own bank account and less attention to the contents of other peoples' bank accounts.
There were rumors that piracy was a big factor in the demise of LookingGlass Studios (Ultima Underworld, System Shock, Flight Unlimited... basically a lot of respected labor- and technology-intensive PC games that saw very widespread play but low sales.)