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 414000
To view parent comment, click here.
To read all comments associated with this story, please click here.
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