Isn't a freenet key not much bigger than the size of a link ?
That is correct. In fact, they are URLs.
Wouldn't that just shift the problem into Freenet, so that we would just slashdot Freenet when there was a suddenly popular file, and there would be this painful lag until Freenet cached stuff at enough nodes ?
You can't really slashdot freenet because information is not stored on any single host. There would be an initial lag - that's true for any new file unless it was released to your own node - but once a popular file propagates through the network, access should be pretty fast. Systems like freenet are actually more suitable for popular material than systems like Gnutella because they cache their files at intermediate nodes, therefore, the more requests, the greater the proliferation of the material.
I've been doing software for a long time now (13 years, professionally) and I've seen some of my cleanest, best documented designs go almost unused, and some of my quickest, dirtiest hacks grow into the cornerstones of the system.
Software development is about dealing with change. Requirements change. Technologies change. Business plans change. Development teams change. Sometimes when we try to do the right thing, plan everything out, document it, create clean interfaces instead of holes in the wall... what we're really doing is betting against change, and that's always a longshot.
The best way to design, IMHO, is to start with a few good quick hacks that solve the bulk of your problems. Then put it into production and let the feedback tell you what you need to do. What do the users like? Where is the redundant functionality that merits adding infrastructure? What parts of the system are most problematic? We never really understand what we develop until we've had to build on it for two or three generations.
So my advice is leave your hack in place. If you have to change it a month from now, and then a month after that, that's a good sign that it's something that's worth doing right. If not, then your hack was the right thing to do, after all.
If you want to insulate yourself against getting slammed in the face by that hack, the best investment of your time is to write some good test suites. This way, if you add something that breaks your hack, you know about it quickly.
Just my little contribution to the background noise:-)
But get, in "writing" (email), confirmation from the powers that be that you're circumventing procedures in order to get the work done within the timeframe needed.
Doh! That could take longer than writing the code the clean and proper way.
I've written some pretty large applications using C++ and I've never had "problems"
Never had problems? That's quite a claim. Never spent a week tracking down an obscure seg-fault? Never spent days getting your working code to compile on a different compiler? Never ran into obscure errors because an executable had not been recompiled against a changed shared library?
If not, you should publish your insights, cause I'd really like to know how you're avoiding these kinds of things.
I see nothing in the author's statement as strong as "C++ must die" - he just says "it's lousy for development time" and lists his reasons why. He opens with "C/C++ is no longer a viable development language", but I think you have consider that to be in the context of Open Source Application Development - which is, after all, what he's doing. I don't think he is advocating rewriting the Linux kernel in Python.
Your point is well taken: most of us would certainly consider Linux and BSD to be "Unix" even though neither is certified.
However, you must admit that there is a difference between casual/common branding (like if someone says in a book "BSD is a flavor of Unix") and the explicit use of this trademark in the advertising of a commercial product.
AFAIK neither Linux nor BSD has ever been distributed as "Unix". In fact, the "GNU" acronym is pretty much an inversion of this trademark.
I'll be interested to see how the courts decide on this: I'm guessing that the failure to enforce casual use will not impede action against commercial use. Anyone know of any precedents?
Unix has become a generic term. Removing trademark status would benefit not only Apple, but the free Unixes, Linux and the BSDs.
I think there might be a little more to it than that. Just got done reading ESR's OSI Position on the SCO-vs-IBM suit paper, and it looks like the right to use the Unix trademark is conferred upon vendors who go through a certification process to confirm compliance to Unix standards.
So it's sort of like if somebody slaps the famous "compact disc" logo on a copy-protected disc - you're advertising conformance to a standard that you don't conform to. That's not to say that apple is necessarily out of compliance with the standard, the point is that the "Unix" trademark is the TOG's "seal of approval".
It seems to me that there are two things that SCO can gain by this campaign: 1) FUDding Linux in the hopes of gaining *NIX market share and 2) getting money from lawsuits.
If they were to disclose the "stolen source code" then either their claims would be dismissed (because the similarities could be shown to be trivial or the code in question could be traced to a non-SCO source) or if their claims actually had merrit, then the problem code could simply be replaced . In either case, the game is over for SCO - the best they could do is sue whoever violated their CDA.
OTOH, by keeping the code in question secret, they can continue to propagate a FUD campaign against Linux. By allowing a select group to review the code, they can increase the likelihood that this group will advocate in their favor, thus strengthening the FUD attack.
In the worst case scenario, if SCO is successful in suing IBM and is able to keep the code from being publicly disclosed during the course of the trial (not sure if this is possible), then they have a powerful weapon. They could then proceed to sue every Linux distributor and there's nothing anyone could do about it - since no one knows what the "stolen code" is, no one would know what to remove and the only way to find out is to go through the lawsuit.
The latter scenario seems pretty unlikely - it seems far more likely that the only thing SCO will gain is the ability to cast FUD up until the conclusion of the trial. Unfortunately, this could take years, and could end up having a fairly significant effect on the adoption of Linux.
I'd like to see a very public legal counter-attack by the open-source community. Something like an FSF lawsuit on the grounds that by their own claims, SCO has implicitly violated the GPL. I can see where it might be hard to launch such an attack - hard to fight vapor, although SCO seems to be doing a pretty good job of fighting with vapor.
Hehe, tried getting this via Gamespot... went through the whole registration thing, tried to download and it couldn't do it because it wanted to install something on my system and I wasn't running IE (or Winblows, for that matter).
So then I tried to view it with Real, got through their promo screen and some race game advertisement and then got "requested file not found" when it actually tried to download the doom3 rm file.
So I tried BitTorrent (for the very first time) against the doom3 link on the page you provided, and whaddaya know, in like 30 seconds I had the mpg - no ads, no bullshit, and I get to help out others by providing upload bandwidth! Thanks dude!
As for the Lamespot thing, I'd be really pissed off if I had provided them with my actual identity:-)
"This is not about 10 lines of code, it's about 20 years of extremely valuable intellectual property we're trying to protect...Am I supposed to lie down and not say anything about it?" McBride said. "There's a certain point here where you stand up for what's right and let the chips fall where they will."
It's refreshing to see someone in today's business environment who's willing to really put it all on the line to protect all that is right and wholsome in the world.
The RIAA could use a man like this to help them sue evil college students who are threatening the very existence of those poor starving record company executives.
That's also true in the US. I work with a small company of career contractors. We are always the top tech guys in the client environment, and most of the other serious contractors I've met are the same way.
However, among many large companies, there is definitely a feeling that the contractors are "a level beneath" the perms, even if they are smarter and more productive. Because what it comes down to is that when the money gets tight, they're going to get rid of the contractors before firing any perms.
I'm not whining here, this is what I've signed up for and I wouldn't want it any other way. However, I do think a lot of consulting companies misrepresent the nature of the work to employees who are not necessarily interested in becoming "career contractors" - these guys get pay and benefits on the scale of normal employees but have all the job insecurity of contractors. From what I've seen, these are generally the people who would rather be perms.
What I find annoying is a) the consulting companies who are essentially misleading these people into thinking they have normal jobs and b) temps who think legal action against the clients is the appropriate course of action and end up screwing us career consultants in the process.
The kinds of usage patterns that you recommend have trade-offs associated with them: for example, if you create objects on the stack and use copy instead of reference semantics when moving them into other data structures, you're going to hurt your performance and bloat your code. I'm not saying that in general you shouldn't do these things, but there are definitely situations where passing around pointers and using memcpy() still makes more sense.
I should also note that I am a huge fan of auto_ptr and reference-counting templates in general, but there are a lot of subtleties to their use. For example, they don't deal with inheritence well, and there's the question of whether or not to expose the underlying pointer (allowing abuse) or not (requiring users to pass around references or copies of the managed pointer in situations where the raw pointer would be more efficient).
And that leads to my more general criticism of C++: coding in it is too much of an art. You need a greater level of understanding than you can expect from most programmers, and most people seem to write either inefficient code or buggy code (usually both).
I respectfully submit that the fact that you _can_ write unsafe code in a programming language _is_ a reason to avoid it! Particularly if the language makes it easy for you to shoot yourself in the foot and there are other languages available that a) don't have this weakness and b) allow you to code faster in the first place.
Tools like the STL definitely help, but they don't offer a guarantee against these kinds of problems. Like you said, you can still reference out of bounds indexes. Furthermore, you can still reference uninitialized pointers, double-free memory, and use objects before they're initialized.
Also, these kinds of abstractions have performance costs. At some point, these costs are going to mount until something like Java or.NET becomes competitive in terms of speed and memory footprint.
At their core, C and C++ are low-level programming languages. They're powerful because they're dangerous, and you should only use them when the situation demands it.
the added security is OK, but as pointed out in the article, high level languages aren't a silver bullet.
No, but they do remove several major classes of vulnerabilities that have a long history of being exploited. There's definitely a security advantage to them.
What's really needed is a decent component model, making it easier to choose the right language for the job, instead of choosing a langauge because that's what all the libraries are written for, or because that's what everybody else uses.
I quite agree. I seem to recall that there are several of these out there, but none has really caught on.
There's another advantage to low level languages: performance. Nothing runs as fast and loads as quick as machine code, and that's very important for something like "inet" and it's services: you want them to be always available, always responsive, and to consume as little of the systems resources as possible. A Java app with its 9 meg footprint just doesn't cut it.
I think the high level stuff is the way to go in the application space, but system services justify the extra time and effort (and risk) of being written in C.
Only I like to come in with the "I need $1200 to purchase this commercial package - unless you want me to use this competing open source package, which IMHO is a better product anyway" angle.
Last project I was on, management was blown away by the stability of our Linux servers. Even the Windows guys were impressed. When I left the group, they were using Linux as a dedicated DB/2 server platform (wouldn't switch their web servers because of the VB/.NET thing).
if they do then that was in the contract you signed. if a musician signs a contract without reading it, or accepts these kinds of clauses as a tradeoff for getting to be a big famous rockstar, then they deserve what they get. it's ridiculous to put the blame on the record companies.
In spite of the fact that you're probably trolling, you raise an interesting point: people are free to enter into contracts that are less than equitable.
I firmly believe in the right of individuals to enter into contract, but there are some problems here. For one thing, contracts are intended to represent a "meeting of the minds" - a situation in which all of the terms of the contract are understood by both parties.
Furthermore, contracts assume a relative "balance of power" between the parties: each has something the other wants that cannot be taken by force.
Both of these ideals would seem to be subverted by a fundamental imbalance of power between the parties when one is a large conglomerate and the other is a starving artist. The starving artist needs the record company much more than they need him, and so he's willing to accept a deal that is inequitable or maybe even incomprehensible to him.
Ideally, this kind of situation should be alleviated by competition. So if company A is offering you a crappy deal, go to company B. But what if there are only 5 major companies and each is offering the same deal?
Obviously, this problem exists beyond the scope of the record industry. It manifests itself in everything from shrink-wrapped EULs to employee non-compete agreements.
It's a complicated problem. I hate to see government intervention in these kinds of matters, but I also hate to see the little guys get screwed by a system that is controlled by the big guys. I'm hopeful that as technology lowers the barriers to entry into many forms of enterprise, the problem will be solved by lots of competition and the dissolution of the giants.
Lots of interesting running story lines (Scorpi's brain invasion, Dargo's son, Crichton's wormholes).
Underlying theme of the danger of centralized power and the "triumph of the underdog".
Complexity of the characters. I've often found myself empathizing with the bad guys and finding the good guys annoying. And let's not forget how last season's uber-villain can be next season's hero.
Emotional depth. The production team does an excellent job of inspiring humor, fear, sadness and exaltation (at least for me).
Farscape is really the only TV series that I care about. I'd gladly pay a subscription fee to see more episodes.
..minus the set of us who realize that any language that makes whitespace syntactically significant should be taken out and shot.
Here we go again. Seems like no one can talk about Python in non-python-programmer forum without the issue of indentation-as-syntax coming up.
I won't attempt to argue for why indentation-is-syntax is a good thing. Suffice it to say that those of us who program in Python generally consider this to be one of the language's greatest features and (from what I can see) most of the people who make statements like yours haven't done any coding in Python.
I think companies (and the courts) would be very foolish to persue legal actions against programmers who add backdoors unless they can show malicious intent.
Do you really want your programmers to have to work under the assumption that they could face criminal prosection for adding debugging hooks to their code? And what about back-doors that open up as the result of discovered security holes? Who's going to admit that their code has such a problem if they could get arrested for it?
This kind of environment will cause programmers to refrain from adding useful problem-solving tools to their code and it will end up leaving more security holes unchecked because programmers will be afraid to talk about them.
As a non-christian with a christian up-bringing, I took it to be an interesting and rather amusing cultural reference. I might have modded it up as such if I had mod points.
But, of course, on/. you can't mention anything that might be seen as endorsing Christianity (or Microsoft for that matter) without inciting controversy, so maybe it's just Flamebait;-)
Slashdot Mirror
Isn't a freenet key not much bigger than the size of a link ?
That is correct. In fact, they are URLs.
Wouldn't that just shift the problem into Freenet, so that we would just slashdot Freenet when there was a suddenly popular file, and there would be this painful lag until Freenet cached stuff at enough nodes ?
You can't really slashdot freenet because information is not stored on any single host. There would be an initial lag - that's true for any new file unless it was released to your own node - but once a popular file propagates through the network, access should be pretty fast. Systems like freenet are actually more suitable for popular material than systems like Gnutella because they cache their files at intermediate nodes, therefore, the more requests, the greater the proliferation of the material.
I've been doing software for a long time now (13 years, professionally) and I've seen some of my cleanest, best documented designs go almost unused, and some of my quickest, dirtiest hacks grow into the cornerstones of the system.
:-)
Software development is about dealing with change. Requirements change. Technologies change. Business plans change. Development teams change. Sometimes when we try to do the right thing, plan everything out, document it, create clean interfaces instead of holes in the wall... what we're really doing is betting against change, and that's always a longshot.
The best way to design, IMHO, is to start with a few good quick hacks that solve the bulk of your problems. Then put it into production and let the feedback tell you what you need to do. What do the users like? Where is the redundant functionality that merits adding infrastructure? What parts of the system are most problematic? We never really understand what we develop until we've had to build on it for two or three generations.
So my advice is leave your hack in place. If you have to change it a month from now, and then a month after that, that's a good sign that it's something that's worth doing right. If not, then your hack was the right thing to do, after all.
If you want to insulate yourself against getting slammed in the face by that hack, the best investment of your time is to write some good test suites. This way, if you add something that breaks your hack, you know about it quickly.
Just my little contribution to the background noise
But get, in "writing" (email), confirmation from the powers that be that you're circumventing procedures in order to get the work done within the timeframe needed.
Doh! That could take longer than writing the code the clean and proper way.
another %6 answered that, after numerous beers on a friday night, they had actually urinated on their last remaining SCO server.
OH MY GOD! After reading this I nearly urinated on my Linux server! (it sits below the desk)
Too funny.
I've written some pretty large applications using C++ and I've never had "problems"
Never had problems? That's quite a claim. Never spent a week tracking down an obscure seg-fault? Never spent days getting your working code to compile on a different compiler? Never ran into obscure errors because an executable had not been recompiled against a changed shared library?
If not, you should publish your insights, cause I'd really like to know how you're avoiding these kinds of things.
I see nothing in the author's statement as strong as "C++ must die" - he just says "it's lousy for development time" and lists his reasons why. He opens with "C/C++ is no longer a viable development language", but I think you have consider that to be in the context of Open Source Application Development - which is, after all, what he's doing. I don't think he is advocating rewriting the Linux kernel in Python.
Your point is well taken: most of us would certainly consider Linux and BSD to be "Unix" even though neither is certified.
However, you must admit that there is a difference between casual/common branding (like if someone says in a book "BSD is a flavor of Unix") and the explicit use of this trademark in the advertising of a commercial product.
AFAIK neither Linux nor BSD has ever been distributed as "Unix". In fact, the "GNU" acronym is pretty much an inversion of this trademark.
I'll be interested to see how the courts decide on this: I'm guessing that the failure to enforce casual use will not impede action against commercial use. Anyone know of any precedents?
Unix has become a generic term. Removing trademark status would benefit not only Apple, but the free Unixes, Linux and the BSDs.
I think there might be a little more to it than that. Just got done reading ESR's OSI Position on the SCO-vs-IBM suit paper, and it looks like the right to use the Unix trademark is conferred upon vendors who go through a certification process to confirm compliance to Unix standards.
So it's sort of like if somebody slaps the famous "compact disc" logo on a copy-protected disc - you're advertising conformance to a standard that you don't conform to. That's not to say that apple is necessarily out of compliance with the standard, the point is that the "Unix" trademark is the TOG's "seal of approval".
[standard IANAL disclaimer]
It seems to me that there are two things that SCO can gain by this campaign: 1) FUDding Linux in the hopes of gaining *NIX market share and 2) getting money from lawsuits.
If they were to disclose the "stolen source code" then either their claims would be dismissed (because the similarities could be shown to be trivial or the code in question could be traced to a non-SCO source) or if their claims actually had merrit, then the problem code could simply be replaced . In either case, the game is over for SCO - the best they could do is sue whoever violated their CDA.
OTOH, by keeping the code in question secret, they can continue to propagate a FUD campaign against Linux. By allowing a select group to review the code, they can increase the likelihood that this group will advocate in their favor, thus strengthening the FUD attack.
In the worst case scenario, if SCO is successful in suing IBM and is able to keep the code from being publicly disclosed during the course of the trial (not sure if this is possible), then they have a powerful weapon. They could then proceed to sue every Linux distributor and there's nothing anyone could do about it - since no one knows what the "stolen code" is, no one would know what to remove and the only way to find out is to go through the lawsuit.
The latter scenario seems pretty unlikely - it seems far more likely that the only thing SCO will gain is the ability to cast FUD up until the conclusion of the trial. Unfortunately, this could take years, and could end up having a fairly significant effect on the adoption of Linux.
I'd like to see a very public legal counter-attack by the open-source community. Something like an FSF lawsuit on the grounds that by their own claims, SCO has implicitly violated the GPL. I can see where it might be hard to launch such an attack - hard to fight vapor, although SCO seems to be doing a pretty good job of fighting with vapor.
Hehe, tried getting this via Gamespot... went through the whole registration thing, tried to download and it couldn't do it because it wanted to install something on my system and I wasn't running IE (or Winblows, for that matter).
:-)
So then I tried to view it with Real, got through their promo screen and some race game advertisement and then got "requested file not found" when it actually tried to download the doom3 rm file.
So I tried BitTorrent (for the very first time) against the doom3 link on the page you provided, and whaddaya know, in like 30 seconds I had the mpg - no ads, no bullshit, and I get to help out others by providing upload bandwidth! Thanks dude!
As for the Lamespot thing, I'd be really pissed off if I had provided them with my actual identity
Favorite quote from the article:
"This is not about 10 lines of code, it's about 20 years of extremely valuable intellectual property we're trying to protect...Am I supposed to lie down and not say anything about it?" McBride said. "There's a certain point here where you stand up for what's right and let the chips fall where they will."
It's refreshing to see someone in today's business environment who's willing to really put it all on the line to protect all that is right and wholsome in the world.
The RIAA could use a man like this to help them sue evil college students who are threatening the very existence of those poor starving record company executives.
Every time I tuned into the last timeslot I saw it on there was some other dumb crap on.
Oh well. Maybe this will get me to cave in and finally buy a DVD player.
That's also true in the US. I work with a small company of career contractors. We are always the top tech guys in the client environment, and most of the other serious contractors I've met are the same way.
However, among many large companies, there is definitely a feeling that the contractors are "a level beneath" the perms, even if they are smarter and more productive. Because what it comes down to is that when the money gets tight, they're going to get rid of the contractors before firing any perms.
I'm not whining here, this is what I've signed up for and I wouldn't want it any other way. However, I do think a lot of consulting companies misrepresent the nature of the work to employees who are not necessarily interested in becoming "career contractors" - these guys get pay and benefits on the scale of normal employees but have all the job insecurity of contractors. From what I've seen, these are generally the people who would rather be perms.
What I find annoying is a) the consulting companies who are essentially misleading these people into thinking they have normal jobs and b) temps who think legal action against the clients is the appropriate course of action and end up screwing us career consultants in the process.
1) Great pyramids of Egypt (paid for by the blood of thousands of conscripts)
2) The Holocaust
3) Detention of the Japanese during WWII
4) McCarthyism
5) Detention of arabs today
6) Watergate
7) Radiation testing on US troops
8) Waco
9) The Internal Revenue Service
10) Project MK-Ultra
Anyone else care to contribute?
The kinds of usage patterns that you recommend have trade-offs associated with them: for example, if you create objects on the stack and use copy instead of reference semantics when moving them into other data structures, you're going to hurt your performance and bloat your code. I'm not saying that in general you shouldn't do these things, but there are definitely situations where passing around pointers and using memcpy() still makes more sense.
I should also note that I am a huge fan of auto_ptr and reference-counting templates in general, but there are a lot of subtleties to their use. For example, they don't deal with inheritence well, and there's the question of whether or not to expose the underlying pointer (allowing abuse) or not (requiring users to pass around references or copies of the managed pointer in situations where the raw pointer would be more efficient).
And that leads to my more general criticism of C++: coding in it is too much of an art. You need a greater level of understanding than you can expect from most programmers, and most people seem to write either inefficient code or buggy code (usually both).
I respectfully submit that the fact that you _can_ write unsafe code in a programming language _is_ a reason to avoid it! Particularly if the language makes it easy for you to shoot yourself in the foot and there are other languages available that a) don't have this weakness and b) allow you to code faster in the first place.
Tools like the STL definitely help, but they don't offer a guarantee against these kinds of problems. Like you said, you can still reference out of bounds indexes. Furthermore, you can still reference uninitialized pointers, double-free memory, and use objects before they're initialized.
.NET becomes competitive in terms of speed and memory footprint.
Also, these kinds of abstractions have performance costs. At some point, these costs are going to mount until something like Java or
At their core, C and C++ are low-level programming languages. They're powerful because they're dangerous, and you should only use them when the situation demands it.
the added security is OK, but as pointed out in the article, high level languages aren't a silver bullet.
No, but they do remove several major classes of vulnerabilities that have a long history of being exploited. There's definitely a security advantage to them.
What's really needed is a decent component model, making it easier to choose the right language for the job, instead of choosing a langauge because that's what all the libraries are written for, or because that's what everybody else uses.
I quite agree. I seem to recall that there are several of these out there, but none has really caught on.
There's another advantage to low level languages: performance. Nothing runs as fast and loads as quick as machine code, and that's very important for something like "inet" and it's services: you want them to be always available, always responsive, and to consume as little of the systems resources as possible. A Java app with its 9 meg footprint just doesn't cut it.
I think the high level stuff is the way to go in the application space, but system services justify the extra time and effort (and risk) of being written in C.
Hmmm. Sounds a lot like one of my stories!
Only I like to come in with the "I need $1200 to purchase this commercial package - unless you want me to use this competing open source package, which IMHO is a better product anyway" angle.
Last project I was on, management was blown away by the stability of our Linux servers. Even the Windows guys were impressed. When I left the group, they were using Linux as a dedicated DB/2 server platform (wouldn't switch their web servers because of the VB/.NET thing).
if they do then that was in the contract you signed. if a musician signs a contract without reading it, or accepts these kinds of clauses as a tradeoff for getting to be a big famous rockstar, then they deserve what they get. it's ridiculous to put the blame on the record companies.
In spite of the fact that you're probably trolling, you raise an interesting point: people are free to enter into contracts that are less than equitable.
I firmly believe in the right of individuals to enter into contract, but there are some problems here. For one thing, contracts are intended to represent a "meeting of the minds" - a situation in which all of the terms of the contract are understood by both parties.
Furthermore, contracts assume a relative "balance of power" between the parties: each has something the other wants that cannot be taken by force.
Both of these ideals would seem to be subverted by a fundamental imbalance of power between the parties when one is a large conglomerate and the other is a starving artist. The starving artist needs the record company much more than they need him, and so he's willing to accept a deal that is inequitable or maybe even incomprehensible to him.
Ideally, this kind of situation should be alleviated by competition. So if company A is offering you a crappy deal, go to company B. But what if there are only 5 major companies and each is offering the same deal?
Obviously, this problem exists beyond the scope of the record industry. It manifests itself in everything from shrink-wrapped EULs to employee non-compete agreements.
It's a complicated problem. I hate to see government intervention in these kinds of matters, but I also hate to see the little guys get screwed by a system that is controlled by the big guys. I'm hopeful that as technology lowers the barriers to entry into many forms of enterprise, the problem will be solved by lots of competition and the dissolution of the giants.
So if it's true that global warming is mostly due to the sun, do you still think we should spend billions of dollars to reduce CO2 emissions?
Quake Lunch Hour!
Farscape is really the only TV series that I care about. I'd gladly pay a subscription fee to see more episodes.
..minus the set of us who realize that any language that makes whitespace syntactically significant should be taken out and shot.
Here we go again. Seems like no one can talk about Python in non-python-programmer forum without the issue of indentation-as-syntax coming up.
I won't attempt to argue for why indentation-is-syntax is a good thing. Suffice it to say that those of us who program in Python generally consider this to be one of the language's greatest features and (from what I can see) most of the people who make statements like yours haven't done any coding in Python.
Can I submit my patch as a jpeg?
I think companies (and the courts) would be very foolish to persue legal actions against programmers who add backdoors unless they can show malicious intent.
Do you really want your programmers to have to work under the assumption that they could face criminal prosection for adding debugging hooks to their code? And what about back-doors that open up as the result of discovered security holes? Who's going to admit that their code has such a problem if they could get arrested for it?
This kind of environment will cause programmers to refrain from adding useful problem-solving tools to their code and it will end up leaving more security holes unchecked because programmers will be afraid to talk about them.
As a non-christian with a christian up-bringing, I took it to be an interesting and rather amusing cultural reference. I might have modded it up as such if I had mod points.
/. you can't mention anything that might be seen as endorsing Christianity (or Microsoft for that matter) without inciting controversy, so maybe it's just Flamebait ;-)
But, of course, on