They're a tool to be used for many purposes. Luckily, it appears that in this case they're being used to represent facts (nothing is always as it appears to be though.) However, one has to wonder just how accurate these numbers are. You'd need an independant entity to do some type of verification, but then who'd verify those results? The verifier of the verifier, most likely.
I guess if you keep verifying each set of results, we will eventually reach what could be collectively known as an "accurate" number. But who wants to spend all that time, when we can just take these numbers and assume that they're good? I admit, I certainly don't, and I am happily willing to say, "Hey Inktomi, and NEC Research Institute, thanks for the thorough study and it's subsequent report! I can now sleep better at night knowing that my one web page on the internet is confirmed to be not alone! Way to go!"
But wait! How am I supposed to know that my one teeny website was included in their numbers?!? Hmmm, guess I'll have to run my own study just to verify, but then someone else will have to verify my report... bah, screw it. I give up.
Hey man, relax. I'm simply saying that the example (shooting accuracy) used to represent real 3D, was hardly an adequate representation of what 3D actually is.
Also, what is your fixation with pointing out that nobody cared about FPS "back then?" I could care less one way or the other about FPS now or then, at least as it relates to what I'm typing about here.
FWIW, I'm not a "Quaker," and have never heard of Bungie, and for that matter could also care less about Halo... Just give me the EQ expansion pack, and I'll be happy.
More to 3D than what engine is being used?!? The engine being used is what defines if it's 3D or not.
More realistic collisions are only possible with a 3D engine. Sure, you could "tweak" the code in a 2D engine to "simulate" 3D (i.e.: Your example of missing a shot as being a better representation of 3D) but that hardly means that it's actually 3D.
I've never heard of Marathon2, but judging by the responses here, I can see the most probably reason why. This was "initially" a MAC game. I've never had a MAC, and only used a MAC when I was 13 in school (Macintosh IIe, if memory serves me correctly.)
Looking at Bungie's site, I see Marathon2 was released for Win95 in late 1996. This explains why I've never heard of it. I was too busy playing Quake and Command & Conquer at that time.
That's true, providing the "current release" is actually on the market.
There is a time span where the new release spends some time being "internally tested", etc. This is a situation where the "latest release" will not be available to the user. If the bug is important enough, and the customer is also important enough, you can almost bet that there will be a "political" response to the matter. A response where execs get involved, to make sure that the customer is satisifed. This is where said developer ends up working 12 hour days until the code is migrated back to the current release.
Heck, in some situations, I've seen it where many developers take shifts getting the fix out (Bug is worked on 24/7, with each developer taking 8-10 hour shifts.)
I agree that it's not fair to harshly judge, and that technology should not be expected to perform correctly 100% of the time. However, you can't deny the facts that have been revealed:
1. Remember the metric conversion screwup a while back?
2. This most recent unfortunate event... I find it strange that the Lockheed people knew nothing about the landing zone features, while JPL did. It seems that there is a level of miscommunication going on between these two parties.
These 2 facts are enough to support a good amount of criticism, as they're both something that is within NASA's power to prevent. Of course, I'm only going by what I read in the media, which definitely is not saying much these days.
OSS bug fixes are simply faster because lots of people are reporting bugs and fixing them.
Much better code is produced for worthwhile projects Like it was said elsewhere in these comments about this post... Faster bug fixes do not mean higher quality code.
In fact, the more of these speed comparison stories that surface, the more I start to get concerned. Concerned, for one thing, that some OSS developers out there will get into a certain mindset that a fast bugfix is "required" in order to help the image of OSS in general. If this turns out to be the case, I fear that we may start to see the quality of OSS bugfixes drop.
I have also seen it where a developer would find bugs themselves, and in some cases rather serious ones. Instead of documenting the bug, they would "hide" the fix in with the next release code.
Of course, the result of this is that there would be software out there, with potentially serious bugs that a company knows about. Instead of it being patched in the current release, it is fixed in a future release. Another interesting "side effect" is that there is no negative publicity generated by the public being told about the bug.
AND... in the case where a user DOES find the bug, and reports it, the software company, which has already fixed the bug in the future release, just has to migrate the fix back to the current release (much faster than fixing it like it was an unkown bug,) and VOILA! The user's happy, and the company looks really sharp for having addressed this "very serious bug" so fast and efficiently.
Don't expect the number of fixed bugs to be accurate (read on to find out why.) I can't speak for all the software companies out there but...
A nameless software product that was developed at a company where I worked at one time, would have bugs (as all programs do.) Now, the "official" process for fixing reported bugs were to, of course, document everything (e.g.: How to recreate the bug, any symptoms that occured, frequency of occurance, plus appropriate comments in the source code to match the changed lines to the supported documents... usually done by referencing a Problem/Bug # of some type.)
Things would be great if ALL the developers followed procedures ALL of the time, but they do not.
In fact, I have seen situations where bugs were reported in a product, and a developer would (instead of following procedures) "hide" the fix for the bug in with the code for a next-release-type of feature. This would result in the bug being fixed, but ONLY in the next release of the software, NOT as a patch in the current release.
Meanwhile, the documentation for the bug would sit there, with some type of "pending" status. It eventually sits there for such a long length of time, that it is eventually closed off with some type of reason such as "Need more info," "unable to reproduce," etc. Basically, this is done after no one really cares anymore, as the customers are now using the next release of the software, which has the bugfix "hidden."
Now, you can go ahead and draw your own conclusions about this, but keep in mind the following: I am NOT saying that any of the software products represented in this post fall under this category, simply that if one company out there in world does this, I wouldn't be surprised to find another that does something similar, if not the same.
This is typical marketing/advertising. If I was in the ad business, I'd be doing the same thing.
It's their job to increase sales, and this is an appropriate method to do so given what they are trying to sell.
To put it another way, when we were kids and they'd show those action figure commercials where the figures seemed like they were really flying, you didn't really believe they could actually fly, did you?
It's advertising, plain and simple. If a person gets suckered into purchasing something simply by viewing the ad, they really have nobody to blame but themselves. Likewise, if a person is willing to spend their money without doing their own research, then perhaps they deserve to be suckered.
advertise Pronunciation: 'ad-v&r-"tIz Function: verb Inflected Form(s): -tised; -tising Etymology: Middle English, from Middle French advertiss-, stem of advertir Date: 15th century transitive senses 1: to make something known to : NOTIFY 2 a: to make publicly and generally known b: to announce publicly especially by a printed notice or a broadcast c: to call public attention to especially by emphasizing desirable qualities so as to arouse a desire to buy or patronize : PROMOTE intransitive senses : to issue or sponsor advertising
In case anyone is interested, here are some further readings on the subject of psychology as it is involved with advertising:
Isn't "secondary initial public offering" (or... "secondary IPO") an oxymoron? Just thought it sounds a bit odd to be using the term IPO with what RedHat is doing. Granted, it is an "offering", but it's hardly their initial offering.
Re:If you like slave labour, go for it.
on
The GCHQ Challenge
·
· Score: 1
Actually, I posted the comment after discussing it with coworkers. Everyone in my area thought it was elementary, and rightfully so.
"Lawrence Bender and Laurie Bickford are in negotiations to come aboard as producers."
Note, "in negotiations". This means that there is no Producer yet.
I just figured I should give everyone a dose of reality here. I feel great for the/. people involved in this good fortune, but it doesn't do anybody any good to jump to conclusions, and as such, raise everybody's expectations.
A. Like any tech job in the government, be prepared to get paid less than an equivalent job in the private sector.
In fact, seeing as how it's tax payer's money that would be used to pay for the government job, you would essentially be working for free, if you pay taxes (Paying yourself to work?! That's crazy!):)
(I have to admit, that compared to what you get paid working as a student, the government wages would be fantastic.)
Also, I'm not sure how the British Government operates, but where I'm from the Government has set levels of pay, usually that are NOT based on the occupation, but rather they are based on the experience. Also, they *usually* do not hire external candidates for high-level/high-paying positions... they *usually* recruit from within.
In all fairness though, I have seen some Government jobs where they would pay a bit higher than the set pay level. However, these situations usually only arrive because they have had an extremely difficult time finding an appropriate candidate.
B. Now, this little scheme that GCHQ has cooked up looks to be one where they hope to get a person with adequate initiative to join their ranks. I see some good points and some bad points about their methods of finding candidates though.
Good: They are able to reach a large target demographic by using their website. Obviously, they are looking for people who have some type of computer skills. They can filter these people out by using their current technique. (Binary code, morse code, etc.) Anyone able to decode their little "surprises" should have the basic knowledge necessary for the job (which, seeing these little encoded snippets, isn't saying much... no offense to those people that were feeling good about themselves for having decoded them all.)
Bad: Building on how I ended the example "good" point above... Being able to decode a few elementary strings is far from impressive. It is also hardly a testimant to the initiative of whoever is able to successfully decode them. There is much, much more to initiative than looking through the HTML of various web pages, seeking encoded text. This is comparable to saying to a group of 6 year old children,
"I've placed several chocolate easter eggs around the house. Your job is to run around and find them. If you find them all, I'll let you ask me for a dollar. Good luck!"
Now, I admit that in this case the "easter eggs" are encoded (albeit, very rudimentally), so perhaps a better comparison would be if the chocolate easter eggs were made to resemble various household items (i.e.: Chocolate ashtray, with a picture of an easter egg stamped on the bottom, etc.)
That's all it is. You know the saying, "The hand is quicker than the eye." Well, I wouldn't be at all surprised if Mr. Gates will still be calling the shots (or "pulling the strings" of Mr. Ballmer) from the sidelines in an "advisory" capacity. I almost feel sorry for Ballmer.
I'm no USENET expert, by any stretch, but you *may* (most likely, you can) still be able to read/post messages using DejaNews. Of course, this is just in theory (my theory too, which isn't saying much.) So, like a lot theories, it stands an equal chance of being proven wrong or right.
FYI... "Because of this lack of response to serious, ongoing problems, even when they have been pointed out repeatedly, a full active Usenet Death Penalty will go into effect at the close of business, 17:00 PST, on Tuesday, 18 January 2000 (19 Jan 2000 01:00:00 GMT)."
Slashdot Mirror
They're a tool to be used for many purposes. Luckily, it appears that in this case they're being used to represent facts (nothing is always as it appears to be though.) However, one has to wonder just how accurate these numbers are. You'd need an independant entity to do some type of verification, but then who'd verify those results? The verifier of the verifier, most likely.
... bah, screw it. I give up.
I guess if you keep verifying each set of results, we will eventually reach what could be collectively known as an "accurate" number. But who wants to spend all that time, when we can just take these numbers and assume that they're good? I admit, I certainly don't, and I am happily willing to say, "Hey Inktomi, and NEC Research Institute, thanks for the thorough study and it's subsequent report! I can now sleep better at night knowing that my one web page on the internet is confirmed to be not alone! Way to go!"
But wait! How am I supposed to know that my one teeny website was included in their numbers?!? Hmmm, guess I'll have to run my own study just to verify, but then someone else will have to verify my report
Hey man, relax. I'm simply saying that the example (shooting accuracy) used to represent real 3D, was hardly an adequate representation of what 3D actually is.
... Just give me the EQ expansion pack, and I'll be happy.
Also, what is your fixation with pointing out that nobody cared about FPS "back then?" I could care less one way or the other about FPS now or then, at least as it relates to what I'm typing about here.
FWIW, I'm not a "Quaker," and have never heard of Bungie, and for that matter could also care less about Halo
More to 3D than what engine is being used?!? The engine being used is what defines if it's 3D or not.
More realistic collisions are only possible with a 3D engine. Sure, you could "tweak" the code in a 2D engine to "simulate" 3D (i.e.: Your example of missing a shot as being a better representation of 3D) but that hardly means that it's actually 3D.
No offense, but you can't be serious. Marathon2 can hardly be considered real 3D.
I admit, I have never played this game, but just looking at the screenshots, it's easy to tell that it's not a real 3D graphics engine.
If you want to find out what is involved with a real 3D engine, check out this link.
I've never heard of Marathon2, but judging by the responses here, I can see the most probably reason why. This was "initially" a MAC game. I've never had a MAC, and only used a MAC when I was 13 in school (Macintosh IIe, if memory serves me correctly.)
Looking at Bungie's site, I see Marathon2 was released for Win95 in late 1996. This explains why I've never heard of it. I was too busy playing Quake and Command & Conquer at that time.
That's true, providing the "current release" is actually on the market.
There is a time span where the new release spends some time being "internally tested", etc. This is a situation where the "latest release" will not be available to the user. If the bug is important enough, and the customer is also important enough, you can almost bet that there will be a "political" response to the matter. A response where execs get involved, to make sure that the customer is satisifed. This is where said developer ends up working 12 hour days until the code is migrated back to the current release.
Heck, in some situations, I've seen it where many developers take shifts getting the fix out (Bug is worked on 24/7, with each developer taking 8-10 hour shifts.)
Of course, I'm only going by what I read in the media, which definitely is not saying much these days.
OSS bug fixes are simply faster because lots of people are reporting bugs and fixing them.
... Faster bug fixes do not mean higher quality code.
Much better code is produced for worthwhile projects Like it was said elsewhere in these comments about this post
In fact, the more of these speed comparison stories that surface, the more I start to get concerned. Concerned, for one thing, that some OSS developers out there will get into a certain mindset that a fast bugfix is "required" in order to help the image of OSS in general. If this turns out to be the case, I fear that we may start to see the quality of OSS bugfixes drop.
I hope that this does not happen.
I have also seen it where a developer would find bugs themselves, and in some cases rather serious ones. Instead of documenting the bug, they would "hide" the fix in with the next release code.
... in the case where a user DOES find the bug, and reports it, the software company, which has already fixed the bug in the future release, just has to migrate the fix back to the current release (much faster than fixing it like it was an unkown bug,) and VOILA! The user's happy, and the company looks really sharp for having addressed this "very serious bug" so fast and efficiently.
Of course, the result of this is that there would be software out there, with potentially serious bugs that a company knows about. Instead of it being patched in the current release, it is fixed in a future release. Another interesting "side effect" is that there is no negative publicity generated by the public being told about the bug.
AND
OK, I'll shut up now.
Don't expect the number of fixed bugs to be accurate (read on to find out why.) I can't speak for all the software companies out there but ...
... usually done by referencing a Problem/Bug # of some type.)
A nameless software product that was developed at a company where I worked at one time, would have bugs (as all programs do.) Now, the "official" process for fixing reported bugs were to, of course, document everything (e.g.: How to recreate the bug, any symptoms that occured, frequency of occurance, plus appropriate comments in the source code to match the changed lines to the supported documents
Things would be great if ALL the developers followed procedures ALL of the time, but they do not.
In fact, I have seen situations where bugs were reported in a product, and a developer would (instead of following procedures) "hide" the fix for the bug in with the code for a next-release-type of feature. This would result in the bug being fixed, but ONLY in the next release of the software, NOT as a patch in the current release.
Meanwhile, the documentation for the bug would sit there, with some type of "pending" status. It eventually sits there for such a long length of time, that it is eventually closed off with some type of reason such as "Need more info," "unable to reproduce," etc. Basically, this is done after no one really cares anymore, as the customers are now using the next release of the software, which has the bugfix "hidden."
Now, you can go ahead and draw your own conclusions about this, but keep in mind the following: I am NOT saying that any of the software products represented in this post fall under this category, simply that if one company out there in world does this, I wouldn't be surprised to find another that does something similar, if not the same.
It's their job to increase sales, and this is an appropriate method to do so given what they are trying to sell.
To put it another way, when we were kids and they'd show those action figure commercials where the figures seemed like they were really flying, you didn't really believe they could actually fly, did you?
It's advertising, plain and simple. If a person gets suckered into purchasing something simply by viewing the ad, they really have nobody to blame but themselves. Likewise, if a person is willing to spend their money without doing their own research, then perhaps they deserve to be suckered.
In case anyone is interested, here are some further readings on the subject of psychology as it is involved with advertising:
Isn't "secondary initial public offering" (or ... "secondary IPO") an oxymoron? Just thought it sounds a bit odd to be using the term IPO with what RedHat is doing. Granted, it is an "offering", but it's hardly their initial offering.
Actually, I posted the comment after discussing it with coworkers. Everyone in my area thought it was elementary, and rightfully so.
I just figured I should give everyone a dose of reality here. I feel great for the
Like any tech job in the government, be prepared to get paid less than an equivalent job in the private sector.
In fact, seeing as how it's tax payer's money that would be used to pay for the government job, you would essentially be working for free, if you pay taxes (Paying yourself to work?! That's crazy!)
(I have to admit, that compared to what you get paid working as a student, the government wages would be fantastic.)
Also, I'm not sure how the British Government operates, but where I'm from the Government has set levels of pay, usually that are NOT based on the occupation, but rather they are based on the experience. Also, they *usually* do not hire external candidates for high-level/high-paying positions
In all fairness though, I have seen some Government jobs where they would pay a bit higher than the set pay level. However, these situations usually only arrive because they have had an extremely difficult time finding an appropriate candidate.
B.
Now, this little scheme that GCHQ has cooked up looks to be one where they hope to get a person with adequate initiative to join their ranks. I see some good points and some bad points about their methods of finding candidates though.
Good: They are able to reach a large target demographic by using their website. Obviously, they are looking for people who have some type of computer skills. They can filter these people out by using their current technique. (Binary code, morse code, etc.) Anyone able to decode their little "surprises" should have the basic knowledge necessary for the job (which, seeing these little encoded snippets, isn't saying much
Bad: Building on how I ended the example "good" point above
Just my thoughts on the matter.
That's all it is. You know the saying, "The hand is quicker than the eye." Well, I wouldn't be at all surprised if Mr. Gates will still be calling the shots (or "pulling the strings" of Mr. Ballmer) from the sidelines in an "advisory" capacity. I almost feel sorry for Ballmer.
I'm no USENET expert, by any stretch, but you *may* (most likely, you can) still be able to read/post messages using DejaNews. Of course, this is just in theory (my theory too, which isn't saying much.) So, like a lot theories, it stands an equal chance of being proven wrong or right.
FYI... "Because of this lack of response to serious, ongoing problems, even when they have been pointed out repeatedly, a full active Usenet Death Penalty will go into effect at the close of business, 17:00 PST, on Tuesday, 18 January 2000 (19 Jan 2000 01:00:00 GMT)."
"Breast"fed with a cock? Now there's a disturbing image.