I agree but in that case a lot of this stuff needs to be in the GUI APIs and the applications need to be coded for that. For e.g. you cant use 'pixel' units to describe on-screen elements and where they are placed. Windows has had this DPI scaling thing and whenever I've tried using it - it always fucks up most apps since they aren't aware of the change.
Tiny text is avoidable. There are dozens of existing font rendering systems that scale fonts so that they remain the same size no matter what the resolution/screen size. Higher resolution in that case would just make the text crisper.
They do not haggle with you or give you grief about HOW broken something is, they err on the side of YOU being happy.
Well.. They did not replace my nano touch, when it got damaged. They said it was "water" damage and hence not replaceable/repairable. It was like 2 weeks old at that time. I did use it for jogging a couple of times, but I hardly thing that's outside normal operating conditions. OTOH, they did replace the DVD drive on my 06 MBP for free, so I guess eventually it balances out:P
Hmm, I actually enjoyed KoA. For me, it was more entertaining than something like Assassins Creed where apart from the first one, I just felt completely ripped off for each successive sequel.
As we've seen with past colonization efforts, laws are not exactly "laws". Atleast with the mexicans they aren't coming here to 'take our land' or 'kill/displace the existing populace'. They're just looking to escape poverty and build a better life for themselves. Its only the most natural evolution-driven thing to want to do that.
They are arbitrary checks for randomly selected egregious mistakes. Passing tests lulls developers into thinking that their software works correctly when it really does not.
That is the way/YOU/ see tests. Most people use them to verify that very rule that you're talking about. Testing is not some random code that people throw together. It can be just as carefully written and as planned, if not more, than the actual software being tested.
Why not? For tests to be meaningful, the difficulty of writing them well exceeds the difficulty of writing formally-proven software. Step down from there, and sufficiently careful logical thinking (a step down from formal proof) will always beat an informal test (a step down from complete test) made with the same level of effort.
The development of tests can be done with multiple smart people. They can divide up the program however they want and implement tests for it. This is impossible with formal proof. Without a several iterations you will be unable to even divide up the code the be formally analyzed in parallel. Tests will always be a faster and commercially more superior solution.
Practice shows that they do not improve quality, they teach people to write software that passes tests, and not think about the whole range of possible situations it has to deal with.
Then that means those people sucks at writing tests.
So the purpose of tests is to create an impression of "proof" to people who don't know any better?
Depends on what you're doing. For a large softwares like Windows there are thousands of outstanding bugs and 90% of the users would not even recognize those bugs. Software will still be shipped and the bugs can be addressed in future updates. If you want a zero bug criteria then no software will ever ship on time. And all the companies will go bankrupt because there is no supply of software developers who are able to write that kind of software.
The better are programmers, the least helpful are tests, and long before programmers become perfect, tests become worthless.
This will never happen. Currently majority of software developers are employed by commercial companies. Their aim is to improve profit, not to make their employees better developer. Sometimes those two things can align because higher quality code means more profit, but that happens only a minority of the time. The other large section of software developers will be in academia. They have no clue about software development. They have never shipped anything robust because they have such low number of users that every code path is never tested in their code.
So basically you want people to improve the quality of their code base, without actually giving them any concrete and practical way to measure the quality? Also why, are you ranting? No-one in this thread has claimed that tests are some kind of silver bullet. They are an important indicator - as objective as humanly possible - within reasonable constraints of day-to-day software development (we are not talking about NASA level quality and formal proofs and all that crap) - that can be useful in enforcing that software is designed & implemented to be robust, and relatively bug-free.
Also you are wrong that tests cannot guarantee anything. When a human guarantees something to another human it is assumed to not be some kind of absolute statement. This *is* the common use (legal and general) of the term. Because otherwise you need some kind of perfect god like being which can evaluate products/services.
There should be no tests. There should be a rule that disables all debugging output in production builds. And, of course, all debugging output should use the mechanism that disables output with aforementioned rule.
What are you disagreeing with?
Testing is for finding out if you have screwed up. Quality comes not from testing but from not screwing up.
That is such a meaningless statement. Thats like saying programming is the process of introducing bugs in the codebase. Only after you write tests can you claim any such quality of code base. If quality does not come from testing then it does not exist other than in a programmers subjective opinions.
Although I'm not particularly a fan of Test Driven Development, you could have created some sort of 'debug flag disabled in release build' test the moment you decided to log passwords in clear text. You can even create a general rule like "Everytime you decided to weaken security for debugging purposes you should create a test that confirms this code will not be included in the release build". But yeah, without knowing much about their build process, its just pure speculation at this point and anyone can tell you how this problem can be avoided in hindsight.
But regarding tests, there are various useful tests that can test previously unknown program states. Especially stuff like fault injection testing is incredibly useful. In fact many security researchers find tons of tricky bugs using these techniques. for e.g. send randomized input strings to test for reliability of API interfaces which accept arbitrary strings, or you can use a test suite that 'randomly' makes the system go Out Of Memory to see how different services deal with it reliably, etc.
Well, believe it or not, there is actually a valid reason for the reboot. Any executable code running in memory is typically not patched by most operating systems. They will update the file stored in the filesystem but not the executable code already loaded in memory. For e.g. Shared libraries loaded in memory with ASLR and other OS protections will be untouched. (And no, KSplice is not even remotely relevant here). This means that you are at a risk of running a vulnerable piece of code. Real bad news if you're a server process that has to handle a ton of potentially unsafe external data.
Even otherwise, I wish MS would create some general infrastructure that software developers could plug into to update their software. They already have an OS component that is capable of dependency checks and other stuff, but they only use it for their OS updates and service packs. It will be used by small dev shops that will find it easy to let someone else manage updates, but a lot of big companies would not use it. So many of them use their shitty updaters to show advertisements for new products and as a way to bundle some toolbar or other unwanted crap. Oh.. and thats not even taking into account the shit tray apps and other BS they install during the first install. Sigh.. the windows world is a mess, its too late to fix it now IMO.
Well, that pretty much failed. Most PC games target Windows XP. Sure you can find a handful that use the newer DX features and wont work on XP, but AFAICT they are not statistically relevant.
Yes and no. I do not think anyone will doubt that Apple has been ahead in the material sciences part of the design phase. Manufacturing the iDevices they way they do is definitely not easy - sure *now* it may be trivial for others to make something similar (material compound wise) but when Apple first started manufacturing the iPhones/iPods/Macbooks.. it was not easy . I'm not even claiming that everything they did was 100% created by Apple. Often times they buy other companies and gain manufacturing expertise.
Sure if you go by electronics components, they get them from other suppliers and everybody has access to those. That is not anything special.
Take the minimum amount of screen size required for a 1:1 output of a display with the maximum amount of pixel density that the eye can manage to see. If the screen is bigger than the area, (which it always is), it is possible to differentiate and enjoy the improvement between low and high-res display. For e.g. At the pixel density of the iPad3 a DVD vs BluRay comparison on an iPad1 vs iPad3 will be a handsdown win for the iPad3. I have the Sony VPCZ2 laptop - 1920x1080 display on a 13" screen and its fricking gorgeous. When I use my 15" MacBook Pro at 1400x900 it feels like going back a generation.
Well Steve Jobs said it himself at the launch of the iphone. I'm not convinced that someone like jobs who takes great efforts in preparing for these events in detail did not know that the way he said it could be misinterpreted.
You're assuming getting something to compile and run is the equivalent of it working acceptably - either visually or raw performance wise. AAA game titles always have special code design considerations when working on different H/W architectures.
The rendering calls can be very simply ported from one API to another. Its actually.. the simplest part of the porting effort. (BTW PS3 and Wii are specifically *NOT* OpenGL. Wii uses GX which is similar but not the same. The PS3 'supports' non-standard OpenGL called PSGL, but nobody uses that in actual games)
But.. what you think is 'common' code between platforms is actually the most difficult to unify and it is where the majority of the resources are expended.
Actually.. you used an incorrect analogy. Right to life is an internationally accepted right. In fact if any individual government violates it, there could be severe sanctions from the other nations. Well unless you are from a country that is not part of the UN...
I think most of the comments on slashdot will have a net-zero effect on the PC game business. The problem here is that majority of the people don't and will never think of the bigger issues with respect to unfair EULAs and single-use DLC codes.
That code might be OK for small use cases, but it is very fragile. Depending on the language used I would consider implementing transaction semantics where the failure mode implies undoing of any transactions prior to the commit.
So then how come negative "opinions" on linux are modded as troll ? Do you call that "shilling" for commercial linux companies? Its easy to ignore bias if you already agree with that position.
Yeah, those stupid horses cause all the stupid pollution anyway, and they keep using up all the oil that fuels geo-political instability in the middle-east:-P
Well google instant used to be opt-in too, now its on by default... You need to remain signed in with an opt-out setting enabled to keep it turned off permanently.
Slashdot Mirror
Why? Couldn't you just encrypt the HDD?
Sorry, but Windows has phoned home for at least 10 years, and sent data without user knowledge to 3rd party companies that could be traced to MS.
Sorry but what data have they collected without your consent? Are you talking about checking to see if you have a valid copy?
I agree but in that case a lot of this stuff needs to be in the GUI APIs and the applications need to be coded for that. For e.g. you cant use 'pixel' units to describe on-screen elements and where they are placed. Windows has had this DPI scaling thing and whenever I've tried using it - it always fucks up most apps since they aren't aware of the change.
Tiny text is avoidable. There are dozens of existing font rendering systems that scale fonts so that they remain the same size no matter what the resolution/screen size. Higher resolution in that case would just make the text crisper.
They do not haggle with you or give you grief about HOW broken something is, they err on the side of YOU being happy.
Well.. They did not replace my nano touch, when it got damaged. They said it was "water" damage and hence not replaceable/repairable. It was like 2 weeks old at that time. I did use it for jogging a couple of times, but I hardly thing that's outside normal operating conditions. OTOH, they did replace the DVD drive on my 06 MBP for free, so I guess eventually it balances out :P
Hmm, I actually enjoyed KoA. For me, it was more entertaining than something like Assassins Creed where apart from the first one, I just felt completely ripped off for each successive sequel.
As we've seen with past colonization efforts, laws are not exactly "laws". Atleast with the mexicans they aren't coming here to 'take our land' or 'kill/displace the existing populace'. They're just looking to escape poverty and build a better life for themselves. Its only the most natural evolution-driven thing to want to do that.
Hmm.. but can't all of those be jammed too? Or is there some kind of reliable indicator?
They are arbitrary checks for randomly selected egregious mistakes. Passing tests lulls developers into thinking that their software works correctly when it really does not.
That is the way /YOU/ see tests. Most people use them to verify that very rule that you're talking about. Testing is not some random code that people throw together. It can be just as carefully written and as planned, if not more, than the actual software being tested.
Why not? For tests to be meaningful, the difficulty of writing them well exceeds the difficulty of writing formally-proven software. Step down from there, and sufficiently careful logical thinking (a step down from formal proof) will always beat an informal test (a step down from complete test) made with the same level of effort.
The development of tests can be done with multiple smart people. They can divide up the program however they want and implement tests for it. This is impossible with formal proof. Without a several iterations you will be unable to even divide up the code the be formally analyzed in parallel. Tests will always be a faster and commercially more superior solution.
Practice shows that they do not improve quality, they teach people to write software that passes tests, and not think about the whole range of possible situations it has to deal with.
Then that means those people sucks at writing tests.
So the purpose of tests is to create an impression of "proof" to people who don't know any better?
Depends on what you're doing. For a large softwares like Windows there are thousands of outstanding bugs and 90% of the users would not even recognize those bugs. Software will still be shipped and the bugs can be addressed in future updates. If you want a zero bug criteria then no software will ever ship on time. And all the companies will go bankrupt because there is no supply of software developers who are able to write that kind of software.
The better are programmers, the least helpful are tests, and long before programmers become perfect, tests become worthless.
This will never happen. Currently majority of software developers are employed by commercial companies. Their aim is to improve profit, not to make their employees better developer. Sometimes those two things can align because higher quality code means more profit, but that happens only a minority of the time. The other large section of software developers will be in academia. They have no clue about software development. They have never shipped anything robust because they have such low number of users that every code path is never tested in their code.
So basically you want people to improve the quality of their code base, without actually giving them any concrete and practical way to measure the quality? Also why, are you ranting? No-one in this thread has claimed that tests are some kind of silver bullet. They are an important indicator - as objective as humanly possible - within reasonable constraints of day-to-day software development (we are not talking about NASA level quality and formal proofs and all that crap) - that can be useful in enforcing that software is designed & implemented to be robust, and relatively bug-free.
Also you are wrong that tests cannot guarantee anything. When a human guarantees something to another human it is assumed to not be some kind of absolute statement. This *is* the common use (legal and general) of the term. Because otherwise you need some kind of perfect god like being which can evaluate products/services.
No.
There should be no tests. There should be a rule that disables all debugging output in production builds. And, of course, all debugging output should use the mechanism that disables output with aforementioned rule.
What are you disagreeing with?
Testing is for finding out if you have screwed up. Quality comes not from testing but from not screwing up.
That is such a meaningless statement. Thats like saying programming is the process of introducing bugs in the codebase. Only after you write tests can you claim any such quality of code base. If quality does not come from testing then it does not exist other than in a programmers subjective opinions.
Although I'm not particularly a fan of Test Driven Development, you could have created some sort of 'debug flag disabled in release build' test the moment you decided to log passwords in clear text. You can even create a general rule like "Everytime you decided to weaken security for debugging purposes you should create a test that confirms this code will not be included in the release build". But yeah, without knowing much about their build process, its just pure speculation at this point and anyone can tell you how this problem can be avoided in hindsight.
But regarding tests, there are various useful tests that can test previously unknown program states. Especially stuff like fault injection testing is incredibly useful. In fact many security researchers find tons of tricky bugs using these techniques. for e.g. send randomized input strings to test for reliability of API interfaces which accept arbitrary strings, or you can use a test suite that 'randomly' makes the system go Out Of Memory to see how different services deal with it reliably, etc.
Well, believe it or not, there is actually a valid reason for the reboot. Any executable code running in memory is typically not patched by most operating systems. They will update the file stored in the filesystem but not the executable code already loaded in memory. For e.g. Shared libraries loaded in memory with ASLR and other OS protections will be untouched. (And no, KSplice is not even remotely relevant here). This means that you are at a risk of running a vulnerable piece of code. Real bad news if you're a server process that has to handle a ton of potentially unsafe external data.
Even otherwise, I wish MS would create some general infrastructure that software developers could plug into to update their software. They already have an OS component that is capable of dependency checks and other stuff, but they only use it for their OS updates and service packs. It will be used by small dev shops that will find it easy to let someone else manage updates, but a lot of big companies would not use it. So many of them use their shitty updaters to show advertisements for new products and as a way to bundle some toolbar or other unwanted crap. Oh .. and thats not even taking into account the shit tray apps and other BS they install during the first install. Sigh.. the windows world is a mess, its too late to fix it now IMO.
dammit ! my firstname@yahoo account which I created in 1996 just became un-cool :P
Much like Vista and DirectX.
Well, that pretty much failed. Most PC games target Windows XP. Sure you can find a handful that use the newer DX features and wont work on XP, but AFAICT they are not statistically relevant.
Yes and no. I do not think anyone will doubt that Apple has been ahead in the material sciences part of the design phase. Manufacturing the iDevices they way they do is definitely not easy - sure *now* it may be trivial for others to make something similar (material compound wise) but when Apple first started manufacturing the iPhones/iPods/Macbooks.. it was not easy . I'm not even claiming that everything they did was 100% created by Apple. Often times they buy other companies and gain manufacturing expertise.
Sure if you go by electronics components, they get them from other suppliers and everybody has access to those. That is not anything special.
Take the minimum amount of screen size required for a 1:1 output of a display with the maximum amount of pixel density that the eye can manage to see. If the screen is bigger than the area, (which it always is), it is possible to differentiate and enjoy the improvement between low and high-res display. For e.g. At the pixel density of the iPad3 a DVD vs BluRay comparison on an iPad1 vs iPad3 will be a handsdown win for the iPad3. I have the Sony VPCZ2 laptop - 1920x1080 display on a 13" screen and its fricking gorgeous. When I use my 15" MacBook Pro at 1400x900 it feels like going back a generation.
it says that those saying the iPhone was running the stripped down OS X were either misinformed or very general with the phrase "stripped down".
http://www.youtube.com/watch?v=9VLb5XdxRm8#t=3m50s
Well Steve Jobs said it himself at the launch of the iphone. I'm not convinced that someone like jobs who takes great efforts in preparing for these events in detail did not know that the way he said it could be misinterpreted.
You're assuming getting something to compile and run is the equivalent of it working acceptably - either visually or raw performance wise. AAA game titles always have special code design considerations when working on different H/W architectures.
The rendering calls can be very simply ported from one API to another. Its actually.. the simplest part of the porting effort. (BTW PS3 and Wii are specifically *NOT* OpenGL. Wii uses GX which is similar but not the same. The PS3 'supports' non-standard OpenGL called PSGL, but nobody uses that in actual games)
But .. what you think is 'common' code between platforms is actually the most difficult to unify and it is where the majority of the resources are expended.
Actually.. you used an incorrect analogy. Right to life is an internationally accepted right. In fact if any individual government violates it, there could be severe sanctions from the other nations. Well unless you are from a country that is not part of the UN...
I think most of the comments on slashdot will have a net-zero effect on the PC game business. The problem here is that majority of the people don't and will never think of the bigger issues with respect to unfair EULAs and single-use DLC codes.
That code might be OK for small use cases, but it is very fragile. Depending on the language used I would consider implementing transaction semantics where the failure mode implies undoing of any transactions prior to the commit.
So then how come negative "opinions" on linux are modded as troll ? Do you call that "shilling" for commercial linux companies? Its easy to ignore bias if you already agree with that position.
Yeah, those stupid horses cause all the stupid pollution anyway, and they keep using up all the oil that fuels geo-political instability in the middle-east :-P
Well google instant used to be opt-in too, now its on by default... You need to remain signed in with an opt-out setting enabled to keep it turned off permanently.