[clug] improving Linux on the desktop

Darren Freeman daz111 at rsphysse.anu.edu.au
Wed Jun 9 08:28:15 GMT 2004

On Wed, 2004-06-09 at 13:37, Edward C. Lang wrote:
> On Wed, Jun 09, 2004 at 12:01:24PM +1000, Sam Couter wrote:
> > Edward C. Lang <edlang at tsumakin.net> wrote:
> > > I'm feeling the same way about colour space management / workflow at the
> > > moment, for photo editing. Colour proofing in Linux/X with GIMP/dcraw
> > > proved to be too difficult, compared to things like Photoshop CS and
> > > Capture One Pro. I haven't seen much effort sunk into this area in OSS. 
> > 
> > 1) What do you expect for nothing?
> Um. Nothing? I don't think that's a very useful question to ask when
> attempting Linux advocacy.

It's particularly useful right after someone has vented a lot of hot air
on our list though. I find people who insult others over the code they
gave away to humanity to be wasting everybody's time. If it's not up to
scratch, either do something about it or be patient.
> > 2) Use the source, Edward. Or, provide some incentive for somebody else
> > to do so.
> It would be working on a lot of source, and would involve interfacing
> with a lot of people. At the moment I don't have the motivation or
> desire to do either of those thing. I'd much prefer to continue taking
> photographs.

I agree - not every user is supposed to be writing their own
applications. But providing lots of feedback to the authors isn't too
much to ask if you genuinely want to see something happen. They usually
don't scan user group mailing lists looking for explosive venting and
then say "wow now I know what I'm supposed to be doing in my free

> Isn't the satisfaction of enabling a large number of people to remain at
> the height of their productivity and creativity, using OSS instead of
> using proprietary software, incentive enough?

Not when reality dictates that the poor starve and have to pawn their

In the real world people only do something for others when they are
nice, polite, civil and respectful. See how many volunteer organisations
come to the aid of a drunken bum who hurls bottles at them.

>   3) Interactive manipulation and decoding of the various camera
>   companies' proprietary raw formats. Seriously, things like Capture One
>   Pro and the Adobe RAW plugin are beyond compare. I enjoyed using dcraw
>   for a while, but when I moved to shooting in the AdobeRGB colour space
>   and at specific temperatures (for white balance) I rapidly grew
>   annoyed by it. dcraw is also an example of reverse engineering, rather
>   than being written with the assistence / guidance of the camera 
>   companies' engineers.

Trust me, assistance from a company's engineers is a rare gift from
above. Even when you spent half a million bucks on the machine, they
won't help you to do anything that wasn't listed in the manual.
(speaking from recent experience)

And even the most mundane facts are strictly enforced as trade secrets,
lest the competitors or users find out which way the designers wiped
their arses during development.

Reverse engineering is a normal part of engineering for that reason. You
don't have to be a competitor to be kept in the dark. This is why it
pisses me off so horrendously that it will become a federal crime as
soon as the US-AU FTA gets into law.

>   4) UI design. For better or for worse, Microsoft, Apple, Adobe and
>   whomever else can enforce a consistent UI policy across their
>   products. And, many tasks can be completed in the one program, which I
>   found sped up my workflow, rather than slowing it down or limiting it.
>   I wish, I wish some entity could come along and take over the X team,
>   the GIMP team, the GNOME/KDE teams, etc to solve this issue, but
>   personally I think you'd have better success at herding cats.

I believe that freedesktop.org has taken on that role and already the
GNOME/KDE teams have taken up certain standards published by them. I
think there is a new copy/paste standard due to this work. Also XFree86
is being replaced (finally!).

>   5) Dealing with, and working around patents, both software and
>   otherwise. Colour management and control seems to be even more
>   proprietised than software. So, lawyers and a lot of money for
>   royalties may be necessary.

This doesn't work for free software. At least not for the GPL. Because
everybody must have the same rights to use the software, this rules out
paying royalties for patents unless you can get the code covered forever
and for everybody in some kind of one-off payment or agreement. This
would be pretty rare since it would allow competitors to insert said
GPLed code into their application that was otherwise being blocked by
patents, and magically they aren't blocked anymore.

Therefore software patents are evil. As is the US-AU FTA which inflicts
them upon us. People just don't get how bad the problem is, you just
can't pay the royalties and go on using the code.

>   6) Finding artists to work with, and software engineers that enjoy
>   working with artists. I've been on both sides of the fence and seen
>   how easily it is for one side to scoff at the other.

=) I don't think there's a shortage of either, but they have better
things to do with their time than work together on a free software
project. Maybe they all work for Adobe =)

>  It's not a topic that I pulled out of thin air, at a whim, in response
> to John's email. I'd be more than willing to work with you and others in
> this area, come July.

Maybe this would make a good topic for discussion at an open forum in

Actually get these mythical engineers and artists face to face,
exchanging email addresses and GPG keys, and make them come up with a
timeline to work together by the next LCA after that?

Actually I think there could be a range of topics like this that deserve
special attention from focus groups at the next LCA. I imagine that a
range of new freedesktop.org standards could start out like this.

> Regards,
> Edward.

Have fun,

More information about the linux mailing list