Um, if a light bulb only turns 2% of its power into light, that means it turns 98% of its power into heat. Granted, that heat might not be in the ideal physical location (too near the ceiling, whatever) for it to be as useful, but any electric heater is going to produce no more than 100 watts of heat for 100 watts of input power. Put in a ceiling fan to redistribute the heat from your lightbulbs, it will be every bit as "efficient" as any other form of electric heat.
That said, direct electric heating is not the most efficient way to convert the energy input at the power station into heat in your home.
The problem isn't when it turns on, it's when it turns off. With an inductive load, the current and voltage are out of phase. The SCR/Triac in the dimmer circuit turns off when the current goes to zero. At that point, the voltage is NOT zero, which causes an inductor to create a large backlash voltage. This can exceed the SCR/triac breakdown delta, causing it to turn back on (which defeats the purpose of the dimmer circuit), but can also damage other components involved.
When you suddenly supply voltage to an inductor, the inductor INSTANTLY opposes that voltage, preventing a large current from flowing. It's slow changes that make an inductor look like a dead short, not fast changes. "inductive resistance" isn't a very good term for it, a better term is reactance. In any case, most CFLs aren't using large inductors, or they wouldn't be "compact". They don't like chopped power for other reasons.
They never recorded the n-hardware. They recorded b/g hardware being ordered, paid for (in full), and installed. Because they didn't reserve any of that price in their accounting documents, on paper, it looks like they wrote up their $1999 computer at $1999 (components plus gross margin). There was $0.00 remaining the way they filed it.
Oh, so YOU'VE seen their filings? Amazing, how'd you do it? What chipset did they claim they installed that couldn't do 11n? What line on what form said "b/g only"?
So what law or CFR requires these filings you're talking about, full bill of materials for every single device manufactured, complete technical specifications that can't be changed unless the customer pays more, but, somehow, software is different, that you don't have to account for development costs, and thus can give upgrades away for free? I mean, software IS different, manufacturing costs are as close to zero as you can get if you distribute on-line, but even with hardware you still have to account for development costs, just like software, even if there aren't individual components that need to be tracked, paid for, and charged for with software.
I would say that a company that doesn't know how much it cost to develop a specific feature in a product, whether it's a software-only or hardware feature, is not doing their accounting very well. How do they know that feature was worth developing? They SHOULD be accounting for how much it cost to "improve save dialog to allow for mobile devices".
You can't give something away that you didn't report buying in the first place
You didn't buy it, you created it. You paid for it by paying the salary of the developers that created it. Whether you release it to earlier customers, to whom you had NO obligation, makes NO accounting difference. If the product wasn't feature-complete when you sold it, charging $4.99 to make it feature complete sounds to me like consumer fraud. If you did sell it with a promise to upgrade it in the future, then absolutely, you should put a liability on the books to account for that future obligation (but charging $4.99 after the fact doesn't somehow excuse it).
So let's say you sell a computer, with a 1-year warranty, for $2000; your best estimate is that you'll spend on average about $200 over the next year for each computer you sold to create and distribute software patches, do warranty repairs, do telephone support, etc. So, you set aside $200, and each quarter you retire $50 of that liability, recognizing it as income (against whatever it cost to actually provide the support). What do you do at the end of the year when it turns out that it actually cost $400 per computer sold to support them? As long as there was no fraud involved (the $200/year estimate can be reasonably justified), would there be any penalties? Or just a restatement of income for the earlier part of the year? How much of that information would you be sending to the government, and how much would only be going to your accountants and auditors?
But they didn't sell it as "upgradeable to 11n". If they did, then charging $4.99 to make it be so would be the part that would be illegal, I'd think.
I agree that the firmware is a component. So what? It costs nothing to distribute (well, no more than any of the other things that Apple gives away for free all the time), and the development time they spent is a sunk cost, they had to do that anyway to sell new devices that they WILL advertise as being 11n capable.
you can't turn one into the other without serious hardware modification, you have what the law considers two different products
Of COURSE you can, that's what is happening. You're turning one thing into the other, by replacing the firmware. Firmware that costs $0.00 to manufacture.
No, there's no difference between "software" and "a software component". With a web browser, my hardware can do certain things that it can't without the web browser. Apple sells the computer partially based on some of those things, yet that doesn't prevent them from releasing a free upgrade to Safari that allows it do do new things that it couldn't do before.
If the wireless chipset that was being used was a totally generic software-defined radio chipset, whether it is b/g or n or a or something that hasn't yet been defined is completely up to the firmware being used. Upgrading it with new capabilities is no different from giving a web browser a new capability.
What law "prohibits free upgrades"?
f you end up with a machine that has 802.11n functionality, the law says you paid for that functionality at some time or other.
What law says that? I bought a machine that had 802.11n capability, but no software, and write my own firmware to implement the 11n functions. When did I pay for that? (never mind that the FCC would have problems with it, that's a different issue entirely). Sure, if Apple promised an upgrade, they'd be required to incur a liability on the books to account for their costs in doing the upgrade (and at that point, some of the development time WOULD be assignable to that). But they didn't promise an upgrade.
As an Apple stockholder, how was I misled in any way as to the value of the company by Apple stating or not stating that their laptops were upgradeable to 11n if they incurred no liability to do that upgrade?
WHAT documents do they file with "the government" that say "this computer can only do 802.11b/g", and what specific part of what law says that it's illegal to have not disclosed that it can be upgraded to 11n, but only if you later give away some free software? Where do I see these documents? Where does some law say that "it isn't possible to add 802.11n capability with software only", but if you charge $4.99 for some software and say it is a hardware upgrade, that's ok? What "generally accepted accounting principle" says that? And where do you get the idea that software doesn't need to be accounted for, only hardware? And why can't you give away a "hardware upgrade" for $0.00 if it doesn't actually cost you anything?
A requirement that revenue received be offset by liabilities incurred as to future deliverables is certainly reasonable. I don't see how it can possibly apply to a product where there is no future liability because a future capability was never promised, particularly if delivering that future capability to a future product allows you to upgrade the old product at no cost.
But I didn't buy iTunes, I bought a computer. It had iTunes on it. Then iTunes got upgraded, giving my computer HARDWARE new capabilities. The driver/firmware is JUST SOFTWARE, there is no new hardware that they are sending you.
If they "materially misstated" something, claiming that a software update changes the hardware capabilities isn't going to fix it. And how is it non-interoperable? It still works with 11b/g equipment. Being able to talk a new radio protocol is no different than being able to talk a new video protocol, new network protocol, new encryption method, new web browser capability. It's JUST SOFTWARE, that runs on HARDWARE. If they didn't send me new hardware, how can it be a hardware upgrade? Your claim that "none of your.11g devices can be software-upgraded to.11n if they don't already have the hardware capability" is a tautology.
Hardware that includes firmware or software to run it ALWAYS has more capabilities than can possibly be disclosed. You're trying to claim that somehow there's something special about 802.11n, and that NOT saying their hardware COULD possibly do it is somehow misrepresenting something. It would be quite possible for someone to have hardware that COULD do a/b/g/n and a bunch of standards that haven't even been defined yet. If the only reason they're using it is to do b/g, how is it misrepresenting anything to not say that it COULD do other standards with the right firmware? How is that ANY different than loading new software onto your computer to make it do things it never did before?
So what happens if I load new firmware, not from Apple, that "upgrades" my hardware? Whoa, Apple didn't sell me an upgrade and yet my hardware has an "apparent upgrade"? Am I now guilty of stealing from Apple?
I also don't understand why you keep saying that you "have to charge money in order to file new paperwork". Why? If it doesn't cost you anything, why can't you put down "0.00"? Let's say that the current FCC regulations for such a device included a power limitation of radiated power (as, in fact, they do). Let's say that your hardware is capable of exceeding those limits (as, in fact, most do). Let's say the FCC changes the limits and after some testing of your hardware with new firmware, approves you releasing the new firmware to existing customers, increasing power output. Why the HELL would an accountant, the government (other than the FCC) or anyone else care? How is that ANY different from enabling a new encryption protocol (e.g. the various WPA protocols that have been added since WEP), or enabling some hardware that you weren't using?
Another example: let's say standard power supplies include a timer circuit for timed turn-on. I'm just using it as a standard power supply, and I don't include any way to access the timer in the software, nor do I advertise that it will do that. A year later, someone comes up with the bright idea to include an automatic start-up/shut-down option (such as Macs actually do have). What demented logic would say that it would be illegal for them to allow people to upload that piece of SOFTWARE that sets the timer, on the strange basis that they didn't disclose at some point that the power supply had that feature in it?
So why don't they have to charge me when they upgrade iTunes to, say, support videos? There's no REAL reason why 802.11n chips need different hardware; one way to implement it (which would not be cost effective, but never mind that) would be to have very general software-defined radio hardware with the appropriate software to run it. How is that any different from releasing a new version of wireless authentication/encryption? It's wireless hardware, it currently does b/g. What it MIGHT do if you MIGHT offer new firmware is irrelevant, unless you promised the customer that you'd upgrade it when, say, the final standard comes out (in which case you do have a liability, to the tune of whatever it will cost to distribute that upgrade, and a portion of the expected development costs, and at that point you need to put that liability on the books to offset the revenue). But Apple didn't do that, they never said it would do 802.11n, so they have no liability. They still have to develop the capability for their future products, but given that there is virtually no cost to upgrade the older product, there's no reason they'd have to charge for it.
So how does charging $4.99 change it so it officially DOES have 802.11n hardware? Doesn't that really just prove that it had 802.11n hardware all along? Apple didn't advertise that it was 802.11n capable. I don't see why Apple can't charge what it actually costs them to provide the update (not including the development costs, as that doesn't increase simply because you distribute more copies; now, if they incurred additional development costs to support an older version of the chipset that isn't compatible with a newer one, I can see distributing that cost over the number of expected upgrades). Apple distributes lots of things for free, and accounts for what that costs them as "advertising", "customer goodwill", etc. There's no reason a nominal charge for such an upgrade couldn't be absorbed the same way, especially if it costs WAY more to charge for it than it costs to provide it for free.
What accounting form are they filing with the government that says "the chipset we're using in this specific laptop is 802.11b/g capable", where not mentioning that with the proper firmware it can also do 802.11n would be considered misrepresentation?
802.11n should maintain speed over a larger distance than 802.11g. It should also have less interference problems with other access points, and should be less susceptible to interference from 2.4GHz cordless phones and microwave ovens (and Bluetooth and...). I'm switching soon after the standard is really released and manufacturers start advertising actual certification rather than "draft" status.
Wow, there's a law that says 802.11g isn't the same as 802.11n?
As I see it, they never CHARGED for 802.11n functionality, so how could they be receiving revenue on that before they deliver it? The change in functionality of the wireless chipset by enabling 802.11n is NO different from the change in functionality of the entire computer anytime you add software to it, which renders the entire argument ridiculous. If they want to be accurate, they should defer some of the income to the future to account for support costs (DIRECT support costs, e.g. the actual cost of the bandwidth for downloading patches) through the supported life of the system, just as they presumably do for things like warranty support. The only way there should be a specific charge for something like this is if they are required to pay licensing fees for each copy they distribute; even there, I don't see any reason they can't eat the cost and chalk it up to customer retention.
Apple allows you to download all sorts of new functionality all the time. I fail to see how this is an "accounting issue".
What I meant was that if the RIAA finally realizes that they gave Apple the perfect excuse to use DRM to help keep their iTMS/iPod lock-in, which makes Apple powerful enough to stand up to them, and they start authorizing other companies to release music DRM-free, you'll still be able to use the DRM-free music on an iPod, so Apple won't really care that much. If the RIAA does that, but doesn't authorize Apple to do the same (distribute DRM-free music), the RIAA may have some anti-trust issues to deal with. If they do allow Apple to do that, and other distributors are doing well with DRM-free music, Apple will follow suit. They'll still maintain the "experience" of iTMS, seamless integration with the iPod, so I don't think it will hurt their business model much.
Of course you can. Where did I say you couldn't talk about things? I asked what the problem was, not that you couldn't talk about the problem! I don't see that there's a problem; I don't buy anything from the iTMS, I rip CDs using iTunes. I don't see a DRM problem. So I ask you, what's the problem? If there's really this "big movement" towards non-DRM music, supported by the RIAA studios, then it isn't a problem, just buy from the alternate sources instead of iTMS. It will still work with an iPod.
I agree that Apple uses the DRM the RIAA forced on them to support their business model. It was VERY clever of them, "Don't throw me in that briar patch, Brer Fox!" However, if the RIAA allows them to drop it, I'm pretty sure they'd drop it in an instant, after all what Apple wants is lots of music out there to put on iPods, so people will keep buying iPods. They aren't that concerned that it all has to be bought from Apple (as Apple doesn't really make that much money from actually selling the music, the studios keep most of it). Sure, Apple's happy to sell music that can ONLY be used in iTunes or an iPod, but if no one is going to buy it that way, they'll change.
Um, ok, but what does that have to do with what you're responding to? You can do the same thing with iTunes. What you're responding to was about "music bought/rented from a site using Windows Media", not about ripping from CDs.
So buy from those other sources and ignore Apple's iTMS. It will work with iTunes and the iPod just fine, if it is just plain old MP3 files. What's the problem? If there's this huge movement, then obviously people will stop buying music from Apple, right?
Yup. I made my own version of this circuit in 1974-75, using a standard one-shot flip-flop (I don't remember if I used a 555 or what), and an 8-bit counter that stopped and latched and reset when the timer circuit triggered. It used an 8080 to read the latched value, which then set two different counter chips to turn on/off a video signal; yes, I was trying to do a mostly-software version of Pong, using straight TTL logic to produce a pseudo-NTSC monochrome video signal. It wasn't fast enough to put two different vertical lines on the same scan lines, much less put the "ball" on the screen, but it was a fun project nevertheless. My first blown-up power supply capacitor, figuring out just how far off-spec a TV set would accept sync signals, learning to use an oscilloscope, etc.
I agree pretty much with the post you're responding to. When I say "testing", I mean that I test all the boundary conditions of each individual subroutine in the library I'm writing to make sure it works with all specified conditions, detects all errors it is supposed to detect, and that any limitations are well documented. In some cases where error checking is too expensive to do in production, I also include a debugging facility, either dynamic or compile-time, to do more extensive input checking. This can also be used in checking code that calls the routine, to verify that it is passing things correctly. Once I have the core routines finished and tested, I then rely heavily on them.
I find that a lot of programming that is done in C++ really should have been done in straight C. It isn't really using any "object oriented" techniques, it's just doing straight linear programming, wrapped in a more complex description, usually doing lots of things the programmer doesn't understand, often much more inefficiently than they expect. With C, you really only have to worry about a few things, and if you're manic about being paranoid about those things, you really won't have a problem: a) opening a file, it might fail, always check it; b) allocating or re-allocating memory, it might fail, always check it; c) stale pointers, zero the thing if there's any doubt that it might be used again, if there can be multiple persistent pointers to a block of memory, have the discipline to keep track of those pointers so you don't free the memory prematurely; d) buffer overflows, whether on the stack or the heap; bounds check if there's ANY doubt whatsoever, document what the bounds are and where the limits come from, etc.
More complex programming, e.g. multi-threading, requires similar discipline - always check that when you create a thread, it succeeded (I had a program where the OS would balk at creating too many new threads too quickly, I had to add in a yield() and re-try a few times before returning an error); creating a mutex or condition variable and initializing it, always check the error results; setting thread priority, always check the error results.
More complex is how to handle "impossible" errors; exceptions in C++ is one of the best reasons to go beyond straight C for this issue. Usually, the best choice is to log the error and kill the entire process, and have a higher layer to restart the program if it is critical. I've found that most such issues occur during initialization, where the best choice IS to have it be a fatal error, but designing the response to various potential errors (socket closed unexpectedly, failed to open a file, invalid input) is important to do early on so you can have a unified approach to such errors and ensure you don't have resource leaks when things don't terminate as expected. C++ and Java allow some of this to be done easier than in C, but it still isn't that hard to do even in straight C, but only if you think about it ahead of time!
Apple really should release updated timezone files as an update for all versions, there's no reason not to. Failing that, it would be very easy for someone to provide an unofficial update to fix it, either by copying the files from 10.4 or just compiling them from the updated sources.
I'm surprised that Java doesn't just use the C library routines for that functionality on platforms where it is available, but I see that you're right, 1.4.2 does not do it correctly, 1.5 does (on OS X 10.4.8).
This also applies to all Mac OS X machines as well, of course. Apple will supply a new set of timezone files in a patch (if they haven't already), and there's absolutely no reason it won't be available for every version of OS X (since they should be the exact same files, the format hasn't changed). Doesn't Windows use a similar method? I thought pretty much everything had switched over to zic-based timezone files (which also takes care of all those pesky leap-seconds that everyone seemed to be so worried about). They're pretty darned complete, and reading the source files for them is very entertaining and informative.
Seems to me it is just as likely that the game being played is the real problem. Every PS3 I've seen (all both of them) have always been frozen, on the same game. Perhaps it is a demo version of the game that has a memory leak problem or something similar so that after several hours of play it locks up. Maybe it does do a reset after a certain amount of time, but the reset isn't quite clean enough so that after enough of them, it freezes. None of that says anything about the reliability of the unit itself, nor of the quality of the release version of the game. Of course, that's only one possible explanation.
Christmas Eve at our local Best Buy, they had about 6 units available. As I stood there, one of them sold, another had someone asking about it. The demo unit was frozen.
Sam's Club has a 42" (Akai, I think) 1080p LCD HDTV for a bit less than $1400.
I hardly ever use a Windows machine. Doesn't mean I can't learn how, if that's what the job calls for. Five of your questions are very Windows-specific, and you're probably looking for a Windows-specific answer to the one about "safe mode". Yet, even not using Windows much, I can guess at most of the answer to most of those questions, which means they aren't very useful (and give me 5 minutes in front of a Windows machine, and 10 minutes to read the documentation on installing Windows XP, and I'll answer them all).
Then again, I probably wouldn't be looking for an entry-level job, certainly not in a Windows environment.
If it's that important to save some memory by using 32-bit pointers (and you don't need a 64-bit process address space), then it seems to me it should be pretty easy to compile to code that only uses 32-bit pointers, even with 64-bit code. It shouldn't be hard to mark a process as only having a 32-bit address space so the kernel memory allocation calls don't allocate anything outside of that range (as they'd have to do with 32-bit code anyway). Doesn't GCC support having 64-bit code with 32-bit pointers?
I've been using 64-bit processors for over 10 years, but the Wintel monopoly keeps burying them, damn it, and damn you Compaq and Hewlett-Packard! And Digital. And Apple. Before that I was using 60-bit processors with an 18-bit address space (and one's complement arithmetic, if you needed a further hint).
Why eat plants? They've converted solar energy to sugars and starches and such. Why not just absorb the solar energy directly? You in fact answered your own question: "to store it when solar energy is not available" (or, more to the point, because you can't tote around a solar energy collector large enough on your car to run it, and even then it would only run in the daytime, as long as you don't drive into shadows or tunnels or under trees or it's raining or...)
Any form of storage of energy so you can use it in an automobile or a laptop or whatever is going to be less than 100% efficient. Direct solar cracking of water should be more efficient than converting solar to electricity to electrolyze water.
We better get rid of all the algae in the oceans, then, they produce this poisonous gas called oxygen in great quantities, by taking sunlight and breaking up water molecules! Damn those cyanobacteria in the first place. Really screwed up the atmosphere for those sulphur-based lifeforms.
Slashdot Mirror
That's why I said "direct electric heating"...
Um, if a light bulb only turns 2% of its power into light, that means it turns 98% of its power into heat. Granted, that heat might not be in the ideal physical location (too near the ceiling, whatever) for it to be as useful, but any electric heater is going to produce no more than 100 watts of heat for 100 watts of input power. Put in a ceiling fan to redistribute the heat from your lightbulbs, it will be every bit as "efficient" as any other form of electric heat.
That said, direct electric heating is not the most efficient way to convert the energy input at the power station into heat in your home.
The problem isn't when it turns on, it's when it turns off. With an inductive load, the current and voltage are out of phase. The SCR/Triac in the dimmer circuit turns off when the current goes to zero. At that point, the voltage is NOT zero, which causes an inductor to create a large backlash voltage. This can exceed the SCR/triac breakdown delta, causing it to turn back on (which defeats the purpose of the dimmer circuit), but can also damage other components involved.
When you suddenly supply voltage to an inductor, the inductor INSTANTLY opposes that voltage, preventing a large current from flowing. It's slow changes that make an inductor look like a dead short, not fast changes. "inductive resistance" isn't a very good term for it, a better term is reactance. In any case, most CFLs aren't using large inductors, or they wouldn't be "compact". They don't like chopped power for other reasons.
Oh, so YOU'VE seen their filings? Amazing, how'd you do it? What chipset did they claim they installed that couldn't do 11n? What line on what form said "b/g only"?
So what law or CFR requires these filings you're talking about, full bill of materials for every single device manufactured, complete technical specifications that can't be changed unless the customer pays more, but, somehow, software is different, that you don't have to account for development costs, and thus can give upgrades away for free? I mean, software IS different, manufacturing costs are as close to zero as you can get if you distribute on-line, but even with hardware you still have to account for development costs, just like software, even if there aren't individual components that need to be tracked, paid for, and charged for with software.
I would say that a company that doesn't know how much it cost to develop a specific feature in a product, whether it's a software-only or hardware feature, is not doing their accounting very well. How do they know that feature was worth developing? They SHOULD be accounting for how much it cost to "improve save dialog to allow for mobile devices".
You didn't buy it, you created it. You paid for it by paying the salary of the developers that created it. Whether you release it to earlier customers, to whom you had NO obligation, makes NO accounting difference. If the product wasn't feature-complete when you sold it, charging $4.99 to make it feature complete sounds to me like consumer fraud. If you did sell it with a promise to upgrade it in the future, then absolutely, you should put a liability on the books to account for that future obligation (but charging $4.99 after the fact doesn't somehow excuse it).
So let's say you sell a computer, with a 1-year warranty, for $2000; your best estimate is that you'll spend on average about $200 over the next year for each computer you sold to create and distribute software patches, do warranty repairs, do telephone support, etc. So, you set aside $200, and each quarter you retire $50 of that liability, recognizing it as income (against whatever it cost to actually provide the support). What do you do at the end of the year when it turns out that it actually cost $400 per computer sold to support them? As long as there was no fraud involved (the $200/year estimate can be reasonably justified), would there be any penalties? Or just a restatement of income for the earlier part of the year? How much of that information would you be sending to the government, and how much would only be going to your accountants and auditors?
But they didn't sell it as "upgradeable to 11n". If they did, then charging $4.99 to make it be so would be the part that would be illegal, I'd think.
I agree that the firmware is a component. So what? It costs nothing to distribute (well, no more than any of the other things that Apple gives away for free all the time), and the development time they spent is a sunk cost, they had to do that anyway to sell new devices that they WILL advertise as being 11n capable.
Of COURSE you can, that's what is happening. You're turning one thing into the other, by replacing the firmware. Firmware that costs $0.00 to manufacture.
No, there's no difference between "software" and "a software component". With a web browser, my hardware can do certain things that it can't without the web browser. Apple sells the computer partially based on some of those things, yet that doesn't prevent them from releasing a free upgrade to Safari that allows it do do new things that it couldn't do before.
If the wireless chipset that was being used was a totally generic software-defined radio chipset, whether it is b/g or n or a or something that hasn't yet been defined is completely up to the firmware being used. Upgrading it with new capabilities is no different from giving a web browser a new capability.
What law "prohibits free upgrades"?
What law says that? I bought a machine that had 802.11n capability, but no software, and write my own firmware to implement the 11n functions. When did I pay for that? (never mind that the FCC would have problems with it, that's a different issue entirely). Sure, if Apple promised an upgrade, they'd be required to incur a liability on the books to account for their costs in doing the upgrade (and at that point, some of the development time WOULD be assignable to that). But they didn't promise an upgrade.
As an Apple stockholder, how was I misled in any way as to the value of the company by Apple stating or not stating that their laptops were upgradeable to 11n if they incurred no liability to do that upgrade?
WHAT documents do they file with "the government" that say "this computer can only do 802.11b/g", and what specific part of what law says that it's illegal to have not disclosed that it can be upgraded to 11n, but only if you later give away some free software? Where do I see these documents? Where does some law say that "it isn't possible to add 802.11n capability with software only", but if you charge $4.99 for some software and say it is a hardware upgrade, that's ok? What "generally accepted accounting principle" says that? And where do you get the idea that software doesn't need to be accounted for, only hardware? And why can't you give away a "hardware upgrade" for $0.00 if it doesn't actually cost you anything?
A requirement that revenue received be offset by liabilities incurred as to future deliverables is certainly reasonable. I don't see how it can possibly apply to a product where there is no future liability because a future capability was never promised, particularly if delivering that future capability to a future product allows you to upgrade the old product at no cost.
But I didn't buy iTunes, I bought a computer. It had iTunes on it. Then iTunes got upgraded, giving my computer HARDWARE new capabilities. The driver/firmware is JUST SOFTWARE, there is no new hardware that they are sending you.
If they "materially misstated" something, claiming that a software update changes the hardware capabilities isn't going to fix it. And how is it non-interoperable? It still works with 11b/g equipment. Being able to talk a new radio protocol is no different than being able to talk a new video protocol, new network protocol, new encryption method, new web browser capability. It's JUST SOFTWARE, that runs on HARDWARE. If they didn't send me new hardware, how can it be a hardware upgrade? Your claim that "none of your .11g devices can be software-upgraded to .11n if they don't already have the hardware capability" is a tautology.
Hardware that includes firmware or software to run it ALWAYS has more capabilities than can possibly be disclosed. You're trying to claim that somehow there's something special about 802.11n, and that NOT saying their hardware COULD possibly do it is somehow misrepresenting something. It would be quite possible for someone to have hardware that COULD do a/b/g/n and a bunch of standards that haven't even been defined yet. If the only reason they're using it is to do b/g, how is it misrepresenting anything to not say that it COULD do other standards with the right firmware? How is that ANY different than loading new software onto your computer to make it do things it never did before?
So what happens if I load new firmware, not from Apple, that "upgrades" my hardware? Whoa, Apple didn't sell me an upgrade and yet my hardware has an "apparent upgrade"? Am I now guilty of stealing from Apple?
I also don't understand why you keep saying that you "have to charge money in order to file new paperwork". Why? If it doesn't cost you anything, why can't you put down "0.00"? Let's say that the current FCC regulations for such a device included a power limitation of radiated power (as, in fact, they do). Let's say that your hardware is capable of exceeding those limits (as, in fact, most do). Let's say the FCC changes the limits and after some testing of your hardware with new firmware, approves you releasing the new firmware to existing customers, increasing power output. Why the HELL would an accountant, the government (other than the FCC) or anyone else care? How is that ANY different from enabling a new encryption protocol (e.g. the various WPA protocols that have been added since WEP), or enabling some hardware that you weren't using?
Another example: let's say standard power supplies include a timer circuit for timed turn-on. I'm just using it as a standard power supply, and I don't include any way to access the timer in the software, nor do I advertise that it will do that. A year later, someone comes up with the bright idea to include an automatic start-up/shut-down option (such as Macs actually do have). What demented logic would say that it would be illegal for them to allow people to upload that piece of SOFTWARE that sets the timer, on the strange basis that they didn't disclose at some point that the power supply had that feature in it?
So why don't they have to charge me when they upgrade iTunes to, say, support videos? There's no REAL reason why 802.11n chips need different hardware; one way to implement it (which would not be cost effective, but never mind that) would be to have very general software-defined radio hardware with the appropriate software to run it. How is that any different from releasing a new version of wireless authentication/encryption? It's wireless hardware, it currently does b/g. What it MIGHT do if you MIGHT offer new firmware is irrelevant, unless you promised the customer that you'd upgrade it when, say, the final standard comes out (in which case you do have a liability, to the tune of whatever it will cost to distribute that upgrade, and a portion of the expected development costs, and at that point you need to put that liability on the books to offset the revenue). But Apple didn't do that, they never said it would do 802.11n, so they have no liability. They still have to develop the capability for their future products, but given that there is virtually no cost to upgrade the older product, there's no reason they'd have to charge for it.
So how does charging $4.99 change it so it officially DOES have 802.11n hardware? Doesn't that really just prove that it had 802.11n hardware all along? Apple didn't advertise that it was 802.11n capable. I don't see why Apple can't charge what it actually costs them to provide the update (not including the development costs, as that doesn't increase simply because you distribute more copies; now, if they incurred additional development costs to support an older version of the chipset that isn't compatible with a newer one, I can see distributing that cost over the number of expected upgrades). Apple distributes lots of things for free, and accounts for what that costs them as "advertising", "customer goodwill", etc. There's no reason a nominal charge for such an upgrade couldn't be absorbed the same way, especially if it costs WAY more to charge for it than it costs to provide it for free.
What accounting form are they filing with the government that says "the chipset we're using in this specific laptop is 802.11b/g capable", where not mentioning that with the proper firmware it can also do 802.11n would be considered misrepresentation?
802.11n should maintain speed over a larger distance than 802.11g. It should also have less interference problems with other access points, and should be less susceptible to interference from 2.4GHz cordless phones and microwave ovens (and Bluetooth and ...). I'm switching soon after the standard is really released and manufacturers start advertising actual certification rather than "draft" status.
Wow, there's a law that says 802.11g isn't the same as 802.11n?
As I see it, they never CHARGED for 802.11n functionality, so how could they be receiving revenue on that before they deliver it? The change in functionality of the wireless chipset by enabling 802.11n is NO different from the change in functionality of the entire computer anytime you add software to it, which renders the entire argument ridiculous. If they want to be accurate, they should defer some of the income to the future to account for support costs (DIRECT support costs, e.g. the actual cost of the bandwidth for downloading patches) through the supported life of the system, just as they presumably do for things like warranty support. The only way there should be a specific charge for something like this is if they are required to pay licensing fees for each copy they distribute; even there, I don't see any reason they can't eat the cost and chalk it up to customer retention.
Apple allows you to download all sorts of new functionality all the time. I fail to see how this is an "accounting issue".
What I meant was that if the RIAA finally realizes that they gave Apple the perfect excuse to use DRM to help keep their iTMS/iPod lock-in, which makes Apple powerful enough to stand up to them, and they start authorizing other companies to release music DRM-free, you'll still be able to use the DRM-free music on an iPod, so Apple won't really care that much. If the RIAA does that, but doesn't authorize Apple to do the same (distribute DRM-free music), the RIAA may have some anti-trust issues to deal with. If they do allow Apple to do that, and other distributors are doing well with DRM-free music, Apple will follow suit. They'll still maintain the "experience" of iTMS, seamless integration with the iPod, so I don't think it will hurt their business model much.
Of course you can. Where did I say you couldn't talk about things? I asked what the problem was, not that you couldn't talk about the problem! I don't see that there's a problem; I don't buy anything from the iTMS, I rip CDs using iTunes. I don't see a DRM problem. So I ask you, what's the problem? If there's really this "big movement" towards non-DRM music, supported by the RIAA studios, then it isn't a problem, just buy from the alternate sources instead of iTMS. It will still work with an iPod.
I agree that Apple uses the DRM the RIAA forced on them to support their business model. It was VERY clever of them, "Don't throw me in that briar patch, Brer Fox!" However, if the RIAA allows them to drop it, I'm pretty sure they'd drop it in an instant, after all what Apple wants is lots of music out there to put on iPods, so people will keep buying iPods. They aren't that concerned that it all has to be bought from Apple (as Apple doesn't really make that much money from actually selling the music, the studios keep most of it). Sure, Apple's happy to sell music that can ONLY be used in iTunes or an iPod, but if no one is going to buy it that way, they'll change.
Um, ok, but what does that have to do with what you're responding to? You can do the same thing with iTunes. What you're responding to was about "music bought/rented from a site using Windows Media", not about ripping from CDs.
So buy from those other sources and ignore Apple's iTMS. It will work with iTunes and the iPod just fine, if it is just plain old MP3 files. What's the problem? If there's this huge movement, then obviously people will stop buying music from Apple, right?
Yup. I made my own version of this circuit in 1974-75, using a standard one-shot flip-flop (I don't remember if I used a 555 or what), and an 8-bit counter that stopped and latched and reset when the timer circuit triggered. It used an 8080 to read the latched value, which then set two different counter chips to turn on/off a video signal; yes, I was trying to do a mostly-software version of Pong, using straight TTL logic to produce a pseudo-NTSC monochrome video signal. It wasn't fast enough to put two different vertical lines on the same scan lines, much less put the "ball" on the screen, but it was a fun project nevertheless. My first blown-up power supply capacitor, figuring out just how far off-spec a TV set would accept sync signals, learning to use an oscilloscope, etc.
I agree pretty much with the post you're responding to. When I say "testing", I mean that I test all the boundary conditions of each individual subroutine in the library I'm writing to make sure it works with all specified conditions, detects all errors it is supposed to detect, and that any limitations are well documented. In some cases where error checking is too expensive to do in production, I also include a debugging facility, either dynamic or compile-time, to do more extensive input checking. This can also be used in checking code that calls the routine, to verify that it is passing things correctly. Once I have the core routines finished and tested, I then rely heavily on them.
I find that a lot of programming that is done in C++ really should have been done in straight C. It isn't really using any "object oriented" techniques, it's just doing straight linear programming, wrapped in a more complex description, usually doing lots of things the programmer doesn't understand, often much more inefficiently than they expect. With C, you really only have to worry about a few things, and if you're manic about being paranoid about those things, you really won't have a problem: a) opening a file, it might fail, always check it; b) allocating or re-allocating memory, it might fail, always check it; c) stale pointers, zero the thing if there's any doubt that it might be used again, if there can be multiple persistent pointers to a block of memory, have the discipline to keep track of those pointers so you don't free the memory prematurely; d) buffer overflows, whether on the stack or the heap; bounds check if there's ANY doubt whatsoever, document what the bounds are and where the limits come from, etc.
More complex programming, e.g. multi-threading, requires similar discipline - always check that when you create a thread, it succeeded (I had a program where the OS would balk at creating too many new threads too quickly, I had to add in a yield() and re-try a few times before returning an error); creating a mutex or condition variable and initializing it, always check the error results; setting thread priority, always check the error results.
More complex is how to handle "impossible" errors; exceptions in C++ is one of the best reasons to go beyond straight C for this issue. Usually, the best choice is to log the error and kill the entire process, and have a higher layer to restart the program if it is critical. I've found that most such issues occur during initialization, where the best choice IS to have it be a fatal error, but designing the response to various potential errors (socket closed unexpectedly, failed to open a file, invalid input) is important to do early on so you can have a unified approach to such errors and ensure you don't have resource leaks when things don't terminate as expected. C++ and Java allow some of this to be done easier than in C, but it still isn't that hard to do even in straight C, but only if you think about it ahead of time!
Apple really should release updated timezone files as an update for all versions, there's no reason not to. Failing that, it would be very easy for someone to provide an unofficial update to fix it, either by copying the files from 10.4 or just compiling them from the updated sources.
I'm surprised that Java doesn't just use the C library routines for that functionality on platforms where it is available, but I see that you're right, 1.4.2 does not do it correctly, 1.5 does (on OS X 10.4.8).
This also applies to all Mac OS X machines as well, of course. Apple will supply a new set of timezone files in a patch (if they haven't already), and there's absolutely no reason it won't be available for every version of OS X (since they should be the exact same files, the format hasn't changed). Doesn't Windows use a similar method? I thought pretty much everything had switched over to zic-based timezone files (which also takes care of all those pesky leap-seconds that everyone seemed to be so worried about). They're pretty darned complete, and reading the source files for them is very entertaining and informative.
Seems to me it is just as likely that the game being played is the real problem. Every PS3 I've seen (all both of them) have always been frozen, on the same game. Perhaps it is a demo version of the game that has a memory leak problem or something similar so that after several hours of play it locks up. Maybe it does do a reset after a certain amount of time, but the reset isn't quite clean enough so that after enough of them, it freezes. None of that says anything about the reliability of the unit itself, nor of the quality of the release version of the game. Of course, that's only one possible explanation.
Christmas Eve at our local Best Buy, they had about 6 units available. As I stood there, one of them sold, another had someone asking about it. The demo unit was frozen.
Sam's Club has a 42" (Akai, I think) 1080p LCD HDTV for a bit less than $1400.
I hardly ever use a Windows machine. Doesn't mean I can't learn how, if that's what the job calls for. Five of your questions are very Windows-specific, and you're probably looking for a Windows-specific answer to the one about "safe mode". Yet, even not using Windows much, I can guess at most of the answer to most of those questions, which means they aren't very useful (and give me 5 minutes in front of a Windows machine, and 10 minutes to read the documentation on installing Windows XP, and I'll answer them all).
Then again, I probably wouldn't be looking for an entry-level job, certainly not in a Windows environment.
If it's that important to save some memory by using 32-bit pointers (and you don't need a 64-bit process address space), then it seems to me it should be pretty easy to compile to code that only uses 32-bit pointers, even with 64-bit code. It shouldn't be hard to mark a process as only having a 32-bit address space so the kernel memory allocation calls don't allocate anything outside of that range (as they'd have to do with 32-bit code anyway). Doesn't GCC support having 64-bit code with 32-bit pointers?
I've been using 64-bit processors for over 10 years, but the Wintel monopoly keeps burying them, damn it, and damn you Compaq and Hewlett-Packard! And Digital. And Apple. Before that I was using 60-bit processors with an 18-bit address space (and one's complement arithmetic, if you needed a further hint).
Why eat plants? They've converted solar energy to sugars and starches and such. Why not just absorb the solar energy directly? You in fact answered your own question: "to store it when solar energy is not available" (or, more to the point, because you can't tote around a solar energy collector large enough on your car to run it, and even then it would only run in the daytime, as long as you don't drive into shadows or tunnels or under trees or it's raining or ...)
Any form of storage of energy so you can use it in an automobile or a laptop or whatever is going to be less than 100% efficient. Direct solar cracking of water should be more efficient than converting solar to electricity to electrolyze water.
We better get rid of all the algae in the oceans, then, they produce this poisonous gas called oxygen in great quantities, by taking sunlight and breaking up water molecules! Damn those cyanobacteria in the first place. Really screwed up the atmosphere for those sulphur-based lifeforms.