SQL is particularly weak if you have definite but flexible hierarchy -- for example, say that you have relations like this between objects:
Obj1 (type A) "owns" Obj2 (type B) and Obj3 (type C)
Obj2 (type B) "owns" Obj4 (type C) There is no particularly good way to model this relationship in SQL; you need at least four tables (one to establish ownership relations and act as object identifiers, and three to define the traits for types A, B and C) where you would ideally want only three.
Another weakness is when implementing "business logic" -- rules that define whether or not particular changes are allowed, or what else must change to keep things consistent. In the past (I believe SQL99 improves this, but is not widely supported yet), there was no standard for defining smart triggers, constraints or stored procedures, and some database systems did not support such things at all. One common solution to this problem is to have a layer of code in front of the database that performs all of the transactions and reports business logic violations to its clients -- the classic three-layer database system, but not as efficient or clean as if the business logic could be handled by the database system itself.
There are some other application-specific weaknesses; for example, a full inverse text index cannot be stored both efficiently and portably in SQL. This has impact on things like DNA sequencing as well as text searches.
On-line analytical processing is also somewhat limited within the standard; this partly goes back to the lack of a standard trigger language, and partly to the traditional table/row model of a SQL database.
SQL is a very powerful and very useful standard, and its existence as a standard has done an incredible amount of good. It does not solve every problem -- but given how complex the standard already is (and has to be), that may be a good thing.
Accusing MySQL and PostgreSQL of "breaking" the SQL standard is a pretty weak accusation. Commercial databases have used non-standard syntax (both for features described by the standard and features that are not) and have not supported all of the standard-defined language year in and year out. Such failings are not limited to open source databases. MySQL's lack (until fairly recently) of transactions and sub-selects is a much more interesting criticism, as would be PostgreSQL's lack of clustering or replication support. Heck, even a performance critique would be more valid than saying that MySQL and PostgreSQL are not conformant with every bit and every optional feature of the SQL standard.
Re:Influences, agendas shouldn't matter with facts
on
Rare Earth
·
· Score: 1
Why does it deserve a footnote? Because they are still doing statistics with a sample size of 1, and when you do that, you have to make a whole lot of assumptions without strong scientific basis.
When somebody has an agenda to push, they tend to make assumptions that support that agenda. Scientific support for any theory on the frequency of life cannot exist yet due to lack of data. Without such support, it is only fair to say which bias(es) you were influenced by when making assumptions.
You, too, miss the point that Dinda and Placeway had in inserting those entries. From a Zephyr message by Dinda following up the letter being published by Stereophile:
The "moose", along with "Squid in vegetable broth" and "evaporated
haggis", were an attempt to make it obvious that we were kidding.
Perhaps they should have tried a little less subtle satire for the benefit of less sophisticated readers.
Thank you for your comments, but the Ada FAQ (see section 2.6), a timeline of the language's history, and a writeup for a UMich course suggest otherwise. While S. Tucker Taft may have led the Ada 95 revision team and Jean Ichbiah led the Cii Honeywell Bull team designing the submission to the DoD (which became Ada 83), the design of the language is clearly not the work of a small number of people.
Rather, it was designed to meet a specification from a DoD working group and received feedback from hundreds of reports (and dozens of individuals or other groups).
While Robert Dewar's answer to "Was Ada designed by a committee?" is certainly witty, a rose by any other name would smell the same. Taft's answer lists -- for just Ada 95 -- not only the core "Design Team," but five other full- or nearly-full-time teams ("Language Precision Team", "Requirements Team", and three "user/implementor" teams) and the large group of "Distinguished Reviewers."
Given all that, I will retract my description of Ada as being designed by a committee -- it was in fact designed by a beauracracy!
(As for VHDL, I cannot find as detailed information on the web about its history, and don't have my VHDL books with me right now. However, the timeline at the University of Erlangen-Nürnberg's VHDL-online -- with discussions and defining requirements taking up most of a decade -- suggests that it suffered from too many cooks at times.)
While I agree that Ada and VHDL are very expressive and powerful, it's not good to get rose-colored glasses about their history or (especially in VHDL's case) drawbacks.
I'm surprised you didn't mention Verilog -- it's an HDL that is (outside of military contracting) much more popular than VHDL. The "obtuse" syntax in VHDL you mention is based on Ada's syntax -- both were designed essentially by committee. Verilog, in contrast, is based on C's syntax (with some Pascal thrown in).
VHDL has a much richer syntactic set than Verilog; however, it's easy to lose track of some of the features, and most synthesis tools need to convert to Verilog for gate-level representation of the code eventually. Some companies (such as Altera, with AHDL) have created hybrid languages that add some of the features to VHDL to Verilog; Verilog 2000 (which does the same, but isn't as widely proven yet) is another option. Still, if you want a simpler HDL than VHDL, I'd recommend Verilog.
The languages derived more directly from C and Java (SystemC, for example) are even less tested; it's hard to tell what bugs or other shortcomings exist in the tools. C and Java were designed without concurrent structures, and this makes me suspect HDLs derived from them will actually be more awkward than VHDL or Verilog.
I don't give a rats ass who knows where I surf. And I don't care about spam. Sure, I get lots of emails a day promising my larger breasts and a huge dick, but is it really that harmful?
Maybe you don't care who knows where you surf. Others do, particularly if they live in a country where reading the wrong web sites is a good way to end up in prison.
Maybe you don't care about the time and annoyance of spam. Others do, particularly if they're busy people, have children using the net, etc.
But those are irrelevant to the point that Mr. Gielda and Cotse bring up in the URL posted, and your arguments about the FBI and fundamentalists are specious. In the FBI case, they could presumably get a subpoena, in which case he is obliged to reveal the information. In the fundamentalist case, you seem to almost be sanctioning the fundamentalist coming hunting for blood.
Of course I don't condone violence, but when you allow someone the right to say whatever they want, you're giving them the right to say something that could REALLY piss someone off. Say it, and you're gonna have to put up with the consequences. It's called prior restraint or something, isn't it? (I'm no lawyer - honest).
Part of living in a free society is that sometimes you hear things you don't like, and if those things don't infringe on your freedom, you are obliged to let the speaker say them. You may disagree with that. There are any number of oppressive regimes in this world that do disagree; they do not provide a free society.
As for prior restraint, that's an entire other ballpark -- prior restraint is making something illegal to ever say. It is a label applied to government actions, not those of private citizens.
No one should have to live in fear for speaking an honest opinion, but the cyber-terrorists that Mr. Gielda describes try to instill that fear -- just like any other terrorists.
If I've offended anyone, then I'm sorry. If you're angry at me, that's fine.
I'm not angry, and don't understand why anyone would be. I'm just astounded at your lack of concern for civil liberties and your sanction of illegal response to the exercise of civil liberties.
You're fundamentally mistaken. The issues at stake really are timeless. I'm sure that people in the 21st century have taken abuse to new levels and new applications, but harassment by lawyer and fraud are nothing new.
Ben Franklin once said, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." It applies to this situation as well as it did to the US Revolutionary War.
Mr. Gielda did identify the problem correctly -- it is not that Cotse's users expect too much privacy; it is that attackers engage in illegal tactics that are unlikely to be punished, and they have learned that they can get away with this. It's the WWW (Wild Wild West) all over again; fewer people may die, but lives still get ruined, and technology just makes it harder to prosecute the bad guys.
Re:its all quite unambiguous...
on
GCC 3.0 Released
·
· Score: 2
> So the int i should be in the outside scope.
No version of the C language allows a declaration in the middle of a block (i.e. between two statements), although C++ does. Your explanation assumes that such a thing is permitted in C.
C99 specifically addresses how constructs like "for (int i=0; i10; i++) STMT" should be handled; it specifies that the compiler should treat it as if there were a new enclosing block around the "for... STMT" that began with the declaration of the variable(s) in the init-part of the "for" loop.
So C99 says that:
for (int i=0; i10; i++) STMT
should be transformed to act like (in older C standards):
{ int i; for (i=0; i10; i++) STMT }
C99 makes it unambiguous indeed.
(I can't speak towards the ISO C++ standard, but I would imagine that they also stipulate that the scope of the defined variables ends after STMT above.)
That's an excellent example of comparing apples to oranges. Internet access is not about delivering certain content, yet you cite three content-based systems as things that are not provided unbundled. The only absurd statements I see are yours, comparing network access to something it isn't, and assuming that being able to buy just network access precludes being able to sell any sort of enhanced network access.
I agree with the person who compared network access to things like the phone system -- you can buy just local phone access if you want; you do not have to buy caller ID or call forwarding or any of the other extensions that phone companies offer. You do not even need to get long distance on a phone line! Being able to buy that basic phone access is analogous to the consumer right that Laubach was advocating.
Despite the fact that phone customers do not need to buy the extensions, many phone companies do provide them, and many consumers do buy them. They are a value-add that is compatible with the basic network, and IP is much richer in protocol terms than dialtone *and* much more compatible with other protocols living on the same wire. Any argument that mandating the availability of a basic IP dialtone will prevent innovation is pure FUD.
As for rewriting laws and IPv7, you vastly underestimate the ability of people to get around unjust laws (through legal or extra-legal means) and the momentum that preserves protocol compatibility. If the laws are unjust, organizations like the EFF and EPIC will fight them in the courts and coders around the world will demonstrate on the network how silly such regulations are. IPv4 and IPv6 are both very compatible with privacy and anonymity services, and the cost to replace them everywhere will prevent regulation requiring transition to any new protocol.
You make the very assumption that you say is a bad one -- you trust that the algorithms you are employing are secure, and more, that the implementations you are using them with are secure.
On top of that, if somebody can always get in, they can always hunt you down and apply rubber hose cryptanalysis. They can do that even without breaking into your machine, and there's not much you can do if an attacker is that determined.
At some point, it comes down to actually having to trust something. Do you trust that your client has not been compromised with a program that will pass any cleartext it sees on to your competitor (or the Mafia, or the government)? Do you trust that your network will deliver a reasonable fraction of the packets you send out? Do you trust that your encryption and authentication are difficult to defeat?
This isn't very surprising, either; you just usually don't think much about trust issues in the real world, because anonymity in the real world is much harder to attain. Do you trust the guy across the street not to pull out an Uzi and try to mow you down? Most people do, because there are generally compelling deterrences against that (based primarily on the ease of being identified and the difficulty of leaving the scene without leaving indentifiable traces). Some people don't, so they either stay inside or only go out in the company of bodyguards. It's a decision that must be made on a case-by-case basis, even if you don't often think about making that choice.
So one of the real tricks in the online world is finding the right balance between anonymity and identification -- some balance point that protects both the victims and the victimized. This is not the only tricky thing about online security; actual bug-free (or security bug-free) code is at least as important, and the code cannot have any more security than the protocol.
Most of the IP-based protocols used in the world today ignore all of these in favor of features and glitz, because they're driven by commercial decision processes, but there's always hope that newer protocols will be adopted and that they will supplant the insecure protocols that come out first. (For more on that, I refer the reader to the classic "Worse Is Better" paper.)
Derive the encryption keys by monitoring the beginning of the conversation? It's easy to make this impossible (or at least, require brute-force of the stream cipher's keys). Diffie-Hellman key exchange is a quick and easy way to do this, and the US patent on it expired last year.
As for the big red flag going up, that's a red herring. Network privacy shouldn't be significantly different than, say, letter-writing privacy -- and nobody goes around (seriously) saying "If you put your letters in envelopes rather than postcards, you must be up to no good!"
Finally, steganography (or other covert channels)isn't a terribly practical scheme for large transfers; it requires a lot of un-useful information compared to the hidden information. Rivest's chaffing and winnowing is probably more useful than hiding a few bits in different parts of HTTP requests. Plus, E-commerce cookies are usually rather shorter than crypto keys, so you'd need several to be useful. Which in itself would be vulnerable to detection via traffic analysis.
Indeed. The ServerBench description page claims it's an "application server" benchmark, but it looks like it's something they implemented themselves. This means that it's almost worthless as a test bench -- it's not very representative of *anything* since server performance varies more with the server program than almost anything else.
If their protocol is simple enough to make it easy to optimize for different platforms (for example, Win32 vs Unix), it's almost certainly too simple to make an interesting test. If it's a complex protocol, I suspect they optimize then Win32 code a lot more than the Linux code.
You obviously didn't read the last paragraph in the "Analysis" section of the article. They claim it didn't arrive in time for them to test. Granted, that's a pretty bogus claim, but it's their excuse.
"Telephone routing" is increasingly a historical term. Today, IP is frequently carried over ATM backbones along with voice data. This adds some burstiness to the traffic patterns. For traditional voice connections, the number of endpoints is still hugely more than their scheme could scale to. It might be managable routing based only upon the ATM Virtual Path, but unfortunately, not all routes use that. Sometimes the ATM Virtual Circuit must come into the equation, and that multiples the 256 (or 4096, depending on whether you're on the edge of the ATM network or not) VPs by 65536 VCs. Maybe you could restrict the domain sufficiently to solve it using their scheme, but they'd have to work at it.
Sometimes it's funny to see non-programmers comment on the progress of computer programming.
Usually it's not.
There's a lot more to programming than just "solving problems" (in the traditional sense, like cracking RC5 or playing chess). For the average application, much more code is devoted to the human interface than is devoted to solving problems. User interfaces cannot be represented solely by neural networks. There are many, many discrete problems where neural networks are suboptimal -- for example, parsing a protocol or performing arithmetic. In these domains, digital logic excels.
In fact, "neural networks" as you describe them are very little more than genies in your computer. You have to train the nets to solve problems -- but first, you need to define the problem, figure out the inputs and outputs, and decide on a reasonable set of training data. You overlook all of this, and represent ANNs as being able to solve anything you can represent in English. The truth is far from that. Have you ever tried to tell a person how to perform a complicated task? How many times did it take you until they understood it? How much longer until they did things the way you thought it should be done? No matter how good your computer's neural network is, it will be either too smart, too dumb, or too specialized to solve a lot of problems given only vague descriptions (at least for the next 20 years or so).
A good programmer is marked by his or her ability to think about a problem and understand a good (not necessarily the best, since there are too many metrics involved to optimize for all of them) way to solve it. This solution may involve fuzzy AI like ANNs. It may involve traditional imperative/procedural programming. It may involve functional programming. There are too many different tasks that computers take on to say there is one best methodology.
There's a big difference between the switching that this can do and solving the IP lookup problem. The neural net structure in the router (as described) can just route in a grid from one edge cell to another. In most routers, there are relatively few of these "edge cells" -- one per line card, or at most one per port on the various line cards. So say between 16 and 1024 endpoints in their system (and 1024 is bigger than almost all deployed systems). Compare this to the 3 billion plus valid IPv4 addresses, or to the 2^126 IPv6 addresses in assigned spaces, and the structure they're using cannot physically scale to the necessary sizes.
(My background? I work at a company that designs chips to power the line cards in routers.)
I must say that your experience with cable modems has been better than mine. I have RoadRunner cable (at least until their contract with Cox Cable expires and @Home is foisted on the area), and am pretty sick of its shoddy performance.
I am not sure if it's local shared-media saturation or just the 1.5mbit/192kbit cap (which, once @Home comes around, will be 1.5mbit/128kbit), but something gives me very high packet loss and higher-than-usual latency for interactive games.
Maybe cable modems do have a higher current (theoretical) bandwidth near end users, but my experience -- and that of friends in other areas -- is that DSL gives better actual performance for us. In addition, the companies building DSL equipment are busy developing higher-speed DSL standards. At least they show that they care about improving bandwidth in the future; cable modem companies seem content to keep rate limiters on their customers that provide lower capacity and more packet loss than DSL does even today.
I call your attention to the part you quoted which says "AT LEAST as great as the precautions you take to protect your own confidential information."
If you agree to treat certain information as someone else's trade secret and keep it confidential, there are minimal things you must do (regardless of how little you take care of your own confidential information, which you have the a priori right to disseminate). If you knowingly do less, you're still legally liable for violating that confidentiality.
For the most part, firewalls are only minimally helpful. There's not much evidence that they do more than slow down determined attackers. Moreover, it's questionable whether you can actually set up firewalls to prevent most attacks without severely hampering legitimate uses of the network -- especially in places like broadband home networks or universities, where a central MI$ department can't dictate usage to end users.
Much better is to provide a default secure installation for software, and encourage people who set up listening services on their machines to know how to administer them properly. Throwing a firewall at something blindly is more likely to cause more problems than it solves.
Object oriented code is not inherently more maintanable than non-OO code. It's just easier to structure in a maintanable way. This is complicated by the fact that most languages designed to support object oriented programming add a lot of overhead unless you're very careful with types (e.g. where you put const in C++, or all of ML, where typechecking can be a major pain). Anything with dynamic invocation has more overhead (but also more extensibility) than purely static invocation, and dynamic invocation is a favorite feature in object oriented languages.
Of course, the real argument is whether or not Linux really isn't OO, as the first post stated. It's monolithic rather than microkernel, but most of the internal design is object-centric. Look at the VFS, at the device subsystem, at the USB stack.. the list goes on and on. Just because it's C doesn't mean it doesn't have objects.
Yes, you can install this under WINE, and even run the executables under WINE (if your WINE is of a recent enough vintage). The only problem is that the C code in the package is for the point release. Since the Linux version of the point release isn't out yet, you can't try new versions of the mod out on a Linux box (yet)..
The insistence with which some people clamor for open sourcing everything really annoys me (and a lot of other people). There are very good reasons not everything is open sourced, and sometimes they're not even due to stupid licensing restrictions imposed by third-party code.
For something like SETI@home (or distributed.net or whatever else you like), there's a very good reason to keep the clients binary-only. Namely, there is no oracle for verifying that a block of search space was actually searched by the client that claims to have searched it. Abuse of this was seen by the DES challenge and distributed.net before; open-sourcing SETI@home would lead to even worse abuses. Unethical people would modify the code to claim they had searched oodles of key blocks, ruining the results of the search -- and only so they could show off how "studly" their computer system is.
Of course, maybe this concept is too hard for bgp4 to grasp. But for goodness's sake, it's in the SETI@home FAQ. Whining about their policies on Slashdot isn't likely to change their minds.
(Beyond the malicious introduction of false reports, it's very easy to "optimize" something like this and introduce numerical or algorithmic errors. Unless you are familiar with advanced theories of signal processing -- the sort of thing you'd find in graduate classes at a good university -- you would be well over your head in looking at how the algorithms work. And there are enough bright grad students working on the average project to know how to optimize for all sorts of cases without the help of a bunch of open source zealots who think that the GPL is some magic potion that can be applied to anything to make it better.)
Blech, I go and get all huffy about checking details before posting and then make that very mistake in my own post. Thanks to those who corrected my erring math -- it's been too long since I looked at it. As for the dicing of words about factoring, I shall clarify: most public-key crypto relies on the difficulties of factoring PRODUCTS of large primes. I shall henceforth be even more strict in my self-editing before posting.:)
Slashdot Mirror
SQL is particularly weak if you have definite but flexible hierarchy -- for example, say that you have relations like this between objects:
Obj1 (type A) "owns" Obj2 (type B) and Obj3 (type C)
Obj2 (type B) "owns" Obj4 (type C)
There is no particularly good way to model this relationship in SQL; you need at least four tables (one to establish ownership relations and act as object identifiers, and three to define the traits for types A, B and C) where you would ideally want only three.
Another weakness is when implementing "business logic" -- rules that define whether or not particular changes are allowed, or what else must change to keep things consistent. In the past (I believe SQL99 improves this, but is not widely supported yet), there was no standard for defining smart triggers, constraints or stored procedures, and some database systems did not support such things at all. One common solution to this problem is to have a layer of code in front of the database that performs all of the transactions and reports business logic violations to its clients -- the classic three-layer database system, but not as efficient or clean as if the business logic could be handled by the database system itself.
There are some other application-specific weaknesses; for example, a full inverse text index cannot be stored both efficiently and portably in SQL. This has impact on things like DNA sequencing as well as text searches.
On-line analytical processing is also somewhat limited within the standard; this partly goes back to the lack of a standard trigger language, and partly to the traditional table/row model of a SQL database.
SQL is a very powerful and very useful standard, and its existence as a standard has done an incredible amount of good. It does not solve every problem -- but given how complex the standard already is (and has to be), that may be a good thing.
Accusing MySQL and PostgreSQL of "breaking" the SQL standard is a pretty weak accusation. Commercial databases have used non-standard syntax (both for features described by the standard and features that are not) and have not supported all of the standard-defined language year in and year out. Such failings are not limited to open source databases. MySQL's lack (until fairly recently) of transactions and sub-selects is a much more interesting criticism, as would be PostgreSQL's lack of clustering or replication support. Heck, even a performance critique would be more valid than saying that MySQL and PostgreSQL are not conformant with every bit and every optional feature of the SQL standard.
Why does it deserve a footnote? Because they are still doing statistics with a sample size of 1, and when you do that, you have to make a whole lot of assumptions without strong scientific basis.
When somebody has an agenda to push, they tend to make assumptions that support that agenda. Scientific support for any theory on the frequency of life cannot exist yet due to lack of data. Without such support, it is only fair to say which bias(es) you were influenced by when making assumptions.
But with slightly different subject matter, and a different set of suckers. See here. It's amusing to see this kind of hoax fool people.
Thank you for your comments, but the Ada FAQ (see section 2.6), a timeline of the language's history, and a writeup for a UMich course suggest otherwise. While S. Tucker Taft may have led the Ada 95 revision team and Jean Ichbiah led the Cii Honeywell Bull team designing the submission to the DoD (which became Ada 83), the design of the language is clearly not the work of a small number of people.
Rather, it was designed to meet a specification from a DoD working group and received feedback from hundreds of reports (and dozens of individuals or other groups).
While Robert Dewar's answer to "Was Ada designed by a committee?" is certainly witty, a rose by any other name would smell the same. Taft's answer lists -- for just Ada 95 -- not only the core "Design Team," but five other full- or nearly-full-time teams ("Language Precision Team", "Requirements Team", and three "user/implementor" teams) and the large group of "Distinguished Reviewers."
Given all that, I will retract my description of Ada as being designed by a committee -- it was in fact designed by a beauracracy!
(As for VHDL, I cannot find as detailed information on the web about its history, and don't have my VHDL books with me right now. However, the timeline at the University of Erlangen-Nürnberg's VHDL-online -- with discussions and defining requirements taking up most of a decade -- suggests that it suffered from too many cooks at times.)
While I agree that Ada and VHDL are very expressive and powerful, it's not good to get rose-colored glasses about their history or (especially in VHDL's case) drawbacks.
I'm surprised you didn't mention Verilog -- it's an HDL that is (outside of military contracting) much more popular than VHDL. The "obtuse" syntax in VHDL you mention is based on Ada's syntax -- both were designed essentially by committee. Verilog, in contrast, is based on C's syntax (with some Pascal thrown in).
VHDL has a much richer syntactic set than Verilog; however, it's easy to lose track of some of the features, and most synthesis tools need to convert to Verilog for gate-level representation of the code eventually. Some companies (such as Altera, with AHDL) have created hybrid languages that add some of the features to VHDL to Verilog; Verilog 2000 (which does the same, but isn't as widely proven yet) is another option. Still, if you want a simpler HDL than VHDL, I'd recommend Verilog.
The languages derived more directly from C and Java (SystemC, for example) are even less tested; it's hard to tell what bugs or other shortcomings exist in the tools. C and Java were designed without concurrent structures, and this makes me suspect HDLs derived from them will actually be more awkward than VHDL or Verilog.
I don't give a rats ass who knows where I surf. And I don't care about spam. Sure, I get lots of emails a day promising my larger breasts and a huge dick, but is it really that harmful?
Maybe you don't care who knows where you surf. Others do, particularly if they live in a country where reading the wrong web sites is a good way to end up in prison.
Maybe you don't care about the time and annoyance of spam. Others do, particularly if they're busy people, have children using the net, etc.
But those are irrelevant to the point that Mr. Gielda and Cotse bring up in the URL posted, and your arguments about the FBI and fundamentalists are specious. In the FBI case, they could presumably get a subpoena, in which case he is obliged to reveal the information. In the fundamentalist case, you seem to almost be sanctioning the fundamentalist coming hunting for blood.
Of course I don't condone violence, but when you allow someone the right to say whatever they want, you're giving them the right to say something that could REALLY piss someone off. Say it, and you're gonna have to put up with the consequences. It's called prior restraint or something, isn't it? (I'm no lawyer - honest).
Part of living in a free society is that sometimes you hear things you don't like, and if those things don't infringe on your freedom, you are obliged to let the speaker say them. You may disagree with that. There are any number of oppressive regimes in this world that do disagree; they do not provide a free society.
As for prior restraint, that's an entire other ballpark -- prior restraint is making something illegal to ever say. It is a label applied to government actions, not those of private citizens.
No one should have to live in fear for speaking an honest opinion, but the cyber-terrorists that Mr. Gielda describes try to instill that fear -- just like any other terrorists.
If I've offended anyone, then I'm sorry. If you're angry at me, that's fine.
I'm not angry, and don't understand why anyone would be. I'm just astounded at your lack of concern for civil liberties and your sanction of illegal response to the exercise of civil liberties.
You're fundamentally mistaken. The issues at stake really are timeless. I'm sure that people in the 21st century have taken abuse to new levels and new applications, but harassment by lawyer and fraud are nothing new.
Ben Franklin once said, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." It applies to this situation as well as it did to the US Revolutionary War.
Mr. Gielda did identify the problem correctly -- it is not that Cotse's users expect too much privacy; it is that attackers engage in illegal tactics that are unlikely to be punished, and they have learned that they can get away with this. It's the WWW (Wild Wild West) all over again; fewer people may die, but lives still get ruined, and technology just makes it harder to prosecute the bad guys.
> So the int i should be in the outside scope.
... STMT" that began with the declaration of the variable(s) in the init-part of the "for" loop.
No version of the C language allows a declaration in the middle of a block (i.e. between two statements), although C++ does. Your explanation assumes that such a thing is permitted in C.
C99 specifically addresses how constructs like "for (int i=0; i10; i++) STMT" should be handled; it specifies that the compiler should treat it as if there were a new enclosing block around the "for
So C99 says that:
for (int i=0; i10; i++) STMT
should be transformed to act like (in older C standards):
{ int i; for (i=0; i10; i++) STMT }
C99 makes it unambiguous indeed.
(I can't speak towards the ISO C++ standard, but I would imagine that they also stipulate that the scope of the defined variables ends after STMT above.)
That's an excellent example of comparing apples to oranges. Internet access is not about delivering certain content, yet you cite three content-based systems as things that are not provided unbundled. The only absurd statements I see are yours, comparing network access to something it isn't, and assuming that being able to buy just network access precludes being able to sell any sort of enhanced network access.
I agree with the person who compared network access to things like the phone system -- you can buy just local phone access if you want; you do not have to buy caller ID or call forwarding or any of the other extensions that phone companies offer. You do not even need to get long distance on a phone line! Being able to buy that basic phone access is analogous to the consumer right that Laubach was advocating.
Despite the fact that phone customers do not need to buy the extensions, many phone companies do provide them, and many consumers do buy them. They are a value-add that is compatible with the basic network, and IP is much richer in protocol terms than dialtone *and* much more compatible with other protocols living on the same wire. Any argument that mandating the availability of a basic IP dialtone will prevent innovation is pure FUD.
As for rewriting laws and IPv7, you vastly underestimate the ability of people to get around unjust laws (through legal or extra-legal means) and the momentum that preserves protocol compatibility. If the laws are unjust, organizations like the EFF and EPIC will fight them in the courts and coders around the world will demonstrate on the network how silly such regulations are. IPv4 and IPv6 are both very compatible with privacy and anonymity services, and the cost to replace them everywhere will prevent regulation requiring transition to any new protocol.
You make the very assumption that you say is a bad one -- you trust that the algorithms you are employing are secure, and more, that the implementations you are using them with are secure.
On top of that, if somebody can always get in, they can always hunt you down and apply rubber hose cryptanalysis. They can do that even without breaking into your machine, and there's not much you can do if an attacker is that determined.
At some point, it comes down to actually having to trust something. Do you trust that your client has not been compromised with a program that will pass any cleartext it sees on to your competitor (or the Mafia, or the government)? Do you trust that your network will deliver a reasonable fraction of the packets you send out? Do you trust that your encryption and authentication are difficult to defeat?
This isn't very surprising, either; you just usually don't think much about trust issues in the real world, because anonymity in the real world is much harder to attain. Do you trust the guy across the street not to pull out an Uzi and try to mow you down? Most people do, because there are generally compelling deterrences against that (based primarily on the ease of being identified and the difficulty of leaving the scene without leaving indentifiable traces). Some people don't, so they either stay inside or only go out in the company of bodyguards. It's a decision that must be made on a case-by-case basis, even if you don't often think about making that choice.
So one of the real tricks in the online world is finding the right balance between anonymity and identification -- some balance point that protects both the victims and the victimized. This is not the only tricky thing about online security; actual bug-free (or security bug-free) code is at least as important, and the code cannot have any more security than the protocol.
Most of the IP-based protocols used in the world today ignore all of these in favor of features and glitz, because they're driven by commercial decision processes, but there's always hope that newer protocols will be adopted and that they will supplant the insecure protocols that come out first. (For more on that, I refer the reader to the classic "Worse Is Better" paper.)
Derive the encryption keys by monitoring the beginning of the conversation? It's easy to make this impossible (or at least, require brute-force of the stream cipher's keys). Diffie-Hellman key exchange is a quick and easy way to do this, and the US patent on it expired last year.
As for the big red flag going up, that's a red herring. Network privacy shouldn't be significantly different than, say, letter-writing privacy -- and nobody goes around (seriously) saying "If you put your letters in envelopes rather than postcards, you must be up to no good!"
Finally, steganography (or other covert channels)isn't a terribly practical scheme for large transfers; it requires a lot of un-useful information compared to the hidden information. Rivest's chaffing and winnowing is probably more useful than hiding a few bits in different parts of HTTP requests. Plus, E-commerce cookies are usually rather shorter than crypto keys, so you'd need several to be useful. Which in itself would be vulnerable to detection via traffic analysis.
Indeed. The ServerBench description page claims it's an "application server" benchmark, but it looks like it's something they implemented themselves. This means that it's almost worthless as a test bench -- it's not very representative of *anything* since server performance varies more with the server program than almost anything else.
If their protocol is simple enough to make it easy to optimize for different platforms (for example, Win32 vs Unix), it's almost certainly too simple to make an interesting test. If it's a complex protocol, I suspect they optimize then Win32 code a lot more than the Linux code.
You obviously didn't read the last paragraph in the "Analysis" section of the article. They claim it didn't arrive in time for them to test. Granted, that's a pretty bogus claim, but it's their excuse.
"Telephone routing" is increasingly a historical term. Today, IP is frequently carried over ATM backbones along with voice data. This adds some burstiness to the traffic patterns. For traditional voice connections, the number of endpoints is still hugely more than their scheme could scale to. It might be managable routing based only upon the ATM Virtual Path, but unfortunately, not all routes use that. Sometimes the ATM Virtual Circuit must come into the equation, and that multiples the 256 (or 4096, depending on whether you're on the edge of the ATM network or not) VPs by 65536 VCs. Maybe you could restrict the domain sufficiently to solve it using their scheme, but they'd have to work at it.
My two cents: it's spelled "laser," not "lazer."
Sometimes it's funny to see non-programmers comment on the progress of computer programming.
Usually it's not.
There's a lot more to programming than just "solving problems" (in the traditional sense, like cracking RC5 or playing chess). For the average application, much more code is devoted to the human interface than is devoted to solving problems. User interfaces cannot be represented solely by neural networks. There are many, many discrete problems where neural networks are suboptimal -- for example, parsing a protocol or performing arithmetic. In these domains, digital logic excels.
In fact, "neural networks" as you describe them are very little more than genies in your computer. You have to train the nets to solve problems -- but first, you need to define the problem, figure out the inputs and outputs, and decide on a reasonable set of training data. You overlook all of this, and represent ANNs as being able to solve anything you can represent in English. The truth is far from that. Have you ever tried to tell a person how to perform a complicated task? How many times did it take you until they understood it? How much longer until they did things the way you thought it should be done? No matter how good your computer's neural network is, it will be either too smart, too dumb, or too specialized to solve a lot of problems given only vague descriptions (at least for the next 20 years or so).
A good programmer is marked by his or her ability to think about a problem and understand a good (not necessarily the best, since there are too many metrics involved to optimize for all of them) way to solve it. This solution may involve fuzzy AI like ANNs. It may involve traditional imperative/procedural programming. It may involve functional programming. There are too many different tasks that computers take on to say there is one best methodology.
There's a big difference between the switching that this can do and solving the IP lookup problem. The neural net structure in the router (as described) can just route in a grid from one edge cell to another. In most routers, there are relatively few of these "edge cells" -- one per line card, or at most one per port on the various line cards. So say between 16 and 1024 endpoints in their system (and 1024 is bigger than almost all deployed systems). Compare this to the 3 billion plus valid IPv4 addresses, or to the 2^126 IPv6 addresses in assigned spaces, and the structure they're using cannot physically scale to the necessary sizes.
(My background? I work at a company that designs chips to power the line cards in routers.)
I must say that your experience with cable modems has been better than mine. I have RoadRunner cable (at least until their contract with Cox Cable expires and @Home is foisted on the area), and am pretty sick of its shoddy performance.
I am not sure if it's local shared-media saturation or just the 1.5mbit/192kbit cap (which, once @Home comes around, will be 1.5mbit/128kbit), but something gives me very high packet loss and higher-than-usual latency for interactive games.
Maybe cable modems do have a higher current (theoretical) bandwidth near end users, but my experience -- and that of friends in other areas -- is that DSL gives better actual performance for us. In addition, the companies building DSL equipment are busy developing higher-speed DSL standards. At least they show that they care about improving bandwidth in the future; cable modem companies seem content to keep rate limiters on their customers that provide lower capacity and more packet loss than DSL does even today.
You don't read very well, do you?
I call your attention to the part you quoted which says "AT LEAST as great as the precautions you take to protect your own confidential information."
If you agree to treat certain information as someone else's trade secret and keep it confidential, there are minimal things you must do (regardless of how little you take care of your own confidential information, which you have the a priori right to disseminate). If you knowingly do less, you're still legally liable for violating that confidentiality.
For the most part, firewalls are only minimally helpful. There's not much evidence that they do more than slow down determined attackers. Moreover, it's questionable whether you can actually set up firewalls to prevent most attacks without severely hampering legitimate uses of the network -- especially in places like broadband home networks or universities, where a central MI$ department can't dictate usage to end users.
Much better is to provide a default secure installation for software, and encourage people who set up listening services on their machines to know how to administer them properly. Throwing a firewall at something blindly is more likely to cause more problems than it solves.
Object oriented code is not inherently more maintanable than non-OO code. It's just easier to structure in a maintanable way. This is complicated by the fact that most languages designed to support object oriented programming add a lot of overhead unless you're very careful with types (e.g. where you put const in C++, or all of ML, where typechecking can be a major pain). Anything with dynamic invocation has more overhead (but also more extensibility) than purely static invocation, and dynamic invocation is a favorite feature in object oriented languages.
.. the list goes on and on. Just because it's C doesn't mean it doesn't have objects.
Of course, the real argument is whether or not Linux really isn't OO, as the first post stated. It's monolithic rather than microkernel, but most of the internal design is object-centric. Look at the VFS, at the device subsystem, at the USB stack
Yes, you can install this under WINE, and even run the executables under WINE (if your WINE is of a recent enough vintage). The only problem is that the C code in the package is for the point release. Since the Linux version of the point release isn't out yet, you can't try new versions of the mod out on a Linux box (yet)..
The insistence with which some people clamor for open sourcing everything really annoys me (and a lot of other people). There are very good reasons not everything is open sourced, and sometimes they're not even due to stupid licensing restrictions imposed by third-party code.
For something like SETI@home (or distributed.net or whatever else you like), there's a very good reason to keep the clients binary-only. Namely, there is no oracle for verifying that a block of search space was actually searched by the client that claims to have searched it. Abuse of this was seen by the DES challenge and distributed.net before; open-sourcing SETI@home would lead to even worse abuses. Unethical people would modify the code to claim they had searched oodles of key blocks, ruining the results of the search -- and only so they could show off how "studly" their computer system is.
Of course, maybe this concept is too hard for bgp4 to grasp. But for goodness's sake, it's in the SETI@home FAQ. Whining about their policies on Slashdot isn't likely to change their minds.
(Beyond the malicious introduction of false reports, it's very easy to "optimize" something like this and introduce numerical or algorithmic errors. Unless you are familiar with advanced theories of signal processing -- the sort of thing you'd find in graduate classes at a good university -- you would be well over your head in looking at how the algorithms work. And there are enough bright grad students working on the average project to know how to optimize for all sorts of cases without the help of a bunch of open source zealots who think that the GPL is some magic potion that can be applied to anything to make it better.)
Blech, I go and get all huffy about checking details before posting and then make that very mistake in my own post. Thanks to those who corrected my erring math -- it's been too long since I looked at it. As for the dicing of words about factoring, I shall clarify: most public-key crypto relies on the difficulties of factoring PRODUCTS of large primes. I shall henceforth be even more strict in my self-editing before posting. :)