Not too long ago, a kid was arrested for using one of NASA's storage computers as a storage site for all the movies and pron he was downloading off the Internet. He wasn't even detected until he'd accumulated something like 20 gigabytes.
None of this surprises me - when I was at NASA Langley, security amounted to having all the main computers with public IP addresses, giving them.rhosts files and praying that their IT security guys would spot intruders. The files were encrypted with DES, which is relatively easy for anyone who has determination and 512 PCs. Either that, or if they're a fairly decent systems cracker - the version of DES used showed the password on the process line, so a skillful intruder would have been capable of logging all the passwords in use.
That was seven or so years ago, so I hope they've improved since then. If not, well, I've even less sympathy for them than I'd thought.
How do they evaluate the worth of such material? Well, it depends on the material, whether they're playing the problem up or down, etc. A trivial way to price the material is to determine the total value of the project and the percent of the project represented by the data. Another simple method is to add up the man-hours spent on that piece of work, and multiply it by the typical charge per hour for that project number. Alternatively, find something similar that a commercial vendor is selling, and assume a credible-sounding factor for NASA's superiority/inferiority. The last method is to add up the bytes of data taken, then multiply by some standard cost per byte.
If an agency/company wants to sound as if the problem is insignificant, they'll pick the smallest of these values (or zero, if they can get away with it). If they want to turn it into a stage drama, for insurance or opinion control reasons, then they'll pick whatever gives the highest value. If they don't care, they'll pick a random number.
And I'd almost given up hope that others realized the technology was useful!:)
Seriously, because ISPs generally do not support multicast (even though their hardware does, it's just disabled, it requires 5 seconds to turn on, and is likely native downstream of them anyway), it is better to do this the way NASA Select did with their TV broadcasts in the days of CU-SeeMe. (Great program, died an ugly death, and is now a zombie in the hands of a corporation.)
What NASA did was to multicast for anyone who could get multicast to receive, but ALSO to reflectors that supported unicast connections. Users without multicast could then hook up to the nearest reflector and get the broadcast with only marginal extra latency.
Because multicast reduces the number of streams (to one), you have the benefit of being able to boost the quality of the transmission. Typical webcasts are maybe 320x200 at 5 seconds a frame. If you're lucky. A typical MBone transmission is very close to NTSC resolution at 15 frames per second, because the users have that much extra bandwidth to play with. That kind of a dramatic improvement in quality draws attention, which means that if this is a payed service (multicasting supports those), you're likely to improve not only the output but the revenue as well.
Because this is a broadcast-only system, the flavour of multicasting most likely to be of interest is SSM (Source-Specific Multicasting) where only designated endpoints (in this case the webcast transmitter) can send, all others receive.
About 90% of the time it takes me to develop an application is in essentially writing my own layout management tools that are transparently scalable and efficient. X/Motif is the worst for layout handling, Java is one of the better environments but still far grottier than it need be.
I have always been in two minds about NetBeans - it's good, but if a tool doesn't actually help in the code writing, then I might as well use a colorized text editor. So far, I've not been as impressed by NetBeans' ability to actually help as I'd have hoped.
Having said that, IMHO, if you want to do pure Java development, NetBeans has always been one of the top choices.
They both lasted several millennia - an order of magnitude more than America has so far, and about twice the lifespan of the Roman Empire (including the relatively insignificant Holy Roman Empire), so lifespan-wise, they did vastly better than anyone else.
The Indus Valley was seized by force by Aryan tribes, but the culture of those people did survive. A blend of Indus Valley philosophy with contemporary Aryan religious thought was put forward by a renegade prince who became a monk, by the name of Shakyamuni, a few centuries later. (The surviving people of the Indus Valley were slaves at that point and their culture was practiced in secret, where it was known at all.) If you include the resulting practice as part of the lifespan of the culture, then there is a simple answer to your question. In every Buddhist temple and in every Buddhist-based culture. That's not a bad record for such an old society that suffered such destruction. The Picts, the Caledonians, the Etruscans and the ancient Cretans didn't fare so well.
It is fairly firmly established that the civilizations of the Indus River and Skara Brae had no significant violence within the community and that warfare was unknown to them. Technically, it does follow that warfare is NOT a part of the "human condition" but is an extra that has voluntarily been incorporated. Whether it can be unincorporated once present is unclear, but if initially absent it can remain absent.
Not all inventions are products of warfare or hostility. In general, inventions are a product of need, with greater need yielding greater inventions. War generates need, so all wars will see inventiveness increase, but need does not require war. It is a one-way relationship.
Should the military use GPLed technology? Provided they honor the license and the spirit, yes. I believe they should. In fact, I'd almost prefer it if it were mandatory. Why? Because if you share what you are doing - even with a limited few - and reduce the secrecy, you will also reduce the sort of paranoia that tends to lead to conflict. If you look at the recent war with Iraq and the building tensions with Iran, what is the common factor? Secrecy on all sides, paranoia on all sides, resulting in tension and finally hostilities. Furthermore, it is between highly unequal forces, leading to the notion of an eventual "victory". Near-equal forces, as existed in the "Cold War", are much keener to avoid conflict. GPLing the armed services, therefore, could be one step towards reducing the need for military interventions.
Then there's the "viral" nature of the GPL. Again, this assumes that the GPL is honored in spirit and in letter. The technology will be sold to close allies, who can then alter the sourcecode for their own needs - within that particular system and for other devices. Those other devices will therefore carry GPLed code. Eventually, through enough such steps, the code will reach dual-purpose technology. Probably pretty quickly, too. When that happens, all of the improvements will flood back into the civilian world.
Finally, I believe that there are members of the armed services who value the Open Source community and want to sustain it. The military, more than anyone else, know how to make software secure. In this day and age, with viruses, trojans and worms running rampant, I certainly think that the military could play a major role in reducing or eliminating malware. They know more about trust systems, authentication of information, controlling access without debilitating operations, fault tolerence in hostile environments, high volume information processing without inflicting DDoS attacks on themselves, etc, than anyone else. That knowledge, donated back into the F/OSS community, could revolutionise computing as we know it. I don't think it can hurt to give them the opportunity.
Yes, Einstein regretted the bomb. Arguably, nuclear weapons technology was a bit of a mistake - it wasn't needed to get Japan to surrender and has opened up more cans of worms across the world than I care to imagine. Arguably, though, it was inevitable. There have been natural runaway reactions, so someone would have discovered how to cause one eventually through simple geology. Either that, or through a nuclear reactor accident.
(Knowing more about the nature of critical mass reactions may actually have prevented far worse accidents than have been caused through malice. We'll never know the answer to that one, but it seems a possibility.)
Uncontrolled nuclear explosions, through proposed derivatives of the Orion Project, may yet have a valuable function in space exploration, too, in a way that might not be practical by other means. When people say that something can cut both ways, they usually mean that there's a negative side to something appearing positive. What they forget is that the statement doesn't stop there. It also means that - if you choose to seek it out - there can be a positive side to something that appears negative.
The Nintendo emulator won't cluster that well and isn't CPU intensive enough. Now, if you'd said that they'd uploaded copies of bzflag and freeciv server on one, xmame on a second and were doing a distributed compile from scratch of Gentoo or Fedora Core on the rest, it would be believable.:)
Although the NSA are not military, there IS a history of the dodgier agencies giving back. (NASA has given back many times - Donald Becker contributed a lot to the network drivers and clustering technologies.)
As for distribution - militaries exchange technology. The British buy from the Americans and vice versa, for example. That will certainly be covered by the GPL, which means first-tier allies of the US are likely to get hold of such code at some point.
It's unclear what this would mean for the - uh - dodgier arms deals. (The contra scandal, the sales to Saddam Hussein, munitions to Osama bin Laden to fight the Russians, etc.) Would the US Government feel obliged to honor the license when it conducts illegal arms deals? Probably not. If the technology proved that vital for them to use, they'd find a way to use Eminent Domain or some such rule to claim exemption or ownership.
I saw many demos, at SC|05, of 3D glasses using polarized light from a single monitor using polarized light. It was actually very good. You can do full colour, because the glasses are not colour filters. In fact, you can get a wider range of colours, because the different views needn't use the same colour for the same pixel. The effect is vastly superior to the two colour glasses and doesn't leave you with the headaches that the shutter-glasses (where each eye was blanked alternately) did.
The drawback is that it only produces 3D if you are in the same plane as the polarizing filter AND are in roughly a direct line with the center of the image.
An alternative 3D glasses system would be the Virtual Reality goggles, which are still nowhere near where they could be. you can't get the resolution you'd want using a LCD screen. There have been reports of the military experimenting with systems that project onto the retina using (very low power) lasers, and even using transmitters to stimulate the optic nerve directly, but I know of no reliable information on where those technologies currently are.
But as for 3D glasses - they're around and they're improving.
But it's along the longest side. The shortest side is only about 2/3rds the diameter of Pluto. (The new object is extremely squished, which led to a lot of problems on determining the actual size and whether it had a moon or not.)
It would mean they'd have to reclassify all of the planets without stars for the same reason. And nobody is going to seriously suggest that a gas ball 100s of times the size of Jupiter is an asteroid or a comet. For a start, the press would crucify them.
It would be reasonable to define a planet in terms of composition and structure (and I've argued that case before) - the problem with that is that you'd need to define something as an unknown until you actually did enough of a geological survey to determine those things. I'm not sure NASA or the ESA would object too loudly, provided they got the funding. Missions like that make for great photo ops, as well as good science. Astronomers would likely complain, though, as it would mean they couldn't prove anything (other than gas giants) were planets.
Actually, when you get right down to it, NASA and the ESA have more money and more political clout than the IAU, so maybe that would actually be practical to enforce.
What happens when you have a split personality?
on
ReactOS Code Audit
·
· Score: 3, Funny
Personally, I'm not enthused with the methods used, anyway. The annual robot table tennis championships have proven time and again that striking moving objects is an extremely difficult problem. And they have the advantage that the bat can be large, relatively speaking, and doesn't have to move very much.
The methods are only good against specific types of target, so any kind of cruise missile is going to get straight through an anti ballistic missile system. Drones and "intelligent" self-controlling vehicles will also go right through. Of course, this all assumes anyone would use a missile. Why bother, when a robot with tracks - dropped near the coast - could drive itself to its target? The DARPA contest proved quite nicely that robots can handle just about any terrain and go from A to B without the need for human intervention.
The "correct" design needs a combination of mechanisms. I would put a visible light camera, thermal camera and RADAR on the anti-missile missile, as the combination will defeat just about any jamming mechanism and - because you're tracking directly - would not rely on guesswork on trajectory, would not be specific to a type of target. I'd also have two airborne tracking systems, which the missile could direct, to maximise information available and minimise the risk of failure in any one component.
Such a system would need to also be designed with maximum manoeverability in mind. Winglets, steering jets, whatever it took to be able to turn the thing quickly in any direction. You'd also need to take a lot of space up with the computer needed to be able to handle all of the navigation and prediction. For that reason, I'd probably go with a ramjet over a rocket, to reduce the space needed for fuel. (To start the ramjet, you'd use a gas cannon to give you the initial velocity needed.)
If you designed a system this way, it should be fairly effective against any kind of attack - EXCEPT ones involving EMP (as it would wipe the computer systems) OR ones that were travelling so fast that convergence was impossible within the range of the sensors (hydrogen-fuelled ramjets can go up to mach 6, but the hypersonic system being tested by the USAF is supposed to do mach 20 and the Australian scramjet status is completely unknown - other than it works).
"But our enemies don't have US-built systems!" Uhh, a certain Osama Bin Laden was supplied with US weapon systems, as was Saddam Hussein. Not all US allies are terribly careful with who they sell to, either. It is not sane to assume the best possible case for a system that is designed specifically for the worst possible scenario. If you are already assuming that you're in the worst of all possible worlds, don't deliberately weaken the scenario for the sole purpose of artificially reducing the problem to something that looks good to the ignorant but won't do anything for you in practice.
But one European country did switch from I believe left-side to right-side for driving everywhere at 10am. The theory went something like "people will gradually get used to it before rush-hour, if it's during the day, so things will stay fairly smooth - they won't, if it's at night, which will cause chaos". I'll suggest, then, that there are ways, if the timing is right.
The problem with routers further out is a good one. You'd have to start at the backbone routers and work outwards to the home user, to be meaningful. The firewall argument isn't quite as strong, as I'm arguing the router will proxy between IPv6 and IPv4, so inbound traffic to the host is still IPv4. Provided the IPv4 firewall rules were shifted to the internal network interface, they would still function exactly as before. (All you'd need then is sensible defalt IPv6 firewall rules for the external interface, and you're all set.)
Hey, I'm not claiming this would be something Joe Average Helpdesk Tech could do in his sleep. I don't see it as this Mission: Impossible thing, either. Certainly, antequated Cisco devices don't support IPv6 well, but modern Cisco equiptment supports it just fine. At the very least, if backbone networks are running archaic equiptment that is about to burn out from old age, I would hope they'd upgrade to something recent.
For the backbone, enabling IPv6 shouldn't be a big deal, as they won't experience any change in traffic. Even if it means updating a few systems here and there, the cost simply won't register above the regular background fluctuations.
ISPs that are big, fairly well-off, and have a fair amount of manpower they can throw at problems (Comcast, Qwest, AT&T, Sprint, even AOL!) are quite capable of going next and updating. Chances are high that they'll have fairly modern equiptment anyway, because they'll have proper service contracts. At least, I'd hope so!
Security, true, is a problem. Well, once you go native IPv6, rather than use proxies to flip between protocols. However, many security headaches are skript kiddies and I seriously doubt many skripts are IPv6-enabled at this time, OR have been updated with exploits relevent to the IPv6 stack and IPv6 routines in applications.
The faster the transition, the longer between first serious usage and first serious headache. That's time that will be needed to get the IPv6 code hardened. (Don't expect network researchers to harden their code - they never did for IPv4, precisely because it wasn't needed when they were the main ones using it.) No, the only time we'll see a real push for solid IPv6 code is when it goes live on a significant number of machines.
The bill of rights wasn't paid, so the rights were disconnected. There is a $500 reconnection fee.
$100 per day of the offence... Well, there are those who say AT&T is an offence, but assuming they mean the wiretap saga over four years, that comes to $146,000 per class member. Of course, nobody is going to know how many class members there are, and I think there's a minimum requirement. If the courts "play safe" and assume a low number of class members (say, 10) the total cost to AT&T would probably be covered by them cutting back on office-space heating for a few weeks.
While the effort is to be applauded, the impact is not going to be terribly significant, even if the EFF win. As such, it won't deter anyone. Hell, given the size of the black budget, the NSA can probably fund the next ten year's worth of spying from the loose change in the glove compartment.
We need something effective, if we're to see something actually constructive done.
I think it very important if 99% of the world's population jumped off a bridge. For a start, the tsunami might damage my Internet connection.
Now, if you were to talk about 99% of Internet Explorer die-hards jumping off a bridge, that would be another matter. I'd even be willing to help them look for a suitable bridge. The browser distribution does matter, however. At the present time, many sites are IE-specific and will not function under Firefox, SeaMonkey or Konqueror. I do not accept the argument that to be good, browser-specific code must be used. Nor do I accept the argument that nobody can test on all the browsers in use - that is why we have standards. And I definitely don't accept the argument that you'd design for the browser most in use, because a good design will work just as well on IE as a specific design, it'll just work everywhere else too.
Think global and long-term, not just next-cube-down and next-week.
Just for historical interest, I started using IPv6 in September of 1996 and the machine I was running was the first to be registered on the 6bone in the UK. At one point, I had 12 IPv6 tunnels up and running, across the British Isles, into Europe and over to America. Routing was initially static, then shifted over to MRT. GateD's IPv6 efforts didn't work when they were free (for researchers) and I didn't care to pay the bazillion dollars to find out if they'd got it to work any better when proprietary.
I currently run a 6bone connection via HE's tunnel broker, which is nowhere near as exciting as running a major junction.
(It should probably be noted that running tunnels from the University was in violation of a whole bunch of rules. I even had to swear blind I wasn't going to run virtual networks, in order to get the University's Autonomous System number. Mind you, they got upset so often about almost anything that about the only way to do research was to ignore them.)
This is part of a conspiracy by fast food places. If you can't get raw packets, only grilled ones, you're going to be more inclined to get fries with that.
IPSec isn't great on unreliable networks (which is why Sun developed the SK/IP protocol) but it is infinitely better than WPA/WEP. IPSec under IPv6 can be in two forms. The first is freeform in which keys are autogenerated and autonegotiated. There is no host authentication, per se, but traffic will be encrypted to the full AES standard and packets are authenticated as to their point of origin. In other words, intercepted packets can't be read and fake packets from an intruder cannot be injected into the stream.
The second is to use pre-defined keys - usually based on X.509 or some shared secret. This method strongly authenticates one or both hosts, depending on how it is set up. In a semi-secure environment, you would only want to connect to trusted wireless access points. In a fully secure environment, you'd also want to restrict connections to fully trusted user machines.
If you have a totally controlled environment, and want to have secure wireless connections, I'd say 802.11x would be better than a generic solution like IPSec. However, you can get IPSec for far more machines than you can 802.11x, so in an environment in which you can't rely on 802.11x being available, IPSec is an extremely good option.
Imagine all the nets work... it isn't hard to do.
on
IPv6 Readiness Report
·
· Score: 1
Oh, certainly. Widespread multicasting would allow multiplayer games to explode in terms of capabilities and users. Webcams would be 15 frame per second, not 15 seconds per frame. Mobility would allow a new genre of live-action roleplaying games that could cover entire cities, provided the players had access to signal. (It wouldn't have to be the same signal, the same provider or the same anything. With mobility, you can flip between networks and yet not drop a packet.)
Some bloggers like to play "intrepid reporter", perhaps including a few seconds of low-res video on their page. Imagine they now have Mobile IP and multicast capability. Suddenly, they can do live telecasts at a resolution and framerate that is starting to approach professional TV studios. Even if only a handful of bloggers ever took advantage of that, the impact would likely be staggering.
Some argue that most of the business on the Internet is X-rated. Ok, I don't agree and wouldn't particularly like it if it were true, but if it were, I feel confident people would pay a lot more for near-TV quality live footage... at the same time, because less bandwidth is needed, the merchants would need to spend less. That makes for much larger profits.
(Mobility support also means they would not be restricted to studios, or stationary locations. There would seem to be a lot of possibilities there that are simply not practical right now.)
IPv6 DNS supports auto-discovery. It doesn't need to be programmed by configuration servers like DHCP. I'm not certain if this uses the "Dynamic Delegation Discovery System" or is just a straight anycast response. Timeservers for IPv6 also support auto-discovery......when they're not simply multicasting anyway.
The current routing is crappy, prone to router storms and routing flaps.
Multicasting in IPv6 isn't an optional extra, as it is in IPv4. If it's not routed, IPv6 won't work. It's an all-or-nothing deal, there.
It really depends and Moore's Law doesn't really apply to it. The jumps tend to be much larger and much more random. The problem is that capacity is limited by several factors: drive speed, disk rigidity, read/write-head speed and the distance the read head is from the disk surface.
The faster a disk spins, the more disk surface is exposed to the magnetic field used to write to the drive, so the less storage you have. Disk rigidity is important for two reasons - it limits how close the read head can get and it limits how precisely you can know how much disk surface has been visible. The faster you can either read magnetic fields or generate them, the less disk you need to write to, thus increasing storage. The distance of the read head determines the surface area exposed to the magnetic field on writing, so determines how far apart your data must be to not overlap.
A trivial question might be: Using a standard, existing hard disk (but modifying the controller as necessary) increase the capacity of a hard drive? The answer is "probably".
One way to do it would be to add enough RAM such that a fairly substantial portion of the disk can be held in ramdisk on the controller. Because you are then not reading and writing to the disk directly, but going through ramdisk, the speed of the drive becomes much less important. If you slow the drive down substantially, whilst writing to it at the same speed, the data won't be smeared over the disk as much, so you should be able to increase the density.
In practice, as disk manufacturers don't design their disks with that kind of mod in mind, you are very likely to run into significant problems with defects on the surface that simply aren't visible at 7200 or 15000 RPM. Other problems, such as stability (drives depend a lot on gyroscopic effects and aren't built to go slow), may also limit how much you can cheat on the density.
Another option would be to seriously cool the read/write head, so that you could flip the magnetic state faster. Again, you're limited. Mechanical devices don't like being freeze-dried - even when they ARE dry. However, you may be able to get some improvement that way.
If you're just looking for ANY increase in capacity, then that's trivial and requires no engineering (but some programming). Modern computers are very fast, compared to modern hard drives. If you have one physical sector per physical track, then break down the structure entirely in memory, you eliminate the need for inter-sector gaps, physical sector headers, etc. You might be able to squeeze out another 10%-15% by this method, which isn't a whole lot but isn't bad for the effort it would take.
There are very likely other mods that hard disk manufacturers could use, but which would be totally beyond anyone doing homebrew stuff. The platters probably aren't using the absolute ideal materials - let's face it, they're in business to make money and there are far more home buyers wanting cheap drives than there are perfectionists wanting perfect drives. I suspect there are other areas they could improve on, using existing technology, but won't because it's not economic.
That's probably why you see bursts of improvement. When there's a massive enough need for the extra storage, it can be achieved. When there isn't, it's not worth the extra investment.
Slashdot Mirror
None of this surprises me - when I was at NASA Langley, security amounted to having all the main computers with public IP addresses, giving them
That was seven or so years ago, so I hope they've improved since then. If not, well, I've even less sympathy for them than I'd thought.
How do they evaluate the worth of such material? Well, it depends on the material, whether they're playing the problem up or down, etc. A trivial way to price the material is to determine the total value of the project and the percent of the project represented by the data. Another simple method is to add up the man-hours spent on that piece of work, and multiply it by the typical charge per hour for that project number. Alternatively, find something similar that a commercial vendor is selling, and assume a credible-sounding factor for NASA's superiority/inferiority. The last method is to add up the bytes of data taken, then multiply by some standard cost per byte.
If an agency/company wants to sound as if the problem is insignificant, they'll pick the smallest of these values (or zero, if they can get away with it). If they want to turn it into a stage drama, for insurance or opinion control reasons, then they'll pick whatever gives the highest value. If they don't care, they'll pick a random number.
Seriously, because ISPs generally do not support multicast (even though their hardware does, it's just disabled, it requires 5 seconds to turn on, and is likely native downstream of them anyway), it is better to do this the way NASA Select did with their TV broadcasts in the days of CU-SeeMe. (Great program, died an ugly death, and is now a zombie in the hands of a corporation.)
What NASA did was to multicast for anyone who could get multicast to receive, but ALSO to reflectors that supported unicast connections. Users without multicast could then hook up to the nearest reflector and get the broadcast with only marginal extra latency.
Because multicast reduces the number of streams (to one), you have the benefit of being able to boost the quality of the transmission. Typical webcasts are maybe 320x200 at 5 seconds a frame. If you're lucky. A typical MBone transmission is very close to NTSC resolution at 15 frames per second, because the users have that much extra bandwidth to play with. That kind of a dramatic improvement in quality draws attention, which means that if this is a payed service (multicasting supports those), you're likely to improve not only the output but the revenue as well.
Because this is a broadcast-only system, the flavour of multicasting most likely to be of interest is SSM (Source-Specific Multicasting) where only designated endpoints (in this case the webcast transmitter) can send, all others receive.
Remember, multicasting is your friend.
I have always been in two minds about NetBeans - it's good, but if a tool doesn't actually help in the code writing, then I might as well use a colorized text editor. So far, I've not been as impressed by NetBeans' ability to actually help as I'd have hoped.
Having said that, IMHO, if you want to do pure Java development, NetBeans has always been one of the top choices.
The Indus Valley was seized by force by Aryan tribes, but the culture of those people did survive. A blend of Indus Valley philosophy with contemporary Aryan religious thought was put forward by a renegade prince who became a monk, by the name of Shakyamuni, a few centuries later. (The surviving people of the Indus Valley were slaves at that point and their culture was practiced in secret, where it was known at all.) If you include the resulting practice as part of the lifespan of the culture, then there is a simple answer to your question. In every Buddhist temple and in every Buddhist-based culture. That's not a bad record for such an old society that suffered such destruction. The Picts, the Caledonians, the Etruscans and the ancient Cretans didn't fare so well.
Not all inventions are products of warfare or hostility. In general, inventions are a product of need, with greater need yielding greater inventions. War generates need, so all wars will see inventiveness increase, but need does not require war. It is a one-way relationship.
Should the military use GPLed technology? Provided they honor the license and the spirit, yes. I believe they should. In fact, I'd almost prefer it if it were mandatory. Why? Because if you share what you are doing - even with a limited few - and reduce the secrecy, you will also reduce the sort of paranoia that tends to lead to conflict. If you look at the recent war with Iraq and the building tensions with Iran, what is the common factor? Secrecy on all sides, paranoia on all sides, resulting in tension and finally hostilities. Furthermore, it is between highly unequal forces, leading to the notion of an eventual "victory". Near-equal forces, as existed in the "Cold War", are much keener to avoid conflict. GPLing the armed services, therefore, could be one step towards reducing the need for military interventions.
Then there's the "viral" nature of the GPL. Again, this assumes that the GPL is honored in spirit and in letter. The technology will be sold to close allies, who can then alter the sourcecode for their own needs - within that particular system and for other devices. Those other devices will therefore carry GPLed code. Eventually, through enough such steps, the code will reach dual-purpose technology. Probably pretty quickly, too. When that happens, all of the improvements will flood back into the civilian world.
Finally, I believe that there are members of the armed services who value the Open Source community and want to sustain it. The military, more than anyone else, know how to make software secure. In this day and age, with viruses, trojans and worms running rampant, I certainly think that the military could play a major role in reducing or eliminating malware. They know more about trust systems, authentication of information, controlling access without debilitating operations, fault tolerence in hostile environments, high volume information processing without inflicting DDoS attacks on themselves, etc, than anyone else. That knowledge, donated back into the F/OSS community, could revolutionise computing as we know it. I don't think it can hurt to give them the opportunity.
Yes, Einstein regretted the bomb. Arguably, nuclear weapons technology was a bit of a mistake - it wasn't needed to get Japan to surrender and has opened up more cans of worms across the world than I care to imagine. Arguably, though, it was inevitable. There have been natural runaway reactions, so someone would have discovered how to cause one eventually through simple geology. Either that, or through a nuclear reactor accident.
(Knowing more about the nature of critical mass reactions may actually have prevented far worse accidents than have been caused through malice. We'll never know the answer to that one, but it seems a possibility.)
Uncontrolled nuclear explosions, through proposed derivatives of the Orion Project, may yet have a valuable function in space exploration, too, in a way that might not be practical by other means. When people say that something can cut both ways, they usually mean that there's a negative side to something appearing positive. What they forget is that the statement doesn't stop there. It also means that - if you choose to seek it out - there can be a positive side to something that appears negative.
I'm not sa
The Nintendo emulator won't cluster that well and isn't CPU intensive enough. Now, if you'd said that they'd uploaded copies of bzflag and freeciv server on one, xmame on a second and were doing a distributed compile from scratch of Gentoo or Fedora Core on the rest, it would be believable. :)
As for distribution - militaries exchange technology. The British buy from the Americans and vice versa, for example. That will certainly be covered by the GPL, which means first-tier allies of the US are likely to get hold of such code at some point.
It's unclear what this would mean for the - uh - dodgier arms deals. (The contra scandal, the sales to Saddam Hussein, munitions to Osama bin Laden to fight the Russians, etc.) Would the US Government feel obliged to honor the license when it conducts illegal arms deals? Probably not. If the technology proved that vital for them to use, they'd find a way to use Eminent Domain or some such rule to claim exemption or ownership.
The drawback is that it only produces 3D if you are in the same plane as the polarizing filter AND are in roughly a direct line with the center of the image.
An alternative 3D glasses system would be the Virtual Reality goggles, which are still nowhere near where they could be. you can't get the resolution you'd want using a LCD screen. There have been reports of the military experimenting with systems that project onto the retina using (very low power) lasers, and even using transmitters to stimulate the optic nerve directly, but I know of no reliable information on where those technologies currently are.
But as for 3D glasses - they're around and they're improving.
But it's along the longest side. The shortest side is only about 2/3rds the diameter of Pluto. (The new object is extremely squished, which led to a lot of problems on determining the actual size and whether it had a moon or not.)
It would be reasonable to define a planet in terms of composition and structure (and I've argued that case before) - the problem with that is that you'd need to define something as an unknown until you actually did enough of a geological survey to determine those things. I'm not sure NASA or the ESA would object too loudly, provided they got the funding. Missions like that make for great photo ops, as well as good science. Astronomers would likely complain, though, as it would mean they couldn't prove anything (other than gas giants) were planets.
Actually, when you get right down to it, NASA and the ESA have more money and more political clout than the IAU, so maybe that would actually be practical to enforce.
Or those with Zaphod Beeblebrox' problem? Are they one or two engineers, under US law?
As the mouths of politicians travel close to the speed of light, time slows down. Thought everyone knew that.
The methods are only good against specific types of target, so any kind of cruise missile is going to get straight through an anti ballistic missile system. Drones and "intelligent" self-controlling vehicles will also go right through. Of course, this all assumes anyone would use a missile. Why bother, when a robot with tracks - dropped near the coast - could drive itself to its target? The DARPA contest proved quite nicely that robots can handle just about any terrain and go from A to B without the need for human intervention.
The "correct" design needs a combination of mechanisms. I would put a visible light camera, thermal camera and RADAR on the anti-missile missile, as the combination will defeat just about any jamming mechanism and - because you're tracking directly - would not rely on guesswork on trajectory, would not be specific to a type of target. I'd also have two airborne tracking systems, which the missile could direct, to maximise information available and minimise the risk of failure in any one component.
Such a system would need to also be designed with maximum manoeverability in mind. Winglets, steering jets, whatever it took to be able to turn the thing quickly in any direction. You'd also need to take a lot of space up with the computer needed to be able to handle all of the navigation and prediction. For that reason, I'd probably go with a ramjet over a rocket, to reduce the space needed for fuel. (To start the ramjet, you'd use a gas cannon to give you the initial velocity needed.)
If you designed a system this way, it should be fairly effective against any kind of attack - EXCEPT ones involving EMP (as it would wipe the computer systems) OR ones that were travelling so fast that convergence was impossible within the range of the sensors (hydrogen-fuelled ramjets can go up to mach 6, but the hypersonic system being tested by the USAF is supposed to do mach 20 and the Australian scramjet status is completely unknown - other than it works).
"But our enemies don't have US-built systems!" Uhh, a certain Osama Bin Laden was supplied with US weapon systems, as was Saddam Hussein. Not all US allies are terribly careful with who they sell to, either. It is not sane to assume the best possible case for a system that is designed specifically for the worst possible scenario. If you are already assuming that you're in the worst of all possible worlds, don't deliberately weaken the scenario for the sole purpose of artificially reducing the problem to something that looks good to the ignorant but won't do anything for you in practice.
The problem with routers further out is a good one. You'd have to start at the backbone routers and work outwards to the home user, to be meaningful. The firewall argument isn't quite as strong, as I'm arguing the router will proxy between IPv6 and IPv4, so inbound traffic to the host is still IPv4. Provided the IPv4 firewall rules were shifted to the internal network interface, they would still function exactly as before. (All you'd need then is sensible defalt IPv6 firewall rules for the external interface, and you're all set.)
Hey, I'm not claiming this would be something Joe Average Helpdesk Tech could do in his sleep. I don't see it as this Mission: Impossible thing, either. Certainly, antequated Cisco devices don't support IPv6 well, but modern Cisco equiptment supports it just fine. At the very least, if backbone networks are running archaic equiptment that is about to burn out from old age, I would hope they'd upgrade to something recent.
For the backbone, enabling IPv6 shouldn't be a big deal, as they won't experience any change in traffic. Even if it means updating a few systems here and there, the cost simply won't register above the regular background fluctuations.
ISPs that are big, fairly well-off, and have a fair amount of manpower they can throw at problems (Comcast, Qwest, AT&T, Sprint, even AOL!) are quite capable of going next and updating. Chances are high that they'll have fairly modern equiptment anyway, because they'll have proper service contracts. At least, I'd hope so!
Security, true, is a problem. Well, once you go native IPv6, rather than use proxies to flip between protocols. However, many security headaches are skript kiddies and I seriously doubt many skripts are IPv6-enabled at this time, OR have been updated with exploits relevent to the IPv6 stack and IPv6 routines in applications.
The faster the transition, the longer between first serious usage and first serious headache. That's time that will be needed to get the IPv6 code hardened. (Don't expect network researchers to harden their code - they never did for IPv4, precisely because it wasn't needed when they were the main ones using it.) No, the only time we'll see a real push for solid IPv6 code is when it goes live on a significant number of machines.
YOU WIN! YAY!
$100 per day of the offence... Well, there are those who say AT&T is an offence, but assuming they mean the wiretap saga over four years, that comes to $146,000 per class member. Of course, nobody is going to know how many class members there are, and I think there's a minimum requirement. If the courts "play safe" and assume a low number of class members (say, 10) the total cost to AT&T would probably be covered by them cutting back on office-space heating for a few weeks.
While the effort is to be applauded, the impact is not going to be terribly significant, even if the EFF win. As such, it won't deter anyone. Hell, given the size of the black budget, the NSA can probably fund the next ten year's worth of spying from the loose change in the glove compartment.
We need something effective, if we're to see something actually constructive done.
Ok, here's a challenge. Write a summary of the entire article using only three letter actonyms, punctuation symbols and mathematical notation.
Now, if you were to talk about 99% of Internet Explorer die-hards jumping off a bridge, that would be another matter. I'd even be willing to help them look for a suitable bridge.
The browser distribution does matter, however. At the present time, many sites are IE-specific and will not function under Firefox, SeaMonkey or Konqueror. I do not accept the argument that to be good, browser-specific code must be used. Nor do I accept the argument that nobody can test on all the browsers in use - that is why we have standards. And I definitely don't accept the argument that you'd design for the browser most in use, because a good design will work just as well on IE as a specific design, it'll just work everywhere else too.
Think global and long-term, not just next-cube-down and next-week.
I currently run a 6bone connection via HE's tunnel broker, which is nowhere near as exciting as running a major junction.
(It should probably be noted that running tunnels from the University was in violation of a whole bunch of rules. I even had to swear blind I wasn't going to run virtual networks, in order to get the University's Autonomous System number. Mind you, they got upset so often about almost anything that about the only way to do research was to ignore them.)
This is part of a conspiracy by fast food places. If you can't get raw packets, only grilled ones, you're going to be more inclined to get fries with that.
It's spelled 1337! Gah, typists these days. In my day, typists had only one key! And that was backspace! AND they were grateful for it.
The second is to use pre-defined keys - usually based on X.509 or some shared secret. This method strongly authenticates one or both hosts, depending on how it is set up. In a semi-secure environment, you would only want to connect to trusted wireless access points. In a fully secure environment, you'd also want to restrict connections to fully trusted user machines.
If you have a totally controlled environment, and want to have secure wireless connections, I'd say 802.11x would be better than a generic solution like IPSec. However, you can get IPSec for far more machines than you can 802.11x, so in an environment in which you can't rely on 802.11x being available, IPSec is an extremely good option.
Some bloggers like to play "intrepid reporter", perhaps including a few seconds of low-res video on their page. Imagine they now have Mobile IP and multicast capability. Suddenly, they can do live telecasts at a resolution and framerate that is starting to approach professional TV studios. Even if only a handful of bloggers ever took advantage of that, the impact would likely be staggering.
Some argue that most of the business on the Internet is X-rated. Ok, I don't agree and wouldn't particularly like it if it were true, but if it were, I feel confident people would pay a lot more for near-TV quality live footage... at the same time, because less bandwidth is needed, the merchants would need to spend less. That makes for much larger profits.
(Mobility support also means they would not be restricted to studios, or stationary locations. There would seem to be a lot of possibilities there that are simply not practical right now.)
The current routing is crappy, prone to router storms and routing flaps.
Multicasting in IPv6 isn't an optional extra, as it is in IPv4. If it's not routed, IPv6 won't work. It's an all-or-nothing deal, there.
The faster a disk spins, the more disk surface is exposed to the magnetic field used to write to the drive, so the less storage you have. Disk rigidity is important for two reasons - it limits how close the read head can get and it limits how precisely you can know how much disk surface has been visible. The faster you can either read magnetic fields or generate them, the less disk you need to write to, thus increasing storage. The distance of the read head determines the surface area exposed to the magnetic field on writing, so determines how far apart your data must be to not overlap.
A trivial question might be: Using a standard, existing hard disk (but modifying the controller as necessary) increase the capacity of a hard drive? The answer is "probably".
One way to do it would be to add enough RAM such that a fairly substantial portion of the disk can be held in ramdisk on the controller. Because you are then not reading and writing to the disk directly, but going through ramdisk, the speed of the drive becomes much less important. If you slow the drive down substantially, whilst writing to it at the same speed, the data won't be smeared over the disk as much, so you should be able to increase the density.
In practice, as disk manufacturers don't design their disks with that kind of mod in mind, you are very likely to run into significant problems with defects on the surface that simply aren't visible at 7200 or 15000 RPM. Other problems, such as stability (drives depend a lot on gyroscopic effects and aren't built to go slow), may also limit how much you can cheat on the density.
Another option would be to seriously cool the read/write head, so that you could flip the magnetic state faster. Again, you're limited. Mechanical devices don't like being freeze-dried - even when they ARE dry. However, you may be able to get some improvement that way.
If you're just looking for ANY increase in capacity, then that's trivial and requires no engineering (but some programming). Modern computers are very fast, compared to modern hard drives. If you have one physical sector per physical track, then break down the structure entirely in memory, you eliminate the need for inter-sector gaps, physical sector headers, etc. You might be able to squeeze out another 10%-15% by this method, which isn't a whole lot but isn't bad for the effort it would take.
There are very likely other mods that hard disk manufacturers could use, but which would be totally beyond anyone doing homebrew stuff. The platters probably aren't using the absolute ideal materials - let's face it, they're in business to make money and there are far more home buyers wanting cheap drives than there are perfectionists wanting perfect drives. I suspect there are other areas they could improve on, using existing technology, but won't because it's not economic.
That's probably why you see bursts of improvement. When there's a massive enough need for the extra storage, it can be achieved. When there isn't, it's not worth the extra investment.