Ethernet has high latency and the kernel adds even more. In consequence, protocols that work via kernel-bypass (which includes some ethernet drivers) will show some performance gain. That's why Van Jacobson channels are superior to normal kernel-processed packets. The greatest gains come, though, when you eliminate Ethernet. Infiniband has roughly a tenth of the latency and SCI has almost a fiftieth. Which is why those tend to be the interconnects used in high-end clusters. They might be good for gaming, too, but they're too damn expensive and you'd need a hybrid switch that could handle multiple connection types and transliterate between them. Not easy, as Infiniband supports concepts regular Ethernet does not. (There are "extended ethernet" devices that add things like RDMA, but can you name anyone who actually has such a device?)
Wouldn't Bluto keep trying to hack in? And what does Popeye think of it?
Seriously, it's an organic oil, which might create problems in the longer-term in a totally sealed environment. I have no idea what olive oil would do over a 5-10 year period exposed to the extreme heat of the silicon surface and the extreme cold of the heat-sink. I'm also not sure what it would do to the silicon, since this would involve direct exposure of the chip itself. The chemistry of organic oils tends to be non-trivial.
It's not really a mead, as it is not primarily honey, but it is good. I like the fact that Dogfish are doing this right. The Japanese brewery that recreated Old Kingdom beer (to the point of reconstructing the original brewing vessels) only did so for one season and distribution was limited. A Californian brewery that recreated one of the 27 known Sumerian beers likewise only did a limited edition. Not all places that sell Dogfish's beers sell Midas Touch though.
Ultimately, there's a huge range of ancient brews that might be very popular but next-to-zero research on the subject and absolutely zero interest from the stores and bars. That has to be fixed before any of this goes anywhere.
For mead, I've produced my own GPLed mead recipe (GPL version 2) which has proven very popular with those who have tried it.
Oh, I agree with what you've said, but I have a very hard time believing people will be porting Linux, OpenBSD or Windows to Erlang any time soon, let alone take advantage of all the capabilities of Erlang. It could be done, in principle, but in practice the codebase is a serious problem. As I mentioned in my submission, one of the previous attempts to change the way CPUs were designed was the Transputer. It died, not because of any flaw in the design (which was superb) but because training everyone in Occam and then converting all the software over was just too large of an obsticle to overcome. And the volume of code in the 1980s was nothing like the volume of code that exists today.
There are many types of error correction codes, and which one you use depends on the nature of the errors. For example, if the errors are totally random, then Reed-Solomon will likely be the error correction code used. CDs use two layers of Reed-Solomon concatenated in series. This is not especially fast, but the output for a CD is in tens of kiloherts and an ASIC could easily be operating in the gigahertz realms. However, when you're talking the internals of a CPU, there's a limit to how slow you can afford things to be.
BCH is a general form of Reed-Solomon and you can therefore tailor the function to handle specific characteristics of the sorts of error observed rather than trying to code round anything that doesn't fit perfectly within Reed-Solomon. Although it's more general, it might actually be quicker if you can find parameters that better describe what it is supposed to be correcting than the default values used by Reed-Solomon.
Turbo codes (as used by NASA for modern deep-space communication) are great when you're dealing with block errors. In long-distance communication, your biggest problem will be bursts of interference rather than the random noise. Wikipedia states: "Turbo codes, as described first in 1993, implemented a parallel concatenation of two convolutional codes, with an interleaver between the two codes and an iterative decoder that would pass information forth and back between the codes." It goes on to state that this is faster than any previous concatenation scheme. Fast is good, here, but it is only meaningful if this is the sort of error experienced.
There are plenty of other sorts out there, and again there may well be error correction codes not listed above that are much better suited to this specific type of problem.
For this, I'd point to the RISC vs. CISC debate. RISC programs took many more instructions to do the same things, but the gain in performance was so great that you ended up with greater performance. Extra steps = some amount of overhead, but so long as the net gain is greater than the net overhead, you will gain overall. The RISC chip demonstrated that such examples really do exist in the real world.
But just because there are such situations, it does not automatically follow that more steps always equals greater performance. It may be that better error-correction techniques in the hardware would handle the transmission errors just fine without having to alter any software at all. It depends on the nature of the errors (bursty vs randomly-distributed, percent of signal corrupted, etc) as to what error-correction would be needed and whether the additional circuitry can be afforded.
Alternatively, the problem may in fact turn out to be a solution. Once upon a time, electron leakage was a serious problem in CPU designs. Then, chip manufacturers learned that they could use electron tunneling deliberately. The cause of these errors may be further electron leakage or some other quantum effect, it really doesn't matter. If it leads to a better practical understanding of the quantum world to the point where the errors can be mitigated and the phenomenon turned to the advantage of the engineers, it could lead to all kinds of improvement.
There again, it might prove redundant. There are good reasons for believing that "Processor In Memory" architectures are good for certain types of problem - particularly for providing a very standard library of routines, but certain opcodes can be shifted there as well. There is also the Cell approach, which is to have a collection of tightly-coupled but specialized processors of different kinds. A heterogenious cluster with shared memory, in effect. If you extend the idea to allow these cores to be physically distinct, you can offload from the original CPU that way. In both cases, you distribute the logic over a much wider area without increasing the distance signals have to travel (you may even shorten the distance). As such, you can eliminate a lot of the internal sources of errors.
It may prove redundant in other ways, too. There are plenty of cooling kits these days that will take a CPU to much lower temperatures. Less thermal noise may well result in fewer errors, since that is a likely source of some of them. Currently, processors often run at 40'C - and I've seen laptop CPUs reach 80'C. If you can bring the cores down to nearly 0'C and keep them there, that should have a sizable impact on whether the data is being transmitted accurately. The biggest change would be to modify the CPU casing so that heat is reliably and rapidly transferred from the silicon. I would imagine that you'd want the interior of the CPU casing to be flooded with something that conducts heat but not electricity - fluorinert does a good job there - and then have the top of the case to also be an extra-good heat conductor (plastic only takes you so far).
However, if programs were designed with fault-tolerence in mind, these extra layers might not be needed. You might well be able to get away with better software on a poorer processor. Indeed, one could argue that the human brain is an example of an extremely unreliable processor whose net processing power (even allowing for the very high error rates) is far far beyond any computer yet built. This fits perfectly with the professor's description of what he expects, so maybe this design actually will work as intended.
Absolutely true. When the Square Kilometer Array (eventually) comes online, it will be possible to directly observe any exoplanet Earth-size or larger at a distance of 1 AU or greater from its sun at a distance of 100 LY from Earth, provided it is not perfectly reflective or perfectly dark within the range of frequencies being looked at. (If there's even one absorption line, the planet will be visible.) With the current design, at the limits given above, the head of the SETI Institute has stated that such a planet would resolve to one pixel. (That particular talk was fascinating, BTW.)
However, consider that most radio telescope arrays have nothing like that collecting area, nor do they have anything like the effective dish radius. Most radio telescope arrays simply can't directly observe exoplanets at any significant distance. This is why indirect observation and indirect measurements remain the norm.
Basically, yes. It's a great way to make money (in this case, the telecos can charge both the user AND the site - twice the money for half the service) and it is extremely effective for things like iPhone apps and television. People really are willing to pay more in order to get less.
One reason I didn't mention it is that it completely skipped my mind, but even if it had, I'm getting used to people picking holes in any argument. Hey, that's not necessarily a bad thing and is often quite valuable, but it means that on "hot button issues" I get extra-careful and make absolutely certain that there exists a solution that would provably and verifiably work for the problems the backbone providers claim to have, that there are no weird corner-cases that would allow the problem to persist or create whole new problems, and is already in actual use (either in part or in whole) somewhere, so that it can't be labeled wild speculation.
So, yes, the solution I suggested was probably excessive, but it would work and work just fine at Internet backbone speeds and would also ensure that machines do not transmit excessive material that will either timeout or otherwise be dropped.
The point is less whose scheme would be "best", but rather that a scheme exists at all. How much does it cost to enable features that are already built into a router or switch? Compared to lobbying several hundred politicians, practically nothing. Lobbying, though, is expensive. And guess who gets to pay for it? Flipping a configuration bit requires testing, sure, but much LESS testing than would be required for firewalling or by-network bandwidth throttling. Testing also costs.
If a scheme - any scheme - exists that would be simpler, cheaper, more efficient and more practical than that offered by the telecos, then that becomes the rational scheme to implement for everyone. The telecos gain, the Government gains, the consumers gain -- the only ones who lose are the ones who want to abandon network neutrality for the purpose of controlling interstate commerce and/or controlling views contrary to their own.
(Interstate commerce? Sure. Throttle back, or block entirely, the IP range owned by a vendor and that vendor ceases to exist. The vendor will be forced to pay protection money to the ISPs in an entirely legal racket.)
Everything will end up being a giant over-reaction. Problem | Solution | Over-Reaction
Cost will go up
Civil Rights will go out the window.
Some Business's will die
Others which should will live like kings
People will get hurt.
Ok. How is telling people that they have to play fair a "power grab"? Surely, the strongest you can say is that this is a denial of a power-grab by the corporate sector.
Ending up an over-reaction? Uhhh, network neutrality has been the accepted practice since the Internet was invented. Imposing the status quo means that there is no reaction. It is enforced non-reaction.
Costs will go up? Why? The status quo is network neutrality. The prices are what they are BECAUSE of network neutrality. Corporations imposing controls WILL raise prices (as in the case of the RIAA - you think CDs cost $10 to make?) but doing nothing will, at most, not alter prices at all.
Civil Rights? I'd say that Tea Partiers being able to control what you see at the network level and being able to impose ABSOLUTE dictatorial power with no possibility of redress is a MAJOR civil rights violation. You are making the corporations Gods, because nobody - not even the Government - will be able to communicate without the express permission of corporate dictators.
Businesses die? Like I said, this is about mandating the status quo. If businesses couldn't survive in the very environment they were designed for, what makes you think they'd survive in a hostile world where major corporations can simply block them out of existence? (Once network neutrality goes, the gloves will come off. Active, malicious blocking of competitors for the purpose of sabotaging and killing them WILL be the norm.)
Giving the mega-corps the power to simply disconnect rivals would certainly leave them living like kings. Preventing any corporation from doing so will eliminate such power games.
People will get hurt? Sure. If there is a bid by wannabe-dictators to seize power over the information you are permitted to see, and the Government denies then that power-bid, people probably will get hurt. Dictators almost always resort to extremes to get what they want. The Government hasn't a great track-record either, but the Tea Party is the one using a vocabulary of violence and extremism. Sure they have freedom of speech, but what gives them the right to rob me of mine?
Because if Network Neutrality goes, the companies get to censor you. They get to censor anyone they feel like, and there's not a damn thing the Constitution will do for you. It only applies to the Government, not private companies. If there's no Network Neutrality, the regional provider will tell you where you can and cannot shop. So you change provider, right? Wrong. There's not much in the way of competition at tier 1 and you don't get to pick what tier 1 your ISP uses. Besides, with much of the redundancy cut out of the Internet as it stands, there IS no way for you to circumvent such restrictions. Oh, and that means that if one backbone provider blocks vendor X, then vendor X will be essentially blocked from ALL backbone vendors downstream of that location. A puritanical backbone provider in one State can impede the commerce in another.
Sure, sure, the providers claim they can't handle the sheer volume of Internet traffic and some small fraction of users use most of it. They can use QoS. ECN, Hierarchical Fair Service Curve and an adaptive packet-dropping scheme like BLACK would be sufficient. (There are a number of schemes, including BLACK, that are designed to prevent packet streaming from clogging up the network. ECN messaging allows the network to tell servers and clients when they need to throttle back. HFSC ensures that nobody can game the system and take unfair advantage of the resources.) This would not be contrary to Network Neutrality, as it ensures that all users are treated absolutely as equals. The networks would be true Common Carriers, rather than Mafia bosses.
Oh, and that reminds me, have you considered that when the RIAA and MPAA started to form and seize power, there were probably people - in all innocence - saying that the industry should take care of itself, that interference would cause problems, that the corporations needed all this extra power for the benefit of the poor, starving artists. Given that the money collected by the RIAA and MPAA never gets seen by said artists, and no serious opposition to this exists, do you seriously expect me to believe that the ISPs and backbone providers will spend the money they rake in through the ultimate protection racket will ever get seen by the poor, starving engineers? Give me a break. You'd have to be insane.
But Chrome is a soft metal. You want Tungsten, if you're going in that direction. Since it's now fashionable to design web browsers in a layered fashion, Graphene might actually be the better bet.
There is almost no way you can really avoid that. Ultimately, once you publish data in a standard format, it is out there. That means that anyone can extract the data and re-present it, embed it in some other content, or indeed do whatever else they feel like.
If a site wants to deep-link and regurgitate badly enough, it's quite capable of running through the entire target site, locally caching the results, and embedding the cached version. This bypasses all protections, but would only work with content that had no controls of any kind beyond straight HTML links. For real-time, just have a spider do all the wandering through the site to the target page. That bypasses any server-side protections automatically, as a "user" is indeed going through all the prior pages - they're just never presented to a human user. I/O is then proxied through the spider, so the remote site sees the spider and treats it as a legitimate user. So long as the spider knows how to get from A to B, when a link on the page does not actually exist, you can simulate the user's navigation. To the user, it's deep-linked. To the target site, it's valid exploration.
It is unnecessary to actually develop such a bot. It is sufficient to show that it is impossible to protect a site against copying, deep-linking, etc, on the server or on the client. If you want to protect content, you cannot do so using the mechanisms in Javascript, HTML or HTTP.
Yeah, but when the inevitable thieves steal the paintings, they almost always damage them when cutting them out. What you really want is a graviton projector embedded in the wall.
"Twain planned to republish every one of his works the moment it went out of copyright with one-third more content, hoping that availability of such 'premium' version will make prints based on the out-of-copyright version less desirable on the market."
If he was actually writing that additional content afterwards, he invented Release Early, Release Often.
If the content actually existed and it was a cynical ploy to sell more products, he invented the model Microsoft uses.
In either case, this puts his business acumen over half a century ahead of anyone else. That's genius.
You're perfectly right, it isn't hard to write modular code. There are many things that are not hard that Microsoft only do after a screaming tantrum, two (or more) court cases and a wallop over the head with a large stick. I'd include "thinking" on that list.
Not every webserver, but you do need that level on ever point of access (physical and virtual). So, this would mean the gateway firewall and/or router, plus the web proxy server(s), plus whatever proxy(s) the users used to connect to the outside world. The web proxies should be on a network that can only talk to the webservers and maybe a NIDS. This isn't overly painful because proxies are relatively simple. They don't involve dynamic database connections, they don't need oodles of complexity, the rights needed are very minimal, the kernel can be one that is very minimal. It's far, far, far simpler than securing the web servers themselves.
The web servers need securing, yes, but if your only access is via a proxy and the proxy is locked-down, and potentially insecure services are only run on ports that are internal (ie: not visible to the proxies), then the risks are restricted to vulnerabilities on the web server and any applications it runs. The rest of the system is effectively masked off. If each thread of the web server is running with the minimum privilege required for that thread, you should be ok. If that's not possible to arrange, then use Mandatory Access Controls to effectively raise the privilege required to do anything hazardous to something above what the web server has.
In other words, take the individual aspects of security and break them down into manageable chunks. One box, one chunk. One big nasty in security is the number of permutations you need to consider, but if you've chunked up the security, you reduce the problem in each chunk to just that chunk, and you reduce the problem of the network to the permutations between each chunk. Everything else is a black box.
No matter how complex the situation, you will always be able to draw circles around "islands" of complexity with few interactions between island. By treating each island individually and then the open seas between them as a separate problem, security becomes much easier. In some ways, this is how most physical security works - you protect the points of entry/exit in one way and protect the internal connections separately and distinctly. For a better example of a layered system, consider a castle with a moat/bailiff system for the outer wall and a keep and other fortified buildings on the inside for different tasks. It's not impossible to break in, but it is hard. But it is much easier to build such a system than to adequately fortify each of the interior buildings to the same level of protection as their fortification plus external fortification provides. By extension, continuing to layer should offer better security still - and, indeed, some of the toughest castles to have ever been built had two or more "outer walls". You could probably build one outer wall that offered the same level of protection, but at vastly greater effort and with all the risks the extra complexity creates.
They had nine suicides and eight fatalities. If they've got undead zombie employees wanting to jump off the roof, restricting access isn't going to do a lot of good.
True, XOR is the fastest operation, and One-Time Pads use XOR and nothing else. However, short of you and the other person using radio telescopes to obtain a common intergalactic source of randomness (and, yes, that is seriously done), you need to take account of the time (and space) needed to store pads large enough and the encryption time (which can't use a One-Time Pad) taken to securely transfer it.
Having said that, for B2B, OTPs using an intergalactic RNG would likely be cheaper and safer than using quantum cryptography. It would also be much more practical, as it takes a lot of hardware at the moment to deliver qbits. Also, OTPs can't be broken -at all- if the pad itself is secure, but the vulnerability recently discussed shows that quantum cryptography CAN be broken to the extent of being partially readable.
To use a common radio source, all you need is a common starting point and a common target. Aluminum atomic clocks have an error of 8.6e-18 of a second. (This makes it a 1.1 Petahertz clock, rather better than the clock chips we're typically using.) That should be good enough to get some excellent randomness from just about any source out there and insure that both collection systems are in-phase.
Consider that one of the biggest area of vulnerabilities is social engineering. If you trust the person behind the till (about whom you know nothing) to hand you a legitimate public key (which, without a third-part, you can't verify), then fine and good. On the other hand, if that same unknown (who might easily be a social engineer who has bluffed his or her way to the counter) hands you a fake key and you CAN verify it by verifying that it has been counter-signed by someone you independently trust, THEN you have a lot more confidence in that key. You aren't dependent on the person being legit because they said so.
High-end Amigas used the 68040 and 68060 processor - which, IIRC, is quite capable of running Linux.
zlib is ok, but other people use szlib or other compression libraries. Huffmann encoding as a form of compression is block-based, zlib is stream-based. These are essentially also the only two types of encryption, as far as data transfer is concerned.
However, most OS' already have the concept of block devices and stream devices. In the same way that a program that operates on a streamed input and/or streamed output doesn't care what the input and/or output actually is, it shouldn't matter if the device/filter they go through is a crypto channel, a compression channel or the English Channel.
In terms of block encryption, you also need to define the encryption mode used. This, too, is nothing more than a component that has an input pipe and an output pipe. It should be pluggable. There is no logical reason for it not to be. Different block cyphers are defined for different block sizes and may have other specific restrictions and/or specific tunable options besides, but provided the I/O API allows you to use standard calls to interrogate and/or set parameters, and provided standard mechanisms are used to prevent the user from mis-matching options, this should not be a big deal.
This means that existing calls for files, sockets, messages, or what have you, could use pre-existing APIs with minor extensions to defined constants to let you have a completely standardized method of tweaking parameters and getting error codes.
If you'd rather use a library and not overload any pre-existing API, it should not be that difficult to stick to very standard methods.
You are right - this is 50% of the problem here. The other 50% is MS just being lazy.
Well, yes. If the IT managers can't tell the difference between Caesar cipher and AES, then it is arguably lazy to use Caesar. Mind you, less work done for the same income from sales equals more profit. And in a world (and stockmarket) driven by profit margins, voluntarily cutting those margins makes no business sense. (It's why the highest-risers in the stockmarket are also the high-risks and also the ones tied to companies most likely to suffer disasters that seriously impact - or in some cases kill - others. Not sure about the US, but in the UK these are sometimes referred to as the Dogs. They can run fast but they can also turn and bite.) Microsoft did not become one of the richest companies in the world by cutting margins. Yes, it is lazy in an intellectual sense, but Microsoft isn't aiming at intellectuals.
DES is sufficiently weak that it is possible to build a home-grown cluster that can break a DES key in minutes. Yes, DES is "strong" in the sense that the algorithm itself has no significant flaws that anyone can detect, but when dealing with a credit card system where it's quite plausible that each card could have a thousand dollars available on it on average, obtaining 500 cards would cover the cost of the EFF's DES-breaking machine and therefore cover the costs. Everything else would be sheer profit for the crook(s). Given that news stories on credit card theft usually talks about hundreds of thousands of cards being stolen, the cost of smashing DES would be 0.1% of the money the criminals could walk off with. In short, as close to nothing as to make no odds.
If the cost of smashing 40-bit or even 56-bit encryption is insignificant, then there is no practical difference between DES and ROT13 at the kind of level of sophistication you'd require to even steal from that many cards without being caught or detected. This leaves you two options - spend less money and superficially meet requirements (and then hope like hell), or spend more money to invest in doing security correctly. Hands up all who know IT managers who enjoy spending money on things that don't (in themselves) offer any return because it is Doing The Job Right. Ok, now hands up all those who know IT managers who take shortcuts to meet business requirements or upper-level management demands even though they know it's probably risky and/or bloody stupid to take those shortcuts?
My guess is that the vast, overwhelming majority raised your hands on the second question and that maybe a few dozen (at most) did so on the first. I also suspect that anyone who questioned my original post would actually agree that IT managers aren't known for Doing The Right Thing when it comes to IT security, that cost and the performance needs of everyone else take first and second place (order depending on where you work). In short, outside threats are likely to be considered rare and more likely to affect underlings than the manager, whereas office politics is a constant and immediate danger with backstabbing and dirty infighting being the norm. You may well be in a place that isn't like that, but if so, I defy you to seriously claim (and prove) that your situation is remotely close to typical.
Even ignoring the treachery that makes up the modern workplace, you still have the Peter Principle to contend with. If you have an IT manager who is experienced at being an IT manager, the principle dictates that this means he has risen to his level of incompetence. Again, there will likely be exceptions, but I'm talking the typical case here.
So, if the typical IT manager is stingy and/or incompetent, thus defining this to be the primary business market for Microsoft, this will be the sort of person Microsoft products will be aimed at. Microsoft is lots of things, but stupid about their customers they are not. If they ship a flaky product, it is because they know the customer won't care and/or won't notice, but will buy it anyway. Hell, Vista for the desktop probably still made a sizable profit despite the complaints and the effective abandonment.
Slashdot Mirror
Ethernet has high latency and the kernel adds even more. In consequence, protocols that work via kernel-bypass (which includes some ethernet drivers) will show some performance gain. That's why Van Jacobson channels are superior to normal kernel-processed packets. The greatest gains come, though, when you eliminate Ethernet. Infiniband has roughly a tenth of the latency and SCI has almost a fiftieth. Which is why those tend to be the interconnects used in high-end clusters. They might be good for gaming, too, but they're too damn expensive and you'd need a hybrid switch that could handle multiple connection types and transliterate between them. Not easy, as Infiniband supports concepts regular Ethernet does not. (There are "extended ethernet" devices that add things like RDMA, but can you name anyone who actually has such a device?)
Wouldn't Bluto keep trying to hack in? And what does Popeye think of it?
Seriously, it's an organic oil, which might create problems in the longer-term in a totally sealed environment. I have no idea what olive oil would do over a 5-10 year period exposed to the extreme heat of the silicon surface and the extreme cold of the heat-sink. I'm also not sure what it would do to the silicon, since this would involve direct exposure of the chip itself. The chemistry of organic oils tends to be non-trivial.
It's not really a mead, as it is not primarily honey, but it is good. I like the fact that Dogfish are doing this right. The Japanese brewery that recreated Old Kingdom beer (to the point of reconstructing the original brewing vessels) only did so for one season and distribution was limited. A Californian brewery that recreated one of the 27 known Sumerian beers likewise only did a limited edition. Not all places that sell Dogfish's beers sell Midas Touch though.
Ultimately, there's a huge range of ancient brews that might be very popular but next-to-zero research on the subject and absolutely zero interest from the stores and bars. That has to be fixed before any of this goes anywhere.
For mead, I've produced my own GPLed mead recipe (GPL version 2) which has proven very popular with those who have tried it.
Oh, I agree with what you've said, but I have a very hard time believing people will be porting Linux, OpenBSD or Windows to Erlang any time soon, let alone take advantage of all the capabilities of Erlang. It could be done, in principle, but in practice the codebase is a serious problem. As I mentioned in my submission, one of the previous attempts to change the way CPUs were designed was the Transputer. It died, not because of any flaw in the design (which was superb) but because training everyone in Occam and then converting all the software over was just too large of an obsticle to overcome. And the volume of code in the 1980s was nothing like the volume of code that exists today.
There are many types of error correction codes, and which one you use depends on the nature of the errors. For example, if the errors are totally random, then Reed-Solomon will likely be the error correction code used. CDs use two layers of Reed-Solomon concatenated in series. This is not especially fast, but the output for a CD is in tens of kiloherts and an ASIC could easily be operating in the gigahertz realms. However, when you're talking the internals of a CPU, there's a limit to how slow you can afford things to be.
BCH is a general form of Reed-Solomon and you can therefore tailor the function to handle specific characteristics of the sorts of error observed rather than trying to code round anything that doesn't fit perfectly within Reed-Solomon. Although it's more general, it might actually be quicker if you can find parameters that better describe what it is supposed to be correcting than the default values used by Reed-Solomon.
Turbo codes (as used by NASA for modern deep-space communication) are great when you're dealing with block errors. In long-distance communication, your biggest problem will be bursts of interference rather than the random noise. Wikipedia states: "Turbo codes, as described first in 1993, implemented a parallel concatenation of two convolutional codes, with an interleaver between the two codes and an iterative decoder that would pass information forth and back between the codes." It goes on to state that this is faster than any previous concatenation scheme. Fast is good, here, but it is only meaningful if this is the sort of error experienced.
There are plenty of other sorts out there, and again there may well be error correction codes not listed above that are much better suited to this specific type of problem.
For this, I'd point to the RISC vs. CISC debate. RISC programs took many more instructions to do the same things, but the gain in performance was so great that you ended up with greater performance. Extra steps = some amount of overhead, but so long as the net gain is greater than the net overhead, you will gain overall. The RISC chip demonstrated that such examples really do exist in the real world.
But just because there are such situations, it does not automatically follow that more steps always equals greater performance. It may be that better error-correction techniques in the hardware would handle the transmission errors just fine without having to alter any software at all. It depends on the nature of the errors (bursty vs randomly-distributed, percent of signal corrupted, etc) as to what error-correction would be needed and whether the additional circuitry can be afforded.
Alternatively, the problem may in fact turn out to be a solution. Once upon a time, electron leakage was a serious problem in CPU designs. Then, chip manufacturers learned that they could use electron tunneling deliberately. The cause of these errors may be further electron leakage or some other quantum effect, it really doesn't matter. If it leads to a better practical understanding of the quantum world to the point where the errors can be mitigated and the phenomenon turned to the advantage of the engineers, it could lead to all kinds of improvement.
There again, it might prove redundant. There are good reasons for believing that "Processor In Memory" architectures are good for certain types of problem - particularly for providing a very standard library of routines, but certain opcodes can be shifted there as well. There is also the Cell approach, which is to have a collection of tightly-coupled but specialized processors of different kinds. A heterogenious cluster with shared memory, in effect. If you extend the idea to allow these cores to be physically distinct, you can offload from the original CPU that way. In both cases, you distribute the logic over a much wider area without increasing the distance signals have to travel (you may even shorten the distance). As such, you can eliminate a lot of the internal sources of errors.
It may prove redundant in other ways, too. There are plenty of cooling kits these days that will take a CPU to much lower temperatures. Less thermal noise may well result in fewer errors, since that is a likely source of some of them. Currently, processors often run at 40'C - and I've seen laptop CPUs reach 80'C. If you can bring the cores down to nearly 0'C and keep them there, that should have a sizable impact on whether the data is being transmitted accurately. The biggest change would be to modify the CPU casing so that heat is reliably and rapidly transferred from the silicon. I would imagine that you'd want the interior of the CPU casing to be flooded with something that conducts heat but not electricity - fluorinert does a good job there - and then have the top of the case to also be an extra-good heat conductor (plastic only takes you so far).
However, if programs were designed with fault-tolerence in mind, these extra layers might not be needed. You might well be able to get away with better software on a poorer processor. Indeed, one could argue that the human brain is an example of an extremely unreliable processor whose net processing power (even allowing for the very high error rates) is far far beyond any computer yet built. This fits perfectly with the professor's description of what he expects, so maybe this design actually will work as intended.
Absolutely true. When the Square Kilometer Array (eventually) comes online, it will be possible to directly observe any exoplanet Earth-size or larger at a distance of 1 AU or greater from its sun at a distance of 100 LY from Earth, provided it is not perfectly reflective or perfectly dark within the range of frequencies being looked at. (If there's even one absorption line, the planet will be visible.) With the current design, at the limits given above, the head of the SETI Institute has stated that such a planet would resolve to one pixel. (That particular talk was fascinating, BTW.)
However, consider that most radio telescope arrays have nothing like that collecting area, nor do they have anything like the effective dish radius. Most radio telescope arrays simply can't directly observe exoplanets at any significant distance. This is why indirect observation and indirect measurements remain the norm.
Basically, yes. It's a great way to make money (in this case, the telecos can charge both the user AND the site - twice the money for half the service) and it is extremely effective for things like iPhone apps and television. People really are willing to pay more in order to get less.
Well, yes, round-robin works too.
One reason I didn't mention it is that it completely skipped my mind, but even if it had, I'm getting used to people picking holes in any argument. Hey, that's not necessarily a bad thing and is often quite valuable, but it means that on "hot button issues" I get extra-careful and make absolutely certain that there exists a solution that would provably and verifiably work for the problems the backbone providers claim to have, that there are no weird corner-cases that would allow the problem to persist or create whole new problems, and is already in actual use (either in part or in whole) somewhere, so that it can't be labeled wild speculation.
So, yes, the solution I suggested was probably excessive, but it would work and work just fine at Internet backbone speeds and would also ensure that machines do not transmit excessive material that will either timeout or otherwise be dropped.
The point is less whose scheme would be "best", but rather that a scheme exists at all. How much does it cost to enable features that are already built into a router or switch? Compared to lobbying several hundred politicians, practically nothing. Lobbying, though, is expensive. And guess who gets to pay for it? Flipping a configuration bit requires testing, sure, but much LESS testing than would be required for firewalling or by-network bandwidth throttling. Testing also costs.
If a scheme - any scheme - exists that would be simpler, cheaper, more efficient and more practical than that offered by the telecos, then that becomes the rational scheme to implement for everyone. The telecos gain, the Government gains, the consumers gain -- the only ones who lose are the ones who want to abandon network neutrality for the purpose of controlling interstate commerce and/or controlling views contrary to their own.
(Interstate commerce? Sure. Throttle back, or block entirely, the IP range owned by a vendor and that vendor ceases to exist. The vendor will be forced to pay protection money to the ISPs in an entirely legal racket.)
Let's look at this list.
Ok. How is telling people that they have to play fair a "power grab"? Surely, the strongest you can say is that this is a denial of a power-grab by the corporate sector.
Ending up an over-reaction? Uhhh, network neutrality has been the accepted practice since the Internet was invented. Imposing the status quo means that there is no reaction. It is enforced non-reaction.
Costs will go up? Why? The status quo is network neutrality. The prices are what they are BECAUSE of network neutrality. Corporations imposing controls WILL raise prices (as in the case of the RIAA - you think CDs cost $10 to make?) but doing nothing will, at most, not alter prices at all.
Civil Rights? I'd say that Tea Partiers being able to control what you see at the network level and being able to impose ABSOLUTE dictatorial power with no possibility of redress is a MAJOR civil rights violation. You are making the corporations Gods, because nobody - not even the Government - will be able to communicate without the express permission of corporate dictators.
Businesses die? Like I said, this is about mandating the status quo. If businesses couldn't survive in the very environment they were designed for, what makes you think they'd survive in a hostile world where major corporations can simply block them out of existence? (Once network neutrality goes, the gloves will come off. Active, malicious blocking of competitors for the purpose of sabotaging and killing them WILL be the norm.)
Giving the mega-corps the power to simply disconnect rivals would certainly leave them living like kings. Preventing any corporation from doing so will eliminate such power games.
People will get hurt? Sure. If there is a bid by wannabe-dictators to seize power over the information you are permitted to see, and the Government denies then that power-bid, people probably will get hurt. Dictators almost always resort to extremes to get what they want. The Government hasn't a great track-record either, but the Tea Party is the one using a vocabulary of violence and extremism. Sure they have freedom of speech, but what gives them the right to rob me of mine?
Because if Network Neutrality goes, the companies get to censor you. They get to censor anyone they feel like, and there's not a damn thing the Constitution will do for you. It only applies to the Government, not private companies. If there's no Network Neutrality, the regional provider will tell you where you can and cannot shop. So you change provider, right? Wrong. There's not much in the way of competition at tier 1 and you don't get to pick what tier 1 your ISP uses. Besides, with much of the redundancy cut out of the Internet as it stands, there IS no way for you to circumvent such restrictions. Oh, and that means that if one backbone provider blocks vendor X, then vendor X will be essentially blocked from ALL backbone vendors downstream of that location. A puritanical backbone provider in one State can impede the commerce in another.
Sure, sure, the providers claim they can't handle the sheer volume of Internet traffic and some small fraction of users use most of it. They can use QoS. ECN, Hierarchical Fair Service Curve and an adaptive packet-dropping scheme like BLACK would be sufficient. (There are a number of schemes, including BLACK, that are designed to prevent packet streaming from clogging up the network. ECN messaging allows the network to tell servers and clients when they need to throttle back. HFSC ensures that nobody can game the system and take unfair advantage of the resources.) This would not be contrary to Network Neutrality, as it ensures that all users are treated absolutely as equals. The networks would be true Common Carriers, rather than Mafia bosses.
Oh, and that reminds me, have you considered that when the RIAA and MPAA started to form and seize power, there were probably people - in all innocence - saying that the industry should take care of itself, that interference would cause problems, that the corporations needed all this extra power for the benefit of the poor, starving artists. Given that the money collected by the RIAA and MPAA never gets seen by said artists, and no serious opposition to this exists, do you seriously expect me to believe that the ISPs and backbone providers will spend the money they rake in through the ultimate protection racket will ever get seen by the poor, starving engineers? Give me a break. You'd have to be insane.
But Chrome is a soft metal. You want Tungsten, if you're going in that direction. Since it's now fashionable to design web browsers in a layered fashion, Graphene might actually be the better bet.
There is almost no way you can really avoid that. Ultimately, once you publish data in a standard format, it is out there. That means that anyone can extract the data and re-present it, embed it in some other content, or indeed do whatever else they feel like.
If a site wants to deep-link and regurgitate badly enough, it's quite capable of running through the entire target site, locally caching the results, and embedding the cached version. This bypasses all protections, but would only work with content that had no controls of any kind beyond straight HTML links. For real-time, just have a spider do all the wandering through the site to the target page. That bypasses any server-side protections automatically, as a "user" is indeed going through all the prior pages - they're just never presented to a human user. I/O is then proxied through the spider, so the remote site sees the spider and treats it as a legitimate user. So long as the spider knows how to get from A to B, when a link on the page does not actually exist, you can simulate the user's navigation. To the user, it's deep-linked. To the target site, it's valid exploration.
It is unnecessary to actually develop such a bot. It is sufficient to show that it is impossible to protect a site against copying, deep-linking, etc, on the server or on the client. If you want to protect content, you cannot do so using the mechanisms in Javascript, HTML or HTTP.
Yeah, but when the inevitable thieves steal the paintings, they almost always damage them when cutting them out. What you really want is a graviton projector embedded in the wall.
"Twain planned to republish every one of his works the moment it went out of copyright with one-third more content, hoping that availability of such 'premium' version will make prints based on the out-of-copyright version less desirable on the market."
If he was actually writing that additional content afterwards, he invented Release Early, Release Often.
If the content actually existed and it was a cynical ploy to sell more products, he invented the model Microsoft uses.
In either case, this puts his business acumen over half a century ahead of anyone else. That's genius.
You're perfectly right, it isn't hard to write modular code. There are many things that are not hard that Microsoft only do after a screaming tantrum, two (or more) court cases and a wallop over the head with a large stick. I'd include "thinking" on that list.
Not every webserver, but you do need that level on ever point of access (physical and virtual). So, this would mean the gateway firewall and/or router, plus the web proxy server(s), plus whatever proxy(s) the users used to connect to the outside world. The web proxies should be on a network that can only talk to the webservers and maybe a NIDS. This isn't overly painful because proxies are relatively simple. They don't involve dynamic database connections, they don't need oodles of complexity, the rights needed are very minimal, the kernel can be one that is very minimal. It's far, far, far simpler than securing the web servers themselves.
The web servers need securing, yes, but if your only access is via a proxy and the proxy is locked-down, and potentially insecure services are only run on ports that are internal (ie: not visible to the proxies), then the risks are restricted to vulnerabilities on the web server and any applications it runs. The rest of the system is effectively masked off. If each thread of the web server is running with the minimum privilege required for that thread, you should be ok. If that's not possible to arrange, then use Mandatory Access Controls to effectively raise the privilege required to do anything hazardous to something above what the web server has.
In other words, take the individual aspects of security and break them down into manageable chunks. One box, one chunk. One big nasty in security is the number of permutations you need to consider, but if you've chunked up the security, you reduce the problem in each chunk to just that chunk, and you reduce the problem of the network to the permutations between each chunk. Everything else is a black box.
No matter how complex the situation, you will always be able to draw circles around "islands" of complexity with few interactions between island. By treating each island individually and then the open seas between them as a separate problem, security becomes much easier. In some ways, this is how most physical security works - you protect the points of entry/exit in one way and protect the internal connections separately and distinctly. For a better example of a layered system, consider a castle with a moat/bailiff system for the outer wall and a keep and other fortified buildings on the inside for different tasks. It's not impossible to break in, but it is hard. But it is much easier to build such a system than to adequately fortify each of the interior buildings to the same level of protection as their fortification plus external fortification provides. By extension, continuing to layer should offer better security still - and, indeed, some of the toughest castles to have ever been built had two or more "outer walls". You could probably build one outer wall that offered the same level of protection, but at vastly greater effort and with all the risks the extra complexity creates.
They had nine suicides and eight fatalities. If they've got undead zombie employees wanting to jump off the roof, restricting access isn't going to do a lot of good.
I don't know what they do to them, but since they have had nine suicides and only eight fatalities, it probably involves necromancy.
True, XOR is the fastest operation, and One-Time Pads use XOR and nothing else. However, short of you and the other person using radio telescopes to obtain a common intergalactic source of randomness (and, yes, that is seriously done), you need to take account of the time (and space) needed to store pads large enough and the encryption time (which can't use a One-Time Pad) taken to securely transfer it.
Having said that, for B2B, OTPs using an intergalactic RNG would likely be cheaper and safer than using quantum cryptography. It would also be much more practical, as it takes a lot of hardware at the moment to deliver qbits. Also, OTPs can't be broken -at all- if the pad itself is secure, but the vulnerability recently discussed shows that quantum cryptography CAN be broken to the extent of being partially readable.
To use a common radio source, all you need is a common starting point and a common target. Aluminum atomic clocks have an error of 8.6e-18 of a second. (This makes it a 1.1 Petahertz clock, rather better than the clock chips we're typically using.) That should be good enough to get some excellent randomness from just about any source out there and insure that both collection systems are in-phase.
Consider that one of the biggest area of vulnerabilities is social engineering. If you trust the person behind the till (about whom you know nothing) to hand you a legitimate public key (which, without a third-part, you can't verify), then fine and good. On the other hand, if that same unknown (who might easily be a social engineer who has bluffed his or her way to the counter) hands you a fake key and you CAN verify it by verifying that it has been counter-signed by someone you independently trust, THEN you have a lot more confidence in that key. You aren't dependent on the person being legit because they said so.
High-end Amigas used the 68040 and 68060 processor - which, IIRC, is quite capable of running Linux.
zlib is ok, but other people use szlib or other compression libraries. Huffmann encoding as a form of compression is block-based, zlib is stream-based. These are essentially also the only two types of encryption, as far as data transfer is concerned.
However, most OS' already have the concept of block devices and stream devices. In the same way that a program that operates on a streamed input and/or streamed output doesn't care what the input and/or output actually is, it shouldn't matter if the device/filter they go through is a crypto channel, a compression channel or the English Channel.
In terms of block encryption, you also need to define the encryption mode used. This, too, is nothing more than a component that has an input pipe and an output pipe. It should be pluggable. There is no logical reason for it not to be. Different block cyphers are defined for different block sizes and may have other specific restrictions and/or specific tunable options besides, but provided the I/O API allows you to use standard calls to interrogate and/or set parameters, and provided standard mechanisms are used to prevent the user from mis-matching options, this should not be a big deal.
This means that existing calls for files, sockets, messages, or what have you, could use pre-existing APIs with minor extensions to defined constants to let you have a completely standardized method of tweaking parameters and getting error codes.
If you'd rather use a library and not overload any pre-existing API, it should not be that difficult to stick to very standard methods.
You are right - this is 50% of the problem here. The other 50% is MS just being lazy.
Well, yes. If the IT managers can't tell the difference between Caesar cipher and AES, then it is arguably lazy to use Caesar. Mind you, less work done for the same income from sales equals more profit. And in a world (and stockmarket) driven by profit margins, voluntarily cutting those margins makes no business sense. (It's why the highest-risers in the stockmarket are also the high-risks and also the ones tied to companies most likely to suffer disasters that seriously impact - or in some cases kill - others. Not sure about the US, but in the UK these are sometimes referred to as the Dogs. They can run fast but they can also turn and bite.) Microsoft did not become one of the richest companies in the world by cutting margins. Yes, it is lazy in an intellectual sense, but Microsoft isn't aiming at intellectuals.
DES is sufficiently weak that it is possible to build a home-grown cluster that can break a DES key in minutes. Yes, DES is "strong" in the sense that the algorithm itself has no significant flaws that anyone can detect, but when dealing with a credit card system where it's quite plausible that each card could have a thousand dollars available on it on average, obtaining 500 cards would cover the cost of the EFF's DES-breaking machine and therefore cover the costs. Everything else would be sheer profit for the crook(s). Given that news stories on credit card theft usually talks about hundreds of thousands of cards being stolen, the cost of smashing DES would be 0.1% of the money the criminals could walk off with. In short, as close to nothing as to make no odds.
If the cost of smashing 40-bit or even 56-bit encryption is insignificant, then there is no practical difference between DES and ROT13 at the kind of level of sophistication you'd require to even steal from that many cards without being caught or detected. This leaves you two options - spend less money and superficially meet requirements (and then hope like hell), or spend more money to invest in doing security correctly. Hands up all who know IT managers who enjoy spending money on things that don't (in themselves) offer any return because it is Doing The Job Right. Ok, now hands up all those who know IT managers who take shortcuts to meet business requirements or upper-level management demands even though they know it's probably risky and/or bloody stupid to take those shortcuts?
My guess is that the vast, overwhelming majority raised your hands on the second question and that maybe a few dozen (at most) did so on the first. I also suspect that anyone who questioned my original post would actually agree that IT managers aren't known for Doing The Right Thing when it comes to IT security, that cost and the performance needs of everyone else take first and second place (order depending on where you work). In short, outside threats are likely to be considered rare and more likely to affect underlings than the manager, whereas office politics is a constant and immediate danger with backstabbing and dirty infighting being the norm. You may well be in a place that isn't like that, but if so, I defy you to seriously claim (and prove) that your situation is remotely close to typical.
Even ignoring the treachery that makes up the modern workplace, you still have the Peter Principle to contend with. If you have an IT manager who is experienced at being an IT manager, the principle dictates that this means he has risen to his level of incompetence. Again, there will likely be exceptions, but I'm talking the typical case here.
So, if the typical IT manager is stingy and/or incompetent, thus defining this to be the primary business market for Microsoft, this will be the sort of person Microsoft products will be aimed at. Microsoft is lots of things, but stupid about their customers they are not. If they ship a flaky product, it is because they know the customer won't care and/or won't notice, but will buy it anyway. Hell, Vista for the desktop probably still made a sizable profit despite the complaints and the effective abandonment.
Ok, what if you applied the logic from Hitch-Hiker's Guide to the Galaxy that currency is a figment of the imagination?