One of the biggest issues I see with the politicization of software licensing is that often advocates of software on a certain license will mentally gloss over major holes in the software/ecosystem, while at the same time gloss over major advantages of competing software/ecosystems.
In your opinion, what are the biggest holes/"areas for opportunity to improve" in Linux at the moment?
I think you are missing the point of the example given.
Microsoft isn't saying that they didn't implement both window.postMessage and window.addEventListener.
They are saying that if you want to test for the existence of feature A, you check for the existence of feature A and you don't infer its existence by checking for the existence of feature B.
Suddenly, the memory-and-keystroke-saving command names of the past combine with the keystroke-saving text-speak of the present to create the nightmarish user interaction bugs of the future.
Internet Explorer has three rendering modes: normal (IE6), standards (IE7) and super-standards (IE8).
Depending on the DOCTYPE, either "normal (IE6)" or "super-standards (IE8)" will appear.
For pages that appear in "super-standards" mode, they may appear broken if the page was built for IE6/7 and has an improper DOCTYPE. They put a button next to the link that someone can click to shift into the legacy rendering mode that looks like a broken page because most users are going to look for an obvious icon.
In this industry, you will NOT be able to sell an idea with what you have.
Time, money, resources, staff, all of these are in short supply...but ideas are in abundance in the industry. Everyone in the industry has an idea, but only a rare few will get the opportunities to make their ideas into products.
If you want your idea to come to life, make a prototype and a proof of concept like you've already done, and then polish it to a shine. Make what is called a "vertical slice."
Once you have the vertical slice, create NDA's to cover your idea and work from there.
The average user doesn't notice any security feature unless it is in their face.
Given the number of phishing sites out there, it could be argued that every additional slap to the face that a user would have to get through in order to get to a phishing site (known phishing site, self-signed SSL, acknowledge that you are a fucking retard for bypassing the last two warnings, etc.) may be worth it.
Just remember that just because the precepts of net neutrality (all bandwidth is equal) means that we should let a user shoot themselves in the head doesn't mean that we shouldn't at least make a passing effort to put a safety on the gun they are using.
First request from the electron was for more funding for science programs.
If that isn't controlled spin, I don't know what is. (grin)
Re:I welcome the exit, if true...
on
The End of E3?
·
· Score: 2, Informative
A lot of companies want the work to go on as long as possible before forking to reduce integration downtime afterwards.
While a pure branch with regular merge-ins from the main tree is ideal, there are many times where it can be impractical.
I welcome the exit, if true...
on
The End of E3?
·
· Score: 4, Insightful
Given the amount of money spent trying to get E3 builds ready, stabilize those builds, then strip out the hacks so that people can get back to work, this may actually be a good thing.
If I have to choose between E3 and essentially getting an extra month of productivity a year...farewell, E3, I barely knew ye.
I'm not going to deny that QA is difficult. I started at Access Software and stuck with QA through almost five years at Microsoft Game Studios before saying "fsck it" because of the stress and leaving games for a bit to try my hand at coding.
During my time as a programmer, I learned two things. First, even just spending time testing games helped me learn enough about coding in a performance-critical environment that I was able to carry many of those lessons over into "the real world;" and second, as much as I enjoyed making things, I enjoyed breaking them even more.
So I've returned to QA. Sure, QA is often the scapegoat in case anything goes wrong; QA often has to work shifts that would make sweatshop workers quit; QA rarely receives the recognition due or the compensation necessary...but QA is also one of the most rewarding careers in terms of variety and challenge. Every day, I receive a build and wonder what's wrong with it this time and how can I break it.
When I report something to a developer and see them seethe for an hour on end trying to figure out how they're going to fix it...it makes my heart smile. Those are the moments I live for.
Generally, the bug count is the same whether you are using a pre-existing engine or a new engine.
With pre-existing engines, the engine-related bugs are more focused on usage scenarios that were never anticipated with the original engine (surface penetration, rotating geometry, gravity normals, etc.) or bugs that were there, but never found or were found, not documented, and as a result, never fixed. With new engines, you get some of that (design almost always goes beyond the originally decided-on limits of the code), but you get bugs that are significantly lower-level (memory allocator going haywire, etc.)
You still get the same level of content bugs, however.
First off, I should probably lay out my credentials. My name is Michael Russell, and I'm the QA Manager for Ritual Entertainment. We're going to be releasing "SiN Episodes: Emergence" over Steam on May 10.
In some ways, Greg Atkinson is absolutely right, but he seems to be right for the wrong reasons.
There are three global problems in game development: marketing usually promises a date that cannot be met, throwing more people at a problem cannot fix it, and bugs found at the end of a project are hard to impossible to fix.
The marketing date is a huge issue because 90% of the time, the people making the game have no buy-in regarding it. They're working towards being done when it's done, and then when they get told that they have six months when they need a year, things get implemented too fast and half-assed.
Of course, here we are at six months out with no testing so far. In fact, the game is generally in an untestable state due to the huge influx of new, untested, unstable code and/or assets. Several major developers and publishers are now moving to the "monkey" model of testing: hire 100 temps for six weeks at the end, have them hammer on the game, and the end result is 5,000 bugs with little time to fix it.
So, the team gets the game to a basic level of functionality, throws it in a box, and gets to work on the patch while the box winds its way to retail.
Until the industry as a whole learns that QA is no longer just a line-item expense but a necessity, we're going to have issues like this.
Console developers are starting to get it, but mostly because the platform holders have a set of tests that every game released on the console must pass. Fail one test or a permutation of one test, and there is a high likelihood that you won't ship. Suddenly, spending an extra few dollars on testing early to find and fix the problem doesn't seem like a big expenditure compared to the nightmare that is missing your street date.
I'm happy that we've had testing on "SiN Episodes: Emergence" from day 1. Are there still going to be bugs? Always...there's nothing you can do to eliminate bugs entirely. It's the nature of software development. But by getting on the project early and testing through to the end, we're able to make sure that the game is stable, completable, and fun out of the box.
It's not the best problem to solve, but when looking at legacy technology to fix, one must often look at the easiest/cheapest solution.
The biggest problem I've seen when it comes to legacy solutions is that often the people who are closest to those solutions are the people least likely to see the problems for what they are.
The largest issue I can see with UNIX permeates all of my comments, and that is that UNIX was designed to as the answer to a problem, which was how to get the most done in a small, shared environment (low memory, low storage, etc.) However, over the last 30 years, the problem has changed to how do we get the most productivity out of our information workers.
Many of the assumptions that led to UNIX, the POSIX standards, etc., are either completely erroneous (the normal user is not a student or a UNIX "hacker") or no longer apply (dumb terminals no longer rule the world). The same can be said of any legacy system (Win16/32 has several issues due to the same overarching problem).
Yes, and the FAT file system only allowed 8.3 filenames by design. Does that mean that Microsoft should have forced Windows developers to stay 8.3? POSIX may be a standard, but all standards evolve. IP4 is slowly moving to IP6. IP4 applications have issues with IP6. HTML is slowly moving to XHTML with similar side effects. I'm not saying that the change would be easy, but there are times when changes should be done.
This is done already. As long as the file is marked executable, the shell will properly lauch the parser. You can even add BINARY formats to the kernel.
This one is my fault. I should have said make it more discoverable to the standard user what type it should have been, either through an addition onto ls or some other easy-to-discover means. file(1) is not easily discoverable.
I understand why the decisions were made. At the time that UNIX was designed, every byte counted.
Case-sensitive compares were smaller and cheaper than case-insensitive compares, even though it opened UNIX up to severe usability issues.
Checking the executable bit on the file attribute at load time was cheaper than parsing the file, even though you could pass in anything and try to make it executable.
The single character flag limitation was due to memory constraints primarily.
The decisions were appropriate for the era that UNIX was designed in. However, should we be hamstrung by design decisions (such as destructive actions without confirmation) that were made over 30 years ago?
UNIX and the various shells were designed for when every keystroke counted due to memory constraints and the painful experience of working at a teletype.
As a result, we've got upper- and lower-case flags doing completely different operations (-r and -R for "remove" and "restore," for example), we've got case-sentitive filenames which just make it so easy to tell the difference between "Index," "iNdex," "inDex," "indEx" and "indeX."
UNIX was designed when plain text was king and the only nudies you ever saw were ASCII art.
As a result, there's no way from looking at the filename to tell what program the file should be processed with.
UNIX was designed under the guidelines of "do one thing well, do it quickly and get out of memory."
Those design decisions permeate UNIX and the *NIX community even today. When I read the newsgroups, I still see tips on how to do things that involve piping a file through 17 filters to do something that can be done on Windows with four mouse clicks.
So how would I fix these problems?
1) Make filenames and command flags case-insensitive. The few cycles you spend doing case comparisons will quickly pale in comparison to the time savings you experience in tech support situations where a touch typist accidentally hits space too soon and types "emacS."
2) Several files that do not have extensions usually have some information about their default parser in line #1. Either parse it, or start using file extensions in *NIX.
3) Start making UI's that only initially expose the 20% of the UI that 80% of people will use. There's no reason for a CD-burning package to have a checkbox on the main screen about verifying post-gap length for 99% of the people in the world.
I bought "Grim Fandango," and while I have enjoyed the game, I have hated the control scheme with a level of hatred I normally reserve for Jehovah's Witness evangelical door-to-door vacuum cleaner/insurance salesmen.
LucasArts' choice of controls for "Grim Fandango" were the killing choice. Abandoning the point/click interface for what was essentially a keyboard version of the "Resident Evil" control scheme was atrocious.
Any time a person has to spend 10-15 minutes rotating their character, slightly moving forward and back, etc. in a futile effort to get into position to hit a button...well,
Yes, but will the mastering house have guaranteed uncorrupted access to your original files? Doubtful. Most likely, the mastering house will have the disks that were sent and nothing more. Even if they do have access to your files over a WAN or via a local copy that you FTP to them, who is to say that there was no data corruption in transfer?
When I mastered, I did as much verification as I could on the disks themselves to ensure that they were correct. Beyond that, the CRC check is merely there so that the mastering house can (with a single command) verify that their hardware is reading the same data that we provided.
The potential for collisions will always exist, admittedly, but on a 700Mb CD, the likelihood of getting a CRC collision on bad data is excessively small (just over 1%). That, combined with the fact that multiple masters were sent and the data was compared from multiple drives at the mastering house as a safety measure, is enough for general peace of mind.
For our high-profile releases, we sent a PM along with a laptop that had the original files to the mastering house, but his services were never required across the over 40 CD's that we mastered during my tenure.
I think we've covered the bases here, so unless you have a compelling real-world argument to show that the mastering method that I used was inadequate, I'm going to consider the thread closed.
From what I understand, if you uninstall Half-Life 2 after activating it on Steam, then install off of Steam, you won't have to use your media anymore.
Admittedly, you'll have to download quite a bit of data and it's a pain in the rump and it might not work after their next patch, but that's what's been going around the message boards.
Qualifications: I am no longer at Microsoft, but when I was at Microsoft, I burned the gold masters for eight seperate titles, including seven that used SafeDisc.
For our CD's, we used Mitsui primarily. They were a decent balance between cost and reliability. We'd also always submit to our release labs at least five copies of each CD.
Finally, we'd use a tool (CRC 3.05, available to MSDN subscribers in Subscriber Downloads) which would calculate the CRC value of each CD. Once we finished burning a CD, we'd do a binary compare with the source bits, and if everything matched up, we'd add the CD to our "good" pile.
For the first several (spread out over three years), we used a PlexWriter 2x writing at 1x to burn. We also used Goldenhawk CDR-WIN to burn the masters, but had to switch to Prassi once Goldenhawk stopped putting in the proper postgap on the CD's.
For our final disks, we went with a PlexWriter 48x writing at 16x.
Forensic evidence is one of the most powerful tools available to law enforcement because it is relatively irrefutable.
While things may not work like they do in "CSI" in real life, the sway towards the forensic can only help ensure that the proper people get sent to jail.
The popularity may also help increase funding for CSI departments nationwide. Most CSI departments are woefully underfunded and undermanned.
Besides, just imagine if they had been able to get O.J.'s DNA or fingerprints off of the inside of those gloves...
I picked up the game at midnight, went home, got a good night's sleep, and since I took the 9th off from work in order to beat the game, started the game around 11:00am.
I beat it at 5:30pm. I loved the entire game...except for that ENDING.
Mein Gott, it's one thing to have a cliffhanger ending when you know that you'll only have to wait a few months for resolution. It's another when you know you'll have to wait for an additional 3-4 YEARS.
Especially since the end boss battle is a bit anticlimatic. I didn't even get in the killing shot...my AI teammates did.
Slashdot Mirror
One of the biggest issues I see with the politicization of software licensing is that often advocates of software on a certain license will mentally gloss over major holes in the software/ecosystem, while at the same time gloss over major advantages of competing software/ecosystems.
In your opinion, what are the biggest holes/"areas for opportunity to improve" in Linux at the moment?
I think you are missing the point of the example given.
Microsoft isn't saying that they didn't implement both window.postMessage and window.addEventListener.
They are saying that if you want to test for the existence of feature A, you check for the existence of feature A and you don't infer its existence by checking for the existence of feature B.
Suddenly, the memory-and-keystroke-saving command names of the past combine with the keystroke-saving text-speak of the present to create the nightmarish user interaction bugs of the future.
So let me see if I get this right...
Internet Explorer has three rendering modes: normal (IE6), standards (IE7) and super-standards (IE8).
Depending on the DOCTYPE, either "normal (IE6)" or "super-standards (IE8)" will appear.
For pages that appear in "super-standards" mode, they may appear broken if the page was built for IE6/7 and has an improper DOCTYPE. They put a button next to the link that someone can click to shift into the legacy rendering mode that looks like a broken page because most users are going to look for an obvious icon.
I'm not seeing the problem here.
In this industry, you will NOT be able to sell an idea with what you have.
Time, money, resources, staff, all of these are in short supply...but ideas are in abundance in the industry. Everyone in the industry has an idea, but only a rare few will get the opportunities to make their ideas into products.
If you want your idea to come to life, make a prototype and a proof of concept like you've already done, and then polish it to a shine. Make what is called a "vertical slice."
Once you have the vertical slice, create NDA's to cover your idea and work from there.
The average user doesn't notice any security feature unless it is in their face.
Given the number of phishing sites out there, it could be argued that every additional slap to the face that a user would have to get through in order to get to a phishing site (known phishing site, self-signed SSL, acknowledge that you are a fucking retard for bypassing the last two warnings, etc.) may be worth it.
Just remember that just because the precepts of net neutrality (all bandwidth is equal) means that we should let a user shoot themselves in the head doesn't mean that we shouldn't at least make a passing effort to put a safety on the gun they are using.
I like the concept of this MMORPG, but it would be difficult to make someone's death a tragedy when they can just respawn two meters away.
First request from the electron was for more funding for science programs.
If that isn't controlled spin, I don't know what is. (grin)
A lot of companies want the work to go on as long as possible before forking to reduce integration downtime afterwards.
While a pure branch with regular merge-ins from the main tree is ideal, there are many times where it can be impractical.
Given the amount of money spent trying to get E3 builds ready, stabilize those builds, then strip out the hacks so that people can get back to work, this may actually be a good thing.
If I have to choose between E3 and essentially getting an extra month of productivity a year...farewell, E3, I barely knew ye.
I'm not going to deny that QA is difficult. I started at Access Software and stuck with QA through almost five years at Microsoft Game Studios before saying "fsck it" because of the stress and leaving games for a bit to try my hand at coding.
During my time as a programmer, I learned two things. First, even just spending time testing games helped me learn enough about coding in a performance-critical environment that I was able to carry many of those lessons over into "the real world;" and second, as much as I enjoyed making things, I enjoyed breaking them even more.
So I've returned to QA. Sure, QA is often the scapegoat in case anything goes wrong; QA often has to work shifts that would make sweatshop workers quit; QA rarely receives the recognition due or the compensation necessary...but QA is also one of the most rewarding careers in terms of variety and challenge. Every day, I receive a build and wonder what's wrong with it this time and how can I break it.
When I report something to a developer and see them seethe for an hour on end trying to figure out how they're going to fix it...it makes my heart smile. Those are the moments I live for.
That's why I test.
Generally, the bug count is the same whether you are using a pre-existing engine or a new engine.
With pre-existing engines, the engine-related bugs are more focused on usage scenarios that were never anticipated with the original engine (surface penetration, rotating geometry, gravity normals, etc.) or bugs that were there, but never found or were found, not documented, and as a result, never fixed. With new engines, you get some of that (design almost always goes beyond the originally decided-on limits of the code), but you get bugs that are significantly lower-level (memory allocator going haywire, etc.)
You still get the same level of content bugs, however.
First off, I should probably lay out my credentials. My name is Michael Russell, and I'm the QA Manager for Ritual Entertainment. We're going to be releasing "SiN Episodes: Emergence" over Steam on May 10.
In some ways, Greg Atkinson is absolutely right, but he seems to be right for the wrong reasons.
There are three global problems in game development: marketing usually promises a date that cannot be met, throwing more people at a problem cannot fix it, and bugs found at the end of a project are hard to impossible to fix.
The marketing date is a huge issue because 90% of the time, the people making the game have no buy-in regarding it. They're working towards being done when it's done, and then when they get told that they have six months when they need a year, things get implemented too fast and half-assed.
Of course, here we are at six months out with no testing so far. In fact, the game is generally in an untestable state due to the huge influx of new, untested, unstable code and/or assets. Several major developers and publishers are now moving to the "monkey" model of testing: hire 100 temps for six weeks at the end, have them hammer on the game, and the end result is 5,000 bugs with little time to fix it.
So, the team gets the game to a basic level of functionality, throws it in a box, and gets to work on the patch while the box winds its way to retail.
Until the industry as a whole learns that QA is no longer just a line-item expense but a necessity, we're going to have issues like this.
Console developers are starting to get it, but mostly because the platform holders have a set of tests that every game released on the console must pass. Fail one test or a permutation of one test, and there is a high likelihood that you won't ship. Suddenly, spending an extra few dollars on testing early to find and fix the problem doesn't seem like a big expenditure compared to the nightmare that is missing your street date.
I'm happy that we've had testing on "SiN Episodes: Emergence" from day 1. Are there still going to be bugs? Always...there's nothing you can do to eliminate bugs entirely. It's the nature of software development. But by getting on the project early and testing through to the end, we're able to make sure that the game is stable, completable, and fun out of the box.
And for a game, that's all you can ask.
It's not the best problem to solve, but when looking at legacy technology to fix, one must often look at the easiest/cheapest solution.
The biggest problem I've seen when it comes to legacy solutions is that often the people who are closest to those solutions are the people least likely to see the problems for what they are.
The largest issue I can see with UNIX permeates all of my comments, and that is that UNIX was designed to as the answer to a problem, which was how to get the most done in a small, shared environment (low memory, low storage, etc.) However, over the last 30 years, the problem has changed to how do we get the most productivity out of our information workers.
Many of the assumptions that led to UNIX, the POSIX standards, etc., are either completely erroneous (the normal user is not a student or a UNIX "hacker") or no longer apply (dumb terminals no longer rule the world). The same can be said of any legacy system (Win16/32 has several issues due to the same overarching problem).
I understand why the decisions were made. At the time that UNIX was designed, every byte counted.
Case-sensitive compares were smaller and cheaper than case-insensitive compares, even though it opened UNIX up to severe usability issues.
Checking the executable bit on the file attribute at load time was cheaper than parsing the file, even though you could pass in anything and try to make it executable.
The single character flag limitation was due to memory constraints primarily.
The decisions were appropriate for the era that UNIX was designed in. However, should we be hamstrung by design decisions (such as destructive actions without confirmation) that were made over 30 years ago?
UNIX and the various shells were designed for when every keystroke counted due to memory constraints and the painful experience of working at a teletype.
As a result, we've got upper- and lower-case flags doing completely different operations (-r and -R for "remove" and "restore," for example), we've got case-sentitive filenames which just make it so easy to tell the difference between "Index," "iNdex," "inDex," "indEx" and "indeX."
UNIX was designed when plain text was king and the only nudies you ever saw were ASCII art.
As a result, there's no way from looking at the filename to tell what program the file should be processed with.
UNIX was designed under the guidelines of "do one thing well, do it quickly and get out of memory."
Those design decisions permeate UNIX and the *NIX community even today. When I read the newsgroups, I still see tips on how to do things that involve piping a file through 17 filters to do something that can be done on Windows with four mouse clicks.
So how would I fix these problems?
1) Make filenames and command flags case-insensitive. The few cycles you spend doing case comparisons will quickly pale in comparison to the time savings you experience in tech support situations where a touch typist accidentally hits space too soon and types "emacS."
2) Several files that do not have extensions usually have some information about their default parser in line #1. Either parse it, or start using file extensions in *NIX.
3) Start making UI's that only initially expose the 20% of the UI that 80% of people will use. There's no reason for a CD-burning package to have a checkbox on the main screen about verifying post-gap length for 99% of the people in the world.
Anyway, that's my opinion.
I bought "Grim Fandango," and while I have enjoyed the game, I have hated the control scheme with a level of hatred I normally reserve for Jehovah's Witness evangelical door-to-door vacuum cleaner/insurance salesmen.
LucasArts' choice of controls for "Grim Fandango" were the killing choice. Abandoning the point/click interface for what was essentially a keyboard version of the "Resident Evil" control scheme was atrocious.
Any time a person has to spend 10-15 minutes rotating their character, slightly moving forward and back, etc. in a futile effort to get into position to hit a button...well,
Didn't say that porting was making. Merely stated Ritual's involvement.
However, I can see how a non-techie reporter could confuse the two.
Ritual handled the Counterstrike port to the Xbox.
Yes, but will the mastering house have guaranteed uncorrupted access to your original files? Doubtful. Most likely, the mastering house will have the disks that were sent and nothing more. Even if they do have access to your files over a WAN or via a local copy that you FTP to them, who is to say that there was no data corruption in transfer?
When I mastered, I did as much verification as I could on the disks themselves to ensure that they were correct. Beyond that, the CRC check is merely there so that the mastering house can (with a single command) verify that their hardware is reading the same data that we provided.
The potential for collisions will always exist, admittedly, but on a 700Mb CD, the likelihood of getting a CRC collision on bad data is excessively small (just over 1%). That, combined with the fact that multiple masters were sent and the data was compared from multiple drives at the mastering house as a safety measure, is enough for general peace of mind.
For our high-profile releases, we sent a PM along with a laptop that had the original files to the mastering house, but his services were never required across the over 40 CD's that we mastered during my tenure.
I think we've covered the bases here, so unless you have a compelling real-world argument to show that the mastering method that I used was inadequate, I'm going to consider the thread closed.
From what I understand, if you uninstall Half-Life 2 after activating it on Steam, then install off of Steam, you won't have to use your media anymore.
Admittedly, you'll have to download quite a bit of data and it's a pain in the rump and it might not work after their next patch, but that's what's been going around the message boards.
Nothing is foolproof. There will always be the chance of CRC collisions on any large set of data.
The entire point of verifying the data written, creating the CRC, etc., is to increase the likelihood that data errors will be found.
After all, while you cannot eliminate errors, best efforts at prevention combined with best efforts at detection will greatly reduce errors.
Qualifications: I am no longer at Microsoft, but when I was at Microsoft, I burned the gold masters for eight seperate titles, including seven that used SafeDisc.
For our CD's, we used Mitsui primarily. They were a decent balance between cost and reliability. We'd also always submit to our release labs at least five copies of each CD.
Finally, we'd use a tool (CRC 3.05, available to MSDN subscribers in Subscriber Downloads) which would calculate the CRC value of each CD. Once we finished burning a CD, we'd do a binary compare with the source bits, and if everything matched up, we'd add the CD to our "good" pile.
For the first several (spread out over three years), we used a PlexWriter 2x writing at 1x to burn. We also used Goldenhawk CDR-WIN to burn the masters, but had to switch to Prassi once Goldenhawk stopped putting in the proper postgap on the CD's.
For our final disks, we went with a PlexWriter 48x writing at 16x.
Forensic evidence is one of the most powerful tools available to law enforcement because it is relatively irrefutable.
While things may not work like they do in "CSI" in real life, the sway towards the forensic can only help ensure that the proper people get sent to jail.
The popularity may also help increase funding for CSI departments nationwide. Most CSI departments are woefully underfunded and undermanned.
Besides, just imagine if they had been able to get O.J.'s DNA or fingerprints off of the inside of those gloves...
I picked up the game at midnight, went home, got a good night's sleep, and since I took the 9th off from work in order to beat the game, started the game around 11:00am.
I beat it at 5:30pm. I loved the entire game...except for that ENDING.
Mein Gott, it's one thing to have a cliffhanger ending when you know that you'll only have to wait a few months for resolution. It's another when you know you'll have to wait for an additional 3-4 YEARS.
Especially since the end boss battle is a bit anticlimatic. I didn't even get in the killing shot...my AI teammates did.