It's not because of self-doubt or fear of damnation. It's because as religious people, they believe they have more to live for. They believe that a supreme being has taken a personal interest in their individual lives, and that whatever is happening to them serves an important purpose in the greater scheme of things. If there is any chance of recovery at all, they'll hang on to it.
The definition of faith is the belief in that for which there is no evidence, so perhaps religious people are less likely to give up hope.
Well, I don't if things are very different on FreeBSD, but my Debian version of patch seems to work a little differently. Don't put a space between the -p and the 1, and feed the patch file in on stdin, instead of naming it as an argument:
patch -p1 <../../patches/maildir.patch
Of course, use -p1 if you're in the root of the alpine-1.00 source directory, otherwise the number will be different.
Does this new alpine app have Maildir support? There is a patch that adds Maildir support as a driver. It seems to build ok, and I'm getting ready to try it out.
FYI, if you build on Debian, you will need to install (at least) libssl-dev and libpam0g-dev.
How about webcams? I still can't walk into a consumer electronics store (Best Buy, Circuit City, etc...), pick up a cheap webcam, and expect it to work. And when they post the compatibility status for a camera, they should list it by the name on the box too, not just the name of the chip inside. When I walk into the Wal-Mart electronics department, I don't see a whole lot of Texas Instruments part numbers. I know that there are a lot of different brands of cameras that use the same parts internally, but they could at least list the model that the developer bought himself to write the driver.
As far as I know the Logitec Quickcam Messenger still doesn't work for Linux, and it was a very commonly available camera.
Yes, I have a humidifier in the bedroom to help with dry sinuses each morning, but the static problem doesn't happen nearly as often now that I'm aware of it. My wife has also pointed out that since I nearly always wear shoes, I may be holding the charge better; since she goes around in sock feet most of the time she's home, she rarely ever shocks herself.
As for the difference between being grounded and just experiencing a static shock, you are correct. I probably misused the term. When I say I "grounded" myself, I simply mean that there was a voltage difference between me and some other object, presumably a grounded one, and through my actions I caused the difference to equalize. I have actually been "grounded" in the true sense of the term too - becoming a conductor in a real electric circuit, and I can say that it feels quite different. But, when you're not expecting it, it's easy to mistake one form of shock for another.
For a while, I thought I had a similar problem with both my new Dell laptop, and an old dumpster-diver I had before that. I was getting shocked occasionally when I touched the machines. I initially blamed it on poorly grounded wiring in my house (a rental), until I realized that the problem was electro-static discharge build up from sitting on my Durapella couch.
I worked it out recently when cold winter temperatures drove the humidity way down. Whenever I got up from the couch I would feel the charge build up, then I would inadvertently discharge myself of a light switch, a metal corner post in the drywall, or worse, on some home electronics. After I accidentally blew out the panel of buttons on a DVD player, I did some experiments. By rubbing my hand on the couch cushions for a few seconds, then using a piece of metal held in my hand (less painful that way) to discharge myself to ground, I found I could jump a spark 2 cm or more. Sometimes, I can get multiple sparks on one charge.
It's kind of cool, if you know to expect it. And, the remote still works for the DVD player...
I know this meets none of your criteria, and so completely fails to answer your question, but the best development environment I've ever found is Slime (Superior Lisp Interaction Mode for Emacs). It can work with several different Common Lisp implementations running on Linux, Unix, Mac, and Windows, and since Emacs is cross-platform, it can run on any platform where Emacs is supported. It provides a REPL, object inspector, debugger, single stepping, multi-thread support, stdout re-direction to the REPL buffer, syntax highlighting, auto-indent, expression evaluation from source files, error re-starts, and function cross-referencing, for those Lisps that support them. It offers capabilities reminiscent of the Fabled Lisp Machines of Old.
Slime uses a component running in the Lisp process, and elisp code running in Emacs that communicates with the Lisp through a local INET socket. That means you can run the Lisp process on machine 1, set up an ssh tunnel to it from machine 2, potentially running a different OS, and connect to 1 from an Emacs on 2. I actually do this every day, connecting to a remote SBCL on Linux from both Linux and Windows. The interaction is fast enough that I routinely develop on the remote Lisp image over a WAN link.
The system works with any libraries available for your Lisp implementation, including database, web, and GUI toolkits, although it would be tricky do to GUIs over remote, and Open GL would probably have to be local.
Of course, there are some caveats... Developing in a Lisp is like working in another OS running on top of the host OS (especially with multiple threads). Also, Emacs doesn't have a drag-and-drop GUI builder, although one could be built in Common Lisp. And, you would have to develop a taste for parentheses.:)
My hometown was much the same. The population is hovering somewhere around 10,000, the high school has the highest teen pregnancy and drop out rates in the state, and the situation hasn't changed much since I graduated 10 years ago. Luckily, I was also aware of a bigger world out there and managed to avoid the vortex. We also watched the 1968 version of Romeo and Juliet and had the teacher fast-forward through the same parts, but watched Glory in full. The description of your experience was so familiar that I briefly wondered if we spent time in the same high school, though I suspect the story is all too common.
Not to go back on-topic or anything, but I have similar thoughts on the hacking of creative works. Yes, the practice is lame and stupid. No, it shouldn't be happening in the first place. But, you can't really outlaw lameness and stupidity, so if some jackass wants to pay a company to censor their own entertainment, a judge shouldn't jump in and stop them.
People who patronize scrub companies are only marginally interested in the creator's vision to begin with, and they certainly care less about it than about offensive material. So what if they miss out? Everyone gets to be happy: The original creators of the piece gain a sale that they wouldn't have otherwise had. The person with the censored copy gets what they want. Everyone else still gets to see the real thing. And, the film-scrubber gets the satisfaction of knowing that he does business with people who prefer to pay extra for less valuable goods.
It's been done a long time ago. Lisp has had this ability for decades, along with a few other features that are only now making it into mainstream programming languages. It's been said for a while now that language design is slowly converging on Lisp. When the s-expression syntax is finally adopted by the average programmer, we'll have caught up with 1968.:)
You're not really asking about interpreted vs. compiled languages. What you're really asking is whether computers have gotten fast enough for us to stop using low-level languages and let the computer handle many of the details in high-level ones.
But, I think the whole question is bollocks because it's based on an incorrect assumption.
There is no inherent tie between LLLs and compiled code, and HLLs and slow, interpreted code. Some HLLs can be compiled into very fast native code. A quick scan of the comments tells me that the name has already been dropped, but I'll put in my plug for Common Lisp. It allows you to use interpreted functions and compiled functions both in the same environment, so that you can develop code quickly, then compile it to get a speed boost. If you need more low-level control to get some extra performance in a bottleneck, you can even do things like declare data types and lower compiler safety levels for individual functions.
Lisp was doing this decades ago, and it was even being used for operating system code in the Lisp Machines. So, computer power really has no relevance to the issue. I think the real barrier to adoption of these kind of high-level techniques is not in the machines, but the beliefs of developers who still think that real programmers do thier own pointer math.
So in the presence of exceptions, you won't leak memory on the heap. But you will leak mutexes, file handles, etc. You need another idiom to handle those cases.
In the.NET world, C# introduced synchronization blocks to handle the leaking mutex problem. But it is a pain in Managed C++ and VB.NET.
File/mutex/whatever leakage in the presence of exceptions? Two words:
Whoa there, Anonymous! And perople were saying that I was looking for an excuse to strut!
rexec doesn't belong in the main python distro unless someone is willing to do a full audit and maintain a full security test case. otherwise people will use it expecting protection without understanding what they're doing.
What - unlike the Linux Kernel or OpenSSH? The source is open so that people can check it for bugs. I know that's not the same as a formal audit, but we couldn't do any worse than the closed source JVM from Sun. We both know that make check sets loose a whole battery of tests, and the Python-Dev thread I mentioned shows code that could go into a PyUnit test case. So, what's the problem?
you can still use rexec if you like, but only as an add on module.
No, you can't - that's the whole problem. Rexec wasn't removed because it had a bug; it was removed because the language changed. A new type of class was introduced, so-called new style classes, that inadvertently broke rexec. By using a new style class, you can break out of an rexec jail.
I don't care that a security hole was discovered. I'm just irked because Guido chose cute class semantics over an established security-related module. It wasn't even an either-or decision - he decided not to fix the module just because he didn't want to deal with it. My project will no longer use Python simply because it can't now that rexec is gone. If this happens to many other projects, Python's future won't be secure in either sense of the word.
Agh, look I love Python but the Global Interpreter Lock's got to go. Threading is severely crippled as long as it's still there... I mean, failing that can't we at least have independent interpreters?
Please? I've looked around for efforts to sort this out but the last of them seems to have died around 1997...
Amen, Brother Derivative! I've actually played with the idea of just removing the GIL code myself to see what breaks (although I suspect quite a bit would). After all, you should use locks to regulate access to variables anyway. It would be dangerous because it would open up the possiblity of a bug crashing the interpreter instead of just the application, but I'd at least like a run-time option to disable it.
And independent interpreters would would make my life a whole lot easier when it comes to embedding Python as a macro language (to which Python is supposed to lend itself easily). It would also allow me to use teminable threads...
I think Perl suffers from these same minor deficiencies. I suspect that's due to the inevitable switch to the Parrot interpreter.
The module advertised to do one thing, "restricted environment" but then failed to deliver. Guido had an obligation to mark it broken and/or remove it.
As for fairly secure, python does not have a sandbox... but I hardly think that the lack of a sandbox makes python insecure.
I'm not disputing the decision - if rexec wasn't salvagable, it should have been dropped. And the specific issue of having a sandbox is not really the point. Guido is saying that he doesn't have confidence in his sucurity design skills, but then he says that Python is secure. Why should we trust the C runtime to not have buffer overflows?
If he wants to say that Python is secure, he should stand behind one of Python's only explicitly security-related modules.
I can understand dissapointment at a "feature" disappearing, but his reasoning was the soundest decision that I have heard of in a long time.
I don't disagree with the decision itself - there is another thread on that site (lost the link) that implies that the new class semantics in Python 2 make it impossible to implement an effective rexec environment. In that case, rexec is a moot point.
But, after accepting that, I hear Guido saying that Python is secure and is being used for security projects. Is that wise, considering that he is removing features because he is afraid that insufficient security consideration was taken in the design? I always thought that the Open-Source development methodology was supposed to fill in those kind of gaps by leveraging the expertise of many people.
Python is "already quite secure," he says, and will be the basis of an upcoming security product ("just getting started") from Elemental.
I'd like to point out a thread that I found a little while back on Python-Dev about Guido's decision to remove the rexec module (similar to the Java sandbox):
Since this last one is particularly telling, I will quote the relevant text for our impatient readers:
I think Guido's rationale for removing all these features will be
widely misunderstood. Me channeling him: it is not that he believes
that the architectures developed were inherently incapable of
providing security. Instead, he feels that no "expert" for these
matters has reviewed these architecture for flaws, and that the
continuing maintenance of these things isn't going to happen.
If this understanding is correct, then any new approaches will likely
suffer from the same fate. Unless somebody steps forward and says: "I
am a security expert, and I guarantee that this and that feature is
secure (in some documented sense)", then I think he will dislike any
changes that mean to provide security.
So this not a matter of engineering but of authority. Somebody must
take the blame, and Guido doesn't want to be that someone.
Disclaimer: I love python. However, I am working on a project that depends on rexec, and when I discovered that it was being removed, I was a little annoyed - especially at the reasoning behind the decision.
Iain M. Banks' Culture series is one of my favorites, and in the U.S., I can only find his 3 most recent books - Excession, Inversions, and Look to Windward. All the others are almost impossible to find - even in the used bookstores where I've looked. I guees everyone else likes them well enough to not sell them off.
But, about a year ago I found a copy of Consider Phlebas in a Borders, along with 2 other titles, which I stupidly decided not to purchase. I was a bit annoyed to discover that it was only there by mistake; the back of the book had a U.K. price, a Canadian price, and a note saying "NOT FOR SALE IN THE USA". WTF?
So, what is Jon trying to say here? These Mac and Linux users have just been too pleased with themselves lately? "Yeah, you guys have great technology, but you still don't have market share". So what.
Lately (the last couple of years), I've noticed a huge trend toward a focus on market share, owning the desktop, and taking over the world. I think Mr. Katz and a whole lot of people in the Linux and Windows communities are the ones who have missed the point; I don't use Linux because I want to take over the world. I don't use it because I want to 'stick it' to Bill Gates, and I don't use it because I think it's cool. All of those things are nice ideas, but they are totally secondary. I think they are for most Mac users, too.
I use Linux because it allows me to do the things I want to do better than any other operating system. I'm a hacker, so I choose the OS that makes it easiest for me to hack. Linux provides me with more power and scalability than any other comparable system, and it easily supports almost every programming language in the world, all for a low cost.
I frankly don't care how neat and nifty the OS is, and I don't care who else uses it. In fact, I don't think everyone in the world should use Linux- "widest possible appeal" was one of Windows' design goals, and look at what it produced. Linux's specialization is what makes it valuable to me. So, Jon, before you get down on me for "not getting it", you get it; Linux is not winning the market share game because most of the Linux community has better things to do with its time.
I don't know if it was actually published in 2001, but that's when I bought it. Descent 3 for Linux is an excellent port of the Windows version, and it even adds a few features that the Windows version doesn't have (like no-mouse-grab and rendering in a window). You just can't beat 6DoF in a first person shooter, as long as you don't get motion sickness too easily.:) Multiplayer is incredible too, with lots of multiplayer game modes.
Then again, I always said that Linux itself was the ultimate video game- it's the only one that's kept me playing continuously for 6 years.
The point isn't whether Open Source companies can stay Open Source or not. The companies could all go bankrupt and it wouldn't stop Open Source. Before it had a catchy name, Open Source was just people writing programs that they wanted for their own purposes, and sharing them with other people. The loss of a few trendy business models won't change that.
In fact, it might actually help Open Source in general by sweeping out all the cruft, just like the current slump is cleaning up the dot-com fad. The people who are left will be the ones that develop Open Source software because they just care about having the software, not because they want to capitalize on a freely available army of developers.
Before, developers (or their companies) wouldn't openly release things that they felt really created a competitive edge. (Non-software companies didn't try to sell such systems either. They kept the advantage for themselves.) Now, these Open Source companies are trying to make a profit from creating software that, by definition, is their competitive edge. And they want to release all the source? Not likely. I don't want to sound like one of those people who yammer about how Open Source advocates shouldn't want everything for free, but it doesn't surprise me that these companies are dropping off and selling out. In the end, it doesn't really matter- the heart of Open Source exists outside of these companies.
Thank you for not reading the body of my post. The point is that software has nothing to do with iron bridges in the 18th century. A bridge is drawn up by some civil engineer who actually knows about statics and materials, then is built by construction workers who input almost nothing to the design. Any one of the workers could be replaced with almost no effect, because they are all just following the engineers instructions anyway.
With software engineering, things are different because the high-level designer talks about object models and protocols, but the code is actually written by programmers who are solving the hundreds of little problems that go along with actually fleshing out the specification. Just specifying the pre and post-conditions of a function doesn't write the function. A coder actually needs to figure out how to do it. Sure, most of the problems are pretty repetitive and trivial, but many are not, which is why automated code generation only goes so far.
The thing that really gets me is that researchers in the field of software engineering can't even decide among themselves whether or not programming is like construction. The question still isn't resolved. They spend their time fooling around with antiquated methods and voodoo like Halstead's "Software Science".
I'm a little concerned because Open Source seems to be leaning in that direction, especially with these large projects like Mozilla and Gnome (although there are plenty more). People marvel at the sheer size of these applications, and I believe the problem is that they are no longer hackers working in their own self interest to fix bugs and add desired features. Instead, they are a huge team working on lots of little pieces that add up to a lot of bloat. Remember The Cathedral and the Bazaar? ESR says that one of the things that makes Open Source great is its freedom from conventional management structures.
No. Actually, I've been programming since the AplleSoft Basic days with the Apple IIe. I've worked on multiple-10-KLOC-sized projects, and I've done both code maintenance and original design.
I also remember the days when flowcharts were an absolute necessity for good programming- if you didn't use them, you lacked professionalism. I took some heat for balking at that idea back then.
I felt that flowcharts were an ill-concieved method of planning programs. Now, flowcharts are virtually extinct in the development process, and I'm paying my bills by writing code the same way I always have.
This is a subject that really irks me in light of the conventional "Software Engineering" mindset. Most of SE nowadays seems to be aimed at making software projects as predictable as possible, as if they were like civil construction projects. The fact of the matter is that they are not like building projects... If we conform to the doctrine of software re-use, on of SE's central tenants, we should never have to re-write a piece of software, so we will never know what the complexity of the related problems are until the project is finished. Software has nothing to do with engineering- it is more like original composition, like writing a symphony or novel, except that it also has a constraint for rigorous correctness. Physics is a good analogy for that.
Slashdot Mirror
It's not because of self-doubt or fear of damnation. It's because as religious people, they believe they have more to live for. They believe that a supreme being has taken a personal interest in their individual lives, and that whatever is happening to them serves an important purpose in the greater scheme of things. If there is any chance of recovery at all, they'll hang on to it.
The definition of faith is the belief in that for which there is no evidence, so perhaps religious people are less likely to give up hope.
Well, I don't if things are very different on FreeBSD, but my Debian version of patch seems to work a little differently. Don't put a space between the -p and the 1, and feed the patch file in on stdin, instead of naming it as an argument:
../../patches/maildir.patch
patch -p1 <
Of course, use -p1 if you're in the root of the alpine-1.00 source directory, otherwise the number will be different.
FYI, if you build on Debian, you will need to install (at least) libssl-dev and libpam0g-dev.
-A
How about webcams? I still can't walk into a consumer electronics store (Best Buy, Circuit City, etc...), pick up a cheap webcam, and expect it to work. And when they post the compatibility status for a camera, they should list it by the name on the box too, not just the name of the chip inside. When I walk into the Wal-Mart electronics department, I don't see a whole lot of Texas Instruments part numbers. I know that there are a lot of different brands of cameras that use the same parts internally, but they could at least list the model that the developer bought himself to write the driver.
As far as I know the Logitec Quickcam Messenger still doesn't work for Linux, and it was a very commonly available camera.
Yes, I have a humidifier in the bedroom to help with dry sinuses each morning, but the static problem doesn't happen nearly as often now that I'm aware of it. My wife has also pointed out that since I nearly always wear shoes, I may be holding the charge better; since she goes around in sock feet most of the time she's home, she rarely ever shocks herself.
As for the difference between being grounded and just experiencing a static shock, you are correct. I probably misused the term. When I say I "grounded" myself, I simply mean that there was a voltage difference between me and some other object, presumably a grounded one, and through my actions I caused the difference to equalize. I have actually been "grounded" in the true sense of the term too - becoming a conductor in a real electric circuit, and I can say that it feels quite different. But, when you're not expecting it, it's easy to mistake one form of shock for another.
For a while, I thought I had a similar problem with both my new Dell laptop, and an old dumpster-diver I had before that. I was getting shocked occasionally when I touched the machines. I initially blamed it on poorly grounded wiring in my house (a rental), until I realized that the problem was electro-static discharge build up from sitting on my Durapella couch.
I worked it out recently when cold winter temperatures drove the humidity way down. Whenever I got up from the couch I would feel the charge build up, then I would inadvertently discharge myself of a light switch, a metal corner post in the drywall, or worse, on some home electronics. After I accidentally blew out the panel of buttons on a DVD player, I did some experiments. By rubbing my hand on the couch cushions for a few seconds, then using a piece of metal held in my hand (less painful that way) to discharge myself to ground, I found I could jump a spark 2 cm or more. Sometimes, I can get multiple sparks on one charge.
It's kind of cool, if you know to expect it. And, the remote still works for the DVD player...
I know this meets none of your criteria, and so completely fails to answer your question, but the best development environment I've ever found is Slime (Superior Lisp Interaction Mode for Emacs). It can work with several different Common Lisp implementations running on Linux, Unix, Mac, and Windows, and since Emacs is cross-platform, it can run on any platform where Emacs is supported. It provides a REPL, object inspector, debugger, single stepping, multi-thread support, stdout re-direction to the REPL buffer, syntax highlighting, auto-indent, expression evaluation from source files, error re-starts, and function cross-referencing, for those Lisps that support them. It offers capabilities reminiscent of the Fabled Lisp Machines of Old.
:)
Slime uses a component running in the Lisp process, and elisp code running in Emacs that communicates with the Lisp through a local INET socket. That means you can run the Lisp process on machine 1, set up an ssh tunnel to it from machine 2, potentially running a different OS, and connect to 1 from an Emacs on 2. I actually do this every day, connecting to a remote SBCL on Linux from both Linux and Windows. The interaction is fast enough that I routinely develop on the remote Lisp image over a WAN link.
The system works with any libraries available for your Lisp implementation, including database, web, and GUI toolkits, although it would be tricky do to GUIs over remote, and Open GL would probably have to be local.
Of course, there are some caveats... Developing in a Lisp is like working in another OS running on top of the host OS (especially with multiple threads). Also, Emacs doesn't have a drag-and-drop GUI builder, although one could be built in Common Lisp. And, you would have to develop a taste for parentheses.
Kansas, I'm afraid.
As for the rest, thanks.
My hometown was much the same. The population is hovering somewhere around 10,000, the high school has the highest teen pregnancy and drop out rates in the state, and the situation hasn't changed much since I graduated 10 years ago. Luckily, I was also aware of a bigger world out there and managed to avoid the vortex. We also watched the 1968 version of Romeo and Juliet and had the teacher fast-forward through the same parts, but watched Glory in full. The description of your experience was so familiar that I briefly wondered if we spent time in the same high school, though I suspect the story is all too common.
Not to go back on-topic or anything, but I have similar thoughts on the hacking of creative works. Yes, the practice is lame and stupid. No, it shouldn't be happening in the first place. But, you can't really outlaw lameness and stupidity, so if some jackass wants to pay a company to censor their own entertainment, a judge shouldn't jump in and stop them.
People who patronize scrub companies are only marginally interested in the creator's vision to begin with, and they certainly care less about it than about offensive material. So what if they miss out? Everyone gets to be happy: The original creators of the piece gain a sale that they wouldn't have otherwise had. The person with the censored copy gets what they want. Everyone else still gets to see the real thing. And, the film-scrubber gets the satisfaction of knowing that he does business with people who prefer to pay extra for less valuable goods.
It's been done a long time ago. Lisp has had this ability for decades, along with a few other features that are only now making it into mainstream programming languages. It's been said for a while now that language design is slowly converging on Lisp. When the s-expression syntax is finally adopted by the average programmer, we'll have caught up with 1968. :)
You're not really asking about interpreted vs. compiled languages. What you're really asking is whether computers have gotten fast enough for us to stop using low-level languages and let the computer handle many of the details in high-level ones.
But, I think the whole question is bollocks because it's based on an incorrect assumption.
There is no inherent tie between LLLs and compiled code, and HLLs and slow, interpreted code. Some HLLs can be compiled into very fast native code. A quick scan of the comments tells me that the name has already been dropped, but I'll put in my plug for Common Lisp. It allows you to use interpreted functions and compiled functions both in the same environment, so that you can develop code quickly, then compile it to get a speed boost. If you need more low-level control to get some extra performance in a bottleneck, you can even do things like declare data types and lower compiler safety levels for individual functions.
Lisp was doing this decades ago, and it was even being used for operating system code in the Lisp Machines. So, computer power really has no relevance to the issue. I think the real barrier to adoption of these kind of high-level techniques is not in the machines, but the beliefs of developers who still think that real programmers do thier own pointer math.
So in the presence of exceptions, you won't leak memory on the heap. But you will leak mutexes, file handles, etc. You need another idiom to handle those cases.
.NET world, C# introduced synchronization blocks to handle the leaking mutex problem. But it is a pain in Managed C++ and VB.NET.
In the
File/mutex/whatever leakage in the presence of exceptions? Two words:
unwind-protect
Whoa there, Anonymous! And perople were saying that I was looking for an excuse to strut!
rexec doesn't belong in the main python distro unless someone is willing to do a full audit and maintain a full security test case. otherwise people will use it expecting protection without understanding what they're doing.
What - unlike the Linux Kernel or OpenSSH? The source is open so that people can check it for bugs. I know that's not the same as a formal audit, but we couldn't do any worse than the closed source JVM from Sun. We both know that make check sets loose a whole battery of tests, and the Python-Dev thread I mentioned shows code that could go into a PyUnit test case. So, what's the problem?
you can still use rexec if you like, but only as an add on module.
No, you can't - that's the whole problem. Rexec wasn't removed because it had a bug; it was removed because the language changed. A new type of class was introduced, so-called new style classes, that inadvertently broke rexec. By using a new style class, you can break out of an rexec jail.
I don't care that a security hole was discovered. I'm just irked because Guido chose cute class semantics over an established security-related module. It wasn't even an either-or decision - he decided not to fix the module just because he didn't want to deal with it. My project will no longer use Python simply because it can't now that rexec is gone. If this happens to many other projects, Python's future won't be secure in either sense of the word.
Agh, look I love Python but the Global Interpreter Lock's got to go. Threading is severely crippled as long as it's still there... I mean, failing that can't we at least have independent interpreters?
Please? I've looked around for efforts to sort this out but the last of them seems to have died around 1997...
Amen, Brother Derivative! I've actually played with the idea of just removing the GIL code myself to see what breaks (although I suspect quite a bit would). After all, you should use locks to regulate access to variables anyway. It would be dangerous because it would open up the possiblity of a bug crashing the interpreter instead of just the application, but I'd at least like a run-time option to disable it.
And independent interpreters would would make my life a whole lot easier when it comes to embedding Python as a macro language (to which Python is supposed to lend itself easily). It would also allow me to use teminable threads...
I think Perl suffers from these same minor deficiencies. I suspect that's due to the inevitable switch to the Parrot interpreter.
The module advertised to do one thing, "restricted environment" but then failed to deliver. Guido had an obligation to mark it broken and/or remove it.
As for fairly secure, python does not have a sandbox... but I hardly think that the lack of a sandbox makes python insecure.
I'm not disputing the decision - if rexec wasn't salvagable, it should have been dropped. And the specific issue of having a sandbox is not really the point. Guido is saying that he doesn't have confidence in his sucurity design skills, but then he says that Python is secure. Why should we trust the C runtime to not have buffer overflows?
If he wants to say that Python is secure, he should stand behind one of Python's only explicitly security-related modules.
I can understand dissapointment at a "feature" disappearing, but his reasoning was the soundest decision that I have heard of in a long time.
I don't disagree with the decision itself - there is another thread on that site (lost the link) that implies that the new class semantics in Python 2 make it impossible to implement an effective rexec environment. In that case, rexec is a moot point.
But, after accepting that, I hear Guido saying that Python is secure and is being used for security projects. Is that wise, considering that he is removing features because he is afraid that insufficient security consideration was taken in the design? I always thought that the Open-Source development methodology was supposed to fill in those kind of gaps by leveraging the expertise of many people.
I'd like to point out a thread that I found a little while back on Python-Dev about Guido's decision to remove the rexec module (similar to the Java sandbox):
posting 1
and Guido's reply:
posting 2
A little bit further down that thread we find this:
posting 3
Since this last one is particularly telling, I will quote the relevant text for our impatient readers:
I think Guido's rationale for removing all these features will be widely misunderstood. Me channeling him: it is not that he believes that the architectures developed were inherently incapable of providing security. Instead, he feels that no "expert" for these matters has reviewed these architecture for flaws, and that the continuing maintenance of these things isn't going to happen.
If this understanding is correct, then any new approaches will likely suffer from the same fate. Unless somebody steps forward and says: "I am a security expert, and I guarantee that this and that feature is secure (in some documented sense)", then I think he will dislike any changes that mean to provide security.
So this not a matter of engineering but of authority. Somebody must take the blame, and Guido doesn't want to be that someone.
Disclaimer: I love python. However, I am working on a project that depends on rexec, and when I discovered that it was being removed, I was a little annoyed - especially at the reasoning behind the decision.
But, about a year ago I found a copy of Consider Phlebas in a Borders, along with 2 other titles, which I stupidly decided not to purchase. I was a bit annoyed to discover that it was only there by mistake; the back of the book had a U.K. price, a Canadian price, and a note saying "NOT FOR SALE IN THE USA". WTF?
-WH-
I keep information on all the books I've read in my brain.
So, what is Jon trying to say here? These Mac and Linux users have just been too pleased with themselves lately? "Yeah, you guys have great technology, but you still don't have market share". So what.
Lately (the last couple of years), I've noticed a huge trend toward a focus on market share, owning the desktop, and taking over the world. I think Mr. Katz and a whole lot of people in the Linux and Windows communities are the ones who have missed the point; I don't use Linux because I want to take over the world. I don't use it because I want to 'stick it' to Bill Gates, and I don't use it because I think it's cool. All of those things are nice ideas, but they are totally secondary. I think they are for most Mac users, too.
I use Linux because it allows me to do the things I want to do better than any other operating system. I'm a hacker, so I choose the OS that makes it easiest for me to hack. Linux provides me with more power and scalability than any other comparable system, and it easily supports almost every programming language in the world, all for a low cost.
I frankly don't care how neat and nifty the OS is, and I don't care who else uses it. In fact, I don't think everyone in the world should use Linux- "widest possible appeal" was one of Windows' design goals, and look at what it produced. Linux's specialization is what makes it valuable to me. So, Jon, before you get down on me for "not getting it", you get it; Linux is not winning the market share game because most of the Linux community has better things to do with its time.
I don't know if it was actually published in 2001, but that's when I bought it. Descent 3 for Linux is an excellent port of the Windows version, and it even adds a few features that the Windows version doesn't have (like no-mouse-grab and rendering in a window). You just can't beat 6DoF in a first person shooter, as long as you don't get motion sickness too easily. :) Multiplayer is incredible too, with lots of multiplayer game modes.
Then again, I always said that Linux itself was the ultimate video game- it's the only one that's kept me playing continuously for 6 years.
The point isn't whether Open Source companies can stay Open Source or not. The companies could all go bankrupt and it wouldn't stop Open Source. Before it had a catchy name, Open Source was just people writing programs that they wanted for their own purposes, and sharing them with other people. The loss of a few trendy business models won't change that.
In fact, it might actually help Open Source in general by sweeping out all the cruft, just like the current slump is cleaning up the dot-com fad. The people who are left will be the ones that develop Open Source software because they just care about having the software, not because they want to capitalize on a freely available army of developers.
Before, developers (or their companies) wouldn't openly release things that they felt really created a competitive edge. (Non-software companies didn't try to sell such systems either. They kept the advantage for themselves.) Now, these Open Source companies are trying to make a profit from creating software that, by definition, is their competitive edge. And they want to release all the source? Not likely. I don't want to sound like one of those people who yammer about how Open Source advocates shouldn't want everything for free, but it doesn't surprise me that these companies are dropping off and selling out. In the end, it doesn't really matter- the heart of Open Source exists outside of these companies.
Thank you for not reading the body of my post. The point is that software has nothing to do with iron bridges in the 18th century. A bridge is drawn up by some civil engineer who actually knows about statics and materials, then is built by construction workers who input almost nothing to the design. Any one of the workers could be replaced with almost no effect, because they are all just following the engineers instructions anyway.
With software engineering, things are different because the high-level designer talks about object models and protocols, but the code is actually written by programmers who are solving the hundreds of little problems that go along with actually fleshing out the specification. Just specifying the pre and post-conditions of a function doesn't write the function. A coder actually needs to figure out how to do it. Sure, most of the problems are pretty repetitive and trivial, but many are not, which is why automated code generation only goes so far.
The thing that really gets me is that researchers in the field of software engineering can't even decide among themselves whether or not programming is like construction. The question still isn't resolved. They spend their time fooling around with antiquated methods and voodoo like Halstead's "Software Science".
I'm a little concerned because Open Source seems to be leaning in that direction, especially with these large projects like Mozilla and Gnome (although there are plenty more). People marvel at the sheer size of these applications, and I believe the problem is that they are no longer hackers working in their own self interest to fix bugs and add desired features. Instead, they are a huge team working on lots of little pieces that add up to a lot of bloat. Remember The Cathedral and the Bazaar? ESR says that one of the things that makes Open Source great is its freedom from conventional management structures.
No. Actually, I've been programming since the AplleSoft Basic days with the Apple IIe. I've worked on multiple-10-KLOC-sized projects, and I've done both code maintenance and original design.
I also remember the days when flowcharts were an absolute necessity for good programming- if you didn't use them, you lacked professionalism. I took some heat for balking at that idea back then.
I felt that flowcharts were an ill-concieved method of planning programs. Now, flowcharts are virtually extinct in the development process, and I'm paying my bills by writing code the same way I always have.
This is a subject that really irks me in light of the conventional "Software Engineering" mindset. Most of SE nowadays seems to be aimed at making software projects as predictable as possible, as if they were like civil construction projects. The fact of the matter is that they are not like building projects... If we conform to the doctrine of software re-use, on of SE's central tenants, we should never have to re-write a piece of software, so we will never know what the complexity of the related problems are until the project is finished. Software has nothing to do with engineering- it is more like original composition, like writing a symphony or novel, except that it also has a constraint for rigorous correctness. Physics is a good analogy for that.