``The same was said for Java. It was sold as the ultimate final language built on 50 years of accumulated knowledge of language design and computer architecture.''
Seriously? If there is anything Java and the culture around it have done wrong, it is _not_ learning from what came before it.
Why, how did you know. I do live in the Netherlands. And I am pissed off that I have to spend effort on my mail servers to curb the spam. Can't tell if the women are wearing parkas, cause I can't see any from my basement.
``To say that one method of error handling is superior or correct or even required over the other is a little naive.''
I disagree. Forget to check a return code and nobody might ever find out, except that some people will end up with corrupted data. Forget to check an exception and you will (in most implementations, at least) get an error message telling you what went wrong and where in the program. Some systems (Lisp systems, in particular) will go as far as letting you fix the error and continue the program. I think exceptions _are_ fundamentally superior over error codes, and I am quite curious about why the designers decided not to put them in Go.
``But if the developer of a platform decides to make available only a non-real-time automatic memory management system, developers of interactive applications are screwed.''
You mean "if there is something in the platform that causes every app to suck, then you're screwed". Yes. But actual real-time guarantees are very rarely needed. Yes, there are extremely sucky garbage collectors. There are insanely sucky malloc implementations, too. This is not an issue of automatic vs. manual memory management.
``I believe this makes up a large part of tracing garbage collection's bad reputation: early versions of Java had no real-time collector.''
No, garbage collectors had a bad reputation long before Java existed. And they used to be bad. And bad ones are still being written. But they aren't necessarily bad, and some of them are actually really good. That's what I'm trying to get people to see.
``A lot of function calls that interact with memory allocate a piece of memory and then free it before the end. These are ideal candidates for reference counting.''
Define "ideal". Reference counting is quite expensive. It also breaks when there are cycles in your object graph. If you use reference counting for resource management, you are effectively making your program slower while still allowing resource leaks. I don't see the point in that.
If you want something like "close this file at the end of this block", you can use a construct like Common Lisp's with-open-file:
(with-open-file (file "/etc/passwd")
; do something with file here
)
Or, of course, your favorite equivalent in your favorite programming language.
ie. Manual management works like this: alloc, dealloc, alloc, dealloc, alloc dealloc.
GC works like this: alloc, alloc, alloc, dealloc, dealloc, dealloc.''
Depends. Generally, garbage collection happens when the heap is fully. In the ideal case, that never happens, and you see everything being deallocated in one fell swoop when the program terminates. In pathological cases, you see GC being run for every memory allocation, spending a lot of time but freeing virtually no heap space.
``So overall there is no difference to speak of.''
Perhaps under "normal" circumstances, but there are cases where the difference is enormous.
``There are places where you can see a benefit to one over the other. In GC, you do not get the fragmentation of the heap like you do with manual management.''
Depends on the memory manager. There are GCs that defragment, but also those that don't. There are also malloc implementations that fragment a lot and malloc implementations that fragment very little.
``However, in GC you do have to walk the heap and compress it.''
Again, depends on the GC. There are compacting GCs and non-compacting GCs. There are those that scan live objects and those that scan garbage. There are generational and non-generational, real-time and non-real-time GCs... there is a lot of work out there, and your generalizations really don't apply to all of it.
``GC can have better performance with shared objects, ie once allocated an object can be passed around by passing the 'pointer' to it.''
I don't think that is a property of GC. It's just something that automatic memory management makes easier, because, unlike manual memory management, you don't have to keep track of who is responsible for when the space is to be freed.
``GC does have an issue with memory leakage - see the notes that inexperience C# programmers have been complaining of when not (manually) removing event handlers from UI components. The GC never frees them if there's always a reference held to an in-use object, even if that object no longer gets used.''
You mean that garbage collectors only reclaim memory that is no longer referenced, not memory that is referenced but will not ever be used. You are right about that.
``GC also has issues with 'deterministic finalisation' - which is not a problem if the only resource used by your object is memory, but it is a huge problem for all other types of resource. I think the designers didn't grasp this fact. (I know they didn't when designing C# because they had to later go and create a reference-counting wrapper, SafeHandle)''
I don't see that as a problem. If you want a resource freed at some specific point in your program, you can write code that does so. GC is useful for when you don't care when the resource is released other than that you want it released after the last reference to it disappears. In that case, automatic memory management saves you the trouble of manually tracking where the last reference disappears, and allows the runtime to schedule release at any arbitrary point - which may buy you performance.
``So GC is a tool that is useful in some instances, but its not something that should be your only option, unfortunately all languages that provide GC-based memory don't tend to offer much in the way of alternatives, unlike C++ which not only allows you to have GC memory management for objects you choose to be collected, but also allows you to have shared objects with deterministic finalisation, and also allows you to have cheap stack-based objects too.''
Right. On the other hand, I'd argue that the correctness of your program depending on when a resource is released is very, very rare.
Think about it this way: garbage collection reclaims the resources used by objects after you're done with them (last reference is lost, so you can't possibly do anything with these objects anymore). The problems you raise are really cases where you _do_ still
``Do you mean "outperform" in latency, or just throughput?''
I meant throughput. But:
``Anything interactive needs a latency guarantee so that the user doesn't spend several seconds at a time staring at a frozen application stuck in its garbage collector.''
There are non-real-time and real-time automatic memory management systems just as there are non-real-time and real-time manual management systems.
As an aside, all the programs that annoy be by making me wait several seconds unpredictably use manual memory management. Not saying the pauses are _because_ they use manual management... but long pauses are neither a necessary consequence of, nor exclusive to garbage collected systems.
Finally:
``And manual resource-other-than-memory management means code needs to be run every time the last reference to a resource other than memory is lost.''
I am developing a programming language in which I will experiment with automatically managing non-memory resources, too. But this differs from automatic memory management in several ways. First of all, by contrast with some automatic memory management systems, it means you do have to perform work for unreachable objects (e.g. close files whose handles are no longer reachable). Secondly, the work you need to perform could take quite a lot of time compared to things that interact only with memory. Thirdly, these resources tend to be acquired and released on a much coarser scale (e.g. virtually every function call interacts with memory, but few deal with other resources). On the whole, I am not convinced automatic non-memory resource management is a good idea - but that's exactly why I'm doing the experiment: to find out.
``All that just goes away with garbage collection. Sure, if you're writing Doom 8 you probably need to squeeze every cycle out of your PC...''
and even then, you shouldn't assume that foregoing garbage collection is the way to go.
After all, manual memory management means code needs to be run every time the last reference to a chunk of allocated memory is lost. With automatic memory management, there is no such requirement. And indeed, some studies have found automatic memory management to actually outperform manual memory management.
Your post makes it sound as if all language designers are ever trying to do is replace C++. As a language designer, I can tell you first hand that this is not the case, at least not for all of us. There are different kinds of programming, and it is perfectly possible for multiple programming languages to coexist, each in their own niche, without there being a question of one replacing the other.
As you yourself say:
If you ARE a language inventor and reading my comment, answer this: can you write a cache/MMU interface or an interrupt handler in your language?
This kind of system programming is a niche that is filled by very few programming languages. Go probably isn't one of those. I don't think C++ is, either. Python? Not even close. Does this mean the designers of these languages need to go back to the drawing board, as you say? I beg to differ. Just because you can't access low-level hardware features in them doesn't mean they aren't perfectly fine application programming languages. In fact, I would go as far as to say that, just as there are many good application programming languages that aren't suitable for systems programming, a good systems programming language usually doesn't make a great application programming language.
And there you have it. As a language designer, I design languages for particular niches. I am not trying to replace C++ or any other language so much as designing what I think will make a better language for some particular purpose. If you still want to program in C++, that's great. And maybe it is the best choice for what you are doing with it. That doesn't mean it isn't a good idea for me to design a new language.
I had to read almost to the end of your post to figure out that DLC is "stuff you have to pay extra for", but thanks for pointing that out. If I can't even play the game that I got without getting the feeling that I'm missing out because I haven't bought extra goodies, that's a deal breaker for me.
Which allows collusion, continued high prices and lackluster service.''
yet isn't deregulated enough that I could start a competing company and compete on price and/or customer service... cause my bank account isn't big enough to afford the necessary licenses and implement the necessary infrastructure.
1) people who are aroused by pictures of (naked) children 2) people who molest children 3) people who record 2 4) people who distribute 3
3 and 4 also include people (law enforcement?) who record the crime for the sake of prosecuting the criminals, and the fact that a crime has been recorded can be an aid to catching the perpetrators.
In the Netherlands, there was a front page news item a few years ago about children uploading videos of their classmates being beaten up. The article I read quoted someone saying that the uploaders should be punished. My reaction was: That's backwards. It's not the videos that are the problem, it's the beating up. The videos help you identify and punish those who are beating people up. You should be grateful to the people who give you these videos, because they help you deal with the _real_ problem.
Now, I understand the difference between recording a video and sharing it for the purpose of getting a criminal punished on the one hand, and recording a video and selling it for profit or sharing it for entertainment, on the other hand. Still, I think recording, sharing, or selling videos of crimes isn't as bad as actually committing the crime. I'd much rather that people who get aroused by sexual abuse of children get their kicks from watching videos than from actually doing it in real life - noting, of course, that the ideal is that these people get treated so that they don't need those kicks anymore in the first place.
Because security through obscurity actually does work.
If all security vulnerabilities anywhere affecting the grid were publicly known, I am pretty sure we'd see outages more often. Forget malicious attackers, there are misguided souls who think this kind of thing is fun.
Of course, if these vulnerabilities were publicly known and being exploited, they would also be addressed.
As it is, my money is on "it's not secure, but the people who know the ways in aren't talking, and are ethical enough not to exploit the system themselves." That's how security works almost everywhere I've been to.
``We run into the classic security vs. usability argument. More security often makes it more difficult for them to do their job (at least for them) and is also much harder to implement, maintain and troubleshoot.''
I've never understood that argument. If your system isn't at least somewhat secure, you have to either constantly check on it, install patches, etc. or risk it being compromised. How is that usable?
To me, it's about the same as building a bridge out of whatever you have lying about in the vicinity. "Look! It works! We can walk on it, see? Take that, you bunch of whining engineering types with your expensive designs and complex calculations." Then, one day, the wind is a little stronger than the day the bridge was built, and it collapses.
We don't build bridges that way. We shouldn't build computer systems that way, either. If it's not strong enough to survive in the Real World, it's not a usable system.
``Apples and oranges. What do you propose? 10 sets of power lines running everywhere? There's a reason utilities are highly regulated monopolies: because it's simply impractical and absurd to have multiple power companies, multiple (landline) phone companies, multiple cable companies servicing the same areas.''
It's funny that you and I can see this, yet governments in the USA and western Europe (I don't know about other places) decided to turn exactly these kinds of former state monopolies into private companies. In some cases, they got it right; for the most part, they didn't.
Competition is good. Less regulation is good. But you have to be realistic. There is not going to be any competition if your infrastructure is provided by the same company that uses it, especially if that company is basically given the whole country as a customer base upon creation. You need to split off infrastructure from services, and impose regulation where you can't expect to get the desired outcome through competition.
``People have a special contempt for pedophiles because their victims are children and the motivation for the crime is mere sexual desire - the sort of urge most of us supress every day. It's an adult versus a child.''
That's fair and well, but that isn't the whole story. I don't think you'll find many people arguing that actual sexual abuse of children isn't a horrible crime that should be punished. The problem is that, under the guise of protecting the children (which we all agree is a Good Thing), many people are labeled as child molesters even though they don't actually sexually abuse children. This is a problem, because it ruins the lives of innocent people - the exact thing the system should prevent.
The debate, now, is about whether the collateral damage (innocent people getting their lives ruined thanks to "protect the children" laws) is a fair price to pay for the protection it affords to our children. Some people seem to take the position that any price is a fair price to pay to protect the children. This is an irrational position, but people find it hard to argue against, for fear of being seen as soft on child abuse. The truth is that there are some measures that are worth it, and some measures where the cure is worse than the disease.
Personally, I feel that only actual abuse (suitably defined) of actual children (suitably defined) should be a crime. Anything beyond that just makes it far too likely that people will be prosecuted even though they mean no harm to children.
``Of course I'd prefer them to release the whole source, but that can't really be expected of an engine that is still commercially available.''
Sometimes, I wonder why companies don't just license the engine as open source and sell the actual game. Let someone else do maintenance and porting on the engine while you focus on the artwork and the story line.
I really wonder how they think to go about cutting off someone's Internet access, too. I access the Internet through various networks, most of them not on my name. Most of these networks are used by multiple people. I am sure the situation is similar for many other people.
This raises two important questions:
1. How does one go about proving that a specific individual committed copyright infringement?
2. How does one cut off that person's Internet access, without cutting off various networks that are used by a lot of people beside that individual?
Of course, they might just disconnect every network that is found to be infringing... but then they can pretty much just shut down the entire Internet right away. I don't think that's really the intent of this directive, but even if it is, I guarantee you that it's not going to fly.
I can't speak for the rest of the world, but I can share my experience.
Back in 2001 or 2002 I bought a copy of Mandrake Linux. I had no Internet access (because I just moved) and I needed something for my new laptop, and I'd heard good things about Mandrake. I was sorely disappointed by it. It was heavy (taking a lot of disk space, memory and CPU time), and, apparently like every RPM-based distro at the time, had broken package management and bad quality packages (Mandrake managed to gain some fame for being unable to run Wine, for example).
I am sure Mandrake/Mandriva has improved since then, but it's been too late to keep me. I've discovered Debian, where time spent on system maintenance is minimal because its package management works, its packages work, they have a larger collection of packages than any other distro I've seen (meaning less time spent installing from source), and I feel safe upgrading my entire system in the expectation that everything will still work afterwards.
Even if Mandriva now provides all these things, that wouldn't compel me to switch, because I already have everything I care about.
I suspect it is the same way for others: either Mandriva doesn't offer compelling enough advantages over their current OS to make people want to switch, or people have had bad experiences in the past that make them want to avoid Mandriva. The fact that the project seems to have difficulty getting new releases out and the company behind it has been close to folding probably doesn't help, either.
(Just to be perfectly clear, none of this has anything to do with the technical quality of today's Mandriva. I am not saying it isn't an excellent product which deserves more attention. Just trying to explain why it isn't getting what it deserves.)
``The voter gets money for turning over his receipt and secret knowledge, whatever that may be, to the person who wants a verified vote for his candidate.''
The key is in the words I've emphasized. You can show your sponsor the codes you wrote down. Your sponsor can then go to the website and see that there indeed exists a ballot that matches these codes. You get paid, you're both happy. Only you have the secret knowledge that these codes mean you voted for Bob, not Alice as you told your sponsor.
``My point is simply that a root vulnerability given shell level access shouldn't be unexpected.''
Well, I think it should be. But it depends on your definition of "expect". If you mean "expect" as in "it's normal", I vehemently disagree. I think it's a disgrace. But if you mean "expect" as in "Linux is huge and complex, it's bound to have security holes you can drive a truck through", then, yes, I agree.
Slashdot Mirror
``The same was said for Java. It was sold as the ultimate final language built on 50 years of accumulated knowledge of language design and computer architecture.''
Seriously? If there is anything Java and the culture around it have done wrong, it is _not_ learning from what came before it.
Why, how did you know. I do live in the Netherlands. And I am pissed off that I have to spend effort on my mail servers to curb the spam. Can't tell if the women are wearing parkas, cause I can't see any from my basement.
Lucky for the world, it's not snowing.
``To say that one method of error handling is superior or correct or even required over the other is a little naive.''
I disagree. Forget to check a return code and nobody might ever find out, except that some people will end up with corrupted data. Forget to check an exception and you will (in most implementations, at least) get an error message telling you what went wrong and where in the program. Some systems (Lisp systems, in particular) will go as far as letting you fix the error and continue the program. I think exceptions _are_ fundamentally superior over error codes, and I am quite curious about why the designers decided not to put them in Go.
``But if the developer of a platform decides to make available only a non-real-time automatic memory management system, developers of interactive applications are screwed.''
You mean "if there is something in the platform that causes every app to suck, then you're screwed". Yes. But actual real-time guarantees are very rarely needed. Yes, there are extremely sucky garbage collectors. There are insanely sucky malloc implementations, too. This is not an issue of automatic vs. manual memory management.
``I believe this makes up a large part of tracing garbage collection's bad reputation: early versions of Java had no real-time collector.''
No, garbage collectors had a bad reputation long before Java existed. And they used to be bad. And bad ones are still being written. But they aren't necessarily bad, and some of them are actually really good. That's what I'm trying to get people to see.
``A lot of function calls that interact with memory allocate a piece of memory and then free it before the end. These are ideal candidates for reference counting.''
Define "ideal". Reference counting is quite expensive. It also breaks when there are cycles in your object graph. If you use reference counting for resource management, you are effectively making your program slower while still allowing resource leaks. I don't see the point in that.
If you want something like "close this file at the end of this block", you can use a construct like Common Lisp's with-open-file:
Or, of course, your favorite equivalent in your favorite programming language.
``Roughly the cancel out overall.
ie. Manual management works like this:
alloc, dealloc, alloc, dealloc, alloc dealloc.
GC works like this:
alloc, alloc, alloc, dealloc, dealloc, dealloc.''
Depends. Generally, garbage collection happens when the heap is fully. In the ideal case, that never happens, and you see everything being deallocated in one fell swoop when the program terminates. In pathological cases, you see GC being run for every memory allocation, spending a lot of time but freeing virtually no heap space.
``So overall there is no difference to speak of.''
Perhaps under "normal" circumstances, but there are cases where the difference is enormous.
``There are places where you can see a benefit to one over the other. In GC, you do not get the fragmentation of the heap like you do with manual management.''
Depends on the memory manager. There are GCs that defragment, but also those that don't. There are also malloc implementations that fragment a lot and malloc implementations that fragment very little.
``However, in GC you do have to walk the heap and compress it.''
Again, depends on the GC. There are compacting GCs and non-compacting GCs. There are those that scan live objects and those that scan garbage. There are generational and non-generational, real-time and non-real-time GCs ... there is a lot of work out there, and your generalizations really don't apply to all of it.
``GC can have better performance with shared objects, ie once allocated an object can be passed around by passing the 'pointer' to it.''
I don't think that is a property of GC. It's just something that automatic memory management makes easier, because, unlike manual memory management, you don't have to keep track of who is responsible for when the space is to be freed.
``GC does have an issue with memory leakage - see the notes that inexperience C# programmers have been complaining of when not (manually) removing event handlers from UI components. The GC never frees them if there's always a reference held to an in-use object, even if that object no longer gets used.''
You mean that garbage collectors only reclaim memory that is no longer referenced, not memory that is referenced but will not ever be used. You are right about that.
``GC also has issues with 'deterministic finalisation' - which is not a problem if the only resource used by your object is memory, but it is a huge problem for all other types of resource. I think the designers didn't grasp this fact. (I know they didn't when designing C# because they had to later go and create a reference-counting wrapper, SafeHandle)''
I don't see that as a problem. If you want a resource freed at some specific point in your program, you can write code that does so. GC is useful for when you don't care when the resource is released other than that you want it released after the last reference to it disappears. In that case, automatic memory management saves you the trouble of manually tracking where the last reference disappears, and allows the runtime to schedule release at any arbitrary point - which may buy you performance.
``So GC is a tool that is useful in some instances, but its not something that should be your only option, unfortunately all languages that provide GC-based memory don't tend to offer much in the way of alternatives, unlike C++ which not only allows you to have GC memory management for objects you choose to be collected, but also allows you to have shared objects with deterministic finalisation, and also allows you to have cheap stack-based objects too.''
Right. On the other hand, I'd argue that the correctness of your program depending on when a resource is released is very, very rare.
Think about it this way: garbage collection reclaims the resources used by objects after you're done with them (last reference is lost, so you can't possibly do anything with these objects anymore). The problems you raise are really cases where you _do_ still
``Do you mean "outperform" in latency, or just throughput?''
I meant throughput. But:
``Anything interactive needs a latency guarantee so that the user doesn't spend several seconds at a time staring at a frozen application stuck in its garbage collector.''
There are non-real-time and real-time automatic memory management systems just as there are non-real-time and real-time manual management systems.
As an aside, all the programs that annoy be by making me wait several seconds unpredictably use manual memory management. Not saying the pauses are _because_ they use manual management ... but long pauses are neither a necessary consequence of, nor exclusive to garbage collected systems.
Finally:
``And manual resource-other-than-memory management means code needs to be run every time the last reference to a resource other than memory is lost.''
I am developing a programming language in which I will experiment with automatically managing non-memory resources, too. But this differs from automatic memory management in several ways. First of all, by contrast with some automatic memory management systems, it means you do have to perform work for unreachable objects (e.g. close files whose handles are no longer reachable). Secondly, the work you need to perform could take quite a lot of time compared to things that interact only with memory. Thirdly, these resources tend to be acquired and released on a much coarser scale (e.g. virtually every function call interacts with memory, but few deal with other resources). On the whole, I am not convinced automatic non-memory resource management is a good idea - but that's exactly why I'm doing the experiment: to find out.
``All that just goes away with garbage collection. Sure, if you're writing Doom 8 you probably need to squeeze every cycle out of your PC...''
and even then, you shouldn't assume that foregoing garbage collection is the way to go.
After all, manual memory management means code needs to be run every time the last reference to a chunk of allocated memory is lost. With automatic memory management, there is no such requirement. And indeed, some studies have found automatic memory management to actually outperform manual memory management.
Your post makes it sound as if all language designers are ever trying to do is replace C++. As a language designer, I can tell you first hand that this is not the case, at least not for all of us. There are different kinds of programming, and it is perfectly possible for multiple programming languages to coexist, each in their own niche, without there being a question of one replacing the other.
As you yourself say:
This kind of system programming is a niche that is filled by very few programming languages. Go probably isn't one of those. I don't think C++ is, either. Python? Not even close. Does this mean the designers of these languages need to go back to the drawing board, as you say? I beg to differ. Just because you can't access low-level hardware features in them doesn't mean they aren't perfectly fine application programming languages. In fact, I would go as far as to say that, just as there are many good application programming languages that aren't suitable for systems programming, a good systems programming language usually doesn't make a great application programming language.
And there you have it. As a language designer, I design languages for particular niches. I am not trying to replace C++ or any other language so much as designing what I think will make a better language for some particular purpose. If you still want to program in C++, that's great. And maybe it is the best choice for what you are doing with it. That doesn't mean it isn't a good idea for me to design a new language.
I had to read almost to the end of your post to figure out that DLC is "stuff you have to pay extra for", but thanks for pointing that out. If I can't even play the game that I got without getting the feeling that I'm missing out because I haven't bought extra goodies, that's a deal breaker for me.
``This is a highly deregulated industry...
Which allows collusion, continued high prices and lackluster service.''
yet isn't deregulated enough that I could start a competing company and compete on price and/or customer service ... cause my bank account isn't big enough to afford the necessary licenses and implement the necessary infrastructure.
Well, do note that:
3 and 4 also include people (law enforcement?) who record the crime for the sake of prosecuting the criminals, and the fact that a crime has been recorded can be an aid to catching the perpetrators.
In the Netherlands, there was a front page news item a few years ago about children uploading videos of their classmates being beaten up. The article I read quoted someone saying that the uploaders should be punished. My reaction was: That's backwards. It's not the videos that are the problem, it's the beating up. The videos help you identify and punish those who are beating people up. You should be grateful to the people who give you these videos, because they help you deal with the _real_ problem.
Now, I understand the difference between recording a video and sharing it for the purpose of getting a criminal punished on the one hand, and recording a video and selling it for profit or sharing it for entertainment, on the other hand. Still, I think recording, sharing, or selling videos of crimes isn't as bad as actually committing the crime. I'd much rather that people who get aroused by sexual abuse of children get their kicks from watching videos than from actually doing it in real life - noting, of course, that the ideal is that these people get treated so that they don't need those kicks anymore in the first place.
Because security through obscurity actually does work.
If all security vulnerabilities anywhere affecting the grid were publicly known, I am pretty sure we'd see outages more often. Forget malicious attackers, there are misguided souls who think this kind of thing is fun.
Of course, if these vulnerabilities were publicly known and being exploited, they would also be addressed.
As it is, my money is on "it's not secure, but the people who know the ways in aren't talking, and are ethical enough not to exploit the system themselves." That's how security works almost everywhere I've been to.
``We run into the classic security vs. usability argument. More security often makes it more difficult for them to do their job (at least for them) and is also much harder to implement, maintain and troubleshoot.''
I've never understood that argument. If your system isn't at least somewhat secure, you have to either constantly check on it, install patches, etc. or risk it being compromised. How is that usable?
To me, it's about the same as building a bridge out of whatever you have lying about in the vicinity. "Look! It works! We can walk on it, see? Take that, you bunch of whining engineering types with your expensive designs and complex calculations." Then, one day, the wind is a little stronger than the day the bridge was built, and it collapses.
We don't build bridges that way. We shouldn't build computer systems that way, either. If it's not strong enough to survive in the Real World, it's not a usable system.
``Apples and oranges. What do you propose? 10 sets of power lines running everywhere? There's a reason utilities are highly regulated monopolies: because it's simply impractical and absurd to have multiple power companies, multiple (landline) phone companies, multiple cable companies servicing the same areas.''
It's funny that you and I can see this, yet governments in the USA and western Europe (I don't know about other places) decided to turn exactly these kinds of former state monopolies into private companies. In some cases, they got it right; for the most part, they didn't.
Competition is good. Less regulation is good. But you have to be realistic. There is not going to be any competition if your infrastructure is provided by the same company that uses it, especially if that company is basically given the whole country as a customer base upon creation. You need to split off infrastructure from services, and impose regulation where you can't expect to get the desired outcome through competition.
``People have a special contempt for pedophiles because their victims are children and the motivation for the crime is mere sexual desire - the sort of urge most of us supress every day. It's an adult versus a child.''
That's fair and well, but that isn't the whole story. I don't think you'll find many people arguing that actual sexual abuse of children isn't a horrible crime that should be punished. The problem is that, under the guise of protecting the children (which we all agree is a Good Thing), many people are labeled as child molesters even though they don't actually sexually abuse children. This is a problem, because it ruins the lives of innocent people - the exact thing the system should prevent.
The debate, now, is about whether the collateral damage (innocent people getting their lives ruined thanks to "protect the children" laws) is a fair price to pay for the protection it affords to our children. Some people seem to take the position that any price is a fair price to pay to protect the children. This is an irrational position, but people find it hard to argue against, for fear of being seen as soft on child abuse. The truth is that there are some measures that are worth it, and some measures where the cure is worse than the disease.
Personally, I feel that only actual abuse (suitably defined) of actual children (suitably defined) should be a crime. Anything beyond that just makes it far too likely that people will be prosecuted even though they mean no harm to children.
``I can't wait until the major video sites default to HTML5 and we can finally say goodbye to Flash.''
and then we will finally be where we could have been, had people just used HTML4's object element.
``They just want to be able to power up, do what they want and log out.''
The question is why there isn't a company making major money providing computers that work that way.
So you are saying that electron-proton collisions probably do occur, but do not lead to the observed gamma radiation TFA mentions?
Is the radiation you observe when a positron is annihilated different from what you would see if, say, an electron collided with a proton?
``Of course I'd prefer them to release the whole source, but that can't really be expected of an engine that is still commercially available.''
Sometimes, I wonder why companies don't just license the engine as open source and sell the actual game. Let someone else do maintenance and porting on the engine while you focus on the artwork and the story line.
``Are they wanting the next one to work for 50?''
Sure, why not?
I really wonder how they think to go about cutting off someone's Internet access, too. I access the Internet through various networks, most of them not on my name. Most of these networks are used by multiple people. I am sure the situation is similar for many other people.
This raises two important questions:
1. How does one go about proving that a specific individual committed copyright infringement?
2. How does one cut off that person's Internet access, without cutting off various networks that are used by a lot of people beside that individual?
Of course, they might just disconnect every network that is found to be infringing ... but then they can pretty much just shut down the entire Internet right away. I don't think that's really the intent of this directive, but even if it is, I guarantee you that it's not going to fly.
I can't speak for the rest of the world, but I can share my experience.
Back in 2001 or 2002 I bought a copy of Mandrake Linux. I had no Internet access (because I just moved) and I needed something for my new laptop, and I'd heard good things about Mandrake. I was sorely disappointed by it. It was heavy (taking a lot of disk space, memory and CPU time), and, apparently like every RPM-based distro at the time, had broken package management and bad quality packages (Mandrake managed to gain some fame for being unable to run Wine, for example).
I am sure Mandrake/Mandriva has improved since then, but it's been too late to keep me. I've discovered Debian, where time spent on system maintenance is minimal because its package management works, its packages work, they have a larger collection of packages than any other distro I've seen (meaning less time spent installing from source), and I feel safe upgrading my entire system in the expectation that everything will still work afterwards.
Even if Mandriva now provides all these things, that wouldn't compel me to switch, because I already have everything I care about.
I suspect it is the same way for others: either Mandriva doesn't offer compelling enough advantages over their current OS to make people want to switch, or people have had bad experiences in the past that make them want to avoid Mandriva. The fact that the project seems to have difficulty getting new releases out and the company behind it has been close to folding probably doesn't help, either.
(Just to be perfectly clear, none of this has anything to do with the technical quality of today's Mandriva. I am not saying it isn't an excellent product which deserves more attention. Just trying to explain why it isn't getting what it deserves.)
It's right in your post:
``The voter gets money for turning over his receipt and secret knowledge, whatever that may be, to the person who wants a verified vote for his candidate.''
The key is in the words I've emphasized. You can show your sponsor the codes you wrote down. Your sponsor can then go to the website and see that there indeed exists a ballot that matches these codes. You get paid, you're both happy. Only you have the secret knowledge that these codes mean you voted for Bob, not Alice as you told your sponsor.
``My point is simply that a root vulnerability given shell level access shouldn't be unexpected.''
Well, I think it should be. But it depends on your definition of "expect". If you mean "expect" as in "it's normal", I vehemently disagree. I think it's a disgrace. But if you mean "expect" as in "Linux is huge and complex, it's bound to have security holes you can drive a truck through", then, yes, I agree.