Some such displays are to get attention by being more outrageous. Others are an indication of physical health or adequate nutrition. A stunted wing might well have indicated that an animal was in trouble, and oversized wings might well have been much more attention-grabbing. With only a single fossil to go by, it's hard to tell anything, but I think you might very well be right, if this is a representative example.
(It could equally well have been a freak one-off mutation that was wholly incapable of propogating further. Given the low probability of fossilization that would seem unlikely, but given the very high number of fossil collectors, if such an animal did fossilize, it would likely be found sooner or later.)
Who the hell used edlin? Blackbeard was a full-screen editor with a very reasonable set of control codes to do things, though Turbo Pascal 3's editor was probably the best of the best for the time.
You are correct that the overall logic is complicated, but in the end ANY series of decisions can be reduced to an n-ary decision tree (which you can provably test, one decision at a time) which can then be folded up into a graph (ie: more than one path exists between point A and point B, for at least one pair of points). If the tree was validated as correct, and the graph is simply an optimized representation of the same structure, the graph must also be correct.
Note: I'm not talking about a rules engine or expert system shell - which would be painfully slow and very hard to follow, but a complete writing out of the rules in such a way that one code block can only be entered by exactly one path through the decisions.
So what you do is you start with something that is valid but slow, then optimize it without changing the overall logic. This is considered "good programming" practice anyway, as optimizing too early can lead to sub-optimal code because you hide what may be become better possibilities. (It's slow because we've not considered the sequence of decisions, we've not considered early break-outs and we've not considered the frequency of differing cases. However, because it's flattened, it'll be faster than most of the procedural code out there. The biggest problem is that it would, well, be big. Very big.)
Now we get onto malformed packets, optional parts, and the like. Yes, this does make things a lot more complicated. The optional parts less so, as those can still be represented by a well-defined set of decisions. It's the malformed packets, packets that are not strictly inside the specification but should be allowed anyway, that are the problem. You can't apply if/then logic if you don't know what the 'if' should be, or necessarily which 'then' is the most applicable. The best I can see here is to split into four types of malformed packet. The first needs to be done early, the other three should be treated as rogue optimizations.
if (x) then (branch)
if (x | x') then (since this is always true, eliminate if and else)
if (x) then (automatically accept)
if (x) then (automatically reject)
The example with e-mail is well-taken. Yes, there are MANY ways to write the same e-mail address, if you include ! notation, multiple levels of @, comments, etc. Again, the overall complexity is provably very high, but the individual rules for handling each case encountered are all relatively simple, particularly if the complexity is caused by nesting, as you don't need to worry about anything at a layer deeper than you need to parse to deliver the mail. Parsing the address to find what you need, though, is (overall) a complex task that requires a fair amount of processing.
With packet validation, again the point that processing needs to be blazingly fast is well-taken. It does need to be blazingly fast. 100 MB/s cards are the standard, with gigabit moving into the mainstream and ten gigabit on the fringes. Any stack that chokes on the standard isn't going to be of much use to anyone, and ideally you'd want it to run fine on the standard-to-be. Validation is expensive, so you want to apply as little as you can, but many errors downstream are likely to be at least as expensive as the validation that would have prevented them.
Assuming we are applying the method of validate early/optimize late, then once we have validated the code, we would want to optimize it as much as possible. Now, code size isn't that important here - smaller code is generally more structured and will therefore often run slower. We're wanting here to make it run as fast as possible. The first thing to do is to decide if we're going to have to allow certain malformed paths. If we're allowing A and A' to have identical results then A can be optmized out entirely. You only need the test if the paths for A and A' differ.
You also want to reorder the decisions. If A' is a common case that MUST lead to
The network stacks that exist for, say, BSD and Linux are rather more convoluted than I would have thought necessary. I believe they could be made a lot simpler and faster, without sacrificing one iota of capability, flexibility or configurability. In fact, there may well be areas where reducing complexity will increase flexibility. That happens.
It should be very easy to build a networking stack for Windows (or any other OS) that is bullet-proof, compact and fast, because it's not a particularly complex piece of logic. There are lots of rules, sure, but each rule within itself is very simple. That makes it possible to test each decsion-making component directly and individually, along with the rule that component applies. Because you know what a well-formed packet looks like - that is defined by the applicable RFC(s) - you can also do comprehensive bottom-up integrated testing.
Add in one of the multitude of profiling packages that will work with kernel-level code, and it should be child's play to make the code not only correct but damn fast.
Could Microsoft do this? Of course they could. They might act the part, but that doesn't make them idiots. In general, anyway. How long it would take and how much manpower it would take depends on how correct they'd want the code. If you want to guarantee fewer than N errors per M lines of code, you can do it, but halving N will more than double the effort required. Can you guarantee no errors at all? Yes. The networking stack is simple enough that you can prove it complete, sufficient and correct. It would cost Microsoft far less to prove their network stack totally bug-free than they're owing the EU in fines. Personally, I feel that producing better code would have been a wiser investment, but that's their decision to make.
could Linux developers do this? Again, sure. There are many tools for profiling and analyzing the Linux networking stack, and suitable test harnesses shouldn't be that hard to write. If kernel hackers had more of a liking for testing, Linux networking bugs should be all but extinct within a year. As things stand, the cleanup is OK but not enough to seriously endanger the bug population. I would like to see a concerted effort to clean up the code rigorously, but I do recognize that much of the code is "good enough" for most developers to be more interested in expanding the capabilities than polishing the code to perfection.
First, let's assume for a moment that address space was what IPv6 was about. It isn't, by a long way, but let's assume it was. Would it still be useful? Yes. Why? Because routing sucks using IPv4, that's why. An address of w.x.y.z could be absolutely anywhere on the Internet. The backbone routers on the Internet need a router table entry for every friggin' block of IP addresses whose next hop cannot be inferred from the broader IP block. With CIDR, this problem is actually a lot worse, as you can't simply say that some C-class network is in that general direction. Any of the subnets could be absolutely anywhere. You don't know if 130.88.12.118 is a machine inside the 130.88.12.x network - it might just as easily be off the 131.23.42.x network. But the router for 130.88.x.y might be off 132.79.42.y, so you can't pass the packet to the router for the general case, you have to pass it to the router for the most specific case. Because many routers don't allow netmasks with "holes", you could in theory end up with router tables with up to 512 million entries with no efficient method of searching it. You have to check the destination against every entry + netmask for the most accurate match.
IPv6 mandates hierarchical addresses. In fact, if you use automatic address assignment, you don't get a choice. Every router WILL have a subgroup of the parent's IP block, and every IP address WILL have a prefix that matches the host router's prefix. This means that routers can largely dispense with routing tables. If the prefix matches the prefix of the router, up to the prefix length of that router, it goes on the local network. Everything else goes upstream. If you are on a peered network, you need to add one prefix check per peer. This means that a router with N ports and M tunnels has an absolute maximum of (N + M - 1) prefix tests. On a huge, 256-port router, with no pipes used for redundancy, you're looking at 255 tests.
That's one hell of a difference, when it comes to latency.
Ok, so what are the other differences? Well, IPv6 mandates IPSec. If you comply with requirements, you WILL use encrypted connections. So, sure, the Government can mandate that ISPs send them all the traffic. Let them. Give them all the triple-DES or AES-encrypted streams they like. Won't do them much good. From a privacy standpoint, IPv6 is about as good as it gets. Even the UK's requirements of handing over encryption keys if there is a reason to believe you have them is of no use - IPSec is opportunistic, per-unit of time, per-session. You don't know the keys, you have no reason to, and most Operating Systems won't let you have them even if you did want them.
Mobility. IPv6 mandates mobility for computers AND for networks. IPv4 - well, it's possible but (a) both providers need to support it, and (b) routing won't be optimized. Ever. With IPv6, upstream routers become aware of your move and the routing becomes corrected over time. You don't need cooperative ISPs, it's built-in. It will simply work.
Zeroconf. Again, you can do this with IPv4 - if the ISP (or network admin in a corporation) is feeling uber-generous. With IPv6, zeroconf is the norm. You can use DHCPv6 if you really want, but you're not stuck with it.
Multicast. This has existed within IPv4 for many decades, but the bloody ISPs won't enable it in their routers, so you can't use it. This is sheer bloody-mindedness on their part, as multicast doesn't place a greater strain on their networks. It would actually reduce it something fierce. It doesn't require any additional effort on their part, other than to enable PIMv2 on the upstream and downstream connections. Everything else is automatic, as multicast has been natively supported on the backbone for at least a decade. Two settings. Two tiny, insignificant settings, and they could cut network traffic at peak times by an order of magnitude.
(FTP-over-multicast exists. I'm sure bittorrent-over-multicast would be doable, if it hasn't been done alrea
Virtually the only thing I have heard from Sir Clive Sinclair that made me stop and think "that is so utterly the way to do it" was when he proposed wafer-scale architecture where, instead of relying on everything working, you design it with the idea that some components will be bad at the start, and others will fail when in use. He did this by proposing that the selection of which element to use support the notion of bad elements which the selection hardware (or software) simply ignores.
If you did this with the cell architecture, you'd get many chips with fewer than 8 coprocessors, but I'd expect the yields to be closer to 60-70% at some level of function. Why sell bad chips? Because not everyone needs that level of compute power, even for games. Because the demonstration of graceful fault tolerence will make the chip very appealing to the military and space industries. And because using bad chips is standard practice when building cheap systems.
Oh yeah, caching would get really fun. Sixteen physical streams hooked together as eight physical processors hooked together as a single virtual processor, hooked to a common cache. You're definitely talking about a heavyweight caching system, especially as the dropping algorithm can't rely on presumed behaviour of a single processor. I'd have to think about that one. Finding anything in the cache would be equally hard.
My excuse there is that evolutionary computing is slow. Revolutionary designs can do in a single year what evolutionary methods can do in a decade. If you're going to invest oodles of cash into a design that alien, you might as well make it truly revolutionary. Otherwise, it won't have enough of an advantage. A slight edge in a market simply isn't going to last long enough or sell enough to cover the costs.
Not sure it's that complex. If anything, it sounds rather limiting. Eight isolated physical coprocessors, each supporting two threads? Why not have one coprocessor that supports 16 threads that maps onto as many virtual coprocessors as desired? Basically the same circuitry, but can dynamically remap to the problem being solved, as opposed to remapping the problem to the circuits provided.
(Having the computer model itself to the problem reduces the complexity of programming and will make optimal use of the hardware. Having the program model itself after what the computer is tuned to do is merely an ugly hack and requires ugly compilers to specifically translate between the paradigms.)
The cell processor is designed around 1980s concepts of load-balancing while keeping to many of the rules of second-generation programming. Technology has moved on. That's not to say the cell is bad. It's a definite improvement over the 1960s concepts used in many modern CPUs. However, it is still 20 years behind the curve. C'mon, guys, this isn't the Space Shuttle, it's a microprocessor. There is no excuse for network and design technology to be so far beyond the best of the best that industrial giants are capable of doing.
Actually, it's worse than that. Modern multi-processor systems require specially-designed chipsets and become exponentially more expensive as you build them up. Single boards don't usually go beyond 16 processors. In comparison, people built single boards with 1024 Transputers without difficulty, with costs increasing linearly. So, in multi-processor architectures, we can't even match everything that could be done in the 1980s.
How does this affect those using the Cell? Well, that's simple. It doesn't offer enough of an added advantage and is different enough that coders will have difficulty making good use of it. That means that coders will have to be inefficient OR dedicated to that one chip, which has no guarantee of making any money for them. Coders won't bother, unless there is something out there that will make it a guaranteed success. I'm not seeing this killer demo.
The BBC burned its copy of the moon landing recordings in the 70s, along with the vast majority of its black and white archive. "Why" depends on who you ask and when you asked them. Oh, they weren't terribly careful about putting reels in the right cans, and nobody seems to have thought to have checked, so they lost a lot of early colour material as well. Virtually all of their early material in their collection has been provided by bootleggers. (The many assorted independent TV stations in Britain are endlessly destroying historic recordings, only to plead with viewers to send in bootlegs and stolen tapes a few years later, when they realize that the stuff is (a) historic and (b) valuable.)
That the National Archives in America is just as incapable of looking after its material is depressing. They're only getting round to looking for the tapes now? Ok, so they're limited in money, so prioritize! Digitize the stuff that's utterly unique FIRST. They might still have found it stolen, but at least they'd have found it stolen around the time the theft happened, and have half a chance of recovering it. Right now, recovery is almost certain not to happen and even if they did, there won't be anything capable of extracting the information by the time they do.
Most aircraft of the time used a wheel on a column. If you look at WW2 movies, the smaller fighters used a simple joystick, but anything larger used more sophisticated controls. So you are correct that he may well have been inspired - I can easily believe that - and that prior art certainly existed, I would argue that it was not universal and had largely gone out of fashion. As such, I would very much like to know why he went with such a retro design. They're not robust and if cheaply made (which most are) the wires and soldered connections are extremely fragile.
However, design them he did, and he must have had his reasons. I would love to know more about his thought process.
Yeesh, you need to put a different spin on it. Besides, we all know you merely lepton this thread to post someting strange. Oh, incidently, quantum cats muon and on.
At the moment, it's impossible to identify Citrix streams except in the generic sense of being Citrix. And even then, documentation is inconsistant. (TCP port 1494 is well-known, but there are also vague references to UDP port 1604, but what this does seems to be unknown.)
Why is this important? Because Citrix is a network hog. Running multiple Citrix instances via VMWare is going to seriously kill the network card - if not the network - unless you can isolate the traffic of greatest interest. Since these are different instances, you can't even rely on the built-in Citrix controls to give meaningful information or bounds.
At present, Linux' netfilter is capable of tagging by the contents of the payload, but I have been unable to find any work on how to use this to get the best from Citrix. The only information I have found was a program for finding what Citrix apps were being published - and that was under a security advisory! You'd have thought something like that would be circulated as a utility, but noooooo...
Has anyone here done much with QoS'ing Citrix or analyzing their protocols?
The stresses involved are gigantic and the tolerences are therefore extremely narrow. That alone does not make rocketry a trivial task - assuming that you use a rocket for these sorts of things. (It's entirely possible to replace the first stage of any rocket with some sort of assisted ramjet. Ramjets aren't trivial either, but they allow much wider tolerences and use less fuel. All you have to do is get airflow to 400mph - a gas cannon or adding a high-speed fan to the ramjet is quite sufficient to do this.)
Assuming you do want to go 100% rocket, though, you'd obviously want to over-engineer the rocket as much as you can. Instead of building a rocket that can just handle what you'd expect, you want to build a rocket that has a wider margin of safety. You'd probably want to launch a whole bunch of rockets laced with sensors to figure out just how wide the margins need to be.
You'd also want to have something that self-corrects. Having rockets self-destruct on you is expensive. If a rocket flies off-course, then it would seem likely to be the guidance system or the rocket nozzle. Backup guidance systems would seem cheaper than new rockets, even allowing for the fact that the extra weight will require more fuel. (I'm sure plenty of top-of-the-line rockets do, in fact, have such backups - it's just not very likely that too many budget launchers do.) A backup nozzle would be tougher, but not impossible - it's just a question of symmetry. Even if you can't self-correct, having a means of ejecting the payload safely so you can recover it and try again is a damn-sight cheaper than rebuilding such modules from scratch.
Of course, rocket scientists aren't stupid. Often underfunded for what they try to do, yes, and in an economy that emphasises cheapness over quality, shortcuts are inevitable. The Russians seem to prefer recycled ICBMs over their Soyuz systems, even though the Soyuz seems to be a lot better built, can certainly carry more, are probably newer, and probably carry fuel that is fresher. Why? Because the missiles are cheap and they've got plenty they can waste. They're not being used for anything else and they're already built, so there's almost no cost in refurnishing them.
India really doesn't have many half-decayed rockets, but the problems come from the same cause - very little money being spent to complete a very difficult task, in the knowledge that this is money they'd need to burn on rocket R&D anyway, if their nukes are to be useful. They're getting paid to do the stuff they'd have to do anyway. The telecos can't really afford to go elsewhere, so they've a captive market that has no practical alternative but to buy their products. They have every reason to experiment, play with ideas, try things out, and none at all to build something that's reliable out of the box.
(Experimentation is great, when it comes to new tech, but it should be done honestly and not at the expense of customers. And in this case, where pure rocket solutions are not regarded as particularly a good way to do things, it's experimentation in technology that has no value. We're at the point where newcomers to space rocketry using rockets for the first stage are being as sensible as corporations hacking the CERN webserver to run on CP/M, and getting CP/M to run on a PDP-8. Neat, sort-of, but utterly pointless and far from the neatest thing you could do with the same amount of effort.)
Have you ever seen the paperwork for a secret clearance? Yeesh! They want everything - and I mean everything - for the past 5 years. 7 if it's top secret. IIRC, the form not only asks about you, but also about your relatives, your friends, your bosses... They'll randomly track down and interview former neighbors. Those applications are thorough. Stupid but thorough. If you're dual-citizen, it can take two years plus for them to process the paperwork, they're that paranoid.
So what would said paranoid individuals do, when confronted with a blocked personal site? Ignore it? Yeah, right. I don't agree with what they look for - it seems questionable as to whether it has any relevance to whether the individual can be trusted - but it's blindingly obvious they'd investigate obviously hidden data.
For "confidential" clearances, the rules are different. There, a fingerprint check with the FBI and a routine background check seems to be sufficient. That can take a week or two, but it's nothing like as extreme.
...is that Closed Source vendors have opposed Open Source "in the national interest" and "for reasons of security" for some time now. Regardless of whether the DoD ever actually follows through on this, there is now an official statement by the US Government no less that these claims are false. Hey, we've all known that for some time, but ringing endorsements by the DoD don't come by on a weekly basis.
This is the time that Open Source activists and promoters need to run with the ball. Draw the attention of CEOs and business executives to the fact that the DoD advocates Open Source. Show them that we're not talking toy software. Show them that this isn't about not wanting to spend money. (Since when was the DoD afraid to spend money?) This is about an innately powerful method of developing high-grade - even military-grade - products that do what people actually need done.
We couldn't ask for better, but only if those outside of the IT industry actually hear of it. If only those who already accept the strengths of Open Source know that someone else has also decided it is a good solution, then that decision means nothing. Particularly as the DoD is very unlikely to do anything about it. It'll just be a decision. But if the business community got shown this... That would be a whole different ball-game.
Which may not sound like much of an addition to the complexity, but it is nonetheless added complexity. The effort is simply shifted from the rules to the alphabet. To go completely phonetic in English, however, would require 44 letters in the alphabet.
...but the chickens wouldn't know that. Besides, what you really want to do is spin them up, keep them at high speed until ready for the supermarket, then hit the brakes. The bones'll be large enough that you won't get fragments everywhere, it would be painless for the chicken, and I'm certain you could make a fortune selling the slow-motion video to students.
Phonetic spelling existed in England for a long time. Formalized spelling is a very recent invention and seems to have been still very much a "work in progress" even in the 1800s. (I have several books from back then and the spelling could get creative at times.) In the end, it was overwhelmingly rejected by the English. And even when phonetic spelling was in use, both spelling and pronounciation varied wildly. The drift, if anything, was likely worse - regional accents and regional texts would have led to far more bleed-over, as people would have borrowed sounds and spellings in search of better ways to communicate.
There is generalization that can be applied - the fewer letters you have, the more complex the rules need to be in order to express the same number of concepts. Thus, as the rules for English have become more powerful, a lot of additional symbols used historically no longer exist. If you have fewer rules (say, by having phonetic spelling) then you need more characters to compensate. British English has 20 vowel sounds (American English has 17) and 24 consonant sounds. In order to have a "pure" phonetic language, we'd need to go from 26 characters to 44! Anything less would be incapable of literally presenting what was being spoken.
(Well, maybe it's not quite that bad. Most phonetically-written languages, like Finnish or Old Futhark, have around 30 characters, but that's only because multiple sounds can be assigned the same character, depending on context, and multiple characters can represent a single sound in some cases. However, if you eliminate both of those possibilities and go to a purely phonetic system, 30 characters is NOT enough just to cover the sounds in general use today.)
In either case, pity the poor child who has to memorize a 44-character alphabet. Rules can be picked up as you go along, but the alphabet is the basis, the foundation, for everything. You can look up obscure rules, but there is no such thing as an obscure character - particularly as we use most of those 44 phonetic characters in everyday speech. For that matter, can you imagine what it would do to QWERTY keyboards? It would need to be 5/3rds its current size to retain proportions and fit the rest of the phonetic alphabet in. You want to be in a typing class for that? Didn't think so.
Slashdot Mirror
(It could equally well have been a freak one-off mutation that was wholly incapable of propogating further. Given the low probability of fossilization that would seem unlikely, but given the very high number of fossil collectors, if such an animal did fossilize, it would likely be found sooner or later.)
Who the hell used edlin? Blackbeard was a full-screen editor with a very reasonable set of control codes to do things, though Turbo Pascal 3's editor was probably the best of the best for the time.
Note: I'm not talking about a rules engine or expert system shell - which would be painfully slow and very hard to follow, but a complete writing out of the rules in such a way that one code block can only be entered by exactly one path through the decisions.
So what you do is you start with something that is valid but slow, then optimize it without changing the overall logic. This is considered "good programming" practice anyway, as optimizing too early can lead to sub-optimal code because you hide what may be become better possibilities. (It's slow because we've not considered the sequence of decisions, we've not considered early break-outs and we've not considered the frequency of differing cases. However, because it's flattened, it'll be faster than most of the procedural code out there. The biggest problem is that it would, well, be big. Very big.)
Now we get onto malformed packets, optional parts, and the like. Yes, this does make things a lot more complicated. The optional parts less so, as those can still be represented by a well-defined set of decisions. It's the malformed packets, packets that are not strictly inside the specification but should be allowed anyway, that are the problem. You can't apply if/then logic if you don't know what the 'if' should be, or necessarily which 'then' is the most applicable. The best I can see here is to split into four types of malformed packet. The first needs to be done early, the other three should be treated as rogue optimizations.
The example with e-mail is well-taken. Yes, there are MANY ways to write the same e-mail address, if you include ! notation, multiple levels of @, comments, etc. Again, the overall complexity is provably very high, but the individual rules for handling each case encountered are all relatively simple, particularly if the complexity is caused by nesting, as you don't need to worry about anything at a layer deeper than you need to parse to deliver the mail. Parsing the address to find what you need, though, is (overall) a complex task that requires a fair amount of processing.
With packet validation, again the point that processing needs to be blazingly fast is well-taken. It does need to be blazingly fast. 100 MB/s cards are the standard, with gigabit moving into the mainstream and ten gigabit on the fringes. Any stack that chokes on the standard isn't going to be of much use to anyone, and ideally you'd want it to run fine on the standard-to-be. Validation is expensive, so you want to apply as little as you can, but many errors downstream are likely to be at least as expensive as the validation that would have prevented them.
Assuming we are applying the method of validate early/optimize late, then once we have validated the code, we would want to optimize it as much as possible. Now, code size isn't that important here - smaller code is generally more structured and will therefore often run slower. We're wanting here to make it run as fast as possible. The first thing to do is to decide if we're going to have to allow certain malformed paths. If we're allowing A and A' to have identical results then A can be optmized out entirely. You only need the test if the paths for A and A' differ.
You also want to reorder the decisions. If A' is a common case that MUST lead to
It should be very easy to build a networking stack for Windows (or any other OS) that is bullet-proof, compact and fast, because it's not a particularly complex piece of logic. There are lots of rules, sure, but each rule within itself is very simple. That makes it possible to test each decsion-making component directly and individually, along with the rule that component applies. Because you know what a well-formed packet looks like - that is defined by the applicable RFC(s) - you can also do comprehensive bottom-up integrated testing.
Add in one of the multitude of profiling packages that will work with kernel-level code, and it should be child's play to make the code not only correct but damn fast.
Could Microsoft do this? Of course they could. They might act the part, but that doesn't make them idiots. In general, anyway. How long it would take and how much manpower it would take depends on how correct they'd want the code. If you want to guarantee fewer than N errors per M lines of code, you can do it, but halving N will more than double the effort required. Can you guarantee no errors at all? Yes. The networking stack is simple enough that you can prove it complete, sufficient and correct. It would cost Microsoft far less to prove their network stack totally bug-free than they're owing the EU in fines. Personally, I feel that producing better code would have been a wiser investment, but that's their decision to make.
could Linux developers do this? Again, sure. There are many tools for profiling and analyzing the Linux networking stack, and suitable test harnesses shouldn't be that hard to write. If kernel hackers had more of a liking for testing, Linux networking bugs should be all but extinct within a year. As things stand, the cleanup is OK but not enough to seriously endanger the bug population. I would like to see a concerted effort to clean up the code rigorously, but I do recognize that much of the code is "good enough" for most developers to be more interested in expanding the capabilities than polishing the code to perfection.
IPv6 mandates hierarchical addresses. In fact, if you use automatic address assignment, you don't get a choice. Every router WILL have a subgroup of the parent's IP block, and every IP address WILL have a prefix that matches the host router's prefix. This means that routers can largely dispense with routing tables. If the prefix matches the prefix of the router, up to the prefix length of that router, it goes on the local network. Everything else goes upstream. If you are on a peered network, you need to add one prefix check per peer. This means that a router with N ports and M tunnels has an absolute maximum of (N + M - 1) prefix tests. On a huge, 256-port router, with no pipes used for redundancy, you're looking at 255 tests.
That's one hell of a difference, when it comes to latency.
Ok, so what are the other differences? Well, IPv6 mandates IPSec. If you comply with requirements, you WILL use encrypted connections. So, sure, the Government can mandate that ISPs send them all the traffic. Let them. Give them all the triple-DES or AES-encrypted streams they like. Won't do them much good. From a privacy standpoint, IPv6 is about as good as it gets. Even the UK's requirements of handing over encryption keys if there is a reason to believe you have them is of no use - IPSec is opportunistic, per-unit of time, per-session. You don't know the keys, you have no reason to, and most Operating Systems won't let you have them even if you did want them.
Mobility. IPv6 mandates mobility for computers AND for networks. IPv4 - well, it's possible but (a) both providers need to support it, and (b) routing won't be optimized. Ever. With IPv6, upstream routers become aware of your move and the routing becomes corrected over time. You don't need cooperative ISPs, it's built-in. It will simply work.
Zeroconf. Again, you can do this with IPv4 - if the ISP (or network admin in a corporation) is feeling uber-generous. With IPv6, zeroconf is the norm. You can use DHCPv6 if you really want, but you're not stuck with it.
Multicast. This has existed within IPv4 for many decades, but the bloody ISPs won't enable it in their routers, so you can't use it. This is sheer bloody-mindedness on their part, as multicast doesn't place a greater strain on their networks. It would actually reduce it something fierce. It doesn't require any additional effort on their part, other than to enable PIMv2 on the upstream and downstream connections. Everything else is automatic, as multicast has been natively supported on the backbone for at least a decade. Two settings. Two tiny, insignificant settings, and they could cut network traffic at peak times by an order of magnitude.
(FTP-over-multicast exists. I'm sure bittorrent-over-multicast would be doable, if it hasn't been done alrea
If you did this with the cell architecture, you'd get many chips with fewer than 8 coprocessors, but I'd expect the yields to be closer to 60-70% at some level of function. Why sell bad chips? Because not everyone needs that level of compute power, even for games. Because the demonstration of graceful fault tolerence will make the chip very appealing to the military and space industries. And because using bad chips is standard practice when building cheap systems.
Oh yeah, caching would get really fun. Sixteen physical streams hooked together as eight physical processors hooked together as a single virtual processor, hooked to a common cache. You're definitely talking about a heavyweight caching system, especially as the dropping algorithm can't rely on presumed behaviour of a single processor. I'd have to think about that one. Finding anything in the cache would be equally hard.
My excuse there is that evolutionary computing is slow. Revolutionary designs can do in a single year what evolutionary methods can do in a decade. If you're going to invest oodles of cash into a design that alien, you might as well make it truly revolutionary. Otherwise, it won't have enough of an advantage. A slight edge in a market simply isn't going to last long enough or sell enough to cover the costs.
(Having the computer model itself to the problem reduces the complexity of programming and will make optimal use of the hardware. Having the program model itself after what the computer is tuned to do is merely an ugly hack and requires ugly compilers to specifically translate between the paradigms.)
The cell processor is designed around 1980s concepts of load-balancing while keeping to many of the rules of second-generation programming. Technology has moved on. That's not to say the cell is bad. It's a definite improvement over the 1960s concepts used in many modern CPUs. However, it is still 20 years behind the curve. C'mon, guys, this isn't the Space Shuttle, it's a microprocessor. There is no excuse for network and design technology to be so far beyond the best of the best that industrial giants are capable of doing.
Actually, it's worse than that. Modern multi-processor systems require specially-designed chipsets and become exponentially more expensive as you build them up. Single boards don't usually go beyond 16 processors. In comparison, people built single boards with 1024 Transputers without difficulty, with costs increasing linearly. So, in multi-processor architectures, we can't even match everything that could be done in the 1980s.
How does this affect those using the Cell? Well, that's simple. It doesn't offer enough of an added advantage and is different enough that coders will have difficulty making good use of it. That means that coders will have to be inefficient OR dedicated to that one chip, which has no guarantee of making any money for them. Coders won't bother, unless there is something out there that will make it a guaranteed success. I'm not seeing this killer demo.
Cache, not cash.
That the National Archives in America is just as incapable of looking after its material is depressing. They're only getting round to looking for the tapes now? Ok, so they're limited in money, so prioritize! Digitize the stuff that's utterly unique FIRST. They might still have found it stolen, but at least they'd have found it stolen around the time the theft happened, and have half a chance of recovering it. Right now, recovery is almost certain not to happen and even if they did, there won't be anything capable of extracting the information by the time they do.
The Doctor need to buy time? He can make his own, can't he?
Some of the simplest solutions are the best.
"Hallucinating flying windows over water in metal boxes;
Invisible messages are lost with the socks;
Floods of water destroy all life;
As circles of glass turn blue and die"
You work for NASA?
However, design them he did, and he must have had his reasons. I would love to know more about his thought process.
Three rings for the synchotron-kings under the phi,
Seven for the cyclotrons in their shields of stone,
Nine for superconducting supercolliders doomed to die,
One for the CERN Lord in his quark Hadron
In the Alps of Switzerland where the gluons lie.
One Ring to hew them all, One Ring to grind them
One Ring to smash them all and in the black holes slime them
In the Alps of Switzerland where the gluons lie.
Yeesh, you need to put a different spin on it. Besides, we all know you merely lepton this thread to post someting strange. Oh, incidently, quantum cats muon and on.
With VMWare, you can have more than one overlord in the same body at the same time!
Why is this important? Because Citrix is a network hog. Running multiple Citrix instances via VMWare is going to seriously kill the network card - if not the network - unless you can isolate the traffic of greatest interest. Since these are different instances, you can't even rely on the built-in Citrix controls to give meaningful information or bounds.
At present, Linux' netfilter is capable of tagging by the contents of the payload, but I have been unable to find any work on how to use this to get the best from Citrix. The only information I have found was a program for finding what Citrix apps were being published - and that was under a security advisory! You'd have thought something like that would be circulated as a utility, but noooooo...
Has anyone here done much with QoS'ing Citrix or analyzing their protocols?
Assuming you do want to go 100% rocket, though, you'd obviously want to over-engineer the rocket as much as you can. Instead of building a rocket that can just handle what you'd expect, you want to build a rocket that has a wider margin of safety. You'd probably want to launch a whole bunch of rockets laced with sensors to figure out just how wide the margins need to be.
You'd also want to have something that self-corrects. Having rockets self-destruct on you is expensive. If a rocket flies off-course, then it would seem likely to be the guidance system or the rocket nozzle. Backup guidance systems would seem cheaper than new rockets, even allowing for the fact that the extra weight will require more fuel. (I'm sure plenty of top-of-the-line rockets do, in fact, have such backups - it's just not very likely that too many budget launchers do.) A backup nozzle would be tougher, but not impossible - it's just a question of symmetry. Even if you can't self-correct, having a means of ejecting the payload safely so you can recover it and try again is a damn-sight cheaper than rebuilding such modules from scratch.
Of course, rocket scientists aren't stupid. Often underfunded for what they try to do, yes, and in an economy that emphasises cheapness over quality, shortcuts are inevitable. The Russians seem to prefer recycled ICBMs over their Soyuz systems, even though the Soyuz seems to be a lot better built, can certainly carry more, are probably newer, and probably carry fuel that is fresher. Why? Because the missiles are cheap and they've got plenty they can waste. They're not being used for anything else and they're already built, so there's almost no cost in refurnishing them.
India really doesn't have many half-decayed rockets, but the problems come from the same cause - very little money being spent to complete a very difficult task, in the knowledge that this is money they'd need to burn on rocket R&D anyway, if their nukes are to be useful. They're getting paid to do the stuff they'd have to do anyway. The telecos can't really afford to go elsewhere, so they've a captive market that has no practical alternative but to buy their products. They have every reason to experiment, play with ideas, try things out, and none at all to build something that's reliable out of the box.
(Experimentation is great, when it comes to new tech, but it should be done honestly and not at the expense of customers. And in this case, where pure rocket solutions are not regarded as particularly a good way to do things, it's experimentation in technology that has no value. We're at the point where newcomers to space rocketry using rockets for the first stage are being as sensible as corporations hacking the CERN webserver to run on CP/M, and getting CP/M to run on a PDP-8. Neat, sort-of, but utterly pointless and far from the neatest thing you could do with the same amount of effort.)
So what would said paranoid individuals do, when confronted with a blocked personal site? Ignore it? Yeah, right. I don't agree with what they look for - it seems questionable as to whether it has any relevance to whether the individual can be trusted - but it's blindingly obvious they'd investigate obviously hidden data.
For "confidential" clearances, the rules are different. There, a fingerprint check with the FBI and a routine background check seems to be sufficient. That can take a week or two, but it's nothing like as extreme.
This is the time that Open Source activists and promoters need to run with the ball. Draw the attention of CEOs and business executives to the fact that the DoD advocates Open Source. Show them that we're not talking toy software. Show them that this isn't about not wanting to spend money. (Since when was the DoD afraid to spend money?) This is about an innately powerful method of developing high-grade - even military-grade - products that do what people actually need done.
We couldn't ask for better, but only if those outside of the IT industry actually hear of it. If only those who already accept the strengths of Open Source know that someone else has also decided it is a good solution, then that decision means nothing. Particularly as the DoD is very unlikely to do anything about it. It'll just be a decision. But if the business community got shown this... That would be a whole different ball-game.
Which may not sound like much of an addition to the complexity, but it is nonetheless added complexity. The effort is simply shifted from the rules to the alphabet. To go completely phonetic in English, however, would require 44 letters in the alphabet.
...but the chickens wouldn't know that. Besides, what you really want to do is spin them up, keep them at high speed until ready for the supermarket, then hit the brakes. The bones'll be large enough that you won't get fragments everywhere, it would be painless for the chicken, and I'm certain you could make a fortune selling the slow-motion video to students.
There is a restraunt in England that has as a menu item "freshly laid fried eggs", though I guess in this case they would be scrambled.
There is generalization that can be applied - the fewer letters you have, the more complex the rules need to be in order to express the same number of concepts. Thus, as the rules for English have become more powerful, a lot of additional symbols used historically no longer exist. If you have fewer rules (say, by having phonetic spelling) then you need more characters to compensate. British English has 20 vowel sounds (American English has 17) and 24 consonant sounds. In order to have a "pure" phonetic language, we'd need to go from 26 characters to 44! Anything less would be incapable of literally presenting what was being spoken.
(Well, maybe it's not quite that bad. Most phonetically-written languages, like Finnish or Old Futhark, have around 30 characters, but that's only because multiple sounds can be assigned the same character, depending on context, and multiple characters can represent a single sound in some cases. However, if you eliminate both of those possibilities and go to a purely phonetic system, 30 characters is NOT enough just to cover the sounds in general use today.)
In either case, pity the poor child who has to memorize a 44-character alphabet. Rules can be picked up as you go along, but the alphabet is the basis, the foundation, for everything. You can look up obscure rules, but there is no such thing as an obscure character - particularly as we use most of those 44 phonetic characters in everyday speech. For that matter, can you imagine what it would do to QWERTY keyboards? It would need to be 5/3rds its current size to retain proportions and fit the rest of the phonetic alphabet in. You want to be in a typing class for that? Didn't think so.