Still, it would be nice to give an airline the chance to compete on something other than cost.
Some of the newer airlines, like JetBlue, provide much nicer and pleasenter service - and they are making money.
The other option is to build an airline with small airplanes (like Eclipse) and create a airline network that takes advantage of the thousands of smaller airports around the US to provide faster door-to-door transportation.
Um actually, as the article mentioned briefly, the wright's approach to airplane control was all wrong. They used an approach called wing-warping which deformed the entire wing in order to control the plane. This guy use ailerons which are used in modern planes because they are mechanically simpler and more aerodynamically efficient.
The use of wing-warping vs. ailerons is just an implementation detail. The Wrights discovered, what is now called "adverse aileron yaw", they understood it and figure out how the rudder must be used to counter balance the adverse yaw.
This was a fundamental discovery/invention that enabled airplanes to turn. The Wrights realized that to turn the airplane must bank (sort of like a bicycle rider need to bank during a turn), and then they found the adverse yaw during their experiments (in fact, the adverse yaw caused several crashes of their gliders).
The adverse yaw is cause by the wing that's on the outside of the turn creating more drag, than the inside wing. This causes the airplane's nose to yaw towards outside of the turn, and the airplane winds up "falling out" of the turn.
The Wrights figured how to use the rudder together with their wing warping (their controls were connected - like they are in the F-16 today) so that the compensation for the yaw was automatic.
Actually, the Wrights had done plenty of glider flying experiments in 1901 and 1902, getting their control system worked out. In the process they beat most of the world glider flying records set by Lilienthal years before.
The flight in 1903 was the first powered flight.
The achievement of the Wright's was that they took a scientific approach to the problem of flight (eg. they invented the wind tunnel in the process) and that they were the ones who actually figured out how to control an airplane in flight.
Hmm, how many hops would that take to get a packet across the US on such a network, and how many would get lost? Even
if it was a mile per hop, that's a lot of hops. I don't see that as being a very good network.
There is still work to be done with these sorts of protocols...:-)
Tell that to my cordless phone! I have 5 devices running on my 802.11b network and for one ifyou're on the phone at the
computer you can watch your signal go all to hell. If you are near the microwave while it's on, your signal is shot to heck, and
every once and a while the the phone nails the DSS of the WLAN and you get a loud static burst out of the earpiece.
That's jsut means that those device do not follow the protocol that you Wi-Fi cards do. We have 20 wireless laptops in the office and they don't interfere with each other...
Imagine a wireless mesh network covering the whole continent. Now you can get your data from one of the country to the other without going through any wires at all!
If the routers are simply devices that everyone owns, and if enough of them are on all the time, you have a free connection between any of those devices.
If you need more bandwidth we only need to allocate a large part of the spectrum (after all the spectrum belongs to the public and corps just rent it - let's evict them).
Now throw in voice over IP and you have free telephone connections everywhere (just buy the right kind of hand set).
I can think of whole bunch of other uses, and I'm sure there are people with better imagination than me.
If everyone is going with WiFi (which I take to be just 802.11b), won't the freqency spectrum saturate in a short period of time?
No. Wi-Fi devices all share the same swatch of frequencies for all the transmission. Wi-Fi devices send very short time pulses spread over a bunch of frequencies (more frequencies, more bandwidth).
Because each pulse is short in time, the collisions are unlikely - so it works like Ethernet where many devices share the same physical medium.
For WAN type of transmissions, everyone's computer has to become a router, so that the actual radio transmission needs to cover short distances and data is forwarded between adjacent computers.
Only three? I can name a million: VMS, OS 360, Windows NT,...
I'm not really sure that these would qualified, as these are pretty modular systems, so each component is it's own project. So, writing device drivers is quite different from kernel development.
7. Graphic 'diff' programs to view the differences between files and versions of files.
Now I am going to go all out and say that ClearCase has the suckiest diff routines and tools ever foisted on mankind. I have
personally witnessed a number of terrible mistakes on the part of the automerge process, and the "Graphical Tool" used to
merge is the worst merge tool I have ever seen.
I use CC now and I completely agree with you. The graphical merge tool is horrbile.
I use ClearCase mode in Xemacs and use the Emacs diff - it's much much better.
Would you characterise XP as being against the idea of reuse, at least reference-based reuse?
Not at all. XP is for re-use. But in XP you discover reuse through refactoring. So, in XP you don't develop the "general problem solver", rather you write code to solve your current problem.
When you get to the next problem and you see similarities, you factor the common code out.
So with XP you not only get re-usable pieces, but you get pieces that are actually re-used.
One problem I have seen trying to make "generic software tools" is that to make them truely generic it seems one has keep adding features and bloating up the interface to cover all possible wants of each client (user).
What I see is that most "generic" tools become so generic, as to be completely useless. I think one of the reasons Extreme Programming is catching on, is that it does away with this concept and advocates building the simplest thing that will work.
Imagine trying to create a "generic bridge building toolkit". Certainly there are standard components from which bridges are built (i.e. bolts etc), but the idea of a generic bridge toolkit is silly.
I'm the last person to bash any engineer for their work, but I get real tired of hearing how software engineers aren't "real" engineers.
I agree. Software engineering is engineering as real as it gets. The problem is that the science of computing is way behind the actual practice of programming.
When one is building a circuit, or a bridge, one can't simply make quick changes. Any changes are ltime consuming, expensive, and painful. Thus, REAL engineers actually plan stuff.
Planning does not necessarily solve the problem. Even in bridge construction.
In the 19th century there were a lot of iron bridge failures in England and the US, because metal fatigue wasn't understood well. Since bridges needed to be build, the engineer's hacked and bridges crashed (see "To Engineer is Human").
But once this is done, and we've come up with some fun and clever stuff, we roll up our sleeves and do real engineering to build a real product.
If you ignore the human relations in Solaris, you're missing a lot. At its core, Solaris is about communication between *humans* -- and about mortality and divinity. The contact-with-aliens stuff is just the mechanism through which this is explored.
The cool thing about Lem that his books are multi-dimensional. The love story is very human, but there is a lot of pondering on the question of "communicating" with the ocean.
Perhaps the point of the book is that human to human communication is hard enough, forget trying to communicate with alien intelligence.
In general, one may actually have more questions after finishing the book than he had in the beginning. BTW, Lem is one of such authors. Philip Dick is another.
Lem is not afraid to tackle the real difficult questions in his books. For example, the problem of communication with another lifeform/species is far from trivial and Lem gets into it in a number of his books.
"The Invincible" - encounter with a "swarm" of machines?
"Solaris" - forget the love story. Is the ocean alive in any sense that humans could understand?
"His Master's Voice" - a message (?) is received from outer space. People trying to decipher it (this is not at all like "Contact").
"Fiasco" - humans visit the first other civilization. Communications doesn't happen.
Orson Scott Card comes close to this topic with "Speaker for the Dead" - where there is a weird cultural conflict. But most other SF authors just gloss over this issue, in Star Trek "Universal Translator" style...
What is needed is selection comparible to a video store, with a reasonable view time (at least 48 hours for new releases, and 7 days for old stuff to mimic the video stores). Quality has to at least equal VHS. As long as the price is competitive, going to the video store is going to become a thing of the past for all but the completely unconnected.
This is just stupid. It's like building a car that uses reins and has a horse head in the front for steering.
In ten years I'm going to have enough storage on my laptop to keep all movies released since 1929. Why would I want to stream stuff and waste bandwidth, or get digital copies that disappear after few days.
A better business model is needed for selling digital works - I'm willing to pay, butI don't want to be subjected to insane control restrictions.
For all I know, not implementing these DRM things will save more money (think, no MS license fees), than would be "lost" to copyright violations.
Probably the biggest improvement is due to the creation of software processes, whether it is the legacy waterfall or the latest XP
I disagree. "Sotware process" is nothing without a bunch of smart developers. I think the idea of "Software Process" has been more harmful that useful - as people who do not understand what software creation is all about, blindly apply process to a random collections of "resources" and expect good results.
There were some studies done on which teams are most productive (see "Peopleware" or "Software Creativity") and the teams with loose process and no schedules were the ones that did best.
For a construction project all of these elements are mapped out well in advance, which is why the construction industry can work on lower margins.
Just to nitpick on this particular myth. In construction there is the idea of "fast-path" construction, where building starts before the design is done.
The idea that all requirements and design are done before construction starts is a myth.
People hack buildings too. There were some famous cases of building "bugs" (eg. CityCorp skyscrapper wasn't stiff enough) or famous failures where design or implementation errors caused a building collapse.
Read "To Engineer is Human" and "Design Paradigms" by Henry Petroski for a start.
Slashdot Mirror
It's a great book. I have the hardcover edition. :-)
Remember "extraordinary claims require extraordinary proof".
Some of the newer airlines, like JetBlue, provide much nicer and pleasenter service - and they are making money.
The other option is to build an airline with small airplanes (like Eclipse) and create a airline network that takes advantage of the thousands of smaller airports around the US to provide faster door-to-door transportation.
The use of wing-warping vs. ailerons is just an implementation detail. The Wrights discovered, what is now called "adverse aileron yaw", they understood it and figure out how the rudder must be used to counter balance the adverse yaw.
This was a fundamental discovery/invention that enabled airplanes to turn. The Wrights realized that to turn the airplane must bank (sort of like a bicycle rider need to bank during a turn), and then they found the adverse yaw during their experiments (in fact, the adverse yaw caused several crashes of their gliders).
The adverse yaw is cause by the wing that's on the outside of the turn creating more drag, than the inside wing. This causes the airplane's nose to yaw towards outside of the turn, and the airplane winds up "falling out" of the turn.
The Wrights figured how to use the rudder together with their wing warping (their controls were connected - like they are in the F-16 today) so that the compensation for the yaw was automatic.
The flight in 1903 was the first powered flight.
The achievement of the Wright's was that they took a scientific approach to the problem of flight (eg. they invented the wind tunnel in the process) and that they were the ones who actually figured out how to control an airplane in flight.
There is still work to be done with these sorts of protocols... :-)
That's jsut means that those device do not follow the protocol that you Wi-Fi cards do. We have 20 wireless laptops in the office and they don't interfere with each other...
The current technology does. But with little more power you can have longer transmission ranges.
Imagine a wireless mesh network covering the whole continent. Now you can get your data from one of the country to the other without going through any wires at all!
If the routers are simply devices that everyone owns, and if enough of them are on all the time, you have a free connection between any of those devices.
If you need more bandwidth we only need to allocate a large part of the spectrum (after all the spectrum belongs to the public and corps just rent it - let's evict them).
Now throw in voice over IP and you have free telephone connections everywhere (just buy the right kind of hand set).
I can think of whole bunch of other uses, and I'm sure there are people with better imagination than me.
No. Wi-Fi devices all share the same swatch of frequencies for all the transmission. Wi-Fi devices send very short time pulses spread over a bunch of frequencies (more frequencies, more bandwidth).
Because each pulse is short in time, the collisions are unlikely - so it works like Ethernet where many devices share the same physical medium.
For WAN type of transmissions, everyone's computer has to become a router, so that the actual radio transmission needs to cover short distances and data is forwarded between adjacent computers.
Google: UWB and Mesh Networks.
I'm not really sure that these would qualified, as these are pretty modular systems, so each component is it's own project. So, writing device drivers is quite different from kernel development.
Now I am going to go all out and say that ClearCase has the suckiest diff routines and tools ever foisted on mankind. I have personally witnessed a number of terrible mistakes on the part of the automerge process, and the "Graphical Tool" used to merge is the worst merge tool I have ever seen.
I use CC now and I completely agree with you. The graphical merge tool is horrbile.
I use ClearCase mode in Xemacs and use the Emacs diff - it's much much better.
OK. Name three.
Hmm. Have you tried ArgoUML?
Other than that, do you really find UML diagrams useful beyond sketches on a white board?
Not at all. XP is for re-use. But in XP you discover reuse through refactoring. So, in XP you don't develop the "general problem solver", rather you write code to solve your current problem.
When you get to the next problem and you see similarities, you factor the common code out.
So with XP you not only get re-usable pieces, but you get pieces that are actually re-used.
What I see is that most "generic" tools become so generic, as to be completely useless. I think one of the reasons Extreme Programming is catching on, is that it does away with this concept and advocates building the simplest thing that will work.
Imagine trying to create a "generic bridge building toolkit". Certainly there are standard components from which bridges are built (i.e. bolts etc), but the idea of a generic bridge toolkit is silly.
I agree. Software engineering is engineering as real as it gets. The problem is that the science of computing is way behind the actual practice of programming.
Planning does not necessarily solve the problem. Even in bridge construction.
In the 19th century there were a lot of iron bridge failures in England and the US, because metal fatigue wasn't understood well. Since bridges needed to be build, the engineer's hacked and bridges crashed (see "To Engineer is Human").
But once this is done, and we've come up with some fun and clever stuff, we roll up our sleeves and do real engineering to build a real product.
And how would you define "real engineering"?
Yeah, but that's in dog years...
The cool thing about Lem that his books are multi-dimensional. The love story is very human, but there is a lot of pondering on the question of "communicating" with the ocean.
Perhaps the point of the book is that human to human communication is hard enough, forget trying to communicate with alien intelligence.
Lem is not afraid to tackle the real difficult questions in his books. For example, the problem of communication with another lifeform/species is far from trivial and Lem gets into it in a number of his books.
Orson Scott Card comes close to this topic with "Speaker for the Dead" - where there is a weird cultural conflict. But most other SF authors just gloss over this issue, in Star Trek "Universal Translator" style...
This is just stupid. It's like building a car that uses reins and has a horse head in the front for steering.
In ten years I'm going to have enough storage on my laptop to keep all movies released since 1929. Why would I want to stream stuff and waste bandwidth, or get digital copies that disappear after few days.
A better business model is needed for selling digital works - I'm willing to pay, butI don't want to be subjected to insane control restrictions.
For all I know, not implementing these DRM things will save more money (think, no MS license fees), than would be "lost" to copyright violations.
I disagree. "Sotware process" is nothing without a bunch of smart developers. I think the idea of "Software Process" has been more harmful that useful - as people who do not understand what software creation is all about, blindly apply process to a random collections of "resources" and expect good results.
There were some studies done on which teams are most productive (see "Peopleware" or "Software Creativity") and the teams with loose process and no schedules were the ones that did best.
Just to nitpick on this particular myth. In construction there is the idea of "fast-path" construction, where building starts before the design is done.
The idea that all requirements and design are done before construction starts is a myth.
People hack buildings too. There were some famous cases of building "bugs" (eg. CityCorp skyscrapper wasn't stiff enough) or famous failures where design or implementation errors caused a building collapse.
Read "To Engineer is Human" and "Design Paradigms" by Henry Petroski for a start.