That's nothing. I saw this show once where a guy made a rocket from parts in a junkyard, and he even used a cement mixer as a crew compartment! And it was an SSTO, too!
Patents cover a method of doing something, not the mere idea of doing something. A software implementation of a hardware feature is likely to use a different method to accomplish the same or similar result.
Management absolutely. "We're a copier company. Why are you working on this crazy crap?"
At least Apple copied the stuff with permission, which the Anti-Apple crowd conveniently never mentions. Xerox management didn't care and basically let them have it cheap.
Great. Except that the bug is probably in a hardware RTC circuit. Please try again in Verilog or VHDL and include the process by which the silicon can be updated to use your glorious patch.
It is very likely that the clock chip used BCD for the date and time, and used "bcd_year % 4" to determine a leap year. 10 is not divisible by 4, but 0x10 is.
They may have only two years to fix it. If it's a bug that causes the BCD year mod 4 to be used to determine leap years, then it will be a problem every other year in this decade. Then another ten years later it would be a problem again.
The next time it happens, the clock will lose a day, instead of gaining a broken day. Among other things, imagine what happens when you play a downloaded "rental" video with a 24 hour clock from when you first start playing it... and you start playing just before it turns Feb 29 in UTC time.
The wiki entry mentioned in another reply was deleted becase it was not relevant to "ARM Architecture". (And it had horrible grammar too.) I dug it out of the article history:
PS3 Date Controversy
It has been suggest that older verions of the ARM SYSCON cpus had errata such that the CPUs believed incorrectly that 2010 was a leap year and may be partially responsible for non slim versions of the Playstation 3 not being able to function properly on 3/1/2010 (issue resolved itself on most PS3s at midnight GMT on 3/2/2010). "The ARM SYSCON CPU that is used to power up the front panel of the ps3, that is responsible for doing things like sleep mode, eject, RTC etc. Is an old batch that sony picked up from the shelf like other manufacturers that has that calendar year bug regarding feburary 29th on certain periods. Causing the ps3 system clock and the real time clock to desync, messing up security measures like Digital Rights management software and sometimes games that relies on clocks for whatever reason. As well as signing up to the playstation network This CPU is always on even when your PS3 isn’t plugged
This is the one of the same type of CPUs that is powering up mobile devices like zune and blackberries, they have been affected with this bug, so they done some software patches. A syscon update can also fix this problem
The Slims ps3s aren’t affected because they use a newer up to date revision on the syscon cpu that fixes this bug.
[WARNING: will void your warranty, may be best to wait for official solution from Sony] - A quick way to fix this is to remove the RTC battery for at least 5-10 min and plug it back in, you will see the date and time reset, and voila "
I would add the following:
1) PS3 asks for date from chip (note: chip time does not include local time zone, and is probably in UTC)
2) Chip returns 10-02-29 with correct hh:mm:ss. Like many clock chips, these are returned as discrete components, probably in BCD.
3) PS3 adds 2000 to the year and passes 2010-02-29 to conversion routine, which is supposed to return an epoch offset in seconds.
4) Conversion routine says "that's stupid" and returns zero because it's an error.
5) PS3 adds hh:mm:ss and time zone offset to the zero.
6) PS3 later tries to convert back to Y/M/D using an epoch of 2000-01-01 00:00.
6) PS3s around the world display 1999-12-31 or 2000-01-01.
The problem points:
* Chip that used discrete date components instead of keeping track of seconds since offset. This is common to make low level (assembly-language) software easier to write, even in this era when C is used for everything but first-stage boot loaders, and integer multiply/divide instructions are standard in CPU instruction sets. This meant that a piece of un-patchable hardware needed to correctly implement the leap year date algorithm, which is rarely tested when implemented, even if the implementor understands it.
* Bogus date was passed to conversion routine, and error condition was not checked. But then what do you do when the date you got from hardware is bogus?
* DRM and other features that depended upon a correct date to enforce digital restrictions.
I think it's possible the source of the bug was that the "year divisible by four" condition in the chip was based on the BCD date. 10 is not divisible by four, but 0x10 is. If so, that would put it in the same category as the SMS Y2010 bug, being due to the use of BCD. So expect it to come back every even year for the rest of the decade, if Sony doesn't patch the software's interpretation of the incorrect date.
I just realized that the zero date may have been the result of: 1) clock chip returns February 29 2010 as discrete Y/M/D components, 2) date is passed to conversion routine that returns seconds-from-epoch of the date at 00:00, 3) conversion routine says WTF U DOIN? and returns zero as an error value, 4) hours and minutes and time zone offset are added to the zero.
So it didn't so much divide by zero as add to zero.
They were showing December 31 because of the time zone adjustment. In whatever is the "prime" time zone (GMT?) it would have been exactly 2000-01-01 00:00.
And unlike the parallel port, this form of bit-banging on the control lines generally works even with USB serial adapters.
A lot of legacy stuff that uses the parallel port won't even work with a PCI parallel port, never mind USB adapters. That's why Windows laptops have kept parallel ports for so long.
I believe you are referring to break. Esc is just a character (0x1B). Break is holding the signal beyond the length of a character, making a special sort of overrun/framing error. Some USB-serial adapters can not send a break signal. And break is the signal you need to interrupt the boot process on Cisco or Sun gear.
Also, your problem could be related to the driver or terminal program that are using.
Or you could just get a Keyspan adapter. They not only work right, but they've even kept up-to-date driver support (at least on OS X) for "legacy" adapters that that they don't sell anymore.
The technical details needed for the proof are pretty advanced maths which would be basically impossible to explain to a layman without teaching a lot of maths after which they would no longer be a layman.
And they most certainly won't fit in the margin of a book.
2.5 years is less than the maximum length of the Applecare warranty. So you're not going to support the major OS release that came with a computer that's still under warranty? Meanwhile, XP, and in many cases W2K are still supported?
You haven't heard the news? They're planning to build an interstellar bypass through there. The plans have been on file at Alpha Centauri for years. It's not their fault if you haven't been around to check them.
When OS X 10.0 beta first came out, it was so much nicer to use than 9 (just being able to wake from sleep in less than 10 seconds was enough alone) that I permanently switched over to it on my G3 Powerbook (Pismo model). However, that being the "previous" model at the time (I bought one of the last ones), they didn't have the power management working right, and it used up the battery noticeably more when in sleep. But that wasn't the big problem.
In the last month before the initial one-year warranty was expiring, I was running it off of battery. When the battery got down to 75%, it suddenly went to 1%. I thought it was a glitch or something. After that, the battery only started crashing sooner. At that time, due to the model being out of sale for a year, Apple (apparently) stopping production of replacement batteries (a really stupid idea right there), and (presumably) other people having their batteries die at the same time, getting a new battery was like pulling teeth... from an elephant.
This illustrates one of the failure modes with LiIon batteries. When they wear out, they will charge to 100%, but crash during the discharge cycle. Part of the problem was that Apple had their laptops topping off the batteries whenever not at 100% (later on, Apple made a change so as not to top it off when already at 95% of better), and part of the problem was that the incomplete power-down during sleep caused the battery to go through cycles faster.
Also, LiIon batteries have a shelf life of a couple of years even if not used. It's possible that some of these people might have had an older laptop, but the summary specifically mentions new W7 laptops, and Windows computers are usually traded up more often than Macs. But I'm sort of surprised that the BIOS wouldn't be handling the power management exactly the same whether XP or 7 was used.
There are recent events that give strong indication that the election in Massachusetts could warrant some investigation in regards to media influence and especially in regards to electronic voting machines.
Are you trying to imply that a 5% margin victory by a candidate from the party not in power, when polls were already predicting a shift in voters to that candidate, was somehow due to electronic voting machines? If so, you're just as nuts as the birthers and 9/11 conspiracy nuts.
If it's the sign I'm thinking of, it would have originated in the same battle(s) between France and England. Take the famous WWII "V for victory" sign, turn the hand around so that the palm is facing you, and close up the V a bit. See, back in the olden days, when archers got captured in a war, the fingers that they needed to draw a bow were cut off. Then consider what archers could do in medieval combat. Enough of them firing at the same time would cause a rain of arrows from above, right over your grouped forces, with very nasty results. That sign (at least from the British side) would roughly mean "we kicked your arse and still have our fingers so we can do it again".
There's no reason something can't be both pronounceable and secure. Start with two nonsense syllables, and add a special character between them. Not quite as "secure" as a completely random password, but much less likely to be written down, plus some of the letters can be l33t3d for variant forms. Make three base words for various levels of usage (one for regular web stuff, one for login passwords, and another rarely used for important stuff), and you can even keep around hints for rarely used passwords with one letter and a bunch of ## or @@ symbols for the parts that change.
A good way to make something pronounceable is with the old "D&D character name generator" type of program, making a CVCCVC name. So you get, for instance, DORLOT (FWIW, I cheated just now and used an alpha D20), and don't tell me you can't pronounce that. Then some variant passwords from that would be "dor%lot", "d0r##lOt", and "D0r:*!o+". They're still "dorlot", but the result is a lot more secure than picking a dictionary word and puts you into that tiny wedge on TFA's pie chart. And while they're all similar, they're different enough that a compromise in one place won't let someone get into every account you have anywhere.
I see a great need for compilers to support an RTF-to-plaintext filter on their front ends. Then you can program in whatever font you want, and it will look essentially the same when viewed by anybody else.
But there should also be a standard on what you should and shouldn't do. For instance, it should not be kosher to specify text sizes or colors. Text sizes give you the "HTML mail" problem (where Outlook e-mails show up in a tiny font because the HTML hard-codes the font point size). Text colors screw things up for the "white on black" crowd, and also allow for "white on white" hiding of evil code.
It doesn't have to specifically be RTF. RTF would really be overdoing it. Whatever format would be chosen should take well to merging in svn or whatever. Maybe something equivalent to Unix's #! line could specify the font. You don't want to specify the size, because that should be up to the individual reader, and I suppose the font should really be a matter of choice too. And most of the time, 8-space tab stops work well in proportional fonts.
So you just need... um, you just need people to use 8-space hard-tab text, not use any tabs after the first non-tab character in a line, and... oh, I guess you can just use plain text after all, as long as everyone switch to hard tabs. Oops, never mind.
Slashdot Mirror
That's nothing. I saw this show once where a guy made a rocket from parts in a junkyard, and he even used a cement mixer as a crew compartment! And it was an SSTO, too!
Patents cover a method of doing something, not the mere idea of doing something. A software implementation of a hardware feature is likely to use a different method to accomplish the same or similar result.
Like Gauntlet, only with RPG stats and more power-ups?
Management absolutely. "We're a copier company. Why are you working on this crazy crap?"
At least Apple copied the stuff with permission, which the Anti-Apple crowd conveniently never mentions. Xerox management didn't care and basically let them have it cheap.
This site seems to have the kind of information that the submitter needs.
Because kdawson is the "editor" who happens to be on duty during the kook-shift?
Great. Except that the bug is probably in a hardware RTC circuit. Please try again in Verilog or VHDL and include the process by which the silicon can be updated to use your glorious patch.
It is very likely that the clock chip used BCD for the date and time, and used "bcd_year % 4" to determine a leap year. 10 is not divisible by 4, but 0x10 is.
They may have only two years to fix it. If it's a bug that causes the BCD year mod 4 to be used to determine leap years, then it will be a problem every other year in this decade. Then another ten years later it would be a problem again.
The next time it happens, the clock will lose a day, instead of gaining a broken day. Among other things, imagine what happens when you play a downloaded "rental" video with a 24 hour clock from when you first start playing it... and you start playing just before it turns Feb 29 in UTC time.
The wiki entry mentioned in another reply was deleted becase it was not relevant to "ARM Architecture". (And it had horrible grammar too.) I dug it out of the article history:
PS3 Date Controversy It has been suggest that older verions of the ARM SYSCON cpus had errata such that the CPUs believed incorrectly that 2010 was a leap year and may be partially responsible for non slim versions of the Playstation 3 not being able to function properly on 3/1/2010 (issue resolved itself on most PS3s at midnight GMT on 3/2/2010). "The ARM SYSCON CPU that is used to power up the front panel of the ps3, that is responsible for doing things like sleep mode, eject, RTC etc. Is an old batch that sony picked up from the shelf like other manufacturers that has that calendar year bug regarding feburary 29th on certain periods. Causing the ps3 system clock and the real time clock to desync, messing up security measures like Digital Rights management software and sometimes games that relies on clocks for whatever reason. As well as signing up to the playstation network This CPU is always on even when your PS3 isn’t plugged
This is the one of the same type of CPUs that is powering up mobile devices like zune and blackberries, they have been affected with this bug, so they done some software patches. A syscon update can also fix this problem
The Slims ps3s aren’t affected because they use a newer up to date revision on the syscon cpu that fixes this bug.
[WARNING: will void your warranty, may be best to wait for official solution from Sony] - A quick way to fix this is to remove the RTC battery for at least 5-10 min and plug it back in, you will see the date and time reset, and voila "
I would add the following:
1) PS3 asks for date from chip (note: chip time does not include local time zone, and is probably in UTC)
2) Chip returns 10-02-29 with correct hh:mm:ss. Like many clock chips, these are returned as discrete components, probably in BCD.
3) PS3 adds 2000 to the year and passes 2010-02-29 to conversion routine, which is supposed to return an epoch offset in seconds.
4) Conversion routine says "that's stupid" and returns zero because it's an error.
5) PS3 adds hh:mm:ss and time zone offset to the zero.
6) PS3 later tries to convert back to Y/M/D using an epoch of 2000-01-01 00:00.
6) PS3s around the world display 1999-12-31 or 2000-01-01.
The problem points:
* Chip that used discrete date components instead of keeping track of seconds since offset. This is common to make low level (assembly-language) software easier to write, even in this era when C is used for everything but first-stage boot loaders, and integer multiply/divide instructions are standard in CPU instruction sets. This meant that a piece of un-patchable hardware needed to correctly implement the leap year date algorithm, which is rarely tested when implemented, even if the implementor understands it.
* Bogus date was passed to conversion routine, and error condition was not checked. But then what do you do when the date you got from hardware is bogus?
* DRM and other features that depended upon a correct date to enforce digital restrictions.
I think it's possible the source of the bug was that the "year divisible by four" condition in the chip was based on the BCD date. 10 is not divisible by four, but 0x10 is. If so, that would put it in the same category as the SMS Y2010 bug, being due to the use of BCD. So expect it to come back every even year for the rest of the decade, if Sony doesn't patch the software's interpretation of the incorrect date.
I just realized that the zero date may have been the result of: 1) clock chip returns February 29 2010 as discrete Y/M/D components, 2) date is passed to conversion routine that returns seconds-from-epoch of the date at 00:00, 3) conversion routine says WTF U DOIN? and returns zero as an error value, 4) hours and minutes and time zone offset are added to the zero.
So it didn't so much divide by zero as add to zero.
They were showing December 31 because of the time zone adjustment. In whatever is the "prime" time zone (GMT?) it would have been exactly 2000-01-01 00:00.
And unlike the parallel port, this form of bit-banging on the control lines generally works even with USB serial adapters.
A lot of legacy stuff that uses the parallel port won't even work with a PCI parallel port, never mind USB adapters. That's why Windows laptops have kept parallel ports for so long.
I believe you are referring to break. Esc is just a character (0x1B). Break is holding the signal beyond the length of a character, making a special sort of overrun/framing error. Some USB-serial adapters can not send a break signal. And break is the signal you need to interrupt the boot process on Cisco or Sun gear.
Also, your problem could be related to the driver or terminal program that are using.
Or you could just get a Keyspan adapter. They not only work right, but they've even kept up-to-date driver support (at least on OS X) for "legacy" adapters that that they don't sell anymore.
The technical details needed for the proof are pretty advanced maths which would be basically impossible to explain to a layman without teaching a lot of maths after which they would no longer be a layman.
And they most certainly won't fit in the margin of a book.
But does it provide more options than having five cats? The rats and roaches won't stick around when you have that many cats around.
Here it is in hexadecimal: 2A
You misspelled "eBaum's World". Hope this helps!
2.5 years is less than the maximum length of the Applecare warranty. So you're not going to support the major OS release that came with a computer that's still under warranty? Meanwhile, XP, and in many cases W2K are still supported?
So who is paying to make sure every pregnant woman has a cell phone during this time period? Or are free cell phones run by the government next?
You haven't heard the news? They're planning to build an interstellar bypass through there. The plans have been on file at Alpha Centauri for years. It's not their fault if you haven't been around to check them.
When OS X 10.0 beta first came out, it was so much nicer to use than 9 (just being able to wake from sleep in less than 10 seconds was enough alone) that I permanently switched over to it on my G3 Powerbook (Pismo model). However, that being the "previous" model at the time (I bought one of the last ones), they didn't have the power management working right, and it used up the battery noticeably more when in sleep. But that wasn't the big problem.
In the last month before the initial one-year warranty was expiring, I was running it off of battery. When the battery got down to 75%, it suddenly went to 1%. I thought it was a glitch or something. After that, the battery only started crashing sooner. At that time, due to the model being out of sale for a year, Apple (apparently) stopping production of replacement batteries (a really stupid idea right there), and (presumably) other people having their batteries die at the same time, getting a new battery was like pulling teeth... from an elephant.
This illustrates one of the failure modes with LiIon batteries. When they wear out, they will charge to 100%, but crash during the discharge cycle. Part of the problem was that Apple had their laptops topping off the batteries whenever not at 100% (later on, Apple made a change so as not to top it off when already at 95% of better), and part of the problem was that the incomplete power-down during sleep caused the battery to go through cycles faster.
Also, LiIon batteries have a shelf life of a couple of years even if not used. It's possible that some of these people might have had an older laptop, but the summary specifically mentions new W7 laptops, and Windows computers are usually traded up more often than Macs. But I'm sort of surprised that the BIOS wouldn't be handling the power management exactly the same whether XP or 7 was used.
There are recent events that give strong indication that the election in Massachusetts could warrant some investigation in regards to media influence and especially in regards to electronic voting machines.
Are you trying to imply that a 5% margin victory by a candidate from the party not in power, when polls were already predicting a shift in voters to that candidate, was somehow due to electronic voting machines? If so, you're just as nuts as the birthers and 9/11 conspiracy nuts.
If it's the sign I'm thinking of, it would have originated in the same battle(s) between France and England. Take the famous WWII "V for victory" sign, turn the hand around so that the palm is facing you, and close up the V a bit. See, back in the olden days, when archers got captured in a war, the fingers that they needed to draw a bow were cut off. Then consider what archers could do in medieval combat. Enough of them firing at the same time would cause a rain of arrows from above, right over your grouped forces, with very nasty results. That sign (at least from the British side) would roughly mean "we kicked your arse and still have our fingers so we can do it again".
There's no reason something can't be both pronounceable and secure. Start with two nonsense syllables, and add a special character between them. Not quite as "secure" as a completely random password, but much less likely to be written down, plus some of the letters can be l33t3d for variant forms. Make three base words for various levels of usage (one for regular web stuff, one for login passwords, and another rarely used for important stuff), and you can even keep around hints for rarely used passwords with one letter and a bunch of ## or @@ symbols for the parts that change.
A good way to make something pronounceable is with the old "D&D character name generator" type of program, making a CVCCVC name. So you get, for instance, DORLOT (FWIW, I cheated just now and used an alpha D20), and don't tell me you can't pronounce that. Then some variant passwords from that would be "dor%lot", "d0r##lOt", and "D0r:*!o+". They're still "dorlot", but the result is a lot more secure than picking a dictionary word and puts you into that tiny wedge on TFA's pie chart. And while they're all similar, they're different enough that a compromise in one place won't let someone get into every account you have anywhere.
I see a great need for compilers to support an RTF-to-plaintext filter on their front ends. Then you can program in whatever font you want, and it will look essentially the same when viewed by anybody else.
But there should also be a standard on what you should and shouldn't do. For instance, it should not be kosher to specify text sizes or colors. Text sizes give you the "HTML mail" problem (where Outlook e-mails show up in a tiny font because the HTML hard-codes the font point size). Text colors screw things up for the "white on black" crowd, and also allow for "white on white" hiding of evil code.
It doesn't have to specifically be RTF. RTF would really be overdoing it. Whatever format would be chosen should take well to merging in svn or whatever. Maybe something equivalent to Unix's #! line could specify the font. You don't want to specify the size, because that should be up to the individual reader, and I suppose the font should really be a matter of choice too. And most of the time, 8-space tab stops work well in proportional fonts.
So you just need... um, you just need people to use 8-space hard-tab text, not use any tabs after the first non-tab character in a line, and... oh, I guess you can just use plain text after all, as long as everyone switch to hard tabs. Oops, never mind.