Linked by tessmonsta on Tue 16th Mar 2010 08:55 UTC
GNU, GPL, Open Source Today's mobile space is owned by the likes of Nokia, RIM, Apple, and Google. While some of these corporations have embraced some open source components, a full FLOSS solution has yet to gain traction. Why? Blogger Bradley M. Kuhn posts thoughtful analysis of the current state of Open Source in the mobile space.
Thread beginning with comment 413980
To view parent comment, click here.
To read all comments associated with this story, please click here.
Neolander
Member since:
2010-03-08

@Laurence : First, thank you for posting that excellent comment ;) I can't mod you up because of OSnews's unusual rules, but I may congratulate you this way.

I agree with what you're saying in principle, but proprietary software doesn't always get it right either.

Totally true. I tried to install my beloved GIMP on Mac OS X and I can tell that being proprietary-oriented is not the solution to anything. I just say that when bits of proprietary management (not necessary proprietary softwares) are carefully introduced in strategic places, one may get way better results.

Take Windows for example:
* You have a range of APIs from .NET and Win32 through to DirectX. So you end up with half a dozen different APIs that can be used to do the same job.

I don't believe it's true, even though I accept proofs of the contrary. For a long time, Win32 did an excellent job at making applications that just work almost alike. There's a lot more free (as in free beer) software on windows than on linux, but I actually encounter a lot less usability and theming inconsistencies on windows.

It's logical when you think of it : programming Win32 was incredibly easy, thanks to simple yet efficient dev tools like Delphi, C++ Builder, and even VB somewhat.

.Net did indeed introduce some mess, but not until Windows XP. And its use remains quite limited, though slowly rising since the death of powerful Win32 dev environments (RIP Pascal object... Sigh...). Actually, Microsoft are more victims of their own success, now that they face Win32's limitations and try their best to make people move to a new platform when they don't want to.

About DirectX... Did you actually encountered applications which code their interface directly using DX, apart from games ? Games have traditionally non-standard interfaces, on every platform, and customers are used to it, so it's not such a big issue.

Sure, there's some shitty non-standard interfaces (noticeably flash-based ones) on autoruns (that are sentenced to die by microsoft anyway). And on installers too. But most software remains Win32/.Net-based and consistent with other software...

* There's no standardisation of interfaces between the numerous Office versions, let alone Office, Visual Studio, and basic windows apps (Explorer, Notepad, etc).

And that's just Microsofts in house projects.

Totally true that Microsoft, and Apple to a lesser extent, don't know how to apply their own interface guidelines to their softs and look like most software around. Again, proprietary guidelines can't do anything, people must actually use them.

When you take the wider Windows platform you have:
* Java which looks and behaves hugely different to .NET / Win32.

Desktop java applications aren't very common, except in corporate environments...

* countless 3rd party projects that don't adhere to Microsofts UI (often creating their own widgets and toolkits)

And infinitely more that do adhere to it, contrary to the Linux world where we get the reverse picture

* countless application duplication (from professional studio suites to freebie config toys).

Of course, but not at a core level. To say it in a different way, they don't depend on each other in an intricated way. You don't need VLC to mix audio with REAPER, and you don't need GIMP in order to use firefox. Duplication very rarely occurs in the API area on Windows, which is a blessing compared to the multimedia madness on linux.

* several different codecs for the same media (video / audio) file types
and so on.

...and codec packs that install all of them definitely, without needing to get through gstreamer here, xine there, and ffmpeg somewhere else.

The point is, sometimes duplication happens because users like to have a choice of application as different projects tackle the same problem differently. So what might be intuitive for one person might not be as intuitive for another.

Yup ! But again, that's true at a user application level. At a core level, a lot of thing are well-defined and don't need to change everyday. If multimedia and basic UI APIs are well-made, like DirectShow and Win32 used to be, there's no need for a new codec set and massive effort duplication, nor for multiple inconsistencies due to use of several widget toolkits.
Which leads us to your next point...

Sometimes duplication happens because the existing tools available aren't up to scratch and it's easier to start from a clean slate than to fix something that's broken.

I can't agree more ! In order to work, the proprietary development model must offer excellent dev tools to begin with, that devs would want to use instead of reinventing the wheel. This means that :
-Design must be carefully discussed and well-thought the first time.
-Communication is a very important issue, as I told before. The system devs must be constantly talking with the user application devs in order to stay informed about their needs and introduce changes in the API as soon as it is needed, before someone decides to make a duplicate of a system library and make the OS enter a Linux-like hell. Contacting them should be very easy, too.
-Good IDEs and encapsulation in APIs are critical. If you make your own dev tools, you can tweak your OS without the devs even knowing, which gives you extreme freedom compared to other options available.

And sometimes duplication happens simply because developers just fancy a personal challenge.

I don't think OS devs can do something about this one, except using a "recommendation" system like default repositories which make installing software preferred by the OS devs easier (without forbidding use of non-preferred software or making installing it a nightmare though, we're not Apple)

But either way, I consider the variety available for Linux an asset rather than a draw back.

Variety is a double-edged blade. On user apps it serves you. On core APIs, it makes life of OS builders, users, and maintainers close to hell.

The problem is polishing enough products so there's alternatives to choose from if you want rather than alternatives users are forced to investigate because the defaults are buggy.

Yes. Defaults must be good enough so that the vast majority of software uses it, for reasons that should be obvious. And slightly pushed forward to make sure most people will use them. But jailing the user is infantile and inefficient.

So users shouldn't need to know about the different GUI toolkits nor sound engines so long as there is themes / wrappers / etc bridging the differences to make applications and utilities use widgets or sound in the same seamless way regardless of the developers API preferences.

That's my point about standards, proprietary design and feature requests but free implementation. OS builders don't have to do anything all by themselves, and they can't anyway. But if something is likely to be often used, and shared between applications, they should better tell developers how it should look and work. And maintain it themselves if use of it is really extremely common (typical example : basic GUI widgets like windows, buttons, pointers, labels, edits, and so on).

And that my friend is the problem with Linux. NOT the variety, but the lack of coherent compatibility between the different APIs.

Right. But do you know a way to reach that coherent compatibility without a shared underlying proprietary design ? I don't know that myself, that's why I'm all for proprietary design of all core and/or often used components.

Thank you for reading ! Looking forward for any further discussion on the subject, it is fascinating.

Edited 2010-03-17 18:26 UTC

Reply Parent Score: 1

Laurence Member since:
2007-03-26

About DirectX... Did you actually encountered applications which code their interface directly using DX, apart from games ? Games have traditionally non-standard interfaces, on every platform, and customers are used to it, so it's not such a big issue.


Sorry, I should have stated that my comments about directX was about audio.

While I appreciate Win7 has a more unified sound architecture, XP had several different sound toolkits available.

Though this is usually irrelevant to the average user, it becomes very obvious when using audio sequencers and trackers (eg FL Studio, Ableton, etc).

Of course, but not [much duplication] at a core level. To say it in a different way, they don't depend on each other in an intricated way. You don't need VLC to mix audio with REAPER, and you don't need GIMP in order to use firefox. Duplication very rarely occurs in the API area on Windows, which is a blessing compared to the multimedia madness on linux.


As I said above, multimedia is (or was) Window's worst area for internal duplication.

The difference is Windows is better at packaging the duplication (either with including the shared APIs with the application installer or -in the case of Microsoft's own APIs- Windows having all of the expected dependencies in the default install).

To use your examples:
VLC doesn't use Windows' codecs, it uses it's own (same goes for Winamp too)
Firefox doesn't Windows' rendering engine (Trident), it uses Gecko (and you have added duplication if you install other web browsers).

Variety is a double-edged blade. On user apps it serves you. On core APIs, it makes life of OS builders, users, and maintainers close to hell.

Very true.

Right. But do you know a way to reach that coherent compatibility without a shared underlying proprietary design ? I don't know that myself, that's why I'm all for proprietary design of all core and/or often used components.

Easily if wrappers are built.
For example, using a GTK+ wrapper for QT4 so KDE4 applications look like native GTK+ apps in GNOME.

Granted building wrappers is easier said than done. But if developers can't agree on a single toolkit, then the toolkits should become inter-compatible so the underlying technologies become completely transparent to the user experience.

Thank you for reading ! Looking forward for any further discussion on the subject, it is fascinating.

Likewise. It's refreshing to have a discussion about the merits or open source vs propitiatory that doesn't descend into a flamewar hehehe
While I'm not agreeing with all of your points, there is a lot of sense being said

Edited 2010-03-18 01:21 UTC

Reply Parent Score: 2

Neolander Member since:
2010-03-08

Sorry, I should have stated that my comments about directX was about audio.

While I appreciate Win7 has a more unified sound architecture, XP had several different sound toolkits available.

Though this is usually irrelevant to the average user, it becomes very obvious when using audio sequencers and trackers (eg FL Studio, Ableton, etc).

You make a point here. I've not been using windows for a while, and had forgotten, but now that I remember, it really was a mess. If I remember correctly, there was...
-The system audio API (PCM playback)
-DirectSound (More advanced multimedia features)
-ASIO/WDM (Low-latency)

If it was me that would have to design that, I'd have asked Microsoft to merge ASIO-related work into the system API, and made DirectSound work on top of it, but well... The problem with the microsoft way of things is that there's only little room for third-party ideas.

But apart when using audio apps, I didn't have to care about that mess in the end because everything worked (except ASIO which needed some tweaks) and was mixed together in the end. That's when you're right : it's maybe not needed to go into "one api" strategy if they've got a common compatibility base in the end.

As I said above, multimedia is (or was) Window's worst area for internal duplication.

The difference is Windows is better at packaging the duplication (either with including the shared APIs with the application installer or -in the case of Microsoft's own APIs- Windows having all of the expected dependencies in the default install).

To use your examples:
VLC doesn't use Windows' codecs, it uses it's own (same goes for Winamp too)
Firefox doesn't Windows' rendering engine (Trident), it uses Gecko (and you have added duplication if you install other web browsers).

I agree that it's a bit ankward that VLC doesn't use DirectShow (or the vista/7 trick) for video decoding. I'm glad it works, but I'd have preferred to see DirectShow improved by VLC devs in order to fit their needs, but in a fully proprietary environment that's not likely to happen, so let's say that at least they managed to make everything work together.

About web engines, I think duplication is acceptable for the following reasons :
-They are quickly evolving technology and hence are not ready for full standardization yet.
-They are not shared by many applications, so inconsistencies between them will not cause much damage as non-geek people generally only use one browser at a time.
-They are not at the core of the system (except on windows). On clean OSs, it's unlikely that system builders would need changes in the web engine, so that can be made by third parties.
-IE is a technically unsatisfactory browser with poor innovation capabilities and that's not open to third-party patches in order to address its lacks. Hence duplication, although generally a bad solution, is needed there.

Easily if wrappers are built.
For example, using a GTK+ wrapper for QT4 so KDE4 applications look like native GTK+ apps in GNOME.

Yes, but can they solve ALL ergonomic inconsistencies ?

As an example, "save" dialogs are very different depending on if you use GTK or KDE/QT dialogs. I can make most GTK and QT widgets look the same thanks to some QTcurve blessing, but how do I get around that kind of problems, that depend on the way those widgets are put together ?

Granted building wrappers is easier said than done. But if developers can't agree on a single toolkit, then the toolkits should become inter-compatible so the underlying technologies become completely transparent to the user experience.

Fine, but how do you achieve that result without some common management on top ? The toolkit mess in linux went somewhat better (more efficient drag and drop, DBUS...) lately due to Freedesktop's standardization work, but technically, it means that devs from GTK+, QT, and desktop environments had to accept that some parts of their design must be made in a specific way for compatibility purposes.

If that part of the design is done in a proprietary way but with openness to third-party ideas, don't the benefits (ability to introduce global consistency in system APIs instead of introducing only consistency at a local scale) overcome the drawbacks (need to take some time to discuss with system manufacturers when they don't accept your changes right away, explain them your point and learn more about their) ?

Edited 2010-03-18 07:02 UTC

Reply Parent Score: 1