I have no interest in buying "a box" like that unless it can record TV shows over the air on re-usable media. That and be able to play back videos from the same re-usable media that I record from other means, such as my computer or camcorder. Now that I mention it, it needs to be able to play audio files and slide shows, too. And, of course, support all open standards (well, at least Dirac and Ogg/{Theora,Vorbis}).
... if they would make the box also serve other purposes, such as receiving free over-the-air TV (tuner, 8VSB demodulator, ATSC decoder), un-encrypted cable channels (add QAM demodulator), and play videos from flash or hard drive (USB slot for hard drives, flash drives, and DVD drives, as well as SD/SDHC/SDXC slot for memory cards). Then all it needs is ethernet and wireless interfaces to the LAN, and it can do all these wonderful things. Oh, and it will need an HDMI output.
When making proposals to some company, never, ever, use that company's competitors in the process in any way, whatsoever. But you might still be able to get a job at Dell.
... dominate the web development arena, anyway. BHC computers (big hardware company), like so many others of their size, try to maximize profit by doing things such as hiring the cheapest people. So they get HTML, CSS, and even Javascript, that is not standards compliant and bases its functionality on the specific behavior of specific browsers. Developers that are in the browser specific mode are then further restricted to at most one or two browsers to "support".
I've seen well done web pages, even ones that don't waste space by fixing the size to a subset of the screen, done in ways that look great and consistent across Explorer, Firefox, Konqueror, Opera, and Safari. So it can be done right. The question is whether there is the management willpower to achieve it.
The good C programmers do know what ASCII is in hex. That's one of many things that separate them from not-so-good C programmers, as well as from the bad C programmers.
I work in this industry. The only novelty here is that the error got into production, and was not caught and corrected before it went that far.
That explains why there are so many software testers currently looking for work. The CC industry doesn't use as many of them, anymore.
Some submitters do, from time to time, change their code, and sometimes they get it wrong. For instance padding a field with spaces instead of zeros. Woopsie...!
You're still using legacy zero padding? You should be doing things in XML.
Seems that's what happened here. Sounds like a hex or dec field got padded with hex 20, and boom.
Not quite. If it were padded with space characters, you get 0x20 in each byte (and that's just what this number had in the first 6 of 8 bytes). If it were padded with zero characters, you would get 34,723,282,962,276,803.04 or so.
The REAL problem here is that the code was interpreting 64 bits as internal binary integer, when the data that arrived was at least 6 ASCII space characters. In other words, the data was in an old legacy format with space padding (which is easily handled by decimal conversion code along with zero padding), but the code expected a raw 64 bit integer, perhaps in the big-endian byte order.
This is annoying, especially when the processor gets to help correct the overwhelming number of errors, and then tries to explain that it wasn't their fault. Plenty of blame to go around with this one.
It was clearly someone's fault. Possibly a programmer not applying the proper field conversion? Perhaps the code was intended field conversion in place (replace the memory that has ASCII digit characters with the binary representation) and the conversion bailed out for some reason and the calling code didn't properly detect that (hint: in today's dollar amounts, the highest order byte of 64 bit integers should be zero).
Even if a programmer is to blame, management is not blameless. And maybe it's not even a programmer to blame. Ultimately, the real blame does lie with management who should have seen to it that errors never happen. Of course, errors do happen and while the blame may be correct, it's really cheaper apply 99.999% perfection instead of 100% perfection. It's not that serious a blame... at least as long as problems get corrected.
And then explains why they don't both validate/sanitize input, and test for at least some reasonable maximum value in the transaction amount. A max amount of $10,000,000 would have fixed this. That and an obvious lapse in testing. This is what keeps my bosses awake sometimes, fearing they will end up on the front page of the fishwrap looking stupid 'cause their overworked minions screwed something up, or didn't check, or didn't test very well. I love one of the guys we have testing. He's insufferable, and he catches genuine show-stoppers on a regular basis. They can't pay him what he's been worth, literally $millions, just in avoiding downtime and re-working code that went too far down the wrong path.
I don't know that $10,000,000 would be high enough. The kind of error this one is could be detected with a test against 2 to the 56th power. A lower test might catch other errors. And whatever tests are done, they should be in their own class, module, function, macro, or whatever, and separate from the mainline code. Two tests should be applied, one being conservatively high but fixed by the coders (e.g. the 2 to the 56th power test) and the other being configurable for code used by multiple processors (they can choose their own closer to the edge sanity check).
Believe me, this is in some ways preferable to getting files with one byte wrong that doesn't show up for a month, or sending the wrong data format (hex instead of packed binary or EBCDIC, for instance) and crashing the process completely. Plea
... unless the image hosting site does any processing of the pixels to re-create the image file for some reason (and there are some). Of course if you have your own web site, this is easy.
It appears that what Comcast may be doing is running TWO sets of DNS caching/resolving servers. One set operates as usual without any redirection. The other set has the redirection implementation deployed and enabled. The DHCP information supplied to customers based on their cable modem MAC address will provide the IP addresses of the redirecting servers, unless the customer opts out in which case the IP addresses of the non-redirecting servers will be provided. The fact that their opt-out is MAC based strongly suggests that this is the mechanism (despite the spin they put on it about how users activities such as upgrading software could mess up other opt-out methods). As long as they don't mess with DNS query datagrams or any other traffic sent elsewhere, this should be OK. The average customer really won't care, or will actually like the way that operates.
... in addition to their modem MAC based opt-out mechanism, they:
Provide alternative DNS cache servers that users can manually configure to bypass the redirection DNS cache servers. Support for this service can be limited to only informing the customer of the IP addresses of these DNS cache servers, such as on the tech support web page that tells customers how to opt-out. They do NOT have to support users on how to deploy this type of change.
Do NOT interfere with DNS queries sent to other DNS servers, whether with or without the recurse flag in the request. This is so that a user can run their own DNS cache server either on an internal network, or access a DNS cache server elsewhere on the internet (their own remote server, or a DNS caching/resolving service), without the need to set up a secure tunnel.
Do NOT interfere with any form of secure tunnel or other VLAN.
Do NOT intercept any UDP traffic, or TCP connections, or SCTP sessions, unless those are directed specifically to the provider's servers or services. For example the provider may offer HTTP caching services, media stream multipliers, IRC servers, etc., but must not affect users that want to bypass those services. ONE EXCEPTION: connections made to port 25 outside the provider's network SHOULD be intercepted unless the customer makes a "knowledgeable opt-out request" (for example, mentions "SMTP").
Do NOT do any other evil activity I don't have time to think about right now.
Anyone that knows what they are doing, or finds out via information from some source (the provider not being obligated to supply this information), should be able to use the internet exactly as it was originally intended.
I never heard of 1920x1050. Did you mean 1920x1080? At least with true 16:9 monitors, video aspect ratio for widescreen TV is correct at fullscreen. With a 16:10 display, it might be stretched vertically. Of course, you get a shorter screen this way. It would be nice if the movie players would just letterbox 1920x1080 movies on a 1920x1200 screen.
SQL can do just about everything you need in a data store... if you aren't considering performance and cost. For many things, the whole point is that SQL is overkill. The alternative solves FEWER problems... it just solves them BETTER.
Relational database have plenty of good uses. They are not the universal solution to data storage, but there are plenty of cases where they are the best case. I would certainly not use a relational database just to store user passwords. Something like Berkeley DB would be good. I have used raw files individually (one file per user named by username) with good success (the underlying filesystem was Reiserfs with tail packing enabled). But even where a relation database is called for (a CRM system, for example), I find that SQL is always a hindrance. I'd rather just get the data across a simple protocol (which can be wrapped in a simple API binding for the language in use).
There is still no reason not to have the open standard codecs installed by default. Browser developers can then obtain licensing for proprietary codecs and use those, in addition. Then web site operators, or the users that submit videos that don't get reformatted, can choose their preferred tradeoffs between the various issues of the various codecs. If they favor universal compatibility they can choose an open standard. If they favor making their video work faster or have stock in a company owning a codec, they can choose the proprietary one. Browser makers that intentionally leave out codec choice are doing their users a disservice. This includes you, Apple.
Vendors don't need to implement Dirac and Ogg Theora. Reference implementations exist. They only need to be willing to adopt the codecs and tie in the reference code to their browser. Their refusal is a sign of arrogance.
It's a nice read on the various things to think about in the design of software. But we still seem huge amounts of production code that is in error or even insecure. These are abstract concepts about design, but the problems in production are real and concrete. There is a failed connection between them. For example, how is it that the computer system for Frontier Airlines has only a place for ONE person to be designated to pick up an unaccompanied minor?
... he had not started to write (and therefore would have been carrying around) his new comic story about a trio of bumbling TSA agents that are always screwing up everything.
Slashdot Mirror
This site is along a mountain ridge while this site is offshore.
I have no interest in buying "a box" like that unless it can record TV shows over the air on re-usable media. That and be able to play back videos from the same re-usable media that I record from other means, such as my computer or camcorder. Now that I mention it, it needs to be able to play audio files and slide shows, too. And, of course, support all open standards (well, at least Dirac and Ogg/{Theora,Vorbis}).
... if they would make the box also serve other purposes, such as receiving free over-the-air TV (tuner, 8VSB demodulator, ATSC decoder), un-encrypted cable channels (add QAM demodulator), and play videos from flash or hard drive (USB slot for hard drives, flash drives, and DVD drives, as well as SD/SDHC/SDXC slot for memory cards). Then all it needs is ethernet and wireless interfaces to the LAN, and it can do all these wonderful things. Oh, and it will need an HDMI output.
... and it worked. It displays just fine. Are they trying to make their competitors look good or something?
When making proposals to some company, never, ever, use that company's competitors in the process in any way, whatsoever. But you might still be able to get a job at Dell.
... dominate the web development arena, anyway. BHC computers (big hardware company), like so many others of their size, try to maximize profit by doing things such as hiring the cheapest people. So they get HTML, CSS, and even Javascript, that is not standards compliant and bases its functionality on the specific behavior of specific browsers. Developers that are in the browser specific mode are then further restricted to at most one or two browsers to "support".
I've seen well done web pages, even ones that don't waste space by fixing the size to a subset of the screen, done in ways that look great and consistent across Explorer, Firefox, Konqueror, Opera, and Safari. So it can be done right. The question is whether there is the management willpower to achieve it.
The good C programmers do know what ASCII is in hex. That's one of many things that separate them from not-so-good C programmers, as well as from the bad C programmers.
... we had to break away from their empire. If this had been the Roman Empire, the cops would have joined the party.
Lots of cool weather and lots of cheap geo-thermal power.
I work in this industry. The only novelty here is that the error got into production, and was not caught and corrected before it went that far.
That explains why there are so many software testers currently looking for work. The CC industry doesn't use as many of them, anymore.
Some submitters do, from time to time, change their code, and sometimes they get it wrong. For instance padding a field with spaces instead of zeros. Woopsie...!
You're still using legacy zero padding? You should be doing things in XML.
Seems that's what happened here. Sounds like a hex or dec field got padded with hex 20, and boom.
Not quite. If it were padded with space characters, you get 0x20 in each byte (and that's just what this number had in the first 6 of 8 bytes). If it were padded with zero characters, you would get 34,723,282,962,276,803.04 or so.
The REAL problem here is that the code was interpreting 64 bits as internal binary integer, when the data that arrived was at least 6 ASCII space characters. In other words, the data was in an old legacy format with space padding (which is easily handled by decimal conversion code along with zero padding), but the code expected a raw 64 bit integer, perhaps in the big-endian byte order.
This is annoying, especially when the processor gets to help correct the overwhelming number of errors, and then tries to explain that it wasn't their fault. Plenty of blame to go around with this one.
It was clearly someone's fault. Possibly a programmer not applying the proper field conversion? Perhaps the code was intended field conversion in place (replace the memory that has ASCII digit characters with the binary representation) and the conversion bailed out for some reason and the calling code didn't properly detect that (hint: in today's dollar amounts, the highest order byte of 64 bit integers should be zero).
Even if a programmer is to blame, management is not blameless. And maybe it's not even a programmer to blame. Ultimately, the real blame does lie with management who should have seen to it that errors never happen. Of course, errors do happen and while the blame may be correct, it's really cheaper apply 99.999% perfection instead of 100% perfection. It's not that serious a blame ... at least as long as problems get corrected.
And then explains why they don't both validate/sanitize input, and test for at least some reasonable maximum value in the transaction amount. A max amount of $10,000,000 would have fixed this. That and an obvious lapse in testing. This is what keeps my bosses awake sometimes, fearing they will end up on the front page of the fishwrap looking stupid 'cause their overworked minions screwed something up, or didn't check, or didn't test very well. I love one of the guys we have testing. He's insufferable, and he catches genuine show-stoppers on a regular basis. They can't pay him what he's been worth, literally $millions, just in avoiding downtime and re-working code that went too far down the wrong path.
I don't know that $10,000,000 would be high enough. The kind of error this one is could be detected with a test against 2 to the 56th power. A lower test might catch other errors. And whatever tests are done, they should be in their own class, module, function, macro, or whatever, and separate from the mainline code. Two tests should be applied, one being conservatively high but fixed by the coders (e.g. the 2 to the 56th power test) and the other being configurable for code used by multiple processors (they can choose their own closer to the edge sanity check).
Believe me, this is in some ways preferable to getting files with one byte wrong that doesn't show up for a month, or sending the wrong data format (hex instead of packed binary or EBCDIC, for instance) and crashing the process completely. Plea
... unless the image hosting site does any processing of the pixels to re-create the image file for some reason (and there are some). Of course if you have your own web site, this is easy.
... Minix?
It appears that what Comcast may be doing is running TWO sets of DNS caching/resolving servers. One set operates as usual without any redirection. The other set has the redirection implementation deployed and enabled. The DHCP information supplied to customers based on their cable modem MAC address will provide the IP addresses of the redirecting servers, unless the customer opts out in which case the IP addresses of the non-redirecting servers will be provided. The fact that their opt-out is MAC based strongly suggests that this is the mechanism (despite the spin they put on it about how users activities such as upgrading software could mess up other opt-out methods). As long as they don't mess with DNS query datagrams or any other traffic sent elsewhere, this should be OK. The average customer really won't care, or will actually like the way that operates.
... in addition to their modem MAC based opt-out mechanism, they:
Anyone that knows what they are doing, or finds out via information from some source (the provider not being obligated to supply this information), should be able to use the internet exactly as it was originally intended.
I never heard of 1920x1050. Did you mean 1920x1080? At least with true 16:9 monitors, video aspect ratio for widescreen TV is correct at fullscreen. With a 16:10 display, it might be stretched vertically. Of course, you get a shorter screen this way. It would be nice if the movie players would just letterbox 1920x1080 movies on a 1920x1200 screen.
Get a 2560x1600 and run the video at 1280x800.
KDS K-726MWB 17 inch WIDE SCREEN LCD 1400 X 1050 0.291MM 500:1 8ms (Black)
... the economy is finally turning around?
... oh wait.
SQL can do just about everything you need in a data store ... if you aren't considering performance and cost. For many things, the whole point is that SQL is overkill. The alternative solves FEWER problems ... it just solves them BETTER.
Relational database have plenty of good uses. They are not the universal solution to data storage, but there are plenty of cases where they are the best case. I would certainly not use a relational database just to store user passwords. Something like Berkeley DB would be good. I have used raw files individually (one file per user named by username) with good success (the underlying filesystem was Reiserfs with tail packing enabled). But even where a relation database is called for (a CRM system, for example), I find that SQL is always a hindrance. I'd rather just get the data across a simple protocol (which can be wrapped in a simple API binding for the language in use).
There is still no reason not to have the open standard codecs installed by default. Browser developers can then obtain licensing for proprietary codecs and use those, in addition. Then web site operators, or the users that submit videos that don't get reformatted, can choose their preferred tradeoffs between the various issues of the various codecs. If they favor universal compatibility they can choose an open standard. If they favor making their video work faster or have stock in a company owning a codec, they can choose the proprietary one. Browser makers that intentionally leave out codec choice are doing their users a disservice. This includes you, Apple.
Vendors don't need to implement Dirac and Ogg Theora. Reference implementations exist. They only need to be willing to adopt the codecs and tie in the reference code to their browser. Their refusal is a sign of arrogance.
It's a nice read on the various things to think about in the design of software. But we still seem huge amounts of production code that is in error or even insecure. These are abstract concepts about design, but the problems in production are real and concrete. There is a failed connection between them. For example, how is it that the computer system for Frontier Airlines has only a place for ONE person to be designated to pick up an unaccompanied minor?
... he had not started to write (and therefore would have been carrying around) his new comic story about a trio of bumbling TSA agents that are always screwing up everything.