I would say details of this sort are more appropriate for Wikipedia books, ie. Wikibooks. It's not that Wikipedia doesn't have a place for these things, it's simply that they must be put in their proper place.
...and the people interested in them generally have journal subscriptions and such to access details. I think a decent criteria to start with is if the proof takes less than a page, and uses high school level mathematics. University students or faculty have access to the university's subscriptions so a cite on Wikipedia suffices.
A "decent timeout" is trivially simple -- mark your cookie only valid for the current session (aka, use a "session cookie"). This is at odds with persistent login designs, so you have to give users the option -- login with a session cookie ("public terminal") that will expire when you close the browser, or login with a persistent cookie ("private terminal") that will remain valid for some period of time.
The server cannot trust an unknown browser to expire the cookie and the server cannot detect when a remote browser has been closed, so the GP is right: a timeout is an arbitrary solution, and there is no good metric for choosing a timeout. Fortunately, the security properties of iDisk contain no flaw that doesn't already exist in a session/login-based web app. Fact is, this "flaw" is simply not a flaw at all.
If someone has physical access to your machine, you're completely screwed 5 ways from Sunday REGARDLESS of the access controls in place. There is NO protection from such an attack. Consider the situation where the site did require a login: the person who gains access to your machine then installs a keylogger and steals your password. SAME conclusion. The key concept here is that no security is invulnerable once you lose control of the hardware. The RIAA and MPAA have been learning this lesson for the past few years. The only way to secure your data, is to encrypt it and carry the security token which holds the decryption hardware and/or key with you. Given enough brute-force or cryptanalysis, even this solution is vulnerable. Some future advancements in security might solve this fundamental problem, but given current knowledge it's simply impossible. In conclusion, the design of Apple's iDrive service is not a security flaw.
But how do we know that the tools we believe give us these things, are actually working correctly?
A capability design is actually quite simple. To get it right is not hard at all, relatively speaking. Most of the languages I mentioned already have a capability core, and they went out of their way to bypass it. Securing those languages means removing features, not adding them.
Of course, reasoning about complex systems assembled from myriad low-level objects can be quite complex. Security experts usually try to tackle complex systems using high level policies and then verifying that the model enforces the policy. SCOLLAR is such a verification tool for capability systems.
Then comes the task of verifying the implementation is faithful to the model. Ultimately, verification is a problem in any field. How do mathematicians guarantee their proofs are correct? They check it, they mechanize it in an automated theorem prover, etc. How do we prove the theorem prover is correct, or the reviewers didn't make a mistake? Other people triple-check, audit the code, prove the code correct using another theorem prover, and so on.
The benefits of capabilities here are two-fold: 1) POLA implies partitioned subsystems, which means modularity and locality, which facilitates auditing (which is almost intractable for any existing system since they require global knowledge instead of just local knowledge), and 2) they actually have a verifiable security model with which we can reason about high-level policies. If you check the security literature, access-control list systems are known to be unverifiable and so we can't reason about their security properties with sufficient confidence.
Regarding root-kits, certainly any vulnerabilities are exploitable, but by the very nature of POLA the damage of any one exploit is isolated to a particular subsystem, akin to puncturing the skin at best; exploits in current systems are total penetrations, a veritable knife to their hearts.
I suppose you also believe that evolution, intelligent design and the Flying Spaghetti Monster should have equal representation in the school curriculum?
Wikipedia is not the school system.
And should the page about the landing on the moon have half the text stating that it is not an accepted fact and that the landing could have been faked.
No, but it absolutely should have half a page describing that many people believe in a conspiracy to fake the moon landings, or at the very least a mention with a link to its own in-depth page.
There's no such thing as absolute truth, but if you include every single point of view, you end up not carrying any information either.
There is such a thing as absolute truth, but Wikipedia is not about making the judgment of absolute truth, it's about representing significant facts. The fact that people believe in moon landing conspiracies is true, the fact that people believe in intelligent design as a opposed to evolution is true. Whether any of those beliefs is true is irrelevant.
I participated in a long debate on the Redshift article with a very competent, scientifically-minded individual who had great trouble accepting edits which discussed frequency-dependent redshifts. Once again, here was a clear misunderstanding of Wikipedia's purpose: it's not to champion truth, it's about representing facts, and it's a fact that people use 'redshift' as a more general term in other disciplines, despite it not being a "general redshift" across all wavelengths like a relativistic redshift.
A leap in security technology will take a requisite leap in human intelligence.
Not at all. A leap in security will take a requisite change in our development tools, from identity-centric abstractions, to authorization-centric abstractions so we can achieve the Principle of Least Authority (POLA) for all software. Ultimately, it's not about adding security, it's about removing insecurity; most languages have insecure abstractions baked into them, and when those are removed, the resulting software is significantly more secure, and yet, poses no significant burden on the developer; quite the opposite in fact: the software becomes more modular and maintainable. See the discussions on capabilities, and the E, and Emily capability-secure programming languages for examples. There have been numerous case-studies on the vulnerabilities of identity-centric services, and how they were rectified by refactoring the service to use authorization-centric models.
I am by no means an expert on this but I do code web applications for a living. I will tell you that these changes do not necessarily "improve reliability, security and performance" of HTML.
Of course, Crockford is pretty much an expert on this, so perhaps you should give it a bit more thought before writing it off.
This is ridiculous. You are attacking the wrong target here, you should be attacking the browsers that don't behave according to standards like the cowboy Internet Explorer browser that sometimes does whatever it wants. Many nights I have spent hacking code that checks what browser is being run and behaves differently because it's Internet Explorer and not "everybody else."
I'll give you a hint: you cannot add simplicity, you must remove complexity. You cannot add security, you must remove insecurity.
Simplifying the standard means HTML renderers are more likely to get it right the first time. That does mean fewer late nights ensuring conformance across all browsers, which by your own admission is exactly what you want. It also means fewer vulnerabilities since the attack vectors are much smaller.
I got a 25% speed gain from some code I was working on a few years ago just be moving a couple of functions into a header and marking them as static inline so the compiler could inline them.
Some might say that's an optimization the compiler should be able to perform on its own, but your point is still valid: most modern compilers still aren't smart enough to do these sorts of optimizations reliably, ie. proper alignments to optimize memory accesses, transparent data structure compressions, etc. LLVM has done lots of work improving on the state of the art here, and they have a shot at eventually replacing GCC. Let's hope they succeed; it's currently the code generator in Apple's OpenGL engine, and in use in a number of other projects.
Is it just me or does it seem like 60MB or even 34MB is a LOT of memory for something that browses Web pages?
But a browser doesn't just browse web pages. A browser is a limited form operating system, as it has an execution language (Javascript) and environment (the DOM). A mail client is relatively simple as it's just a texty protocol. A browser is HTML + XML + CSS + HTTP/S + JPG/PNG/GIF/etc renderers + embedded plugins + caches, and in case of FF, it has XPCOM and various other extensible subsystems.
Seems immature and counter-productive to declare that anyone who says they experience this is lying just because they don't put enough effort into helping us fix it.
I never said anyone was lying; those are the words the GP poster put into my mouth. The original statement I contradicted was >1GB for 2 or 3 tabs which has never occurred on any of my, or my client's computers (some 20+ machines in total) in a broad range of usages with stock configs.
Maybe he has Firebug or another memory-hogging extension installed (not Firefox's fault). Maybe he's browsing large photos or intense AJAX apps. When I want to use YouTube or browse photos on Flickr, I always open another browser, because otherwise I'll have to restart Firefox when it swells to using half my memory and that again in swap.
I have all of these extensions, including the web developer toolbar, petname toolbar, bugmenot, and the javascript debugger, and browse all of these sites in the same browser, with 50+ tabs and FF has never risen above 600MB. It slows a bit as it approaches 400MB, but it's not unbearable.
So the current release has (or had--minor releases fix some) 300+ leaks, but it's worse than wrong to say it leaks memory?
As I discussed, stock config, even with the many extensions and plugins I have installed, has negligible leaks. I know FF leaks in an absolute sense, as the process grows by maybe 5MB every time I wake from hibernation for no discernible reason, but that only necessitates a restart every two weeks! I usually have to restart Windows before I have to restart FF. Overall, that's pretty decent, and the criticisms that it leaks paint a much harsher picture (like the post I first replied to), which makes them FUD.
Overall, there plenty of work to be done to make FF more resistant to leaks, particularly in the plugin and extension API; the core seems fairly solid though. Ideally, I'd like a core written in a memory safe language with a compacting GC to avoid many of these problems, but I'm sure that won't be coming anytime soon.
My system has 2GB of memory, so caches would be far larger than on typical systems; if I'm only seeing 500MB of usage, most other people will see less, particularly with 50+ tabs open. My bread and butter is web applications development, which means I'm browsing far more than the average individual, and thus far more likely to see errant behaviour. I use a stock configuration, with a custom homepage. The only uncontrolled variables are plugins, which can't be blamed on Firefox. Same results on a completely different system as well. This is more than mere anecdotal evidence: it's observation under a controlled environment, otherwise known as the scientific method.
Now if people experiencing memory growth would conduct similar tests with their unusual configurations, and stop spouting "FF leaks memory!", then perhaps we can narrow it down to the actual source of their problem. If FF itself leaks memory, it's negligible; stating FF leaks memory is worse than wrong: it's a malicious attack, aka FUD.
Millions of people who browse two or three pages, then close their browser have no problems.
Bull. I have over 50 tabs open. I regularly hibernate my computer, and only do a full restart maybe once every other week, so technically, my FF is running for almost 2 weeks straight. Firefox has never gone over 600MB. It gets progressively slower and consumes slightly more memory on each wakeup, but it never stops working, and it has never approached 1GB. I used this same pattern on my previous machine as well (only 4 months ago), so it's not a peculiarity of my installation.
auto_ptr have scoped lifetimes; in other words, no better than stack-allocated objects. scoped_ptr doesn't seem much better than manual memory management, except for its use of RAII which prevents uninitialized use.
C/C++ have stack-variables, and I agree, there's nothing more memory efficient than this.
Region-based memory management (also sometimes known as arenas in the C/C++ world) is at least as efficient, and strictly more general than stack allocation.
You do not usually need to use pointers that often, but when you do smart pointers can help manage lifetime without any overhead.
I could chalk your post up to a matter of opinion right up until I hit this point. Fact is, smart pointers ARE an incremental garbage collection technique called reference counting. In fact, it's now well known that all garbage collectors are a hybrid between incremental reference counting techniques and stop-the-world tracing techniques.
What surprises me is that outspoken proponents of managed languages use the garbage collection so often as a good thing, as if now you can be a sloppier programmer and get away with it.
No, it lets you become a *better* programmer because the focus is now on the algorithms, instead of cluttered with resource management issues.
In reality you have to identify/control the lifespan of objects anyway, so I personally never understood what the big deal is about freeing memory manually.
With respect, you will probably never understand the big deal until you work in a more advanced language such as Haskell or OCaml. The fact is, you often *don't* have to manage resource lifetimes, and the advantages of automatic memory management become *very* apparent when you work in fine-grained compositional languages, rather than coarse-grained imperative languages.
And since for many resources it isn't nearly as appropriate to 'lazy' free them, as a programmer you still have to be aware of the allocate/free paradigm.
I've heard this trumpeted may times, but it's a fallacy. Memory is a fine-grained resource whose lifetime is error-prone and tedious to manage. Coarse-grained resources such as file handles or sockets are easier to manage, and their lifetimes are part of the semantics of their interface (although Java and C# do a very poor job of specifying these semantics in their interfaces).
I would totally agree with you that manual memory management was good if it had a proper formal semantics which prevented you from freeing memory early. In fact, such languages have been built. C/C++ is not one of them.
I wish people would stop using GC as an argument why languages as Java are so much better to use than C++.
Seriously! There are so many other reasons, why focus on just the one!;-)
NO! It is not a good thing, if a program slowly leaks memory then it just makes it harder to find the bug. If you have to reboot the app every week because it has a little leak, no-one's going to be bothered (except the users who see it slowly getting slower).
This implies the language is lacking something, not that automatic memory management is a poorer choice than manual memory management. In this case, the language lacks facilities to book memory to executing agents (like a lightweight language process), and to recover from failures, ie. kill and restart the language process running the application (see Erlang for instance). Now you have your automatic memory management, AND your automatic failure recovery.
What is interesting is to see that garbage collection changes one class of bugs (forgetting to explicitly deallocate memory) to another one: unintentionally keeping objects around.
Pardon the analogy, but there's a big difference shooting yourself in the foot with a shotgun and a bb gun; 9.999 times out of 10, your foot will survive a shot from a bb gun.
Functional languages are much better from a security standpoint. Look up Omega-7 or E if you don't believe me.
If you're referring to w7 and E of capability security fame, then I'm well aware of them. However, they are not the predominant functional languages (Lisp, Scheme, Haskell, OCaml/ML), so as a broad classification, "functional languages" have only marginally better security properties as a result of their better abstraction abilities and static type systems.
There's a reason E's authors call it an object-capability language, and not a functional language.
Slashdot Mirror
I would say details of this sort are more appropriate for Wikipedia books, ie. Wikibooks. It's not that Wikipedia doesn't have a place for these things, it's simply that they must be put in their proper place.
It's exactly the same problem. How do you know that unknown machine isn't logging your password?
While I can sympathize, I think Wikipedia has to be realistic: they can't support the world's knowledge. The strain would be simply too much.
...and the people interested in them generally have journal subscriptions and such to access details. I think a decent criteria to start with is if the proof takes less than a page, and uses high school level mathematics. University students or faculty have access to the university's subscriptions so a cite on Wikipedia suffices.
A "decent timeout" is trivially simple -- mark your cookie only valid for the current session (aka, use a "session cookie"). This is at odds with persistent login designs, so you have to give users the option -- login with a session cookie ("public terminal") that will expire when you close the browser, or login with a persistent cookie ("private terminal") that will remain valid for some period of time.
The server cannot trust an unknown browser to expire the cookie and the server cannot detect when a remote browser has been closed, so the GP is right: a timeout is an arbitrary solution, and there is no good metric for choosing a timeout. Fortunately, the security properties of iDisk contain no flaw that doesn't already exist in a session/login-based web app. Fact is, this "flaw" is simply not a flaw at all.
You'd think Apple of all people (er, companies) would understand the need to make the right interface for different kinds of applications.
:-)
They did make the right interface. Fact is, this is not a security flaw. No, seriously.
If someone has physical access to your machine, you're completely screwed 5 ways from Sunday REGARDLESS of the access controls in place. There is NO protection from such an attack. Consider the situation where the site did require a login: the person who gains access to your machine then installs a keylogger and steals your password. SAME conclusion. The key concept here is that no security is invulnerable once you lose control of the hardware. The RIAA and MPAA have been learning this lesson for the past few years. The only way to secure your data, is to encrypt it and carry the security token which holds the decryption hardware and/or key with you. Given enough brute-force or cryptanalysis, even this solution is vulnerable. Some future advancements in security might solve this fundamental problem, but given current knowledge it's simply impossible. In conclusion, the design of Apple's iDrive service is not a security flaw.
But how do we know that the tools we believe give us these things, are actually working correctly?
A capability design is actually quite simple. To get it right is not hard at all, relatively speaking. Most of the languages I mentioned already have a capability core, and they went out of their way to bypass it. Securing those languages means removing features, not adding them.
Of course, reasoning about complex systems assembled from myriad low-level objects can be quite complex. Security experts usually try to tackle complex systems using high level policies and then verifying that the model enforces the policy. SCOLLAR is such a verification tool for capability systems.
Then comes the task of verifying the implementation is faithful to the model. Ultimately, verification is a problem in any field. How do mathematicians guarantee their proofs are correct? They check it, they mechanize it in an automated theorem prover, etc. How do we prove the theorem prover is correct, or the reviewers didn't make a mistake? Other people triple-check, audit the code, prove the code correct using another theorem prover, and so on.
The benefits of capabilities here are two-fold: 1) POLA implies partitioned subsystems, which means modularity and locality, which facilitates auditing (which is almost intractable for any existing system since they require global knowledge instead of just local knowledge), and 2) they actually have a verifiable security model with which we can reason about high-level policies. If you check the security literature, access-control list systems are known to be unverifiable and so we can't reason about their security properties with sufficient confidence.
Regarding root-kits, certainly any vulnerabilities are exploitable, but by the very nature of POLA the damage of any one exploit is isolated to a particular subsystem, akin to puncturing the skin at best; exploits in current systems are total penetrations, a veritable knife to their hearts.
I suppose you also believe that evolution, intelligent design and the Flying Spaghetti Monster should have equal representation in the school curriculum?
Wikipedia is not the school system.
And should the page about the landing on the moon have half the text stating that it is not an accepted fact and that the landing could have been faked.
No, but it absolutely should have half a page describing that many people believe in a conspiracy to fake the moon landings, or at the very least a mention with a link to its own in-depth page.
There's no such thing as absolute truth, but if you include every single point of view, you end up not carrying any information either.
There is such a thing as absolute truth, but Wikipedia is not about making the judgment of absolute truth, it's about representing significant facts. The fact that people believe in moon landing conspiracies is true, the fact that people believe in intelligent design as a opposed to evolution is true. Whether any of those beliefs is true is irrelevant.
I participated in a long debate on the Redshift article with a very competent, scientifically-minded individual who had great trouble accepting edits which discussed frequency-dependent redshifts. Once again, here was a clear misunderstanding of Wikipedia's purpose: it's not to champion truth, it's about representing facts, and it's a fact that people use 'redshift' as a more general term in other disciplines, despite it not being a "general redshift" across all wavelengths like a relativistic redshift.
A leap in security technology will take a requisite leap in human intelligence.
Not at all. A leap in security will take a requisite change in our development tools, from identity-centric abstractions, to authorization-centric abstractions so we can achieve the Principle of Least Authority (POLA) for all software. Ultimately, it's not about adding security, it's about removing insecurity; most languages have insecure abstractions baked into them, and when those are removed, the resulting software is significantly more secure, and yet, poses no significant burden on the developer; quite the opposite in fact: the software becomes more modular and maintainable. See the discussions on capabilities, and the E, and Emily capability-secure programming languages for examples. There have been numerous case-studies on the vulnerabilities of identity-centric services, and how they were rectified by refactoring the service to use authorization-centric models.
Like most problems, textual code reuse has via copy & paste has already been studied, and a language based on first-class copy & paste is being developed; it's called the Subtext language. See a more detailed discussion of it on lambda-the-ultimate. Academia is not so far remove from everyday programming as people seem to think!
I am by no means an expert on this but I do code web applications for a living. I will tell you that these changes do not necessarily "improve reliability, security and performance" of HTML.
Of course, Crockford is pretty much an expert on this, so perhaps you should give it a bit more thought before writing it off.
This is ridiculous. You are attacking the wrong target here, you should be attacking the browsers that don't behave according to standards like the cowboy Internet Explorer browser that sometimes does whatever it wants. Many nights I have spent hacking code that checks what browser is being run and behaves differently because it's Internet Explorer and not "everybody else."
I'll give you a hint: you cannot add simplicity, you must remove complexity. You cannot add security, you must remove insecurity.
Simplifying the standard means HTML renderers are more likely to get it right the first time. That does mean fewer late nights ensuring conformance across all browsers, which by your own admission is exactly what you want. It also means fewer vulnerabilities since the attack vectors are much smaller.
I got a 25% speed gain from some code I was working on a few years ago just be moving a couple of functions into a header and marking them as static inline so the compiler could inline them.
Some might say that's an optimization the compiler should be able to perform on its own, but your point is still valid: most modern compilers still aren't smart enough to do these sorts of optimizations reliably, ie. proper alignments to optimize memory accesses, transparent data structure compressions, etc. LLVM has done lots of work improving on the state of the art here, and they have a shot at eventually replacing GCC. Let's hope they succeed; it's currently the code generator in Apple's OpenGL engine, and in use in a number of other projects.
Is it just me or does it seem like 60MB or even 34MB is a LOT of memory for something that browses Web pages?
But a browser doesn't just browse web pages. A browser is a limited form operating system, as it has an execution language (Javascript) and environment (the DOM). A mail client is relatively simple as it's just a texty protocol. A browser is HTML + XML + CSS + HTTP/S + JPG/PNG/GIF/etc renderers + embedded plugins + caches, and in case of FF, it has XPCOM and various other extensible subsystems.
Seems immature and counter-productive to declare that anyone who says they experience this is lying just because they don't put enough effort into helping us fix it.
I never said anyone was lying; those are the words the GP poster put into my mouth. The original statement I contradicted was >1GB for 2 or 3 tabs which has never occurred on any of my, or my client's computers (some 20+ machines in total) in a broad range of usages with stock configs.
Maybe he has Firebug or another memory-hogging extension installed (not Firefox's fault). Maybe he's browsing large photos or intense AJAX apps. When I want to use YouTube or browse photos on Flickr, I always open another browser, because otherwise I'll have to restart Firefox when it swells to using half my memory and that again in swap.
I have all of these extensions, including the web developer toolbar, petname toolbar, bugmenot, and the javascript debugger, and browse all of these sites in the same browser, with 50+ tabs and FF has never risen above 600MB. It slows a bit as it approaches 400MB, but it's not unbearable.
So the current release has (or had--minor releases fix some) 300+ leaks, but it's worse than wrong to say it leaks memory?
As I discussed, stock config, even with the many extensions and plugins I have installed, has negligible leaks. I know FF leaks in an absolute sense, as the process grows by maybe 5MB every time I wake from hibernation for no discernible reason, but that only necessitates a restart every two weeks! I usually have to restart Windows before I have to restart FF. Overall, that's pretty decent, and the criticisms that it leaks paint a much harsher picture (like the post I first replied to), which makes them FUD.
Overall, there plenty of work to be done to make FF more resistant to leaks, particularly in the plugin and extension API; the core seems fairly solid though. Ideally, I'd like a core written in a memory safe language with a compacting GC to avoid many of these problems, but I'm sure that won't be coming anytime soon.
My system has 2GB of memory, so caches would be far larger than on typical systems; if I'm only seeing 500MB of usage, most other people will see less, particularly with 50+ tabs open. My bread and butter is web applications development, which means I'm browsing far more than the average individual, and thus far more likely to see errant behaviour. I use a stock configuration, with a custom homepage. The only uncontrolled variables are plugins, which can't be blamed on Firefox. Same results on a completely different system as well. This is more than mere anecdotal evidence: it's observation under a controlled environment, otherwise known as the scientific method.
Now if people experiencing memory growth would conduct similar tests with their unusual configurations, and stop spouting "FF leaks memory!", then perhaps we can narrow it down to the actual source of their problem. If FF itself leaks memory, it's negligible; stating FF leaks memory is worse than wrong: it's a malicious attack, aka FUD.
Millions of people who browse two or three pages, then close their browser have no problems.
Bull. I have over 50 tabs open. I regularly hibernate my computer, and only do a full restart maybe once every other week, so technically, my FF is running for almost 2 weeks straight. Firefox has never gone over 600MB. It gets progressively slower and consumes slightly more memory on each wakeup, but it never stops working, and it has never approached 1GB. I used this same pattern on my previous machine as well (only 4 months ago), so it's not a peculiarity of my installation.
auto_ptr have scoped lifetimes; in other words, no better than stack-allocated objects. scoped_ptr doesn't seem much better than manual memory management, except for its use of RAII which prevents uninitialized use.
C/C++ have stack-variables, and I agree, there's nothing more memory efficient than this.
Region-based memory management (also sometimes known as arenas in the C/C++ world) is at least as efficient, and strictly more general than stack allocation.
You do not usually need to use pointers that often, but when you do smart pointers can help manage lifetime without any overhead.
I could chalk your post up to a matter of opinion right up until I hit this point. Fact is, smart pointers ARE an incremental garbage collection technique called reference counting. In fact, it's now well known that all garbage collectors are a hybrid between incremental reference counting techniques and stop-the-world tracing techniques.
What surprises me is that outspoken proponents of managed languages use the garbage collection so often as a good thing, as if now you can be a sloppier programmer and get away with it.
;-)
No, it lets you become a *better* programmer because the focus is now on the algorithms, instead of cluttered with resource management issues.
In reality you have to identify/control the lifespan of objects anyway, so I personally never understood what the big deal is about freeing memory manually.
With respect, you will probably never understand the big deal until you work in a more advanced language such as Haskell or OCaml. The fact is, you often *don't* have to manage resource lifetimes, and the advantages of automatic memory management become *very* apparent when you work in fine-grained compositional languages, rather than coarse-grained imperative languages.
And since for many resources it isn't nearly as appropriate to 'lazy' free them, as a programmer you still have to be aware of the allocate/free paradigm.
I've heard this trumpeted may times, but it's a fallacy. Memory is a fine-grained resource whose lifetime is error-prone and tedious to manage. Coarse-grained resources such as file handles or sockets are easier to manage, and their lifetimes are part of the semantics of their interface (although Java and C# do a very poor job of specifying these semantics in their interfaces).
I would totally agree with you that manual memory management was good if it had a proper formal semantics which prevented you from freeing memory early. In fact, such languages have been built. C/C++ is not one of them.
I wish people would stop using GC as an argument why languages as Java are so much better to use than C++.
Seriously! There are so many other reasons, why focus on just the one!
NO! It is not a good thing, if a program slowly leaks memory then it just makes it harder to find the bug. If you have to reboot the app every week because it has a little leak, no-one's going to be bothered (except the users who see it slowly getting slower).
This implies the language is lacking something, not that automatic memory management is a poorer choice than manual memory management. In this case, the language lacks facilities to book memory to executing agents (like a lightweight language process), and to recover from failures, ie. kill and restart the language process running the application (see Erlang for instance). Now you have your automatic memory management, AND your automatic failure recovery.
What is interesting is to see that garbage collection changes one class of bugs (forgetting to explicitly deallocate memory) to another one: unintentionally keeping objects around.
Pardon the analogy, but there's a big difference shooting yourself in the foot with a shotgun and a bb gun; 9.999 times out of 10, your foot will survive a shot from a bb gun.
I know, what's your point? Joe-E is implemented on top of Java, but like w7, must tame the underlying platform. Scheme is not secure.
Functional languages are much better from a security standpoint. Look up Omega-7 or E if you don't believe me.
If you're referring to w7 and E of capability security fame, then I'm well aware of them. However, they are not the predominant functional languages (Lisp, Scheme, Haskell, OCaml/ML), so as a broad classification, "functional languages" have only marginally better security properties as a result of their better abstraction abilities and static type systems.
There's a reason E's authors call it an object-capability language, and not a functional language.