...But, you have heard of "apt-get source xxx", right?
(Very VERY usefull in the frequently-named dependency-conflict situations above: Don't have a version of "foo" that works with "bar-1.2.3-10"? "apt-get -b source foo".....
Re:Proper weapoin wont puncture the Aircraft
on
More On Tragedy
·
· Score: 2
I thought it only fair to respond to the many replies to my message above.
Most of these responses have focussed on technical means to prevent a repetition. Needless to say I have my doubts about the feasibility and suitability of most of these but that's irrelevent.
I should have originally stated this more clearly rather than reacting, but it is my firm belief that the solutions to these issues lies overwhelmingly in the human domain, not the technical domain.
I'd love to live in a world where geeks don't even need to devote their prodigious problem-solving skills to issues of this kind, and the only way to bring that about is consideration from the ground-up of the human issues here.
From organisational and chain-of-command matters through to foreign policy and human rights: This atrocity was NOT caused by guns, knifes, cost-cutting by aircraft manufacturers or lack of available technolog. And it will not be resolved through those means.
Flame away.
Re:Proper weapoin wont puncture the Aircraft
on
More On Tragedy
·
· Score: 3, Interesting
But secondly, to be honest, in a hijacking ill take my chances with depressurization. If the hijacker is put down there are always the breathing masks for the passengers.
Up until yesterday you'd have been a fool to take that risk. By sitting still and doing exactly as the hijacker said you'd have stood an excellent chance of making it out alive and unharmed.
What happened yesterday is totally without
precedent and it would be unwise to make such a drastic policy and procedural change [carrying guns on commercial flights] without considering first what other measures might be more appropriate and secondly whether the additional risks incurred [of carrying weapons] are matched by a corresponding increase of overall safety.
Sadly I have no idea of a feasible means of measuring such an impact without waiting for it to happen again and plotting statistical graphs. How very depressing.
Go read The Risks Digest. Then come back and explain in great and convincing detail how you've solved the problems of managing technical complexity and especially it's interface to the human element in automated control systems such as you're proposing.
I don't know the solution to this problem, but it's in the human domain, not the technical.
Re:it seems we could do more to help the effort.
on
More On Tragedy
·
· Score: 2
An interesting idea. Let's consider some implications
One: what on EARTH makes you think that any of the planning and execution of this disgusting atrocity involved any digital communications or indeed any other form of information which is amenable to Number Crunching?
Two: It's not called the "Web of a Thousand Lies" for nothing. Anyone surfing for verifiable info in the last 36 hours is familiar with this concept. Discriminating "Wheat" from "Chaff" is not a solved problem at this time
Three: You and I and the rest of the Clan here are active in a field of endeavour unique amongst the human experience as being immature, incomplete, and above all unreliable. Assuming points 1 and 2 can be dealt with satisfactorily, your bonus question becomes: How do you convince those who Need to Know that you've actually derived some usefull data?
Every commercial airline pilot i have ever met was an ex air-force pilot. (In the USe abotu the only way to learn to fly jhets is to join the US Airforce.)
Given that, I would think they have training on the proper handling of a side arm. Maybe its time to arm them all.
I have two points for your consideration:
Do you have any idea how Bad a thing it is to puncture a thin-skinned pressure vessel? Let alone one containing hundreds of people at altitude potentially over an inhabited area?
I can't quote stats (and under the circumstances I don't want to quote stats) but it occurs to me that the number of law enforcement personnel attacked or injured by their own weapon is non-trivial.
Firearms on civil aircraft... nope, that's a scary idea. Try Again.
Re:What can be done about terrorism?
on
More On Tragedy
·
· Score: 2
Yesterday, immediately after the attack, it was hard to think anything but "nuke the middle east back into stone age", which seemed to fit the would-be nukees' level of cultural development.
I don't think you have any idea how much such views under any circumstances scare the bejesus out of me and many other people.
Regardless of any justification, righteous anger and emotional response I urge you to consider one very very simple point: How would acting on such an impulse or (horror) reasoned response make you any better that those you seek vengence on?
If you want to be the good guys, you have to act like good guys.
Re:Speaking of PVRs...
on
More On Tragedy
·
· Score: 4, Insightful
I'm in the UK, and I have no PVR. This is a comment regarding motive & conclusions, not facts.
In that vein, and regardless of my feelings about the gentleman concerned, under the circumstances I am very prepared to cut him some slack. I wouldn't trust myself to get a 4-word sentence out straight if placed in a similar situation. Any assistance the man needed to get the right words out to the world would be very astute and appropriate.
The towers were specifically built to withstand a direct hit from a 707, which was the largest plane at the time of construction. Whether or not it they actually would have withstood such a hit is unknown, of course.
With all due deference to your inside knowledge, Hogwash.
A 707 (see here) has a takeoff weight of 150 tonnes.
Both of these are large lumps of metal and jet fuel moving at high velocity. Given the failure mode of the buildings, and the time to do so under a direct hit, I don't think 30 tonnes would have made a hell of a lot of difference.
This is a very partisan approach to the issue. Success for Linux in the market place is not tied to the financial success of it's most well-known distro. It may not even be linked to RedHat's success.
I also believe you have mis-understood the fundamental premise on which one company may choose to support another. Let's take a worked example:
IBM is a global IT provider. And it has a very strong presence in non-US markets. It may surprise you to find that those markets have different requirements to the US. In particular, support for other languages & keyboards is higher on the priority list. And there are Distros that do indeed recognise this and cater for it: SuSE is one (mainly European) and TurboLinux is another (mainly Asia-Pacific).
As a result of this, these Distros are much more popular in their respective geographies than RedHat. MUCH more popular. (and not only for "good" reasons: there's as much senseless product jingoism in the computer biz as there is in any other (e.g. all those pissing-on-ford/chevvy badges one can observe on trucks in the US).
As a result of this effect, Linux's penetration world-wide is increased over and above that which would be observed if there was only One True Distro. And IBM therefore has a bigger global market into which it can sell it's value-add services and products.
It can therefore be observed that this isn't altruism on the part of these companies, it's just plain business sense: support the infrastructure that provides your ability to sell. RedHat is a part of, but by no means all of, that infrastructure, globally, and it behoves us all to remember that.
While stability is pretty much unchanged since then, Mozilla has gotten noticably faster during the 0.9.x cycle. 0.9.1 is usable on a 350 Mhz Pentium II... sort of. 0.9.3, while still being slower than Navigator 4.77, isn't bad at all.
True comments, for the browser. However, the mail&news client is still, on my PII-300MHz Linux system, juuust on the barely-acceptable side of unusably slow.
And still refuses to check ALL imap folders for new messages automatically.
This actually makes Linux stronger, as it provides choice. Got an old system: use ext3. Want speed: use ReiserFS. Want (I don't know. Sorry): use JFS, XFS, fooFS.
Speaking as an ex-AIX worshipper (I have now been converted to the One True OS and it's apt-get luvin' incarnation), IBM JFS has one MAJOR attraction for me: ease of filesystem modification.
I haven't tried JFS/Linux yet, but after years of expanding filesystems on production systems without outage ("chfs -a size=+blocks/fs/mount/point"), porting this to Linux is all it'll take me to switch. Performance? Pah! nice to have, but if you're reliant on FS performance you need to splurge a few beans on more memory. Ease of administration is the major win with JFS here folks....
Sadly, this was the most believable part of the entire book.
One to skip... Oh, and "Moonseed" too. "Voyage" isn't bad though (as the first in his "let's reuse existing space hardware" series which you have to admit isn't nearly as snappy a title as his previous "Xeelee Sequence" novels)
I think you're right. Also I think there's an error in the original story.
In most articles on the subject, the adjective "small" is not found anywhere near the quantifier "1 megaton"....
(megaton-class Nukes tend to be fusion hence expensive and big. "tactical" nukes which are smaller and lighter and pure fission or fission-boosted are in the 10-500 *Kilo*ton range).
of course, i still dont know why ibm just doesnt just use real modems. they worked great in the earlier models. i somehow doubt the cost difference would be more than a few more dollars at the factory...
Disclaimer: I know nothing of intentions. The following is drawn from observations
MWave isn't just a modem. It's a generalised DSP solution; effectively a DSP co-processor. Originally, way-back-when on the 750/760 even series Thinkpads, the MWave chip provided soundcard support (SoundBlaster Pro emulation I believe) and Modem support; the MWave chips ran a mini-multitasking OS that would time-slice these tasks so you could play Doom online thru the modem and still hear sound. There were some obvious drawbacks to this approach - IIRC if you wanted 33.6K modem dialups you had to fallback from stereo to mono 22KHz soundcard.
I believe the design point was that soundcard+modemcard cost more than MWave and thus the total system cost was cheaper; the side-effects of a software upgradeable soundcard and modem were secondary.
Some of the Aptiva model desktop PCs also got the full MWave for sound + modem (or was it sound only? I forget).
What I don't understand is why in newer Stinkpads (such as the models referred to by the article), the MWave hardware (presumably in cut-down form) is only used for modem function; the sound card function is provided by a standalone chipset (uur... CS4236+ I believe). This Makes No Sense to me.
Does anyone else who can organise thoughts more coherently have any better insights into the history here?
Disclaimer: I am only a recent convert to the One True Distribution, having previously been an inhabitant of SuSE and Slackware Lands.
Debian is indeed a fine, fine distro. And a model of what is required for high-granularity packaging, with all the benefits that brings - Especially for the net-connected with their I-want-it-now update needs. But I'd venture to suggest that it's not the ultimate in user interaction and consistency when it comes down to the how of selecting, installing and configuring packages.
For instance, as a relatively new user with much more experience of rpm or tarball-extraction, I'm still struggling with apt-get's Maze of Twisty Turny Dependencies. Fr'instance: how the hell do I get gimp-1.1.29 installed with xsane? apt-get is forever telling me I need to de-install gimp to install xsane; I *can* replace it with gimp1.1-xsane but only for gimp 1.1.17. This is for 2 packages I *know* can integrate, cos I've done it on SuSE (rpm -i gimp, rpm -i xsane, RTFM & create links in ~/.gimp-1.1/modules as needed, et voila bob's yer uncle).
Presumably I can override dependencies and prevent removal of shiny new gimp, and I dare say that if I could bring myself to launch dselect again there'd even be a psuedo-menu based system for letting me do that, but why should I? This example leads me to believe that we, the great unwashed Debian User masses are at the mercy of the Fickle Masters of Packaging and their dependency whims...
This is a trivial whine in the grand scheme of things, but like the man said - You want Linux for the masses, it's got to be damn-fool-proof. In this case, I'd venture to suggest that this means that both a more friendly interface is required (dselect? Just Say No. Especially to das bluddy awful dependency correction), and an independent (of the packagers) comb-through the thousands of.deb out there to validate dependencies before burning to CD.
Did you notice the coverage of this announcement last night? How it covered just about all aspects of the proposed regulator as they apply to the media with a little byline saying "oh this covers the Telcos as well"?.
That's how it's going to be, folks. OFCOM will be seen to be regulating the sexy, up-front, public-facing Ugly Sisers of the New Media, but the background, necessary-but-unspectacular Cinderella that is the Telcos marketplace will remain as FUBARed as usual, out of sight..
Errmm.... surely if his GPS data is encrypted with his private key then isn't that enough to "prove" that at least he believes that his GPS is with him?
The chain of trust is therefore:
Exchange public keys
Validate trust in public keys (as per normal)
Owner validates trust in GPS location
Owner encrypts / signs position information packet from GPS with private key
Receiver party validates postion against public key
At the end of this exchange, the receiver trusts that the owner believes s/he's in the position exchanged between them.
This doesn't cover the case that the authentic Owner is trying to spoof his location, but I don't believe that was the question - which I read as "How can I prevent someone masquarading as me from a remote location at a given time?"
I think you'll find that the technology demonstration gear in current use does indeed use off-the-shelf OS technology.... Certainly the UK's similar efforts were based on Windows OSes: You could see the logo in the eyepiece the guys were using on boot up.
However, recognise that there is a world of difference between the stage this equipment is at now - tech.demo / concept validation - and what'll get deployed.
This sounds like the same core problem as the US Army's Apache / Longbow upgrade suffered
The Longbow radar adds a similar degree of sensor improvement and comms. capability to the attack helicopter as Landwarrior is attempting to do for infantry.
Cost considerations aside, however, it was found that the average pilot/gunner under the current training / experience regime (especially in the National Guard) was having enough trouble keeping the helo in the air, let alone exploiting the sensor suite. The crashes in the Kosovo with the night sight equipment are for roughly the same reasons - insufficient preparation & experience leading to excessive workload & disorientation.
The net outcome was/is that the US Army per se is incapable of exploiting the capabilities provided by the Shiny New Toys. I believe current doctrine has now 1 Longbow radar equipped Apache per flight, with the others data-linked in - i.e. there's effectively a command & control Helo and "n" supplementary weapons carriers.
A related question... What is Transmeta's MIPS-per-Watt rating?
This was the metric used by Psion to select the StrongARM processor for the Series 5 and successor PDAs. A rather enlightened means of guesstimating which architecture to tie oneself into, I thought...
This is an honest question posing as a troll/flamebait.
Given recent history, is this activity illegal under the DMCA? It would certainly appear to be reverse engineering, and I'm wondering whether Sun could claim (fairly or not) that they've implemented "technical measures" to prevent such. I'm not suggesting they would, but I would be interested to know whether The Collective views this as a possibility?
The key point in the Benchmarking wars here is that current benchmarks don't reflect the core feature of the Crusoe technology.
For years and years and years (back thru i386 / 486 times), all that's happened is that the x86 instruction set has been executed quicker by successive processors. Modulo some trickiness with pentium instruction pipelining, benchmarks executed on a i386 16MHz (in Protected mode) are directly comparable to the same benchmark executed on a P4 1.5Ghz. The code goes in, the processor munches it, the results come out.
Wheras the Crusoe has this clever new feature where the code is analysed in realtime and optimisations made to popular code. This implies a benchmark will execute quicker second time round.
Now add in all the power saving optimisation and you can see that the current benchmarks - winBench et al - which are designed on a fairly simplistic basis, do not effectively translate to the usage model Crusoe-based systems are designed around.
So, by all means read them benchmarks, but the basic point applies: the only meaningfull benchmark is the one that executed *your* desired workload on the *exact* proposed hardware.
That's generally why Big Iron manufacturers are prepared to spend months of time, and throw many many people at providing demo services to potential customers. I know of one big BIG bid situation where a team of 50 was provided an *entire* cutting-edge mainframe, together with middleware developers and given 3 months to work with the customer to implement their exact application (minus some error handling and fluff, natch) specifically for the purposes of a benchmark. The potential benefits of the bid far, far outweighed this not-inconsiderable cost, obviously.
Where was I? Oh yes: Benchmarks are useless. go out and get 1 of each candidate system, and put it through your proposed usage profile. Then decide which is better. Most corporations do this as a matter of course - and you Joe Schmoe individual consumer aren't important enough to worry about so you'll get what Big Q says you can have (and you'd better be grateful).
Hmmm.. So Mac OSX = BSD + Nice GUI. And the article reveals that (modulo freely available dev tools) it's a full BSD port.
So... I can use Linux/BSD + XFree + KDE/Gnome and play the Catchup-with-continuous-development game, or I can get a nice shiny easy to use Mac, get the benefit of (theoretically) 15 yrs worth of legacy Apps, *and* the cutting-edge of Open software fresh from the labs.
Slashdot Mirror
There's no way of putting this without seeming:
...But, you have heard of "apt-get source xxx", right?
(Very VERY usefull in the frequently-named dependency-conflict situations above: Don't have a version of "foo" that works with "bar-1.2.3-10"? "apt-get -b source foo".....
I thought it only fair to respond to the many replies to my message above.
Most of these responses have focussed on technical means to prevent a repetition. Needless to say I have my doubts about the feasibility and suitability of most of these but that's irrelevent.
I should have originally stated this more clearly rather than reacting, but it is my firm belief that the solutions to these issues lies overwhelmingly in the human domain, not the technical domain.
I'd love to live in a world where geeks don't even need to devote their prodigious problem-solving skills to issues of this kind, and the only way to bring that about is consideration from the ground-up of the human issues here.
From organisational and chain-of-command matters through to foreign policy and human rights: This atrocity was NOT caused by guns, knifes, cost-cutting by aircraft manufacturers or lack of available technolog. And it will not be resolved through those means.
Flame away.
Up until yesterday you'd have been a fool to take that risk. By sitting still and doing exactly as the hijacker said you'd have stood an excellent chance of making it out alive and unharmed.
What happened yesterday is totally without precedent and it would be unwise to make such a drastic policy and procedural change [carrying guns on commercial flights] without considering first what other measures might be more appropriate and secondly whether the additional risks incurred [of carrying weapons] are matched by a corresponding increase of overall safety.
Sadly I have no idea of a feasible means of measuring such an impact without waiting for it to happen again and plotting statistical graphs. How very depressing.
Go read The Risks Digest. Then come back and explain in great and convincing detail how you've solved the problems of managing technical complexity and especially it's interface to the human element in automated control systems such as you're proposing.
I don't know the solution to this problem, but it's in the human domain, not the technical.
An interesting idea. Let's consider some implications
One: what on EARTH makes you think that any of the planning and execution of this disgusting atrocity involved any digital communications or indeed any other form of information which is amenable to Number Crunching?
Two: It's not called the "Web of a Thousand Lies" for nothing. Anyone surfing for verifiable info in the last 36 hours is familiar with this concept. Discriminating "Wheat" from "Chaff" is not a solved problem at this time
Three: You and I and the rest of the Clan here are active in a field of endeavour unique amongst the human experience as being immature, incomplete, and above all unreliable. Assuming points 1 and 2 can be dealt with satisfactorily, your bonus question becomes: How do you convince those who Need to Know that you've actually derived some usefull data?
I'm sorry. I can't see how this helps.
I have two points for your consideration:
Firearms on civil aircraft... nope, that's a scary idea. Try Again.
I don't think you have any idea how much such views under any circumstances scare the bejesus out of me and many other people.
Regardless of any justification, righteous anger and emotional response I urge you to consider one very very simple point: How would acting on such an impulse or (horror) reasoned response make you any better that those you seek vengence on?
If you want to be the good guys, you have to act like good guys.
I'm in the UK, and I have no PVR. This is a comment regarding motive & conclusions, not facts.
In that vein, and regardless of my feelings about the gentleman concerned, under the circumstances I am very prepared to cut him some slack. I wouldn't trust myself to get a 4-word sentence out straight if placed in a similar situation. Any assistance the man needed to get the right words out to the world would be very astute and appropriate.
All IMHO, obviously....
With all due deference to your inside knowledge, Hogwash.
The building was hit by a 767. Taking the first google'd link (http://www.sasflightops.com/fleet/767_general.htm ) we see it has a max all-up weight of 185 metric tons.
A 707 (see here) has a takeoff weight of 150 tonnes.
Both of these are large lumps of metal and jet fuel moving at high velocity. Given the failure mode of the buildings, and the time to do so under a direct hit, I don't think 30 tonnes would have made a hell of a lot of difference.
To any building.
This is a very partisan approach to the issue. Success for Linux in the market place is not tied to the financial success of it's most well-known distro. It may not even be linked to RedHat's success.
I also believe you have mis-understood the fundamental premise on which one company may choose to support another. Let's take a worked example:
IBM is a global IT provider. And it has a very strong presence in non-US markets. It may surprise you to find that those markets have different requirements to the US. In particular, support for other languages & keyboards is higher on the priority list. And there are Distros that do indeed recognise this and cater for it: SuSE is one (mainly European) and TurboLinux is another (mainly Asia-Pacific).
As a result of this, these Distros are much more popular in their respective geographies than RedHat. MUCH more popular. (and not only for "good" reasons: there's as much senseless product jingoism in the computer biz as there is in any other (e.g. all those pissing-on-ford/chevvy badges one can observe on trucks in the US).
As a result of this effect, Linux's penetration world-wide is increased over and above that which would be observed if there was only One True Distro. And IBM therefore has a bigger global market into which it can sell it's value-add services and products.
It can therefore be observed that this isn't altruism on the part of these companies, it's just plain business sense: support the infrastructure that provides your ability to sell. RedHat is a part of, but by no means all of, that infrastructure, globally, and it behoves us all to remember that.
True comments, for the browser. However, the mail&news client is still, on my PII-300MHz Linux system, juuust on the barely-acceptable side of unusably slow.
And still refuses to check ALL imap folders for new messages automatically.
YMMV
Speaking as an ex-AIX worshipper (I have now been converted to the One True OS and it's apt-get luvin' incarnation), IBM JFS has one MAJOR attraction for me: ease of filesystem modification.
I haven't tried JFS/Linux yet, but after years of expanding filesystems on production systems without outage ("chfs -a size=+blocks /fs/mount/point"), porting this to Linux is all it'll take me to switch. Performance? Pah! nice to have, but if you're reliant on FS performance you need to splurge a few beans on more memory. Ease of administration is the major win with JFS here folks....
Sadly, this was the most believable part of the entire book.
One to skip... Oh, and "Moonseed" too. "Voyage" isn't bad though (as the first in his "let's reuse existing space hardware" series which you have to admit isn't nearly as snappy a title as his previous "Xeelee Sequence" novels)
I think you're right. Also I think there's an error in the original story.
In most articles on the subject, the adjective "small" is not found anywhere near the quantifier "1 megaton"....
(megaton-class Nukes tend to be fusion hence expensive and big. "tactical" nukes which are smaller and lighter and pure fission or fission-boosted are in the 10-500 *Kilo*ton range).
Seconded! Now if only there wasn't such a lead-time I'd suggest a few other places to wipe out.
Milton Keynes. West Midlands (ALL of it). Basingstoke. Bracknell.
Come on kids, join in! It's fun to destroy towns...
Disclaimer: I know nothing of intentions. The following is drawn from observations
MWave isn't just a modem. It's a generalised DSP solution; effectively a DSP co-processor. Originally, way-back-when on the 750/760 even series Thinkpads, the MWave chip provided soundcard support (SoundBlaster Pro emulation I believe) and Modem support; the MWave chips ran a mini-multitasking OS that would time-slice these tasks so you could play Doom online thru the modem and still hear sound. There were some obvious drawbacks to this approach - IIRC if you wanted 33.6K modem dialups you had to fallback from stereo to mono 22KHz soundcard.
I believe the design point was that soundcard+modemcard cost more than MWave and thus the total system cost was cheaper; the side-effects of a software upgradeable soundcard and modem were secondary.
Some of the Aptiva model desktop PCs also got the full MWave for sound + modem (or was it sound only? I forget).
What I don't understand is why in newer Stinkpads (such as the models referred to by the article), the MWave hardware (presumably in cut-down form) is only used for modem function; the sound card function is provided by a standalone chipset (uur... CS4236+ I believe). This Makes No Sense to me.
Does anyone else who can organise thoughts more coherently have any better insights into the history here?
Disclaimer: I am only a recent convert to the One True Distribution, having previously been an inhabitant of SuSE and Slackware Lands.
Debian is indeed a fine, fine distro. And a model of what is required for high-granularity packaging, with all the benefits that brings - Especially for the net-connected with their I-want-it-now update needs. But I'd venture to suggest that it's not the ultimate in user interaction and consistency when it comes down to the how of selecting, installing and configuring packages.
For instance, as a relatively new user with much more experience of rpm or tarball-extraction, I'm still struggling with apt-get's Maze of Twisty Turny Dependencies. Fr'instance: how the hell do I get gimp-1.1.29 installed with xsane? apt-get is forever telling me I need to de-install gimp to install xsane; I *can* replace it with gimp1.1-xsane but only for gimp 1.1.17. This is for 2 packages I *know* can integrate, cos I've done it on SuSE (rpm -i gimp, rpm -i xsane, RTFM & create links in ~/.gimp-1.1/modules as needed, et voila bob's yer uncle).
Presumably I can override dependencies and prevent removal of shiny new gimp, and I dare say that if I could bring myself to launch dselect again there'd even be a psuedo-menu based system for letting me do that, but why should I? This example leads me to believe that we, the great unwashed Debian User masses are at the mercy of the Fickle Masters of Packaging and their dependency whims...
This is a trivial whine in the grand scheme of things, but like the man said - You want Linux for the masses, it's got to be damn-fool-proof. In this case, I'd venture to suggest that this means that both a more friendly interface is required (dselect? Just Say No. Especially to das bluddy awful dependency correction), and an independent (of the packagers) comb-through the thousands of .deb out there to validate dependencies before burning to CD.
Nice sentiment. It won't happen though.
Did you notice the coverage of this announcement last night? How it covered just about all aspects of the proposed regulator as they apply to the media with a little byline saying "oh this covers the Telcos as well"?.
That's how it's going to be, folks. OFCOM will be seen to be regulating the sexy, up-front, public-facing Ugly Sisers of the New Media, but the background, necessary-but-unspectacular Cinderella that is the Telcos marketplace will remain as FUBARed as usual, out of sight..
Just mark this -1 Unwarranted Cynicism
Errmm.... surely if his GPS data is encrypted with his private key then isn't that enough to "prove" that at least he believes that his GPS is with him?
The chain of trust is therefore:
At the end of this exchange, the receiver trusts that the owner believes s/he's in the position exchanged between them.
This doesn't cover the case that the authentic Owner is trying to spoof his location, but I don't believe that was the question - which I read as "How can I prevent someone masquarading as me from a remote location at a given time?"
I think you'll find that the technology demonstration gear in current use does indeed use off-the-shelf OS technology.... Certainly the UK's similar efforts were based on Windows OSes: You could see the logo in the eyepiece the guys were using on boot up.
However, recognise that there is a world of difference between the stage this equipment is at now - tech.demo / concept validation - and what'll get deployed.
This sounds like the same core problem as the US Army's Apache / Longbow upgrade suffered
The Longbow radar adds a similar degree of sensor improvement and comms. capability to the attack helicopter as Landwarrior is attempting to do for infantry.
Cost considerations aside, however, it was found that the average pilot/gunner under the current training / experience regime (especially in the National Guard) was having enough trouble keeping the helo in the air, let alone exploiting the sensor suite. The crashes in the Kosovo with the night sight equipment are for roughly the same reasons - insufficient preparation & experience leading to excessive workload & disorientation.
The net outcome was/is that the US Army per se is incapable of exploiting the capabilities provided by the Shiny New Toys. I believe current doctrine has now 1 Longbow radar equipped Apache per flight, with the others data-linked in - i.e. there's effectively a command & control Helo and "n" supplementary weapons carriers.
Can anyone see the parallels here?
A related question... What is Transmeta's MIPS-per-Watt rating?
This was the metric used by Psion to select the StrongARM processor for the Series 5 and successor PDAs. A rather enlightened means of guesstimating which architecture to tie oneself into, I thought...
This is an honest question posing as a troll/flamebait.
Given recent history, is this activity illegal under the DMCA? It would certainly appear to be reverse engineering, and I'm wondering whether Sun could claim (fairly or not) that they've implemented "technical measures" to prevent such. I'm not suggesting they would, but I would be interested to know whether The Collective views this as a possibility?
The key point in the Benchmarking wars here is that current benchmarks don't reflect the core feature of the Crusoe technology.
For years and years and years (back thru i386 / 486 times), all that's happened is that the x86 instruction set has been executed quicker by successive processors. Modulo some trickiness with pentium instruction pipelining, benchmarks executed on a i386 16MHz (in Protected mode) are directly comparable to the same benchmark executed on a P4 1.5Ghz. The code goes in, the processor munches it, the results come out.
Wheras the Crusoe has this clever new feature where the code is analysed in realtime and optimisations made to popular code. This implies a benchmark will execute quicker second time round.
Now add in all the power saving optimisation and you can see that the current benchmarks - winBench et al - which are designed on a fairly simplistic basis, do not effectively translate to the usage model Crusoe-based systems are designed around.
So, by all means read them benchmarks, but the basic point applies: the only meaningfull benchmark is the one that executed *your* desired workload on the *exact* proposed hardware.
That's generally why Big Iron manufacturers are prepared to spend months of time, and throw many many people at providing demo services to potential customers. I know of one big BIG bid situation where a team of 50 was provided an *entire* cutting-edge mainframe, together with middleware developers and given 3 months to work with the customer to implement their exact application (minus some error handling and fluff, natch) specifically for the purposes of a benchmark. The potential benefits of the bid far, far outweighed this not-inconsiderable cost, obviously.
Where was I? Oh yes: Benchmarks are useless. go out and get 1 of each candidate system, and put it through your proposed usage profile. Then decide which is better. Most corporations do this as a matter of course - and you Joe Schmoe individual consumer aren't important enough to worry about so you'll get what Big Q says you can have (and you'd better be grateful).
Hmmm.. So Mac OSX = BSD + Nice GUI. And the article reveals that (modulo freely available dev tools) it's a full BSD port.
So... I can use Linux/BSD + XFree + KDE/Gnome and play the Catchup-with-continuous-development game, or I can get a nice shiny easy to use Mac, get the benefit of (theoretically) 15 yrs worth of legacy Apps, *and* the cutting-edge of Open software fresh from the labs.
Is this is future of UNIX-for-the-masses?