I agree. XP is like music in the ears of managers who handle projects and developers which already suck (BTW, Kent Beck is a consultant). XP is not meant to be applied by good developers.
It is quite interesting that you say this since a frequent criticism of XP is that it only works well for teams of good developers, who would presumably do pretty well using most methodologies. I can't see why managers would be so keen on XP either, since most managers would probably prefer methodologies which promise repeatable results.
In order to write good (stable, maintainable, extendible, generic, efficient,...) software efficiently, you want to minimize the overhead (tests, refactoring, redesign, debugging). This can only be achieved by good upfront design skills and applying them as early as possible.
Oh, you call tests and refactoring overhead! Um, have you ever noticed that when a developer adds a feature to some software, or fixes a bug, there is a significant chance that he breaks the software. Therefore, if there are no tests in place he will have to test manually, which is a lot slower.
If the code is well written, there's few need for writing tests (except for sophisticated algorithms), almost no need for refactoring (except for really simple ones like moving/renaming), redesign or debugging.
Riiight, and if the system is actually useful the people who use it will want you to extend it. Or maybe they only use certain parts of it and want a more lightweight configuration with just some additional features. Or, maybe the system needs to be integrated with webservice X and legacy system Y. The point is that the designer, no matter how good he/she is, could possibly anticipate which one of these scenarios actually happened. Therefore either the design takes all of them into account, which means the system is incredibly bloated (not necessarily in execution but design-wise), or alternatively you will have to do redesign and/or refactoring. Both of these are a lot nicer to do if you have unit tests in place. That is why XP advocates unit tests and refactoring together. XP is not inherently anti-design. XP is geared towards application areas where requirements change frequently. Up-front design is therefore replaced with continuous redesign using refactoring. It should also be noted that other agile methodologies are not quite as radical as XP on this point, and they usually recommend a short up-front design period at the beginning of the project and/or iteration.
Unfortunately good OO design is a hard to learn skill and I haven't seen a good book on this yet.
Maybe Gamma et al. and Design Patterns could be a start.
Who will have authority to kill the said processes? Will the ability for those authorities to do so be implemented in the OS?
I thought the same thing. Having this type of infrastructure in the OS would probably create a lot more problems than it would solve. The OS of the compromised system can't possibly know which of its processes are hostile, so it must allow remote sysadmins to kill all processes. That can't possibly work in practice so some kind of filtering of what processes may be killed remotely is needed. The only sensible way of filtering, that I can think of from the top of my head, would be to allow remote users to kill only processes that interact with their machine, for instance the web-server box could kill web-client processes that connect to it. Now this would make sense to a point but still sounds like something that could be abused in a hostile environment by spoofing etc.
The author might of course also mean that the processes should be killed by attacking the infected computer through the same security hole that the original worm/virus used. Using this security hole the infected computer could be cleaned, and even patched. Now this scheme just might work, but it's probably illegal and perhaps immoral as well. I at least wouldn't like it if my machine would be patched remotely without notifying me. It might of course inspire worm writers to have the worm fix the security hole it uses by itself, which would be kind of amusing
For playing media there are already many solutions for all intersting platforms, and the only reason for using WMP would be for the DRM stuff...which no-one honestly likes.
This is so very true. If I have understood correctly, and chances are that I haven't so feel free to correct me, the MS DRM-scheme relies on the client program playing nicely and not allowing copying of the content. If this is the case then open-source implementations of this scheme are impossible, even though the article seems to imply otherwise. In that case it would simply mean being able to use the media through a close sourced player. Maybe nice in some cases but certainly not great news.
Even Extreme Programming does not remove the dependency of needing a super-star on the team.
I think you are right about XP depending on having a good team. The fundamental idea in XP is to make software more change friendly (automatic testing, refactoring, collective code ownership, pair programming), and this in turn allows design-as-you-go to be an efficient practice. The reason that up-front design is traditionally considered so valuable is that the cost of changing software seems to grow very fast during the project. If the cost of change is lower it might become feasible to design as you go instead.
Since I haven't tried XP in any real project, I can't claim I know it would work in practice but the idea is very interesting. Since XP might be a little too extreme (that's why it's called eXtreme Programming) there are other methodologies that are philosophically similar but less demanding (so called Agile methodologies) that one might try instead.
You are primarily speaking about design where Paul Graham was speaking of actual code. It should be noticed that even they are called _design_ patterns, they are actually patterns in program code. The point he was trying to make in this article was that regularities in code are a sign of the human compiler at work, and that means that the programmer is doing the job that the compiler should be doing. As an example of how it would work, consider the Singleton pattern you mentioned. Instead of doing something like this:
public class Foo{
private static Foo instance = null;
private Foo(){
}
public static getInstance(){
if(instance == null){
instance = new Foo()
}
return instance;
} }
You should be able to write an abstraction Singleton declaring something similar to the above code (this would be the macro Paul Graham was recommending). After this you could write:
public class Singleton Foo
(or something similar). Now this way the Singleton code would not be duplicated. Note that I personally do find design patterns a very powerful technique, and am not trying to dis them like Paul Graham was. However I would find it very neat if one could define Singletons as I described above.
And imagine all the people nowadays protesting against the unequal distribution of wealth moving to this game to collect enormous hordes of game characters and start attacking the succesful characters. The rich and succesful have no other options than running armies to protect themselves. The barbarian hordes keep growing as a reaction to the imperialism of the good players and so on, apply recursively a few hundred times and we have created a simulation of the real world...
I wonder what kinds of action the good players(tm) would take against game terrorists who sacrifice their own character to kill another one. Not to mention weaponsmith and bard characters trying to enforce patents and copyrights to their respective works..
So if your classes don't change externally, there should be little merit to this argument. You can extend them just as well as before as you can after, performance considerations aside.
I think you confuse system external behaviour with class external behaviour. When you refactor you might very well change class external structure, but you don't change system external behaviour (that is add features).
Then once the system is well factored it is easier to make changes that change the system external behaviour.
You certainly have a point about sucky coders creating sucky code. However many times programs that are initially well designed get bloated with all sorts of cruft over time when features are added and requirements change. Requirement change tends to turn good designs into bad designs, since the original good design was for a different problem than the current program solves. This mess can often be cleaned up with refactoring. Often one is forced to work with code created by someone else, and if that code is messy, but not completely hopeless wonders can often be achieved by refactoring it.
Searches are logged by time of day, originating I.P. address (information that can be used to link searches to a specific computer), and the sites on which the user clicked.
How can they tell that? It looks to me as if the links point straight at the real site, instead of using some kind of redirect. Of course they can tell it for the ones that hit their own cache, but what about the others?
While I agree that well designed software SHOULD allow you to do this, not all software is well designed and it's a company's right to have crappily written software. The author seems to think that the good software police have some right to chastise these companies. Well, ya don't. Get over it.
The point he was trying to make was that it is hard to release badly designed software with source since it would be difficult to remove the unique (or protectable) parts when the program is badly factored.
Furthurmore, the author makes the assumption that these removed subroutines can't be substituted by something else. If open source authors can deliver a functional, quality OS, they can figure out a couple subroutines and replace them.
Well, yes of course you can replace these routines, but the point was that the original source code which was removed contained some clever algorithm that needed to be protected. So if someone replaces these routines with well known algorithms that achieve the same thing, the resulting program will probably be slower and use more memory.
Could you explain to me why it would be so terrible if hackers would fill in the missing part? What would they do with the resulting program? Sell it? Remember the author advocates all source being open for inspection, so selling is impossible since the original company would accuse them for plagiarism. Copy it? Why then not just copy the binaries?
I think there is a much more serious flaw in the author's reasoning: If you can remove a part of the source for protection, why not hide most of the program? Tah-Dah! We have closed source software, but released with source so no one can complain. Possibly some people will even assume that the whole missing part is very very clever and that the people producing it are geniouses.
The point you raise about online games however is very valid, but I think that is a special case and that the ethics of open vs closed source should not be evaluated only based on it. One could probably solve it technically somehow (for instance use some kind of cryptographic verification of the running client binary, not sure how this would work but I don't believe it's impossible)
Well I've certainly heard of people copying DVDs as well. Once the data is off the disc in some other format the DVD protection mechanisms doesn't help very much. Even if all Joe Schmo's can't rip themselves they sure are capalble of downloading and distributing something someone else has ripped.
Net games are different from raw data (like music and video) because they interact with some sort of server, therefore they can make use of more elaborate copy-protection measures.
The DVD-quality issue is merely a question of bandwidth and storage capacity, it will go away soon enough.
Just to clear my own standpoint on these issues: I completely agree with you on your points about stealing and piracy. The reason I dislike this kind of copyright protection is not that it hinders piracy (to some extent) but that it removes freedoms that I find very useful. Playing the same music in your car is the obvious example. However what causes me to think such DRM technology is "stupid" is the fact that it is impossible to create an open implementation of the software since it depends on the "security by obscurity" principle. As soon as the source of the decoder would be available the security of the system would be compromised. What this means in practice is that all open implementations need to be made illegal. The DMCA makes this possible and it was this aspect that made me call it a "silly law". Basically it's the same argument as in the age-old discussion on open and closed fileformats: Should one party be allowed to control the format of everyones data, and therefore be in control of it?
Well obsoleting CDs makes sense only if there is a more "protectable" alternative. What would that be? Microsoft Palladium perhaps, since every digital medium is inherently copyable. Is this what you intended or is there some simpler alternative?
On the other hand, don't the record labels dislike the thought of MS having a monopoly in DRM systems?
So this means that if I wanted to become really dominant in a conversation, I could bribe a couple of the participators to look at me once in a while, and rarely at my "opponent"? Hmmm suddenly I realize that a sales team should never ever consist of under ten people...
Could someone explain to me how these people think? I mean they must know it will be hacked. At least the techies who actually create the products must know it will be hacked. So what's the point? Do they trust stupid laws like the DMCA to enforce their silly DRM systems?
What about ripping from the audio stream, is that illegal too? Does Sony 0wnz your audio output!? If not then this is still pretty pointless. One could of course argue that if it would be difficult enough to actually rip tracks most people would just pay for the music, but this is unlikely since the record labels don't control the distribution channels (the P2Ps) and therefore their distribution will initially be more difficult than its illegal counterpart.
Since I'm hardly an expert in medicine I won't make any guesses about which specific diseases could be cured if the inner workings of a cell were known. However I am sure that this knowledge would certainly be useful for this purpose. If this justifies carrying out such an experiment is a question everyone has to consider themselves. I personally think it's worth doing. I feel more comfortable with this kind of information being general knowledge in the medical community rather than having some hostile party carry out these same experiments by themselves and have a weapon that none but them know how to remedy.
What you say about Einstein and e=mc^2 misses the point a little bit. I agree that nuclear weapons have been used with terrible effects, but only for a few times. One could argue that the fact that there hasn't been any world wars since the introduction of nuclear weapons is because nobody dares to start one fearing the nuclear revenge. This is, by the way, the reason why the Nobel prizes are given, Alfred Nobel believed that world peace would be achieved if there were a frightning enough weapon. Then people would be discouraged from fighting wars. Therefore every year an award is given to researchers who have contributed to reaching this goal. And you certainly can't deny that nuclear fission has been used for peaceful purposes.
Not to be cynical but when will man reallize that playing god never pays off!
While it is certainly true that this experiment raises some ethical issues, I think your comment does even more so. I might be feeding a troll, but I would still like to point out that your argument is very weak.
Imagine the caveman Ugh showing the other caveman Ugh2 how to light a fire. Ugh gets a little burnt in the process and Ugh2 comments "when will man reallize that playing god never pays off".
I mean if we want to understand life experiments like the one in the article are probably necessary. The ethical issue is not (as I see it) that the scientists are messing with the DNA of some micro-organism (=playing god), but the fact that their results might be used for producing biological weapons.
Why should this "custom firewall" be considered a necessity that makes it completely impossible to use closed MS systems? I mean can't they just hide their network of MS computers behind a designated firewall using their custom scheme? I of course wouldn't mind MS opening their code but I don't see why this issue would require it?
The real problem is not the existance of high-level abstractions, but the fact that many programmers are unwilling or unable to understand the abstraction.
So you say "let's get rid of encapsulation". But that doesn't solve this problem, because this problem is one of laziness or incompetence rather than not being allowed to touch what's inside the box. Encapsulation solves an entirely different problem, that is the one of modularity. If we abolish encapsulation the same clueless programmers will just produce code that is totally dependent on some obscure property in a specific version of a library. They still won't understand what the library does, so we're in a worse position than when we started.
Not many games keep up with the features of new cards, so OpenGL doesn't have to be bleeding edge to run them.
You should take into account that it takes a significant amount of time to develop a game. One of the reasons games lag behind the cards is that people rarely like to code purely to the specs of some hypothetical next-generation card, and therefore wait until a card is released. Now if the 3D API is developed with a similar philosophy it will lag behind as well, and this will be a big deal to developers: Should I develop using the
1.OpenGL drivers which support current generation chips, which will be low-range or obsolete cards at the time of the game release
2.DirectX which supports current bleeding edge chips, which will be mid-range cards when the game is released
In what way is it safer to run (presumably) binary only installers as root on your system instead of remote shell scripts? I'm not saying it's safe to run remote shell scripts but a binary only installer could be used to compromise a system in exactly the same ways.
Quite the opposite of just writing code. In fact people just writing code is has spawned the so-called software crisis which in the nineteen seventies triggered the emergence of the software engineering research field.
While I do agree with you that "just writing code" might cause significant problems when developing software, blaming the software crisis purely on the lack of methodology implies that the crisis can be solved simply with more methodology.
Since software is still expensive to develop and maintain, buggy and insecure (and probably often over budget etc.), the "software crisis" still persists to some amount.
Since almost everyone has improved their processes since the seventies, and the problem still persists, just adding methodology cannot be the solution.
It should also be noted that light-weight methodologies (for example XP, Crystal* etc) are gaining popularity, because the heavyweight methodologies often waste too much time on producing and maintaining deliverables that strictly speaking are not needed to develop the actual software, and therefore make the development process less efficient. Therefore too much methodology is at least as bad as too little.
The C code is not that smart. It tries once per hour to connect to port 6667 on the machine 203.62.158.32 which is web.snsonline.net and waits for commands from the person or persons who 0wn3d the machine. Does it get an M, it sleeps for another hour. Does it get an A, it will abort. Does it get M, it will spawn a shell
Slashdot Mirror
I agree. XP is like music in the ears of managers who handle projects and developers which already suck (BTW, Kent Beck is a consultant). XP is not meant to be applied by good developers.
...) software efficiently, you want to minimize the overhead (tests, refactoring, redesign, debugging). This can only be achieved by good upfront design skills and applying them as early as possible.
It is quite interesting that you say this since a frequent criticism of XP is that it only works well for teams of good developers, who would presumably do pretty well using most methodologies. I can't see why managers would be so keen on XP either, since most managers would probably prefer methodologies which promise repeatable results.
In order to write good (stable, maintainable, extendible, generic, efficient,
Oh, you call tests and refactoring overhead! Um, have you ever noticed that when a developer adds a feature to some software, or fixes a bug, there is a significant chance that he breaks the software. Therefore, if there are no tests in place he will have to test manually, which is a lot slower.
If the code is well written, there's few need
for writing tests (except for sophisticated algorithms), almost no need for refactoring (except for really simple ones like moving/renaming), redesign or debugging.
Riiight, and if the system is actually useful the people who use it will want you to extend it. Or maybe they only use certain parts of it and want a more lightweight configuration with just some additional features. Or, maybe the system needs to be integrated with webservice X and legacy system Y. The point is that the designer, no matter how good he/she is, could possibly anticipate which one of these scenarios actually happened. Therefore either the design takes all of them into account, which means the system is incredibly bloated (not necessarily in execution but design-wise), or alternatively you will have to do redesign and/or refactoring. Both of these are a lot nicer to do if you have unit tests in place. That is why XP advocates unit tests and refactoring together.
XP is not inherently anti-design. XP is geared towards application areas where requirements change frequently. Up-front design is therefore replaced with continuous redesign using refactoring. It should also be noted that other agile methodologies are not quite as radical as XP on this point, and they usually recommend a short up-front design period at the beginning of the project and/or iteration.
Unfortunately good OO design is a hard to learn skill and I haven't seen a good book on this yet.
Maybe Gamma et al. and Design Patterns could be a start.
Who will have authority to kill the said processes? Will the ability for those authorities to do so be implemented in the OS?
I thought the same thing. Having this type of infrastructure in the OS would probably create a lot more problems than it would solve. The OS of the compromised system can't possibly know which of its processes are hostile, so it must allow remote sysadmins to kill all processes. That can't possibly work in practice so some kind of filtering of what processes may be killed remotely is needed. The only sensible way of filtering, that I can think of from the top of my head, would be to allow remote users to kill only processes that interact with their machine, for instance the web-server box could kill web-client processes that connect to it. Now this would make sense to a point but still sounds like something that could be abused in a hostile environment by spoofing etc.
The author might of course also mean that the processes should be killed by attacking the infected computer through the same security hole that the original worm/virus used. Using this security hole the infected computer could be cleaned, and even patched. Now this scheme just might work, but it's probably illegal and perhaps immoral as well. I at least wouldn't like it if my machine would be patched remotely without notifying me. It might of course inspire worm writers to have the worm fix the security hole it uses by itself, which would be kind of amusing
For playing media there are already many solutions for all intersting platforms, and the only reason for using WMP would be for the DRM stuff...which no-one honestly likes.
This is so very true. If I have understood correctly, and chances are that I haven't so feel free to correct me, the MS DRM-scheme relies on the client program playing nicely and not allowing copying of the content. If this is the case then open-source implementations of this scheme are impossible, even though the article seems to imply otherwise. In that case it would simply mean being able to use the media through a close sourced player. Maybe nice in some cases but certainly not great news.
Even Extreme Programming does not remove the dependency of needing a super-star on the team.
I think you are right about XP depending on having a good team. The fundamental idea in XP is to make software more change friendly (automatic testing, refactoring, collective code ownership, pair programming), and this in turn allows design-as-you-go to be an efficient practice. The reason that up-front design is traditionally considered so valuable is that the cost of changing software seems to grow very fast during the project. If the cost of change is lower it might become feasible to design as you go instead.
Since I haven't tried XP in any real project, I can't claim I know it would work in practice but the idea is very interesting. Since XP might be a little too extreme (that's why it's called eXtreme Programming) there are other methodologies that are philosophically similar but less demanding (so called Agile methodologies) that one might try instead.
You should be able to write an abstraction Singleton declaring something similar to the above code (this would be the macro Paul Graham was recommending). After this you could write:
(or something similar). Now this way the Singleton code would not be duplicated. Note that I personally do find design patterns a very powerful technique, and am not trying to dis them like Paul Graham was. However I would find it very neat if one could define Singletons as I described above.
And imagine all the people nowadays protesting against the unequal distribution of wealth moving to this game to collect enormous hordes of game characters and start attacking the succesful characters. The rich and succesful have no other options than running armies to protect themselves. The barbarian hordes keep growing as a reaction to the imperialism of the good players and so on, apply recursively a few hundred times and we have created a simulation of the real world...
I wonder what kinds of action the good players(tm) would take against game terrorists who sacrifice their own character to kill another one. Not to mention weaponsmith and bard characters trying to enforce patents and copyrights to their respective works..
Anyone actually tried this?
What is the performance like when BSD is emulating linux which is emulating windows?
So if your classes don't change externally, there should be little merit to this argument. You can extend them just as well as before as you can after, performance considerations aside.
I think you confuse system external behaviour with class external behaviour. When you refactor you might very well change class external structure, but you don't change system external behaviour (that is add features).
Then once the system is well factored it is easier to make changes that change the system external behaviour.
You certainly have a point about sucky coders creating sucky code. However many times programs that are initially well designed get bloated with all sorts of cruft over time when features are added and requirements change. Requirement change tends to turn good designs into bad designs, since the original good design was for a different problem than the current program solves. This mess can often be cleaned up with refactoring. Often one is forced to work with code created by someone else, and if that code is messy, but not completely hopeless wonders can often be achieved by refactoring it.
Searches are logged by time of day, originating I.P. address (information that can be used to link searches to a specific computer), and the sites on which the user clicked.
How can they tell that? It looks to me as if the links point straight at the real site, instead of using some kind of redirect. Of course they can tell it for the ones that hit their own cache, but what about the others?
While I agree that well designed software SHOULD allow you to do this, not all software is well designed and it's a company's right to have crappily written software. The author seems to think that the good software police have some right to chastise these companies. Well, ya don't. Get over it.
The point he was trying to make was that it is hard to release badly designed software with source since it would be difficult to remove the unique (or protectable) parts when the program is badly factored.
Furthurmore, the author makes the assumption that these removed subroutines can't be substituted by something else. If open source authors can deliver a functional, quality OS, they can figure out a couple subroutines and replace them.
Well, yes of course you can replace these routines, but the point was that the original source code which was removed contained some clever algorithm that needed to be protected. So if someone replaces these routines with well known algorithms that achieve the same thing, the resulting program will probably be slower and use more memory.
Could you explain to me why it would be so terrible if hackers would fill in the missing part? What would they do with the resulting program? Sell it? Remember the author advocates all source being open for inspection, so selling is impossible since the original company would accuse them for plagiarism. Copy it? Why then not just copy the binaries?
I think there is a much more serious flaw in the author's reasoning: If you can remove a part of the source for protection, why not hide most of the program? Tah-Dah! We have closed source software, but released with source so no one can complain. Possibly some people will even assume that the whole missing part is very very clever and that the people producing it are geniouses.
The point you raise about online games however is very valid, but I think that is a special case and that the ethics of open vs closed source should not be evaluated only based on it. One could probably solve it technically somehow (for instance use some kind of cryptographic verification of the running client binary, not sure how this would work but I don't believe it's impossible)
Well I've certainly heard of people copying DVDs as well. Once the data is off the disc in some other format the DVD protection mechanisms doesn't help very much. Even if all Joe Schmo's can't rip
themselves they sure are capalble of downloading and distributing something someone else has ripped.
Net games are different from raw data (like music and video) because they interact with some sort of server, therefore they can make use of more elaborate copy-protection measures.
The DVD-quality issue is merely a question of bandwidth and storage capacity, it will go away soon enough.
Just to clear my own standpoint on these issues: I completely agree with you on your points about stealing and piracy. The reason I dislike this kind of copyright protection is not that it hinders piracy (to some extent) but that it removes freedoms that I find very useful. Playing the same music in your car is the obvious example. However what causes me to think such DRM technology is "stupid" is the fact that it is impossible to create an open implementation of the software since it depends on the "security by obscurity" principle. As soon as the source of the decoder would be available the security of the system would be compromised. What this means in practice is that all open implementations need to be made illegal. The DMCA makes this possible and it was this aspect that made me call it a "silly law". Basically it's the same argument as in the age-old discussion on open and closed fileformats: Should one party be allowed to control the format of everyones data, and therefore be in control of it?
Well obsoleting CDs makes sense only if there is a more "protectable" alternative. What would that be? Microsoft Palladium perhaps, since every digital medium is inherently copyable. Is this what you intended or is there some simpler alternative?
On the other hand, don't the record labels dislike the thought of MS having a monopoly in DRM systems?
So this means that if I wanted to become really dominant in a conversation, I could bribe a couple of the participators to look at me once in a while, and rarely at my "opponent"? Hmmm suddenly I realize that a sales team should never ever consist of under ten people...
Could someone explain to me how these people think? I mean they must know it will be hacked. At least the techies who actually create the products must know it will be hacked. So what's the point? Do they trust stupid laws like the DMCA to enforce their silly DRM systems?
What about ripping from the audio stream, is that illegal too? Does Sony 0wnz your audio output!? If not then this is still pretty pointless. One could of course argue that if it would be difficult enough to actually rip tracks most people would just pay for the music, but this is unlikely since the record labels don't control the distribution channels (the P2Ps) and therefore their distribution will initially be more difficult than its illegal counterpart.
Since I'm hardly an expert in medicine I won't make any guesses about which specific diseases could be cured if the inner workings of a cell were known. However I am sure that this knowledge would certainly be useful for this purpose. If this justifies carrying out such an experiment is a question everyone has to consider themselves. I personally think it's worth doing. I feel more comfortable with this kind of information being general knowledge in the medical community rather than having some hostile party carry out these same experiments by themselves and have a weapon that none but them know how to remedy.
What you say about Einstein and e=mc^2 misses the point a little bit. I agree that nuclear weapons have been used with terrible effects, but only for a few times. One could argue that the fact that there hasn't been any world wars since the introduction of nuclear weapons is because nobody dares to start one fearing the nuclear revenge. This is, by the way, the reason why the Nobel prizes are given, Alfred Nobel believed that world peace would be achieved if there were a frightning enough weapon. Then people would be discouraged from fighting wars. Therefore every year an award is given to researchers who have contributed to reaching this goal.
And you certainly can't deny that nuclear fission has been used for peaceful purposes.
Not to be cynical but when will man reallize that playing god never pays off!
While it is certainly true that this experiment raises some ethical issues, I think your comment does even more so. I might be feeding a troll, but I would still like to point out that your argument is very weak.
Imagine the caveman Ugh showing the other caveman Ugh2 how to light a fire. Ugh gets a little burnt in the process and Ugh2 comments "when will man reallize that playing god never pays off".
I mean if we want to understand life experiments like the one in the article are probably necessary. The ethical issue is not (as I see it) that the scientists are messing with the DNA of some micro-organism (=playing god), but the fact that their results might be used for producing biological weapons.
Why should this "custom firewall" be considered a necessity that makes it completely impossible to use closed MS systems? I mean can't they just hide their network of MS computers behind a designated firewall using their custom scheme? I of course wouldn't mind MS opening their code but I don't see why this issue would require it?
The real problem is not the existance of high-level abstractions, but the fact that many programmers are unwilling or unable to understand the abstraction.
So you say "let's get rid of encapsulation". But that doesn't solve this problem, because this problem is one of laziness or incompetence rather than not being allowed to touch what's inside the box. Encapsulation solves an entirely different problem, that is the one of modularity. If we abolish encapsulation the same clueless programmers will just produce code that is totally dependent on some obscure property in a specific version of a library. They still won't understand what the library does, so we're in a worse position than when we started.
Not many games keep up with the features of new cards, so OpenGL doesn't have to be bleeding edge to run them.
You should take into account that it takes a significant amount of time to develop a game.
One of the reasons games lag behind the cards is that people rarely like to code purely to the specs of some hypothetical next-generation card, and therefore wait until a card is released. Now if the 3D API is developed with a similar philosophy it will lag behind as well, and this will be a big deal to developers:
Should I develop using the
1.OpenGL drivers which support current generation chips, which will be low-range or obsolete cards at the time of the game release
2.DirectX which supports current bleeding edge chips, which will be mid-range cards when the game is released
In what way is it safer to run (presumably) binary only installers as root on your system instead of remote shell scripts? I'm not saying it's safe to run remote shell scripts but a binary only installer could be used to compromise a system in exactly the same ways.
While I do agree with you that "just writing code" might cause significant problems when developing software, blaming the software crisis purely on the lack of methodology implies that the crisis can be solved simply with more methodology.
Since software is still expensive to develop and maintain, buggy and insecure (and probably often over budget etc.), the "software crisis" still persists to some amount.
Since almost everyone has improved their processes since the seventies, and the problem still persists, just adding methodology cannot be the solution.
It should also be noted that light-weight methodologies (for example XP, Crystal* etc) are gaining popularity, because the heavyweight methodologies often waste too much time on producing and maintaining deliverables that strictly speaking are not needed to develop the actual software, and therefore make the development process less efficient. Therefore too much methodology is at least as bad as too little.
Except if the port was closed recently when this whole thing came out?
From the weblog:
The C code is not that smart. It tries once per hour to connect to port 6667 on the machine 203.62.158.32 which is web.snsonline.net and waits for commands from the person or persons who 0wn3d the machine. Does it get an M, it sleeps for another hour. Does it get an A, it will abort. Does it get M, it will spawn a shell
I guess this answers your question