Forking hell
Google in embrace, extend, exterminate shocker . Who'd'a thunk it?
After removing Google's Android driver code from the Linux kernel, Novell Fellow and Linux developer Greg Kroah-Hartman has argued that the mobile OS is incompatible with the project's main tree. Kroah-Hartman deleted the Android drivers on December 11 - Android code is no more as of version 2.6.33 of the kernel release - and …
Some of Greg's argument is that he wants Android to start modifying kernel internals at the same maddening pace as the 2.6 mainline tree. That is a "no way in hell" item and I am glad that a company that is large enough to say "no way in hell" has finally said "no way in hell". Applause.
It was about f*** time for someone to take offence with the current practice where every distribution maintains its own kernel fork, there is no stable tree and no development tree. That may suit Linus very well, but it does not really suit anyone who uses Linux in production or has to try to port a driver once in a while.
The google code is open, it was posted to the tree but NOBODY did anything with it, it went stale and Linux Admins removed it as stated.
To all and sundry who are slagging google try reading the article.
IT is a sad day, in terms of compatibility. Perhaps if the open source comunity would have embraced and not let it fall from the tree then we would all be happier.
However thsi is not the end of android and it is not the end of it being open source.
Er, so why didn't they just base it on OpenBSD, then?
As for Google, the fork is still GPL-encumbered, so it's just as much part of the OSS ecosystem as the non-forked kernel, RTLinux, uCLinux, etc. etc. The counter to the position of the Linux developers is that maybe server-grade Linux is not the best choice for a mobile OS, just as it's not the best choice for a real-time OS, or the best choice for a microcontroller-based OS. The kernel devs are right not to have a problem with this; forks are one of Linux's strengths, not one of its weaknesses.
BTW, if you use BSD-licensed code commercially, that's not stealing. You're explicitly allowed to do that. BSD and GPL reflect differing philosophies. The GPL philosophy is not some sort of universal default.
As long as Android stays open-source (GPL) then the world still has access to source code for mobile-phone hardware. So if someone decides that they want to port Linux onto hardware on which Android runs, they'll have access to working copylefted code. Some parts of it will be reusable. Other bits won't be usable except as documentation, but at least it's documentation that's been tested and de-bugged on the hardware, rather than a figment of a document-writer or translator's imagination.
I once connected hardware to VMS, given the source code for interfacing it to MS/DOS. None of the code was portable, but the working source was nevertheless a great help compared to the (hopeless) English language hardware documentation (translated from Japanese?)
And I think the jury is still out on whether one O/S (Linux) really can scale across everything from a mobile phone to a datacenter cluster. The phone environment is one where you pay (in battery life or weight) for inefficiency in the software, and maybe the linux kernel represents too much of a handicap. Or maybe not. Time will tell.
I suppose you are right about just using BSD and I do acknowledge that google contributes somewhat to the OSS movement. Whether they contribute in fair share to the massive revenue they generate by building out the worlds largest OSS structure could be debated. I will agree also though that Linus (and associated henchmen) though a great contributor to mankind can be a bit of petty tyrant as well (cough bitkeeper). Still I hope both continue even more so to make Linux such a joy owned by all of mankind.
Basically, if he's totally ignored by the developers for the code, gets no replies to his emails, etc. then he just drops it on the floor, because he doesn't have much choice.
Google apparently wants to look like it's contributing, but not actually doing it, then blame the kernel developers for "oh, they wouldn't accept our lovely code!" - other people have done this too, it's not a new dodge.
What part of "has dependencies on code that only lives in Google's kernel tree" do they not understand? Why aren't they contributing all the code?
It's not great that the android drivers can't be put into mainline... I think it'd be better overall if they were. But, I do agree that if they are using their own locks, their own framebuffer code, slapping in an extra security model, etc., and not really trying to use what's in the kernel (or make a good reason why they NEED seperate code), then it's better to pull it out... every platform having it's own platform-specific lock types and etc. would be a huge mess before long.
It's not terrible either though, it's fairly common for odd platforms to have their own kernel versions... MIPS and PA-RISC did for quite a while (the bulk of the MIPS or PA-RISC support was merged in, but it took a while for the bugs to be worked out of mainline, requiring platform-specific kernel patches to actually yield a bootable kernel.) A lot of embedded platforms have their own branches, with lower memory and CPU power than a typical desktop or server, the branch can be cut down in ways that are not portable but speed up the kernel for that platform; embedded platforms (including Android) also don't have expansion slots, so the user is not going to put some new card in then lament not having drivers from a newer kernel.
Ultimately, if there's enough interest, I suppose the Android code can be made to use regular locks and framebuffer code, and then be merged into the mainline kernel. If it turns out the performance is lower or something (maybe the special locks sped things up...), people would then still have the choice between a "stock" mainline kernel and an Android kernel.
Google are an accident that happened already. They were once quite innovative, but to be honest they are like MS in terms of stealing / parasiting good ideas from elsewhere and using their financial muscle from their advertising success to enter and eventually flood other markets / products.
In my view Google are worse than MS because everyone has known what MS' game is all about, whereas Google have been ever so sneaky, playing the nice guys whilst all the time using that image, to con people.
Just look what they did with Mozilla. Supported it and then stuck up 2 fingers once theyd achieved a critical mass to launch their own browser.
El Reg, we need a new icon "Google is Evil"
Microsoft and Apple are also doing it, so what exactly is your problem ? Oh, and one more thing, GPL license also makes sure you contribute back to the community.
To make this clear to you, the GPL license is not free in the same way you are not free to take away other people freedom. Get it?
"Microsoft and Apple are also doing it, so what exactly is your problem ?"
His problem is exactly that - Apple and MS are doing it. Quite a few Freetards have issues with Apple's use of OSS, despite Apple's contribution to WebKit - you know, the best browser engine out there by far. Freetards really think everything should be - and *can* be - free, and that no-one can make money from OSS, licenses be damned.
Microsoft are of course paying OSS lip-service in exactly the way Google does. "Don't be seen to be evil."
Based solely on the Sunspider benchmarks I am sure. Who makes those benchmarks again? Hmmm I think it might be Apple. And the scores are never better "by far", usually ms differences. You seem to forget that webkit was based on KHTML and there were long disputes between Apple and the KHTML people before webkit actually satisified both sides. Not to mention that they implement quick and dirty fixes so that they can pass ACID tests.
"Microsoft and Apple are also doing it, so what exactly is your problem ?"
Just this: The hypocrisy. Do as I say, not as I do. There's enough of that about without infecting open source with double standards.
What part of "Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer" do you not understand?
Relicensing is NOT an option. BSD code stays BSD licensed. Extracting strings from the Windows XP nslookup binary proves that Microsoft have fulfilled their obligations. Relicensing BSD code under GPL, however, is not compliant.
But who cares? It's only BSD, right?
The BSD license is good, precisely because it doesn't push people into a constrained model of software distribution and development (which both closed source and the GPL do). I have no problem with commercial/closed source organisations taking BSD code, doing something useful with it and hopefully furthering its visibility even if nothing is contributed back. Sometimes companies do contribute back to BSD code anyway, which is is always useful.
Taking away someone's freedom in order to push your own viewpoint is an extremely dubious definition of 'free' - this is precisely what the GPL does, because it is limited in ways the BSD license is not. I'll grant that there is perhaps a limit to how far proponents of the GPL are morally obliged to contribute back to the original BSD source, but I would suggest that the limit is considerably above zero.
In other words, many of the aims of BSD and GPL fans are identical, so expecting programmers to enhance and contribute to your code whilst refusing to do precisely the same to the original BSD source could be considered both hypocritical and abusive.
This post has been deleted by its author
the BSD license does allow for code to be reproduced, however there are incompatibilities between the BSD and GPL licenses that mean you cannot take BSD code and re-license it GPL or vice versa.
A good number of projects run dual licensing, but that requires the permission of the original authors.
If you search the web you will find a fair number of projects that have arguments over this sort of thing, in both directions, just have a look for the bcm43xx driver project for OpenBSD (bcw driver) : http://lwn.net/Articles/229742/ and forum entries related to this discussion ... they get quite heated.
RING RING.
You realises that all the emo linux fa{ng} boys will mark you down. But yes it does piss me off how they just take BSD code, change it a little and then refuse any of the improvments (if any) to filter back to the BSD code. Would be like Apple taking a bookstore interface from another company and redoing it in such a way that they could deny the other company even thought of it at all. There again I've always thought of linux as the microsoft of unix's since version 2 onwards. So to read how the Linux kernel click go emo over some changes they cant fully steal and bastardises is frankly the most funneist and sadest things I've read this year.
`"No one cared about the code, so it was removed," writes Kroah-Hartman` If we translated that into theo speak it would read "I cared so meh to the rest of you" :).
That said the politics of kernel managment is very much onpar in its parrelesls to school playground politics. Just a clear observation there.
FAO REG HEADS - were is my BSD icon, I want one now dammit Jayne.
They still have to produce the code if they're distributing it (and they are.)
It might not be an easy import into the mainline, but it doesn't mean a clever developer can't look at it and try to merge it back in, or look at a device driver and try to port it back to the mainline.
Interesting to review Reg's December 23rd article - "Google 'open' memo betrays deep corporate delusion" - and the various comments following it. Seems to me, as an observer outside of the Linux community, that company deeds and staffers' words don't quite tie together ...
Google is a Trojan Horse........ with Rabid Thirst and your Every Personal and Private, Public and Business Weakness and Desire for Exploitation and Heavy MetaDataBase Analysis/Deep Packet Inspection/Digital Rights Manipulation and Proxy Intellectual Property Theft and Plagiarisation? Nice ..... when One Knows All Evil, or even just Thinks that One Knows IT All ..... which is a Most Reasonable and Perpetually Wise Nagging Virtual Doubt best Safe Harboured in Order to be Eternally Protected against the Arrogance of Total Information Awareness, on Guard against Envy and Catastrophe which always Accompanies and Dogs the Lack of Humility in Perverse and Subversive Self Centred Intelligence.
* Wall Street/Capitalism/Google/Sergey and Larry/Alien$-) ........ Uncle Sam, an Enigmatic Scarlet Pimpernel and Certifiable Manic Depressive/Yin Yang Bi-Polar Refugee/Asylum Seeker? ...... or Zero Day Hero?
Smells to me of "This will create headlines, let's do it".
Basically, kernel.org is telling Google that it's big enough not to need all their money and donated employee time. Fine, go ahead. What happens when someone builds a laptop with a touchscreen and you want to provide touchscreen drivers? You can't have them because you gave them back to Google and told them where to stick it.
Of course it cuts both ways - if anyone finds a bug in the Linux kernel (unlikely but possible) and releases a patch, I don't get it on my phone until Google release their own patch - even though the code will be identical.
Well, Linus and his followers managed to kick out Google... the question will be --- what will be more popular: Linus's Operating System or Google, who runs a huge portion of the internet's, soon to be phone dominator, soon to be tablet dominator, Operating System?
Sounds like the beginning of the Linux Wars - in 2010
Linus of course. Google's chrome OS or Android mobile OS won't touch the hundreds and thousands of servers running Redhat, SuSE, Ubuntu, Novell distributions of Linux, not to mention the lesser-known ones like Mandriva and Slack. Tablets and mobiles don't run the Internet, they only use it.
Novell and Redhat have both built highly profitable businesses from Linux (the kernel on it's own is not an OS.)
Google do not run "a huge portion of the internet's operating system." If you're talking about the Google web server, only 2% of requests to the million busiest websites in January was to GWS. 67% went to Apache, and 17% to Microsoft.
It'll be a long, long time before we have to worry about the Google IOS.*
*Internet Operating System
If Google's additions to the Linux kernel were so designed as to be only relevant to Android systems, then they would indeed cause bloat to the kernel, which should be avoided.
However, this should have been addressed in a diplomatic manner, giving Google an opportunity to resolve the issue. Perhaps there would have been a way of making the Android-related code an optional extension to the Linux kernel, for example.
If people find stuff from Google's Android useful, it may indeed happen that Linux will become history, and Android will replaice it. Is this spat with Google worth risking that possibility?
This post has been deleted by its author
"if anyone finds a bug in the Linux kernel (unlikely but possible)"
Really?
Linux code is 100% perfect?
You could try visiting
http://bugzilla.kernel.org/
or this for general stuff
https://bugs.launchpad.net/bugs/+bugs?field.searchtext=linux&search=Search+Bug+Reports&field.scope=all&field.scope.target=
You see, this is what we battle against, deluded people who bang on about something, with little knowledge about what they are talking about.
that surprises me about this story is the amount of people who have apparently only just worked out that Google are a "for profit" organisation the same as any other business structured the way Google are structured and "Don't be evil" is a marketing tagline just as much as "Think Different" or "Where do you want to go today".
I expect the Google will force them to do a lot of back/cross ports (security) from the Linux kernel. Wow that will take a lot more effort. Makes you wonder how insecure the Google phone will become. I expect Nokia (Symbian) and Istuff have the same problems with closed software.
...act brutal. But really, this should come as no surprise to anyone. Google needs to make money just like any other large software company. At some point you sacrifice the "be good" and have to "act a little evil" to keep up with the other big boys.
Nice to see Google coming over to the dark side.
As soon as they started Android you knew it wouldn't last, and the amount of locks ins android has to google means you can't go back. You need a Gmail to sign up and use the thing in the first place and everything is 'google apps or not ' pretty much. They are doing what Apple do and it will just generate another bunch of fan bois nobody likes.
It won't be "Is there an app for that?" It will be "Is there a google app for that."
I just got the N900 and it suits me, I just hope Nokia don't take mamo, meamo (whatever its called) the same way later on.
We need an icon for the "blindingly obvious" or "well I didn't see that coming..."
...between the Jesusphone and the Penguinphone, let's see..
Apple: Requires you own a Mac with a more recent version of OS X to develop on it. Good if you have a bottomless wallet. Tough shit if you only have Tiger.
Google: SDK available for Windows, Mac and Linux.
Apple: Works on the Ipod Touch, Iphone and Ipod Maxi (sorry, Ipad).
Google: Works on a fuckzillion Android handsets out there and increasing.
Apple: Uses "Objective C", and an Apple-specific version at that.
Google: Uses Java. You know, that tiny thing that nobody has ever heard of?
..I'm sure that there are other ways in which Android provides a hell of a lot more choice than anything Apple will ever do, but for now I think the above is probably most important to app developers. I'm no fanboi, I don't even have a "smart" phone (nor see the need for one). What I have been doing though, coincidentally, is perusing through the app developer sites for both because someone at the college I'm studying wants to develop Iphone apps.
He doesn't have a Mac.
Some code that wasn't being maintained is no longer part of the main branch. Neither party is particularly upset at the other and they each concede the legitimacy of the other side's position. There was no legally or morally binding agreement between them before, and they've managed to disengage from each other's affairs without any observable fall-out.
How in the name of the spaghetti monster is this a story?
The story is that Google added Android stuff to Linux and published it... but the guardians of the Linux trunk route (to the future) are excluding the Android material from the trunk? So you can get Android source code(?) or get Linux source code, and play with either, but if you're playing with Android then your work too is excluded from Linux - unless you also write a Linux version of it?
And what did they need to write separately anyway (they thought)? Telephony?
Linus is not an a-hole. He's a bastard (as in BOFH) and you can ask him yourself if you don't believe me. Linus' function is to oversee the kernel code repository and be a single point decision maker in the event of disputes. If Linus wasn't a bastard with power the LKML would be full of arguments and nothing would ever get committed.
This is one the strengths of Linux: Without an overall "benevolent dictator" it would be rule by committee, which we all know is a recipe for disaster. So, I'll go so far as to say Linus' function is essential for the smooth running of the kernel development process. Linus occasionally delegates power to other sub-bastards for the same reason. Yours is not to reason why, yours is just to enjoy the results. If you think you can do better, why, just fork it!
Calling Linus an a-hole can only be the plaint of someone too young to have known a time when none of this stuff was around. (Unless a-hole is short for architect holistic e-man.) It's like calling the inventor of sliced bread an arsehole because some people slice it so thin it falls to pieces in your hand while others slice it so fat your face disappears when you try to bite it. Linus is essentially why a global community of hackers - sorry, I mean peer-reviewed software developers - started up when it did. He found a simple way to get kernels talking to each other and he used it to invite anybody to join in. The best hack held the floor. It was not only not rectal, it was effective, democratic and bloody inspirational. People of a certain age never witnessed this computer transition from a house to a small fist-hold, from little texty terminal in hock to a room-full to see-hear-speak what you want to anyone you want.
And meanwhile, Mr. Dos could hardly get his port out of the garage, let alone drive it down the
street and say hello to the neighbours.
The name of the game is configuration management and control: forkityer and audit trail. The rest is commercial secrecy and attempting to own the internet. If that's what you want, don't expect the next generation to get turned on by a pile of droppings.
No matter what google have done (or in this case not done) comparing then to Microsoft is not valid.
- Google do actually contribute code and do GPL code
- Google (unlike MS) are not having a jihad against Linux ( http://www.groklaw.net/article.php?story=20100124111743687 )
- Google do not take a certain percentage of my tax - even time we pay takes MS gets some of that money
- Google does not support the Republican party
And also it's not like:
- Google have another allegedly open source OS in the pipeline that they might want to strong-arm vendors into supporting rather than the main-line Linux kernel
- Google are fashioning said imaginary OS to coincidentally support their Mountain View Chocolate Factory ad-opoly money hoovering/printing machine.
As if!
So, if I understand GKH correctly, Google/Android have made their all their code available, per the GPL, but the Keepers of the Kernel want them to change it before they're prepared to merge it into the mainline, and Google have said "no thanks, we like it the way it is". I guess this is inevitable with the one-size-fits-all approach - you can't keep everybody happy all of the time, especially with something as volatile as the Linux kernel. Who's idea was it to use a kernel which is essentially a badly-reinvented version of a timesharing system for PDP-11s on a mobile phone anyway? ;-)
Likening the current Linux kernel to V4-V7 Bell Labs. UNIX on a PDP/11 is like saying that your Ford Mondeo is a re-implemented Model T.
It's true, it has four wheels, a motor, and used a steering wheel, brakes and a gearbox, but there ain't no compatible parts!
Now I'll defend V6 or V7 as being brilliant for their time until the cows come home, but don't suggest that Linux is 'just a re-implementation'. Even if you did, SVR3.2 with TLI or BSD4.4 would be a better reference than anything that ran on a PDP/11 (think communication subsystems).
And anyway, why should Android not be multi-tasking (OK, I'm blurring the distinction between timesharing and multi-tasking), but both the timeslicing and the privilege protection is just as useful in a mobile device as it is on a multi-user computer. After all, the inability of the iPhone and iPad to multi-task is one of it's biggest criticisms, and having an ineffective security model was seen as Windows biggest problem. Multiple tabs in Chrome on ChromeOS will probably be implemented as threads which will probably need to run in parallel, anyway.
Whilst BeOS, OS9 and VxWare people may think their OS's have significant advantages over a Linux kernel, Linux is not such a bad place to start. The API's are well understood, the code is open, and you can comfortably remove the overhead you don't need (I remind people that vanilla V6 UNIX on a PDP/11 without separate I&D space HAD to fit in less that 56K of memory!).
The reason I mentioned Google not sponsoring the Republican party is because Microsoft does (financially) , therefore by paying Tax in the UK (which MS gets part of due to Police/hospitals/schools buying windows) you are helping a sponsor of the Republican party.
Of course that is the least important factor in my decision to avoid Microsoft products..
I don't really see the issue; shock horror Google develop code and implement it differently than the mainline kernel.
Linux kernel developers don't like how the code works and realise that it cannot be added to mainline kernel due to hooks and none standard frame buffer.
Google possibly just take the attitude that it the mainline Linux developers won't include it whats the point in trying; I don't see how this is any different that other linux distros which choose which kernel to include and what changes to make to it.
I'm sure you could get Google's code and manually include it in a later kernel version but it's possibly a pain to do but do able.
Google are not Microsoft - Google at least contribute code back where as Microsoft just choose code with a BSD or big obligations type license (i.e. not GPL).
From dim memory BSD gives you the source and you report any bug fixes *but* any additions or non bug fixes are *yours* to keep. MS *like* the BSD license a lot.
GPL *requires* a 2 way street. They hand you the bug fixes (found by a worldwide developer community if you did not) and you hand back any extensions you developed. It seems Goggle have been handing back bits with references to non kernel components (whose code they have *not* supplied) and other parts that view core data structures in non standard ways.
This code is *useless* to the Linux kernel.
People have been trying remind users that Android is just a form of Linux. Clearly Google no longer want to be a part of this process. They want to be a *proprietary* OS, with a locked in developer community. IOW just *like* Windows.
There is nothing proprietary about it. From the article:
'But the larger problem, he continues, is that Android uses a new lock type, new hooks for its "sometimes bizarre" security model, and a revamped framebuffer driver infrastructure. All this, he says, prevents "a large chunk" of Android drivers and platform code from merging into the main kernel tree.'
Nowhere does it say they are refrencing non-provided code. (if you cite a source to back that, it does change matters a bit.)
To simplify that for you: "they are doing stuff we don't like, so we won't put it in." Google provided the code, which was more then they had to do (they only HAD to provide it to people they distributed to, per The GNU General Public License ver. 2, Paragraph 3, Subparagraph a). Using GPLed code does NOT mean you have to rewrite your code to fit someone else's use case (even if it is the kernel developers). If Google want's to change the driver infrastructure for framebuffers, and the kernel devs don't like the changes, they don't have to incorperate them, but it doesn't obligate Google to do anything. They already met the requirements of the GPL.
Puting aside reactionary flaming and trolls (theres a novel thing)...
It looks like a simple protracted case of company puts bits into kernel as a supplier of that bit to bolster its open source credentials, but keeps other bits away secret but the expectation is over time they'll put it all in. Kernel devs then spend a long period saying "its about time you honoured that stuff about the extra bits", then realizing that nobody's bothering to listen or pay attention, they do the only thing they can. Chuck it out since without the other bits its just unmaintainable fluff anyway. They cant change xyz in a maintainable way in the open source parts in case it screws up pqr in the binary blob non shared source bits.
How many of us get promises from suppliers etc to fix things when we find a bug or issue, only to review a few months later to find theyve done absolutely jack thinking they can get away with it instead of spending money on fixing things. At which point the big "we'll get rid of you if you dont fix it" stick comes out to encourage them to make good on their promises.
So, in your corporate environment, how much would you tolerate a supplier taking the mick? would you mind if you asked them to fix something and they just ignored you? would you re-engineer your internal setups to eliminate their product?
If the answer is no, you deserve the bug ridden sloppy steaming pile of poo you will end up with and the suppliers will love you to bits for letting them get away with it, its all a game, the supplier wins by saving costs and not fixing, you win by either forcing them to fix or getting any reliance you have off their kit.
So why is it even a issue when the kernel devs operate on sound business principles too?
AFAICT,
a) the mainline doesn't want the Google code because it has been modified in such as way as to make it difficult/unnecessary to merge. Now that is simply a sensible choice.
b) Google has made changes to the Linux code to make it more suitable to their business purposes. Perfectly within their right's under GPL, and the code they have changed is still under the GPL, not closed. So, the code is available to anyone who wants it. (go on, you can download it RIGHT NOW)
c) If some people do want some Google Android code to work on the Linux mainline, they are perfectly entitled to integrate it themselves as they have access to all the source code. It will be easy in some cases, difficult in others.
So, where is the problem? Sounds like a perfect example of OSS in action. Google have take GPL code, modified it, and released the resulting source as required by the GPL. That fact that mainline doesn't want it surely has nothing to do with OSS?
"Because Google doesn't have their code merged into the mainline, these companies creating drivers and platform code are locked out from ever contributing it back to the kernel community,"
Because they're totally incapable of porting? Why would the development of an Android driver preclude the development of a Linux driver? OK, so they can't produce one driver for both, but they can't product 1 driver for, say, Windows and OSX, either. Surely it's just a matter of having, say, separate header and interface files for the less that 10% of code that has to be different for the different OSes?
Others might see more value in writing code that isn't gratuitously incompatible with the existing kernel, but whatever.
Forking is fine, but when the rest of the world doesnt want to follow you should keep churlish remarks like the one in the title to yourself, Google.
> Android uses a new lock type, new hooks for
> its "sometimes bizarre" security model, and a
> revamped framebuffer driver infrastructure.
These aren't trivial changes, and these low-level changes will probably continue going forward to further divide Android from the base Linux kernel. Android will be a 900-pound gorilla in the OSS space and will be viewed as "another version of Linux", but, in the eyes of IT managers/sysadmins/developers, this just means that Linux has AGAIN fractured from within in a major way (a new distro with its own patches and peculiarities). This splintering apart is not a source of strength for Linux, it is a weakness, it impedes the development of momentum in the marketplace and the development of critical mass. If, a few years from now, it's common to hear questions like, "What does that thing run, Android or Linux?", will that be good or bad for Linux? It certainly won't be good.
The Linux kernel developers explained at length the problems created by Google. Basically Google insisted on adding some proprietary hooks to the kernel, setting the stage for other such hooks by other companies. This is neither sound design, nor bug free, and it presents another security risk. The developers also explained how Nokia cooperated with the kernel team and resolved the exact same issue in a satisfactory and clean manner. As a result, Nokia still uses the standard kernel while those who use Android have forked themselves. There you have it - Nokia doesn't have BS slogans but they do play well. Goodbye Nexus, hello Nokia.
Google can easily afford to fork the kernel for it's Android project others have done so with only a tenth of their corporate pot to pull from just a matter of programing. Now do they want to thats another story altogether are there any people(user/ developer/ community/corporate partner) risks involved you can denegrate the concern but it is a real concern for a public company.
I always wondered why all this 'linux' (a misnomer, i know.) stuff is in this perpetual state of 'under development'. When will it be ready and ship as a product that doesn't need messing with ? I'd love to see it one day.
...grabs 720k floppy with kernel 0.89 and second 720 k floppy with very early xwindows port ,640x480 driver , and xeyes ... ahhh memories.
Hi all. I haven't been here for a while but why when I click comments does it take me to the last page of comments instead of the first??? It's really annoying as I have to read comments which are relevant to previous comments and the whole thread is f***ed. Or is it just me???
Sorry for posting this here but it's getting on my tits and since the site has been 're-done' I cannot seem to find the appropriate channel to express my... annoyance at this.
I hope the Linux kernel developers will stay strong and think carefully about merging any new "foreign" code, like before.
I like to believe Google is not the new "Microsoft", but then again, big companies are always so damned attractive to all the small pricks of this world, and I am not all that convinced that Google can prevent that virus.
But to the thing that happened, "rubbish" was not merged into the kernel. Fine, normal, so what is the problem.
Well, the size of the rejected proposer. So what.
Some years down the line and there's two "Linux" kernels, the Mainline and Google's, forked and diverged totally, sure it's all GPL but so far apart they are different beasts, probably rare if anyone has a full understanding of each.
Google, resource packed and deep-pocketed, can acquire in-house staff to port all that's new to Mainline Linux into Google Linux, but it isn't going to cut so well the other way, so eventually developers have to decide which side to take.
Shouldn't be too long before Google owns the Linux arena, and what was Mainline falls by the wayside through neglect, not having the good stuff (TM) that Google Linux has, and the 'in crowd' getting hard-ons over Google's better offerings.
And then Google starts replacing GPL code with proprietary code in a manner which doesn't breach GPL licensing,
So it's goodbye Linus and Mainline, hello Google and Google Linux ( aka New Proprietary Chrome OS ).
Come on; you didn't think Google doesn't want to dominate in every market and everything it puts it's sticky fingers into did you ?
My point was that Linux inherits from UNIX lots of fundamental concepts that aren't really useful in a small embedded system. You're not going to have a hundred different users logged into a smartphone at the same time, and the hardware you need to handle doesn't really fit well into the simplistic open/close/read/write/ioctl driver interface model that worked fine for disks, tapes and terminals. If you designed an OS from scratch specifically for a smartphone, I don't think you'd end up with something that looked much like UNIX or Linux at all. Multitasking is of course a great thing to have on even the simplest embedded device, but you don't need Linux to do that. As for iPhone OS, since it's based on the Darwin kernel, I'm sure it does multitasking just fine - it must be an artificial restriction that stop apps doing it.
Google are linking their kernel with proprietary unreleased code. Manufacturers are adding drivers and other stuff to the Android kernel which has dependencies on this unreleased code.
How is any of the work by Google and others benefiting Linux? not at all, Google is benefiting quite a lot from Linux though.