Slashdot Mirror
Android's "Non-Fragmentation Agreement"
superglaze writes "The biggest doubt cast over Android (whose SDK was released yesterday) has been the fact that much of it is licensed under Apache. There have been worries that manufacturers might fork the code road in a non-interoperable kind of way. I.e., they would have no obligation to feed back code to the wider Open Handset Alliance, or even tell the other members what alterations have been made. However, it turns out that Google made all the members sign a 'non-fragmentation agreement' to make sure everything works with everything. In theory at least. 'All of the partners have signed a non-fragmentation agreement saying they won't modify [the code] in non-compatible ways ... That is not to say that a company that is not part of the OHA could not do so.' Google's spokesperson highlighted the historical dangers of working with Java, the programming language that lies at the heart of Android. 'One of the current problems with mobile Java development is that Java has fragmented ... Java virtual machines have fragmented, but all the members of the OHA have agreed to use one virtual machine that can run script in Java'"
How is this google vs apache? I don't understand (its early and I'm feeling fuzzy headed so forgive me). Google is using an apache license to release this... other than that I don't see asf involvement in the project. Maybe I'm missing something here? This article talks about all the involved parties signing an additional agreement separate from the license agreeing not do what MS did to Java before being sued.
So... how is this google vs apache?
I took a look at the SDK yesterday and some of the videos - having done windows mobile development it looks like it will be almost as easy and have a number of similar features.
My concern with all of this though - is that there is no hardware available.
One of the things about emulators is that they run really fast, much faster than the actual hardware runs - so it's hard to tell how responsive an application will be. So given that google has been plowing ahead on development but not been testing on real hardware, one has to wonder if things are going to get seriously challenging when they move to hardware...
I'm going to lose all my karma points, but here goes...
From this (and other comments in the previous postings about Android), one might get the impression that the people at Google are a bunch of idiots who just didn't do any basic research. Why, if only they had read Slashdot occasionally, they'd know that Java is slow, has 10^6 different versions, is very slow, is inferior to C++, is extremely slow, takes up too much memory, is abominably slow, is a programming language that no real programmer uses any more, and in general is teh sux0rz. <grin/>
Isn't the scenario above EXACTLY what this non-fragmentation agreement should help to avoid? Seems like a reasonable way to ensure device compatibility to me. If a non-OHA entity fragments the code, that's fine, because their code/app/SDK/whatever isn't guaranteed to run on all of the devices anyway. If some hobbyists want to create their own derivative platform for device X, they're perfectly free to do so. Seems like all of the benefits of the open source model to me.
This guy's the limit!
Whoa, he-llo? That's a rather interesting (and bold!) statement to be making there. I don't know if Google has noticed, but J2ME phones all run the same code and the same APIs. Issues between phones almost always come down to working around JVM implementation bugs. Which isn't that huge of a deal when you consider that "porting" then becomes a straightforward matter of applying a minor patch between "versions". (Often you can just inline the workarounds and have a single version that works everywhere.)
Meanwhile, Google has created a JVM that's not actually a JVM, that's incompatible with the J2ME/MIDP standard, and then has the gall to claim they're the solution to a more or less non-existent problem? That's ballsy even for Google.
Javascript + Nintendo DSi = DSiCade
Sounds to me like they don't want anyone forking it.
This is not as bad as Tivo ... or is it?
Non-fragmentation my you-know-what.
How exactly? I don't see it that way
Google releases all their open source under the Apache license. I'm sure they have various reasons for choosing the Apache license, but I'd wager a major one is that it is very business friendly. They most likely understand what a pain it can be to include OSS products that are licensed under a different licensing scheme in a commercial product.
to develop in non-java. Of course, it may not work on ALL handsets (in fact, all but certain that it will not). But if you do the work in Java, AND use their API, it is being guaranteed to work across all of the handsets. So, what is your gripe?
I prefer the "u" in honour as it seems to be missing these days.
So why do people keep adopting it.
For the same reason people keep voting for the same old corrupt politicians?
Seven puppies were harmed during the making of this post.
In a strange kind of way, this is Google versus Apache.
I really don't think it is. This is Google taking the Apache license and then fixing a major perceived weakness in it, at least within the context of their application (creating a single, uniform, mobile platform). And even then, they're not really restricting the software; they're just getting the people who are part of their trade group to agree not to stab each other in the back.
It's not Google "versus" anything or anyone, except perhaps maybe the closed-source phone manufacturers. Certainly not Apache.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
Agreed 100% about the unfair commentary that there usually is on Java. But, Google are behaving rather bizarrely by on the one hand warning about the problems of forking and then on the other releasing their own JVM Dalvik instead of using JavaME. So they're going with Apache's dodgy non-GPL approach and further causing fragmentation of the Java platform right when sun is doing the right thing by releasing a GPL'ed Java and Red Hat and others have stepped up to the plate to integrate the OpenJDK work with IcedTea. Google aren't stupid, I wonder what they're game is? I suspect they're trying to GPLv3-proof themselves.
Apache. While Google does have the mantra "Do No Evil", you must remember, they are a corporation. Their goal is to make money. While they are good now, down the road, you can't be sure. The heart of the system is always corporate gain. The heart of Apache is public gain.
Development notes at http://devscribbles.blogspot.com
I agree that the use of the Apache licence is the biggest problem with Android.
If Android had just used the GPL (which prohibits forking), then this problem would have avoided. There are lots of examples to back this up. For example, if Emacs had used the GPL, instead of the Apache licence, the XEmacs fork would never have occurred. And if Gnome and KDE would both switch to using the GPL licence, then the projects would just magically merge into one, and we wouldn't have the duplication of effort and lack of standards that you currently see on the Linux desktop.
Oh, wait... (consults Google). Never mind.
I have written a truly remarkable program which this sig is too small to contain.
behaving rather bizarrely by on the one hand warning about the problems of forking and then on the other releasing their own JVM Dalvik instead of using JavaME.
You've never written a JavaME (J2ME) app, have you? Getting a J2ME application to work properly on all phones is a huge nightmare. Just when you have it working on your phone, and all of your coworkers phones, you try it on your wife's phone, and find that it completely doesn't work. There's plenty of fragmentation just within J2ME, and it's made worse by the fact that it's almost impossible to test an application on every different phone that's out there. If Google can come up with an SDK that makes "write once run anywhere" a reality in the mobile world, I'm all for it.
ZuluPad, the wiki notepad on crack
Lets just get it over with - all "GOOG is the AntiChrist" posts please file under this one, so as to have a neat and orderly flamefest.
Brought to you by the Lawful Neutral alignment since 1984 - "I don't care what you do, just as long as it's in a neat and orderly fashion"
"As God is my witness, I thought turkeys could fly." A. Carlson
Say it isn't so! It's all these guys can do!
...it is largely because cellphone mfgs are so tightly wedded to telecoms that they have little interest in offering a platform that attracts 3rd party development.
Open up the network, as Google is proposing, and mfgs have to compete more in terms of coherent feature sets and what 3rd party apps they can attract.
Can a kind Slashdotter educate an ignorant soul about the gist of the Apache license? I sincerely would like to know.
That's fine, but you're avoiding the central point: Google are causing further fragmentation and forking within Java at a time when there are significant efforts being made to re-unify and stabilize the platform. Also they've chosen a license which has the potential to allow leachers to benefit from any work anyone does on the distributed code. A pity that they didn't put their efforts into improving J2ME instead.
Symbian was developed on hardware, on the lowest hardware then available so that it would be sure to run on everything. This made the design obsolete at launch and now it is so archaic(?) that people really resent that original decesion.
Perhaps Google wants to avoid this. Wants apps that push the hardware requirements so that the Android phones will HAVE to be powerhouses, and it doesn't get trapped in the symbian or even MS trap of having to work on the cheapest shit some company can throw together.
Apparently (I only have this from hearsay) symbian phones often miss basic hardware capabilties that drive a pc programmer up the wall because he suddenly has to code for features that have been present in PC's from the dawn of computing.
All google now has to do, is convince mobile phone makers that it is in their best interest to make their phones capable of actually running the software currently being developed.
Don't forget mobile tech moves fast but is expensive. If the companies could get away with yesterdays tech they would. That ain't good for us consumers, we want them to be pushed so we finally get some fully capable smart phones and not the same crippled yunk they have pushing on us.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
I don't know about you others, but I seriously think that Android is over hyped. Yes, it's Linux based platform for mobile devices, but so what? There's already Maemo, but you don't see it hyped to death. Yes, the Android can also run Java ME applications, so what? All mobile phones can run Java ME applications...
And one last thing... there are no devices yet! No nothing! And you know what, there probably won't be even many of them. If you look at the alliance that Google has put together, the only serious vendors are Motorola and Samsung. But hey hey hey, Motorola just bought half of UIQ from Sony-Ericsson. UIQ is an user interface used primarily by Sony-Ericsson on top of Symbian. How serious Motorola is about Android when they have just made an serious investment into an Symbian company? And Samsung... they are just as much flip flopping as Motorola.
You know I'm not saying that you should not discuss about Android or not develop applications to it. I just say that Android seems to be again an over hyped thing. If I would be developing mobile applications running native in a phone, I would be damn sure that there is adequate installation base before jumping in, otherwise it could be very well be just seriously wasted time.
Survey research tool for commercial and scientific use
Forking - and even just the threat of forking - can be powerful forces for coordination. Reducing the freedom to fork tends to centralize control and reduce the size of the community for a project, while also restricting potential innovation. From Stephen Weber's The Success of Open Source (pp. 169-170):
Forking helps distribute influence and the freedom to make choices about development (pp. 180-181):
So by preventing forking, Google maintains control. The relationship seems to go the other way too - open communities may tend to fork less (p. 160, 227):
or we could say you're missing the point, java is so very fragmented already one more little fragment in the broken heap of glass won't make any difference at all. java: write once, run well only in the IDE of the developer.
So long as the person fragmenting the platfrom hasn't used a Java obfuscator then it would be incredibly easy to decompile the bytecode back to Java source.
Run your emulator in another emulator, maybe two or three levels deep. Emulators, not virtualizers. That should make it run slowly enough for you.
(I'm sure there's a way to simply slow down the one emulator, but I just had to post the Rube Goldberg solution...)
Don't thank God, thank a doctor!
I could go into all the reasons you're shortsighted, wrong, and really a fanboy -- is sucking up to Linus so much better than sucking up to RMS?
But I have a bigger question. What the fuck does the GPLv3 have to do with Android?
Someone slap this tool with -1 offtopic, please.
Don't thank God, thank a doctor!
'Write once, run anywhere'. Hmm, I'm a java programmer and have been for 10 years. I know, as every java developer knows and realises, it actually means 'write once, run on the important places'. Meaning something that works on your desktop PC will also work on the Solaris server you intend to deploy it to.
Mostly people who use 'but I thought you said run ANYWHERE' argument should actually try to think about what that would mean in real terms. For example, should you expect a huge Swing application or something like Weblogic 9 to run on your 8 year old J2ME phone? Be sensible please...
There are Java profiles that work across most cellphones. Most of the new phones implement the profiles with ease.
----- You know you have ego issues when you register a domain in your name.
Sorry, that I go to a different subject, but do I miss something?
(50 * $25.000) + (10 * $100.000) + (10 * $275000) = $5 million
Where are the $10 million ???
No idea why you got modded off topic. You are correct. Normal J2ME commands will work across all phones. It is when you get into graphics or messing with screen resolution that you have to be aware of different devices. That is why you can get emulators for different screen/phones and test.
Well, if the licensing of the SDK is anything to go by it seems more like it's a case of Google vs. Free Software.
That is why you can get emulators for different screen/phones and test.
The emulators I've found don't adequately emulate the various limitations of these phones. You're probably right that basic J2ME commands will work across most phones, but writing games, for instance, can be a huge headache.
ZuluPad, the wiki notepad on crack
A pity that they didn't put their efforts into improving J2ME instead.
Improving J2ME would mean updating he basic standards of what it takes to be considered a J2ME phone. Right now, the standards are so out of date as to be completely useless, so you end up writing for what you think will work on most current phones, and then testing to find out...available emulators don't adequately emulate phone limitations, and not all manufacturers publish all of the relevant implementation specifications, so testing requires actually having a wide array of phones, which can be pretty expensive.
ZuluPad, the wiki notepad on crack
the impression that the people at Google are a bunch of idiots who just didn't do any basic research
They did do research, which is why they replaced most of the Sun bloat with native C libraries.
they'd know that Java is slow, has 10^6 different versions
They know that; it's one of the reasons they created Android in the first place.
Java is slow
They know that, too, which is why only the high-level apps are written in Java and why they replaced the JVM with Dalvik.
Regardless of why Linux is popular, the fact remains that it is (arguably) the best known open source project.
Even assuming that the GPL is the reason Linux occupies in its current position in the computing landscape, the points you make (which I agree with BTW) about being in the right place at the right time and somebody else stepping up, don't change a thing. Linux is here and it is important and by extension Linus is here and he is important.
Ultimately, disregarding what Linus says isn't the best way to push adoption of the new license.
So you still can't modify the source code on your phone and run the changes. I bet they are still going to lock down the phone software with DRM (Example.. Motorola A1200)
Forking is not a problem when code is free as you can tell by looking at the hundreds of "forks" in the Debian repository, or if you look at the thousands of distributions that all get along famously.
Yeah, cos Ian Murdock didn't say that he wished Ubuntu hadn't forked so far from Debian as to be entirely incompatible.
Oh, wait. He did.
*complete shite about Java*
What? What are you talking about?
The problem came when they were unable to verify that all of their code was free.
Bollocks, frankly. XEmacs has always been GPL. The problem came because the FSF wanted copyright assigned to them for XEmacs. So yes, complete horseshit, Twitterris.
The "Linux Desktop" is far more unified than non free equivalents from M$ and others where you can't be sure the clipboard is going to work across applications or the network.
I haven't had a single problem copying and pasting between any application in Windows. Or for that matter, Mac OS X and Linux. Care to explain more about this mythical uncertainty? And no, the *NIX desktop isn't more unified than Windows or the non-free equivalent. Windows and OSX have visual styles which export the global style to all applications that are coded to use it. The *nix world has 2 major APIs and numerous other smaller ones. Slightly different, no?
I write bullshit
Whoever modded him offtopic was either being childish or desperate to hide the information. Probably just a fanboy.
Reading further on this, the interesting thing about Dalvik is that it's a non-Sun-controlled JVM. The thing about JavaME (aka PhoneME) is that although it (like JavaSE and JavaEE (Glassfish)) is released under GPLv2, there is no exception clause (there is for JavaSE). This means that you can only run GPLv2 code on PhoneME. Obviously Google and it's partners didn't like this, so they wrote their own JVM. In order to avoid infringing on Sun's IP they've made the bytecode unique to Dalvik. So Java goes in ---> Dalvik bytecode comes out, runs on Dalvik. Very clever.
As I've said before, I think you're missing the point. And having read a bit more about Dalvik I think that Google needed their own fragmented platform because the GPLv2 (sans-exception) license of JavaME/PhoneME meant that if they want to encourage partners to write proprietary, non-Free code then they had to get their own JVM. See my post here for more information. This is a license war. It has fuck all to do with technical excellence or the ease-of-development on the platform. The only reason I care is that I don't like non-Free stuff. It doesn't really matter a fuck to me whether I get proprietary apps from the OHA or from Microsoft. I also dislike fragmentation of Java, especially when it has the chance of being an even more viable platform.
v4sw6PU$hw6ln6pr4F$ck 4/6$ma3+6u7LNS$w2m4l7U$i2e4+7en6a2X h
Wow, that was quick. I posted an hour ago on the other thread about my worries about Device Fragmentation.
IMHO the differences in the J2ME API is not the main issue for a developer. Differences in screen size, processing power and keypad layout is much more important.
Is google going to force 240x320 (or whatever) on everyone? Is it going to prevent a manufacturer to heavily customize the look and feel? Are we going to have a split between devices having a touch screen and devices not having it?
Since Google is doing this, my guess is they looked into J2ME, found a mess of legacy code and outdated standards, and decided it wasn't worth it.
Even Microsoft was wise enough to do something similar when they decided to scrap the whole pre-NT platform and start anew.
Whoever modded this as "redundant" is on crack. There was absolutely nothing else posted on this thread about the JavaSE exception licensing and it's the heart of the matter.
The core J2ME API was made by several commities and "evolved" rather than was designed. Those commities were controlled by the operertors who were more concerned about using the API to generator revenue for themselves than advancing technology. Google is right in starting from scratch rather than building on J2ME.
However, some extension apis are rather well designed (for instance bluetooth and mg3), it would be not be a bad way to re-use those apis.
Football Odds
If Google actually said that the "full stack" would be OSS, then shame on them. But it seems like they're going to be way more open than anyone else, and possibly as open as they can be while still getting FCC approval for the device.
At any rate, I find the whole project interesting but I'm not getting personally invested in it yet. I'll see what the license is like on the real thing before praising or condemning it.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
I know that's why they did it, which is why I posted this comment. I'm also aware that people inside Sun have been trying to streamline Java SE further. I think it's pretty clear that Google is working hard to facilitate the creation of non-Free software by mobile phone makers. I guess the company slogan changed to "Do lots of evil". Meet the new Microsoft, happily embracing and extending Java.
"It does not do to leave a live dragon out of your calculations, if you live near him." - Tolkien
Google cares little either way about fragmenting Java - what they want to avoid is fragmentation of Android, and I think they will accomplish this, more or less. They just decided that J2ME didn't do it technically for them. As far as the license, I think they wisely realized that Apache would be seen as more business friendly, and it leaves service providers with the illusion that they can still lock everything down.
Illusion? Yup - in practice, this will be extremely difficult. IMO, Google's play is to make a huge fuss about how open the platform is, and get a whole crapload of software written for it that requires fully unlocked phones in order to operate, which will all exist before the first phones even come out. They're even dumping $10 mil into this, and I all but guarantee you that most of those 50 finalists will be using all the cool API features that providers would be happier to lock independent developers out of. By the time phones hit the market, people will be so used to seeing all the sweet things that full Android phones can do that it would be tactical suicide for a phone company to release crippled versions - they would be instantly accused of misleading their customers, with very good reason. I'd be freaking pissed if I was expecting to get a phone that could run all sorts of free map-based software with P2P gaming and all that fun stuff, and when I picked one up none of the software I was promised (implicitly, by their marketing of it as an Android phone) would run.
Think about it - what are the buzzwords associated with Android as far as the press releases go? 1) Open, and 2) Business-friendly. These are largely mutually incompatible, but a lot more people will be pissed if the phone companies strip out 1), so they will have no choice but to succumb to a different business strategy. Google is going to force their hand by making their customers insist on keeping the phone open, just watch - it's rather clever, if you ask me, and I hope it works.
"people will be so used to seeing all the sweet things that full Android phones" Once again, slashdot user != typical user. Normal people want what they see on TV or what their friends have. Not something from videos in the developer section of google's website.
The reason that one forks or fragments a project like this is in order to try to do it right. With so many vendors working on and supporting Android, I think they've got a real shot at making a platform where tweaks aren't necessary to get code to work on another Android phone (compare to getting the same software to work in different J2ME phones.)
That's one of the more thoughtful posts on this topic that I've read. It's also optimistic which is nice.
I hope it works too.
/me begins work on bandwidth-hungry, GPS enabled Android application.
So looking at this from the opposite direction (I downloaded the SDK last night), I think you may have shed some light on Google's rating criteria for the Phase I Challenge. All one has to do is make something that does something the average "G-phone" user would want, but that the cellphone companies wouldn't likely give away without a surcharge or lock-in package. Like you suggest, it's about creating demand for a product that doesn't exist yet, thanks to mobile telco hegemony.
One more thing. I came across this little writeup:
http://ianskerrett.wordpress.com/2007/11/13/what-does-android-mean-for-suns-openjdk/
If you're right about Google forcing the telcos to open up, then perhaps they've deliberately positioned Android for a two-pronged assault: the other target being Sun's kinda-open-but-not-quite-JavaME. After all, they could have done this with a Python variant or something else entirely, so why Java?
Yes, I've had to clean up after someone who relied on Microsoft's locking semantics for their Java application (or rather, their component of a much, much larger application). Knowing the abstractions and not the underlying details does not a useful developer make.
Well, this _IS_ the Internet.
Every time I start to have faith in humanity, I ruin it by driving to work between 7 and 8 am.
It's the Unix philosophy. You get many small utilities that work very well together, and you can pipe the input of one into another if you want to do more advanced things.
This is why grep doesn't let you replace, why ls doesn't let you read files, etc.
Of course, not all Unix programs ascribe to the Unix philosophy--which is why EMACS can read your mail.
IMO, Python got the thumbs down for three reasons, 1) there are far more Java developers out there than Python, 2) there is a much larger body of useful Java code for developers to draw on, and 3) adding Python on top of Java is much simpler than the other way around - all that's needed is to get Jython up and running. I'm hoping that support will be added at the OS level at some point before release, it would be a great addition and make certain kinds of development much easier. Java + Python is a pretty good combo, as each one tends to make up for the deficiencies of the other, except when it comes to speed.
So we have to route around Google's efforts to route around Sun's GPL restriction. Sigh. Unfortunately Google didn't just write an incompatible byte-code translator, which we could have dealt with in a simple way, say with a JVM-to-Dalvik translator. They also wrote incompatible class libraries. Really this is just Java in syntagma. Calling it Java is misleading.
-I like my women like I like my tea: green-
I get your point but any Java developer has to at least acknowledge that there might be some differences. For example, we all know that the threading model is different on Solaris and Windows. Also, clock timings used to have different resolutions across platforms too. Your example is far more devious however and probably could not have been predicted so easily.
You are right of course. That is the point I was making I think. I think the 'run anywhere' claim was overblown at the time and shouldn't be taken literally any more. Java developers have long since realised this and those opposed to Java should stop using it as an argument.
"The FCC won't allow the parts that control the radio, for example, to be user-modifiable. "
That's a red herring. All cellphone chips are locked down in *hardware*. The software can control certain parts (that's why, for example, we have the ETSI specs). And any user CAN modify those parts.
Just because the hardware is locked is no reason whatsoever why parts of the software should be.
We do not inherit the Earth from our parents. We borrow it from our children.
And I don't think openmoko had any problems with FCC approval and are truly open. "free software" is not all that relevant the type of "locked-down chunks" you are talking about - like 911 location service - since they are "locked down" in the hardware chips (by simply not having certain things controllable via serial interface) and not by any software.
So... Letting people make non-free software is evil, but charging people money to make non-free software is not?
I would argue that it's Google versus closed-source phone manufacturers, their service allies, their software allies (i.e, Microsoft), and, most notably, Sun Microsystems and the Java Community Process.
Note the conspicuous absence of any Sun software (or support for it) in the SDK release.
See:
http://ohadev.com/blog/dalvik-vm-icicles-abound-no-sun-in-sight/
One Java to rule them all?
Money is the root of all evil?
No, you're missing the point. Google isn't making phones that happen to run Java. They're making a PLATFORM that developers can target, that happens to use Java. You won't be writing apps for Android that can run on other devices.
There's no such thing as "locked down in hardware" for telephony stacks - the stack is firmware as well and thus subject to being reflashed and modified. OpenMoko and similar devices have a separate baseband processor which runs its own firmware, which you talk to over a serial interface - the application processor runs free software, the baseband processor doesn't.
But.. handset manufacturers in general are moving towards a single-processor model - a separate baseband processor costs money. Either they run an RTOS which has the entire application stack as a task (so, your OS is effectively being context switched in and out, whether it's Linux or whatever) and the telephony stack as a separate task - which is also going to be nonfree - or they run Symbian, which has a hard realtime microkernel and can support a telephony stack running on that alongside Symbian tasks - which is nonfree.
So, while openmoko and similar might choose to make hardware designs that allow it to be 'truly open' - assuming you choose to call it that - other handset manufacturers probably won't, your free software will be stuck running on a closed RTOS to support the telephony stack.
Exactly. I prefer this approach. Fork it if you want to do your own independant thing, but if you want to belong to our trade group, then agree to the non-fragmentation agreement. Everybody should be happy.
I prefer the Apache and BSD style licensing myself, it's really what freedom is all about to me (including the freedom to have your own private fork if you wish). The Apache license hasn't exactly led to the Apache web server itself going to hell in a handbasket due to fragmentation. People are free to fork, but the mainstream is tasty enough that it's what most people use.
Love many, trust a few, do harm to none.
Ah, well. Should have known.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
No, twitter. I think you don't really understand what "unified" means. It doesn't mean being able to copy and paste text across applications, Microsoft figured that out 15 years ago. It means KParts working with GNOME applications. It means KIOslaves working with GNOME applications. It means KDE apps being bonobo-aware. It means that hilarious "embedding" technology OpenOffice uses is used by other desktop applications as well. It means having a single unified shell API. It means not having to load another massive set of runtimes for the "other" desktop when I want to use Kate on GNOME or Gedit on KDE. It means having a single binary layer API like COM that acts as glue for everyone.
That's what "unified" would mean. There is no such thing on Linux, at all. There is unity on Windows because it's controlled by a single entity, but at least there is cohesion and consistency. The only way you approach that in Linux is if you write apps that run on plain X or ncurses.
Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo