Comment Re:Israeli Airport Security folks are professional (Score 1) 741
The US also has 50 times the population of Israel; that might go towards filling up the positions. :)
Users won't need to recompile or reconfigure anything -- they'll get the updated system installed for them by the distro packagers in upcoming versions. You only need to do anything if you want to enable this *right now by yourself*, and there are indeed a few different ways to do it.
The differences between the change to the kernel and the shell script are basically two: one, they apparently have slightly different algorithms for choosing how to group the processes. That's not due to it being in-kernel vs out-of-kernel though -- that's just because they are slightly different. Both can be implemented in both ways, and both work with the same actual implementation mechanism -- simply one works from userspace through the interfaces and one's built-in to the kernel.
Auto-tuning behavior that's built in will probably be the most reliable, easiest, and best-performing way to do this, rather than requiring every Linux distribution to ensure that they're running the same extra scripts and keeping the userspace stuff in sync. Do it once and leave it built-in to the kernel.
b)There really isn't a clean way to talk between applications. You can send files, but it's really a drop box, I can COPY(not link!) something into another apps area, but after that the file is no longer mine. So if I want to send something to another app to process and then get it back to do some processing by my application I have to hope the app tells me about the changes, and considering the app may not even know I exist(nor should it, thats the beauty of decoupling), thats a lot to ask.
Indeed, there's not a great way to share data between apps on iOS; the 'file sharing' in iOS 3.2/4 seems pretty dreadful and awkward to use. You can push some data around via URLs, but I've not been able to find a system for discovering URL handlers, or having a way to declare support for particular types of data instead of manually listing some application-specific URL schemes.
Android's system for "Intents" is a bit nicer; you can combine some typed or structured data (say text/plain) and an action ('send') and just shove that off to whatever apps will take it. That's how the 'share' buttons in Gallery, Twitter, etc are implemented, and how you launch email dialogs, etc. Much more flexible, though still tends to be UI-driven rather than behind the scenes.
I can *sort* of understand 1 from a performance standpoint, if you allow user created dynamic libraries every time the application is swapped out of memory you have to find which dynamic libraries it uses, make sure nobody else is using them, then unload them. However as memory increases the rationale behind needing to constantly load/unload them starts to disappear.....
Dynamic libraries don't really work that way; when your program is loaded, the linker pops over to your libraries and pokes a few bits in memory that make the function & data references work correctly. The untouched parts of the library can be shared between processes because the executable code is memory-mapped from the file into address space directly; the kernel's memory manager deals with knowing what's using it, so at the system level there's no special need to go looking for what process is using what library.
There can be performance issues with dynamic libraries because the dynamic linker has to, well, link more things when your program is loaded.
On iOS you're even more restricted because user-installable apps are kinda funkily sandboxed from each other, and the app distribution/installation infrastructure is totally geared towards individual, standalone app bundles. If you've got no place to put shared libraries that will share them, there's not much point to using dynamic linking (unless you're going so far as to manually load/unload the libraries and link symbols yourself to keep from having to load them, which is probably not very beneficial these days; it might be better to just link statically and avoid fixups.
Your basic widgets are pretty straightforward to implement on multiple systems, but what eats up time and effort is indeed things like getting layout to feel like it fits in the system, and to integrate with native widget styles, dialogs, or UI conventions that are different. (Use a system icon there, a menu here; a nav bar at top here, submit/cancel buttons at the bottom there.)
For StatusNet Mobile which we built with Titanium we've had to do a lot of special-casing to get various parts of the UI looking and feeing a little more native on each system, and we've still got a number of dialogs that need more work. The majority of our UI though is in a webview, which is nicely universal.
Tying into low-level platform integration can be a bit more difficult too; being able to 'share' messages out to other apps that accept the Action.SEND intent or text/plain for instance required tossing in a low-level module to hook into the Android system code directly, which was more awkward than I'd prefer.
My own (free) app is cross-platform, built on Appcelerator's Titanium Mobile; it runs much smoother and nicer on iPhone, but we've got some very handy extras for inter-app sharing on Android that just aren't available on iOS. We were able to publish to the Android market *instantly*, but had to wait over a week to get pushed to the App Store. I'd still much rather see Android "win" (if there is such a thing as "winning") but there's still a lot of work to do on user interface, interactive performance, and reducing the administrative burden on users.
Driving from SF to LA is *hell* on holidays or in bad weather, but it's short enough that high-speed rail will get you there about as fast as flying (considering the extra check-in and security burden at the airport)
Happiness is twin floppies.
