Slashdot Mirror

For the record, since Gnome 2.10 uses the freedesktop.org Desktop Menu Specification, you can use any menu editor. It is true that gnome-menu-editor hasn't shipped with Gnome before 2.12, but nothing has stopped you from using Smeg or even kmenuedit!

New clipboard management, based on the Freedesktop.org specification

...which is probably referring to the freedesktop.org Clipboard Manager spec.

The bloody X clipboard is separate from GNOME's clipboard

Really? How is GNOME's clipboard implemented? Does it really have nothing to do with the ICCCM's CLIPBOARD selection?

If they've got rid of it

Given the freedesktop.org Clipboard Manager spec's references to the ICCCM, I suspect they have not gotten rid of the X clipboard in the sense of the CLIPBOARD selection.

If I can't just highlight into the PRIMARY selection and then middle-click-paste into an xterm (or my other "real" X11 applications) anymore, then Gnome is useless to me.

If selecting text doesn't set the PRIMARY selection in a GNOME application, then GNOME doesn't follow the freedesktop.org clipboard explanation.

If the middle mouse button in xterm doesn't paste the PRIMARY selection, either your xterm is broken or somebody's configured it not to do so.

I find it to be very consistent. The default X11 behavior is not necessarily intuitive to windows/mac users.

I'm not sure what the "default" X11 copy/paste behavior is, but I suspect the most common one is Ctrl+C copies, Ctrl+V pastes.

(Note: that button in the middle of your mouse - or, if you have a two-button mouse and have configured it in the typical fashion, clicking both at once - implements "paste current selection", not "copy/paste". They're two different things.

Both can be useful, although on OSes with desktop environments that don't use Ctrl as the command modifier, one of the main uses of a purely mouse-based paste-current-selection, i.e. pasting in a terminal window where Ctrl+C is typically the "interrupt program" key and Ctrl+V is typically the "quote the next character" key, isn't quite as necessary as it is on other desktop environments.)

A lot of the problem with consistent copy/paste on X11-based desktop environments is a result of toolkits or applications not following the X clipboard explanation; it has nothing to do with...

But there are a wealth of desktop environments which supply a clipboard manager (and a wealth of other clipboard managers you can use instead).

...the absence of a clipboard manager.

Guess you've never heard of Cairo (as another reply pointed out), or maybe Xgl /Xegl?

Or even seen the videos of what luminocity can do? It can do that NOW. How about Project Looking Glass?

Just becuase you don't know about them yet doesn't mean they don't exist.

Guess you've never heard of Cairo (as another reply pointed out), or maybe Xgl /Xegl?

Or even seen the videos of what luminocity can do? It can do that NOW. How about Project Looking Glass?

Just becuase you don't know about them yet doesn't mean they don't exist.

I wonder if they'll start taking advantage of Cairo and Glitz. Doing so would let graphics cards accelerate GUI drawing via OpenGL, a la Quartz on OS X. Hardware accelerated GUIs are a hallmark of modern operating systems (OS X, Windows Vista), it'd be nice if Linux could join the party too.

You should read up on D-BUS.

It's pretty early but it's already in quite heavy use.

This upcoming release of the Quake 3 source code coincides nicely with the latest r300 project update (http://r300.sf.net/): the open-source ATI R300 drivers (for Radeon 9500, 9600, 9700 and 9800 cards) have been moved into the Mesa CVS at http://freedesktop.org/.

See http://dri.freedesktop.org/wiki/ATIRadeon for more info about Radeon cards and chipsets.

This upcoming release of the Quake 3 source code coincides nicely with the latest r300 project update (http://r300.sf.net/): the open-source ATI R300 drivers (for Radeon 9500, 9600, 9700 and 9800 cards) have been moved into the Mesa CVS at http://freedesktop.org/.

See http://dri.freedesktop.org/wiki/ATIRadeon for more info about Radeon cards and chipsets.

It would also help if we worked harder on well-defined and standardized APIs, so that it would be easier to get things working with each other. For example, a standardized hardware configuration API would help make "control center" type apps a lot easier to make, etc.

This is where HAL comes in. (Cue the 2001 jokes.) It's pretty new, so it's mostly being used for things like auto-mounting devices in KDE and GNOME currently; but tools like GNOME Power Manager are starting to be built on top of it.

Right now it's Linux-only, but AFAIK there's nothing that inherently prevents it from being ported to one of the BSDs.

How about the URL and MIME integration of GNOME-VFS? It's supposed to let apps hand off data, as per the FreeDesktop.org specs, with exactly the same API calls as in KDE (and other systems subscribing to the FDo spec). It kinda worked before, but didn't really interoperate with the KDE implementation. Is that working in GNOME v2.12? How about the KDE work to comply?

This interop really would go a long way towards a useable Linux desktop for everyone. Right now, users must choose which of GNOME or KDE they use. Or install both, and either switch, or put up with mismatched widgets. But developers must pick which environment to code into their apps. The FDo specs offer any app the critical ability to toss data to another app, across a "three-tier architecture" boundary. The protocol lookup lets an app that gets a pointer to an object (URL) call another app to retrieve the data, without knowing which app - it just asks the OS to look it up. The app can then do the same for processing or presentation of the object, according to the MIME type of the data (or decoded from the URL, at the app's choice). This extremely powerful IPC lets any apps integrate, even using custom protocols and x-<whatever> MIME types for custom integration.

But if it only works on GNOME or KDE, stuck inside its ghetto, it's not going to get used by developers. It's not going to be expected by users. It'll remain a half-assed solution to problems internal to a given desktop choice. When instead it could make Linux apps integrate easily, across all kinds of divides, like an automated backdend clipboard. Instead of a fragmented desktop market with limited integration, we'd have a unified market, with choices available for ways of doing things, and seamless app integration. Without excluding any apps - rather, including every app that calls the unified API.

This tour mentions GNOME-VFS only in its HAL/GUI feature. What's the status of the real guts? And is KDE working yet?

As far as I can tell from the wiki the new clipboard manager won't affect middle button pasting (which uses the "primary" selection rather than the "clipboard" selection). Perhaps you could change the mapping of your middle mouse button from 2 to 6?

You are looking for info about the freedesktop.org shared mime specification.

That's right. The enabling technology of HAL is D-BUS which is intended to be interoperable with the major window managers.

Of late, my personal (ie: non-work) hacking has been mainly D-BUS and GnomeVFS so I know a fair bit about the technology itself. Personally, I reckon KDE have their thumbs up their asses if they want to stick with DCOP for their desktop IPC interoperability/integration layer. But, I also think that they're waiting for D-BUS to hit stable then adopt it in time for KDE 4.0. Let someone else can do the hard work.

Enough politics. If you like this kind of stuff, check out D-BUS. People will love the Glib, Python, Qt, Mono and Ruby bindings. For a young project, it has already gathered quite a few early adopters. Among other things, Beagle, HAL, Zero Install, Galago are already on D-BUS. Have you got your ticket?

(Damn that was a classy fade-out!)

Er. You don't have to "choose", for the most part. GNOME applications typically run just fine on a mostly-KDE desktop and vice-versa.

It's mainly the fanboys who don't STFU. Under the auspices of the http://freedesktop.org/ organisation, KDE and GNOME (and other minority desktop!) developers regularly work together, standardising interaction protocols and whatnot. KDE and GNOME have different design philosophies, and I happen to prefer KDE (though I wish it wasn't written in Qt-extended-C++). I don't WANT to see one or the other go away, though, because friendly competition drives innovation in the linux desktop.

I have 3-5 of them as a students. I'll see if they're interested. I have the skillset you're looking for, but I'm not willing to move to Boston and I doubt you'd want to pay what I'm worth.

There's nothing braindead about m4. I've used it as a metalanguage tool to design 3 or 4 highly successful little application-specific languages. See, for example, the first version of what eventually became XML-XCB.

What's braindead is csh---I wouldn't use it as a scripting language on my most desperate day. Horrible syntax and semantics, a variety of error-prone features, and a really buggy reference implementation (last I checked).

While I'm not aware of any open source 3D accelerated drivers for NVidia cards, there are the DRI drivers for Radeon cards 9200/9250 and under which are very good. I'm using them on my Radeon Mobility 7500 card and after enabling S3TC, speeds are very impressive, probably about equal to that of the Windows drivers. S3TC isn't enabled by default because of potential IP issues, but even without it, the drivers are still quite fast.

There currently is an active project to get the DRI drivers working on the R300 series of Radeons (ie, the rest of them), but I'm not aware of anyone who has tried them, and I don't have the hardware necessary to try them myself. The page itself strongly suggests that these drivers are not finished or stable at the moment however, so try at your own risk.

At least this will give Keith more time to work on our rocket. I hope he and Jim both quickly find day jobs to support their outstanding work on the X Window System.

The timing is pretty awful for this research group; many of them were presenting their work at the this conference. "Welcome back! Here is the box of stuff from your office."

"no one has a real true standard to enforce anywhere."

"A standard way of doing things are key to appeal to a large audience."

Freedesktop standards
Gnome HIG
KDE Guidelines
If I use either KDE or Gnome, I very rarely use applications that don't match the environment. My desktop of choice is Gnome, and I've found it much more consistent than the windows GUI.

Windows User Experience

Office (XP anyway) is really inconsistent. I normally use Microsoft Word, in which every new document opens in a seperate window. However in Excel, the new documents actually open in a new window inside the main excel window, but they create another application button on the taskbar, giving the illusion that it's opened in a seperate window.

Sometimes I've had 1 document open that I've not edited, and 1 that I have edited. I'm used to Office bugging me to save documents even when I've not edited them, so when I hit the big "X" button on the window, and it asks to save, I just click "no" because being a human, I don't read messages that I expect to say something, stupid I know. I lose my work.
I'm not the only person this has happened to either...

I know I'll probably get modded troll or something...

Um, then what about this?

It's allready in X.Org CVS, new EXA accelleration. Working in driver sis(4) and soon to be in radeon(4). Let's just hope EXA for radeon(4) gets into X.Org 6.9/7.0. It's mentioned here: http://xorg.freedesktop.org/wiki/ChangesSince68

Unsurprisingly there's already a lot of "bah, this guy wants Linux dumbed down for n00bs" comments on this thread. Which totally misses the point:

Linux-on-the-desktop isn't just too complicated for n00bs -- it's too complicated for reasonably sharp users, too. And that's the problem.

I offer myself as an example. I am not the God of All Things Computing. But I've been tinkering with PCs since MS-DOS 3 days, I've used Windows, Macs, Linux and even CP/M for pete's sake. Today my primary desktop at home runs Ubuntu Linux. I'm comfortable compiling software from source tarballs and rooting through Google for HOWTOs and FAQs.

In short, I know my way around a computer -- and yet Ubuntu still manages to throw me for a loop more frequently than I'd like.

Example. The other day I installed the new Deer Park preview of Firefox. For some reason, its installer (bonus points to it for even having a graphical installer, btw) didn't add a shortcut for launching it to my GNOME panel. So I wanted to add one myself.

Easy? Right? Bzzt.

On Windows, here's the steps for adding a new item to the Start menu:

1. Click Start menu button
2. Navigate to folder where you'd like to add shortcut
3. Right-click folder name
4. Select "New Shortcut"
5. Wizard launches that walks you through finding the program you want the shortcut to point to, and giving the shortcut a name.

I figured there must be a way to manipulate the GNOME panel in a similar fashion. Nope. There is no direct way in Ubuntu Hoary to add a panel item to the menus through the GUI. Instead you have to open a shell, find /usr/share/applications, and create a .desktop file in there for your application.

But! You don't have permission to do that by default, so you have to use sudo to create the file. ("You do know how to use sudo, right Mom?")

And then -- once you figure out that you need to create a .desktop file, and where this file needs to go, and what format this file needs to be in, and you actually go and create it -- nothing happens! That's right, you don't see the item in your panel until the next time you log in, unless you manually restart the X server with CTRL-ALT-BACKSPACE.

(Yes, you have to restart the window manager, or else it will appear that all your work was for naught. "Just restart the X server, Mom. Mom? Hello? Noob.")

The icing on the cake is that to find this answer, you have to go through three levels of redirection:

• Ubuntu tells you to refer to GNOME, since it's their desktop, Ubuntu's just distributing it
• GNOME tells you to refer to FreeDesktop.org, since it's their standard for panel items, GNOME is just packaging it
• FreeDesktop.org hides the instructions on how to write a .desktop file deep in a standards document.

("You do read standards documents, right Mom?")

I went through all that and finally got my shortcut added to the panel. But how many average users are gonna put up with that? (And Ubuntu does better at this stuff than most others.)

With all the spit and polish issues that Linux has, Asa is not the only Mozillian to find fault with it; former Moz UI gadfly Matthew Thomas (aka mpt), who's now with Ubuntu sponsor Canonical, recently posted a list of 69 usability flaws in Ubuntu Hoary, and old skooler Jamie Zawinski gave up Linux for OS X for good.

My case was not a case of "user who could not snap out of Windows-ism". I'm more than willing to embrace a better approach when I see it. But this is not a better approach fo

Not quite. There are actually two clipboards (I think "selections" is the correct term). The one accessed by selecting an object (the "primary selection") is independent of the one that is accessed by choosing Cut/Copy from a menu (the "clipboard selection").

Once one internalises this information, it becomes clear that many clipboard related problems that people have with X11 are caused by poorly written apps that fail to follow the conventions on the use of the Primary and Clipboard selections.

http://freedesktop.org/wiki/Standards_2fclipboards _2dspec has a more detailed explanation.

Windows doesn't do per-pixel alpha blending. Go read longhorn papers, there is a reason they're doing this in longhorn
With respect to x-composite, this is in xorg's current CVS, and XGL is on his way

With respect to E17, it can do alpha blending by software or opengl. Currently they're doing it by software because it's faster than most OSS opengl drivers.

For me, it's Longhorn's vector-based approach to the UI. While everybody's busy giggling and snorting at the 'eye-candy' at Longhorn, the reality is you'll be able to use it on monitors with > 3,000 pixels in width without having to use a microscope to read the text. You'll be able to resize windows etc to suit your needs. I also really enjoy the idea of using the system's GPU to offload the graphical stuff.... ...Certainly Linux is going to have its own implementation of this feature set.

Vector based graphics, offloading work to the GPU? Linux has its own implementation of this featureset now. It is called Cairo, and it works right now. GTK+ is going to be using it very soon, and SWT already makes use of it for their "advanced graphics" system. If you want Cairo rendering of GTK+ right now, use the cairo-gtk theme engine and associated themes.

Is Cairo fully integrated in yet? No, development is still in the works to port things over to Cairo (but work on both Mozilla and OpenOffice is already underway as well). In a sense then while the backend has been hammered out (Cairo) the full end to end functionality is till in the works. Then again Longhorn is still a ways from release as well.

This does mark an interesting point though: Linux is not playing catchup with Windows on this one, they are running pretty much in parallel. Similarly Beagle is in parallel or ahead of WinFS. I know all the Mac people will complain that their both playing catchup with OS X, but let's take this one hurdle at a time. In terms of new features Linux is playing head to head with Windows these days, and considering how far behind they were when they started (or how far behind they were even a year or two ago) I would take that to mean that Linux will be running ahead of Windows and only a little behind OS X in another few years.

Jedidiah.

You might also want to look at XCB, an asynchronous replacement for Xlib.

There's a lot of good work going on!

I did file a bug.

Nothing much has happened. STATUS is still "NEW" and there has been no activity or comments by others.

https://bugs.freedesktop.org/show_bug.cgi?id=3473

Original bug:

http://bugs.gentoo.org/show_bug.cgi?id=93866

Since filing a bug didn't help, and isn't even generating any activity, yet Xorg has tons of free time as evidenced by these eye candy plans, now I'm bitching.

I am not doing something against Xorg, I am providing constructive criticism. If they fix these show stopper bugs, X looks good - if they don't - X looks bad and people will stick with or switch to Windows.

I'm more in favor of the Xgl method of modern linux desktop rendering. Currently a lot of work is being done on Xegl. Which is an extension of Xgl with the EGL API. There was a lengthy discussion over Xegl vs KAA on the freedesktop mailing-list. My impression is KAA is good for all basic hardware while Xgl/Xegl takes advantage of modern hardware.

if they are going to be modded -1,flamebait by uninformed moderators. In my previous post i wrote that Exa is a temporary solution before Xgl (as it is http://lists.freedesktop.org/pipermail/xorg/2005-J une/008356.html), please think before modding.

How can i do an informative post if uninformed moderators are going to mod me -1,flamebait? Please check Xorg ml, and think before modding: http://lists.freedesktop.org/pipermail/xorg/2005-J une/008356.html

If you bothered to read the links, you'd know that 6.9 (the (last?) monolithic release) and 7.0 (the modular release) will occur at the same time.

The problem with KDE is, even if its usability is fine, it's all thrown out the window as soon as you open non-KDE apps, because in their infinite wisdom, open source programmers decided to divide programs up into groups, each group having completely different interfaces and settings.

Yes, this is completely unique to open source. OS X would never craft a commpletely unique interface for, say, Quicktime. Or The Calculator. It's all about the HIG for them, right?

The larger point here is that opne source developers are not a single entity, so *of course* they don't necessarily coordinate UI decisions. However, this is starting to change.
And commercial desktops like OS X and Windows don't have this excuse.

Even simple dialog boxes seem to be over 1200 pixels wide.

I hate to call you a liar, can you tell us what this "simpe" dialog is?

I don't know about vice versa, but GTK apps can be made to blend in quite well with KDE without resorting to having "sort of the same theme for both": GTK-Qt Theme Engine http://www.freedesktop.org/Software/gtk-qt

I say start from scratch, and engineer a system for today's hardware. Also, don't try to provide backwards compatibility for X. Just start fresh. Application developers will follow.

Just as logically sound, while more practical, is the focus on standards organizations:

http://www.linuxbase.org/
http://freedesktop.org/wiki/

They promote compatibilty between distributions.

Other than that, we need a superset of existing packaging systems, let's call it ".app", which will allow a binary (or source) package to be installed on all popular Linux distributions. It would contain enough metadata and be compatible and supported by all package managers.

Then the only differences between distributions would only be default settings, artwork, support and distribution-specific packages.

Now you could acurately call the differences between linux distros "flavors" rather than now where I'd call them "forks" or "reinventions"

*No intended correlation to Mac OS X .app

Anyway, I think that answers your question in more detail than you needed.

No, that's the level of detail I like.

So, in effect, even on Windows, the user "tells" the system what type of card they have, by installing the driver from the CD-ROM that came with the card. Easier than having to add the tuner module as a parameter (although if, for example, a system using HAL can be configured to fire up a particular program if it detects hardware that it hasn't yet seen, that program might, for TV tuner cards, be able to determine whether the card type can be automatically determined or not, and, if not, offer the user a choice of card types, which might arguably be as easy, if not easier), although it doesn't work if you change the TV tuner card out from under it.

Look up the following:

• Freedesktop.org
• Desktop Linux Consortium

Hi Tom,
It's been a long time -- good to see you're still around.

I'm not sure which ATI chip set you have, but my laptop has a Mobility Radeon 7000, which definitely does have alpha-blending hardware. Elsethread you mentioned this as a possible driver problem, which may well be right. If you haven't already, it might be worth looking at http://dri.freedesktop.org/wiki/ for one possible source of drivers that might give you better hardware support. I don't have any really ancient hardware handy to test with, but as I said, I definitely get hardware alpha blending at least as far back as the Radeon 7000, which certainly isn't what you'd call particularly new. I haven't had any S3 hardware to test with for quite a while, but the DRI site at least claims to support some of it, and even some really old stuff (for the Virge) that's incomplete supports Alpha blending in hardware anyway.

--
The universe is a figment of its own imagination.

Dvorak point brings up the Linux desktop issue... I use the Linux OS everyday, and for all kinds of tasks: servers, desktop, routers, embedded. Our company uses Linux embedded OS for our main products.
However, for Linux to truly succeed it must succeed on the desktop. Linux fans: let's be honest, gnome and KDE are neither cool, innovative or good in comparison to Windows or Mac OS - regardless of what style of windowing system you like.
To fix the issue Linux developers must move quickly. First, X sucks - it lacks the underpinnings that allow OS X to do thing like expose, and other nice 3D effects. The answer to this problem is to move to a pure openGL based render system (which is what OS X does) - such as Xgl being worked on by David Reveman - http://lists.freedesktop.org/pipermail/xorg/2004-N ovember/004358.html who is now working for Novell.

Secondly, as a community we must *decide* on a GUI api - not have the 50+ ones which are available now. Perhaps this is gtk 2.0, maybe something else. But professional developers, and software companies which have to support products dont like making software which looks crappy b/c every developer is using a different system for drawing buttons and handling user activity.

Everything else is beside the point: window managers, kde, gnome desktop environments, etc.

But, without the two above problems solved, there is no way for Linux on the desktop to be significant.

The idea that one should achieve standardization through a single codebase is the way Windows and Macintosh work; it's a stupid idea.

X11 defines standards for how toolkits should behave, and then different toolkits should adhere to those standards.

Gtk+ is a C-based toolkit and Qt is a C++-based toolkit; you can bind them to other languages, but you pay a hefty price compared to toolkits written in those languages.

GUIs aren't going to get anywhere if we are shackled by the limitations of C/C++.

No, the right thing to do would be to fix X11 (and xlib) and GTK+(GDK)/Qt. We need more people working TOGETHER rather than apart.

No, the right thing to do would be to fix X11 (and xlib) and GTK+(GDK)/Qt. We need more people working TOGETHER rather than apart.

Fontconfig recognized the sheldon4.fon file, but when I tried to use the font, it just showed blank space -- no letters, not even substitutions from another font. I tried to convert it using FontForge and produced a variety of non-working versions. Eventually I found the key is to change the encoding in the Font Info dialog to Unicode, with that I created this working version. (This is the first time I've used FontForge, so I might have been doing stupid things.)

I guess this mess shows people just don't care for bitmap fonts anymore :) BDF/PCF is pretty much deprecated and it's not really a surprise Windows-specific formats like .FON are poorly supported. (Bitmap-only TrueType fonts should still work fine, however.)

As for diagnostics, the only thing I know about is fc-list, which is fontconfig's version of xlsfonts. You could try asking the fontconfig mailing list, it seems to be the most likely place to reach people who know more.

This may be of some use:

http://xorg.freedesktop.org/X11R6.8.2/doc/fonts.ht ml

These may help with your next question ;-)

http://www.cl.cam.ac.uk/~mgk25/unicode.html

http://www.gentoo.org/doc/en/utf-8.xml

> Apple quite simply forked Safari.

No, they forked kHTML. Safari is an Apple-made product, without any OSS code whatsoever.

> This happens all the time in the OSS world.

And, most of the time, hostile forks are frowned upon.

> Hello, does anyone really expect that X.org patches will remain 100% compatible with the XFree86 code structure ad aeternam ?

No, but everyone expects X.Org to

• Have their source control system public
• Have their bug tracker public
• Have their mailing lists public
• Make their patches in useful, small self-contained patches with clear descriptions ("frobs the master foobox" instead of "fixes bug #14567894 in our internal, private bug tracker")

Apple does nothing of this, they just release multimegabyte hunks of code that are just *useless* (you would probably spend more time trying to separate the big blob into small patches than to rewrite these independently). Your example thus falls completely flat.

> Could someone please tell me what exactly the problem is in the Apple-Safari case ?

Right where I told you. But don't let this detract you from praising Apple at every opportunity. I know that (on /. at least), praising Apple and Google whatever they do is Really Hip...

> Apple quite simply forked Safari.

No, they forked kHTML. Safari is an Apple-made product, without any OSS code whatsoever.

> This happens all the time in the OSS world.

And, most of the time, hostile forks are frowned upon.

> Hello, does anyone really expect that X.org patches will remain 100% compatible with the XFree86 code structure ad aeternam ?

No, but everyone expects X.Org to

• Have their source control system public
• Have their bug tracker public
• Have their mailing lists public
• Make their patches in useful, small self-contained patches with clear descriptions ("frobs the master foobox" instead of "fixes bug #14567894 in our internal, private bug tracker")

Apple does nothing of this, they just release multimegabyte hunks of code that are just *useless* (you would probably spend more time trying to separate the big blob into small patches than to rewrite these independently). Your example thus falls completely flat.

> Could someone please tell me what exactly the problem is in the Apple-Safari case ?

Right where I told you. But don't let this detract you from praising Apple at every opportunity. I know that (on /. at least), praising Apple and Google whatever they do is Really Hip...

> Apple quite simply forked Safari.

No, they forked kHTML. Safari is an Apple-made product, without any OSS code whatsoever.

> This happens all the time in the OSS world.

And, most of the time, hostile forks are frowned upon.

> Hello, does anyone really expect that X.org patches will remain 100% compatible with the XFree86 code structure ad aeternam ?

No, but everyone expects X.Org to

• Have their source control system public
• Have their bug tracker public
• Have their mailing lists public
• Make their patches in useful, small self-contained patches with clear descriptions ("frobs the master foobox" instead of "fixes bug #14567894 in our internal, private bug tracker")

Apple does nothing of this, they just release multimegabyte hunks of code that are just *useless* (you would probably spend more time trying to separate the big blob into small patches than to rewrite these independently). Your example thus falls completely flat.

> Could someone please tell me what exactly the problem is in the Apple-Safari case ?

Right where I told you. But don't let this detract you from praising Apple at every opportunity. I know that (on /. at least), praising Apple and Google whatever they do is Really Hip...

I found the thread, it's at http://lists.freedesktop.org/archives/xdg/2005-Mar ch/006224.html. I unsubscribed in disgust shortly afterwards. IMHO this is pretty damn serious, but nothing's been done about it, in favour of waiting for SELinux to be integrated into desktop distributions. Maybe that will be a sensible solution in about 15 years...

Apple already released their ZeroConf stack for POSIX-like systems under an open source license.

Except it's under Apple's APSL, which isn't DFSG free. KDE uses it anyway, but I assume Debian strips it out before packaging it. Avahi is a GPL'd implementation of zeroconf, and AFAIK Gnome is waiting for it to mature before integrating it. The web page has a progress update added today.