Active Topics

 


Reply
Thread Tools
GeneralAntilles's Avatar
Posts: 5,478 | Thanked: 5,222 times | Joined on Jan 2006 @ St. Petersburg, FL
#21
Originally Posted by Matan View Post
So Google is exactly like Nokia in this regard.
Mmm . . . no. Let me lay it out for you:

Nokia contributes code to existing community projects. Unlike Google, they don't go off and create their own closed-door projects whenever possible (examples like icd2 generally exist because the existing options didn't fit their requirements well enough and would've cost too much to make work). In fact, Nokia is one of the biggest drivers of mobile development in Linux. BlueZ, Mozilla, ConMan, oFono, Telepathy, GStreamer, kernel, GTK, Qt, and Scratchbox (to name a few) are all projects where Nokia or Nokia-financed contractors are major contributors in their development (especially in mobile directions). Note the only major commercially viable open source GSM stack is a Nokia/Intel project.

Unlike Google, Nokia works well with upstream. Chris DiBona's comments about their relationship with the kernel at the Linux Foundation Summit last month were revealing. He thought they were one of the best behaved companies in the industry here, and Nokia is clearly kicking their ***. Nokia is a good open source citizen that understands open source isn't there just to be abused.

Nokia's nothing like Google here—they're very nearly everything that Google pretends to be, in fact. You need to look only as far as the kernel to see how well Nokia is doing at the whole open source thing.
__________________
Ryan Abel
 

The Following 3 Users Say Thank You to GeneralAntilles For This Useful Post:
qwerty12's Avatar
Posts: 4,274 | Thanked: 5,358 times | Joined on Sep 2007 @ Looking at y'all and sighing
#22
Originally Posted by GeneralAntilles View Post
[snip]
Oh, I used to believe that, but then I saw just exactly how many times Nokia went off and chose to "create their own closed-door projects" with the N900.

For Fremantle, the plan was to open source tablet-browser-ui, at least according to http://wiki.maemo.org/Why_the_closed...s_for_packages. timeless tells us what really happened: http://mg.pov.lt/maemo-irclog/%23mae...03-16T21:52:36

If tablet-browser-ui had been open, it would've saved conny from making his own clone of the overlayed fullscreen button, based on the maemopad source Nokia put out. The funny thing about the button they included in the maemopad source? It wasn't transparent, much to the annoyance of many in that fremantle-stars thread. Even funnier is that a member of the Browser team wrote that button for maemopad. I guess if it had been released with transparency, it would've been too much like the one in tablet-browser-ui and we can't have that.

What timeless fails to realise is that they did once open neteal and browserd (tablet-browser-daemon). I guess it's the Way of Nokia to not have the latest version of their sources published in the SDK repository.
It is possible to embed the MicroB EAL in an application without neteal just through plain dlopen () but why should third party apps be forced to have higher startup times and greater memory usage, when they could just be served an instance through browserd (via neteal) which Nokia won't open the latest version of.

(For that matter, the open components of MicroB are not even developed in the open anymore. https://garage.maemo.org/plugins/scm.../?root=browser hasn't had an update in months. How do I know it's not being done in the open? Look at the file browser-eal-0.5.5/.hg/hgrc in http://repository.maemo.org/pool/fre...6.1+0m5.tar.gz)

Now, let's take some applets. The applet Memory is closed in Fremantle, like how it has been in previous releases of Maemo. Why? **** knows. It's certainly not a danger to Nokia's secrets as they know it; it's linked to all open source libraries, and it sure as hell is not a USP so I don't think Nokia would lose out too much if some manufacturer in the Far East decides to use it.
For Fremantle, it wouldn't mean much, but for previous devices, it would mean people using/wanting to use higher amounts of swap wouldn't have to hit Terminal just to do so.
Oh, and the Certificate manager applet. This is a fun one as Nokia did actually GPL this and release the source in the SDK repository. But, alas, Nokia saw fit to take it down. Open sourcing a component? We can't be having that now!

On the topic of previous devices: I think we can all ascertain (just as surely that Justin Bieber's balls'll never drop) that Nokia has no intention of bringing updates to them. Fine by me (genuinely), but where's the source to metalayer-crawler and all those other programs et al. that Nokia will never bring updates to so that someone here can do it? I'm not talking about the components that will make Nokia liable if someone decides to add kamikaze traits to BME, but components like metalayer-crawler which nearly everyone disables because it does a **** job of indexing cards with a large amount of media on 'em.

Take components like IPHB and the FM Transmitter. Nokia have contributed open source drivers for them to the kernel (congrats to them for that) but libiphb and fmtx-middleware? Uh-uh. Hell, even the Status Menu applet for it is closed source. 'Twas an annoyance for me as I did not want it to hide once the transmitter was turned off. It wasn't a particularly complicated applet so I looked at what it did and managed to write a (even if I say so myself) a damn perfect clone, even taking some better approaches to things than what the guy at Nokia was doing.

And being able to share any file to any service. In the beginning, Nokia didn't want you doing that. All http://wiki.maemo.org/Documentation/...ing_dialog_API would only contain information on how to send files via Bluetooth and email; both were already possible on previous devices.
Now, I'ma be arrogant here and say that "Using Sharing dialog API" was added because of me and Stskeeps for opening the bug, Why? You see, I'd already figured out how to bring up Nokia's undocumented Sharing Dialog in Petrovich and had released the function signatures for all the world to see. So, really, there was no point in holding back the -dev package for it and, indeed, we got to see it in Nokia's heavily-populated nokia-binaries repository. Still, no source, but truth be told, I don't think anyone has much interest in that component anyway.

No, what people would like to see is libcumulus, another closed source component, for its tagging abilities so that they can be utilized in third-party programs. But, alas, no source nor headers.

libconnui_cell. Ah, a favourite of mine. This, like its brother libconnui (which also features in previous versions of Maemo), is also closed source without any headers available for developers to use. Nokia have employed interesting logic here, as they've placed headers in the nokia-binaries repository for controlling the cellular chip.

Had the headers to this one been released, I wouldn't have pissed time away looking at undocumented D-Bus methods to change what mode the phone is in re. connecting to networks (3G/2G/Dual) and finding out how to change the Caller ID state.
Nor would I be waiting on the delivery of O2 SIM cards just so I can figure out the get_service_provider_info method. This is the third of two other undocumented methods I've looked at just so that I can retrieve the name of the current operator!
fiferboy wouldn't have also have had to write his own functions to get and interpret the data counter values.

I've just talked of a fraction of closed source components here. If Nokia really were interested in open sourcing many of theirs, they would've started with Diablo, a version of Maemo they have no plans of bringing updates to.

And the policy system. Made up of an open source component, OHM, with closed source parts. Responsible for, among many, many other things, disabling the headset button outside of a call and not allowing third party applications to play sounds in Silent mode (through a PulseAudio plugin that communicates with the Policy System; again, closed source). Now, on https://bugs.maemo.org/show_bug.cgi?id=6694, I was told my way was wrong. Fine, but why the **** wasn't we told the right way? Hell, still, to this day we don't know the "right way" because that -doc package hasn't been released yet.

Here's the kicker: Nokia won't fix many bugs in applications that come with the N900, but they refuse to open source the component in question so that someone else can do it.

I do recognise Nokia's contributions to Open Source (of which there are many, like Mission Control). I think it's great that the kernel and modules are all open source on the N900 (for the N8x0, you had umac.ko - something outside of Nokia's control - and building a new cx3110 module for the N8x0 was made a fun task because of this) and I'm sure Nokia's contributions to Tracker to make it more power-friendly help people running GNOME on a battery powered device, but when looking at the amount of closed source components and headers that Nokia will keep back from you on the N900, these achievements mean nothing to me as these aren't the areas of the N900 that interest me, not in the slightest.

[Congrats to me. This is the longest post I've ever written, I believe.]

Last edited by qwerty12; 2010-05-30 at 07:16.
 

The Following 11 Users Say Thank You to qwerty12 For This Useful Post:
Reply


 
Forum Jump


All times are GMT. The time now is 05:05.