"Pieces of snake/alligator/crocodile skins are scattered all over the mountain. In picking up a plane part for a closer look, often there would be crocodile hide on or near the part. They are in such abundance that we actually became quite sick of them as we combed the field for the black box.
...
While we don’t think this is the sole reason for the bungling of the investigation immediately following the crash (10 months before an expedition was mounted!), these illegal animal skins are part of a larger pattern of smuggling illegal goods on Eastern Airlines commercial flights. Someone in the organization was making money on these sketchy practices. If some of this money found its way to the right pockets, it would been easy to delay the appropriate investigational response until many feet of snow/ice covered the crash site."
I worked in cargo for a Latin American airline in the 1970's. Our fleet consisted solely of 727's. Back then, cargo prices were regulated. Our cargo operations paid for the airline's costs; passengers were profit. Even without passengers we paid the bills. Also, keep in mind that the aircraft would pick up passengers in Bolivia who were going to Miami. If you were in Paraguay flying to Bolivia there were a lot of better local choices than waiting for the flight from Miami.
For those interested, Bill Hammack (Engineer Guy) pulled apart a 1970s-era flight recorder in an old video.[1] The one in video, though, gets etched to a roll of tin rather than recorded to a magnetic tape.
What's on the last picture is mostly casing. They seem to have found a magnetic roll that hopefully contains data, but there's some risk they found nothing
It looks to be from a VHS tape. Also, a Cockpit Voice Recorder (CVR)/Flight Data Recorder (FDR) would likely be setup to record in a loop. You can do that with magnetic tape, but not in the configure it appears to be in.
I'll try to remember to look up what CVR would have been used for that plane when I get back to work in a week.
[EDIT:] In other words, Wikipedia seems to be the last vestige of the dumb old "separate web for mobile" mindset of ideas like WML. Media queries are just better, and would prevent this inane "that link sucks for half of us; here's one that sucks for the other half" crap.
As someone else said, "responsive" sometimes means loading both versions of a site and being readable for both desktop and mobile. If Wiki Desktop has a lot of features or content that shouldn't get loaded on mobile, it's a bit trickier to do that. Although I agree, at least some kind of media detect/redirect may be in order.
If Wiki Desktop has a lot of features or content that shouldn't get loaded on mobile...
Except it doesn't.
The whole idea behind the iPhone's browser was to avoid the need for crappy "mobile" versions of web sites. It's a crying shame that this vision had to fail because a bunch of underemployed web developers were obsessed with fixing things that were no longer broken.
I don't undertand why the mobile version doesn't have a link to the talk page. For some articles it's a very useful additional reading to the main page.
I'm sorry, what? Last vestige? That's not even close to being correct. Off the top of my head, here are some websites that still have a separate mobile domain: YouTube, Facebook, Reddit, Twitter, and a whole host of smaller websites as well. Granted, many of these do some kind of automatic redirect, so that you're redirected to the appropriate domain for the device you're using regardless of the link you follow. But none of them do the kind of responsive-design-and-media-query approach that you're talking about to differentiate between desktop and mobile.
The reason for a separate mobile site is that we can transfer less data over the wire. mobile sites typically aren't as feature filled as the desktop sites.
Bandwidth isn't the issue as much as latency. Those collapsible sections where the content isn't loaded just mean I have to wait 10 times for 20s while trying to read an article, rather than once for 25s upfront.
wikipedia has a big "never change anything" culture that resists any design changes to the main site, but doesn't seem to care about the mobile site.
more likely we'll see m.wikipedia.org become more desktop-friendly and responsive before we see it happen to "desktop wikipedia". (and really, the m.wikipedia site is quite nice to use on the 11" screen i'm reading on now)
> wikipedia has a big "never change anything" culture that resists any design changes to the main site, but doesn't seem to care about the mobile site.
Except for the deletionists. They like to change things!
I think that's basically the same crowd. And from one perspective, those articles never existed to start with so deleting them is just reverting a change.
Unless they get rid of the vast amounts of position: absolute; in the Vector skin it is unlikely. Which will most likely require switching out entirely to a new skin. Unfortunately many extensions that are not parser extensions rely on the Vector skin to function.
Flaw in media query. They work on resolution and on pixel density as reported by the device but you have no way to know if it's a small size high density screen or a large screen with average density.
There are 13" laptops with a resolution which overlaps with the higher end mobile phones and that is where mq falls apart because you can't tell where you are. The real issue is with all browser reporting the same fixed dpi, for reason which make sense in context but don't allow to discern all cases.
We work with a mix of media query + user agent sniffing to enable mobile queries only on mobile stuff.
It was all fine and dandy as long as pc had >1280 pixels, tablets where between 768 and 1024 and phones below that range. Now that everything overlaps with everything, not so much, and because all browser reports metric around the 96dpi magic number, there's no solution. At least making a media query in em instead of pixel saves you from the trouble with people zooming on pages.
And if your website is responsive and allows iframing, it's even worse.
> The real issue is with all browser reporting the same fixed dpi, for reason which make sense in context but don't allow to discern all cases.
I'm certainly unaware of browsers doing this, except for a few old ones on desktop and Windows Phone 8's IE, and I can't find anything claiming other browsers do this. Certainly it's never been an issue I've hit.
all browser have fixed dpi, at 96dpi precisely. it's part of the css3 standard and it's tied to the physical unit - so if you get 1cm as css width, it's the same amount of 'logical' or 'css' pixels irregardless of actual device density. (and of course if you ask 1inch to css you get 96px https://www.w3.org/TR/css3-values/#absolute-lengths )
you can use device-pixel-ratio and the likes to have an hint on the pixel density, which doesn't protect you from the extremes (small, very high density devices and large low density screens)
like the galaxy tab 7.7" has a 1280 width, which would trigger desktop line of queries if you break at 1024 like many do.
It's actually in 2.1 as well, the fact that 96 CSS pixels equal 1 CSS inch. But that's not what's relevant here, as we're talking about media queries where we have resolution units, and resolution units give the device pixels per some CSS unit.
> you can use device-pixel-ratio and the likes to have an hint on the pixel density, which doesn't protect you from the extremes (small, very high density devices and large low density screens)
> like the galaxy tab 7.7" has a 1280 width, which would trigger desktop line of queries if you break at 1024 like many do.
Oh, right, so the issue here is the fact we have relatively high density screen (197 PPI) but where 1 CSS pixel still equals 1 device pixel? That seems pretty bad generally, given I presume the same is true for the rest of the OS (AFAIK in general Android browsers just follow the OS here)? It seems like to fix this we'd need to add resolution units giving number of CSS pixels per physical length unit, right?
exactly, instead they went on the road of giving physical pixel per css pixel, which means we need to create all combination of kinda valid queries to support future devices (problem isn't THAT bad now, but it's getting worse)
> exactly, instead they went on the road of giving physical pixel per css pixel, which means we need to create all combination of kinda valid queries to support future devices (problem isn't THAT bad now, but it's getting worse)
Do you have examples of other device and browser combinations of this being a problem? Let's make this situation better!
(FWIW, these browsers are likely not conforming CSS implementations, because you either must have 1 CSS inch equal 1 physical inch (and 1 CSS pixel is still 1/96 of a CSS inch, with whatever ratio to device pixel that ends up being), or by relating the CSS pixel to "the visual angle of one pixel on a device with a pixel density of 96dpi and a distance from the reader of an arm's length", but hey, they exist so we may as well add media queries to deal with the resultant fallout.)
[Edit: In the Galaxy Tab 7.7 case, the reference pixel, assuming 15.75" viewing distance (which is totally non-scientifically the viewing distance my partner uses her tablet at) works out to be 1/170th of an inch: almost exactly a device pixel. I guess a lot of the problem with tablets is the viewing distance varies so much...]
Responsive design is the design ideal of not having two separate sites -- one for mobile and the other for desktop -- but rather just being able to visit one site and have its CSS dynamically adjust so that it looks good in all screen sizes.
If you can do it without adding a bloated JavaScript framework and adding tons of requests to a page load, sure. If you can't do that I'd prefer auto detection by the load balancer and redirects to the mobile site
Jesus, you don't need frameworks or sniffing, it's an almost all-text site with very minimal styling. It's almost more difficult to make it non-responsive. There isn't anything really on the desktop version that isn't on the mobile, so I'm not sure where those extra requests would be coming from.
Sorry for the the tetchy reply, I just find it nuts that, to get around writing maybe a page of CSS, people build and maintain an entirely separate site that has to be in lockstep to the the first, along with ever-reliable sniffing, and then say that is the simpler way to do it. There are several scenarios where it turns.out to be useful; this isn't one of them
You can do a fair amount these days with CSS thanks to flex-box, it handles the row based layout transition to column based quite well.
A benefit of using CSS is that it handles browser zoom and high dpi screens much better as you can use units other than pixels (eg: em/rem, vh/vw, %).
From a architecture point of view, you want to keep layout logic out of the JavaScript anyways as JS should be for interactions and other 'nice to have' behaviors.
The responsive bit doesn't really work though. The mobile version does, but there doesn't seem to be any good reason for that being extra functionality, rather than it just being how the site should reflow at smaller sizes
Haha that's an ironic URL. Clearly I was wrong about Wikipedia's use of media queries, but that makes the persistence of the ".m." subdomain even stranger. It's time to start 301'ing this.
There just isn't adequate satellite internet worldwide to trust that system just yet. Airplanes don't even broadcast their coordinates to satellites in many airlines, despite existing networks likely (ie Iridium) being able to handle the small increase in data (if they kept the packets small - just flight number/lat/lon - and let the satellites figure out where to send and what time the packets come, the total size from all flights worldwide every hour could still remain under 200mb)
It's truly mind boggling that airlines don't do this. Given the cost of an aircraft and the value it represents, surely the data cost is more than worth it. I hope MH370 has changed the mindset of airlines and aircraft manufacturers.
I know that pilots are against live streaming, always on voice recorders in the cockpit due to privacy concerns but surely there are ways to regulate access to that (eg: it goes to the safety regulator of the airline's country of governance and is held for 48 hours, released only if an accident occurs).
I don't put a server into staging use let alone production use without having comprehensive monitoring in place for CPU, memory, etc. Putting a $200mm+ aircraft in the sky without monitoring every single thing in real time with multiple layers of redundancy seems unbelievably insane.
> It's truly mind boggling that airlines don't do this.
They don't do it because they don't need the data. Governments do, for when they need to do search and rescue. So, governments should make it a requirement.
For a manager making a decision in an airline whether or not to use this service, he would have to justify the cost to the airline. If none of his competitors are using it, then he's just got an unnecessary cost which the airline has to eat or pass on the cost to the customer.
The way around this is to make it a requirement for all airlines. Then everybody has to eat the cost.
You may not be aware but there is an effort in the United States to move aircraft from primarily radar-based Air Traffic Control to GPS-based. This requires all planes to be equipped with additional equipment to transmit their location, and there is a mechanism to transmit via satellite. It's just not a requirement.
> This requires all planes to be equipped with additional equipment to transmit their location
ADS-B (out) is not required for all planes, even after 2020. It's only required in class A, B, C, and some E, basically "wherever transponders are required today".
There will be a significant fraction of the GA fleet that will not equip.
Governments should just bill the manufacturer and the airline for the costs of the search and rescue/recovery operation. Then the manufacturers, airlines, and their insurers could work out what the cost/benefit equation is.
That would fix the economic incentives, but not the larger externalities. After all, many black boxes are never recovered[1], including the Eastern Airlines one at issue (well, it might have just been recovered, decades late) and, so far, MH370's. To an airline, this outcome is not the end of the world, or perhaps even preferable: abstractly, data from the flight recorder might help prevent future crashes, but that's far in the future, the crash rate is already very low, and in the near term, whenever info about the crash makes it into the news cycle, that's bad PR for the airline. But the government has a strong interest in getting that data: if it was terror, that information can help catch the masterminds and prevent future attacks; if it was an accident, well, government regulatory bodies are the embodiment of the public's collective interest in safety, which is considered more important than short-term profit. On top of that, typically, people who knew the victims have a very strong emotional interest in learning what happened, no matter whether any practical benefit can be derived from the knowledge.
If there was some realistic dollar amount that would guarantee recovery of existing black boxes, then sure, bill the airline for it and let them weigh the probabilities. But there isn't. The only way to prevent these types of situations from happening again is by upgrading the technology, and that has to be done in advance.
Of course, that doesn't mean we are supposed to disregard the cost of reducing externalities; nobody wants a bankrupt industry. Me, I'm not familiar with the economics of aviation, so I don't know whether the airlines should, or whether the government should require them to, make those upgrades in the near term. But at the very least, both of those statements will be true someday (due to turnover, technology improvements, etc.), and economic benefits won't have much to do with it.
For Center (high-altitude en route) operations, ADS-B is fantastic. Random, direct routing becomes much more possible, because there's an electronic box giving people the warm fuzzy feeling. (The "it's a big sky" theory would also work perfectly well here, but people feel better with a semblance of active control.)
There are no plans to shutdown all ground radio based systems. Right now, to file a flight plan in "bad" weather, either your intended airport or your alternate airport must have a legal approach that does not require GPS.
The point of this data is to understand why planes crash (or how were hijacked) so that design faults, defects and crew procedures can be altered to prevent them happening again.
As an initial thought, being able to much more accurately locate missing aircraft sounds like it would be a cost saving. eg:
* the many months/years of effort + associated resources for searching would be likely reduced
* technical/procedural weaknesses that led to aircraft loss could be better analysed, hopefully leading to reduced further aircraft losses, reduced loss of life
Realtime data (other than location) sounds like it would have uses too. Not just alerting for impending or actual failure.
On the other hand, would doing this open up potential remote vulnerabilities for aircraft systems? That could have long term crappy-ness attached. :(
If the software that does the sending has vulnerabilities in it, that would be bad.
Although we can all think of approaches to try to minimise/exclude that possibility... reality often has ways of showing up things people didn't think of. :(
Why would a transmit-only device expose any vulnerabilities in its software? It shouldn't have the physical capability to receive any remote signals, much less act in any way in response to them.
Depends on how "transmit only" is done. If it's using the equivalent of UDP and no encryption of the data, then you're likely correct.
But if the "transmit only" has anything that receives data - even just ack signals for what's sent, let alone something to negotiate encryption - all bets are off. :(
You're thinking a few OSI layers too high. Any such radio communications from similar systems have one-way broadcast as the physical layer.
If you don't include a radio receiver, then there is no capability to receive a single bit, much less negotiate encryption; the system throws out a waveform and the rest of the world may figure out what to do with it if they manage to receive it.
Typically plane crashes are very rare events. Even more rare are crashes from crusing altitude over water. MH370 doesn't change that.
So if the proposal is to add new equipment to every aircraft in service, that is compared to the very rare cost of having to recover a data recorder, and the even more rare cost of having to recover it from underwater. Airlines don't see that as an economic tradeoff that makes sense.
They should also install cockpit video recorders. A lot of accidents will be much easier to reconstruct what went wrong with such. For example, it could confirm who was at the controls, and if there was a struggle going on.
It doesn't seem to be on Elon Musk's radar (no pun intended) but if his or Amazon's reusable launch platform really does make commodity launches possible then it would make sense for Elon or someone to put up Iridium 2.0. Maybe Google or Facebook will do it to bring internet to the masses.
There is currently a company called Globalstar seeking permission from the FCC to offer satellite based internet services. The stock dropped 60% last week on rumors that they won't be approved but nothing has been confirmed.
SpaceX are working on a low orbit constellation to provide low latency satellite internet (for consumers). Presumably that could serve the purpose of an "Iridium 2"?
Oh I stand corrected then. In my opinion between a lower cost competitor to BGAN, extending higher speed internet to undeveloped and underdeveloped areas I believe there is a great deal of pent-up demand. That's before things like mandatory internet-connected aviation transponders as mooted elsewhere in this thread.
https://operationthonapa.com/an-international-smuggling-ring...
"Pieces of snake/alligator/crocodile skins are scattered all over the mountain. In picking up a plane part for a closer look, often there would be crocodile hide on or near the part. They are in such abundance that we actually became quite sick of them as we combed the field for the black box.
...
While we don’t think this is the sole reason for the bungling of the investigation immediately following the crash (10 months before an expedition was mounted!), these illegal animal skins are part of a larger pattern of smuggling illegal goods on Eastern Airlines commercial flights. Someone in the organization was making money on these sketchy practices. If some of this money found its way to the right pockets, it would been easy to delay the appropriate investigational response until many feet of snow/ice covered the crash site."