With the wonderful template metaprogramming that you mentioned, you can't do as much as easily and you are at the mercy of the implementation (e.g. how many levels of expansion).
There are a theoretical infinite number of levels of expansion, limited only by available memory for the compiler. So what limitations does it have?
I said it has more, and listed some of them. You've yet to explain how to somehow discount all those paradigms back down to one.
You're right that it does, but most coders only limit themselves to imperative (which I generally don't count because almost all languages support it) and functional.
The fact that I made a syntax error in an array declaration doens't change the fact that LISP supports more than one paradigm -- and more paradigms than C++.
More? So which extra ones does it support?
The fact that you said "destructor" when you meant "constructor" is equally atrocious - by your own logic, I could argue you don't know C++.
I corrected myself right after I wrote it. I was actually thinking "destructor" when I wrote it, but accidentally wrote constructor instead. Nonetheless, I made no syntax errors (as I wrote no code), especially not a newbie one.
Holy shit. An insane amount of those comments were moderated 0 or -1, "offtopic." There's no way that many random Slashdot moderators would waste their mod points moderating down a large thread of trolls. You only get like 5 moderator points at a time, so that means either a) a lot of random Slashdot moderators were just being overzealous that day for no good reason or more likely, b) the small group of official moderators (like CmdrTaco), who have an infinite number of mod points, moderated them down.
I'm guessing B, because I have never, EVER seen a single thread that literally had dozens of comments from different users moderated to 'offtopic.'
Actually, I was just trying to make an example. I have plenty of experience with C++.
Which is why you don't know the syntax for declaring a character array?
Well, in this case, the race condition was between the GC and the other thread.
It wasn't, since they wouldn't using a garbage collector in this case.
You could have race conditions, but not between the GC and a thread. In this case, it would have been a cureall.
I don't think you understand what cureall means. If something only applies to a very select and limited case, it's very much the opposite of a cureall. I'm guessing he was inexperienced with multi-threading, because I'm no expert in it, yet even I can recognize that information you want to be globally accessible should be in a global variable of some kind.
Well, that's why a C++ programmer gets less work done; he has to do tasks that a LISP programmer doesn't have to deal with
Well if you repeat that enough times, it must make it true! Or not. LISP will end up taking far more time because of its limited language capabilities. The rest of the world prefers multi-paradigm langauges, and for good reason.
In this case, the performance penalty of a LISP, over C++ would be negligible -- so overall, the C++ programmer loses.
No, not really.
As Ron makes clear, there were multiple programmers.
Yes, but he apparently was the one responsible for finding this particular problem. His rant reads more like he's bitter than anything else, probably because *he* is the one who introduced the error in the first. Also, sour grapes.
So using C++ imposes more costs: the programmers have to talk to make sure they don't fuck themselves with little implementation details
Are you kidding me? The programmers always have to talk to eachother on ANY project, it doesn't matter what the language is. First you suggest that programmers not be cautious, then you suggest that they not talk to eachother. And this "little implementation detail" is something that should have been obvious from the beginning. "Let's use local stack storage to share details between threads" is just plain dumb.
What's the headache? Also, why do you say "less powerful"? I'm really not getting your point here.
Have you actually seen how enormously complex and large the C++ language is? Given that you can't even manage a simple declaration, I doubt it.
LISP is a more powerful language, because it has closures, a GC, arbitrarily complicated macros, runtime compilation, etc.
C++ supports all of those except runtime compilation (which is rather problematic anyway when dealing with a COMPILED language) and can do it better too. The templating system allows you to do all kinds of things, that's the beauty of C++, it's very extendable.
Since the 1970's, Common Lisp has been faster than Fortran for problems where performance matters.
And fortran was superseded by C in perforamance many years ago. Beating Fortran ceased being an accomplishment long ago. Incidentally, that's wrong. Back then Fortran had the best support for mathematical computations.
Furthermore, if you will argue that "C" or C++ is faster than LISP, because you can do machine-level things, then I'd ask why you just don't use assembly, to get the most "power". Whatver "C" has, assembly has more of it, right?
No, because the compilers are far superior. The best high level compilers you can get are for C/C++. No amount of equivalent work has gone into the sheer man-hours into their development to make the best optimizing compilers.
So I made a basic syntax error, and now I don't know anything about C++? That's absurd. And there's no need to be so insulting.
Yes, it does. It wasn't just a typo, that indicates you have little to no experience with C++. That's not the kind of mistake anyone with significant experience would make.
My point was that if you wanted a simple program to do what they were doing, C++ would allow you to build a mostly working, but under some conditions horribly broken program very easily, and a language with a GC wouldn't.
First of all, a GC isn't not a magic cureall. Second of all, there is GC support for C++. Third of all, this is programmer induced race condition, it's a rare kind of error. GC is generally only helpful in avoiding memory leaks, it is rarely ever helpful in preventing such kinds of rare errors as this which actually break the program. So really, all GC ends up doing is, at best, make it so you don't have to restart your program (assuming they are leaking significantly) for like 99.9% of implementations.
Your points about using wrappers or destructor Kung Fu are in keeping with the "always do things very carefully" attitude of C++: if someone makes a mistake, it is his fault.
Because programmers shouldn't be careful, right? And a person who makes a mistake isn't at fault for the mistake even though THEY made it?
Someone like Ron, knowing that there's a chance of making a mistake, would prefer to use tools that remove the risk of him making a mistake from the get-go.
Using LISP doesn't remove the risk of making mistakes. It just forces you into a less powerful language and ends up giving you a headache, all for the sake of avoiding some trivial programming error. Being google, I'd imagine performance issues were of concern too.
It's actually very difficult to imagine businesses with an enormous need to transmit extra-securely between two fixed points.
Hah. You mean like a BANK? Any financial institution? Any large company with a VPN between two offices? All communications between two military bases? There are lots of ordinary applications by businesses whose communications need to be confidential, the idea that it's limited just to nuclear missle launch sites is ridiculous.
Well, the actual arguement was against Kish's ludicrous claim that his technique was "absolutely secure", which you already surrendered by changing the subject to "practical" security.
Bullshit, you were suggesting it wasn't secure at all, that a simple tap could compromise it, that's a far cry from simply saying that it's not "absolutely secure." You thought you had found a way to compromise the system, but you didn't. Now you're just backpedaling and arguing semantics.
In any case, "absolutely secure" is obviously referring to the security of the transmission medium itself, not the possibility of someone breaking in and copying the hardware on each end. It's very clear that he meant "absolutely secure" in the same sense that a one time pad is "absolutely secure"--that as long as you don't break into the endpoints to steal the secret key, it's secure. The transmission medium is "absolutely secure," but obviously he's not making allowances for physical security to protect the endpoints from break-ins/inside jobs/whatever as those are outside the scope of cryptosystems.
For anything outside of nuclear-missile control, Kish and QC lose the cost argument: carrying more OTPs to the remote site is incomprably more affordable than building and maintaining a dedicated cable.
Only if you operate under the assumption of small amounts of data transfer.
For nuclear-missile control, Kish and QC lose the robustness argument: if that dedicated cable is sabotaged, there is no way the system can fall back to packet-switched or RF transmission.
That's a vulnerability of ANY system. They can cut the cable, jam radio communications and so forth. No system is immune. Just because his system is vulnerable to hte same thing that all wire-based mediums are doesn't mean it's not robust. Would you call 100% of cryptography on the internet non-robust? Because that's what you're suggesting, since you can't get on the internet without directly or indirectly connecting to some line that can get cut. In any case, for nuclear missle control, they'd obviously have multiple redundant systems.
Using consumer-grade optical discs, I can lift in one hand enough random numbers to transmit data for 10 years (assuming new keys are loaded at 100hz, which is faster than proposed QC methods would provide them).
What the hell are you talking about? You just made an insane generalization without knowing how much data would need to be transmitted by the numerous potential users. A one time pad on one CD is enough to transfer exactly one CDs worth of data. Guess what? I personally go through a CDs worth of data over my personal internet connection in just several days of internet usage, imagine what it would be like for a business.
Why the hell would you limit usage to 100hz? The limit for this method is no where near that low. You deliberately brought up existing QC methods (which are irrelvent to the resistor method) because you know that you've lost this argument.
Conversly, QC requires continuous, impractical immobility of both sender and reciever. You can't move.
That's not an issue if you're transmitting from one building (which is static) to another. Gee, certainly no one who is stuck in one place has a use for cryptography!
I saw your code in your other and it has a very basic "newbie syntax error" in declaring a char array. This tells me you don't even know basic C/C++ and aren't really qualified in the slightest to comment on it. Whoever taught you C++, you should get a refund from.
This is why it's called a race condition, because the two threads were racing each other, with the ad-count-writer trying to finish before the main thread freed up the memory it was using to get those counts.
That's a programmer induced race condition though, it has nothing to do with the system. Threads are supposed to deallocate data their own data when they're finished, that's a known and expected behavior. Local thread data storage is just that--local to the thread, it's not meant to be shared.
If you want to share data between threads, you use specific mechanisms for that, which are available on practically all operating systems in some form. Even if it's not explicitly available, you can just easily allocate data on the heap and share that, it's not really hard at all. This is an out and out programmer error, nothing to do with a problem with C/C++. The problem could have been avoided with a single, simple heap allocation.
On top of that, this kind of bug is actually impossible to introduce except in a language with manual memory management like C++. In a language with automatic memory management like Java or Lisp the system automatically notices that the memory is still in use and prevent it from being reused until all threads were actually done with it.
The distinction between "automatic" and "manual" memory management is arbitrary. With java you have to manually allocate memory for data and the same for any other language, though the semantics might vary. The issue memory deallocation. First of all, C++ provides many automated means for automatic memory deallocation, namely in the form of constructors, especially with wrapper classes designed to deallocate data. Second of all, there is garbage collection available for C++, it's just not typiclly used.
By the time this bug was found and fixed (by Ed) I was a mental wreck, and well on my way to becoming a physical wreck as well. My relationship with my wife was beginning to strain. My manager and I were barely on speaking terms.
If an error like that turned this guy into such a mental wreck, then quite frankly, he's a moron.
Of course. And we call that technique One Time Pads. It was technically detailed more than 50 years ago, and was informally used much earlier.
No, that's not a one time pad, a one time pad requires regular manual, impractical exchanges of data. You need to do it continuously to sustain the secure channel. With this device, you would only need to do the exchange ONCE and then you can send information forever.
OTP does all that, and doesn't require an actual copper wire to be installed between the endpoints (which adds tremendous cost and DOS vulnerability to the system)
OTP wouldn't work with one impractical exchange. You need to do it repeatedly and exchange large amounts of data each time.
This "invention" (like QC) is almost as good as "Proposal for Running OTP Wearing a Daffy Hat"- at least the hat costs less than 60 km of cable.
I find it interesting that you're criticizing quantum cryptography too, this pretty much discredits you on the subject matter. QC isn't a OTP, it's superior to it.
You're trying to carry mathematical concepts into the physical world, it doesn't work like that.
How did you get that list? It had to be communicated somehow. If the channel by which the list was transmitted is secure, then the whole random-resistor scheme is redundant. If it's insecure, then it is vulnerable to man-in-the-middle tampering, and so is the whole scheme.
I already covered this in the comment you responded to. You can use it to securely exchange information in a way that's no more vulnerable than any other exchange of secret keys. Of course, these methods of manual key exchange are impractical to perform regularly, which is why you wouldn't substitute them for this technology.
You see, this is why you shouldn't try to analyze something without knowing about cryptography. It amuses me greatly when amateurs pretend they have expertise in an area where they obviously don't have it.
Right. Given that your criticisms apply equally to quantum cryptography and even one time pads, which you probably think are secure, I'm *sure* you know more about cryptography than me. If you had actually bothered to think this through, you'd realize that. Of course having knowledge of the hardware gives you the ability to compromise the system, but the same applies to any system--if you could manage to get physical access to the hardware, you're screwed.
Then you proceeded to disregard the exchange medium as being redundant, on the basis that it should replace the other medium. But of course, if you exercised some critical thought, you'd realize this was meant to address practical concerns. All cryptography addresses practical concerns, otherwise we'd just stick with one time pads. One single impractical exchange (for the initial exchange of private information) is nothing when you get numerous future, practical exchanges as a result.
Actually, Schneier specifically said in that interview that it makes public key cryptography insecure. He was referring to symmetric, private key cryptography when he stated that it doesn't make all cryptography insecure.
Remember, I cut the receiver from the line and connected an identical device (which RANDOMLY connects components, like the receiver's) to the line. You don't ask the receiver what his random choices are (if you did, I'd just compromise this secondary channel).
But your device isn't identical to what's at each end. If it's not identical, it will generate different current and voltage levels, which can be detected. A "brute force" approach to getting the right ones wouldn't work since, unless your first guess was correct, it would be detected that the voltage and current levels aren't right on the first attempt.
The legitimate communicators know ahead of time the hardware of the device they're communicating with. The hardware acts as the secret key on both ends. The "secondary channel" would be real life meetings or something else that's secure, making it no less secure than any other manual exchange of secret keys.
You see, this is why you shouldn't try to analyze something without knowing about electronics. It amuses me greatly when cryptographers pretend they have expertise in an area where they obviously don't have it.
Simple as that, no EE involved. And I'm sure it's not the only answer (there are some posts about measuring the propagation of the signals too).
Nope, it's not simple as that. This is why you need to be an actual EE. You can't passively monitor it, you need to inject a current into the system, which is easily detected.
Where would that barcode be placed? You can't place it anywhere where it would be rubbed, scratched or otherwise come off. If you place it on the inside, it makes it more of a pain in the ass to scan it in, especially when you have many tires to scan. You're a crazy conspiracy theorist, have fun with those crazy theories.
You realize that those RFID tags are specially designed for that, right? You can't just do it with any arbitrary RFID tag and it doesn't make sense that they'd use these more expensive RFID tags in their tires. It has to drive right under it or over it. You'd be better off with a camera.
Really? I read the Sokymat link that you pasted and I even searched the site, there's only one page about the RFID tire things and it doesn't mention anything about reading arbitrary RFID tags from 14 feet below, especially not at 100 km/hr. Why don't you provide proper sources? These are PASSIVE RFID tags (meaning that you have to get close to them to power them through induction), they're not going to be read except close up and certainly not at high speeds.
You completly misread that. They're using RFID only as a serial number, to make it easier to know where each tire came from during a recall. In the article you linked to, it specifically says they're doing it simply because it makes compliance easier, not because it's REQUIRED. Sounds like a common sense business move, since RFID makes it easy to identify tire serial numbers. The TREAD Act doesn't even mention RFID, I actually searched the PDF text of it (linked in my original comment).
And again, if you read those links you paste, you'll note that they put in RFID to comply with the customers they're supplying to, one of which is the DoD, the other is Wal-Mart. They could have chosen not to, certainly, if they wouldn't mind losing those contracts. However, there's no legal regulation saying they must use RFID.
Besides, technologically speaking, reading RFID off of moving cars is infeasible. IF you read the first article you linked to, they had significant problems just making the RFID tags readable from any orientation (upside down/right side up). So doing it from a moving vehicle, from a random location on the tires isn't possible. The RFID tag is embedded in a specific part of the tire, so the reader has to be put right next to it for a period of time to read it. How are you going to do that with a moving vehcile, or even a stationary one where the RFID tag may be on the opposite side of the tire that the reader is on?
In any case, I'm definitely not a shill for the FBI, I find your posting hilarious, and I'm sure you're a troll, I p ost this only for the good karma.:)
This is way too over-the-top for me to believe this guy is anything other than a troll, read the end: " 4 out of 5 times this post was rapidly modded to -1 by fbi shills angry at the epson ink info and tire info and explosives taggant info and only one time did it survive the FBI negative modding Slashdot accounts and remain at +2 by the next day. If you like to read RFID facts like this that I BROKE FIRST IN SPRING OF 2001 here on Slashdot, then keep this vital post from getting modded to -1 by idiots that cannot follow links or perform searches for themselves."
Come on, FBI shills? I can't believe this got moderated up, this is bad even by Slashdot's standards. You should be ashamed!
In case you actually bother to look up anything he mentioneds, like the TREAD Act, you'll note there is no conspiracy. The TREAD act is about Tire Safety and Accountability for defective/bad tires, it has nothing to do with tracking or RFID.
Re:I worked for an ISP that was hosting a M$ site
on
Debugging Microsoft.com
·
· Score: 3, Insightful
Pardon me if I think you're lying through your teeth. How could they not notice that they're no longer connecting to a Windows server? They would still have to connect via FTP or something other protocol, did you spoof those too? Not just that, how did you manage to fake the whole directory tree? If they connect to upload files, they'd notice it was a unix system by the file hierarchy and the fact that ASP DIDN'T WORK ANYMORE. Yes, there are some *nix ASP products, but they don't work that well. They'd definitely notice something was wrong the second they tried changing something on the website.
It can actually. Our understanding of how climatology can involve peforming controlled experiments. And your comparison to evolution is completely bunk, this has no religious basis and it is contested within the scientific community.
That analogy might work if it weren't for the fact that the root DNS companies in question do not own, control nor have any responsibility for the ISP's DNS servers (the "pipes"). The water companies, OTOH, are largely responsible and do exercise control over the pipes that deliver the water to your house. You're basically blaming companies for something they don't have control over and that's totally irrational. Rogers' problem is Rogers' problem, not the problem of root dns servers. Fuck, while you're at it, in typical Slashdot lore, just throw in a totally random and out of place jab at Microsoft? After all, I'm sure Microsoft is somehow tangentially responsible for this.
Your assertion that the root DNS servers don't want to protect themselves is ludicrous. They simply don't have a viable option due to the existing DNS infrastructure, w hich they don't have control over. They're not going to hold the entire internet hostage (illegally, mind you) for the sake of trying to get people to correct configurations. And even when they did that, it would only reduce the severity of the problem, not eliminate. The point you keep evading is that caching is only part of the problem--they still receive a large influx of bad queries for other reasons and it would still be expensive to maintain.
You don't want monopoly driven pricing? Well then, why don't you actually propose a solution? Because this doesn't actually solve it. DNS is centralized, so it's automatically going to be monopoly driven no matter how well behaved DNS servers are. So why don't you work on your miracle proposal for decentralized DNS? Oh I know why--because shit like that doesn't work. You don't have a solution, you're just talking out of your anti-corporate ass. You're whining becuase you're too damn cheap to pay $8/year for a domain name. Registrars pay $5 per domain, that's their price, it's not high, stop your bitching.
Wow, why didn't anyone else think of that?! Probably because it's a really bad solution and would only end up pissing people off, disrupting the service of tons of innocent people without getting anything accomplished. They've tried overly agressive services like that for spam, which just piss people off and as a result few people use those services. While you're at it, take your vigilantism to an extreme, any misconfigured server of any kind gets its DNS cut off, great idea! Nevermind that this would be very, very illegal. You don't even bother thinking these things through, do you?
And you still managed to be evasive, did you read the studies? The large amount of bad requests aren't just due to a lack of caching, if you had read the studies in question you'd know that. No matter how you cut it, running root servers requires a massive amount of bandwidth, even if your "solution" worked, this would still be true. You refuse to address this. But hey, don't let things like facts get in your way.
I'm sorry, but did you even bother reading this guy's post where he quoted actual figures? How does gigabits of bandwidth constitute very little bandwidth? Did you notice the massive amount of improperly configured DNS servers in the studies I showed you? I'm sorry, but the facts are in direct contradiction to your ridiculous hypothesis. I know you're not going to bother addressing facts because they go against your point and instead you'll use your typical tactic of becoming evasive and spewing out random irrelevent bullshit to help preserve your ego.
Your tactic of cutting off DNS servers like that would likely mean most would be cut off, and that's a ridiculous and rather moronic "solution", if you could call it one. You may not see it as being a huge problem, but the studies and figures show that is. What you're doing is is saying "I don't think there should be a problem, therefore I'm going to stick my fingers in my ears and go 'lalalalaalalalal it's not a huge problem because I say so lalalalalala'." Doesn't work that way. Your proposal of cutting off most DNS servers would cause chaos. Even if most servers were configured properly, they would still require a large amount of bandwidth to maintain, unless you're using some weird tom-math whereby gigabits are still nothing.
So, in conclusion, come back to me when you're willing to actually address the facts and not just make up magical "solutions" that involve cutting off most DNS servers on the internet.
Jesus Tom, this is twice in a week I've seen you get moderated up for blatantly false statements on Slashdot. As saikatguha266 rightfully pointed out, operating the root DNS servers requires a massive amount of bandwidth and has high operating costs. In addition to that, DNS queries are already recursive, so I don't understand what your point is. People who don't even understand how the DNS protocol works, and try to assert that a fundamental component of how it works--recursion--isn't used, shouldn't criticize it.
You're not insightful, you're suggesting making them waste even more money than is already wasted. As someone else pointed out (http://www.bind9.net/dnshealth/), many DNS servers are already improperly configured and as a result, are bombarding the root DNS servers with tons of unnecessary queries. It's a huge waste of bandwidth and resources. If DNS servers were configured properly, respecteced DNS TTLs, cached queries properly, a huge burden would be taken off the root servers, and they could actually lower their prices.
Slashdot Mirror
With the wonderful template metaprogramming that you mentioned, you can't do as much as easily and you are at the mercy of the implementation (e.g. how many levels of expansion).
There are a theoretical infinite number of levels of expansion, limited only by available memory for the compiler. So what limitations does it have?
I said it has more, and listed some of them. You've yet to explain how to somehow discount all those paradigms back down to one.
You're right that it does, but most coders only limit themselves to imperative (which I generally don't count because almost all languages support it) and functional.
The fact that I made a syntax error in an array declaration doens't change the fact that LISP supports more than one paradigm -- and more paradigms than C++.
More? So which extra ones does it support?
The fact that you said "destructor" when you meant "constructor" is equally atrocious - by your own logic, I could argue you don't know C++.
I corrected myself right after I wrote it. I was actually thinking "destructor" when I wrote it, but accidentally wrote constructor instead. Nonetheless, I made no syntax errors (as I wrote no code), especially not a newbie one.
And why did you add me as a fan?!
Holy shit. An insane amount of those comments were moderated 0 or -1, "offtopic." There's no way that many random Slashdot moderators would waste their mod points moderating down a large thread of trolls. You only get like 5 moderator points at a time, so that means either a) a lot of random Slashdot moderators were just being overzealous that day for no good reason or more likely, b) the small group of official moderators (like CmdrTaco), who have an infinite number of mod points, moderated them down.
I'm guessing B, because I have never, EVER seen a single thread that literally had dozens of comments from different users moderated to 'offtopic.'
That seems to be many paradigms to me -- and some of them have no C++ equivalent.
You're right, I forgot about LISP's kludgey macro system. Of course, this doesn't make it "arbitrarily complex."
That seems to be many paradigms to me -- and some of them have no C++ equivalent.
Like what? You can't even declare a simple character array properly, what makes me think you know that they have no C++ equivalent?
Actually, I was just trying to make an example. I have plenty of experience with C++.
Which is why you don't know the syntax for declaring a character array?
Well, in this case, the race condition was between the GC and the other thread.
It wasn't, since they wouldn't using a garbage collector in this case.
You could have race conditions, but not between the GC and a thread. In this case, it would have been a cureall.
I don't think you understand what cureall means. If something only applies to a very select and limited case, it's very much the opposite of a cureall. I'm guessing he was inexperienced with multi-threading, because I'm no expert in it, yet even I can recognize that information you want to be globally accessible should be in a global variable of some kind.
Well, that's why a C++ programmer gets less work done; he has to do tasks that a LISP programmer doesn't have to deal with
Well if you repeat that enough times, it must make it true! Or not. LISP will end up taking far more time because of its limited language capabilities. The rest of the world prefers multi-paradigm langauges, and for good reason.
In this case, the performance penalty of a LISP, over C++ would be negligible -- so overall, the C++ programmer loses.
No, not really.
As Ron makes clear, there were multiple programmers.
Yes, but he apparently was the one responsible for finding this particular problem. His rant reads more like he's bitter than anything else, probably because *he* is the one who introduced the error in the first. Also, sour grapes.
So using C++ imposes more costs: the programmers have to talk to make sure they don't fuck themselves with little implementation details
Are you kidding me? The programmers always have to talk to eachother on ANY project, it doesn't matter what the language is. First you suggest that programmers not be cautious, then you suggest that they not talk to eachother. And this "little implementation detail" is something that should have been obvious from the beginning. "Let's use local stack storage to share details between threads" is just plain dumb.
What's the headache? Also, why do you say "less powerful"? I'm really not getting your point here.
Have you actually seen how enormously complex and large the C++ language is? Given that you can't even manage a simple declaration, I doubt it.
LISP is a more powerful language, because it has closures, a GC, arbitrarily complicated macros, runtime compilation, etc.
C++ supports all of those except runtime compilation (which is rather problematic anyway when dealing with a COMPILED language) and can do it better too. The templating system allows you to do all kinds of things, that's the beauty of C++, it's very extendable.
Since the 1970's, Common Lisp has been faster than Fortran for problems where performance matters.
And fortran was superseded by C in perforamance many years ago. Beating Fortran ceased being an accomplishment long ago. Incidentally, that's wrong. Back then Fortran had the best support for mathematical computations.
Furthermore, if you will argue that "C" or C++ is faster than LISP, because you can do machine-level things, then I'd ask why you just don't use assembly, to get the most "power". Whatver "C" has, assembly has more of it, right?
No, because the compilers are far superior. The best high level compilers you can get are for C/C++. No amount of equivalent work has gone into the sheer man-hours into their development to make the best optimizing compilers.
So I made a basic syntax error, and now I don't know anything about C++? That's absurd. And there's no need to be so insulting.
Yes, it does. It wasn't just a typo, that indicates you have little to no experience with C++. That's not the kind of mistake anyone with significant experience would make.
My point was that if you wanted a simple program to do what they were doing, C++ would allow you to build a mostly working, but under some conditions horribly broken program very easily, and a language with a GC wouldn't.
First of all, a GC isn't not a magic cureall. Second of all, there is GC support for C++. Third of all, this is programmer induced race condition, it's a rare kind of error. GC is generally only helpful in avoiding memory leaks, it is rarely ever helpful in preventing such kinds of rare errors as this which actually break the program. So really, all GC ends up doing is, at best, make it so you don't have to restart your program (assuming they are leaking significantly) for like 99.9% of implementations.
Your points about using wrappers or destructor Kung Fu are in keeping with the "always do things very carefully" attitude of C++: if someone makes a mistake, it is his fault.
Because programmers shouldn't be careful, right? And a person who makes a mistake isn't at fault for the mistake even though THEY made it?
Someone like Ron, knowing that there's a chance of making a mistake, would prefer to use tools that remove the risk of him making a mistake from the get-go.
Using LISP doesn't remove the risk of making mistakes. It just forces you into a less powerful language and ends up giving you a headache, all for the sake of avoiding some trivial programming error. Being google, I'd imagine performance issues were of concern too.
It's actually very difficult to imagine businesses with an enormous need to transmit extra-securely between two fixed points.
Hah. You mean like a BANK? Any financial institution? Any large company with a VPN between two offices? All communications between two military bases? There are lots of ordinary applications by businesses whose communications need to be confidential, the idea that it's limited just to nuclear missle launch sites is ridiculous.
Well, the actual arguement was against Kish's ludicrous claim that his technique was "absolutely secure", which you already surrendered by changing the subject to "practical" security.
Bullshit, you were suggesting it wasn't secure at all, that a simple tap could compromise it, that's a far cry from simply saying that it's not "absolutely secure." You thought you had found a way to compromise the system, but you didn't. Now you're just backpedaling and arguing semantics.
In any case, "absolutely secure" is obviously referring to the security of the transmission medium itself, not the possibility of someone breaking in and copying the hardware on each end. It's very clear that he meant "absolutely secure" in the same sense that a one time pad is "absolutely secure"--that as long as you don't break into the endpoints to steal the secret key, it's secure. The transmission medium is "absolutely secure," but obviously he's not making allowances for physical security to protect the endpoints from break-ins/inside jobs/whatever as those are outside the scope of cryptosystems.
For anything outside of nuclear-missile control, Kish and QC lose the cost argument: carrying more OTPs to the remote site is incomprably more affordable than building and maintaining a dedicated cable.
Only if you operate under the assumption of small amounts of data transfer.
For nuclear-missile control, Kish and QC lose the robustness argument: if that dedicated cable is sabotaged, there is no way the system can fall back to packet-switched or RF transmission.
That's a vulnerability of ANY system. They can cut the cable, jam radio communications and so forth. No system is immune. Just because his system is vulnerable to hte same thing that all wire-based mediums are doesn't mean it's not robust. Would you call 100% of cryptography on the internet non-robust? Because that's what you're suggesting, since you can't get on the internet without directly or indirectly connecting to some line that can get cut. In any case, for nuclear missle control, they'd obviously have multiple redundant systems.
Using consumer-grade optical discs, I can lift in one hand enough random numbers to transmit data for 10 years (assuming new keys are loaded at 100hz, which is faster than proposed QC methods would provide them).
What the hell are you talking about? You just made an insane generalization without knowing how much data would need to be transmitted by the numerous potential users. A one time pad on one CD is enough to transfer exactly one CDs worth of data. Guess what? I personally go through a CDs worth of data over my personal internet connection in just several days of internet usage, imagine what it would be like for a business.
Why the hell would you limit usage to 100hz? The limit for this method is no where near that low. You deliberately brought up existing QC methods (which are irrelvent to the resistor method) because you know that you've lost this argument.
Conversly, QC requires continuous, impractical immobility of both sender and reciever. You can't move.
That's not an issue if you're transmitting from one building (which is static) to another. Gee, certainly no one who is stuck in one place has a use for cryptography!
DEstructors, not constructors, sorry. That should also read "The issue IS memory deallocation."
I saw your code in your other and it has a very basic "newbie syntax error" in declaring a char array. This tells me you don't even know basic C/C++ and aren't really qualified in the slightest to comment on it. Whoever taught you C++, you should get a refund from.
This is why it's called a race condition, because the two threads were racing each other, with the ad-count-writer trying to finish before the main thread freed up the memory it was using to get those counts.
That's a programmer induced race condition though, it has nothing to do with the system. Threads are supposed to deallocate data their own data when they're finished, that's a known and expected behavior. Local thread data storage is just that--local to the thread, it's not meant to be shared.
If you want to share data between threads, you use specific mechanisms for that, which are available on practically all operating systems in some form. Even if it's not explicitly available, you can just easily allocate data on the heap and share that, it's not really hard at all. This is an out and out programmer error, nothing to do with a problem with C/C++. The problem could have been avoided with a single, simple heap allocation.
On top of that, this kind of bug is actually impossible to introduce except in a language with manual memory management like C++. In a language with automatic memory management like Java or Lisp the system automatically notices that the memory is still in use and prevent it from being reused until all threads were actually done with it.
The distinction between "automatic" and "manual" memory management is arbitrary. With java you have to manually allocate memory for data and the same for any other language, though the semantics might vary. The issue memory deallocation. First of all, C++ provides many automated means for automatic memory deallocation, namely in the form of constructors, especially with wrapper classes designed to deallocate data. Second of all, there is garbage collection available for C++, it's just not typiclly used.
By the time this bug was found and fixed (by Ed) I was a mental wreck, and well on my way to becoming a physical wreck as well. My relationship with my wife was beginning to strain. My manager and I were barely on speaking terms.
If an error like that turned this guy into such a mental wreck, then quite frankly, he's a moron.
Of course. And we call that technique One Time Pads. It was technically detailed more than 50 years ago, and was informally used much earlier.
No, that's not a one time pad, a one time pad requires regular manual, impractical exchanges of data. You need to do it continuously to sustain the secure channel. With this device, you would only need to do the exchange ONCE and then you can send information forever.
OTP does all that, and doesn't require an actual copper wire to be installed between the endpoints (which adds tremendous cost and DOS vulnerability to the system)
OTP wouldn't work with one impractical exchange. You need to do it repeatedly and exchange large amounts of data each time.
This "invention" (like QC) is almost as good as "Proposal for Running OTP Wearing a Daffy Hat"- at least the hat costs less than 60 km of cable.
I find it interesting that you're criticizing quantum cryptography too, this pretty much discredits you on the subject matter. QC isn't a OTP, it's superior to it.
You're trying to carry mathematical concepts into the physical world, it doesn't work like that.
How did you get that list? It had to be communicated somehow. If the channel by which the list was transmitted is secure, then the whole random-resistor scheme is redundant. If it's insecure, then it is vulnerable to man-in-the-middle tampering, and so is the whole scheme.
I already covered this in the comment you responded to. You can use it to securely exchange information in a way that's no more vulnerable than any other exchange of secret keys. Of course, these methods of manual key exchange are impractical to perform regularly, which is why you wouldn't substitute them for this technology.
You see, this is why you shouldn't try to analyze something without knowing about cryptography. It amuses me greatly when amateurs pretend they have expertise in an area where they obviously don't have it.
Right. Given that your criticisms apply equally to quantum cryptography and even one time pads, which you probably think are secure, I'm *sure* you know more about cryptography than me. If you had actually bothered to think this through, you'd realize that. Of course having knowledge of the hardware gives you the ability to compromise the system, but the same applies to any system--if you could manage to get physical access to the hardware, you're screwed.
Then you proceeded to disregard the exchange medium as being redundant, on the basis that it should replace the other medium. But of course, if you exercised some critical thought, you'd realize this was meant to address practical concerns. All cryptography addresses practical concerns, otherwise we'd just stick with one time pads. One single impractical exchange (for the initial exchange of private information) is nothing when you get numerous future, practical exchanges as a result.
Actually, Schneier specifically said in that interview that it makes public key cryptography insecure. He was referring to symmetric, private key cryptography when he stated that it doesn't make all cryptography insecure.
Remember, I cut the receiver from the line and connected an identical device (which RANDOMLY connects components, like the receiver's) to the line. You don't ask the receiver what his random choices are (if you did, I'd just compromise this secondary channel).
But your device isn't identical to what's at each end. If it's not identical, it will generate different current and voltage levels, which can be detected. A "brute force" approach to getting the right ones wouldn't work since, unless your first guess was correct, it would be detected that the voltage and current levels aren't right on the first attempt.
The legitimate communicators know ahead of time the hardware of the device they're communicating with. The hardware acts as the secret key on both ends. The "secondary channel" would be real life meetings or something else that's secure, making it no less secure than any other manual exchange of secret keys.
You see, this is why you shouldn't try to analyze something without knowing about electronics. It amuses me greatly when cryptographers pretend they have expertise in an area where they obviously don't have it.
Simple as that, no EE involved. And I'm sure it's not the only answer (there are some posts about measuring the propagation of the signals too).
Nope, it's not simple as that. This is why you need to be an actual EE. You can't passively monitor it, you need to inject a current into the system, which is easily detected.
Where would that barcode be placed? You can't place it anywhere where it would be rubbed, scratched or otherwise come off. If you place it on the inside, it makes it more of a pain in the ass to scan it in, especially when you have many tires to scan. You're a crazy conspiracy theorist, have fun with those crazy theories.
You realize that those RFID tags are specially designed for that, right? You can't just do it with any arbitrary RFID tag and it doesn't make sense that they'd use these more expensive RFID tags in their tires. It has to drive right under it or over it. You'd be better off with a camera.
Really? I read the Sokymat link that you pasted and I even searched the site, there's only one page about the RFID tire things and it doesn't mention anything about reading arbitrary RFID tags from 14 feet below, especially not at 100 km/hr. Why don't you provide proper sources? These are PASSIVE RFID tags (meaning that you have to get close to them to power them through induction), they're not going to be read except close up and certainly not at high speeds.
You completly misread that. They're using RFID only as a serial number, to make it easier to know where each tire came from during a recall. In the article you linked to, it specifically says they're doing it simply because it makes compliance easier, not because it's REQUIRED. Sounds like a common sense business move, since RFID makes it easy to identify tire serial numbers. The TREAD Act doesn't even mention RFID, I actually searched the PDF text of it (linked in my original comment).
:)
And again, if you read those links you paste, you'll note that they put in RFID to comply with the customers they're supplying to, one of which is the DoD, the other is Wal-Mart. They could have chosen not to, certainly, if they wouldn't mind losing those contracts. However, there's no legal regulation saying they must use RFID.
Besides, technologically speaking, reading RFID off of moving cars is infeasible. IF you read the first article you linked to, they had significant problems just making the RFID tags readable from any orientation (upside down/right side up). So doing it from a moving vehicle, from a random location on the tires isn't possible. The RFID tag is embedded in a specific part of the tire, so the reader has to be put right next to it for a period of time to read it. How are you going to do that with a moving vehcile, or even a stationary one where the RFID tag may be on the opposite side of the tire that the reader is on?
In any case, I'm definitely not a shill for the FBI, I find your posting hilarious, and I'm sure you're a troll, I p ost this only for the good karma.
This is way too over-the-top for me to believe this guy is anything other than a troll, read the end: "
4 out of 5 times this post was rapidly modded to -1 by fbi shills angry at the epson ink info and tire info and explosives taggant info and only one time did it survive the FBI negative modding Slashdot accounts and remain at +2 by the next day. If you like to read RFID facts like this that I BROKE FIRST IN SPRING OF 2001 here on Slashdot, then keep this vital post from getting modded to -1 by idiots that cannot follow links or perform searches for themselves."
Come on, FBI shills? I can't believe this got moderated up, this is bad even by Slashdot's standards. You should be ashamed!
In case you actually bother to look up anything he mentioneds, like the TREAD Act, you'll note there is no conspiracy. The TREAD act is about Tire Safety and Accountability for defective/bad tires, it has nothing to do with tracking or RFID.
Pardon me if I think you're lying through your teeth. How could they not notice that they're no longer connecting to a Windows server? They would still have to connect via FTP or something other protocol, did you spoof those too? Not just that, how did you manage to fake the whole directory tree? If they connect to upload files, they'd notice it was a unix system by the file hierarchy and the fact that ASP DIDN'T WORK ANYMORE. Yes, there are some *nix ASP products, but they don't work that well. They'd definitely notice something was wrong the second they tried changing something on the website.
It can actually. Our understanding of how climatology can involve peforming controlled experiments. And your comparison to evolution is completely bunk, this has no religious basis and it is contested within the scientific community.
That analogy might work if it weren't for the fact that the root DNS companies in question do not own, control nor have any responsibility for the ISP's DNS servers (the "pipes"). The water companies, OTOH, are largely responsible and do exercise control over the pipes that deliver the water to your house. You're basically blaming companies for something they don't have control over and that's totally irrational. Rogers' problem is Rogers' problem, not the problem of root dns servers. Fuck, while you're at it, in typical Slashdot lore, just throw in a totally random and out of place jab at Microsoft? After all, I'm sure Microsoft is somehow tangentially responsible for this.
Your assertion that the root DNS servers don't want to protect themselves is ludicrous. They simply don't have a viable option due to the existing DNS infrastructure, w hich they don't have control over. They're not going to hold the entire internet hostage (illegally, mind you) for the sake of trying to get people to correct configurations. And even when they did that, it would only reduce the severity of the problem, not eliminate. The point you keep evading is that caching is only part of the problem--they still receive a large influx of bad queries for other reasons and it would still be expensive to maintain.
You don't want monopoly driven pricing? Well then, why don't you actually propose a solution? Because this doesn't actually solve it. DNS is centralized, so it's automatically going to be monopoly driven no matter how well behaved DNS servers are. So why don't you work on your miracle proposal for decentralized DNS? Oh I know why--because shit like that doesn't work. You don't have a solution, you're just talking out of your anti-corporate ass. You're whining becuase you're too damn cheap to pay $8/year for a domain name. Registrars pay $5 per domain, that's their price, it's not high, stop your bitching.
Wow, why didn't anyone else think of that?! Probably because it's a really bad solution and would only end up pissing people off, disrupting the service of tons of innocent people without getting anything accomplished. They've tried overly agressive services like that for spam, which just piss people off and as a result few people use those services. While you're at it, take your vigilantism to an extreme, any misconfigured server of any kind gets its DNS cut off, great idea! Nevermind that this would be very, very illegal. You don't even bother thinking these things through, do you?
And you still managed to be evasive, did you read the studies? The large amount of bad requests aren't just due to a lack of caching, if you had read the studies in question you'd know that. No matter how you cut it, running root servers requires a massive amount of bandwidth, even if your "solution" worked, this would still be true. You refuse to address this. But hey, don't let things like facts get in your way.
I'm sorry, but did you even bother reading this guy's post where he quoted actual figures? How does gigabits of bandwidth constitute very little bandwidth? Did you notice the massive amount of improperly configured DNS servers in the studies I showed you? I'm sorry, but the facts are in direct contradiction to your ridiculous hypothesis. I know you're not going to bother addressing facts because they go against your point and instead you'll use your typical tactic of becoming evasive and spewing out random irrelevent bullshit to help preserve your ego.
Your tactic of cutting off DNS servers like that would likely mean most would be cut off, and that's a ridiculous and rather moronic "solution", if you could call it one. You may not see it as being a huge problem, but the studies and figures show that is. What you're doing is is saying "I don't think there should be a problem, therefore I'm going to stick my fingers in my ears and go 'lalalalaalalalal it's not a huge problem because I say so lalalalalala'." Doesn't work that way. Your proposal of cutting off most DNS servers would cause chaos. Even if most servers were configured properly, they would still require a large amount of bandwidth to maintain, unless you're using some weird tom-math whereby gigabits are still nothing.
So, in conclusion, come back to me when you're willing to actually address the facts and not just make up magical "solutions" that involve cutting off most DNS servers on the internet.
Jesus Tom, this is twice in a week I've seen you get moderated up for blatantly false statements on Slashdot. As saikatguha266 rightfully pointed out, operating the root DNS servers requires a massive amount of bandwidth and has high operating costs. In addition to that, DNS queries are already recursive, so I don't understand what your point is. People who don't even understand how the DNS protocol works, and try to assert that a fundamental component of how it works--recursion--isn't used, shouldn't criticize it.
You're not insightful, you're suggesting making them waste even more money than is already wasted. As someone else pointed out (http://www.bind9.net/dnshealth/), many DNS servers are already improperly configured and as a result, are bombarding the root DNS servers with tons of unnecessary queries. It's a huge waste of bandwidth and resources. If DNS servers were configured properly, respecteced DNS TTLs, cached queries properly, a huge burden would be taken off the root servers, and they could actually lower their prices.