Slashdot Mirror

Strangely they've added a few. The new "Appearance" applet is quite nice.

But "fortunately" screensavers remain unconfigurable. After all, Billy Jon McCann (the sole developer and rule of the Guuh-Nome screensaver universe) says that screensavers that you can adjust settings on are "inherently broken".

GNOME screensavers. Crippled for your protection since 2005.


"Please, just tell people to use KDE"

-Linus Torvalds, December 2005.

Strangely they've added a few. The new "Appearance" applet is quite nice.

But "fortunately" screensavers remain unconfigurable. After all, Billy Jon McCann (the sole developer and rule of the Guuh-Nome screensaver universe) says that screensavers that you can adjust settings on are "inherently broken".

GNOME screensavers. Crippled for your protection since 2005.


"Please, just tell people to use KDE"

-Linus Torvalds, December 2005.

I'll never understand the OSS community's C++ phobia.

Besides the fact that C++ is "the PDP-11 assembler that thinks it's an object system"?

Gnome has always encouraged high-level bindings for just about everything they do. C, and in particular GObject, is really easy to make great bindings for. Gtk+ may be a bit verbose from C, but PyGTK is a dream for Python programmers.

To put this in Ballmer terms, Gnome is pretty darn good about "developers, developers, developers". They have orthogonal libraries (cairo, pango, gtk, gconf, etc.) that you can take or leave as you like. They're good for using from whatever language you like. They're LGPL, so companies writing proprietary apps (like Real) are willing to use them. The documentation isn't great, but it's pretty good. "Pretty good" on every axis, in my book, is quite rare.

In contrast, once you're in C++, you're kind of stuck in C++. I've had to develop large apps in PyGTK, and large apps in PyQt, and PyQt can be quite painful. Unlike PyGTK, I never felt like I was developing a Python application. It never lets you forget you're using a C++ library underneath. I really don't want to have to think about C++ memory management when I'm writing a Python app, and abstracting it away is apparently non-trivial.

I don't know what you mean by "500 different code generators" or "hardly recognizable as C". Looks like plain ol' C to me. If you want to see scary code, look at OOo sometime (which is in C++, coincidentally). Gnome is among the cleanest code I've seen, for a project of its size.

static bool CheckTrayIconShowing ()
{
// Check to make sure the tray icon is showing. If it's not,
// it's likely that the Notification Area isn't available. So
// instead, launch the Search All Notes window so the user can
// can still use Tomboy.
// NOTE: this infringes on Microsoft IP.

It's hackish, but it was already possible.

http://live.gnome.org/Epiphany/WebKit

If you're so afraid of some kind of "Microsoft infection" why don't you try reading the source?
http://download.gnome.org/sources/tomboy/0.8/tomboy-0.8.0.tar.gz

All I had to do was look at the Tomboy site and see that it is based on MS C# and their DotNyet stuff. Therefore, it is not safe to touch Gnome 2.20 due to Microsoft infection and MS MIB knocking on your door. Let Novell announce this is all free of Microsoft's IP before touching it. KDE is the better choice in this regard. IMO.

http://www.gnome.org/projects/tomboy/

LoB

Yep, and when the application can't adopt, its a problem of the app.

Gimp doesn't adopt, it simply does its own thing, which seems to be CSDI,

Gimp isn't a Gnome up to begin with, to this day it doesn't use a single gnome lib.

Yep, and when the application can't adopt, its a problem of the app.

Gimp doesn't adopt, it simply does its own thing, which seems to be CSDI,

Gimp isn't a Gnome up to begin with, to this day it doesn't use a single gnome lib.

Because its completly irrelevant, the problem is within the Gimp (or well, GTKs lack for MDI support), not the OS.

The GUI they use now would have been great on Mac Classic, where all an application's windows were on the same layer and there was only one application menu at the top of the screen. (In fact, this is what Photoshop looked like when it was originally developed for Macintosh.) The reason this worked is because when you switched from one application to another, ALL of the first application's windows moved behind ALL of the second application's windows... applications were in their own "layer."

This no longer applies. OS X doesn't do it. Windows doesn't (and never did) do it. Linux GUIs don't (and never did) do it. GIMP is using a 1984 GUI model in the modern era, and it's simply not working. (Personally, I liked Mac Classic's model, but I'm also pretty good at coping with reality when things change.)

Even worse, each of the GIMP windows have menus in them, leaving you in that mysterious position of not being to figure out exactly which ones are supposed to be palettes and which are supposed to contain the image. (Especially when you, as a new user, first open the program.) To make things even worse-worse, GIMP used to have two seperate File menus, one of which was actually used to open an image file, and the other one... totally different.

So my first suggestion is for GIMP to implement its palettes like virtually every modern application does. Paint.NET would be an excellent model on Windows... its palettes can exist happily in the main window, or outside it, but it's always clearly obvious which windows are palettes. (Don't use the Macromedia/Dreamweaver Flash example, which constantly pisses me off.)

Secondly, and this is a major change that will probably take a few revisions, but ditch your widget library. GTK, I believe. It requires a seperate application package on Windows, which gives the user a headache for virtually no benefit. It requires that the Mac OS X port run in X11, which is a usability nightmare on Macs. (And has irritating bugs on Mac that never seem to get addressed and/or fixed: http://bugzilla.gnome.org/show_bug.cgi?id=391461 has been a thorn in my side for a year now, and it's still "unconfirmed.")

But what GIMP really needs is lots, and lots of development. This means community-building, the way the Firefox team did before the release of 1.0. GIMP needs a totally new UI, it needs a ton more features if it desires to be competitive with Photoshop, and it needs the community with the size and activity to make this happen. Right now, GIMP development is glacial. (My first suggestion would be to change the name, so people could say in public "I work on GIMP" without being laughed at or feeling embarassed.)

Apple is hostile to Linux, because it is beginning to compete with OS X in a much more serious way than Windows.

It all started last year when with the release of iTunes 7, Apple purposely broke DAAP, ending the compatibility of their iTunes software with various media players. Now rhythmbox/amaroK/banshee users can't listen to iTunes shares, and no one has yet been able to break the hash that would allow it.

So it comes as no surprise that the iPod is being further locked down. The closer our desktops get in usability to OS X (and they are not close yet, but making progress), the more of this we'll see.

Disclaimer: I use an OS X desktop and a Linux laptop.

Apple is hostile to Linux, because it is beginning to compete with OS X in a much more serious way than Windows.

It all started last year when with the release of iTunes 7, Apple purposely broke DAAP, ending the compatibility of their iTunes software with various media players. Now rhythmbox/amaroK/banshee users can't listen to iTunes shares, and no one has yet been able to break the hash that would allow it.

So it comes as no surprise that the iPod is being further locked down. The closer our desktops get in usability to OS X (and they are not close yet, but making progress), the more of this we'll see.

Disclaimer: I use an OS X desktop and a Linux laptop.

Jody left Novell some time ago, and today coincidentally he blogged about his opinion on OOXML and ODF, his blog post is very interesting, as he is an independent developer working now only on gnumeric and not in OOo nor being paid by Microsoft (as I know that many of you consider my opinion completely invalid and tainted):

http://blogs.gnome.org/jody/2007/09/10/odf-vs-oox-asking-the-wrong-questions/

OH MY GOD THEY USE A BITFIELD THAT IS JUST SO-NOT-XML

I just do not have the energy or the time to compete with a guy whose full time job is to make sure OOXML is blocked.

People claimed that 6,000 pages for 4 office applications was to big, but it comes down to 1,500 pages per application. And someone mentioned that removing the examples and changing the font size to use the same font size that the ODF spec uses the spreadsheet (or word processor, I cant remember) spec goes down to 700 pages.

Jody left Novell some time ago, and today coincidentally he blogged about his opinion on OOXML and ODF, his blog post is very interesting, as he is an independent developer working now only on gnumeric and not in OOo nor being paid by Microsoft (as I know that many of you consider my opinion completely invalid and tainted):

http://blogs.gnome.org/jody/2007/09/10/odf-vs-oox-asking-the-wrong-questions/

Yes, very interesting. Jody says: "I did not comment on the quality of the formats. That will come up later."

What did Jody actually say? That OOXML was easier to support because Gnumeric already supported the XLS format. Which does nothing to address the relative merits of having a format like OOXML standardized under the terms with which Microsoft wishes to standardize it.

OH MY GOD THEY USE A BITFIELD THAT IS JUST SO-NOT-XML

Oh my God, they used a bitfield to encapsulate Microsoft-proprietary extensions like VBA rather than standardizing them as well. (Proper capitalization used to represent more somber tone of retort.)

I just do not have the energy or the time to compete with a guy whose full time job is to make sure OOXML is blocked.

That's right. It's Microsoft's job to pay off officials, exert political pressure, and abuse due process to ensure that OOXML is forced into consumer hands before ODF catches hold.

People claimed that 6,000 pages for 4 office applications was to big, but it comes down to 1,500 pages per application. And someone mentioned that removing the examples and changing the font size to use the same font size that the ODF spec uses the spreadsheet (or word processor, I cant remember) spec goes down to 700 pages.

A disingenuous argument at best. The ODF format supports those same four applications, plus a bit more. 1,500 per application is huge in comparison. Even if we assume that it's 700 per application, it's STILL huge when compared to 867 for ALL applications.

That being said, I don't mind long specifications if they are long for a good reason. Being long because ancient cruft is being supported for no real reason is not a "good" reason at all.

ODF is predicated on the ideals of KISS, interoperability, and long-term data storage and retrieval. OOXML is predicated on the concept of converting Microsoft formats to an XML description. While the latter may be a nice goal for Microsoft, it does not conform the the former ideals required for an international standardization effort.

I'm sorry Miguel. I've disagreed with you in the past, but I can't even begin to fathom your position in this matter.

He [Novell's Michael Meeks]
certainly would like clarification in various areas [of OOXML] and more details in
some. But Michael's criticism (or for that matter, the Novell OpenOffice
team working with that spec) seems to be incredibly different than the
laundry list of issues that pass as technical reviews in sites like Groklaw.

The difference is that the Novell-based criticism is based on actually
trying to implement the spec. Not reading the spec for the sake of finding
holes that can be used in a political battle.

Finally, Michael sounded incredibly positive after the ECMA meeting last
month when all of their technical questions were either answered or added to
the batch of things to review. ...

I find it hilarious that the majority (not all) of the criticism for OOXML
comes from people that do not have to write any code that interacts with
OOXML. Those that know do not seem to mind (except those whose personal
business is at risk because Microsoft moved away from a binary format to an
XML format, which I also find hilarious).

. . . here before starting a flamefest.

I'll paste it here to make sure those averse to clicking on links can read it too (anonymously even so you don't say I'm karma whoring):

Hello,

On 9/10/07, martin.schlan...@gmail.com wrote:

> On 6 Sep., 07:37, "Miguel de Icaza" wrote:
> > OOXML is a superb standard and yet, it has been
> > FUDed so badly by its competitors that serious people believe that
> > there is something fundamentally wrong with it. This is at a time when
> > OOXML as a spec is in much better shape than any other spec on that
> > space.

> Michael Meeks didn't seem to think so at FOSDEM 2007.

That is odd. Michael and I have discussed this topic extensively. He certainly would like clarification in various areas and more details in some. But Michael's criticism (or for that matter, the Novell OpenOffice team working with that spec) seems to be incredibly different than the laundry list of issues that pass as technical reviews in sites like Groklaw.

The difference is that the Novell-based criticism is based on actually trying to implement the spec. Not reading the spec for the sake of finding holes that can be used in a political battle.

Finally, Michael sounded incredibly positive after the ECMA meeting last month when all of their technical questions were either answered or added to the batch of things to review. I know you are going to say "The spec is not owned by ECMA", well, currently the working group that will review the ISO comments is at ECMA.

For another view at OOXML look at what Jody Goldberg (no longer a Novell employee) has to say about OOXML and ODF from the perspective of implementing both:

http://blogs.gnome.org/jody/2007/09/10/odf-vs-oox-asking-the-wrong-questions/

I find it hilarious that the majority (not all) of the criticism for OOXML comes from people that do not have to write any code that interacts with OOXML. Those that know do not seem to mind (except those whose personal business is at risk because Microsoft moved away from a binary format to an
XML format, which I also find hilarious).

> >Will I have to suffer
> > > the shadow of Microsoft patents over Silverlight when using or
> > > developing Moonlight?

> > Not as long as you get/download Moonlight from Novell which will include
> > patent
> > coverage.

> You're saying two things here that really shock me. Please tell me I
> misunderstood.

1) You're saying that people _will_ have patent problems - i.e.

> Moonlight "infringes" MS patents and doesn't work around them. Even
> though Novell promised never to ship code that infringes MS patents -
> but always avoid them one way or another.

First of all, am not aware of such Novell promise to "never ship code that infringes MS patents". You can not make such statement because for one, the patent system is broken. Novell statements are wildly different, they are of the form "we do not believe that we infringe" and am sure they say something along the lines of "we dont plan on infringing, and we plan on removing infringing code". But I am not aware of all the promises Novell has made, and I can not comment on other parts of the organization. If you want an official answer, my personal blog on politics and poor attempts at humor is not the place to get an official answer. Contact Novell public relations for that.

But you might be referring to the policy that we use for Mono, and I will be happy to discuss those with you. The policies are on our FAQ, so you might want to read that before you post in panic again.

Moonlight does not have the same policy that Mono does in terms of us working around to remove infringing c

No. There is no built-in support on X11 (you can hack a magnifier, but the same is true on Windows, or pretty much any system). What is used here is the ATK library originally developed by Sun for GTK+ and that has been now adopted by Qt4, and will, in the future, be, as a result, extended to KDE.

Don't know much about Windows, but it also has some similar accessibility library that exposes some introspection into the layout and the widgets, and I doubt it is as rudimentary as you make it sound. I think you may be confusing the accessibility layer with accessibility tools -- yeah, Windows doesn't bundle as much a11y tools as Gnome.

Just want to mention Vala, a high-level language with C#-like syntax that is compiled into C, so it has quite good performance.

It looks like an interesting project, albeit an unfinished one. It is also specific to GNOME in that it compiles into C code using GObject.

Completely agree with the above. Would just like to add that *if* you were to choose Gnome on whatever platform, there's a handy tool for locking it down called Pessulus : http://www.gnome.org/learn/admin-guide/latest/lock down.html

No *nix desktop runs Exchange + Outlook, nor runs Word.

Not true. You can, in fact, get Office to run on a *nix desktop. You'd just be much better off retraining people for OpenOffice or KOffice.

Word should be trivial to replace, but it isn't. It is hard to make people change, and most managers aren't willing to listen to complains just to save a few thousand (yet most should).

Put that few thousand into a training program. Done.

It would be a much more valid argument if there were still really critical features that either office suite doesn't have, but the reality is, for 99% of what you need to do with an office suite, KOffice is fine. Then, for maybe .9%, OpenOffice will cover you. That leaves .01% that you need Office for, so just make one XP machine and turn RDP on, for those very rare cases.

Exchange + Outlook is even harder, because it not only has a calendar system but also make it available to the network

Gosh, that's never been done before.

Now, if only we had a way to share them...

Trust me, Exchange + Outlook is a solved problem. If anything, the irony here is that I haven't been able to implement any of these at work, as there's not really any other good groupware clients for Windows, other than Outlook -- although most of the open servers can probably talk to Outlook. But if you can get them on Linux, I'd suggest Kontact and probably Kolab as the server.

It's even possible that KDE will be ported to Windows wholesale at some point, from what I've been reading. If that happens, just standardize on Kontact.

NetworkManager combined with a custom script should be able to address running Unison whenever connected to the correct network.

Bahh... I think the "vendor lock-in" for home users is a crock of shit. Linux does everything you want it to and more, whereas Windows comes with nothing useful out of the box. In my opinion, Kubuntu beats XP any day. How much time does the average user need to waste downloading this and that utility in order to do the most basic things? Wireless networking with NetworkManager works better on my Kubuntu laptop than my girlfriend's XP laptop. Furthermore, I'll take the integrated KDE UI over the mish-mash of Windows programs that each implement their own "cartoon" GUIs.

There are several IDEs for linux, my favorites: boa-constructor, glade.

Gnome project was started also exactly 10 years ago! Happy anniversary, guys!
http://mail.gnome.org/archives/gtk-list/1997-Augus t/msg00123.html

In terms of a typical Unix, you have a kernel, a shell, libraries and tools. GNU has all those, and some people choose to replace one of them with Linux.

* Shell - bash
* Libraries - glibc
* Tools - GNU coreutils
* Kernel - Hurd

Bash, isn't productive? Install GNOME - it's part of GNU.

http://www.gnome.org/about/

"GNOME is Free Software and part of the GNU project."

I crashed a large Epiphany session with a segmentation violation a couple of days ago

Many crashes are due to misbehaving plugins. Due to Mozilla plugin architecture, there's nothing we can do about this. (However, an experimental WebKit back-end was recently added to Epiphany.)

It's just a shame that the connector doesn't work with Exchange 2007. I used Evolution + connector for years now and when our MS loving bleeding edge Exchange admins upgraded to Exchange 2007 late in 2006 my Evolution + connector usage came to a screeching halt:

http://bugzilla.gnome.org/show_bug.cgi?id=374810

I really think part of that big paycheck from Microsoft to Novell was incentive money to Novell to be slow to make this "interoperability" thing work. It was about the same time the deal was done that I could no longer access corporate email. Novell has been bought and paid for and I will never touch SUSE again because of it.

Try Dia as a replacement for Omnigraffle.

http://www.gnome.org/

Gnumeric isn't strictly gnome. I'm running it on Xfce. Gnumeric's dependencies are pretty straightforward to install, in case your system doesn't already have those libraries.

Cutting and pasting a table from Excel into Word requires that both applications agree on what the format of that data will be

Gross oversimplification. The real difficulty is what happens after one of the applications is closed. This post explains how the Windows clipboard works: http://mail.gnome.org/archives/desktop-devel-list/ 2003-September/msg00257.html

*nix applications are developed entiresly independantly of one another

That's a bit of an odd thing to say. Applications on all OSes are developed somewhat independently of each other; that's what makes them individual applications. They aren't developed entirely independently of each other, otherwise they plain wouldn't work. They make use of each other's APIs, they talk to each other, they collaborate and depend on each other. A lot of apps on Linux tend to cooperate very well considering that they are developed pretty much all by third parties. 3rd party applications in Windows tend to be pretty bad for cooperation with each other and the OS in general... they tend to try and all compete for the user's attention in a highly uncoordinated way.

if you want to cut something from gnumeric and past it into OOo writer, it's not going to work

Copy and pasting from Excel into Word works fine. As does copy and pasting from OOo Calc into OOo Writer. This covers 95% of use cases. I wonder, though, how well things like Lotus 1-2-3 or Gnumeric/Win32 works when copying into Microsoft Word... I don't know, I've never tried... but I do know that a lot of the cooperation between Microsoft Office and third party applications isn't because of their solid foundation on standards, but rather because support has been hacked into the application. There may well be standards, but Microsoft in particular seem to be pretty good at diverging from even their own standards. Admittedly, clipboard is a bit of a soft spot

X needs a "com"unication layer

There is lots of session/system communication in Linux, all for different purposes and with different ideas. Many are agreed upon and collaborated with. DBUS is one.

"just use Samba or NFS" you say? Ha. Linux security works at the OS level. If you're root on one system and you access a filesystem on another system over NFS you can modify files owned by root without having authenticated. That's a HUGE security flaw and it's been that way forever.

You've fudged an awful lot of information here....

It is true that NFSv3 works this way, but it is also true that NFSv3 should only be used on trusted networks. This is nothing to do with filesystem security being at the OS level. It's true that this is the case, but that's nothing to do with the fact that being root allows you to behave as root on other computers... this is purely the way that NFS is implemented. Filesystem security should be at the OS level... that's merely how applications interact with the filesystem. Applications mediate the network access to filesystems, so if they're running as root and allow external users to access as root, it's their fault. NFSv4 fixes a lot of these flaws.

Samba/SMB/CIFS (or indeed AFS, DFS, or many of the other network filesystems) do not have this problem whatsoever. They work exactly the same as Windows File Sharing and in the case of Samba, is completely cross compatible with Windows.

NFSv4 isn't anywhere near the "just works" stage

I don't think it will ever be, and I think this is the idea of NFS. I don't think NFS was ever meant to be "just

If you make a mistake in any configuration file on Linux, things aren't going to work properly. That's the way of things, and there's no simple fix. It's just the same for KDE. You might be looking for the GNOME FTP site (ftp://ftp.gnome.org/Public/gnome/sources/). It doesn't include Cairo, since that's a separate project. When compiling, the configuration script should check that you've got the minimum required versions of all dependencies, which should stop compilation from failing. GTK+ (etc.) will compile fine with any version later of a dependency than its minimum required version, so you don't really need to get a "set of fitting version together". Regardless, you should be using your distribution's package management system, since it'll likely have distribution-specific changes. You just go to kde.org; I just go to http://www.gnome.org/start/2.18/ (linked to from gnome.org).

If you want to build GNOME from source, try http://www.gnome.org/projects/garnome/ HTH

They've had this idea before for a small, fast oss browser... it's called Dillo http://www.dillo.org/.

Why not fund Dillo so it can start up production again?

And for Firefox lite compare it to Gnome's browser Epiphany--

Dillo http://www.dillo.org/download/dillo-0.8.6.tar.bz2 is less than 1 MB, Epiphany http://ftp.gnome.org/pub/GNOME/sources/epiphany/2. 18/epiphany-2.18.1.tar.bz2 is less than 5 MB, while Firefox ftp://ftp.mozilla.org/pub/mozilla.org/firefox/rele ases/latest-2.0/source/firefox-2.0.0.5-source.tar. bz2 is ~35 MB!!

There are many lite weight open source browsers. Why not port them to Windows instead of asking Firefox to design another browser?

I'm sorry but this has already been done, it includes tabs (as "pages") and bookmarks, but it's much lighter then Mozilla Firefox: K-Meleon

But I wouldn't recommend running Windows on old PC's, especially when they're connected to the Internet. Build Epiphany with XULRunner, it's a pretty good browser IMHO.

With Irfanview it's something like select images and do operation on the images. With an off-the-shelf Gimp it's not possible.

see: Bug 173066 - Feature Request: Batch-Processor

Startup on Win32 is pretty fast, definitely a lot faster than Photoshop. If it isn't, then your font cache is broken as explained in the FAQ.

Yes, it would be good to finally figure out why this happens at all and there are people working on this (see bug 154968).

Just a note, "Abiword+Gnumeric+etc." is known as "GNOME Office".

http://www.gnome.org/gnome-office/

I think the distinction between compiled and scripting languages being made is largely historical and cultural. Because, take a step back: Practically, is there much difference?

As you develop -- doing incremental development, testing as you go -- you write some code, and then you run it. How relevant really is it to you that there's a "compilation" step in the middle? Ten bucks says you're working in an IDE with a single button to click that compiles your code and runs it. So what's the big deal?

(Compiling does add an additional time lag, especially on large projects, but chances are you're only recompiling one or two object files and linking, so it's not like compiling from scratch; it's not bad at all.)

In the grand scheme (was that a LISP pun?) of things, Javascript and C++ are pretty damn similar. They're imperative, OO languages. They even have similar syntax. What is so hugely different about writing Javascript? Writing an algorithm in one is pretty much like writing an algorithm in the other.

Javascript lets you interact with HTML and the whole DOM, so you've got a lot of interface stuff set up ahead-of-time for you: That's the difference. But in theory, a nice library in C++ could give you the same thing. And using Qt or GTK, often in conjunction with something like (in the year 2007) Glade, even that gap is narrower now than it used to be.

The distinction between compiled and scripted languages also doesn't give, say, Javascript, its due. Javascript is a nice language; it's easy to write code in; it's Turing-complete (of course). If somebody wrote a binary compiler for it and some Unix libraries (maybe this has already happened?), it could compete in a niche similar to C++-and-Java's. (In fact, it'd almost be nicer than Java ;-) ).

I will agree that "web developers" tend to care more about the visual aspect: 'Design,' presentation, and the UI. But that says more about where they're coming from, I think -- they got into programming via writing webpages, once upon a time -- than it does about the tools they're using now. Because algorithms are algorithms.

If you use Gnome you might want to look at Tracker.
http://www.gnome.org/projects/tracker/

Tracker is a tool designed to extract information and metadata about your personal data so that it can be searched easily and quickly. By using Tracker, you no longer have to remember where you've left your files. To locate a file you only need to remember something about it, such as a word in the document or the artist of the song. This is because as well as searching for files in the traditional way, by name and location, Tracker searches files' contents and metadata.

not only beagle, but there's also http://www.gnome.org/projects/tracker/ to compete with, not written in mono n stuff.

For those who don't get it, read this: http://bugzilla.gnome.org/show_bug.cgi?id=316654 This is why I stopped using GNOME.

Ok, don't go for the gold right out of the box. Find a smaller/lesser know OSS project to work on.

Some projects are actively trying to get newbies involved. I've heard of GnomeLove (though I don't actually know much about it), and Subversion has a list of bite-sized tasks.

They also have co-opted gnome