You are aware that there are still some 707 and 727s in service, right? :)

The reason they landed at Manchester was not because they burned more fuel, but it was because they thought that the fuel on the outer wing tank on the wing that had the shut down engine on was inaccessible - this turned out to be false, they could have made it all the way to LHR without issue.

That entirely depends on the use you have for the aircraft - high oil price or not, no aircraft has the CASM of the A380 (not even the proposed 777X), which puts it in a league of its own. Consequently, the 747-8 falls foul to the 777 so the sole VLA competitor to the A380 would be killed by its own sibling...

Oil can go through the roof, but if you can fill an A380 then thats the aircraft you need for the job. You can't shoehorn 600 into a 777 no matter how hard you try.

Fully aware of the KC-X contest, NG was the prime contractor but it was actually Airbus that did all the work.

The KC-X contest was only ran because Boeing got caught firstly trying to lease replacement tankers to the USAF at a rate which was several times more than they cost to buy, and then Boeing got caught in the first round buying the Airbus bid details from the US DOD procurement officer in charge of the bids.

Even with a US prime contractor and a US assembly line, there was massive uproar over the fact that Airbus had won the second round of bidding, before it got out back out to tender and Boeing magically found a way to make the 767 offering several billion dollars less than their previous bid...

There is no way the US political arena would accept a non-American plane as AF1. Which raises an interesting problem when the next replacement comes round...

The 747-8 has new engines, a new wing definition and loft, new winglets, new avionics and significant aerodynamic improvements across the board. The only thing left to do is switch construction to CFRP or another modern material, and its cheaper to do an all new aircraft for that as you have to redesign the framework completely for the new material loading. The -8 will be the last 747.

Plus, while iconic, the 747 carries a lot of unnecessary weight around due to its short upper deck (there is a lot of wasted dead space behind that hump in commercial aircraft, so much so that they considered putting a dozen sleeping berths up there), so compared to single deck aircraft or the A380 its not as well optimised weight wise for its structure.

average user wont be able to, but many hobbiest users will.

once the code is done and an example circuit is created, its just copy and paste. hell, I'd do a sample just for grins. I find the whole idea WRONG to put limits in the code like this, so I'd be happy to write some sample code that will remap gps data on a serial line. but seriously, its not at all hard.

There will be hundreds of 747s flying for the next three to four decades, so parts are not an issue - Boeing makes the majority of its money on aftermarket care and parts, they won't close those lines down fast.

Also, Airbus refused to submit a proposal for this when approached several years ago (while there was no bidding process, basic proposals were requested from both Airbus and Boeing) because they knew it was a no contest decision.

gps modules almost always use low speed serial (ttl) comms.

it would be trivial (50 lines of C code, maybe much much less) to have a cpu (even attiny) in the middle between the gps module and the rest of the brain. when the x,y values come back and its inside a 'nfz' it could easily be remapped (in simple ascii) to NOT be in nfz. perhaps if you are near a nfz, it would go into auto-offset mode and add a fixed x,y value so that it thinks its miles away. then you compensate for it at the ground level when you program its course.

would not be hard at all.

waste of time to try to disallow x,y values for things like this. anyone here who spent a few weeks on even a simple arduino could do this remapping in an afternoon.

*secure* is my big issue, these days. without security being well thought out, iot stuff can be a disaster. and I'm not seeing a lot of thought (not really) being put into the whole iot stuff, which worries me a lot.

snmp is a red herring. it won't ever be used for iot and doesn't make sense there, other than to manage the systems that hold the sensors. (speaking as a seasoned snmp guy who spent 25+ yrs doing snmp for lots of big co's).

one data point for you: in the Eiot stuff that I worked on (e = enterprise) we used 'usb sensors' (analog and digital sensors that went to an a/d dongle, then into usb, then into a usb-ip bridge of sorts). this feed power (poe) to the sensors using existing poe infra at big companies and you only have to have cat5 cables to get power and ip connectivity to your sensors.

iot is a superset and includes low-end stuff (for us consumers) and high-end stuff for industry; and when its for industry, its 'eiot'.

(ob disc: I spent some 25+ yrs in the SNMP field; now working in IoT, at least I was until my last gig finished)

snmp has absolutely zero to do with IoT. snmp is a good (...) netmgt protocol that is very lightweight, standard (well...) and has been around for a few decades. as you know, its poller-based, mostly, with traps there as accelerants to help pollers zoom in, faster, to any events worth knowing about. snmp sucks for streaming loads of data upwards and really has no mechanism for that. has no mechanism for filtering at its source or data compression for transport.

what you want for IoT is to have, essentially, endless streams of source data going thru 'smart filters' along the way (last place I was at, we used 'hacked routers' to do our smart filtering) and then getting to some analysis node. the node may just collect data or it may run some rules and decide if a 'talk back' is needed or some control/feedback loop to change something in the real world.

the 2 cases are really different. snmp is 'slow' and never EVER realtime (not even traps, technically) and is mostly poller based (req/response). IoT is 'transmit continuously' based and MUST have low latency and a reliable (tcp) transport for all its crucial data points.

sorry, but IoT is nothing - NOTHING - about cellphones or mobile data. those come from USERS. this is not about USER data. its about DEVICE data.

think 'sensors' and you will be headed in the right direction.

right. and one solution (that home users won't like but industry will) is to use usb sensors.

huh? yeah, usb sensors. and usb/ip transports. and PoE for power.

lower end sensors are analog. a cpu will convert it to digital and stream it to some remote sink.

mid-end sensors will be digital (pure) or digital-usb (transported).

high-end sensors will be native ip-based.

all 'ends' are covered.

internet of things (from what I've seen, working on it at a big-name comms company) is all about SENSORS and REALTIME data.

if you are streaming loads of sensor data to some sink, somewhere, that is the current classic example or use-case of IoT.

expect this to be worked out more in industry than at the consumer level. the consumer level is getting the buzz (at forums like this) but in industry, they are talking about expensive sensors (high end a/d systems that robots depend on), power over ethernet to distribute power to the sensors and also ip connectivity, along with (believe it or not) usb-over-ip routing to send sensor data over ip networks.