Maybe that's where you live, but on the other half of the developed world we're starting to see 100/200mbit FTTH connections being pretty common in large and medium cities, with such affordable prices that "normal people" have them at home. So that's definitely a big change from the 10mbit DSL lines we had 5 years ago.
And the 50mbit domestic connections wasn't at all common 20 years ago (heck, we did have 33.6kbps dial-up and it cost a fortune). In fact, if you say that there haven't been large, fast changes in bandwidth terms then I'd invite you to revisit the following facts:
- Smartphones in every pocket, with people consuming 1-2 GB a month. This was unthinkable 7 years ago — and I vividly recall spending a ton of money because I used 1 GB of mobile internet.
- 4G in every corner — just a few years ago the top was the 384kbps UMTS
- FTTH and DOCSIS 3.0 ubiquitous, mainly to lowered costs for fiber equipment, GPON lowers the cost and tougher fiber cables that can easily be installed in houses
- Ten-fold growth in internet provides bandwidth… or more. For example, <10 years ago, OVH's network (one of the largest dedicated server providers in the world) was one of the largest at 300Gbps (I remember the party when they reached out that capacity!). Now they are at +3Tbps and growing.
- 1080p and 4K increasingly common — and then a decade ago we were still buying CRT televisions, a far cry from the FHD and higher bitrate contents
I could keep going with the list… But the fact is: everywhere you look bandwidth is getting cheaper AND faster, same goes for consumer devices that profit said bandwidth (TVs, smartphones…) and that comes in hand with more, richer content.
DOCSIS was standardized to operate at up to 38/9 Mbps in 1997. That's not quite 50Mbit 20 years ago, but it does show that almost all of the perceived advancement in broadband isn't from technological progress, just wider deployment of existing capabilities.
Current cable modems can negotiate with the CMTS to determine which of several channels to use for communication, even when channel bonding is not in use. This means different customers can be communicating on different channels if the CMTS has sufficient resources. Are you saying that this was not possible with DOCSIS 1.0? Obviously it is more common for channels to be shared than for each customer to get dedicated channels, but I don't think that is a technological limitation.
No, 38/9Mbps PER CHANNEL. Multiple customers may be on a single channel yes, but there is a fairly large number of available channels on modern QAM-based cable networks, and has been for some time. 3-5 DOCSIS channels would normally be sufficient back in 97 for the number of customers attached to each head-end.
Aviation and medical practice involve lives, unlike (most of the time) software development. Same happens with the speed at which it happens — aviation, as medicine, is a "slow and steady" evolution towards improvement, while software development is ever-changing.
Yes, it would be great to have a better way to identify and tackle common mistakes in software development, but it is not nearly as crucial and universal in software development as it may be in other fields. And, after all, each tool/language is so different that few common denominators exist. In a way, it isn't really an issue — yet people dying from malpractice or negligence (either in aviation, or medicine), is.
Most modern airliners have satellite links (data and voice) with their dispatch centers. They also use the ACARS system to send and receive clearances (they can acknowledge by pushing a button). The old SELCAL+HF radio is no longer in use, except for backup.
Planes have GPS trackers. Not only their company knows where they are, the control center can too. In the case of the north atlantic track system, air control keeps a tight eye on speed, altitude and separation with very precise measurements, even as airplanes are far away from land.
I just fail to see the point of this post. I recently hitched a ride on the cockpit jump seat of a modern airplane for a Europe-East Coast flight and during that I saw the air traffic control knowing exactly where we were, and the pilots communicating via text message (ACARS) with control, as well as using satellite links to contact dispatch (via text messages), as well as satellite phone calls.
Pilots keep paper around them because pilots are there to maintain control, and paper is just another failsafe (with pretty good reliability record!).
Bonus: some planes can notice alterations in the flight dynamics and report an ice buildup. No pilot in this planet is going to let any external person input flight parameters remotely into their aircraft's system while they are in the air.
It's actually a brilliant system, with network of transmit and receive sites its like globally available text messaging for pilots.
Also, unless the pilot was using atrocious equipment I can't see why HF radio would sound awful. I use my HF radio almost daily and don't have any complaints. I can legally listen to air traffic controllers on HF with no problem as well. The equipment I have is far, far inferior to that in most commercial airliners.
"Missing" is an euphemism for "very likely crashed" here. They won't say crashed just in case it is later found with people alive, but not communicating and gone from radar over the sea usually ends only one way.
It could be hijacked, landed, and held hostage, but it's incredibly difficult to hide a 777 anywhere in the world where it can safely land. It's possible it was hijacked with intention of being held hostage but crashed, hence no claims of responsibility.
Not likely. It was at cruising altitude and then vanished off the radar screen after sudden maneuvering. If it had diverted it would have continued to be tracked on radar. Even if they had shut off transponders and such, primary surveillance radar would have continued to see them. It almost certainly experienced a sudden catastrophic failure in flight (and I would bet due to a bomb).
Or not a bomb, just some maintenance problem. No group claims responsibility. The point of bombing seems to be to strike fear and send a message. The passport thing is curious but stolen/fake passports can be of use for other things that are nothing to do with terrorism.
Indeed. My money is on "bomb" just because it's hard to come up with a maintenance problem that causes such a rapid disaster at altitude. It would have to be something that caused a massive explosion like TWA 800. Possible, but unlikely. The lack of a claim makes a bombing less likely too, but IMO less so than the improbability of a mechanical problem.
As I understand it, you'd expect such a thing to happen during the climb. That's what happened with your linked flight 611, if I'm reading between the lines correctly, and it's what happened on e.g. Aloha 243. In general it would make sense that the failure would typically make itself known as the stress on the fuselage is increasing, not after it's reached a steady state. Not that it's impossible, but the fact that this flight was at cruising altitude for a while before it disappeared would seem to be an argument against this possibility.
Also true for http://en.wikipedia.org/wiki/Japan_Airlines_Flight_123, the event happened "at near cruising altitude". Although I wouldn't say a plane once cruising is entirely steady state, there are winds and such. But, yeah, as you climb stress on the pressure vessel increases and that's when you'd expect a flaw to manifest.
And pilot aids that appear to provide more information than they actually do can do more harm than good. If pilots take suicidal risks based on dubious information from "real-time" weather updates specifically designed for pilots, just imagine what would happen if consumer-grade iPad "real-time" weather apps found their way into the commercial cockpit.
FYI, the author of the post owns and pilots a modern jet plane, and is a seasoned pilot. His post was not just about airliners, but any planes up in the sky. And he is right, that the technology in many cases is outdated and prone to errors.
He owns a plane which he does not fly as a pilot and got a PPL which allows him to fly light aircraft in visual conditions but refuses to fly unaccompanied. I would not say that he is a seasoned pilot…
There are planes and planes. Security in airliners and in light aircraft are two matters of their own. You don't expect people who own a Cessna to have a black box and a satellite data link.
Modern airliners are also flown by entire teams of ground crews, among them Rolls Royce support engineers that monitor an aircrafts engines in realtime every second of operation trough its entire lifespan trough the hundreds of sensors embedded in each and every engine.
This way, most problems an engine would develop that would be hard to spot by ground service, are detected and acted upon long before they threaten the operation of the engine and airplane.
There's nothing much you need to know to write a webchat client. Campfire isn't high volume, so it doesn't need to be too efficient either. Last time I checked campfire processes a few messages a second. Heck you could rewrite it in PHP/MySQL if you were that way inclined.
Campfire didn't succeed because it was a good product. It succeeded because they marketed it to their "following" who bought into it.
You could levy that same criticism on any company who leveraged an existing success to market and sell a less than stellar product or service.
Many times people will see a product or company and think "how simple, I could have made that ... why did they succeed?" Everyone has assets they bring to the table that help them succeed. For some it means they can create and sell a less than stellar product because they have existing leverage in a market that give them an advantage an average "Joe" wouldn't.
I loved it! And still do, but sadly I moved to a RPi/XBMC/transmission/SickBeard/Couchpotato setup which was very easy to setup using xbian, thus not using showRSS anymore. The raspberry is a bit underpowered (according to me) though, so I'm thinking about replacing SickBeard with showRSS again. Pitty there isn't a good & easy way to do it. (not that I'm afraid of doing it all manually).
Something I'm missing from showRSS btw, is the ability to browse trough all episodes/seasons and be able to select an episode/season to be added to the RSS-queue, so my downloading box would fetch it next time it checks the feed. But than, showRSS does one thing very well, so I'm not sure more features like that would be helpful for everyone.
ShowRSS right now works as a piece in the workflow for many people: feed what aired a few hours ago to another system. It hasn't got an archive and it doesn't serve as one. Thus, no option to do what you say… it's meant for the last week or so, not a lot more.
It does what it does pretty well, though. The new system reads a few sources (not just EZTV) and picks the best releases. So, 720p for everyone in a matter of hours and for almost every show you can think of.
P.S: have you thought about using transmission+dyndns? It's how I run it (minidlna+transmission, and showRSS pushes to my rasppi, no RSS involved!).
I agree, it does what it does very very well! And it's not meant as a show-organizer.
minidlna seems like something I'm going to be looking into, thanks! And for dns, I use a domain which I manage using cloudflare and a script  which gets run by cron and updates the cloudflare entry every day or so. Didn't wrote the script though, found it somewhere and had to edit it a bit to work again.
Something else I have been looking into is splitting up the load, using the RPi only for streaming and xbmc; and handling downloading and NAS capabilities using a different device, such as a MIKROTIK RouterBOARD (which I'm afraid isn't going to work).
Want to work in sunny Madrid, Spain? Come join us!
We're ShuttleCloud, a small (<15 employees) data migration company based in Madrid & New York. We're hiring a Senior Developer and an Executive Assistant to join us in our (very cool) Madrid office. We're flexible about a lot of things, so don't hesitate and apply.
Senior Developer. Madrid, Spain.
Our technical team is seeking a senior developer to lead us and help us support our growth. We want you to teach us & introduce new methodologies and tools, and lead our team towards the future.
We're also looking for an Executive Assistant. We don't ask for any previous experience or look only for people wanting to stay in the position long term (recently graduated students welcome!). We want someone who is independent and who can think ahead. If you think you can do that, then, we want to meet you! So, write us.
Contact us at: jobs at shuttlecloud.com.
Thank you for reading, and happy 2014 to everyone!