Either an insecure scripting environment embedded into a mail reader or enough social engineering to convince users to save and execute untrusted binaries for the correct architecure or scripts with the correct paths and permissions.
Yes, it's possible. Security, however, is about minimizing risks. Diversity helps.
Re:An Interpreter/Compiler combination is far easi
on
Perl is Sweet Sixteen
·
· Score: 1
Why not put all the good stuff into one language?
That's exactly what Larry's doing. Of course, his definition of "good stuff" is probably different from yours as is his choice of "one language".
Re:Larry Wall's first mention of Perl on Usenet
on
Perl is Sweet Sixteen
·
· Score: 1
Funny, I'm running Perl 6 in another window as I type. I thought I had Pirate installed, but I don't, so I can't claim to be running Python on Parrot. Ah well, one out of two isn't so bad.
Instead of impossible, you might more accurately write ineffective only in delivering messages only to servers which perform this check. Spammers don't particularly care about bounces and forged headers now. This scheme would only be effective if almost everyone switched to it.
It's better to rewrite code than it is to understand it.
I don't understand this at all. How can you rewrite the code correctly unless you know what it's doing and why?
I think you're quite mistaken about XP. XP says, in cases where you don't have all of the requirements up front and you expect them to change, to design and code only what you need right now, and then to refactor regularly as changes come along.
If you don't refactor, of course you'll end up with a big ball of mud!
I'm not arguing against design. I'm not arguing against cleaning up code. I'm arguing against the idea that the best way to clean up working but ugly code is to throw it all away and start over.
As you suggest, why not do it right to begin with?
Your project doesn't have to be perfect at every release. It should get better with every release though. I'm not convinced that enough developers are asking "Hey, how can we do this better next time?" and are following through. That's all.
I wish I had the time and resources to do that kind of study... but I'm afraid anecdotal evidence is all I'll ever get.
I see two drawbacks to feature freezes.
The only way to get widespread testing of and feedback on open source software is to get it into the hands of users. Linus kinda has this right, as he knows that 2.6.0 isn't the be-all end-all of the 2.6 family, but people will start to migrate to it in droves because of the name. The first problem with a feature freeze is that it actually delays this adoption! Sure, you'll get more feedback than if you released completely unstable snapshots, but the label "stable release" is powerful magic.
The second problem is that every open source project has finite resources.
A feature freeze means either splitting development into bugfixes and new development. If you have the resources to pay people to stabilize things (like the Mozilla Foundation or Ximian do), that may not be so bad. If you don't have those resources, you'll have to hope that your regular contributors will actually fix bugs instead of writing new features.
The longer the feature freeze, the worse it gets. The longer you delay new features entering the tree, the more time before you can get feedback on them and the less stable they may be. The Linux kernel went into feature freeze for 2.6 in October 2002! At some point, the pressure to add nice new features is too great.
I do think it's a good idea to give people a few days or a couple of weeks (depending on the size of the project) to find and fix showstoppers and to add polish, but given the drawbacks, I think developers ought to focus their quality assurance efforts much earlier in the process.
As always, I could be wrong. I do think the concept of quick feedback is incredibly important, though.
Haphazard programming without the discipline of design leads you to a psychotic system that is often beyond repair.
I agree. Thinking about the your design is good. That's why I suggest doing it as often as possible.
You may be a much better designer than I am -- I have a terrible time coming up with the right design before I start putting code together. I usually end up refactoring out useful bits and going off in a different direction than I thought. I'm happy with that because I end up with code I like much better. If you get everything right up front the first time, though, more power to you. I wish I did.
[The Linux kernel] gets better design all the time. The SCSI code was almost completely rewritten for 2.4. The memory manager was completely rewritten. The scheduler has since been replaced.
Amusing example; how many times have those subsystems been rewritten from scratch? The SCSI code seems to turn from "bright shiny nice new rewrite" into "terrible mucky old crufty garbage that really needs a rewrite" in the time it takes to branch a new development version. I also don't count the VM swap that happened around kernel 2.4.9 or so as a bright shining moment in history!
The main point is not to throw away a working solution without considering the cost of reimplementing all of the parts that work. I consider "does it solve the problem correctly?" to be slightly more important than "is it beautiful?".
Of course, I think that you can do both, but that's me wearing my Test-Driven Development Evangelist hat again, and no one wants that on a Friday night. (I also think that refactoring is usually the right approach -- but it depends on the problem you're trying to solve. Dom and I probably agree far more than it may sound.)
This isn't a myth because it's impossible to improve your coding habits. This is a myth because too few developers actually have concrete, sensible plans to improve.
For fun, choose ten random projects on Freshmeat. Browse their complete changelogs, looking for the phase "completely rewrote". The results might scare you. (Or, you could just look at the change history for the Enlightenment window manager.)
You might be surprised, but I agree. It usually takes me finding three instances of similar code before I can generalize it correctly.
This article was talking about the open source world, though. There seems to be a penchant for writing frameworks without any projects that actually use them. That's the myth I was trying to address. Extracting a framework from only one project isn't spectacular, but it's much, much better than extracting a framework from zero working projects.
Still, count the number of Perl users in the world and the number of registered CPAN authors. I can't find a reference now, but there are a few thousand authors and a few thousand modules. The ratio of CPAN contributors to Perl users worldwide is still much less than 10% -- probably still not over 1%.
You may not be counting, but there are about a dozen active perl 5 developers on p5p, about half with commit rights. Similarly parrot has
about 5 active committers.
This is the number of competent volunteers that a well established 16-year
old programming language used by many individuals and many organisations
can muster. From the entire world.
Of course, there are hundreds of people in the CREDITS file, but a handful of people do the bulk of the work. Maybe it's an edge case, but 10% of Perl users aren't contributing back to the core. It's very much below 1%.
That's not bad. It just is. My point is that expecting a smaller, younger, and less-well-used project to attract more regular and frequent developers is usually unrealistic.
Is the use of the word "myth" really intended to indicate that a large cross-section of people actually believe these things?
No, it's not. I tried to make that clear in the introduction. I don't believe that most open source projects deliberately believe that, for example, bundling up their code to make it easy to distribute and install is a bad thing. Too many projects fail to do just that, though.
The word "myth" was just more expressive than the phrase "things you'd think we believe based on our actions".
Please don't do that. What if (as is usually the case) the spammer has forged the From address? Hopefully, there's not an innocent person on the other end and you've just wasted bandwidth.
It sounds like we're in agreement, though we seem to be approaching from different angles. You'd like to solve large problems by growing small teams that have successfully solved smaller ones. I'd like to solve large problems by breaking them into smaller ones.
The biggest flaw in that argument is that duplicating an automobile assembled by craftsmen is tremendously expensive when compared to duplicating a piece of software.
Lumping everyone who uses, advocates, or develops open source into one big community and trying to generalize a single belief or behavior is a mistake.
Some people sneer at proprietary applications. Some people launch projects to clone them. Some people care about Linux on "the" desktop. Some people don't.
No matter what a developer believes, the code's available for use, study, and modification under a resonable license. I don't see that as a failing of open source. It's a feature.
I think that's much too simple an explanation, for at least two reasons.
First, the source code is available for Mozilla. I would think it easier to find security holes by reading the source code than by randomly sending input to a binary. (Of course, I know how to read code and I've never tried to exploit a binary.)
Second, Apache, for example, is used far more often than IIS and it has far fewer exploits.
The argument that popularity is the primary determinant of exploitage seems to ignore the possibility that some software is more secure than other software. That's a big elephant to ignore.
The fact is *most* open source projects are done by students or the unemployed.
Do you have research on this? The Boston Consulting Group's Hacker Survey (warning, PDF!) had some very different numbers. I'm curious to the real story either way.
Copyright holders are not bound by the licenses they choose. If everyone who held copyright to the code in the project agreed to relicense the software for a new release, they could do so. They could even do it for the current release.
There's no changing a license retroactively, though, so anyone who has received the code under an open source license can continue to use it (and, more importantly, redistribute it) under that license.
Slashdot Mirror
Either an insecure scripting environment embedded into a mail reader or enough social engineering to convince users to save and execute untrusted binaries for the correct architecure or scripts with the correct paths and permissions.
Yes, it's possible. Security, however, is about minimizing risks. Diversity helps.
That's exactly what Larry's doing. Of course, his definition of "good stuff" is probably different from yours as is his choice of "one language".
Funny, I'm running Perl 6 in another window as I type. I thought I had Pirate installed, but I don't, so I can't claim to be running Python on Parrot. Ah well, one out of two isn't so bad.
It's just like every other news channel!
... or configure PHP and MySQL properly.
Instead of impossible, you might more accurately write ineffective only in delivering messages only to servers which perform this check. Spammers don't particularly care about bounces and forged headers now. This scheme would only be effective if almost everyone switched to it.
I don't understand this at all. How can you rewrite the code correctly unless you know what it's doing and why?
I think you're quite mistaken about XP. XP says, in cases where you don't have all of the requirements up front and you expect them to change, to design and code only what you need right now, and then to refactor regularly as changes come along.
If you don't refactor, of course you'll end up with a big ball of mud!
I'm not arguing against design. I'm not arguing against cleaning up code. I'm arguing against the idea that the best way to clean up working but ugly code is to throw it all away and start over.
As you suggest, why not do it right to begin with?
Your project doesn't have to be perfect at every release. It should get better with every release though. I'm not convinced that enough developers are asking "Hey, how can we do this better next time?" and are following through. That's all.
I wish I had the time and resources to do that kind of study... but I'm afraid anecdotal evidence is all I'll ever get.
I see two drawbacks to feature freezes.
The only way to get widespread testing of and feedback on open source software is to get it into the hands of users. Linus kinda has this right, as he knows that 2.6.0 isn't the be-all end-all of the 2.6 family, but people will start to migrate to it in droves because of the name. The first problem with a feature freeze is that it actually delays this adoption! Sure, you'll get more feedback than if you released completely unstable snapshots, but the label "stable release" is powerful magic.
The second problem is that every open source project has finite resources. A feature freeze means either splitting development into bugfixes and new development. If you have the resources to pay people to stabilize things (like the Mozilla Foundation or Ximian do), that may not be so bad. If you don't have those resources, you'll have to hope that your regular contributors will actually fix bugs instead of writing new features.
The longer the feature freeze, the worse it gets. The longer you delay new features entering the tree, the more time before you can get feedback on them and the less stable they may be. The Linux kernel went into feature freeze for 2.6 in October 2002! At some point, the pressure to add nice new features is too great.
I do think it's a good idea to give people a few days or a couple of weeks (depending on the size of the project) to find and fix showstoppers and to add polish, but given the drawbacks, I think developers ought to focus their quality assurance efforts much earlier in the process.
As always, I could be wrong. I do think the concept of quick feedback is incredibly important, though.
I agree. Thinking about the your design is good. That's why I suggest doing it as often as possible.
You may be a much better designer than I am -- I have a terrible time coming up with the right design before I start putting code together. I usually end up refactoring out useful bits and going off in a different direction than I thought. I'm happy with that because I end up with code I like much better. If you get everything right up front the first time, though, more power to you. I wish I did.
Amusing example; how many times have those subsystems been rewritten from scratch? The SCSI code seems to turn from "bright shiny nice new rewrite" into "terrible mucky old crufty garbage that really needs a rewrite" in the time it takes to branch a new development version. I also don't count the VM swap that happened around kernel 2.4.9 or so as a bright shining moment in history!
The main point is not to throw away a working solution without considering the cost of reimplementing all of the parts that work. I consider "does it solve the problem correctly?" to be slightly more important than "is it beautiful?".
Of course, I think that you can do both, but that's me wearing my Test-Driven Development Evangelist hat again, and no one wants that on a Friday night. (I also think that refactoring is usually the right approach -- but it depends on the problem you're trying to solve. Dom and I probably agree far more than it may sound.)
As I said in the conclusion of that section:
For fun, choose ten random projects on Freshmeat. Browse their complete changelogs, looking for the phase "completely rewrote". The results might scare you. (Or, you could just look at the change history for the Enlightenment window manager.)
Do you believe it's possible to evolve a small program into a large program with a good design?
I very much believe that it's possible. It takes time and discipline, but I think it's usually much easier than getting the design right beforehand.
You might be surprised, but I agree. It usually takes me finding three instances of similar code before I can generalize it correctly.
This article was talking about the open source world, though. There seems to be a penchant for writing frameworks without any projects that actually use them. That's the myth I was trying to address. Extracting a framework from only one project isn't spectacular, but it's much, much better than extracting a framework from zero working projects.
That's a good point.
Still, count the number of Perl users in the world and the number of registered CPAN authors. I can't find a reference now, but there are a few thousand authors and a few thousand modules. The ratio of CPAN contributors to Perl users worldwide is still much less than 10% -- probably still not over 1%.
It's my experience that the percentage of people who send feedback or patches is much lower than commonly expected. See, for example, Nicholas Clark explaning the volunteer pool for Perl 5 core development:
Of course, there are hundreds of people in the CREDITS file, but a handful of people do the bulk of the work. Maybe it's an edge case, but 10% of Perl users aren't contributing back to the core. It's very much below 1%.
That's not bad. It just is. My point is that expecting a smaller, younger, and less-well-used project to attract more regular and frequent developers is usually unrealistic.
No, it's not. I tried to make that clear in the introduction. I don't believe that most open source projects deliberately believe that, for example, bundling up their code to make it easy to distribute and install is a bad thing. Too many projects fail to do just that, though.
The word "myth" was just more expressive than the phrase "things you'd think we believe based on our actions".
Please don't do that. What if (as is usually the case) the spammer has forged the From address? Hopefully, there's not an innocent person on the other end and you've just wasted bandwidth.
It sounds like we're in agreement, though we seem to be approaching from different angles. You'd like to solve large problems by growing small teams that have successfully solved smaller ones. I'd like to solve large problems by breaking them into smaller ones.
The biggest flaw in that argument is that duplicating an automobile assembled by craftsmen is tremendously expensive when compared to duplicating a piece of software.
How do you account for voter apathy and cynicism then?
Lumping everyone who uses, advocates, or develops open source into one big community and trying to generalize a single belief or behavior is a mistake.
Some people sneer at proprietary applications. Some people launch projects to clone them. Some people care about Linux on "the" desktop. Some people don't.
No matter what a developer believes, the code's available for use, study, and modification under a resonable license. I don't see that as a failing of open source. It's a feature.
I think that's much too simple an explanation, for at least two reasons.
First, the source code is available for Mozilla. I would think it easier to find security holes by reading the source code than by randomly sending input to a binary. (Of course, I know how to read code and I've never tried to exploit a binary.)
Second, Apache, for example, is used far more often than IIS and it has far fewer exploits.
The argument that popularity is the primary determinant of exploitage seems to ignore the possibility that some software is more secure than other software. That's a big elephant to ignore.
Do you have research on this? The Boston Consulting Group's Hacker Survey (warning, PDF!) had some very different numbers. I'm curious to the real story either way.
Copyright holders are not bound by the licenses they choose. If everyone who held copyright to the code in the project agreed to relicense the software for a new release, they could do so. They could even do it for the current release.
There's no changing a license retroactively, though, so anyone who has received the code under an open source license can continue to use it (and, more importantly, redistribute it) under that license.