My guess is that relationship went south quite a bit earlier - around the time a New Zealand hobbyist was offering the schematics for a DIY cruise missile that could be built by any geek with a basic toolset and $5k spare change. That episode......freaked out more than a few governments, as I recall. It may not have used rockets, but that's immaterial. The guidance system is the only technically difficult part of this sort of project and is the chief reason the US and USSR were in the space race to begin with. (They had less interest in reaching the moon than they did in being able to show they could hit an incredibly small target over an incredibly long range.)
Once it became known that anyone could develop a highly accurate guidance system for pennies, hobbyists would not be seen as potential recruits (a-la Bletchley Park) but as potential adversaries.
There are a lot of projects that aim to give rockets an assist at the start. NASA has experimented with ski ramps (and is back to them again) but has also played with turbine-assisted ramjets and variants thereof. ScaledX opted for a hybrid liquid/solid fuel motor, to get the controllability of liquid fuels with the oomph and reduced weight of solid. Have you considered any non-standard design or are you more in the "keep it simple" camp?
For low-altitude rocketry, passive stabilizing is just fine. When you start getting to the heights your rocket is reaching, it's hard to imagine that this is still the case, yet your diagrams on your website show no active mechanism for keeping the rocket upright, the base fins for stability and that's about it. (Actually, given the wind sheer, it would be almost as bad to be blown horizontally yet remain vertical. To fix that, you'd need full-blown guidance.) To be fair, though, the diagram is hellishly crowded and you may well have kept the details to what would be the most interest/use to the most people.
So, are you using active mechanisms in your current rockets and, if not, are you planning on adopting any in future projects?
IIRC, it was because the higher-ups rejected the pluggable nature of it. They didn't want the ability for someone to change the scheduler on-the-fly. I don't recall the specific objection to the pluggable nature, it may have been that the ability to insert essentially arbitrary code into the kernel in such a critical component was unnerving. I honestly don't know why. There's not much difference between an untrusted kernel object and an untrusted scheduler object, in terms of capability. At worst, it would have accelerated the adoption of module-specific capabilities and user-specific permissions -- hardly a bad thing. It may even have accelerated the demise of the Big Kernel Lock and facilitated the development of the real-time patches.
(Come to think of it, being able to mix-n-match schedulers would have made life a hell of a lot easier every time Linux has switched scheduler. The scheduler plug-in system would have evolved to support the new needs, rather than major chunks of code being replaced. Much less risk of accidents and much less annoying to those wanting to maintain the prior behaviour - they would only need to maintain a kernel scheduler module, not an entire kernel.)
Testing/debugging is also easier if the scheduler you're testing and trying to crash ISN'T the one you're running the testing software on.
I'm not certain on that. HP produced a pluggable hierarchical scheduler for Linux and a clustering patch. Neither were adopted. Neither were even that widely used. If there's more than a dozen Slashdot readers who even knew these products existed, I'd be amazed.
I'm not saying the contributions were poor. Quite the opposite. I liked their scheduler patch. It was absolutely wonderful if you wanted to do any kind of research into the dynamics of that part of kernel operations. The potential for teaching OS theory was obvious. It also meant you could tweak the dynamics to suit the workloads.
What I am saying is that if HP produced a whole bunch of patches almost nobody knew existed, almost nobody is going to miss them not being there.
There are thousands of ink recipes out there, many much more stable than modern inks. There are also hundreds of ink cartridge vendors out there - modern inks may be naff but there's a lot of people selling the stuff.
If HP wants to survive, it certainly needs to concentrate on core products but it also has to diversify. Having said that, diversifying into areas HP aren't very good at doesn't help HP.
Military drones would presumably use something like Windows CE. (Non-classified drones do, from what little experience I have in the field.) Which, to be fair, would likely run a reasonable range of Windows programs. However, it's not fully compatible and cross-compilers are something of a necessity. It's possible it could be a generic binary but I'm going to guess that a custom build is the more likely.
I'm not sure it matters who it is. What matters is that if you can intercept a keystroke, you can inject one, and that if you log sequences you know command sequences. That knowledge never needs to go anywhere outside the virus - if the virus catalogs how to do X, Y and Z then an unauthorized user merely needs to tell the virus that it is to replay the sequence to do X, Y or Z. The user doesn't need to know anything other than what macro does what.
For most nations, it just doesn't make sense to do this with any current mission - that we know of, at least. Scripting a drone attack only makes sense if the drone has attacked a point that the person who wrote the virus will want to attack in the future. This is great if you're a nation defending against an attacker overrunning your positions, since you can get the attacker's weapons to attack the attacker. But no current target nation has the capacity for such a strategy and even if they did it would be pointless. It wouldn't be useful at all in Libya, for example, and the draw-down in Afghanistan means the probability of there ever being a meaningful target is next to zero.
Israel is a remote possibility - they've the knowledge - and there are doubtless drone surveillance missions that the Israelies could turn into attacks and keep plausible denial. However, it's exceedingly remote. Most of their threats don't distinguish between the US and Israel, so plausible denial is pointless, and they've enough support to be able to obtain all the US-made drones they want. There's no obvious added value.
The Mexican drug cartels are hampered by drones, but not usually by the high-end military ones, and being able to launch a replay would be absolutely pointless. If they were to have the kind of savvy needed, it would more likely go into a logic bomb that would cripple the drone. It's just possible they'd want to divert a drone to some site of theirs so that they could use it for their own purposes, but you'd not want a logger for that. Makes no sense. Besides which, if they had that kind of skill, they wouldn't need cheap cop drones.
China? Maybe, but again if they wanted a Predator they'd be better off with a logic bomb that disabled the radios and landed the UAV somewhere they could pick it up from. They wouldn't use loggers because there'd be nothing worth logging.
This isn't making sense. The story so far is too illogical. Those with the skills would be doing something different, those who want to do what is claimed don't have the skills.
Oh, and you seem to be assuming that anyone in India must be an amateur. Doubtless there are plenty of amateurs there, but there are also plenty of universities. There are also plenty from India who have attended either British or American university. It is illogical to assume that such people would be no better able to work in mathematics than a call center worker.
I was going to say ascetic priest, but actually several of those have made major discoveries in mathematics in England. Then I thought "author" and "school teacher" but realized there were British examples of top-flight mathematicians in both categories. I didn't bother with Patent Clerk.
I didn't say there was a claim of a proof. Neither did the summary.My point was solely that you can't ignore the possibility of an Indian succeeding in making progress towards a proof merely because the country as a whole has a poor reputation in a totally unrelated field.
Advanced mathematical knowledge, yes. But both solvers placed themselves in total isolation for a long time to get the work done.
A strong background, again yes - although there have been notable amateur mathematicians who have achieved remarkable success in history. To diss them is to do a disservice to mathematics as a whole. Besides which, a "strong background" really only means knowing a set of standard core methods. Advanced standard methods and all standard results can be piled into a database then looked up as needed. You don't need to memorize them, you only need to have access to them and know enough to be able to understand what to do with said information once you have accessed them.
Cookbook mathematics by recipes is no less doable than cookbook computer programming by recipes. They are, after all, really the same thing. And just as nobody writes their own standard libraries any more, nobody needs to know all the intricate details of such-and-such method. They only need to know that if they put X in, they get Y out.
Fermat meant the general case. What isn't clear is whether he wrote down the right formula. n^x + n^y = n^z for n 3, according to New Scientist, does indeed yield a simple and elegant proof that could have been known in his time, and he was notorious for that kind of error. Even if he did get the formula right, he was also notorious for sloppy work and may well have made a simple error. There's all kinds of possibilities.
Actually, I disagree with that interpretation of relativity. All objects have their own local time, which varies according to their relative motion and relative gravitic field, but that just means they're moving at different velocities in spacetime. In the same way that space isn't fixed because any point can be treated as zero, time isn't fixed because any point can be treated as zero. Yes, relativity introduces the complication that the size of the units also varies according to relative motion, but we're talking about Galactic Standard Time not Universal Standard Time. There's bound to be some object close to the galactic core that is rotating around that core at close enough to a fixed rate relative to, oh, say some object in one of the arms in Andromeda.
Since we can measure the angle subtended, we can measure where we are in time relative to anyone else. This will not equal the time we have experienced, any more than wall-clock time is proportional to the CPU time a computer program experiences. Doesn't matter. It's a Galactic Standard Time and relativistic effects are the observer's problems.
No, that's the reference implementation. Code Sourcery developed a much more powerful, much more rounded version up until about 2009-2010. Whilst the 2005 reference version could certainly be used, you lose all of the (GPLed) developments over the half decade since then. And in the digital signal processing world, that's a hell of a lot of development.
VSIPL++ is a signal processing library. I track it (and about a hundred other pieces of science/engineering projects) in part because this kind of stuff in the commercial sector costs as much as a mid-range server. Open source variants make it possible for enthusiasts to do the kind of work only major corporations could otherwise touch.
Two of the major problems (Fermat's Last Theorum and the Poincaire Conjecture) have been cracked in recent times. A third major breakthrough is not impossible, particularly in a nation that has produced some superb minds in the past.
True, India has developed a bad reputation as a result of the call centers and the crappy software engineering, but that's like dissing the engineers developing the PCI Express and HyperTransport specifications because GM can't make a decent car or Bank of America can't provide anything remotely close to service. The subjects are wholly unrelated and you can draw no conclusions about one from the other. (India still runs a better train service than Amtrak, though that should not be considered credit to either.)
Mathematics doesn't require advanced infrastructure and is better done in peace with no distractions.
Hey, it's worth a shot. But in order for it to be proper and everything, we need a vote to establish you as a legal representative of Slashdania. This is a democracy, there's no quorum defined, so all you need is more votes for than against. I hereby vote for you as Slashdania's UN Representative.
Y'know, the IETF doesn't seem to have a copy of the GETF standard on this, would you be interested in helping me set up a working group so we can get the RFC to them, say around the April timeframe?
Slashdot Mirror
My guess is that relationship went south quite a bit earlier - around the time a New Zealand hobbyist was offering the schematics for a DIY cruise missile that could be built by any geek with a basic toolset and $5k spare change. That episode... ...freaked out more than a few governments, as I recall. It may not have used rockets, but that's immaterial. The guidance system is the only technically difficult part of this sort of project and is the chief reason the US and USSR were in the space race to begin with. (They had less interest in reaching the moon than they did in being able to show they could hit an incredibly small target over an incredibly long range.)
Once it became known that anyone could develop a highly accurate guidance system for pennies, hobbyists would not be seen as potential recruits (a-la Bletchley Park) but as potential adversaries.
There are a lot of projects that aim to give rockets an assist at the start. NASA has experimented with ski ramps (and is back to them again) but has also played with turbine-assisted ramjets and variants thereof. ScaledX opted for a hybrid liquid/solid fuel motor, to get the controllability of liquid fuels with the oomph and reduced weight of solid. Have you considered any non-standard design or are you more in the "keep it simple" camp?
For low-altitude rocketry, passive stabilizing is just fine. When you start getting to the heights your rocket is reaching, it's hard to imagine that this is still the case, yet your diagrams on your website show no active mechanism for keeping the rocket upright, the base fins for stability and that's about it. (Actually, given the wind sheer, it would be almost as bad to be blown horizontally yet remain vertical. To fix that, you'd need full-blown guidance.) To be fair, though, the diagram is hellishly crowded and you may well have kept the details to what would be the most interest/use to the most people.
So, are you using active mechanisms in your current rockets and, if not, are you planning on adopting any in future projects?
That number may, however, have dropped with the second crash.
IIRC, it was because the higher-ups rejected the pluggable nature of it. They didn't want the ability for someone to change the scheduler on-the-fly. I don't recall the specific objection to the pluggable nature, it may have been that the ability to insert essentially arbitrary code into the kernel in such a critical component was unnerving. I honestly don't know why. There's not much difference between an untrusted kernel object and an untrusted scheduler object, in terms of capability. At worst, it would have accelerated the adoption of module-specific capabilities and user-specific permissions -- hardly a bad thing. It may even have accelerated the demise of the Big Kernel Lock and facilitated the development of the real-time patches.
(Come to think of it, being able to mix-n-match schedulers would have made life a hell of a lot easier every time Linux has switched scheduler. The scheduler plug-in system would have evolved to support the new needs, rather than major chunks of code being replaced. Much less risk of accidents and much less annoying to those wanting to maintain the prior behaviour - they would only need to maintain a kernel scheduler module, not an entire kernel.)
Testing/debugging is also easier if the scheduler you're testing and trying to crash ISN'T the one you're running the testing software on.
Is that the last minute is either "next year" or "last week" depending on which side of the disaster you're on.
I'm not certain on that. HP produced a pluggable hierarchical scheduler for Linux and a clustering patch. Neither were adopted. Neither were even that widely used. If there's more than a dozen Slashdot readers who even knew these products existed, I'd be amazed.
I'm not saying the contributions were poor. Quite the opposite. I liked their scheduler patch. It was absolutely wonderful if you wanted to do any kind of research into the dynamics of that part of kernel operations. The potential for teaching OS theory was obvious. It also meant you could tweak the dynamics to suit the workloads.
What I am saying is that if HP produced a whole bunch of patches almost nobody knew existed, almost nobody is going to miss them not being there.
There are thousands of ink recipes out there, many much more stable than modern inks. There are also hundreds of ink cartridge vendors out there - modern inks may be naff but there's a lot of people selling the stuff.
If HP wants to survive, it certainly needs to concentrate on core products but it also has to diversify. Having said that, diversifying into areas HP aren't very good at doesn't help HP.
Addressed twice in the article.
Military drones would presumably use something like Windows CE. (Non-classified drones do, from what little experience I have in the field.) Which, to be fair, would likely run a reasonable range of Windows programs. However, it's not fully compatible and cross-compilers are something of a necessity. It's possible it could be a generic binary but I'm going to guess that a custom build is the more likely.
Nonononono. If you say you don't know, you should be catapulted from the bridge.
I'm not sure it matters who it is. What matters is that if you can intercept a keystroke, you can inject one, and that if you log sequences you know command sequences. That knowledge never needs to go anywhere outside the virus - if the virus catalogs how to do X, Y and Z then an unauthorized user merely needs to tell the virus that it is to replay the sequence to do X, Y or Z. The user doesn't need to know anything other than what macro does what.
For most nations, it just doesn't make sense to do this with any current mission - that we know of, at least. Scripting a drone attack only makes sense if the drone has attacked a point that the person who wrote the virus will want to attack in the future. This is great if you're a nation defending against an attacker overrunning your positions, since you can get the attacker's weapons to attack the attacker. But no current target nation has the capacity for such a strategy and even if they did it would be pointless. It wouldn't be useful at all in Libya, for example, and the draw-down in Afghanistan means the probability of there ever being a meaningful target is next to zero.
Israel is a remote possibility - they've the knowledge - and there are doubtless drone surveillance missions that the Israelies could turn into attacks and keep plausible denial. However, it's exceedingly remote. Most of their threats don't distinguish between the US and Israel, so plausible denial is pointless, and they've enough support to be able to obtain all the US-made drones they want. There's no obvious added value.
The Mexican drug cartels are hampered by drones, but not usually by the high-end military ones, and being able to launch a replay would be absolutely pointless. If they were to have the kind of savvy needed, it would more likely go into a logic bomb that would cripple the drone. It's just possible they'd want to divert a drone to some site of theirs so that they could use it for their own purposes, but you'd not want a logger for that. Makes no sense. Besides which, if they had that kind of skill, they wouldn't need cheap cop drones.
China? Maybe, but again if they wanted a Predator they'd be better off with a logic bomb that disabled the radios and landed the UAV somewhere they could pick it up from. They wouldn't use loggers because there'd be nothing worth logging.
This isn't making sense. The story so far is too illogical. Those with the skills would be doing something different, those who want to do what is claimed don't have the skills.
Heh! I still play Bell&Braben-era Elite and occasionally indulge in a round of Chuckie Egg, so yes I do know that. :)
That's three states but two bits produces four states, so there must be a base not covered.
Why would hackers still be playing Command and Conquer?
Oh, and you seem to be assuming that anyone in India must be an amateur. Doubtless there are plenty of amateurs there, but there are also plenty of universities. There are also plenty from India who have attended either British or American university. It is illogical to assume that such people would be no better able to work in mathematics than a call center worker.
I was going to say ascetic priest, but actually several of those have made major discoveries in mathematics in England. Then I thought "author" and "school teacher" but realized there were British examples of top-flight mathematicians in both categories. I didn't bother with Patent Clerk.
I didn't say there was a claim of a proof. Neither did the summary.My point was solely that you can't ignore the possibility of an Indian succeeding in making progress towards a proof merely because the country as a whole has a poor reputation in a totally unrelated field.
Advanced mathematical knowledge, yes. But both solvers placed themselves in total isolation for a long time to get the work done.
A strong background, again yes - although there have been notable amateur mathematicians who have achieved remarkable success in history. To diss them is to do a disservice to mathematics as a whole. Besides which, a "strong background" really only means knowing a set of standard core methods. Advanced standard methods and all standard results can be piled into a database then looked up as needed. You don't need to memorize them, you only need to have access to them and know enough to be able to understand what to do with said information once you have accessed them.
Cookbook mathematics by recipes is no less doable than cookbook computer programming by recipes. They are, after all, really the same thing. And just as nobody writes their own standard libraries any more, nobody needs to know all the intricate details of such-and-such method. They only need to know that if they put X in, they get Y out.
Fermat meant the general case. What isn't clear is whether he wrote down the right formula. n^x + n^y = n^z for n 3, according to New Scientist, does indeed yield a simple and elegant proof that could have been known in his time, and he was notorious for that kind of error. Even if he did get the formula right, he was also notorious for sloppy work and may well have made a simple error. There's all kinds of possibilities.
Actually, I disagree with that interpretation of relativity. All objects have their own local time, which varies according to their relative motion and relative gravitic field, but that just means they're moving at different velocities in spacetime. In the same way that space isn't fixed because any point can be treated as zero, time isn't fixed because any point can be treated as zero. Yes, relativity introduces the complication that the size of the units also varies according to relative motion, but we're talking about Galactic Standard Time not Universal Standard Time. There's bound to be some object close to the galactic core that is rotating around that core at close enough to a fixed rate relative to, oh, say some object in one of the arms in Andromeda.
Since we can measure the angle subtended, we can measure where we are in time relative to anyone else. This will not equal the time we have experienced, any more than wall-clock time is proportional to the CPU time a computer program experiences. Doesn't matter. It's a Galactic Standard Time and relativistic effects are the observer's problems.
No, that's the reference implementation. Code Sourcery developed a much more powerful, much more rounded version up until about 2009-2010. Whilst the 2005 reference version could certainly be used, you lose all of the (GPLed) developments over the half decade since then. And in the digital signal processing world, that's a hell of a lot of development.
VSIPL++ is a signal processing library. I track it (and about a hundred other pieces of science/engineering projects) in part because this kind of stuff in the commercial sector costs as much as a mid-range server. Open source variants make it possible for enthusiasts to do the kind of work only major corporations could otherwise touch.
Two of the major problems (Fermat's Last Theorum and the Poincaire Conjecture) have been cracked in recent times. A third major breakthrough is not impossible, particularly in a nation that has produced some superb minds in the past.
True, India has developed a bad reputation as a result of the call centers and the crappy software engineering, but that's like dissing the engineers developing the PCI Express and HyperTransport specifications because GM can't make a decent car or Bank of America can't provide anything remotely close to service. The subjects are wholly unrelated and you can draw no conclusions about one from the other. (India still runs a better train service than Amtrak, though that should not be considered credit to either.)
Mathematics doesn't require advanced infrastructure and is better done in peace with no distractions.
Since Lakshmi is an Indian goddess, the poster is correct. Ramanujan DID say an Indian can do maths. :)
Hey, it's worth a shot. But in order for it to be proper and everything, we need a vote to establish you as a legal representative of Slashdania. This is a democracy, there's no quorum defined, so all you need is more votes for than against. I hereby vote for you as Slashdania's UN Representative.
Y'know, the IETF doesn't seem to have a copy of the GETF standard on this, would you be interested in helping me set up a working group so we can get the RFC to them, say around the April timeframe?