I actually agree that many of the behaviors he displayed at the trial are symptomatic of how he treated the world in general, and that this adversely affected the design of the filesystem.
But, I don't think that ReiserFS3 has been a bad filesystem for quite some time now. And I think the one person responsible for ReiserFS who also was the hardest to work with is now gone. Perhaps renaming it and then getting version 4 into the kernel might be a possibility.
No, if I recall correctly I can remember this kind of repugnant calculation being applied previously by other car companies for other defects. It's cheaper for them to apply this calculation and risk getting caught than the occasional blow-up and bad press they get for it.
The minimum age rule applies specifically to women's gymnastics and it was implemented largely because of injuries. Basically they decided that countries going for younger and younger girls in gymnastics competitions and having them break and pull things and permanently screw up their joints was a bad thing, so they implemented a minimum age rule.
I found the people in "The Spirits Within" to be distracting. I kept looking at them trying to figure out why they didn't look like people. I actually largely enjoyed the movie, but I suspect that my ability to deal with that kind of irritation is a lot higher than most people's.
Templates are not a natural way to express metaprograms. Why not give C++ programmers the tools to write nice, clean, object-oriented, imperative metaprograms instead of the kludgy functional metaprograms they are forced to scrape by with now?
It is my intuition that you must define metaprograms in a pure functional language if the resulting programs are going to be statically compiled into machine code with little or no runtime support. This is especially true if the language supports multiple disjoint compilation units that produce object code that requires no compiler support to link together into an executable program.
Re:Boost epitomizes everything that is wrong with
on
Boost 1.36 Released
·
· Score: 1
I agree with you that somewhere inside C++ is a small, elegant language screaming to get out. So, please write it already!:-) Until then, I'll use Boost.
And no, I won't use your language if it requires extensive runtime support such as garbage collection, if it isn't statically compiled to machine code, or if it doesn't allow me to do the low-level fiddling I can do with C or C++.
If I considered Java to be a worthwhile programming language at all, that might be an option for me. As it is, I largely consider it the language of large flailing IT shops inside organizations that largely have no clue.
did you just pick a buzzword without knowing what it means?
No. I picked ICMP without thinking it through carefully enough. The idea of hiding data in ICMP echo packets amused me, especially since such packets would generally be dismissed as innocuous.
At least one.:-) I found a flaw in the Python interpreter once that allowed a Python program to cause the interpreter to crash. I actually found it because the documentation for a particular function seemed a little weird since it implied a strange corner case. I tested the corner case and the interpreter promptly crashed. I was able to find out why using the source code, but I will admit that I did not find the security flaw by auditing the source code.
I believe there have been others I've noticed here and there, but I can't remember the specific details of any others.:-( I happen to have a fairly good eye for noticing flaws in code.
The first point is the well-known article floating around the Internet about how to create a virtually undetectable self-replicating trojan. The article is very interesting: I recommend you read it.
I have, and it's rather distressing.:-/ And you're right that it is a thing to worry about. One thing about that trojan is that it requires a certain amount of stability in the compiler to work or it requires the compiler to be re-trojaned. I think that every major piece of gcc has been re-written in various ways that would make it very hard for a self-replicating trojan to keep itself embedded in the compiler. An interesting experiment would be to use a very old binary of gcc to compile one of the newer versions and see how they compare in their output.
But there is this attitude that having access to the source means that trust doesn't even enter into the equation, that somehow you can be objectively assured that the code does exactly what you want it to and nothing else. In reality, you have almost the exact same level of assurance, namely none at all.
I disagree. The corporate wall of secrecy surrounding their software makes it much easier for a corporation to pull off a long-term attempt to basically put trojans in their software. Such trojans don't even have to remain hidden. There are well known trojans in several well known pieces of software for things like DRM or user tracking that nobody ever bothers to remove because those pieces of software are not Open Source.
I don't go through the source code of most software myself. I have, as it happens, gone through some of the source code for OpenSSL, enough to know that it is a total piece of garbage and if any other library existed that did what it does (like, say, gnutls) I'd rather use it.:-)
But that's not relevant. What is relevant is that other people can. And someone likely has. Perhaps that person is one of the contributors. Or maybe it's someone who wanted to go in and see how something worked, or any number of things. The point is that the accountability is possible, which is a lot more than you can say for closed source commercial software.
Even though I have not personally fully audited OpenSSL, I do pay attention to the communities in which serious problems in OpenSSL would be reported in. For this reason, I feel fairly confident that there are no back doors written into OpenSSL.
No, I said AFAIK. I really don't know if they are or not. It certainly wouldn't surprise me if they were doing it. They easily could because the source isn't available for us to look at and see for ourselves.
The real world however revolves around rational business practices.
And so it does. I disagree with you however on what constitutes a rational business practice. Keeping the internals of your product secret is rational for software ceators perhaps, but I think that nobody who uses software should be willing to put up with it. It also makes sense for business owners to demand all the money in your pocket when you walk in the door, but I don't think any rational person would be willing to put up with that either.
Confusing the self interest of software creators with the self interest of everybody as a whole is an interesting and pitiable delusion.
I consider that really sad. For the most part, since about 2004 or 2005 compilers have been perfectly fine for Boost. If most shops are still wondering about this, most shops are using dreadfully old development tools.
That being said, I haven't done any really serious C++ development work since early 2006. I now consider C++ to be the language to go to when Python is just too slow for something. And for that there's Boost.Python.
Though, I'm starting to get interested in intensive parallelization and Python is seriously lagging in good multithreading support.
Any software where they won't show me the source code and/or let me compile it myself with my own tools and have it work has something to hide. In Flash's case, I'll grant that what it's likely hiding is umpteen million security vulnerabilities,. But it could just as easily be hiding code to spy on me or censor things because the software decides I don't have a copyright license or I'm living in China or something.
And I don't think, given the general history of software, that I'm being particularly paranoid here.
I've never been able to make any Flash site at all work with gnash (I'm currently using gnash 0.8.2). Though I'm using 64-bit Linux, so maybe that's the problem. Though I thought gnash was supposed to be written well enough that it wouldn't matter.
I don't want to install Adobe's player. The source isn't available for public scrutiny and it's a major piece of infrastructure. AFAIK it's sending encrypted ICMP packets to Adobe telling them every piece of Flash I download or some such stupidly evil thing.
I liked Independence War myself. They had a realistic space flight sim and showed how it could actually be playable. The tactics you used there were considerably different than the tactics you would use in any sort of flight-sim like space game.
SSL isn't meant just for encrypting pages, it's meant for verifying identity also.
We have another application in which this is also the case. It's called ssh. Why can't Firefox act more like ssh? ssh is perfectly secure and good at verifying identity without buying into the root CA scam. Why wouldn't Firefox be just as good?
I realize there are some differences in the intended audience's of the two applications and other details of how and when they're used. But still, ssh is pretty secure against MITM attacks without relying on some bogus and stupid 'trusted CA' concept.
What I would like to see is an ssh-like mechanism where Firefox remembers the key previously associated with a website and complains if you appear to be accessing the same website but it's presenting a different key than it did before. Perhaps the existing mechanism of trusted roots could be kept as well, though IMHO, I would like to see that replaced by my scheme as well with an explanation of who the root is and why you should trust them instead.
I do not like Firefox randomly making a decision that certain root CAs are trustworthy and requiring those CAs to give them money for the privilege of being considered trustworthy.
On reading the article, it doesn't sound like the author is totally clueless. Though I do think self-signed certificates deserve a warning of some kind. I really do think that the whole trusted root thing is a bit of a scam and users should be allowed to make choices about who they consider a trusted root.
Clearly people (including me, even though I didn't comment) were being somewhat alarmist. I don't apologize for being alarmist about something like that. It's very typical of the kind of thing Microsoft has had a tendency to do in the past.
Though, in retrospect Microsoft largely no longer has to be so sneaky about stuff like this. The easiest way for them to play this game now is to convince a majority of motherboard manufacturers to not give the keys to their trusted computing hardware to the users of the motherboard.
Especially given many people's tendency nowadays to suspend all judgment when anybody even vaguely plausibly mentions 'security'.
Maybe he is, and maybe he isn't. He certainly could be. He just has to be classed as an 'enemy combatant' and there he goes. Nobody gets to question the 'enemy combatant' classification, it doesn't even have to be justified.
It would sure as heck be a lot easier than actually trying the case, and then they'd get to beat him, waterboard him and otherwise punish him in nasty ways.
So, while that's a possibility, I think other countries have a responsibility to their own citizens to not allow them to be extradited to the United States.
Slashdot Mirror
I would like to see some studies on whether or not 'dark energy' was clumpy like 'dark matter' seems to be.
I actually agree that many of the behaviors he displayed at the trial are symptomatic of how he treated the world in general, and that this adversely affected the design of the filesystem.
But, I don't think that ReiserFS3 has been a bad filesystem for quite some time now. And I think the one person responsible for ReiserFS who also was the hardest to work with is now gone. Perhaps renaming it and then getting version 4 into the kernel might be a possibility.
No, if I recall correctly I can remember this kind of repugnant calculation being applied previously by other car companies for other defects. It's cheaper for them to apply this calculation and risk getting caught than the occasional blow-up and bad press they get for it.
The minimum age rule applies specifically to women's gymnastics and it was implemented largely because of injuries. Basically they decided that countries going for younger and younger girls in gymnastics competitions and having them break and pull things and permanently screw up their joints was a bad thing, so they implemented a minimum age rule.
I found the people in "The Spirits Within" to be distracting. I kept looking at them trying to figure out why they didn't look like people. I actually largely enjoyed the movie, but I suspect that my ability to deal with that kind of irritation is a lot higher than most people's.
Templates are not a natural way to express metaprograms. Why not give C++ programmers the tools to write nice, clean, object-oriented, imperative metaprograms instead of the kludgy functional metaprograms they are forced to scrape by with now?
It is my intuition that you must define metaprograms in a pure functional language if the resulting programs are going to be statically compiled into machine code with little or no runtime support. This is especially true if the language supports multiple disjoint compilation units that produce object code that requires no compiler support to link together into an executable program.
I agree with you that somewhere inside C++ is a small, elegant language screaming to get out. So, please write it already! :-) Until then, I'll use Boost.
And no, I won't use your language if it requires extensive runtime support such as garbage collection, if it isn't statically compiled to machine code, or if it doesn't allow me to do the low-level fiddling I can do with C or C++.
If I considered Java to be a worthwhile programming language at all, that might be an option for me. As it is, I largely consider it the language of large flailing IT shops inside organizations that largely have no clue.
Except that I don't think even the magic of stackless will give me the true multi-CPU concurrency that I want. :-(
did you just pick a buzzword without knowing what it means?
No. I picked ICMP without thinking it through carefully enough. The idea of hiding data in ICMP echo packets amused me, especially since such packets would generally be dismissed as innocuous.
At least one. :-) I found a flaw in the Python interpreter once that allowed a Python program to cause the interpreter to crash. I actually found it because the documentation for a particular function seemed a little weird since it implied a strange corner case. I tested the corner case and the interpreter promptly crashed. I was able to find out why using the source code, but I will admit that I did not find the security flaw by auditing the source code.
I believe there have been others I've noticed here and there, but I can't remember the specific details of any others. :-( I happen to have a fairly good eye for noticing flaws in code.
The first point is the well-known article floating around the Internet about how to create a virtually undetectable self-replicating trojan. The article is very interesting: I recommend you read it.
I have, and it's rather distressing. :-/ And you're right that it is a thing to worry about. One thing about that trojan is that it requires a certain amount of stability in the compiler to work or it requires the compiler to be re-trojaned. I think that every major piece of gcc has been re-written in various ways that would make it very hard for a self-replicating trojan to keep itself embedded in the compiler. An interesting experiment would be to use a very old binary of gcc to compile one of the newer versions and see how they compare in their output.
But there is this attitude that having access to the source means that trust doesn't even enter into the equation, that somehow you can be objectively assured that the code does exactly what you want it to and nothing else. In reality, you have almost the exact same level of assurance, namely none at all.
I disagree. The corporate wall of secrecy surrounding their software makes it much easier for a corporation to pull off a long-term attempt to basically put trojans in their software. Such trojans don't even have to remain hidden. There are well known trojans in several well known pieces of software for things like DRM or user tracking that nobody ever bothers to remove because those pieces of software are not Open Source.
I don't go through the source code of most software myself. I have, as it happens, gone through some of the source code for OpenSSL, enough to know that it is a total piece of garbage and if any other library existed that did what it does (like, say, gnutls) I'd rather use it. :-)
But that's not relevant. What is relevant is that other people can. And someone likely has. Perhaps that person is one of the contributors. Or maybe it's someone who wanted to go in and see how something worked, or any number of things. The point is that the accountability is possible, which is a lot more than you can say for closed source commercial software.
Even though I have not personally fully audited OpenSSL, I do pay attention to the communities in which serious problems in OpenSSL would be reported in. For this reason, I feel fairly confident that there are no back doors written into OpenSSL.
No, I said AFAIK. I really don't know if they are or not. It certainly wouldn't surprise me if they were doing it. They easily could because the source isn't available for us to look at and see for ourselves.
And so it does. I disagree with you however on what constitutes a rational business practice. Keeping the internals of your product secret is rational for software ceators perhaps, but I think that nobody who uses software should be willing to put up with it. It also makes sense for business owners to demand all the money in your pocket when you walk in the door, but I don't think any rational person would be willing to put up with that either.
Confusing the self interest of software creators with the self interest of everybody as a whole is an interesting and pitiable delusion.
I consider that really sad. For the most part, since about 2004 or 2005 compilers have been perfectly fine for Boost. If most shops are still wondering about this, most shops are using dreadfully old development tools.
That being said, I haven't done any really serious C++ development work since early 2006. I now consider C++ to be the language to go to when Python is just too slow for something. And for that there's Boost.Python.
Though, I'm starting to get interested in intensive parallelization and Python is seriously lagging in good multithreading support.
Any software where they won't show me the source code and/or let me compile it myself with my own tools and have it work has something to hide. In Flash's case, I'll grant that what it's likely hiding is umpteen million security vulnerabilities,. But it could just as easily be hiding code to spy on me or censor things because the software decides I don't have a copyright license or I'm living in China or something.
And I don't think, given the general history of software, that I'm being particularly paranoid here.
I've never been able to make any Flash site at all work with gnash (I'm currently using gnash 0.8.2). Though I'm using 64-bit Linux, so maybe that's the problem. Though I thought gnash was supposed to be written well enough that it wouldn't matter.
I don't want to install Adobe's player. The source isn't available for public scrutiny and it's a major piece of infrastructure. AFAIK it's sending encrypted ICMP packets to Adobe telling them every piece of Flash I download or some such stupidly evil thing.
I liked Independence War myself. They had a realistic space flight sim and showed how it could actually be playable. The tactics you used there were considerably different than the tactics you would use in any sort of flight-sim like space game.
SSL isn't meant just for encrypting pages, it's meant for verifying identity also.
We have another application in which this is also the case. It's called ssh. Why can't Firefox act more like ssh? ssh is perfectly secure and good at verifying identity without buying into the root CA scam. Why wouldn't Firefox be just as good?
I realize there are some differences in the intended audience's of the two applications and other details of how and when they're used. But still, ssh is pretty secure against MITM attacks without relying on some bogus and stupid 'trusted CA' concept.
Yes, and people can remove Media Player and IE from their computers too.
What I would like to see is an ssh-like mechanism where Firefox remembers the key previously associated with a website and complains if you appear to be accessing the same website but it's presenting a different key than it did before. Perhaps the existing mechanism of trusted roots could be kept as well, though IMHO, I would like to see that replaced by my scheme as well with an explanation of who the root is and why you should trust them instead.
I do not like Firefox randomly making a decision that certain root CAs are trustworthy and requiring those CAs to give them money for the privilege of being considered trustworthy.
On reading the article, it doesn't sound like the author is totally clueless. Though I do think self-signed certificates deserve a warning of some kind. I really do think that the whole trusted root thing is a bit of a scam and users should be allowed to make choices about who they consider a trusted root.
Clearly people (including me, even though I didn't comment) were being somewhat alarmist. I don't apologize for being alarmist about something like that. It's very typical of the kind of thing Microsoft has had a tendency to do in the past.
Though, in retrospect Microsoft largely no longer has to be so sneaky about stuff like this. The easiest way for them to play this game now is to convince a majority of motherboard manufacturers to not give the keys to their trusted computing hardware to the users of the motherboard.
Especially given many people's tendency nowadays to suspend all judgment when anybody even vaguely plausibly mentions 'security'.
Maybe he is, and maybe he isn't. He certainly could be. He just has to be classed as an 'enemy combatant' and there he goes. Nobody gets to question the 'enemy combatant' classification, it doesn't even have to be justified.
It would sure as heck be a lot easier than actually trying the case, and then they'd get to beat him, waterboard him and otherwise punish him in nasty ways.
So, while that's a possibility, I think other countries have a responsibility to their own citizens to not allow them to be extradited to the United States.
That's a cop-out and you know it.