Canonical Demos Early Stage Android-On-Ubuntu 165
An anonymous reader notes Ars Technica's report from the Ubuntu Developer Summit in Barcelona, where Canonical has unveiled a prototype Android execution environment that will allow Android applications to run on Ubuntu and "potentially other conventional Linux distributions." "Android uses the Linux kernel, but it isn't really a Linux platform. It offers its own totally unique environment that is built on Google's custom Java runtime. There is no glide path for porting conventional desktop Linux applications to Android. Similarly, Java applications that are written for Android can't run in regular Java virtual machine implementations or in standard Java ME environments. This makes Android a somewhat insular platform. Canonical is creating a specialized Android execution environment that could make it possible for Android applications to run on Ubuntu desktops in Xorg alongside regular Linux applications. The execution environment would function like a simulator, providing the infrastructure that is needed to make the applications run. Some technical details about the Android execution environment were presented by Canonical developer Michael Casadevall... They successfully compiled it against Ubuntu's libc instead of Android's custom libc and they are running it on a regular Ubuntu kernel."
Re:If I had the choice (Score:3, Informative)
Re:Why? (Score:5, Informative)
Re:This is where a subject should be (Score:1, Informative)
It might mean that Canonical and Google could share an app store.
Canonical already has one (the huge Ubuntu repositories, especially -universe and -multiverse (-multi- is nonfree)) and Google can't use it b/c it's "Desktop ready" and not "android ready". So no, they won't share an app store.
Re:important lesson (Score:5, Informative)
Re:Canonical Demos Early Stage Android-On-Ubuntu (Score:2, Informative)
hibernate works (well its a horribly designed hack on all linux but it works)
suspend varies by computer, but for most it works (occasionally the screen will not resume on some chipsets, but that is being worked on)
mint is ubuntu but with a couple of extra repos and prop drivers by default.
Re:Why? (Score:3, Informative)
Re:And Google doesn't get Sued? (Score:3, Informative)
Java wasn't opensourced back then. There's a not-so-subtle difference here:
I take your specs for a platform, implement them, and extend them with some proprietary APIs that I make sure are valuable for developers but won't run on your platform.
This is meant to kill your product's unique advantage: its ability to run everywhere, which I consider a threat to the monopoly of another product I develop: an operating system.
Next, I make my platform the standard on said operating system by bundling and leveraging my monopoly.
In the mean time I make sure that products written for your standard platform will break in funny ways when running on mine, so developers will shy away from the technology altogether.
vs.
I take some of your specs, look at your code, and come up with a different product. I never pretend interoperability between our platforms.
Then I publish the code under a liberal license, which even allows you to incorporate all my work into your product.
If they are so inclined, Sun, err.. Oracle can take whatever extras Google implemented in Android and make it part of their JVM. It's perfectly legal, and they don't have to pay squat for it.
Comparing this to Microsoft's embrace-extend-extinguish attempt is either trolling, or a severe lack of knowledge of recent history / understanding of licensing / what Android is all about. For the sake of innocence until proven guilty I presume you're not a troll.. but then.. what are you doing on slashdot?
Re:And Google doesn't get Sued? (Score:3, Informative)
Android allows developers to write applications using the Java language but doesn't claim to be compatible with either the Java SE or ME platforms. Nor does it license any code from Sun or OpenJDK.
Re:Canonical Demos Early Stage Android-On-Ubuntu (Score:3, Informative)
Yes, absolutely, they do.. except for the whole patches upstream part.. last I heard, that doesn't actually happen. Bug reports upstream, sure.
Oh, you heard did you? Want to provide us with a link [phunnypharm.org] to back up your assertion?
Here's a choice quote from my link:
Re:Developer tools - eclipse died in Debian (Score:2, Informative)
The primary problem is that eclipse is not being actively maintained upstream in Debian. It is in some ways rather hard to package which has to be actively maintained much like firefox, and nobody has stepped up to take it over. If nothing changes, I would not be surprised to see eclipse eventually dropped in Debian and by extension in Ubuntu.
Re:If I had the choice (Score:3, Informative)
Still in business, still selling the current generation of hardware, still developing the operating system.
It would have been nice for them to continue developing the next generation but the current generation of hardware is still fine.
Re:Fault != problem (Score:3, Informative)
Won't you agree that it is constantly becoming less of a problem?
I agree, less of a problem. But there is a threshold where a user can walk into Best Buy and expect to walk out with a known-working printer without having to use a different printer to print up the HCL.
Do you mean that it is the vendors fault for not specifying "not linux ready" if the hardware is not Linux supported, or are you saying it is the vendors fault for not providing drivers and then specifying "linux Ready?"
It's the vendors' fault for not supporting enough hardware (boo Microtek) and for specifying "Linux ready" on the hardware that is supported. There are probably more installations of Linux than Mac OS X (granted, most of those are embedded or servers), yet Mac OS X gets a logo on the box and Linux doesn't.
I have never needed to download a driver for a modem or network card in Linux.
Back in the Red Hat Linux 6 days (that's 2000, not RHEL 6 which isn't out yet), I had to download and install a kernel module to let me use the Lucent winmodem in my Acer TravelMate 721TX laptop. This is probably because winmodem drivers are non-free, which in turn is because v.90 is patented. And how does "never" meet your "Internal Intel software modem"?
For WIFI (and I make here a distinction between WIFI card and NETWORK card)
I wasn't making such a distinction. Forward-thinking restaurants and hotels used to provide Ethernet jacks for each patron. Now they have switched from 100BASE-TX to Wi-Fi, just a change in layer 1 without a corresponding change in the layer 2-3 network policy above it.
On reading your final comment I realise you might have meant "No enclosed drivers on the CD" as opposed to "No Drivers Available At All"
Correct.
but my counterpoint is that the large majority of hardware out there works out of the box with Linux, and hence needs no drivers.
It depends on which releases of your distribution you follow. A hobbyist has the time to follow Ubuntu from Hardy to Intrepid to Jaunty, but if you're trying for a stable environment, for example at work, you're probably going from one long-term-supported release to the next, so the hardware support of Hardy out of the box remains relevant for about another year. And often, the official driver enables features that the developers of the free driver don't know how to turn on, such as OpenGL acceleration on some video cards.
Re:Fault != problem (Score:3, Informative)
One problem is that for many device the manufacture can not put the driver on a CD and have much hope of it working.
Linux refuses to implement a stable binary driver interface. From a companies point of view that is a huge problem.
You can not put a driver on a say cd for Linux kernel 2.6 and have it work. Even if you make it FOSS. You could make it a source tar ball and maybe write a script that will compile it BUT then you have to hope that the user has the kernel files installed.
Ah but you say that you can just release the specs and driver will show up. Well maybe but most complex FOSS drivers are written by the companies that produce the hardware and not by the community. They often help but the majority of the work is done by the vendor.
Next you have support issues. How do you know if the device is failing and not the driver?
Then you have timing issues. You have a supper cool new graphics card and you want Linux users to have chance to use it. Well the new driver has made it into the the distros kernels yet.... So what do you do?
And are the problems if you can FOSS the driver.
If your driver uses software that you can not release because you bought it then can not do a FOSS driver. You may have to spend a lot of money to write around the code and test it. Then you are right back to the same problems.
The reasons for a lack of a stable driver interface are IMHO contrived at best. Yes you may loose a tiny bit of speed. Security? Not if you design the interface well. Locked into Cruft? Yes that is an issue but nobody says you must keep the interface forever. Just keep it for .x revisons like 2.6 and if you need to change it change it for 2.7 or 2.8
The real reason is the desire to keep closed source drivers out of the Kernel. Which I can understand but has failed. NDIS wrapper and the nVidia and ATI binary drivers are proof of that.
ATI has been releasing the specs of their chips for a while now. Still no driver that is fully usable for the latest and greatest. You can not just release the specs and have the drivers show up. It takes a lot of work and effort.