Most apps aren't really making use of 64-bits. The OS could make use of this if it needs more address space but those watches generally don't have that much all running at the same time. So now you have long registers most of which are rarely used.
The difference between 16 and 32 bit was huge, because there were many applications that found limitations on the address space and were already commonly doing 32-bit arithmetic. Fo 32 to 64 bit on the PC it wasn't all that big a deal overall; we already had 64 and 128 bit floating point on 32-bit machines, the arithmetic part of applications really didn't need that much extra space, so the real boost was in having lots more RAM for caching data instead of swapping. And from that the applications that succeded the most from all of this were 3D games with the truckloads of textures they use. For the same CPU clock rate, architecture, and capabilities (number of ALUs, cache size, etc) 32-bit has a good chance of running faster than 64-bit.
I am amazed that your personal info is worth that much money. Let's say 200 cups of coffee a year at the normally overpriced rate of $5 and that's $1000. If my personal info is worth that much then I should be getting all this free stuff. Why am I paying for an ISP when these advertisers could be totally subsidizing it? Why pay for streaming TV when they could be making it free or even providing kickbacks?
Problem is, the personal info is not inherently worth that much. I think we're in another dot-com era misconception of the price of some things.
Eventually another store in the area will want to get in on the action and the advertisers will say "sorry, we already got more personal data than we know what to do with from these students".
Most of the Black Mirror episodes haven't really been about romance. These are much more of a Twilight Zone feel with a technology or social media angle.
Don't forget the old Fortran programmer who moved to C/C++ and insists that all of his arrays start at 1, like God intended, and added some helper functions and macros to do this. Pity the developer who inherited that code and had to maintain it.
I have had to remove asserts where the code was too big to fit on the chip anymore. I found a few asserts, verified that they could not possibly happen, and removed them.
For most stuff I've worked in in the last couple of decades, the assert causes a mysterious reboot and coredump.
Several places I worked had a policy of leaving all asserts in place for production release. I think the rationale is that half the bugs are found by customers, which is another problem in itself.
They can sometimes be annoying. Ie, "assert(0)" for me often generates a code dump where I can't see the actual value of the original culprit variables anymore, since the compiler thinks the variables in don't need to be saved and the assert code itself scribbles all over the registers.
Another problem with asserts is that they need to be about REAL errors. I've seen many cases where an assert has happened at a customer and when investigating you see that the assert itself is the error. Often the devs just add them willy nilly without thinking about whether the precondition is true or not
I also see asserts (or exceptions) used as the cheap ass way of handling unexpected stuff, rather than trying to recover from the error and carry on. Ok, you got an unexpected value in a packet from the network, probably best to NOT assert there and instead handle the error (discard the packet probably), and yet I've seen code that did this which asserted after shipping.
I knew people who relied on non-standard or indeterminate compiler behavior like that. Then they'd move to a new machine or upgrade the compiler and complain that it wasn't working right or that it was now giving warnings about code that they thought was perfectly fine.
Or the bug only happens in optimized code but goes away when compiling for debugging. Which means you end up debugging optimized code so that the debugger is uncertain about a variable's value. You end up cross referencing it with an assembler listing.
The fun ones are alignment errors. Which never happen on x86 code so those who only know Windows or Linux on a PC have never encountered these. Stick in a variable to store state for debugging and suddenly things are aligned again. This sometimes leads to the developer saying "I don't know what the bug was but when I merged in Bob's code it started working again", then it gets checked in and forgotten about for several months until it resurfaces.
Sadly that last seems to happen a lot when you've got really complicated code, poor documentation (or hard to find), and the developers are new and don't understand it as well as they think. The result are devs poking at bugs with sticks trying to get them to go away.
A kernel debugging itself is tricky, and leads some into a trap when they don't realize that somethings won't debug that way. Using a separate JTAG or other external debugging helps a lot, but sometimes that screws things up too.
What I hate is when there's a bug that depends upon timing so that using a debugger causes it to not happen. But tell the debugger to just run until the bug but then you can't step backwards. If you single step through it, the other tasks aren't running so the bug doesn't appear. Which is the time when you put in your old fashioned printfs, or add a mini logging mechanism to tell you the last N function calls, etc.
I didn't have a debugger, since the stupid chip gets wonky when turning it on. So compile, load the code, look at the oscilloscope, scratch my head, and repeat. I worry I was doing something stupid like it wasn't really loading my new code but had the old code, but that checked out too. Ask for some help over skype, but get nowhere.
Stop and stare at it, the change was supposed to be over and done in 5 to 10 minutes and it's been a few hours. Then I see it, I forgot a "~". I wasn't clearing that bit, I was clearing everything but that bit. And that's the first programming related question I tend to ask in interviews, so I felt pretty dumb.
This was Thursday. I will be keeping a journal of my senility.
A student in the dorms once hooked up a model of the lander in his room with thread, pulleys, and a stepper and you could play the game that way on his text-only computer.
Except for the US. For federal elections much of these elections have dates that can't move. There's one and only one shot. For congress the states would have to appoint temporary positions. For president, as we've seen in the past there's a long drawn out arm-wrestling tournament between the lawyers and eventually the Supreme Count make a mistake and steps into the mess. A re-do is a perfectly good idea, only you'd have to change a lot of laws to allow that.
Are they really cybersquatters? The story is unclear how long the family owned this. Did they have it before the NFL and Microsoft had plans with that goofy name.
While it's urban myth that someone was killed doing this, it's not farfetched to have someone remove their hands from the wheel and then be surprised that the car started veering to the side. Ie, if they have technology to keep the accelerator pressed (and you can feel that it's depressed on those earlier cars) then it's not a leap to think that there's some mechanism that holds the steering wheel straight.
Some do of course, and the idiots in question aren't always customers but can be other people in the vicinity. Ie, customer wanted us to turn off the power LED on the devices that are put up on telephone poles, because the customer said that in their state people like to shoot at boxes with LEDs for target practice.
And there are better idiots being generated of course. One radiation therapy machine put on two buttons to initiate the process far apart on opposite sides of the console to ensure that two operators were present, to avoid operator error on the dangerous machine. At one site when servicing a machine the technician noticed that the operator used a weight to depress one of the buttons.
Slashdot Mirror
Most apps aren't really making use of 64-bits. The OS could make use of this if it needs more address space but those watches generally don't have that much all running at the same time. So now you have long registers most of which are rarely used.
The difference between 16 and 32 bit was huge, because there were many applications that found limitations on the address space and were already commonly doing 32-bit arithmetic. Fo 32 to 64 bit on the PC it wasn't all that big a deal overall; we already had 64 and 128 bit floating point on 32-bit machines, the arithmetic part of applications really didn't need that much extra space, so the real boost was in having lots more RAM for caching data instead of swapping. And from that the applications that succeded the most from all of this were 3D games with the truckloads of textures they use. For the same CPU clock rate, architecture, and capabilities (number of ALUs, cache size, etc) 32-bit has a good chance of running faster than 64-bit.
64 bits, it's what plants crave!
Also every 2 to 3 months there's a new model and everyone wants to switch.
Then 65 bit!
Sure it was clumsy and inconvenient, but boy did I look cool!
I am amazed that your personal info is worth that much money. Let's say 200 cups of coffee a year at the normally overpriced rate of $5 and that's $1000. If my personal info is worth that much then I should be getting all this free stuff. Why am I paying for an ISP when these advertisers could be totally subsidizing it? Why pay for streaming TV when they could be making it free or even providing kickbacks?
Problem is, the personal info is not inherently worth that much. I think we're in another dot-com era misconception of the price of some things.
Eventually another store in the area will want to get in on the action and the advertisers will say "sorry, we already got more personal data than we know what to do with from these students".
Or like blaming the Clintons when being asked tough questions.
Most of the Black Mirror episodes haven't really been about romance. These are much more of a Twilight Zone feel with a technology or social media angle.
I call myself stupid all the time, this lessens the blow of other people calling me stupid.
Don't forget the old Fortran programmer who moved to C/C++ and insists that all of his arrays start at 1, like God intended, and added some helper functions and macros to do this. Pity the developer who inherited that code and had to maintain it.
I have had to remove asserts where the code was too big to fit on the chip anymore. I found a few asserts, verified that they could not possibly happen, and removed them.
For most stuff I've worked in in the last couple of decades, the assert causes a mysterious reboot and coredump.
Several places I worked had a policy of leaving all asserts in place for production release. I think the rationale is that half the bugs are found by customers, which is another problem in itself.
They can sometimes be annoying. Ie, "assert(0)" for me often generates a code dump where I can't see the actual value of the original culprit variables anymore, since the compiler thinks the variables in don't need to be saved and the assert code itself scribbles all over the registers.
Another problem with asserts is that they need to be about REAL errors. I've seen many cases where an assert has happened at a customer and when investigating you see that the assert itself is the error. Often the devs just add them willy nilly without thinking about whether the precondition is true or not
I also see asserts (or exceptions) used as the cheap ass way of handling unexpected stuff, rather than trying to recover from the error and carry on. Ok, you got an unexpected value in a packet from the network, probably best to NOT assert there and instead handle the error (discard the packet probably), and yet I've seen code that did this which asserted after shipping.
Which is why the newer compilers give warnings in that case.
I knew people who relied on non-standard or indeterminate compiler behavior like that. Then they'd move to a new machine or upgrade the compiler and complain that it wasn't working right or that it was now giving warnings about code that they thought was perfectly fine.
Or the bug only happens in optimized code but goes away when compiling for debugging. Which means you end up debugging optimized code so that the debugger is uncertain about a variable's value. You end up cross referencing it with an assembler listing.
The fun ones are alignment errors. Which never happen on x86 code so those who only know Windows or Linux on a PC have never encountered these. Stick in a variable to store state for debugging and suddenly things are aligned again. This sometimes leads to the developer saying "I don't know what the bug was but when I merged in Bob's code it started working again", then it gets checked in and forgotten about for several months until it resurfaces.
Sadly that last seems to happen a lot when you've got really complicated code, poor documentation (or hard to find), and the developers are new and don't understand it as well as they think. The result are devs poking at bugs with sticks trying to get them to go away.
A kernel debugging itself is tricky, and leads some into a trap when they don't realize that somethings won't debug that way. Using a separate JTAG or other external debugging helps a lot, but sometimes that screws things up too.
What I hate is when there's a bug that depends upon timing so that using a debugger causes it to not happen. But tell the debugger to just run until the bug but then you can't step backwards. If you single step through it, the other tasks aren't running so the bug doesn't appear. Which is the time when you put in your old fashioned printfs, or add a mini logging mechanism to tell you the last N function calls, etc.
I didn't have a debugger, since the stupid chip gets wonky when turning it on. So compile, load the code, look at the oscilloscope, scratch my head, and repeat. I worry I was doing something stupid like it wasn't really loading my new code but had the old code, but that checked out too. Ask for some help over skype, but get nowhere.
Stop and stare at it, the change was supposed to be over and done in 5 to 10 minutes and it's been a few hours. Then I see it, I forgot a "~". I wasn't clearing that bit, I was clearing everything but that bit. And that's the first programming related question I tend to ask in interviews, so I felt pretty dumb.
This was Thursday. I will be keeping a journal of my senility.
A student in the dorms once hooked up a model of the lander in his room with thread, pulleys, and a stepper and you could play the game that way on his text-only computer.
Except for the US. For federal elections much of these elections have dates that can't move. There's one and only one shot. For congress the states would have to appoint temporary positions. For president, as we've seen in the past there's a long drawn out arm-wrestling tournament between the lawyers and eventually the Supreme Count make a mistake and steps into the mess. A re-do is a perfectly good idea, only you'd have to change a lot of laws to allow that.
Are they really cybersquatters? The story is unclear how long the family owned this. Did they have it before the NFL and Microsoft had plans with that goofy name.
I'm jiggy with it.
This decision is often up to the insurers.
You can be a millenial at any age...
While it's urban myth that someone was killed doing this, it's not farfetched to have someone remove their hands from the wheel and then be surprised that the car started veering to the side. Ie, if they have technology to keep the accelerator pressed (and you can feel that it's depressed on those earlier cars) then it's not a leap to think that there's some mechanism that holds the steering wheel straight.
Some do of course, and the idiots in question aren't always customers but can be other people in the vicinity. Ie, customer wanted us to turn off the power LED on the devices that are put up on telephone poles, because the customer said that in their state people like to shoot at boxes with LEDs for target practice.
And there are better idiots being generated of course. One radiation therapy machine put on two buttons to initiate the process far apart on opposite sides of the console to ensure that two operators were present, to avoid operator error on the dangerous machine. At one site when servicing a machine the technician noticed that the operator used a weight to depress one of the buttons.