>Look, being disabled means there are some thing you are not able to do.
Kid, go and take a look at your grandparents. Take a good, long look. Do you plan to stop using a computer when you're their age? No more games, no more surfing the web?
I didn't think so, punk. *Now* do you see why you might want to care just a little bit about this?
>if you search one of the above companies say that there products are already powerful enough not to need ush things, which given some of the physics I've seen in some of the more recent games is quite true, although I still wonder how much the CPU plays part, not the GPU.
Until I can fire a rocket launcher into a wall in a FPS and actually have that wall blow up instead of just leaving a scorch mark, the physics isn't realistic enough.
The HP 200LX would be my favorite piece of tech nostalgia. A tiny 80x86 based PDA from the mid-90's, it had excellent PIM software and Lotus 1-2-3 in ROM, plus ran DOS programs at CGA resolution.
Coupled with the DOS version of Derive, a symbolic mathematics package not unlike a cut down version of Mathematica, it beats the HP-48GX hands down.
There's a large/. fraternity who will jump on anyone who proposes anything outside the current scientific orthodoxy. And yet here we are reminded that one of our foremost scientific forebears dabbled in a lot of stuff that, today, we see as rather esoteric (to be charitable).
Unorthodoxy is science is fine, as long as the resulting discoveries are repeatable / provable.
Pseudo-science is still pseudo-science, no matter how many fine minds have indulged in it.
>In such a case, a copyright violation has been committed and you have to remove the code in question, and possibly pay damages.
That doesn't change a thing! While that's better than having to open source their codebase, those consequences are quite severe. Doing a recall and emergency fix would be extremely expensive in terms of cost and in terms of customer satisfaction and confidence.
Sad as it is, for the grandparent's poster's company, running the GPL code scanner is still the right thing to do.
Whoa there, son. Whatever MS's sins, that ain't one of them. Sega was killed by Sony and their own incompetent management. Xbox was barely a glimmer on the horizon at that point.
That means a company that aims to base itself on a piece of software is very unlikely to pick an obscure project with a single author and no documentation.
Indeed, but that's a far cry from "...you can take the latest code, latest R&D that was just made, and change it any way you like the same day..."
Moreover, what you just said was the point of the original Register article: that companies wishing to use OSS should create such a policy to avoid getting burned.
From there, one gets into service contracts and SLAs (since businesspeople tend to be conservative about areas outside of their core business), that, in turn, leads to growth of one or two projects in a category at the expense of the others (the equivalent of consolidation, except that the competitors don't actually die), and thence to large OSS companies not unlike their closed source competitiors.
Definitely not the form of OSS we've all been hoping for, but I fail to see the weak link in his logic.
However, with open source, you can take the latest code, latest R&D that was just made, and change it any way you like the same day, unlike closed source where you would have to duplicate the R&D yourself.
I believe his point was that if the author is unavailable (either abandaoned the project or too busy to take on your contract), the costs of paying somebody to learn the code sufficiently to make changes and to re-validate the system (QA is part of the process too) are a significant fraction of the costs of re-developing the project. I find that hard to argue with.
Good sir, I have the utmost respect for your role as the educator of future generations but your defense would have been more convincing had you actually known how to spell "capice".
Probably the worst thing ever adopted by the education system, IMHO, is PowerPoint.
Pah, that's nothing new. Instructors were doing this way before Powerpoint using canned lecture notes written using dry-erase markers on acetate sheets with an overhead projector.
That is certainly important. Free Software encourages diversity. back in the day, even in the world of proprietary software, people had alternatives, they would ask you what OS you run, if you had a gui or not, what word processor you used, or what spreadsheet, what browser, etc.
Yeah, and it was a bitch and a half to support. One of the things holding OSS back is an excess of diversity: a profusion of subtly differnt distros, a plethora of package managers, a panopoly of window managers, etc. Diversity is fine if (for example) the steps for installation or troubleshooting of any given software package does not depend on what else you're using; otherwise it's an unmanageable mess.
>Question: Whilst I appreciate it's probably a good idea to know a bit of C#, VB.Net and Windows stuff, and there seems to be the demand out there, am I right in thinking that MS technologies (Windows and.Net primarily) aren't as great a choice to base a career on as they first appear?
Unlike the other guy, I suggest that thinking about basing your career on any particular platform is the wrong attitude to take. Remember what happened to the mainframe and COBOL guys?
The only thing your career should be based on are a solid knowledge of the fundamentals of your trade (programming language, computer architecture, algorithmic theory, and the like) and a desire to keep up on current technologies and platforms. Focus on the platform you prefer, but keep enough knowledge of the other major platform(s) that you could orient yourself quickly if you had to work on it.
It isn't easy by any means. However, if you can manage it, you will always be ahead of the pack, regardless of whether the fruity OSS zealots or the evil M$ drones win.
>QA may resolve the issues but it doesn't prevent someone upstream from making a mistake with the requirements or the design document.
That may be the case where you work. Here, QA gets input into the requirements and the design. I've lost count of the times I or my colleagues have pointed out "Hey, it's physically impossible for that to work." or "The product would be greatly improved if we did this...".
>If the design is flawed, that is none of your business in Quality. That is up to the programmers. You tell the programmers that their program does not meet the requirements, and explain why, and how to get the same results.
None of my business, huh? If you're happy working on something that meets the docs but you know doesn't meet the actual needs of the project, more power to you. I've got better things to do with my life and another bankruptcy just means that my company gets a bigger slice of the pie.:P
>If you don't agree on the requirements, you contact the customer and find out exactly what the customer meant.
>The programmers fix the design if necessary, but the design is based around the requirements and Quality should develop test cases in parallel with the Coding developing a design document.
>And btw, the best docs, in my opinion do depict what the program does. State charts are the best documentation available in most cases, and many times, the only documentation that matters.
Slashdot Mirror
>Look, being disabled means there are some thing you are not able to do.
Kid, go and take a look at your grandparents. Take a good, long look. Do you plan to stop using a computer when you're their age? No more games, no more surfing the web?
I didn't think so, punk. *Now* do you see why you might want to care just a little bit about this?
>if you search one of the above companies say that there products are already powerful enough not to need ush things, which given some of the physics I've seen in some of the more recent games is quite true, although I still wonder how much the CPU plays part, not the GPU.
Until I can fire a rocket launcher into a wall in a FPS and actually have that wall blow up instead of just leaving a scorch mark, the physics isn't realistic enough.
>"Hayabusa is sure to have succeeded in asteroid sampling! It found the Target Marker with 880,000 names."
This refers to a promotional program by ISAS (see here) where people could submit their name to be microengraved on the target marker.
>It basically boils down to if you make good games, I'll buy. But, if you put out crap, I won't.
Ah, if this only worked with employees. If I'm not satisified with the work done this month, I won't pay you.
Fair is fair, isn't it?
The only way I can visualize to unify my mail and calendar involves a car crusher.
The HP 200LX would be my favorite piece of tech nostalgia. A tiny 80x86 based PDA from the mid-90's, it had excellent PIM software and Lotus 1-2-3 in ROM, plus ran DOS programs at CGA resolution.
Coupled with the DOS version of Derive, a symbolic mathematics package not unlike a cut down version of Mathematica, it beats the HP-48GX hands down.
>If it is growth we're interested in, why not call it "Viagrux"?
I'm not sure anyone would want an OS where it's considered a problem if it stays up for more than a couple of hours.
>Yes, for people who want to make easy money on work done by community people.
Yeah, like Red Hat and IBM. That Linus is such a chump.
Oh, is that not what you meant? So sorry.
>The problem with the system is I can't own a damn thing anymore.
Anymore? Read up on copyright law. You never owned anything in the first place.
There's a large /. fraternity who will jump on anyone who proposes anything outside the current scientific orthodoxy. And yet here we are reminded that one of our foremost scientific forebears dabbled in a lot of stuff that, today, we see as rather esoteric (to be charitable).
Unorthodoxy is science is fine, as long as the resulting discoveries are repeatable / provable.
Pseudo-science is still pseudo-science, no matter how many fine minds have indulged in it.
>Does anyone else see this movie as a $75Mil+ Halo3 commercial meant almost solely to steal thunder from the PS3 and Rev's launches?
*cough*Pokemon*cough*
>Marvel sued WWF/E for using "Hulk" in Hulk Hogan and won. I can not help but wonder if they have TMed "Magneto" too.
Magneto is a word that has a separate definition from the Marvel villian.
>In such a case, a copyright violation has been committed and you have to remove the code in question, and possibly pay damages.
That doesn't change a thing! While that's better than having to open source their codebase, those consequences are quite severe. Doing a recall and emergency fix would be extremely expensive in terms of cost and in terms of customer satisfaction and confidence.
Sad as it is, for the grandparent's poster's company, running the GPL code scanner is still the right thing to do.
>You don't want to be designing while in final production do you? That would be stupid.
Well, if you believe some of voices in the software industry and computer science, yes, you do.
(Which is not to say that I believe them yet.)
>Sega is now dead as a console manufacturer...
Whoa there, son. Whatever MS's sins, that ain't one of them. Sega was killed by Sony and their own incompetent management. Xbox was barely a glimmer on the horizon at that point.
That means a company that aims to base itself on a piece of software is very unlikely to pick an obscure project with a single author and no documentation.
Indeed, but that's a far cry from "...you can take the latest code, latest R&D that was just made, and change it any way you like the same day..."
Moreover, what you just said was the point of the original Register article: that companies wishing to use OSS should create such a policy to avoid getting burned.
From there, one gets into service contracts and SLAs (since businesspeople tend to be conservative about areas outside of their core business), that, in turn, leads to growth of one or two projects in a category at the expense of the others (the equivalent of consolidation, except that the competitors don't actually die), and thence to large OSS companies not unlike their closed source competitiors.
Definitely not the form of OSS we've all been hoping for, but I fail to see the weak link in his logic.
However, with open source, you can take the latest code, latest R&D that was just made, and change it any way you like the same day, unlike closed source where you would have to duplicate the R&D yourself.
I believe his point was that if the author is unavailable (either abandaoned the project or too busy to take on your contract), the costs of paying somebody to learn the code sufficiently to make changes and to re-validate the system (QA is part of the process too) are a significant fraction of the costs of re-developing the project. I find that hard to argue with.
>It's "capisce".
A typo on my part. The AC is indeed correct.
>Kapeesh?
Ow, my eyes.
Good sir, I have the utmost respect for your role as the educator of future generations but your defense would have been more convincing had you actually known how to spell "capice".
Probably the worst thing ever adopted by the education system, IMHO, is PowerPoint.
Pah, that's nothing new. Instructors were doing this way before Powerpoint using canned lecture notes written using dry-erase markers on acetate sheets with an overhead projector.
That is certainly important. Free Software encourages diversity. back in the day, even in the world of proprietary software, people had alternatives, they would ask you what OS you run, if you had a gui or not, what word processor you used, or what spreadsheet, what browser, etc.
Yeah, and it was a bitch and a half to support. One of the things holding OSS back is an excess of diversity: a profusion of subtly differnt distros, a plethora of package managers, a panopoly of window managers, etc. Diversity is fine if (for example) the steps for installation or troubleshooting of any given software package does not depend on what else you're using; otherwise it's an unmanageable mess.
Bugger diversity. Whatever happened to standards?
>Question: Whilst I appreciate it's probably a good idea to know a bit of C#, VB.Net and Windows stuff, and there seems to be the demand out there, am I right in thinking that MS technologies (Windows and .Net primarily) aren't as great a choice to base a career on as they first appear?
Unlike the other guy, I suggest that thinking about basing your career on any particular platform is the wrong attitude to take. Remember what happened to the mainframe and COBOL guys?
The only thing your career should be based on are a solid knowledge of the fundamentals of your trade (programming language, computer architecture, algorithmic theory, and the like) and a desire to keep up on current technologies and platforms. Focus on the platform you prefer, but keep enough knowledge of the other major platform(s) that you could orient yourself quickly if you had to work on it.
It isn't easy by any means. However, if you can manage it, you will always be ahead of the pack, regardless of whether the fruity OSS zealots or the evil M$ drones win.
>Don't be fooled. Microsoft is the new Microsoft, and the old Microsoft.
I thought Microsoft was the new IBM.
(Kids these days don't even know their computer history it seems...)
>QA may resolve the issues but it doesn't prevent someone upstream from making a mistake with the requirements or the design document.
:P
That may be the case where you work. Here, QA gets input into the requirements and the design. I've lost count of the times I or my colleagues have pointed out "Hey, it's physically impossible for that to work." or "The product would be greatly improved if we did this...".
>If the design is flawed, that is none of your business in Quality. That is up to the programmers. You tell the programmers that their program does not meet the requirements, and explain why, and how to get the same results.
None of my business, huh? If you're happy working on something that meets the docs but you know doesn't meet the actual needs of the project, more power to you. I've got better things to do with my life and another bankruptcy just means that my company gets a bigger slice of the pie.
>If you don't agree on the requirements, you contact the customer and find out exactly what the customer meant.
>The programmers fix the design if necessary, but the design is based around the requirements and Quality should develop test cases in parallel with the Coding developing a design document.
>And btw, the best docs, in my opinion do depict what the program does. State charts are the best documentation available in most cases, and many times, the only documentation that matters.
No argument with that.
If design is flawed, what should QA do?
QA prevents that from happening in the first place
If docs are porly written, and incomplete, how does one decide what's bug an what's feature?
QA prevents that from happening in the first place
If the docs depict the program's behavior, not define it, what can QA do?
QA prevents that from happening in the first place
And yes, if everythign is done right from the beginning, the QA people would have enough time to do something except testing.
Sounds like your company needs to develop a real QA process.