Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

How Would You Fix the Linux Desktop?

itwbennett (1594911) writes | about 2 years ago

Programming 2

itwbennett writes "Slashdot readers are familiar with the Torvalds/de Icaza slugfest over 'the lack of development in Linux desktop initiatives.' The problem with the Linux desktop boils down to this: We need more apps, and that means making it easier for developers to build them, says Brian Proffitt. 'It's easy to point at solutions like the Linux Standard Base, but that dog won't hunt, possibly because it's not in the commercial vendors' interests to create true cross-distro compatibility. United Linux or a similar consortium probably won't work, for the same reasons,' says Proffitt. So, we put it to the Slashdot community: How would you fix the Linux desktop?"
Link to Original Source

cancel ×


Sorry! There are no comments related to the filter you selected.

COM and Backwards-compatible Interoperable APIs (1)

lkcl (517947) | about 2 years ago | (#41260311)

It's very simple. Microsoft succeeded (at a technical level) because of the binary-level backwards-compatible APIs that are built on top of COM; Apple succeeded because of the binary-level backwards-compatible APIs that are built on top of a fundamental feature of Objective-C.

Does there exist, anywhere in the GNU/Linux world, a similar system to COM and to Objective-C? yes... sort-of: Olivetti Labs released CORBA under the GPL in 1997, but only GNOME took it up. KDE developed DCOP in a famous "20 minute hack".

Does there exist, anywhere in the GNU/Linux world, a similar system to COM and Objective-C that is then used to set up APIs that are maintained even if Hell Freezes Over? the answer to this is a resounding NO, and that's the crux of the problem.

Can I write a widget for KDE that plugs into and properly integrates into GNOME or LXDE? no. Can i run a widget from 15 years ago (in its original binary form) on a desktop today? no.

Linus Torvalds HATES binary-level interoperability, and Miguel's beef with that isn't anything to do with Linus himself, it's that everyone *follows* Linus. What Linus says is "bad", nobody else follows, whether it's appropriate or inappropriate. we KNOW that Linux != GNU/Linux but that really hasn't sunk in to many peoples' brains.

So this is the problem. The power of COM and the *necessity* of creating backwards-compatible APIs on top of well-established interfaces is completely and utterly ignored by the Free Software Community.

Miguel's take on this (I've spoken to him about it) isn't so much that this is a technical issue as it is a "communications and persistence and committment" issue. a) there's not enough communication to b) drive a standard forward with c) any level of committment over the long-term.

So he started to reach out, to express, communicate and solve this problem, and got shat on by Linus Torvalds for his efforts. hmmm.... something wrong, there, I feel.

But my take on this goes a little bit further than what Miguel raises. I absolutely agree with Miguel that there is a communications, persistence and committment problem, right across the entire Free Software Community, but I also feel that the technology available to us simply isn't up to the task.

There was something of a mini-bun-fight on slashdot last week, where several people did not understand that "just adding in d-bus" does *not* make a solution. nor does using unix domain sockets, or using the unix rule of "files" and "pipes". It really, really is about the APIs, and about making it easy to *maintain* those legacy APIs, for good or for worse, for pretty much forever.

if you don't *have* a good technical solution that allows you to extend an interface with newer APIs, then is it any wonder that Free Software Developers fall back to the age-old "oh you can just go download the latest-and-greatest source code". yeah. and that's working out really well for Ubuntu with their forced 6-month release cycle.

the conversation starts here: []

so: my recommendations would be as follows:

a) set up (or find) and fund an institute or organisation responsible for advocating, communicating, establishing and then paying for implementations of COM interfaces to be built-in to every single desktop system (KDE, Gnome, LXDE, XFCE, EWM), with *or without* their cooperation, even if that means creating "shims" or wrappers or even full forks of the projects (if Trinity Desktop has a place in this world, then so does KDE/COM, GNOME/COM, LXDE/COM, EWM/COM and XFCE/COM).

b) take Wine's implementation of DCOM, take FreeDCE, and stabilise the codebase as an independent project, fully-documented and properly explained - with examples - how to create COM applications for Linux.

c) take ActiveState's "python-comtypes" code for Win32 and, using the Mozilla Foundation's python-xpcom code, create a Linux port of python-com.

d) begin to create COM language bindings for all other major programming languages (by tracking down their win32 equivalents if they exist and porting them to linux).

e) beat the Mozilla Foundation about the head until they scream for mercy and can't take it any more, and cave in to convert "XPCOM" into a true implementation of "COM". they didn't add co-classes when they were "inspired" by COM to create XPCOM, and the lack of binary interoperability has caused severe problems for 3rd party java and c++ developers for over 10 years.

just from this description alone, it can be seen that this is a massively ambitious set of goals - not just to do but also to maintain. however: once you truly understand what COM is about, it becomes clear that the pain barrier isn't as heavy as it seems. it's only because there isn't *any* backwards-compatible binary-level interoperability *at all* in the GNU/Linux world that it appears to be an almost impossible task, because nobody in the GNU/Linux world has any experience in solving this problem, let alone maintaining such interoperability.

not even Linus Torvalds! he *DESPISES* Micro-kernels, which are an essential prerequisite to having binary-level kernel interoperability. not that that's relevant per se, but it's important to point out that the problem of binary-level kernel interoperability *can* be solved, but it is a task that really does *not* have anything to do with GNU/Linux Desktop systems. as such, it would be really great if people could stop listening to Linus Torvalds saying that "binary interoperability is bad" when it comes to solving *DESKTOP* binary interoperability and backwards compatibility.

Re:COM and Backwards-compatible Interoperable APIs (1)

Finerva (1822374) | about 2 years ago | (#41263793)

"Does there exist, anywhere in the GNU/Linux world, a similar system to COM and Objective-C that is then used to set up APIs that are maintained even if Hell Freezes Over? the answer to this is a resounding NO, and that's the crux of the problem.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>