Sure, it looks likely that he passed this information onto his new employer, but unless you are the defendant, how can you be so sure?
Exactly. Over the last few years, WestJet has been a textbook case in terms of how to set up and run a profitable airline even in times when global airline travel took a (figurative) nosedive. Clive Beddoe (WestJet CEO) is a savvy businessman - it seems to me that if he and/or his legal department were aware of this kind of stuff going on, they'd punt the idiot that was responsible just to avoid the exact kind of allegations we're seeing now. WestJet was already Air Canada's favorite excuse for all its woes - I doubt that they would sanction anything borderline like this, which would only give legitimacy to Air Canada's griping.
How will an MP3 recording help?
on
Giant Sub-Woofer
·
· Score: 1
Recording the sound produced by that and then compressing it to MP3 (and playing it back on some tinny sound system) is unlikely to give anything even close to what it's really like. You'll just have to book a trip to Italy...
Getting in the news equals free airtime, which equals funding dollars from the government. The profit angle is bunk, because it would take several thousand tourists to recoup the billions of dollars pumped into the space program as a whole.
At $20million a pop, the current crop (is three a crop?) of space tourists would have made a much bigger impact on the space industry by putting their money into John Carmack's, Rutan's, or one of the other X-prize ventures.
If software becomes putting lego blocks together... someone will still have to make lego blocks that help you do what you want. There will be new lego blocks that do what you need in one brick, where you needed four bricks to do it the old way. And, you'll sometimes have to arrange it so you only have blue bricks on the outside where people can see them.
Silly metaphor, but there are a lot of underlying parallels. It's how you use the bricks that makes a Lego thing work well, not whether or not you made the bricks yourself.
Interesting notion... What I find is that if I can draw out a problem, whether it's mechanical, hardware, or software, then I can figure out a way to solve it. If I can make a clear drawing, then the solution is likely to be straightforward (that doesn't mean it won't be a lot of work, though). The big issue with making the drawings manageable is to have the right level and types of abstraction in the components, and probably the biggest failing of OO related teaching these days is the inability to get across a coherent method for determining what should be an object and what constitutes a 'class' of objects.
When I was taking my EE degree we took two courses specifically on computer science related topics. One of them required little coding assignments to demonstrate the application of a principle, and assignments in the other one would usually grow into multiple thousands of lines. Of the two, the bigger assignments were usually a lot more instructive - if you screw up the architecture of a big system, it hurts you a lot more than getting it wrong on a little one. It's the doing that gives the long-term memory retention, not the reading.
You need to harness the kinetic energy of the photons in the laser beam such that it doesn't just turn into heat... pretty hard to do given the range and acceleration you're required to achieve. Solar sails could eventually be used to accelerate interplanetary hardware but most of the concepts these days envision effective sail areas of multiples (hundreds?) of square km.
I would think that a big motivation for this would be time to orbit, as in: If you get into the queue today at any of the existing space agencies, when will your piece of hardware actually achieve orbit? Having a low-cost, fast-turnaround operation allows quicker replacement of failed space hardware. Hopefully (as others have lamented) this won't result in a rash of space junk cluttering the LEO corridors.
But the chances are that your clothes are going to be screaming "I am size M shirt serial number 162731527281 from the Gap" and "Levis 501's #1241432", which means there is no conflict at all - any item of clothing could be uniquely identified, given that you can get 64-bit IDs on current RFID technology. Unique clothing tags uniquely identify the wearer.
Not true. If you can scan an ID off my jacket, you can tell that I go past your scanner X times per week. That information alone can be useful. If you further determine that the tag ID group corresponds to a particular brand, then you know a little more. If you tie your RF reader to a computer with a camera, then you can get my picture. Now you know that the person that looks like me, goes past a certain location at a certain time.
Here's a nice scenario: Some loser finds the ID group for kids' clothing, and then starts scanning for kids that regularly go by his location. This kind of thing CAN already be done with scanning cameras and feature recognition software, but having an automatic RFID reader tied into it would make the identification of repeat visitors easier by orders of magnitude.
Currently, a lot of clothes and boxed items end up with multiple anti-theft tags, and they're typically NOT on the price label - they're hidden so that prospective shoplifters can't easily remove them. If this thinking is extended to RFID tags, then the customer will be required to either get an EMP gun or spend a few hours sifting through the stitching on the stuff they buy in order to keep from being labeled everytime they approach an RFID reader.
Having the store use RFID tags to track inventory, and even using loyalty cards to determine your personal preferences, is pretty much a per-transaction exposure.
But when you buy a set of clothes, you should be able to get any and all ID tags contained within that clothing deactivated, to prevent you becoming a walking RF billboard.
A tactile (output) interface would be kinda cool - like an interactive Braille display. Definitely better (as an alternative to the traditional visual output) than audio or smell output.
They didn't say anything about the relative angle at which the asteroid would be approaching. Geostationary sats occupy a fairly narrow belt around the equator (see, for example, this applet - assuming your computer is less Java-hostile than mine) 3D satellite simulator
Any object approaching from angles significantly above or below the equator will have only a very small chance of nailing a geostationary satellite.
Then all the orbital energy gets bled off by the drag induced by the wing, which means it will have to absorb and then radiate that energy. You don't get something for nothing. As mentioned, though: For sub-orbital flight, the energy to be dissipated is minute compared to orbital re-entry.
A question: Is this design even intended as an orbital vehicle, or just a stepping stone (incidentally aimed at meeting X-prize requirements)? If it isn't intended to make it to orbital speeds, then there's no need to build in infrastructure that an orbital vehicle would need.
Another question (or two): What are the shallowest and steepest practical re-entry profile? If you could descend from orbit slowly enough, then you wouldn't need to decelerate at such a high rate that you would get the leading edge temperatures reached by the Shuttle. Then again, tearing through even the upper atmosphere at Mach 25 while trying to slowly burn off speed might cause too much heating. On the opposite end of the envelope, if one had sufficient retro-rocket capability, you could bleed off most of your orbital velocity while 100 km up, then freefall to an altitude where aerodynamic conditions are more friendly - but that would take a huge amount of fuel.
On the assumption that the Shuttle presents the state of the art in re-entry vehicles as it was 25 years ago, how have materials and fuels changed to push either end of the re-entry envelope (shallower vs. steeper)?
I don't have any handy links, but for the last half-dozen years or so, John Carmack has been putting a lot of effort into creating some very fast Ferraris. If nothing else that experience will have prepared him for the "well that idea didn't work, now what?" stage of development, as it applies to building physical things that are pushing the limits in terms of material properties. You can't just put in some bounds checking and then recompile after you grenade an engine, and Carmack has demonstrated a great deal of stamina in pushing the mechanical boundaries as well as the software ones.
As a regular eBay / PayPal user, I get these emails regularly - the first one had me thinking for a while, but logging into Ebay directly and doing some status queries quickly settled the situation. The later phish emails got way more brazen - they're asking for more personal information than eBay or PayPal ever did.
The basic rule of only supplying personal information when YOU are the originator of a Web transaction still applies, but as you say,
.. not to mention some way to get the average public to read them both.
... it's going to be hard to get everyone to think critically all the time.
That's pretty crass. I don't think that Clemens' comments were nearly as cynical as you're making them out to be there. All he's saying is that outside of a tight-knit community, there is NO value or recognition attached to the fact you're doing software as part of an open-source community, and unless you're planning to remain inside that community for the rest of your life, you should recognize that the rest of the world does not provide valuable services for free, and you will need to be able to compensate them in order to get stuff you need to live. Writing software for money is a good way to do that.
Before everyone gets all uppity: I think that when it comes to basic underlying architecture, there is no better way to ensure quality and performance, than to get lots of eyes on the the source code. In that respect, open source environments, where there are a large number of volunteers willing to scrutinize implementation details, will guarantee that lurking issues get addressed in due course.
But 'open' doesn't necessarily imply 'free'. As Clemens says, your skills are valuable, and while you're at a stage where coding is 'fun', being able to say 'all the Linux users are using my kernel mod' doesn't pay the rent.
Go read some of Henry Petroski's books (their titles escape me right now - there is one that opens with the failure of the hotel skybridge in Kansas City), and you'll see that civil engineering occasionally still has big gaps between the designer's intent and what actually gets screwed together.
On the software front, you are correct. Software eventually rots because it is usually "maintained" by continually applying patches as opposed to periodically taking a whole chunk and rewriting it to fit the new extended requirements.
Even when the latter happens, in a lot of cases the overall soundness of the implementation is compromised by the perceived need to maintain backwards compatability (e.g. why does the Borland Builder compiler use the 80386 instruction set by default, when almost any executable you are likely to build with it will be larger than the 386 can support?)
You don't need a Java environment to get caught in that trap. In about half of the bigger software projects I've been parachuted into, there were cases where race conditions, memory leaks, and other manifestations of bad design and/or implementation were "fixed" by writing tons of extra code to deal with all the exceptions, exceptions to the exceptions, and runtime issues caused by the extra code.
The thing that I see most often with 'intuitive' interfaces is, like some others have posted, that the interface will eventually be applied incorrectly, and then the problems that arise are fixed by massive amounts of testing and exception handling, instead of redesigning things properly. In the case of OO languages, that most often applies to people not understanding how to identify which constructs in their software should be treated or defined as objects.
My comment was on the previous poster's inference that the dime-level accuracy of his 1994 demonstration would probably have been improved by the availability of WAAS and/or the lack of SA, which is not the case since you can't get that level of accuracy using single point measurements to begin with, even with WAAS on and SA off.
Carrier-phase differential GPS and a low-multipath environment will get you centimeter-level accuracy. WAAS and SA being turned off help speed up the acquisition process but that's about all; the fundamental resolution achievable by GPS receivers (when used to measure carrier phase) is limited by the clock accuracy (satellite and receiver) and close-in multipath. For more information on GPS technology check out
GPS equipment manufacturer FAQs
Slashdot Mirror
Exactly. Over the last few years, WestJet has been a textbook case in terms of how to set up and run a profitable airline even in times when global airline travel took a (figurative) nosedive. Clive Beddoe (WestJet CEO) is a savvy businessman - it seems to me that if he and/or his legal department were aware of this kind of stuff going on, they'd punt the idiot that was responsible just to avoid the exact kind of allegations we're seeing now. WestJet was already Air Canada's favorite excuse for all its woes - I doubt that they would sanction anything borderline like this, which would only give legitimacy to Air Canada's griping.
Recording the sound produced by that and then compressing it to MP3 (and playing it back on some tinny sound system) is unlikely to give anything even close to what it's really like. You'll just have to book a trip to Italy...
That would be appropriate for just about any of Microsoft's recent ventures into the standards arena.
At $20million a pop, the current crop (is three a crop?) of space tourists would have made a much bigger impact on the space industry by putting their money into John Carmack's, Rutan's, or one of the other X-prize ventures.
Silly metaphor, but there are a lot of underlying parallels. It's how you use the bricks that makes a Lego thing work well, not whether or not you made the bricks yourself.
Interesting notion... What I find is that if I can draw out a problem, whether it's mechanical, hardware, or software, then I can figure out a way to solve it. If I can make a clear drawing, then the solution is likely to be straightforward (that doesn't mean it won't be a lot of work, though). The big issue with making the drawings manageable is to have the right level and types of abstraction in the components, and probably the biggest failing of OO related teaching these days is the inability to get across a coherent method for determining what should be an object and what constitutes a 'class' of objects.
When I was taking my EE degree we took two courses specifically on computer science related topics. One of them required little coding assignments to demonstrate the application of a principle, and assignments in the other one would usually grow into multiple thousands of lines. Of the two, the bigger assignments were usually a lot more instructive - if you screw up the architecture of a big system, it hurts you a lot more than getting it wrong on a little one. It's the doing that gives the long-term memory retention, not the reading.
You need to harness the kinetic energy of the photons in the laser beam such that it doesn't just turn into heat... pretty hard to do given the range and acceleration you're required to achieve. Solar sails could eventually be used to accelerate interplanetary hardware but most of the concepts these days envision effective sail areas of multiples (hundreds?) of square km.
I would think that a big motivation for this would be time to orbit, as in: If you get into the queue today at any of the existing space agencies, when will your piece of hardware actually achieve orbit? Having a low-cost, fast-turnaround operation allows quicker replacement of failed space hardware. Hopefully (as others have lamented) this won't result in a rash of space junk cluttering the LEO corridors.
But the chances are that your clothes are going to be screaming "I am size M shirt serial number 162731527281 from the Gap" and "Levis 501's #1241432", which means there is no conflict at all - any item of clothing could be uniquely identified, given that you can get 64-bit IDs on current RFID technology. Unique clothing tags uniquely identify the wearer.
Here's a nice scenario: Some loser finds the ID group for kids' clothing, and then starts scanning for kids that regularly go by his location. This kind of thing CAN already be done with scanning cameras and feature recognition software, but having an automatic RFID reader tied into it would make the identification of repeat visitors easier by orders of magnitude.
Currently, a lot of clothes and boxed items end up with multiple anti-theft tags, and they're typically NOT on the price label - they're hidden so that prospective shoplifters can't easily remove them. If this thinking is extended to RFID tags, then the customer will be required to either get an EMP gun or spend a few hours sifting through the stitching on the stuff they buy in order to keep from being labeled everytime they approach an RFID reader.
But when you buy a set of clothes, you should be able to get any and all ID tags contained within that clothing deactivated, to prevent you becoming a walking RF billboard.
A tactile (output) interface would be kinda cool - like an interactive Braille display. Definitely better (as an alternative to the traditional visual output) than audio or smell output.
Any object approaching from angles significantly above or below the equator will have only a very small chance of nailing a geostationary satellite.
A question: Is this design even intended as an orbital vehicle, or just a stepping stone (incidentally aimed at meeting X-prize requirements)? If it isn't intended to make it to orbital speeds, then there's no need to build in infrastructure that an orbital vehicle would need.
Another question (or two): What are the shallowest and steepest practical re-entry profile? If you could descend from orbit slowly enough, then you wouldn't need to decelerate at such a high rate that you would get the leading edge temperatures reached by the Shuttle. Then again, tearing through even the upper atmosphere at Mach 25 while trying to slowly burn off speed might cause too much heating. On the opposite end of the envelope, if one had sufficient retro-rocket capability, you could bleed off most of your orbital velocity while 100 km up, then freefall to an altitude where aerodynamic conditions are more friendly - but that would take a huge amount of fuel.
On the assumption that the Shuttle presents the state of the art in re-entry vehicles as it was 25 years ago, how have materials and fuels changed to push either end of the re-entry envelope (shallower vs. steeper)?
Go Armadillo!
The basic rule of only supplying personal information when YOU are the originator of a Web transaction still applies, but as you say,
Before everyone gets all uppity: I think that when it comes to basic underlying architecture, there is no better way to ensure quality and performance, than to get lots of eyes on the the source code. In that respect, open source environments, where there are a large number of volunteers willing to scrutinize implementation details, will guarantee that lurking issues get addressed in due course.
But 'open' doesn't necessarily imply 'free'. As Clemens says, your skills are valuable, and while you're at a stage where coding is 'fun', being able to say 'all the Linux users are using my kernel mod' doesn't pay the rent.
Even when the latter happens, in a lot of cases the overall soundness of the implementation is compromised by the perceived need to maintain backwards compatability (e.g. why does the Borland Builder compiler use the 80386 instruction set by default, when almost any executable you are likely to build with it will be larger than the 386 can support?)
The thing that I see most often with 'intuitive' interfaces is, like some others have posted, that the interface will eventually be applied incorrectly, and then the problems that arise are fixed by massive amounts of testing and exception handling, instead of redesigning things properly. In the case of OO languages, that most often applies to people not understanding how to identify which constructs in their software should be treated or defined as objects.
My comment was on the previous poster's inference that the dime-level accuracy of his 1994 demonstration would probably have been improved by the availability of WAAS and/or the lack of SA, which is not the case since you can't get that level of accuracy using single point measurements to begin with, even with WAAS on and SA off.
Carrier-phase differential GPS and a low-multipath environment will get you centimeter-level accuracy. WAAS and SA being turned off help speed up the acquisition process but that's about all; the fundamental resolution achievable by GPS receivers (when used to measure carrier phase) is limited by the clock accuracy (satellite and receiver) and close-in multipath.
For more information on GPS technology check out GPS equipment manufacturer FAQs
So tape a golf pin to the moose, and then you can use your BYP500.