Comment Re:Incoming international flights (Score 1) 702
How many people still use Rios/Zunes/old CD players/etc.? Old iPods (unless they're reeeaalllly old) use the standard Apple connector that was only recently superceded for the iPhone5.
How many people still use Rios/Zunes/old CD players/etc.? Old iPods (unless they're reeeaalllly old) use the standard Apple connector that was only recently superceded for the iPhone5.
How many people actually have dead devices at the TSA line? Definitely not 100%.
Those numbers are somewhat misleading. The big problem is that they don't show the number of passenger-miles traveled per year; this number has risen greatly over the decades. Everyone (in the US) flies these days; back in 1970, only richer people took planes anywhere, or when others did, it was a rare event because it was so expensive.
Also, since this is about American airport security, these numbers are misleading since they show ALL accidents worldwide. There's a lot more air travel internationally than there used to be, as the standards of living rise in developing nations (and everywhere really). Accidents in Malaysia or Brazil by airlines which don't even operate within the US don't really worry Americans much, it's accidents on our own planes in our own country that are concerning.
You don't need hundreds of wall-warts and cables. Lots of hotels have all-in-one cellphone charging stations (and so do lots of airports, just not near TSA lines). There aren't that many cellphone cables, especially now that everyone except stupid Apple has standardized on the microUSB plug. MiniUSB, MicroUSB, and a couple of Apple connectors would work for probably every phone made in the last 8 years that anyone still uses. For laptops, all you need to do is provide electrical outlets, since everyone carries around their charger. One of the $10 universal international power adapters will allow international travelers to use their chargers if they didn't bring a US power cord (every charger operates on 110V-240V, the only problem is the physical plug).
So all the TSA would have to do is provide about $30 worth of extension cords and adapters. Of course, knowing how inept Obama is with everything, that won't happen.
Nope, it is really, REALLY important to run TSA badly and punish innocent people - so they will NOT be providing an electrical plug to allow you to save your $700 phone or $1,500 laptop.
Thanks, Obama!!
Terrorists already go for softer targets, namely shopping malls. It's happened in Mumbai and in Kenya. It just hasn't happened in the US. That means that either our security is so good that the terrorists are prevented from coming here and shooting up malls (extremely unlikely since our southern border is wide-open and guns are easy to obtain here), OR the terrorists just aren't interested in messing with us that much.
I think you're completely overblowing things. Regressions are rare; once a driver is working properly, what reason is there to go back and muck with the driver? Personally I've never seen any regressions at all on my hardware (or any HW I've worked with); once something's working, it stays working on newer versions. It's not like they need constant maintenance; the only time they need any maintenance is when the kernel interfaces change.
For your bluetooth and backlight drivers, it sounds like you made some fixes, and didn't get those pushed upstream; is that the case? If you push your changes upstream and get them included in the kernel, then you don't need to reapply them.
We're not talking about resistance to change, we're talking about inertia. Who wants to use a language where you can't run a program on a different system, because it has a different version of the interpreter installed? Or where doing an update can break lots of important programs that your company has been running for years? It's a hindrance to adoption. Not wanting to modify all your in-house programs because of some gratuitous language change is not "resistance to change", it's simple pragmatism. This kind of thing wasn't generally a problem in the past, such as with Perl =5. Now, for some odd reason, these language developers seem to think that everyone wants to spend time modifying all their programs to keep up with changes to the languages.
There is no time wasted rewriting drivers, and there is no problem. The drivers are part of the kernel; when the interfaces are changed, the drivers are changed accordingly. This doesn't take any time because the changes are fairly trivial (usually adding an argument to a function call). You have no idea what you're talking about, and are obviously not involved in kernel development.
As someone who worked in C and C++ pre-standardization, I recall (perhaps erroneously) that the new standards broke a fair bit of existing code, albeit in minor ways. And of course Microsoft's broken C++ compiler in Visual Studio 6 resulted in a vast amount of borken code when they finally caught up to the rest of the world.
Yes, but there's a big difference: C and C++ are compiled languages. So if your application was built with some older compiler, and now C++ has been standardized and your application doesn't compile with the new compilers, that's only a problem for you, the developer. Your users won't see it, because they're using the compiled form, which still runs just fine (unless the OS has changed to break it of course).
When an interpreted language breaks backwards compatibility, everyone is affected. Users suddenly can't run the program when their interpreter is updated.
Yes, but people don't want to dig up all their older programs and modify them just because the language has changed and is no longer backwards compatible. Inertia is a very powerful thing, and these language developers have really screwed up by forgetting this.
Wrong. Linux doesn't need a static ABI, because the device drivers are all distributed as part of the kernel. Only makers of proprietary modules, and sycophants and nay-sayers complain about the Linux kernel not having a static API and ABI for kernel modules.
If you're talking about application code, the kernel is static on that. You can take binaries from 15 years ago and run them on a modern Linux kernel. The problem you'll usually run into is that the libraries that binary links to are not fully backwards-compatible, including glibc. That's not a kernel issue. In practice, it's rarely an issue at all; even glibc is very stable. The other libraries, OTOH, are a different matter (things like gtk, Qt, and myriad other small libraries). Even here, though, there's a pretty good effort to maintain some backwards compatibility. Most distros have qt3 compatibility packages, for instance, if you need to run applications built with Qt3. But if you've wrote an application 15 years ago that only uses kernel system calls, it should work just fine now.
The problems with Perl6 and Python are real, though, and I think do hurt their adoption a lot. It's a real PITA if you can't run an older program because the newer versions of its interpreter aren't backwards-compatible.
That's certainly not the case. Look at all the horrible things the European nations did back during their colonial days. Most nations, when sufficiently powerful, do pretty awful things to other nations just because they can and because it benefits them (or certain members of their population).
"No job too big; no fee too big!" -- Dr. Peter Venkman, "Ghost-busters"