You're assuming that A. this is not code that has to be written in a procedural language, and B. that the resources are being consumed long-term. What of all of the temporary resources used only during the course of a single function or method? It's incredibly wasteful to bloat the size of your objects to try to accommodate such things, not to mention that doing so would add additional choke points for concurrency.
Apparently, they decided to free slashdot from the story boundaries. The CA traffic light story is or was cross-linked to the comments for some Microsoft developer technology.
Did anybody read that as the Onion Crew Exploration Vehicle? Did anybody think this article reads like something the Onion would post? Except with a better headline, e.g. "Bean Counters Say Putting People in Space Is Hard"....
This reads like the sort of thing I see from mid to upper level corporate managers who often can't tell the difference between minor, trivially solvable problems and major, fundamental problems, and have no idea how to describe things to their managers except to portray everything generically as a "risk".
Digging a hole that big is expensive. Just pick a site in the middle of the desert somewhere, then nuke it from orbit. It's the only way to be sure.:-D
Modern C++ compilers have known how to remove duplicate template code for quite a few years.
Last I checked, the most popular C++ compiler, G++, still is not "modern" by that definition. The linker may reduce the mess at the end, but it's still likely to be a significant compile time hit. (No, I haven't benchmarked this.)
You also can't safely use the STL classes as base classes because they have no virtual destructor, so if you end up using them and need to do interesting stuff on top of them later, you can be in for a world of hurt.
Finally, if you use STL classes with mixed types that are polymorphic and expect them to behave reasonably, you're in for a world of hurt.
Yeah, that's probably going to take up a few kilobytes of your gigabyte of RAM. Seriously, I believe this is very, very rarely a problem.
In large pieces of software coded with heavy use of templates, it can bloat code pretty dramatically. RAM isn't free.
Most threading is due to stupidity, not a real need.
I guess it depends on what you're doing. If you are writing something that doesn't need multiple threads for performance, though, you usually don't need more than about a two core CPU, either, in which case you probably have already bought the last computer you will ever need. If we're focusing most of our coding effort on those folks, we're mainly wasting time because they've also probably bought the last version of the app they will ever need.:-)
Let's face it, CPUs aren't getting any faster, for all practical purposes. Performance is reaching a plateau. This means that if software continues to grow larger and more complex at the current rate, the user experience is going to get exponentially slower. The most promising way to improve upon this is with multiple cores, but only if the software can take advantage of it. Single threaded apps need not apply.
I would argue that goto is great when used correctly---for jumping to a cleanup routine at the end of a complex function that you jump to when anything goes fatally wrong. This makes the code much more readable and concise, reduces code bloat, and generally makes debugging easier. It's rare that goto is acceptable anywhere else, though.:-)
I have to disagree with you about templates. In C++, IIRC, templates bring with them limitations and restrictions that can really cause problems down the line. Worse, their memory footprint is an abomination. You can generally assume that for each different template type you pass to a template class, you've duplicated a significant portion (and possibly all) of the executable code for that class. They also clutter up the syntax every time you declare the class, though one might reasonably argue that void casting does the same for every use, so that's not a very strong argument.
If you really don't like casts, add extra wrapper methods for each type, thus confining the void casting to a limited number of places in the class itself without causing a significant amount of code bloat. Or use macros to do the casting for you and remove all the code bloat.
I agree with you about multithreading, though. One should not eschew it because it is hard. Bolting it on when you realize you're only taking advantage of 12.5% of that eight core CPU is much harder than designing your app right to begin with.
On the subject of red light cameras, if they become administrative violations, IMHO, the right solution is to simply not pay them. The DMV almost certainly won't refuse to renew your license for such administrative violations because the law only allows parking violations and a few other things to be handled in that manner.. As such, the tickets probably have no teeth unless you do other business with the city and they have laws that would allow them to refuse to do other business with you until you pay the fees.
The trivial solution is to set a time stamp and user ID every time somebody goes in to modify it. If the time stamp is within the last thirty minutes, display a warning that "John Doe is editing this file. You should check with him/her before making changes to make sure you don't collide." That's good enough for 99% of these sorts of things.
But yeah, rolling back and showing both versions in a side-by-side view when collisions occur is a nicer user experience if you're dealing with a lot of users. Using diff and patch to generate a suggested merging of the two new revisions with changes highlighted in yellow and conflicts shown in red is nicer still.
I think it would be more accurately analogous to someone picking a business's front door lock with a paperclip, after which he might or might not have told others how to pick that type of lock with a paperclip. Then, they expect him to replace the front, back, and side door locks because now everyone knows how to break into the business. Pretty absurd inasmuch as the business had cheap lock to begin with that should have been replaced years ago, not so absurd inasmuch as the risk of those locks getting picked increased dramatically as a result of the person's actions. So I can see both sides of this one. It certainly isn't clear cut. It really depends on whether he can establish reasonable doubt that anyone else knows about the specific flaws as a result of his actions.
No, a legitimate software vendor would never lie and claim that bulk P2P traffic requires low jitter communication. In fact, even an illegitimate vendor would have to be an idiot to do that because doing so would on the average slow down communication, not speed it up. You can only maintain low jitter (VoIP-grade) traffic by the equivalent of time slicing. That means that even when there's no other traffic, you only get a certain percentage of the time, period. The net result is that during the 90% of the time when there is no congestion, your traffic is artificially limited to a fraction of its potential so that it will still be able to maintain its data rate during the 10% when there is congestion. That's not conducive to getting the best data rate.
No, this likely falls completely and totally outside that law. This project is not about brute forcing crypto keys used to prevent decrypting the firmware. AFAIK, the firmware and apps are not encrypted. This project is about brute forcing keys used to SIGN firmware. The only time a signature is covered by the DMCA is if it is used to prevent people from using illegal copies of software that for some technical reason could not be copied with such a signature (e.g. game titles installed on a hard drive). Since no TI-83+ hardware is EVER sold without a copy of their firmware, such an argument is moot. Anyone with access to the hardware also has a legally licensed copy of the firmware. Therefore, the signature does not prevent people from obtaining copies of the firmware illegally in any useful way, and as such, is not a copyright protection mechanism under the DMCA.
In short, unless TI uses DRM software resident in their firmware to protect OTHER titles from copying, this clearly falls WELL outside the realm of the DMCA. Bear in mind that there are legal precedents for what I'm saying here. Similar cases have been tried in the past (e.g. Lexmark). The courts have consistently ruled that such circumstances are not protected. Now if TI has an app store and sells applications that are coded to your particular calculator in some way, they would have a case. Otherwise, using the DMCA in this way goes way beyond silly.
Any client that requires isochronous behavior (consistent flow of data at a constant bitrate) should make its intentions clear by requesting a bandwidth reservation.
The DMCA doesn't protect hardware in the U.S., either. Since AFAIK TI doesn't sell copyrighted software that is protected by DRM, this is clearly not a DMCA violation, and unless TI's lawyers haven't read any of the cases that have clarified this beyond a reasonable doubt, it also qualifies TI for perjury charges for deliberately making a false DMCA claim---not that any attorney general will actually have the guts to make an example of them....
IMHO, all these folks need to do is file a proper DMCA counter notice and then go about their business. Of course, IANAL, and they should consider getting advise from one.
That hasn't really been an issue since analog OTA TV went away. A lot of new shows aired in the last 8-10 years were originally shot in 16:9 anyway and have been P&S cropped for 4:3. That technique did often lead to only using about 3/4ths of the screen width for critical content, though not always in the center. In other words, a lot of the studios were ready for 16:9 for many years before the networks were ready to air it....:-)
Since NTSC OTA TV went away, there's no longer any reason to broadcast in 4:3 at all. Everybody either has a 16:9 set or has a converter that has to support letterboxing. It's well understood that the 4:3 experience will be inferior, so most of the broadcasters seem to be shifting everything fully over to 16:9 at this point without a crop. For now, some cable networks are maintaining non-HD versions of their feeds, sometimes with different edits for 4:3, sometimes with cropping off the 16:9, sometimes with the 16:9 containing a cropped or letterboxed 4:3 feed. It's all very messy.
At this point, little to no new content is being created with a 4:3 aspect ratio, though. That means that within a year or so, you likely won't see any more 4:3 content (on real networks) except for old reruns, and even many of the reruns will likely air in a 16:9 aspect ratio because they were shot that way originally. And the non-HD cable channels are likely to fade within a couple of years as well. There's really no point in catering to people with ancient TVs. Advertisers want people who buy stuff.:-)
Plasma sets I've seen use about half again more power than LCD sets, but that still puts them at or below what a direct view CRT would typically draw at a similar size. Yes, the old CRT-based projection TVs used a lot less (than LDCs, even), but were dimmer, had a narrower viewing angle, and were otherwise inferior in almost every way. That's just not a fair comparison.
My bad experiences with Sony products were mostly before the RoHS travesty took effect in '06. That said, I completely agree that RoHS is an abject failure of the highest order as environmental laws go.
I think we all deserve better TVs frankly and I think it is fair to say that the TV industry as a whole has failed to step up. We still have brand new TVs which draw almost as much power "off" as they do turned on with the sound blazing...
Either you don't know what you're talking about or you are lying to push a political position. I'll give you the benefit of the doubt and assume that you simply know nothing about modern electronics.
First, modern TVs use much less power than older TVs. The move away from CRTs alone made a big improvement (ignoring projection TVs), and even within the CRT space, things improved a lot over the years when they built those.
Second, power consumption when idle is almost invariably a tiny fraction of the active power consumption if you're looking at anything built in the past few years. Anything with the Energy Star logo is required to draw <1W standby, compared with 200W or more for a large LCD set. Even with non-Energy-Star-certified plasma sets, they typically draw low single digit Watts. Either way, there's typically at least a factor of 100 difference in power consumption between standby power and active power consumption in most modern TVs.
So citation needed. Find me a recent TV that draws almost as much power when idle as it does when turned on. The backlight alone for an LCD set is between half and 2/3rds of its power consumption, so good luck.
In my experience, Sony = Sucks to Own Next Year....:-)
I stopped buying Sony products about five years ago because of a long series of bizarre product problems, including products that took multiple repairs before they worked, products that never really worked well, etc. About the only product I've ever gotten from them that wasn't a train wreck was my Sony Ericsson phone, and even that was pretty clumsy, had a bizarre screen distortion if you kept it in your pocket, and had a joystick that didn't work reliably after a couple of years. And good luck finding a usable case for those lollipop-style phones.... Grrr.
Slashdot Mirror
You're assuming that A. this is not code that has to be written in a procedural language, and B. that the resources are being consumed long-term. What of all of the temporary resources used only during the course of a single function or method? It's incredibly wasteful to bloat the size of your objects to try to accommodate such things, not to mention that doing so would add additional choke points for concurrency.
A hit of what though?
Apparently, they decided to free slashdot from the story boundaries. The CA traffic light story is or was cross-linked to the comments for some Microsoft developer technology.
Did anybody read that as the Onion Crew Exploration Vehicle? Did anybody think this article reads like something the Onion would post? Except with a better headline, e.g. "Bean Counters Say Putting People in Space Is Hard"....
This reads like the sort of thing I see from mid to upper level corporate managers who often can't tell the difference between minor, trivially solvable problems and major, fundamental problems, and have no idea how to describe things to their managers except to portray everything generically as a "risk".
Ooh. They fixed posting for this story.
Digging a hole that big is expensive. Just pick a site in the middle of the desert somewhere, then nuke it from orbit. It's the only way to be sure. :-D
Last I checked, the most popular C++ compiler, G++, still is not "modern" by that definition. The linker may reduce the mess at the end, but it's still likely to be a significant compile time hit. (No, I haven't benchmarked this.)
Among other things, templates tend to lead to problems debugging, designs that aren't well thought out, etc.
http://www.ski-epic.com/templates_stl_rant/index.html
http://www.informit.com/articles/article.aspx?p=26017
You also can't safely use the STL classes as base classes because they have no virtual destructor, so if you end up using them and need to do interesting stuff on top of them later, you can be in for a world of hurt.
Finally, if you use STL classes with mixed types that are polymorphic and expect them to behave reasonably, you're in for a world of hurt.
http://www.oonumerics.org/tmpw00/kuehl.html
In large pieces of software coded with heavy use of templates, it can bloat code pretty dramatically. RAM isn't free.
I guess it depends on what you're doing. If you are writing something that doesn't need multiple threads for performance, though, you usually don't need more than about a two core CPU, either, in which case you probably have already bought the last computer you will ever need. If we're focusing most of our coding effort on those folks, we're mainly wasting time because they've also probably bought the last version of the app they will ever need. :-)
Let's face it, CPUs aren't getting any faster, for all practical purposes. Performance is reaching a plateau. This means that if software continues to grow larger and more complex at the current rate, the user experience is going to get exponentially slower. The most promising way to improve upon this is with multiple cores, but only if the software can take advantage of it. Single threaded apps need not apply.
I would argue that goto is great when used correctly---for jumping to a cleanup routine at the end of a complex function that you jump to when anything goes fatally wrong. This makes the code much more readable and concise, reduces code bloat, and generally makes debugging easier. It's rare that goto is acceptable anywhere else, though. :-)
I have to disagree with you about templates. In C++, IIRC, templates bring with them limitations and restrictions that can really cause problems down the line. Worse, their memory footprint is an abomination. You can generally assume that for each different template type you pass to a template class, you've duplicated a significant portion (and possibly all) of the executable code for that class. They also clutter up the syntax every time you declare the class, though one might reasonably argue that void casting does the same for every use, so that's not a very strong argument.
If you really don't like casts, add extra wrapper methods for each type, thus confining the void casting to a limited number of places in the class itself without causing a significant amount of code bloat. Or use macros to do the casting for you and remove all the code bloat.
I agree with you about multithreading, though. One should not eschew it because it is hard. Bolting it on when you realize you're only taking advantage of 12.5% of that eight core CPU is much harder than designing your app right to begin with.
Don't forget Objective-C, which on the Mac platform is the most important one of all.
On the subject of red light cameras, if they become administrative violations, IMHO, the right solution is to simply not pay them. The DMV almost certainly won't refuse to renew your license for such administrative violations because the law only allows parking violations and a few other things to be handled in that manner.. As such, the tickets probably have no teeth unless you do other business with the city and they have laws that would allow them to refuse to do other business with you until you pay the fees.
The trivial solution is to set a time stamp and user ID every time somebody goes in to modify it. If the time stamp is within the last thirty minutes, display a warning that "John Doe is editing this file. You should check with him/her before making changes to make sure you don't collide." That's good enough for 99% of these sorts of things.
But yeah, rolling back and showing both versions in a side-by-side view when collisions occur is a nicer user experience if you're dealing with a lot of users. Using diff and patch to generate a suggested merging of the two new revisions with changes highlighted in yellow and conflicts shown in red is nicer still.
I personally prefer an old computer with a modem:
while true ; do /dev/ttyS0 /dev/ttyS0 /dev/ttyS0 /dev/ttyS0 /dev/ttyS0
echo "atdt ###-###-####" >
sleep 30
printf "\E" >
sleep 1
printf "\E" >
sleep 1
printf "\E" >
sleep 1
echo "ATH0" >
done
The problem is that as soon as you make a monetary system idiot-proof, nature goes and creates a better idiot.
I think it would be more accurately analogous to someone picking a business's front door lock with a paperclip, after which he might or might not have told others how to pick that type of lock with a paperclip. Then, they expect him to replace the front, back, and side door locks because now everyone knows how to break into the business. Pretty absurd inasmuch as the business had cheap lock to begin with that should have been replaced years ago, not so absurd inasmuch as the risk of those locks getting picked increased dramatically as a result of the person's actions. So I can see both sides of this one. It certainly isn't clear cut. It really depends on whether he can establish reasonable doubt that anyone else knows about the specific flaws as a result of his actions.
No, a legitimate software vendor would never lie and claim that bulk P2P traffic requires low jitter communication. In fact, even an illegitimate vendor would have to be an idiot to do that because doing so would on the average slow down communication, not speed it up. You can only maintain low jitter (VoIP-grade) traffic by the equivalent of time slicing. That means that even when there's no other traffic, you only get a certain percentage of the time, period. The net result is that during the 90% of the time when there is no congestion, your traffic is artificially limited to a fraction of its potential so that it will still be able to maintain its data rate during the 10% when there is congestion. That's not conducive to getting the best data rate.
The claim that they are acting on behalf of the copyright holder, however, is in fact false, as hardware is not generally eligible for copyright.
No, this likely falls completely and totally outside that law. This project is not about brute forcing crypto keys used to prevent decrypting the firmware. AFAIK, the firmware and apps are not encrypted. This project is about brute forcing keys used to SIGN firmware. The only time a signature is covered by the DMCA is if it is used to prevent people from using illegal copies of software that for some technical reason could not be copied with such a signature (e.g. game titles installed on a hard drive). Since no TI-83+ hardware is EVER sold without a copy of their firmware, such an argument is moot. Anyone with access to the hardware also has a legally licensed copy of the firmware. Therefore, the signature does not prevent people from obtaining copies of the firmware illegally in any useful way, and as such, is not a copyright protection mechanism under the DMCA.
In short, unless TI uses DRM software resident in their firmware to protect OTHER titles from copying, this clearly falls WELL outside the realm of the DMCA. Bear in mind that there are legal precedents for what I'm saying here. Similar cases have been tried in the past (e.g. Lexmark). The courts have consistently ruled that such circumstances are not protected. Now if TI has an app store and sells applications that are coded to your particular calculator in some way, they would have a case. Otherwise, using the DMCA in this way goes way beyond silly.
Any client that requires isochronous behavior (consistent flow of data at a constant bitrate) should make its intentions clear by requesting a bandwidth reservation.
RSVP
All such clients should specify the Type Of Service field value as well.
The DMCA doesn't protect hardware in the U.S., either. Since AFAIK TI doesn't sell copyrighted software that is protected by DRM, this is clearly not a DMCA violation, and unless TI's lawyers haven't read any of the cases that have clarified this beyond a reasonable doubt, it also qualifies TI for perjury charges for deliberately making a false DMCA claim---not that any attorney general will actually have the guts to make an example of them....
IMHO, all these folks need to do is file a proper DMCA counter notice and then go about their business. Of course, IANAL, and they should consider getting advise from one.
That hasn't really been an issue since analog OTA TV went away. A lot of new shows aired in the last 8-10 years were originally shot in 16:9 anyway and have been P&S cropped for 4:3. That technique did often lead to only using about 3/4ths of the screen width for critical content, though not always in the center. In other words, a lot of the studios were ready for 16:9 for many years before the networks were ready to air it.... :-)
Since NTSC OTA TV went away, there's no longer any reason to broadcast in 4:3 at all. Everybody either has a 16:9 set or has a converter that has to support letterboxing. It's well understood that the 4:3 experience will be inferior, so most of the broadcasters seem to be shifting everything fully over to 16:9 at this point without a crop. For now, some cable networks are maintaining non-HD versions of their feeds, sometimes with different edits for 4:3, sometimes with cropping off the 16:9, sometimes with the 16:9 containing a cropped or letterboxed 4:3 feed. It's all very messy.
At this point, little to no new content is being created with a 4:3 aspect ratio, though. That means that within a year or so, you likely won't see any more 4:3 content (on real networks) except for old reruns, and even many of the reruns will likely air in a 16:9 aspect ratio because they were shot that way originally. And the non-HD cable channels are likely to fade within a couple of years as well. There's really no point in catering to people with ancient TVs. Advertisers want people who buy stuff. :-)
Plasma sets I've seen use about half again more power than LCD sets, but that still puts them at or below what a direct view CRT would typically draw at a similar size. Yes, the old CRT-based projection TVs used a lot less (than LDCs, even), but were dimmer, had a narrower viewing angle, and were otherwise inferior in almost every way. That's just not a fair comparison.
The keys alone won't do the trick. It's the password written on the Post-it note taped to the palm rest that's the bigger concern....
My bad experiences with Sony products were mostly before the RoHS travesty took effect in '06. That said, I completely agree that RoHS is an abject failure of the highest order as environmental laws go.
Either you don't know what you're talking about or you are lying to push a political position. I'll give you the benefit of the doubt and assume that you simply know nothing about modern electronics.
First, modern TVs use much less power than older TVs. The move away from CRTs alone made a big improvement (ignoring projection TVs), and even within the CRT space, things improved a lot over the years when they built those.
Second, power consumption when idle is almost invariably a tiny fraction of the active power consumption if you're looking at anything built in the past few years. Anything with the Energy Star logo is required to draw <1W standby, compared with 200W or more for a large LCD set. Even with non-Energy-Star-certified plasma sets, they typically draw low single digit Watts. Either way, there's typically at least a factor of 100 difference in power consumption between standby power and active power consumption in most modern TVs.
So citation needed. Find me a recent TV that draws almost as much power when idle as it does when turned on. The backlight alone for an LCD set is between half and 2/3rds of its power consumption, so good luck.
In my experience, Sony = Sucks to Own Next Year.... :-)
I stopped buying Sony products about five years ago because of a long series of bizarre product problems, including products that took multiple repairs before they worked, products that never really worked well, etc. About the only product I've ever gotten from them that wasn't a train wreck was my Sony Ericsson phone, and even that was pretty clumsy, had a bizarre screen distortion if you kept it in your pocket, and had a joystick that didn't work reliably after a couple of years. And good luck finding a usable case for those lollipop-style phones.... Grrr.