up next: an app for your phone that interacts with all the crap they try to make you watch before they show you any content, then beeps to let you know the actual content is starting.
I think the fact that reviewers fail to mention obvious bugs is: 1) unethical 2) Proof of how widespread the control/corruption of these reviewers by the game companies is. 3) If it already isnt, it should be illegal if reviewers misrepresent themselves as being an independent authority/in a position of trust that puts consumers interests first, as we look to these people for advise on spending wisely. Them being complicit in what amounts to misrepresenting and misadvertising a product is clearly fraudulent.
Just because they are reviewing a pre-release version is no excuse either, they should still mention the bugs but then say its still in beta or whatever, not just pretend it didn't happen.
I know Bethesda has a long history of releasing very buggy games, but expecting all consumers to necessarily know that and make a judgement before buying the product is unreasonable.
If you were reviewing any other product (say a car) and it failed in some way, of course you'd mention it. I don't go along with the apparently common sheep-like misconception that software somehow gets a magic get-out-of-jail card, so that when we buy a clearly substandard product its somehow now the consumers responsibility to just suck it up and accept crap for good money.
your comments, while interesting, don't come close to addressing the point. The question being asked here is, is it ethical for reviewers to not mention that a bunch of bugs exist in the game they are reviewing? I would say hell no.
Are you saying that you haven't personally encountered any bugs?
Maybe you should respond to what I *actually* wrote instead of responding to your own incorrect assumption that I didn't read or understand what he wrote.
I agree that moving away from IC engines would be good for the enviironment, and I agree that motor vehicles are a significant contributor to human-caused emissions of greenhouse gasses, but lets get this into persspective:
The entire transportation sector only accounts for about 27% of the total man-made greenhouse gas (MMGG) emissions: http://www3.epa.gov/climatecha...
Of that 27%, Road transport accounts for 72%, http://www3.epa.gov/climatecha... the rest is aviation and marine. That means about 19% of all MMGG is road vehicles. From http://www3.epa.gov/otaq/clima...
About 23% of that 19% is from heavy duty vehicles (so 18 wheelers etc are responsible for 4.37% of all MMGG), which means that all the millions of family cars on the road are actually only responsible for 14.6%. Clearly we need to target electricity generation (31%) and industry (21%) long before just beating up on car drivers more.
It seems clear that the set top box is basically just a signal converter used so the cable company can exploit customers further. Its clearly not anything you technically need, since OTA proves that multiple channels of digital TV can go through the air and over existing coax just fine (QAM), and all tvs I've ever seen on sale still come with a digital tuner.
Instead of coming up with a law to make cable boxes more interchangeable or whatever, they should make the law so that it eliminates them entirely. Apart from anything else, think of the energy and other waste savings.
You can call me a Developer, Programmer, Software Engineer, whatever you want, but I draw the line at "Coder". That totally trivialises what most of us actually do, unless youâ(TM)re a data entry typist or something.
What happens when you want to watch a movie and you're somewhere without internet? What happens if you do ever want to watch the same movie more than once? do you pay again? Work out your TRUE cost of streaming, e.g you might be paying cable internet just so you can stream, as well as your netflix plan over say 10 years, and suddenly my approach doesn't look so bad.
Of course it is very advantageous if you're the seller, but all I can see are the extra risks, inconvenience and cost to consumers of buying stuff that you never get a local copy of, so you have to stream online each time you play it.
It completely boggles my mind why anyone would give good money for that, vs buying media that you can e.g. download DRM-free copies of, or media you can (legally thanks to fair use) rip local copies from.
Ok well if the state HAS to employ them, then instead of them being a pointless bottleneck at airports that actually inconveniences people, at least have them doing something actually productive that makes people's day better, like picking up garbage on highways or whatever.
Since their inception the TSA has been repeatedly proven to be almost completely ineffective at prevention, yet there has been no US planes hijacked or blown up since their inception anyway. This alone proves that any benefit to the TSA's existence is entirely imaginary because the threat is not real. The TSA were originally created as a perhaps understandable but nevertheless paranoid and ill-informed kneejerk overreaction to 9/11. We need to simply fix that mistake now. There is clearly no rational reason for the TSA to continue to exist, especially since they cost the taxpayer 7.9 Billion USD every year that could be spent elsewhere solving problems that actually exist.
>> Hell put one under the stamp on a letter to yourself at your destination.
Physically mailing storage? really? why wouldn't you just encrypt it and copy it (scp or whatever) to some server then pick it up when you get wherever you're going? If you're paranoid about cloud storage (which is probably quite reasonable) just run your own server at home.
If for no other reason, it would be great to finally kill the accepted protocol that buying a car needs to take several hours sat at the dealer's desk doin god knows what, or that you should pay them literally hundreds of dollars on top of the purchase price just for the privilege of having them sell you the car and doing their own damn paperwork.
Its a ridiculous example because there's no situation where you'd ever actually write code that looked like that in real life. You're basically showing me a collapsing wooden house built on shifting sand then asking me to show you a better engineered way to apply the duct tape that keeps it together than you used. That said, rather than ever use gotos I'd find the cleanest, simplest way to use conditionals that test previous results. whether I'd use a variable to hold status and then test it, or wheter I'd just test the return value directly would be a decision based on what keeps it most clear/simple. I can tell you from first-hand experience that whether you think its good or not, any code with any gotos in it at all wouldn't ever pass certification by the FAA so would never be allowed into an aircraft, for example.
...also another issue with functions that return pointers to memory they allocate themselves is that it can play havoc in multi threaded systems, especially if it is in a windows DLL.
That makes no sense. Why are you mallocing at all? It would go on the stack. In which case that whole thing collapses to: int func (void)
{ char one[SOME_MAX], two[SOME_MAX], three[SOME_MAX]; return (foo( one)) && (bar(one,two)) && (baz(one,two,three)) ? 0 : -1; }
I agree that its using an idiom dating from the early days of Unix that some functions (most notably in the STDC library, such as strdup) still use, but thats mostly because not so many people knew better back in the day when strdup was written, and no-one can change the interface to any standard C functions because it would break just about every existing application out there. Just because its used in functions in the C library and been around forever does not mean its a good idom to move forward on, or that we should keep doing it in new code. One example of some acknowledgement of how the STDC library is not some unquestionable authority on programming excellence is how functions like strcpy got (almost) fixed with the later addition of safer alternatives such as strncpy(). The reality is that mallocing memory in a function then returning a pointer to it is undeniably FAR more prone to all sorts of problems (such as memory leaks) than having the caller provide the memory. It also goes against pretty much all modern software engineering principles and in my experience many company coding standards. Argument about whether some "BTW dont forget to free teh return value" comment in the header file is sufficient to somehow make everyone never forget to actually do it, or to ever make it an acceptably good idiom to use is subjective therefore pointless. What isn't subjective is that idom can also easily result in less flexible and efficient code. Example: Say I wanted the result of xstr_cat() to go into a memory structure I already had, such as a member of a struct. My way you can just directly provide a pointer to the element to xstr_cat. The existing way unavoidably causes a temporary copy to get malloced on the heap, which you'd then need to explicitly copy into the struct, and then remember to explicitly free the temporary copy you got back, or your app will have a memory leak. Any argument that the idiom used by xstr_cat() in your example results in a better approach than passing in a pointer to an existing buffer seems to be pretty much indefensible, regardless of how much code already does that.
That is a perfect example of what I said earlier about such things pointing to a deeper problem. In this case, its taht xstr_cat() is allocating memory then returning a pointer to it, so expecting/requiring the caller to know to clean up after, but only if the function worked. A much better approach is for xstr_cat to require the user to pass in memory for the function to fill. Apart from the classical arguments about not breaking encapsulation and avoiding situations with implied responsibility, it would also make the cleanup in the calling code less conditional, so would simplify that code too.
...and the real trouble with gotos/breaking out of loops early is that its not so easily scaleable or changeable, and there are often hidden edge cases.
Slashdot Mirror
up next: an app for your phone that interacts with all the crap they try to make you watch before they show you any content, then beeps to let you know the actual content is starting.
I think the fact that reviewers fail to mention obvious bugs is:
1) unethical
2) Proof of how widespread the control/corruption of these reviewers by the game companies is.
3) If it already isnt, it should be illegal if reviewers misrepresent themselves as being an independent authority/in a position of trust that puts consumers interests first, as we look to these people for advise on spending wisely. Them being complicit in what amounts to misrepresenting and misadvertising a product is clearly fraudulent.
Just because they are reviewing a pre-release version is no excuse either, they should still mention the bugs but then say its still in beta or whatever, not just pretend it didn't happen.
I know Bethesda has a long history of releasing very buggy games, but expecting all consumers to necessarily know that and make a judgement before buying the product is unreasonable.
If you were reviewing any other product (say a car) and it failed in some way, of course you'd mention it. I don't go along with the apparently common sheep-like misconception that software somehow gets a magic get-out-of-jail card, so that when we buy a clearly substandard product its somehow now the consumers responsibility to just suck it up and accept crap for good money.
your comments, while interesting, don't come close to addressing the point.
The question being asked here is, is it ethical for reviewers to not mention that a bunch of bugs exist in the game they are reviewing? I would say hell no.
Are you saying that you haven't personally encountered any bugs?
Maybe you should respond to what I *actually* wrote instead of responding to your own incorrect assumption that I didn't read or understand what he wrote.
The numbers I gave I were for all greenhouse gasses emitted, not just Co2
>> We all know the oil reserves will be severely depleted by 50 years from now
Whatever. I can quite distinctly remember back in the 1980's that they were predicting that oil would run out by about 5 years ago now.
but burning coal has far worse greenhouse emissions than burning gasoline, so its not a level playing field.
I agree that moving away from IC engines would be good for the enviironment, and I agree that motor vehicles are a significant contributor to human-caused emissions of greenhouse gasses, but lets get this into persspective:
The entire transportation sector only accounts for about 27% of the total man-made greenhouse gas (MMGG) emissions:
http://www3.epa.gov/climatecha...
Of that 27%, Road transport accounts for 72%,
http://www3.epa.gov/climatecha...
the rest is aviation and marine. That means about 19% of all MMGG is road vehicles.
From http://www3.epa.gov/otaq/clima...
About 23% of that 19% is from heavy duty vehicles (so 18 wheelers etc are responsible for 4.37% of all MMGG), which means that all the millions of family cars on the road are actually only responsible for 14.6%.
Clearly we need to target electricity generation (31%) and industry (21%) long before just beating up on car drivers more.
It seems clear that the set top box is basically just a signal converter used so the cable company can exploit customers further. Its clearly not anything you technically need, since OTA proves that multiple channels of digital TV can go through the air and over existing coax just fine (QAM), and all tvs I've ever seen on sale still come with a digital tuner.
Instead of coming up with a law to make cable boxes more interchangeable or whatever, they should make the law so that it eliminates them entirely. Apart from anything else, think of the energy and other waste savings.
You can call me a Developer, Programmer, Software Engineer, whatever you want, but I draw the line at "Coder". That totally trivialises what most of us actually do, unless youâ(TM)re a data entry typist or something.
What happens when you want to watch a movie and you're somewhere without internet? What happens if you do ever want to watch the same movie more than once? do you pay again?
Work out your TRUE cost of streaming, e.g you might be paying cable internet just so you can stream, as well as your netflix plan over say 10 years, and suddenly my approach doesn't look so bad.
Of course it is very advantageous if you're the seller, but all I can see are the extra risks, inconvenience and cost to consumers of buying stuff that you never get a local copy of, so you have to stream online each time you play it.
It completely boggles my mind why anyone would give good money for that, vs buying media that you can e.g. download DRM-free copies of, or media you can (legally thanks to fair use) rip local copies from.
Ok well if the state HAS to employ them, then instead of them being a pointless bottleneck at airports that actually inconveniences people, at least have them doing something actually productive that makes people's day better, like picking up garbage on highways or whatever.
Since their inception the TSA has been repeatedly proven to be almost completely ineffective at prevention, yet there has been no US planes hijacked or blown up since their inception anyway.
This alone proves that any benefit to the TSA's existence is entirely imaginary because the threat is not real.
The TSA were originally created as a perhaps understandable but nevertheless paranoid and ill-informed kneejerk overreaction to 9/11. We need to simply fix that mistake now.
There is clearly no rational reason for the TSA to continue to exist, especially since they cost the taxpayer 7.9 Billion USD every year that could be spent elsewhere solving problems that actually exist.
This seems entirely contradictory to their stance on Assange.
I wonder why.
>> Hell put one under the stamp on a letter to yourself at your destination.
Physically mailing storage? really? why wouldn't you just encrypt it and copy it (scp or whatever) to some server then pick it up when you get wherever you're going?
If you're paranoid about cloud storage (which is probably quite reasonable) just run your own server at home.
If for no other reason, it would be great to finally kill the accepted protocol that buying a car needs to take several hours sat at the dealer's desk doin god knows what, or that you should pay them literally hundreds of dollars on top of the purchase price just for the privilege of having them sell you the car and doing their own damn paperwork.
>> even the government wants permission to un "DRM" our devices
Err wait... what makes you think they're actually concerned with seeking permission first now?
Its a ridiculous example because there's no situation where you'd ever actually write code that looked like that in real life.
You're basically showing me a collapsing wooden house built on shifting sand then asking me to show you a better engineered way to apply the duct tape that keeps it together than you used.
That said, rather than ever use gotos I'd find the cleanest, simplest way to use conditionals that test previous results. whether I'd use a variable to hold status and then test it, or wheter I'd just test the return value directly would be a decision based on what keeps it most clear/simple.
I can tell you from first-hand experience that whether you think its good or not, any code with any gotos in it at all wouldn't ever pass certification by the FAA so would never be allowed into an aircraft, for example.
...also another issue with functions that return pointers to memory they allocate themselves is that it can play havoc in multi threaded systems, especially if it is in a windows DLL.
sorry, too many braces in last line. should look like this:
return (foo( one) && bar(one,two) && baz(one,two,three)) ? 0 : -1;
That makes no sense. Why are you mallocing at all? It would go on the stack. In which case that whole thing collapses to:
int func (void)
{
char one[SOME_MAX], two[SOME_MAX], three[SOME_MAX];
return (foo( one)) && (bar(one,two)) && (baz(one,two,three)) ? 0 : -1;
}
I agree that its using an idiom dating from the early days of Unix that some functions (most notably in the STDC library, such as strdup) still use, but thats mostly because not so many people knew better back in the day when strdup was written, and no-one can change the interface to any standard C functions because it would break just about every existing application out there. Just because its used in functions in the C library and been around forever does not mean its a good idom to move forward on, or that we should keep doing it in new code.
One example of some acknowledgement of how the STDC library is not some unquestionable authority on programming excellence is how functions like strcpy got (almost) fixed with the later addition of safer alternatives such as strncpy().
The reality is that mallocing memory in a function then returning a pointer to it is undeniably FAR more prone to all sorts of problems (such as memory leaks) than having the caller provide the memory. It also goes against pretty much all modern software engineering principles and in my experience many company coding standards. Argument about whether some "BTW dont forget to free teh return value" comment in the header file is sufficient to somehow make everyone never forget to actually do it, or to ever make it an acceptably good idiom to use is subjective therefore pointless.
What isn't subjective is that idom can also easily result in less flexible and efficient code. Example:
Say I wanted the result of xstr_cat() to go into a memory structure I already had, such as a member of a struct. My way you can just directly provide a pointer to the element to xstr_cat.
The existing way unavoidably causes a temporary copy to get malloced on the heap, which you'd then need to explicitly copy into the struct, and then remember to explicitly free the temporary copy you got back, or your app will have a memory leak.
Any argument that the idiom used by xstr_cat() in your example results in a better approach than passing in a pointer to an existing buffer seems to be pretty much indefensible, regardless of how much code already does that.
That is a perfect example of what I said earlier about such things pointing to a deeper problem.
In this case, its taht xstr_cat() is allocating memory then returning a pointer to it, so expecting/requiring the caller to know to clean up after, but only if the function worked.
A much better approach is for xstr_cat to require the user to pass in memory for the function to fill.
Apart from the classical arguments about not breaking encapsulation and avoiding situations with implied responsibility, it would also make the cleanup in the calling code less conditional, so would simplify that code too.
...and the real trouble with gotos/breaking out of loops early is that its not so easily scaleable or changeable, and there are often hidden edge cases.