With the same logic you could argue that all states run by a dictator, that does not screw up too badly should be left alone.
This is a flawed analogy. Internet users don't have to use ICANN. They could use some other root DNS servers. If the majority of net users switched to another service, then ICANN would not be the defacto controller anymore. Further, ICANN could be removed from its position by the US government without very much fuss. So yes, ICANN is akin to a dictator, albeit one that can be removed at the whim of the majority. I believe such systems are commonly known as 'democracies'.
DNS resolves in a hierarchical structure, and therefore there are root DNS servers that sit at the top of the tree. This has to be the case in order to guarentee DNS entries are consistant. Without a central authority, how would you decide who gets a certain domain name?
Given this, a monopoly is a necessary evil. The question is who controls this monopoly. Currently ICANN, a private US company oversees this. ICANN has its faults; more public involvement would be nice, less kissing up to large multinationals wouldn't go amiss either. However, ICANN has not screwed up too badly, and the US doesn't interfere with ICANN too often.
The alternative to ICANN is a group created by a bureaocracy of counties that all want a piece of the pie. Many people are leery of such an idea, as there's a strong possibility that this will turn out to be worse than ICANN.
As the majority of people here know, this debate was not about who controls the Internet, but which countries have authority over the body that controls the central DNS servers.
Frankly, I couldn't care one bit where ICANN is based, just so long as politicians bloody stay away from it! If you don't understand it, then it might not be a good idea screw about with it, especially when all of the experts are telling you not to. How hard is this concept to grasp?
To its credit, the US has been quite good about not fucking things up... so far. However, I rather fear that the political fuss over the xxx domain may be the tip of a rather ugly iceburg.
Unfortunatly, the invasion into our privacy has only just begun. There is no techonlogical way to avoid this - it will only get worse.
In terms of cameras and the like, I agree with you, though in terms of purely virtual privacy issues (for instance, monitoring instant messages and emails), it's reasonably easy to gain secure privacy through encryption and pseudonymous networks.
I just wish there were a way of applying this to meatspace:(
It's designed to get around NATs and firewalls, but this is not the same as creating a protocol that's designed to be difficult to see.
For instance, WASTE, IIRC, sends a random n-byte encryption key the moment a client connects. The client and server then use this key to obscure the handshake of public keys. To the outside observer, it looks like a stream of random bytes; there isn't any substrings to recognise.
To stop WASTE, you'd either need to implement a whitelist, or spend a large amount of computing power checking for keys if no pattern is found. You improve this further by embedding a hard-coded password in each new release; to block this type of protocol, one would need to alter your firewall each time a new client version is released.
One could go even further by masking your protocol using a HTTPS handshake. You'd then either have to ban HTTPS and thus prevent people from shopping and banking online, or you'd have to maintain a whitelist of trusted sites, which again would seriously hamper Internet business growth.
Unless you're willing to set up a carefully audited whitelist of trusted sites, you can't stop a protocol designed not to be stopped.
I think that would be quite difficult to implement such a law. Grokster only got in trouble because it was deemed to be promoting piracy. The RIAA has tried, and failed, to make P2P illegal. What makes you think they can succeed at making VPNs illegal?
I don't think the Great Firewall would be particularly effective at blocking content that is designed not to be blocked.
Re:And the MPAA/RIAA's response will be...
on
Darknets Coming Soon?
·
· Score: 2, Informative
A pseudonoymous network system like MUTE or FreeNet would solve this by offering plausible deniability. You can't tell whether your neighbours are requesting illegal files, or whether they are merely unknowingly routing a request from someone else on the network.
I'm talking about the creation of a new species. If one can observe it in the wild, then ID is proven false.
As others have noted, speciation has been observed in the wild. However, this does not prove ID false. Just because evolution is occuring now, does not imply that it occurred in the past. Indeed, one could make the argument that the entire Universe was created a mere 5 minutes ago, and there would be no way to disprove this assertion.
KDE and GNOME should share a theme engine, not combine. That way applications look the same on both desktops, but we don't get any of the disadvantages that would come from a merger.
I've always felt that KDE feels more mature and, for want of a better word, more solid, perhaps, than Gnome. Though that may just be what I'm used to and what I prefer. It's a shame that SuSE's moving away; few major distros support KDE by default, and now we're one less.
Perhaps you don't understand how to read those pages?
Pray tell, how would you read this:
The Secunia database currently contains 0 Secunia advisories marked as "Unpatched", which affects RedHat Enterprise Linux AS 4.
Personally, from this I conclude that Secunia know of no unpatched vulnerabilities in RedHat Enterprise Linux, but clearly there's a hidden meaning! Perhaps you could decipher this message for me?
Just wondering... how can Red Hat have no vulnerabilities, when the 2.6 linux kernel alone has 15 unpatched vulnerabilities?
Because RedHat don't use the stock 2.6 kernel. No major distribution does.
As of writing, Internet Explorer 6 has 20 unpatched vulnerabilies, one or more of which are marked as highly critical. Firefox has 3 vulnerabilities, with one or more marked as less critical. So yes, Firefox is more secure than IE.
The Linux market is so incredibly tiny that no hacker looking to make money takes the time to hack Linux.
I would not rate a 30-40% webserver marketshare as 'incredibly tiny', and yet Red Hat, the most popular Linux distribution for servers has 0 unpatched vulnerabilities whilst Windows Server 2003 suffers from 8 unpatched vulnerabilities and Windows XP Professional suffers from a full 26 vulnerabilities one or more of which are marked as as highly critical.
How can claim that Linux is less secure than Windows, when it has less unpatched vulnerabilities?
By that token you could go after many companies. You could argue Microsoft causes economic damage by failing to properly secure its software which results in companies losing millions in lost productivity.
I have a choice whether I buy Microsoft products or not. I do not have a choice whether I receive spam (short of stopping using email altogether).
Okay, now you're just making up a strawman arguments to knock down.
Apologies; this was unintentional, and I appear to have misunderstood your argument, and you mine.
My original assertion was that mod_python is similar in performance to mod_perl, and mod_perl can scale successfully to large loads. Evidence of this can be seen in Slashdot, which uses mod_perl and handles around 3 million hits daily.
Others in the thread alleged that Slashdot was sometimes unstable, and that this demonstrated mod_perl was inherently unscalable to large loads. I disagreed, pointing out that any instabilities were due to bugs in Slashcode, rather than mod_perl's inability to handle high traffic sites.
If you are not arguing that mod_perl (or mod_python) cannot handle high loads without becoming unstable, then I have no issue. I'm not defending Slashcode, but I do take exception to the tenuous assertion that mod_perl and mod_python do not scale, as some Slashdot posters seemed to suggest. Especially when this assertion is not backed up with even the most circumstancial of evidence.
Good point; but I don't think Linux has a problem with looks. MSN messenger looks as ugly as sin, has a cluttered interface and annoying adverts lodged in the client. Kopete, on the other hand, is clean, simple, and looks a hell of a lot nicer.
The mod_perl and software framework used by slashdot doesn't offer much scalability. Therefore, the developers were forced to implement an ad-hoc caching system that doesn't work well.
With caching, it's easy to get a little too aggressive and end up caching stale information or writing that stale information to persistent storage.
So mod_perl can only be used for high volume traffic if it uses an unstable caching system. If we follow this strange premise to its inevitable end, we must conclude that there exists an unstable caching algorithm, that can be programmed in Perl, that is exponencially faster than the fastest known stable caching algorithm. After all, this theoretical unstable algorithm cannot just be, say, twice as fast - as one could just double or triple the hardware - for a stable caching algorithm to be realistically impractical, our unstable caching algorithm needs to be exponentially faster.
Let me outline a stable caching algorithm for comment posting:
Get POST data from user INSERT user data as row in comments table Delete cache for comments index For each parent of comment: ____ Delete cache of comment
Now, one could remove the cache deletions and use a cron task to remove them at leisure, which would improve performance. But whilst this would result in a delay between when a user posts to when the post appears, it would not result in destruction or alteration of data, because comments are immutable.
Perhaps you could outline an algorithm that is exponentially faster, but more unstable, than the one I've given above? Extraordinary claims require extraordinary evidence.
In regards to your question of speed vs. stability, there's often a tradeoff between the two.
In several years of programming, I don't think I've ever come across a situation where stability has to be sacrificed for speed.
The errors are exactly the point. The errors appear because the slashdot code has to do a lot of caching and other tricks to reduce system load and handle the traffic in a reasonable manner.
If I understand your argument correctly, you're saying that even if an unstable piece of software can serve up 30 pages per second, a stable piece of software cannot do the same. I must confess to being puzzled by this; why does speed imply a greater risk of instability? I cannot think of a single 'trick' related to scalability that would inherently increase instability of the overall system.
Slashdot Mirror
Yes, it's called IPv6.
This is a flawed analogy. Internet users don't have to use ICANN. They could use some other root DNS servers. If the majority of net users switched to another service, then ICANN would not be the defacto controller anymore. Further, ICANN could be removed from its position by the US government without very much fuss. So yes, ICANN is akin to a dictator, albeit one that can be removed at the whim of the majority. I believe such systems are commonly known as 'democracies'.
DNS resolves in a hierarchical structure, and therefore there are root DNS servers that sit at the top of the tree. This has to be the case in order to guarentee DNS entries are consistant. Without a central authority, how would you decide who gets a certain domain name?
Given this, a monopoly is a necessary evil. The question is who controls this monopoly. Currently ICANN, a private US company oversees this. ICANN has its faults; more public involvement would be nice, less kissing up to large multinationals wouldn't go amiss either. However, ICANN has not screwed up too badly, and the US doesn't interfere with ICANN too often.
The alternative to ICANN is a group created by a bureaocracy of counties that all want a piece of the pie. Many people are leery of such an idea, as there's a strong possibility that this will turn out to be worse than ICANN.
Better the devil you know, in other words.
As the majority of people here know, this debate was not about who controls the Internet, but which countries have authority over the body that controls the central DNS servers.
Frankly, I couldn't care one bit where ICANN is based, just so long as politicians bloody stay away from it! If you don't understand it, then it might not be a good idea screw about with it, especially when all of the experts are telling you not to. How hard is this concept to grasp?
To its credit, the US has been quite good about not fucking things up... so far. However, I rather fear that the political fuss over the xxx domain may be the tip of a rather ugly iceburg.
Or discardable manufactured bodies, as in Ghost in the Shell. I think we're a while away from that, though :)
In terms of cameras and the like, I agree with you, though in terms of purely virtual privacy issues (for instance, monitoring instant messages and emails), it's reasonably easy to gain secure privacy through encryption and pseudonymous networks.
I just wish there were a way of applying this to meatspace
IIRC SSL XORs an MD5 and SHA1 hash together and uses the resulting combined hash.
It's designed to get around NATs and firewalls, but this is not the same as creating a protocol that's designed to be difficult to see.
For instance, WASTE, IIRC, sends a random n-byte encryption key the moment a client connects. The client and server then use this key to obscure the handshake of public keys. To the outside observer, it looks like a stream of random bytes; there isn't any substrings to recognise.
To stop WASTE, you'd either need to implement a whitelist, or spend a large amount of computing power checking for keys if no pattern is found. You improve this further by embedding a hard-coded password in each new release; to block this type of protocol, one would need to alter your firewall each time a new client version is released.
One could go even further by masking your protocol using a HTTPS handshake. You'd then either have to ban HTTPS and thus prevent people from shopping and banking online, or you'd have to maintain a whitelist of trusted sites, which again would seriously hamper Internet business growth.
Unless you're willing to set up a carefully audited whitelist of trusted sites, you can't stop a protocol designed not to be stopped.
I think that would be quite difficult to implement such a law. Grokster only got in trouble because it was deemed to be promoting piracy. The RIAA has tried, and failed, to make P2P illegal. What makes you think they can succeed at making VPNs illegal?
I don't think the Great Firewall would be particularly effective at blocking content that is designed not to be blocked.
A pseudonoymous network system like MUTE or FreeNet would solve this by offering plausible deniability. You can't tell whether your neighbours are requesting illegal files, or whether they are merely unknowingly routing a request from someone else on the network.
Good news all round, it would seem. :)
As others have noted, speciation has been observed in the wild. However, this does not prove ID false. Just because evolution is occuring now, does not imply that it occurred in the past. Indeed, one could make the argument that the entire Universe was created a mere 5 minutes ago, and there would be no way to disprove this assertion.
KDE and GNOME should share a theme engine, not combine. That way applications look the same on both desktops, but we don't get any of the disadvantages that would come from a merger.
People should choose their desktop environment based on personal preference, not to participate in software zealotry.
I've always felt that KDE feels more mature and, for want of a better word, more solid, perhaps, than Gnome. Though that may just be what I'm used to and what I prefer. It's a shame that SuSE's moving away; few major distros support KDE by default, and now we're one less.
Does anyone seriously have flamewars over Vi vs. Emacs anymore?
Pray tell, how would you read this:
Personally, from this I conclude that Secunia know of no unpatched vulnerabilities in RedHat Enterprise Linux, but clearly there's a hidden meaning! Perhaps you could decipher this message for me?
Because RedHat don't use the stock 2.6 kernel. No major distribution does.
As of writing, Internet Explorer 6 has 20 unpatched vulnerabilies, one or more of which are marked as highly critical. Firefox has 3 vulnerabilities, with one or more marked as less critical. So yes, Firefox is more secure than IE.
I would not rate a 30-40% webserver marketshare as 'incredibly tiny', and yet Red Hat, the most popular Linux distribution for servers has 0 unpatched vulnerabilities whilst Windows Server 2003 suffers from 8 unpatched vulnerabilities and Windows XP Professional suffers from a full 26 vulnerabilities one or more of which are marked as as highly critical.
How can claim that Linux is less secure than Windows, when it has less unpatched vulnerabilities?
What's done to prevent man-in-the-middle attacks?
I have a choice whether I buy Microsoft products or not. I do not have a choice whether I receive spam (short of stopping using email altogether).
Apologies; this was unintentional, and I appear to have misunderstood your argument, and you mine.
My original assertion was that mod_python is similar in performance to mod_perl, and mod_perl can scale successfully to large loads. Evidence of this can be seen in Slashdot, which uses mod_perl and handles around 3 million hits daily.
Others in the thread alleged that Slashdot was sometimes unstable, and that this demonstrated mod_perl was inherently unscalable to large loads. I disagreed, pointing out that any instabilities were due to bugs in Slashcode, rather than mod_perl's inability to handle high traffic sites.
If you are not arguing that mod_perl (or mod_python) cannot handle high loads without becoming unstable, then I have no issue. I'm not defending Slashcode, but I do take exception to the tenuous assertion that mod_perl and mod_python do not scale, as some Slashdot posters seemed to suggest. Especially when this assertion is not backed up with even the most circumstancial of evidence.
Good point; but I don't think Linux has a problem with looks. MSN messenger looks as ugly as sin, has a cluttered interface and annoying adverts lodged in the client. Kopete, on the other hand, is clean, simple, and looks a hell of a lot nicer.
So mod_perl can only be used for high volume traffic if it uses an unstable caching system. If we follow this strange premise to its inevitable end, we must conclude that there exists an unstable caching algorithm, that can be programmed in Perl, that is exponencially faster than the fastest known stable caching algorithm. After all, this theoretical unstable algorithm cannot just be, say, twice as fast - as one could just double or triple the hardware - for a stable caching algorithm to be realistically impractical, our unstable caching algorithm needs to be exponentially faster.
Let me outline a stable caching algorithm for comment posting:
Now, one could remove the cache deletions and use a cron task to remove them at leisure, which would improve performance. But whilst this would result in a delay between when a user posts to when the post appears, it would not result in destruction or alteration of data, because comments are immutable.
Perhaps you could outline an algorithm that is exponentially faster, but more unstable, than the one I've given above? Extraordinary claims require extraordinary evidence.
In several years of programming, I don't think I've ever come across a situation where stability has to be sacrificed for speed.
If I understand your argument correctly, you're saying that even if an unstable piece of software can serve up 30 pages per second, a stable piece of software cannot do the same. I must confess to being puzzled by this; why does speed imply a greater risk of instability? I cannot think of a single 'trick' related to scalability that would inherently increase instability of the overall system.