Call it a programmer's intuition, or just calculating chances. If 100 games work on a system and 1 doesn't, there's a good chance it's something to do with the game.
This is the first assumption that you'd jump to, but there's no real evidence that it's true. Perhaps the "one game" simply uses more ram than the others, and thus hits a "faulty bit" in one of the ram chips. Perhaps the graphics drivers have an off-by-one condition that causes them to over-read a vertex buffer and into unallocated memory. Even on "identical" machines, this may not crash unless the application's allocations match an exact pattern that causes the bad read to touch an unmapped page. We've seen both of these in practice.
Sure, there are plenty of bugs - pretty much any software has some, and some software more than others, but it's fair to say that the "my machine is fine, it must be the software" mentality leads to some very poor conclusions from time to time, even though it's an understandable position for a user to take.
Now try and prove that the game is broken to a person for who it worked flawlessly for 3 whole run throughs. Good luck.
Yup, we certainly see some of this as well. Loyal users can sometimes be fast to jump on people reporting valid bugs.
I bought Mass Effect only to find out that the game simply does not run. My computer is as close to flawless as it could possibly get, it's been running for years and has successfully played many games with many different engines, I have done workarounds for crashes and bugs and all sorts of things, it's a tried and true PC.
Just an anecdote from the other side of the fence, and not saying this is necessarily your case. Certainly not defending Mass Effect, I've never tried the game personally.
We've had numerous users report serious defects in our products over many years, and faced all sorts of threats and insults, only for the fault to be eventually traced to the user's "tried and tested hardware." Each program that you may use exercises different components of your PC in different ways. Sometimes subtle differences can make a massive difference in results; the difference between working fine and not even starting up. Should the developer pay because you have some mildly faulty ram?
We've also seen vastly different behavior from hardware/drivers built to the same spec but sourced from different manufacturers, or from the same manufacturer but over different periods. Sometimes these deviations are within the spec but not covered by reasonable testing; often these deviations are outside the spec completely. Should the developer pay because one or more of your components do not follow the specs, or deviate significantly from what was standard practice at the time the software was developed?
As a user, I have to agree that it sucks when products don't work as advertised. I agree that there should be a mechanism for complaint against any vendor, whether their product be physical or virtual. But I'm not sure that I agree that there should be an absolute right of refund at the user's discretion. That's just open for abuse - whether deliberate or incidental.
I'm also not particularly fond of DRM and yet that would seem to be the only way that a vendor could offer true "returns" of a software-only product.
It's probably worth noting that I'm not claiming that all bugs are the user's fault; but it's certainly not the case that all bugs are the application developer's fault, either.
I would say it's pretty much lost steam already. If you take a function that can't exploit multiple cores, then the single core performance has not improved much in a while.
He's right though; the user cares about the response time between their action and the final result. They care about the time cost of transferring multiple packets just as much as they care about the time cost for the round trip. To optimize this, you can attack either:
* The round trip time (outside the reach of most users and companies.) * The number of round trips (may be open to tweaking by predicting which files will be requested as a group, etc.) * The quantity of data transferred. This tends to have less impact than the others for people on fast connections, but still adds up. For people on slower connections, this may be the largest factor.
Now, while Apple continues to sell slightly better than mediocre products for 10X what they're worth, on hype alone, I keep asking myself "Why?"
Which products were you referring to? I can think of a few of theirs that are a little exxy, but nothing like that much, and most of their products seem quite competitively priced. I can understand that people might want a configuration that Apple doesn't offer - and fair enough if that's you - but if you fall into one of their target markets, they're pretty hard to beat on price.
Unless you specifically set your keychain password to something other than your admin password this also means any password you store in there is compromised too.
This doesn't sound correct. As far as I'm aware, overriding the admin password will not grant access to keychain?
Regardless of the vanishingly small probability of a collision between two randomly chosen data blocks, I'd be concerned about using this system for two reasons:
* Unlike an encryption system, the same data is being stored on every disk. This means that once a single attack is found against a commonly occurring block, all systems are vulnerable. (This can be solved by salting each disk appropriately; they may already do this.)
* If a collision is found, nothing can be done about it (short of disabling the dedupe algorithm completely.) Reruns of a flawed program will be doomed to repeat the same mistakes, even after the operator is aware of the issue. This is far worse than any silent data corruption; it's effectively silent algorithm corruption.
This article is specifically about games, but the answer to your question is really "no". You need to use Objective C to access Apple's UI framework, and you'd be pretty silly to write a custom UI system for most non-game apps.
Your core application logic can still be C++ of course, but all of the actual application UI must be Objective C.
That said, I like C++ and dislike being forced to program in either Objective C or Java - but I'm honestly enjoying working in Objective C (and being able to fall back on my C++ ways from time to time where appropriate) rather than being stuck in Java. My only complaint is the difficulty in memory management in Objective C - it's alien enough that a C++ programmer will not automatically get it right, and really needs the garbage collection functionality that Apple added on the MacOS.
It's always interesting to guess at the future, but at my day job (definitely a Windows shop) everyone is buying Apple hardware and nobody even mentions Android. You may be right, but Google has a long march ahead of them.
More importantly perhaps, the iPhone does not actually force you to program in Obj-C. A very thin wrapper can be used to interface native C++ with the hardware. While Java may be friendly to mobile developers, C++ is definitely the language of choice for games developers.
I believe that Android has taken steps in this direction as well, but last I heard there were severe compatibility concerns. Anybody know whether this has gone anywhere useful?
You can run software through something like a theorem prover for something like memory leaks... proving something like "for any possible data input and every possible execution sequence, this program will ALWAYS correctly follow up every memory allocation with a matching command to free that memory".
Except that you can't. You can do this for very specific types of program, built in very specific ways or very specific languages. There are a much greater number of programs and languages for which this is not possible.
Don't get me wrong - I realize that you can describe a theoretical algorithm to achieve this, and it would not even be difficult to write a program to do this in any arbitrary language. It's just that the program would require near-infinite storage and time to run.
So as per my post, while it may be technically correct that programming is applied math, in practice this is like saying that my heart beating is applied particle physics. The reality is too far from the theory to be of any use in the general case.
Every algorithm and piece of software can be proven
Yes and no. That's my point. Theoretically speaking, yes. Practically speaking, no.
While each algorithm and piece and indeed the whole could theoretically be proven, it is not feasible to do so except in very trivial cases.
Once we reach the point where practice does not match theory, one questions the point of naming the practice after the theory. I'm not questioning the mathematical background or principles, but rather questioning the useful application of math to programming as a domain at the current time.
While you're technically correct, of course, I think that this attitude leads to some rather poor conclusions.
From the little I know of pure math (so correct me if I'm off-base here) I would suggest that 'proofs' are fundamental to the field. This is very definitely not the case in the majority of programming. If it was, we wouldn't need much testing, and there wouldn't really be bugs.
Your argument is that all programming is math when you get down to the single-instruction level, and that you can scale this up to cover the whole program. However once you reach the point where a program is complex to the point that it is impossible for our technology to prove, the result is certainly not what I'd consider math.
Your same logic could be applied to almost anything really. Break it down small enough, demonstrate it's math, therefore the whole must be math.
Maybe it's Apple-provided libs and dev tools that only create software that runs on the latest version of the OS? In this case, Apple does strongly encourage an upgrade by making your previous-version OS obsolete.
Nope. The tools allow you to select which set of headers and libraries you'd like to link against. The only technical reason for requiring a newer OS is to access new/fixed features.
I agree with your opinion of Theo. He rarely speaks up without cause. I do however think that many people have placed themselves on his bad side over the years, and they might disagree with your comments.
I'm not saying that Theo is a big angry bear, just that he doesn't tolerate crap. It's a sentiment that I agree with. I don't have any direct personal experience with either guy, but that sounds an awful lot like the glorious leader from TFA.
And Theo de Raadt is a bad leader? I agree that, all else being equal, a sociable leader is beneficial. But I'd gladly take an unsociable leader over one who is poor at management or technically.
WoW runs multiple instances quite fine even with a single install directory. You may need to launch the game directly rather than start through the launcher (haven't confirmed that) but we certainly have no trouble multiboxing from a single install.
What you say is true, but is also a very pessimistic viewpoint. I prefer to believe that the majority of people (politicians, developers, everyone) are actually trying to make things better. I'm sure that there are certainly notable exceptions.
Certainly, in games development, there is little incentive in developing overly buggy systems. Doing so repeatedly is more likely to get you fired as incompetent rather than have management ask you to spend additional time on the same tasks.
Regardless, that wasn't really my point - I'm just saying that such systems do not reach perfection. The whys and wherefores don't change that.
A fair analogy would be our legal system. While it serves us reasonably well for the most part, nobody would claim that is completely fair or that there are no loop-holes. Additionally, we have to keep adjusting in on a regular basis.
What makes you think that a handful of game devs will "get it right" where thousands of lawyers and politicians over the years have tried and are still trying?
There is no such thing as absolute balance. There are always loopholes. I have no experience with CoH so I can't say whether their implementation stinks or whether it's amazing, but I think it's fair to say that expecting anything approaching perfection is unreasonable.
I'd have to agree with GP - this really is a marketing term. As you correctly note, overclocking implies that the part is unreliable. I doubt that any large business is going to deliberately risk the high rate of returns that would be associated with shipping an unreliable part. IANAL, but I doubt that "it's sold overclocked!" is going to get you out of honoring a warranty of merchantability or fitness.
While they may indeed be up-clocking a standard part, and then improving cooling and so on, you can be sure that they will have also performed an extensive reliability analysis on the new hardware. If you're saying this is being done at the "Factory" then the normal meaning of "overclocked" doesn't apply.
How can this gadget be compared to Kindle? The most important feature Kindle sports is its e-paper display, while the Apple gizmo uses an ordinary LCD screen with touch function.
IOW, Kindle is a document reader, while this thing is another hyped i-something - we're talking about oranges and apple(s) here.
In what meaningful way is a Kindle a "Document Reader" and an i-something not?
* The Kindle lacks other functions - okay, so it's a dedicated "Document Reader" as opposed to being a multifunction device.
* It has an e-paper display - okay, so it gets better battery life, and is arguably easier to work with if you happen to be outside.
While I wouldn't disagree with you saying that the Kindle is a better dedicated document reader, the fact that an i-something saves you carrying around a second device trumps the other concerns for me. I certainly have no troubles using an iPhone to read books.
Carbon is the API abstraction layer; Classic was very much a VM - you even got to watch MacOS 9 boot in a window prior to any Classic application being loaded.
http://en.wikipedia.org/wiki/Classic_(Mac_OS_X)
Classic was only a VM and not an emulator, which is why the Intel chips are not supported.
Surely this logic fails simply because the total amount of money (or time, or interest, or whatever you'd like to measure as a cost) is roughly constant - so for a given product to become more popular, other products must become less popular.
Slashdot Mirror
Call it a programmer's intuition, or just calculating chances. If 100 games work on a system and 1 doesn't, there's a good chance it's something to do with the game.
This is the first assumption that you'd jump to, but there's no real evidence that it's true. Perhaps the "one game" simply uses more ram than the others, and thus hits a "faulty bit" in one of the ram chips. Perhaps the graphics drivers have an off-by-one condition that causes them to over-read a vertex buffer and into unallocated memory. Even on "identical" machines, this may not crash unless the application's allocations match an exact pattern that causes the bad read to touch an unmapped page. We've seen both of these in practice.
Sure, there are plenty of bugs - pretty much any software has some, and some software more than others, but it's fair to say that the "my machine is fine, it must be the software" mentality leads to some very poor conclusions from time to time, even though it's an understandable position for a user to take.
Now try and prove that the game is broken to a person for who it worked flawlessly for 3 whole run throughs. Good luck.
Yup, we certainly see some of this as well. Loyal users can sometimes be fast to jump on people reporting valid bugs.
I bought Mass Effect only to find out that the game simply does not run. My computer is as close to flawless as it could possibly get, it's been running for years and has successfully played many games with many different engines, I have done workarounds for crashes and bugs and all sorts of things, it's a tried and true PC.
Just an anecdote from the other side of the fence, and not saying this is necessarily your case. Certainly not defending Mass Effect, I've never tried the game personally.
We've had numerous users report serious defects in our products over many years, and faced all sorts of threats and insults, only for the fault to be eventually traced to the user's "tried and tested hardware." Each program that you may use exercises different components of your PC in different ways. Sometimes subtle differences can make a massive difference in results; the difference between working fine and not even starting up. Should the developer pay because you have some mildly faulty ram?
We've also seen vastly different behavior from hardware/drivers built to the same spec but sourced from different manufacturers, or from the same manufacturer but over different periods. Sometimes these deviations are within the spec but not covered by reasonable testing; often these deviations are outside the spec completely. Should the developer pay because one or more of your components do not follow the specs, or deviate significantly from what was standard practice at the time the software was developed?
As a user, I have to agree that it sucks when products don't work as advertised. I agree that there should be a mechanism for complaint against any vendor, whether their product be physical or virtual. But I'm not sure that I agree that there should be an absolute right of refund at the user's discretion. That's just open for abuse - whether deliberate or incidental.
I'm also not particularly fond of DRM and yet that would seem to be the only way that a vendor could offer true "returns" of a software-only product.
It's probably worth noting that I'm not claiming that all bugs are the user's fault; but it's certainly not the case that all bugs are the application developer's fault, either.
I would say it's pretty much lost steam already. If you take a function that can't exploit multiple cores, then the single core performance has not improved much in a while.
Moore's law does not describe performance.
He's right though; the user cares about the response time between their action and the final result. They care about the time cost of transferring multiple packets just as much as they care about the time cost for the round trip. To optimize this, you can attack either:
* The round trip time (outside the reach of most users and companies.)
* The number of round trips (may be open to tweaking by predicting which files will be requested as a group, etc.)
* The quantity of data transferred. This tends to have less impact than the others for people on fast connections, but still adds up. For people on slower connections, this may be the largest factor.
Now, while Apple continues to sell slightly better than mediocre products for 10X what they're worth, on hype alone, I keep asking myself "Why?"
Which products were you referring to? I can think of a few of theirs that are a little exxy, but nothing like that much, and most of their products seem quite competitively priced. I can understand that people might want a configuration that Apple doesn't offer - and fair enough if that's you - but if you fall into one of their target markets, they're pretty hard to beat on price.
Unless you specifically set your keychain password to something other than your admin password this also means any password you store in there is compromised too.
This doesn't sound correct. As far as I'm aware, overriding the admin password will not grant access to keychain?
Regardless of the vanishingly small probability of a collision between two randomly chosen data blocks, I'd be concerned about using this system for two reasons:
* Unlike an encryption system, the same data is being stored on every disk. This means that once a single attack is found against a commonly occurring block, all systems are vulnerable. (This can be solved by salting each disk appropriately; they may already do this.)
* If a collision is found, nothing can be done about it (short of disabling the dedupe algorithm completely.) Reruns of a flawed program will be doomed to repeat the same mistakes, even after the operator is aware of the issue. This is far worse than any silent data corruption; it's effectively silent algorithm corruption.
This article is specifically about games, but the answer to your question is really "no". You need to use Objective C to access Apple's UI framework, and you'd be pretty silly to write a custom UI system for most non-game apps.
Your core application logic can still be C++ of course, but all of the actual application UI must be Objective C.
That said, I like C++ and dislike being forced to program in either Objective C or Java - but I'm honestly enjoying working in Objective C (and being able to fall back on my C++ ways from time to time where appropriate) rather than being stuck in Java. My only complaint is the difficulty in memory management in Objective C - it's alien enough that a C++ programmer will not automatically get it right, and really needs the garbage collection functionality that Apple added on the MacOS.
It's always interesting to guess at the future, but at my day job (definitely a Windows shop) everyone is buying Apple hardware and nobody even mentions Android. You may be right, but Google has a long march ahead of them.
More importantly perhaps, the iPhone does not actually force you to program in Obj-C. A very thin wrapper can be used to interface native C++ with the hardware. While Java may be friendly to mobile developers, C++ is definitely the language of choice for games developers.
I believe that Android has taken steps in this direction as well, but last I heard there were severe compatibility concerns. Anybody know whether this has gone anywhere useful?
IRC pushes. The only reason you would use a 'pull' for something like this is if the client can't maintain a persistent connection to a server.
You can run software through something like a theorem prover for something like memory leaks... proving something like "for any possible data input and every possible execution sequence, this program will ALWAYS correctly follow up every memory allocation with a matching command to free that memory".
Except that you can't. You can do this for very specific types of program, built in very specific ways or very specific languages. There are a much greater number of programs and languages for which this is not possible.
Don't get me wrong - I realize that you can describe a theoretical algorithm to achieve this, and it would not even be difficult to write a program to do this in any arbitrary language. It's just that the program would require near-infinite storage and time to run.
So as per my post, while it may be technically correct that programming is applied math, in practice this is like saying that my heart beating is applied particle physics. The reality is too far from the theory to be of any use in the general case.
Every algorithm and piece of software can be proven
Yes and no. That's my point. Theoretically speaking, yes. Practically speaking, no.
While each algorithm and piece and indeed the whole could theoretically be proven, it is not feasible to do so except in very trivial cases.
Once we reach the point where practice does not match theory, one questions the point of naming the practice after the theory. I'm not questioning the mathematical background or principles, but rather questioning the useful application of math to programming as a domain at the current time.
While you're technically correct, of course, I think that this attitude leads to some rather poor conclusions.
From the little I know of pure math (so correct me if I'm off-base here) I would suggest that 'proofs' are fundamental to the field. This is very definitely not the case in the majority of programming. If it was, we wouldn't need much testing, and there wouldn't really be bugs.
Your argument is that all programming is math when you get down to the single-instruction level, and that you can scale this up to cover the whole program. However once you reach the point where a program is complex to the point that it is impossible for our technology to prove, the result is certainly not what I'd consider math.
Your same logic could be applied to almost anything really. Break it down small enough, demonstrate it's math, therefore the whole must be math.
Maybe it's Apple-provided libs and dev tools that only create software that runs on the latest version of the OS? In this case, Apple does strongly encourage an upgrade by making your previous-version OS obsolete.
Nope. The tools allow you to select which set of headers and libraries you'd like to link against. The only technical reason for requiring a newer OS is to access new/fixed features.
I agree with your opinion of Theo. He rarely speaks up without cause. I do however think that many people have placed themselves on his bad side over the years, and they might disagree with your comments.
I'm not saying that Theo is a big angry bear, just that he doesn't tolerate crap. It's a sentiment that I agree with. I don't have any direct personal experience with either guy, but that sounds an awful lot like the glorious leader from TFA.
And Theo de Raadt is a bad leader? I agree that, all else being equal, a sociable leader is beneficial. But I'd gladly take an unsociable leader over one who is poor at management or technically.
WoW runs multiple instances quite fine even with a single install directory. You may need to launch the game directly rather than start through the launcher (haven't confirmed that) but we certainly have no trouble multiboxing from a single install.
What you say is true, but is also a very pessimistic viewpoint. I prefer to believe that the majority of people (politicians, developers, everyone) are actually trying to make things better. I'm sure that there are certainly notable exceptions.
Certainly, in games development, there is little incentive in developing overly buggy systems. Doing so repeatedly is more likely to get you fired as incompetent rather than have management ask you to spend additional time on the same tasks.
Regardless, that wasn't really my point - I'm just saying that such systems do not reach perfection. The whys and wherefores don't change that.
A fair analogy would be our legal system. While it serves us reasonably well for the most part, nobody would claim that is completely fair or that there are no loop-holes. Additionally, we have to keep adjusting in on a regular basis.
What makes you think that a handful of game devs will "get it right" where thousands of lawyers and politicians over the years have tried and are still trying?
There is no such thing as absolute balance. There are always loopholes. I have no experience with CoH so I can't say whether their implementation stinks or whether it's amazing, but I think it's fair to say that expecting anything approaching perfection is unreasonable.
I'd have to agree with GP - this really is a marketing term. As you correctly note, overclocking implies that the part is unreliable. I doubt that any large business is going to deliberately risk the high rate of returns that would be associated with shipping an unreliable part. IANAL, but I doubt that "it's sold overclocked!" is going to get you out of honoring a warranty of merchantability or fitness.
While they may indeed be up-clocking a standard part, and then improving cooling and so on, you can be sure that they will have also performed an extensive reliability analysis on the new hardware. If you're saying this is being done at the "Factory" then the normal meaning of "overclocked" doesn't apply.
My 2c.
Posting to remove moderation. Please ignore.
How can this gadget be compared to Kindle? The most important feature Kindle sports is its e-paper display, while the Apple gizmo uses an ordinary LCD screen with touch function.
IOW, Kindle is a document reader, while this thing is another hyped i-something - we're talking about oranges and apple(s) here.
In what meaningful way is a Kindle a "Document Reader" and an i-something not?
* The Kindle lacks other functions - okay, so it's a dedicated "Document Reader" as opposed to being a multifunction device.
* It has an e-paper display - okay, so it gets better battery life, and is arguably easier to work with if you happen to be outside.
While I wouldn't disagree with you saying that the Kindle is a better dedicated document reader, the fact that an i-something saves you carrying around a second device trumps the other concerns for me. I certainly have no troubles using an iPhone to read books.
Carbon is the API abstraction layer; Classic was very much a VM - you even got to watch MacOS 9 boot in a window prior to any Classic application being loaded.
http://en.wikipedia.org/wiki/Classic_(Mac_OS_X)
Classic was only a VM and not an emulator, which is why the Intel chips are not supported.
Surely this logic fails simply because the total amount of money (or time, or interest, or whatever you'd like to measure as a cost) is roughly constant - so for a given product to become more popular, other products must become less popular.