'The teams' challenge was to collectively create a mobile-game masterpiece using a "mystery ingredient" -- random verbs and nouns -- to guide design.'"
Sounds like just another day with Marketing to me.
Re:Glad to see menu editing has been fixed
on
Gnome 2.14 Released
·
· Score: 1
Can you add *any* old program/shell script/symlink as a menu item with that menu editor? Because the one I have, on FC5, only allows me to enable or disable existing applications, not add a new app that it does not know about.
Glad to see menu editing has been fixed
on
Gnome 2.14 Released
·
· Score: 1, Insightful
I am so glad to see that Gnome 2.14 has fixed menu editing, so that ordinary users can add applications to the Gnome menu rather than having to clutter up the desktop with icons that will inevitably be hidden by windows.
After all, such a simple feature being missing really made Gnome look bad compared to Windows....
Wait, I am being handed a message........
Menu editing *hasn't* been fixed? Users still cannot edit the application menus in a sane, convenient fashion?....
Here's a silly question - what is wrong with simply providing Internet access at places like the public library, and allowing all citizens (and gasp! even non-citizens) to use that?
That way, even people who have no fixed address (from the homeless to full-time RVers) can also find the local public library.
This reminds me of the good old days - the late 80's to early 90's, to be exact, when games came on floppy disks and companies like Psygnosis were well-known for the execution-protection, err, copy-protection on their games.
In fact, my friends and I had a saying - "Psygnosis - Latin for won't boot".
Good to see the youngsters will get to enjoy that experience. Of course, back in the day, when you were done playing the game you rebooted your computer and the system was back to normal - you didn't have the games leaving little turdlets behind like they do now.
Kids today. Always have to go us old farts one better.
As the other reply to your post stated - if an AM station is not bandlimiting their signal to 10 kHz or less, they are in violation of their FCC license, and will get a hefty fine and/or get shut down if the FCC catches them.
However, the other response is incorrect - you CANNOT put a modulating signal of more than 5kHz bandwidth onto an A3E carrier without exceeding 10 kHz bandwidth. Moreover, the emissions mask for an AM station (the frequency vs. amplitude plot they are not allowed to exceed) is not a simple rectangle 10 kHz wide - there are "shoulders" at +/- 3kHz, and the spectrum MUST then roll off by a number of dBc in order to not be in violation.
Well, "twice as close" would place the signals at 5 kHz spacing, which for A3E would mean 2.5 kHz max signal bandwidth - which would worse fidelity. I would respectfully submit that you may have been wrong in your observation - either the signals weren't closer together or the signals in question were pure-digital IBOC signals (if you drop the analog compatibility you can get quite a bit of data in a 5kHz bandwidth).
The reason I suspect the signals you were listening to were pure digital is that Europe has a much higher adoption rate for newer radio technologies, especially in the AM dial, for a couple of reasons:
A single AM station can cover most of your average Western European country - so they have a very high listenership (and thus lots of money for new gear).
The Western Europeans don't have the older cars like we do here in the States - so you get more turnover in car radios (one of the primary markets for AM).
The hypothesis that the signals were digital would also explain the increased fidelity and greater range.
Yes, you can use phase modulation of the carrier to carry information - that's the "...a lot of trouble...." that I spoke of in my previous post. There are tricks, such as using a quadrature modulated carrier (carrier at 90 degrees phase shift to the main carrier).
I design radio test equipment for a living - so welcome to Modulation Theory 101.
Amplitude modulation, or more correctly double-sideband non-suppressed carrier amplitude modulation (FCC emission type A3E), results in an RF spectrum that is twice as wide as the highest frequency component of the modulating signal. In other words, if the signal you are modulating has as its highest frequency component 3kHz (normal voice signals), then the resulting AM signal will occupy 6 kHz of RF spectrum - from 3kHz below the nominal carrier frequency to 3 kHz above the nominal carrier.
Now, we have to consider the concept of "receiver bandwidth". A properly designed radio receiver will only pick up signals within a given frequency difference of where it is tuned (the "tuned frequency" or TF) - this is the receiver bandwidth (sometimes referred to as "IF bandwidth" since in modern superheterodyne receivers it is the bandwidth of the narrowest intermediate frequency section that determines the overall receiver bandwidth).
Now, consider the case of 2 radio stations spaced such that their carriers are 10 kHz apart - the normal spacing for AM radio stations. Assume your radio is tuned to one of the stations. If your radio has a receiver bandwidth of 20 kHz (in other words receiving signals from 10 kHz below tuned frequency to 10 kHz above tuned frequency), you would hear the station you *weren't* tuned to as a 10 kHz whine on your radio (the carrier of the other station, 10 kHz off your tuned frequency), plus the audio of the other station inverted in frequency (low tones become high tones and vise versa).
So, your radio has to have a narrow filter to receive only those signals within 5 kHz of tuned frequency (total 10 kHz). Now, a perfect "brick wall" filter would allow, say, 4 kHz through, but stop 4.00001 kHz dead. Now, filters are not perfect, and so if your filter allows signals from, say, 4 kHz away from TF, then it will not totally block signals until they are, say, 6 kHz from TF. So, radios are designed to allow signals +/- 3kHz from TF in (receiver bandwidth of 6kHz), and block signals more than 5 kHz from TF.
OK, now, how do we add any new signals to the A3E signal so that we can put the digital signal in place? We cannot place those signals within 3kHz of the carrier without going to a LOT of trouble, otherwise analog radios will "hear" the digital signal as noise. So what IBOC does is exploit that "no man's land" from 3kHz away from carrier to 5kHz away from carrier to put the digital signal in. Now, your old analog radio will still "hear" these signals to an extent, but between the attenuation of the receiver bandwidth and the attenuation of the audio chain, this noise will not be very perceptible.
HOWEVER - remember how I said there were no perfect "brick wall" filters? Well, that applies to transmitters too. The transmitter may be putting signal into the 3 kHz to 5 kHz region, but it will put some unwanted signals beyond 5kHz (they will just be very weak compared to the desired signals) - and that means into the frequency band of the next guy on the dial. However, if the next guy is far enough away in space, your signals that are in his band (which are already weak) will be weakened further by distance, and won't be perceptible by the other guy's listeners. Also, your signals that are in the 3kHz to 5kHz area will be weakened by distance, and attenuated by the receiver's filters, and so they, too, won't be very objectionable.
Except in the fringes between where your spatial region stops and his starts. That's what is happening here - if you are close to "the other guy" you won't hear the interference, but if you are far from him, and close to the digital station - you get noise where there was none before.
Add to this the fact that the stations that are going digital are the stations with money - and how do you get money? By having lots of listeners. How do you get lots of listeners? Among other things, by having lots of POWER <Tim Allen Grunt>. The little station
This could be a blessing in disguise, if the composition of the rock is largely metals rather than being just stone - it could force us to intercept it and mine it for the resources to avert it, forcing us to develop the technology and skills needed to mine other asteroids.
Also - a large impact would lower temperatures a lot....
Simple. It is all about locking-in the computer vendors to Microsoft.
Microsoft says to the vendor, "If you will put this 'We recommend Microsoft Windows' line in ALL of our advertising, we will pay you $$$ out of our advertising budget." The amount paid is large - large enough to pay for a good chunk of the vendor's advertising.
However, the catch is that ALL ADS, bar none, must have this logo. So even is what is being sold is a Linux server, the "We recommend Microsoft" has to appear. Also, the vendor is STRONGLY discouraged from advertising anything else - they cannot, for example, say "We recommend Microsoft Vista or RedHat Enterprise Linux" (emphasis mine).
So, vendors like Dell receive very large sums of money for those blurbs.
In short, it is a way around the banned practice of "per CPU license fees" that Microsoft used to do before the anti-trust decisions.
Too damn many of you are missing the point of his question.
He does not want to store all of his code in the wiki.
He wants to set it up so that when a programmer CREATES a wikipage on a function, he can include source code FOR A SAMPLE INVOCATION of the function and have that code be nicely formatted, syntax-highlighted and so on without the programmer having to to do it all by hand.
In other words:
Write function "foo"
Write Wikipage on "foo", detailing function parms, conditions, exceptions, etc.
Write sample code for calling "foo" in his normal programming editor (and hopefully test it to insure it works!)
Paste tested sample code into wiki.
Preview, and behold the syntax highlighted, formatted, and preferably automatically wikilink-ified code.
Now, I am sure that he wouldn't mind it if there were some form of Doxygen-style "Code goes in here, and initial versions of wikipages come out here" interface, so that you could start from the Doxygen generated pages and then annotate them better.
I think Microsoft is subscribing to the "Pokemon" school of marketing - they are banking on developers feeling they "gotta catch'em all".
Consider: you develop for Windows. You now have to test your app against between 1 to 6 versions of Vista (depending upon your target market). If you are targeting ALL Vista users, you now have to check against 6 version of Vista - and thus have to BUY six versions.
Consider: You support Windows (e.g. ISP, IT department, hardware vendor). You have to test against 6 versions of Vista.
The only plus is that the virus and script kiddie tool writers will ALSO have to test against six versions of Vista.
It is what I call The Selfish Principle - that a collaborative operation is most successful when every member has a very selfish reason for contributing. Sad, but true.
Consider free software - I'll use Wine as an example. The Wine joystick drivers didn't work. I fixed them - not because of some enlightened idea of "giving back to the community", but because *I needed them to work* - I had a very selfish reason for spending my time to make them work. I then contributed my changes back, again not for some enlightened reason, but because doing so saved me from having to merge my changes back into the code every time an update happened.
Consider this post - I am making it not because of some enlightened desire, but because it is my belief that if people will accept these suppositions as true, that they will better structure online collaborations and that I will have access to better tools.
In other words, there is nothing intrinsically *wrong* with selfishness so long as you are considering how your actions affect others and pick options that benefit them (or at least don't harm them) as well as benefiting yourself - enlightened self-interest.
Now, let us consider Wikipedia - what is *my* motivation for, say, improving the article on Big Brutus. I already know about Big Brutus, and so there is little advantage to me to improve the article. The only advantage to me is ego boost - the joy of seeing my article be lauded as a great article. Now, do you really want an encyclopedia written by a bunch of egotists?
Divide, and conquer - DON'T do the whole app in C++. Split the back-end, the part that does the heavy lifting and uses all the libraries you have in C++. Define (AND DOCUMENT) the interface between the back-end and the front-end GUI - use something like a socket or a pipe or some other form of interprocess communications to tie them together.
Do the front-end (the GUI) separately. If you want to stay with C++, great, otherwise, use whatever language makes the front-end easier.
GUIs are hard - they have to be asynchronous, and that makes design and debugging a bitch. From what little you have described, the back-end should be fairly straightforward from a code flow perspective - get data, process data, return results - no event handlers, no callbacks.
Given the split, you can unit test the back-end a lot more simply, and test for all the corner cases. Unit testing a GUI is hard - again, testing all the async events is a bitch.
Design the back-end so that if the GUI "goes away", the back-end can continue to operate - preferably allowing the front-end to reconnect to the back-end and pick up where you left off.
Other than that, here are some general rules I follow in C++:
Never instantiate a variable until you can initialize it - if that means you define a variable in the middle of a function then do so.
Use lots of local scopes - you can insert a "{ }" anywhere, and create a scope, with its own variables. This both helps the optimizer know where a variable is used, and it helps the programmer know, too.
Keep functions as small as possible.
Treat pointers like guns - keep them pointed in a safe direction (i.e. at an object or at NULL), never make any assumptions about whether they are loaded or not (check for NULL), keep them away from children (junior programmers) by keeping them locked up safely inside objects.
Where-ever possible, use the "allocation is construction" idiom: If you need to allocate a resource, such as a socket, or mutex, or whatever, create a class object that allocates the resource on construction and releases it on destruction. That way, you can instantiate that object as an auto variable, and when that variable goes out of scope the resource is released, no ifs, ands or buts. It is also released if any exceptions are thrown. One of the reasons I don't like Java is that this idiom won't work due to Java's lazy destructor policy.
Last but not least - use ASSERT and other logical checks LIBERALLY in the code. If you are making an assumption TEST IT in the code. Track where you are - objects that are passed the __FILE__ and __LINE__ parameters to track who did what where will help you immensely in testing your code.
The field reversals of the earth are in many ways similar to the solar sunspot cycle. Sunspots are places where the sun's magnetic field is "tangled up", and happen as the sun's field reverses.
The same sort of "tangles" will happen as the earth's field reverses - the only difference is that since the earth is not undergoing nuclear fusion, we won't see "earthspots".
However, I wonder what will happen to the earth's magnetosphere and ionosphere as the flux lines break and reconnect - on the sun that is what causes solar flares as the energy contained in the twisted flux lines is released. Will the released energy from the earth's flux lines reconnecting be dumped into the ionosphere? Will they cause even more dramatic aurora?
I don't seem to be able to get to the article - something about their annoying advertising and my refusal to send referrers or accept cookies. Anybody have a mirror or another link to the court's filing?
Ahh, the wonders of Moore's Law. This device is more powerful than my current laptop (yes, it is a very old laptop) - they only edge my laptop has is in mass storage. I'd love to replace my laptop with one of these, save for only one problem - a lack of mapping software.
At least with my current x86 laptop, I can run Delorme's mapping software under Wine. However, since the Nokia device is NOT x86 that option is not open.
Yes, I *could* use Google Maps. Except that would require me having a live Internet connection while moving down the highway, and except that Google maps does not do multiple point routes very well, and Google maps does not update very quickly, and....
Nokia is a big enough company they could go to one of the map software companies and negotiate for a license to port the software to this device - that, and a Bluetooth GPS and that would settle it for me.
For you early adopters who are going to be interviewed by Nokia - could you put a word in for this feature?
(before you suggest just buying a GPS with mapping built in - most of those run US$700 or more. They are not a multi-function device, and they STILL suck at computing a route).
Slashdot Mirror
Some things in life are free. For everything else, there's extortion.
'The teams' challenge was to collectively create a mobile-game masterpiece using a "mystery ingredient" -- random verbs and nouns -- to guide design.'"
Sounds like just another day with Marketing to me.
Can you add *any* old program/shell script/symlink as a menu item with that menu editor? Because the one I have, on FC5, only allows me to enable or disable existing applications, not add a new app that it does not know about.
I am so glad to see that Gnome 2.14 has fixed menu editing, so that ordinary users can add applications to the Gnome menu rather than having to clutter up the desktop with icons that will inevitably be hidden by windows.
....
....
....
After all, such a simple feature being missing really made Gnome look bad compared to Windows
Wait, I am being handed a message....
Menu editing *hasn't* been fixed? Users still cannot edit the application menus in a sane, convenient fashion?
Never mind.
Here's a silly question - what is wrong with simply providing Internet access at places like the public library, and allowing all citizens (and gasp! even non-citizens) to use that?
That way, even people who have no fixed address (from the homeless to full-time RVers) can also find the local public library.
This reminds me of the good old days - the late 80's to early 90's, to be exact, when games came on floppy disks and companies like Psygnosis were well-known for the execution-protection, err, copy-protection on their games.
In fact, my friends and I had a saying - "Psygnosis - Latin for won't boot".
Good to see the youngsters will get to enjoy that experience. Of course, back in the day, when you were done playing the game you rebooted your computer and the system was back to normal - you didn't have the games leaving little turdlets behind like they do now.
Kids today. Always have to go us old farts one better.
As the other reply to your post stated - if an AM station is not bandlimiting their signal to 10 kHz or less, they are in violation of their FCC license, and will get a hefty fine and/or get shut down if the FCC catches them.
However, the other response is incorrect - you CANNOT put a modulating signal of more than 5kHz bandwidth onto an A3E carrier without exceeding 10 kHz bandwidth. Moreover, the emissions mask for an AM station (the frequency vs. amplitude plot they are not allowed to exceed) is not a simple rectangle 10 kHz wide - there are "shoulders" at +/- 3kHz, and the spectrum MUST then roll off by a number of dBc in order to not be in violation.
The reason I suspect the signals you were listening to were pure digital is that Europe has a much higher adoption rate for newer radio technologies, especially in the AM dial, for a couple of reasons:
The hypothesis that the signals were digital would also explain the increased fidelity and greater range.
Yes, you can use phase modulation of the carrier to carry information - that's the "...a lot of trouble...." that I spoke of in my previous post. There are tricks, such as using a quadrature modulated carrier (carrier at 90 degrees phase shift to the main carrier).
I design radio test equipment for a living - so welcome to Modulation Theory 101.
Amplitude modulation, or more correctly double-sideband non-suppressed carrier amplitude modulation (FCC emission type A3E), results in an RF spectrum that is twice as wide as the highest frequency component of the modulating signal. In other words, if the signal you are modulating has as its highest frequency component 3kHz (normal voice signals), then the resulting AM signal will occupy 6 kHz of RF spectrum - from 3kHz below the nominal carrier frequency to 3 kHz above the nominal carrier.
Now, we have to consider the concept of "receiver bandwidth". A properly designed radio receiver will only pick up signals within a given frequency difference of where it is tuned (the "tuned frequency" or TF) - this is the receiver bandwidth (sometimes referred to as "IF bandwidth" since in modern superheterodyne receivers it is the bandwidth of the narrowest intermediate frequency section that determines the overall receiver bandwidth).
Now, consider the case of 2 radio stations spaced such that their carriers are 10 kHz apart - the normal spacing for AM radio stations. Assume your radio is tuned to one of the stations. If your radio has a receiver bandwidth of 20 kHz (in other words receiving signals from 10 kHz below tuned frequency to 10 kHz above tuned frequency), you would hear the station you *weren't* tuned to as a 10 kHz whine on your radio (the carrier of the other station, 10 kHz off your tuned frequency), plus the audio of the other station inverted in frequency (low tones become high tones and vise versa).
So, your radio has to have a narrow filter to receive only those signals within 5 kHz of tuned frequency (total 10 kHz). Now, a perfect "brick wall" filter would allow, say, 4 kHz through, but stop 4.00001 kHz dead. Now, filters are not perfect, and so if your filter allows signals from, say, 4 kHz away from TF, then it will not totally block signals until they are, say, 6 kHz from TF. So, radios are designed to allow signals +/- 3kHz from TF in (receiver bandwidth of 6kHz), and block signals more than 5 kHz from TF.
OK, now, how do we add any new signals to the A3E signal so that we can put the digital signal in place? We cannot place those signals within 3kHz of the carrier without going to a LOT of trouble, otherwise analog radios will "hear" the digital signal as noise. So what IBOC does is exploit that "no man's land" from 3kHz away from carrier to 5kHz away from carrier to put the digital signal in. Now, your old analog radio will still "hear" these signals to an extent, but between the attenuation of the receiver bandwidth and the attenuation of the audio chain, this noise will not be very perceptible.
HOWEVER - remember how I said there were no perfect "brick wall" filters? Well, that applies to transmitters too. The transmitter may be putting signal into the 3 kHz to 5 kHz region, but it will put some unwanted signals beyond 5kHz (they will just be very weak compared to the desired signals) - and that means into the frequency band of the next guy on the dial. However, if the next guy is far enough away in space, your signals that are in his band (which are already weak) will be weakened further by distance, and won't be perceptible by the other guy's listeners. Also, your signals that are in the 3kHz to 5kHz area will be weakened by distance, and attenuated by the receiver's filters, and so they, too, won't be very objectionable.
Except in the fringes between where your spatial region stops and his starts. That's what is happening here - if you are close to "the other guy" you won't hear the interference, but if you are far from him, and close to the digital station - you get noise where there was none before.
Add to this the fact that the stations that are going digital are the stations with money - and how do you get money? By having lots of listeners. How do you get lots of listeners? Among other things, by having lots of POWER <Tim Allen Grunt>. The little station
This could be a blessing in disguise, if the composition of the rock is largely metals rather than being just stone - it could force us to intercept it and mine it for the resources to avert it, forcing us to develop the technology and skills needed to mine other asteroids.
Also - a large impact would lower temperatures a lot....
Simple. It is all about locking-in the computer vendors to Microsoft.
Microsoft says to the vendor, "If you will put this 'We recommend Microsoft Windows' line in ALL of our advertising, we will pay you $$$ out of our advertising budget." The amount paid is large - large enough to pay for a good chunk of the vendor's advertising.
However, the catch is that ALL ADS, bar none, must have this logo. So even is what is being sold is a Linux server, the "We recommend Microsoft" has to appear. Also, the vendor is STRONGLY discouraged from advertising anything else - they cannot, for example, say "We recommend Microsoft Vista or RedHat Enterprise Linux" (emphasis mine).
So, vendors like Dell receive very large sums of money for those blurbs.
In short, it is a way around the banned practice of "per CPU license fees" that Microsoft used to do before the anti-trust decisions.
He does not want to store all of his code in the wiki.
He wants to set it up so that when a programmer CREATES a wikipage on a function, he can include source code FOR A SAMPLE INVOCATION of the function and have that code be nicely formatted, syntax-highlighted and so on without the programmer having to to do it all by hand.
In other words:
Now, I am sure that he wouldn't mind it if there were some form of Doxygen-style "Code goes in here, and initial versions of wikipages come out here" interface, so that you could start from the Doxygen generated pages and then annotate them better.
OK, folks? Got it?
Good.
Now, comment.
I think Microsoft is subscribing to the "Pokemon" school of marketing - they are banking on developers feeling they "gotta catch'em all".
Consider: you develop for Windows. You now have to test your app against between 1 to 6 versions of Vista (depending upon your target market). If you are targeting ALL Vista users, you now have to check against 6 version of Vista - and thus have to BUY six versions.
Consider: You support Windows (e.g. ISP, IT department, hardware vendor). You have to test against 6 versions of Vista.
The only plus is that the virus and script kiddie tool writers will ALSO have to test against six versions of Vista.
Good analysis - may I add my own?
It is what I call The Selfish Principle - that a collaborative operation is most successful when every member has a very selfish reason for contributing. Sad, but true.
Consider free software - I'll use Wine as an example. The Wine joystick drivers didn't work. I fixed them - not because of some enlightened idea of "giving back to the community", but because *I needed them to work* - I had a very selfish reason for spending my time to make them work. I then contributed my changes back, again not for some enlightened reason, but because doing so saved me from having to merge my changes back into the code every time an update happened.
Consider this post - I am making it not because of some enlightened desire, but because it is my belief that if people will accept these suppositions as true, that they will better structure online collaborations and that I will have access to better tools.
In other words, there is nothing intrinsically *wrong* with selfishness so long as you are considering how your actions affect others and pick options that benefit them (or at least don't harm them) as well as benefiting yourself - enlightened self-interest.
Now, let us consider Wikipedia - what is *my* motivation for, say, improving the article on Big Brutus. I already know about Big Brutus, and so there is little advantage to me to improve the article. The only advantage to me is ego boost - the joy of seeing my article be lauded as a great article. Now, do you really want an encyclopedia written by a bunch of egotists?
Divide, and conquer - DON'T do the whole app in C++. Split the back-end, the part that does the heavy lifting and uses all the libraries you have in C++. Define (AND DOCUMENT) the interface between the back-end and the front-end GUI - use something like a socket or a pipe or some other form of interprocess communications to tie them together.
Do the front-end (the GUI) separately. If you want to stay with C++, great, otherwise, use whatever language makes the front-end easier.
GUIs are hard - they have to be asynchronous, and that makes design and debugging a bitch. From what little you have described, the back-end should be fairly straightforward from a code flow perspective - get data, process data, return results - no event handlers, no callbacks.
Given the split, you can unit test the back-end a lot more simply, and test for all the corner cases. Unit testing a GUI is hard - again, testing all the async events is a bitch.
Design the back-end so that if the GUI "goes away", the back-end can continue to operate - preferably allowing the front-end to reconnect to the back-end and pick up where you left off.
Other than that, here are some general rules I follow in C++:
Never instantiate a variable until you can initialize it - if that means you define a variable in the middle of a function then do so.
Use lots of local scopes - you can insert a "{ }" anywhere, and create a scope, with its own variables. This both helps the optimizer know where a variable is used, and it helps the programmer know, too.
Keep functions as small as possible.
Treat pointers like guns - keep them pointed in a safe direction (i.e. at an object or at NULL), never make any assumptions about whether they are loaded or not (check for NULL), keep them away from children (junior programmers) by keeping them locked up safely inside objects.
Where-ever possible, use the "allocation is construction" idiom: If you need to allocate a resource, such as a socket, or mutex, or whatever, create a class object that allocates the resource on construction and releases it on destruction. That way, you can instantiate that object as an auto variable, and when that variable goes out of scope the resource is released, no ifs, ands or buts. It is also released if any exceptions are thrown. One of the reasons I don't like Java is that this idiom won't work due to Java's lazy destructor policy.
Last but not least - use ASSERT and other logical checks LIBERALLY in the code. If you are making an assumption TEST IT in the code. Track where you are - objects that are passed the __FILE__ and __LINE__ parameters to track who did what where will help you immensely in testing your code.
Real men use their Swiss Army Knife to punch holes in punch cards.
Real MANLY men use the needle of their Swiss Army Knife, which they have magnetized, to directly write the domains on the disk.
Real OLD MANLY men use the needle of their Swiss Army Knife to directly write to the cores of their memory array.
The field reversals of the earth are in many ways similar to the solar sunspot cycle. Sunspots are places where the sun's magnetic field is "tangled up", and happen as the sun's field reverses.
The same sort of "tangles" will happen as the earth's field reverses - the only difference is that since the earth is not undergoing nuclear fusion, we won't see "earthspots".
However, I wonder what will happen to the earth's magnetosphere and ionosphere as the flux lines break and reconnect - on the sun that is what causes solar flares as the energy contained in the twisted flux lines is released. Will the released energy from the earth's flux lines reconnecting be dumped into the ionosphere? Will they cause even more dramatic aurora?
They missed some far more interesting characters:
Gregory "Elephant" Pelton, hier to the Jumpshift teleportation fortune, from Niven's Known Space universe.
"Hotblack" Desiato, lead singer from Disaster Area.
Woodrow Wilson Smith, a.k.a. Lazarus Long. (being exceptionally long lived does have its benefits when ammassing wealth).
In the same vein, Mr. "Flint" from ST:TOS.
Many of the "Intel Inside", "Designed for Microsoft Windows", and such stickers are great for putting on urinals and public toilets.
/. strips the &tm; entity?)
Or, slap them on the back or sides of a ricercar when nobody is looking - obviously an "Intel Inside" sticker must be good for another 20HP.
(OT: did you know that
I don't seem to be able to get to the article - something about their annoying advertising and my refusal to send referrers or accept cookies. Anybody have a mirror or another link to the court's filing?
Actually, it was mentioned. Several times. Go re-read my original post. I several times mention "routing".
Yes, I agree - that looks like just the ticket. Now, if either a) we can pursuade Nokia to pursue this or b) pursuade Mapopolis to do this....
Unlike the Delorme packages, GPSDrive is nothing but a map display - it has no ability to compute a route, only show you where you are.
Ahh, the wonders of Moore's Law. This device is more powerful than my current laptop (yes, it is a very old laptop) - they only edge my laptop has is in mass storage. I'd love to replace my laptop with one of these, save for only one problem - a lack of mapping software.
At least with my current x86 laptop, I can run Delorme's mapping software under Wine. However, since the Nokia device is NOT x86 that option is not open.
Yes, I *could* use Google Maps. Except that would require me having a live Internet connection while moving down the highway, and except that Google maps does not do multiple point routes very well, and Google maps does not update very quickly, and....
Nokia is a big enough company they could go to one of the map software companies and negotiate for a license to port the software to this device - that, and a Bluetooth GPS and that would settle it for me.
For you early adopters who are going to be interviewed by Nokia - could you put a word in for this feature?
(before you suggest just buying a GPS with mapping built in - most of those run US$700 or more. They are not a multi-function device, and they STILL suck at computing a route).