Slashdot Mirror

So... not a big deal. you can always build it yourself (if you have the skills). I would bet a third party would come along and pick up the task of porting if there is enough interest.

Except, those 3rd parties have already been contributing to it ... as has been pointed out, Solaris has adopted and invested time and effort into it ... it's been ported to the BSDs and likely has benefited from some bug fixes from them ...

This more or less throws away the fact that people who aren't tied to Linux have been contributing to Gnome for as long as it's been around. Hell, Gnome originated as a cross-platform toolkit -- to suddenly pretend otherwise is self-serving.

The basic thing I'm noticing is that for a guy who in his history of GNOME describes himself as a "free software entusiast" [sic], he seems awfully disinterested in making Gnome better, or if the Gnome devs don't like his ideas forking off something of his own.

The other fascinating point I see in your second statement is that it's not the open source world's fault that the latest and greatest high-performance video and audio cards aren't supported as well as they are on Windows. Microsoft, Apple, etc have very little to do with that level of support - it's Intel, ATI, NVidia, etc that are doing the hard work to make their stuff work on Windows, and just don't care about the Linux market.

On the flip side, unless you're doing high performance gaming, you really don't need to care about having the latest and greatest hardware. And one thing Linux does very very well is support older hardware.

A quick googling ("libgmp .net mono") turns up the possibility that there may be a wrapper for libgmp in mono. Other than my google-fu, I know nothing of .net and mono.

Writing GUI-based GTK# applications does not require any libraries not covered by this promise. There are FOSS database access libraries available for Mono that interface with MySQL etc. without needing ADO.NET. In fact, none of the high profile C# complex(!) applications for Linux like FSpot, Banshee or Tomboy require any libraries not covered. And Mono is separating the source code into two parts in a future release so that you can run the libraries in doubt at your own discretion and risk. You're the one who's missing it, not everyone else. Here is a figure for clear delineation. http://primates.ximian.com/~miguel/tmp/two-stacks.png

Flamebait, maybe. These kids today do not respect a healthy, if inflammatory point. Makes sites like Digg a nightmare.

The reason GNOME was started is nearly the same the reason it should fade away. Because KDE relied upon (the then closed) Qt, GNOME was started, as a workaround using the GIMP Tool Kit. It's a similar situation with Mono, but hairier.

This is actually something to remember, thanks!

"I mailed Richard Stallman to let him know that this interesting project existed. KDE was licensed under the terms of the GNU GPL. I got a reply back from both Erik and Richard pointing out that KDE dependency on Qt resulted in a piece of non-free software. Qt did not end users the right to modify, redistribute nor distribute modifed copies of the code and violated the terms of the GNU GPL."

From The Story of the GNOME project.

I have to totally agree with you that this debate has been gone over so many times that it is a troll posting. Please read the following.... Started by another troll on the mono list anonymously under the name 666lawyer: http://lists.ximian.com/pipermail/mono-list/2009-June/042680.html From some time ago... http://www.jprl.com/Blog/archive/development/mono/2009/Jan-19.html Here we go again...Why Mono doesn't Suck... http://www2.apebox.org/wordpress/rants/124/

You haven't been with GNOME forever, then, and maybe not even very long, as these things are reckoned :) Enlightenment was the original GNOME window manager, back in the day when Rasterman worked closely with the GNOME project. I started using GNOME in the late 1990s, and it was most definitely using E at that time. See Miguel's page on the early history of GNOME here:

http://primates.ximian.com/~miguel/gnome-history.html

E was later replaced by Sawfish, which I never cared for. I guess a lot of other people didn't either, because sometime in 2002, after I'd stopped using GNOME, Sawfish was replaced with Metacity.

Nice memories of those old days when Linux was still an adventure. Cheers!

KDE is Free Software. True Free Software.

KDE is "True Free Software"? OMFG, how times have changed! One of the biggest single reasons I'm a GNOME user today is because back in the "dark ages" KDE depended upon the then-proprietary qt library and GNOME and the associated GTK library were "truly Free". By the time this was rectified GNOME had improved a lot, GNOME designers were more focused on usability and I was already used to the environment.

One thing that has NOT changed is the licensing for GNOME--it's still good ol' GPL and LGPL and nothing else.

GNOME is free software lite. It is almost free software, just without the Four Freedoms. With KDE, you can be sure that all KDE software you use is truly Free. GNOME, on the other hand, is more than willing to bow to Microsoft.

With GNOME, you can see the source code, make copies of the code or resulting binaries to meet any needs you have, use it for any purpose you want (fit or unfit, without any warranty, but still use it nonetheless) and of course you can share it with your friends without the BSA beating down your door. Those are pretty good freedoms, and there are four of them. Can you explain to me SPECIFICALLY where the freedoms are lacking?

Furthermore, with KDE, what exactly give you any more assurance over GNOME that the software you are using is truly free? Trolltech will happily offer an alternative, proprietary license for its code to the highest bidder. GNOME has taken a more consistent approach by putting libraries under LGPL--so commercial apps can be made that take advantage of GTK yet the libraries are sure to remain Free. Such is not the case with commercial KDE apps. You can use KDE-based software that is totally non-Free because the publishers have paid off Trolltech.

At least with GNOME everyone has to play by the same rules and the GNOME platform itself remains uncompromised. Historically KDE with qt has been quite a moving target due to different platforms having different licensing rules and with the dual licensing scheme in place.

GNOME died the day it accepted Evolution with the proprietary Exchange connector.

What have you been smoking? I suggest you stop because it's frying your brain. From the "horses mouth" (Novell's own press release):

The Evolution Connector for Microsoft Exchange Server source code can be found at http://ftp.ximian.com/ and developer information about Evolution can be found at http://www.gnome.org/projects/evolution. The Connector code is now available to the public along with the rest of Evolution under the terms of the GNU General Public License (GPL).

When Novell included the connector with Evolution 2.0 it also relicensed it to GPL (FULL GPL at that; not LGPL) and it immediately made all the source code for it available the very second it licensed it under GPL. Do you know something I don't? How EXACTLY is this different from when Trolltech GPLed its libraries to allow them to be TRULY Free? Being you're such a devout fan of KDE surely you know how this is different?

The fact that KDE is objectively a better desktop environment is just gravy.

I've never once seen any OBJECTIVE evidence that one desktop is superior over the other from end users OR developers. It's ALWAYS been a matter of personal tastes, which are very SUBJECTIVE...visual layout, how things are configured, use of C++ or whatever. Again, I gladly welcome any concrete, specific areas where KDE is without a doubt superior to GNOME. I prefer GNOME over KDE myself, and I'll freely admit that I think KDE does SOME stuff better and that my overall impressions are largely my personal taste. To be more specific, I find the GNOME design has become more consistent than KDE (something that wasn't always the case, but has become true over time as GNOME has really pushed specific and consistent usability/UI standards for the desktop and ass

There's no smoking gun, but Miguel's own writings on the topic suggest that even GNOME was intended to be a playpen for him to start cloning Microsoft's technologies. From http://primates.ximian.com/~miguel/gnome-history.html:

At Microsoft I learned the truth about ActiveX and COM and I got very interested in it inmediately. Upon my return to Mexico Federico and I started to design a GUI control infrastructure for Unix that we code named `GNOME'. He was working as the maintainer of the GIMP back then and our efforts were targeted towards its adoption on Tk at the time. This project was the seed for what later became the Bonobo component architecture (sixteen months would pass before I started working on Bonobo).

No fancy editing on my part - he really does go straight from describing his admiration for ActiveX to describing his work on GNOME - the GNU Network Object Model Environment.

Thank God other people wrested control of the project from him years ago.

Yeah. Lets port to Mono ASAP!

This message piped directly to your Term via stin...

Good question, given that "look like ass" is highly variable from person to person. I think Windows apps look like ass. YMMV.

Wow, zealot much? I want stuff to look like native. That rules out out most of the cross platform stuff.

But I can see if you consider XML 'programming', WTL's assembly language HWND to CWnd* converter is a bit hard to understand. It's a pity for you that the world is full of Indians and Chinese who are smart enough to figure out stuff like this if that's what it takes to produce an efficient end result.

Just one more example. I can't vouch for how bloated or not the applications it produces are.

http://lists.ximian.com/archives/public/mono-devel -list/2005-October/015136.html

9MB Hello World applications. I've worked on phones that managed a GSM stack, GUI, TCP/IP in less than that.

I just ran across an interesting blog entry by Federico Mena Quintero that linked to two interesting papers : When should a test be automated? and Classic testing mistakes.
Automated tests are often more expensive to write than manual tests, so when should you do automated tests versus manual ones? The answer is not always automated tests. Also typical unit testing is only part of what kind of testing needs to happen.
Using Ring Buffer Logging to Help Find Bugs was also another good link that Federico had in another entry.

The Eft file selector has a visible location box.

At the Ottawa Linux Symposium in 1999 or 2000, Miguel had a series of slides about why UNIX sucks. Those were his words. Check it out yourself.

As for why MSFT didn't get the desktop right, I'm not really qualified to answer, because in my entire career, I've used Windows only for a hellish 5-month stint back in 1996 (Win95). The things I hated about the Win95 desktop:

• No window manager. If an application hung, there was no way to move its window temporarily, because applications had to cooperate to move or close windows.
• Cumbersome cut-n-paste compared to X.
• No decent command-line tool. (My perfect desktop is a wall of xterms. :-))
• Hideous complexity under the hood. Edit some magic mumble-mumble registry key if you want to do X...
• Totally useless error messages, so when something inevitably goes wrong, you haven't a clue how to fix it.

I'm not sure if MSFT has fixed the desktop. Somehow, I doubt it.

Unfortunately, the two big Linux desktops (GNOME and KDE) are showing symptoms of Windozification, which is why I don't use them. XFCE is just perfect, IMO.

Merging is only supported using the actual version numbers, not tags. Specifically, the merge command syntax requires the user to determine what version numbers are associated with what tags so as to perform the merge using the version numbers.

Not at all. You clearly have a lot of documentation reading to do, and it's pointless for me to reproduce it here, but let me at least say that you need not specify the version numbers at all, and that you haven't understood that there are SVN tags which, while simply represented by directories (Unix philosophy anyone?), are actually a snapshot of a certain revision and thus interchangeable with revision numbers. Go ahead and tag your every commit with whatever naming scheme you want if it makes you more comfortable, and use those instead.

The "copy" is referred to by SVN zealots as a "cheap copy" because it is an almost constant time operation

So making an objective observation about an O(1) copying operation makes one an SVN zealot? That's a pretty cheap shot. Are computer scientists "linked-list zealots" too when they point out that adding an entry to the beginning of those is usually O(1), and thus are objectively better at that than other data structures? I honestly don't get your aggressive tone against a technology which you don't seem to understand and has done no harm to you, yet serves many of us well. Seriously, have you even used it?

What the documentation says occurs is that links are made to the original repository area and the file deltas are recorded in the new tree. Conceptually this means that space consumption is very small being only a small growth in the size of some control files and creation of some directories. Realistically, there is a practical limit on the number of directory entries that can be made in a system. So for a very large repository containing many modules, tags and branches, then the growth rate in directory entry usage would be significant if not unsustainable.

Uh, no. Had you even once created an FSFS repository you would have noticed that in fact every transaction, no matter how large, adds exactly two (2) new files to your filesystem, one with the revision and one with the revision properties (usually just a few bytes). All the operations described in the documentation are done in the SVN virtual filesystem. When you commit changes, the revision file contains an aggregation of all the reverse deltas of the changes you made in that transaction. When you commit branches/tags, that file contains the difference in the virtual filesystem nodes described in the link. By my count, that file is usually a little over 600 bytes. I don't know the details about BDB but it's similar.

Convinced yet? No? Good! How about you try it?

The migration of a multiple-project CVS repository to SVN appears on the surface to be an unsustainable move. Ideally, the projects would be split into separate repositories if such a migration was to be performed.

Really? You should tell these guys (have a look at their repo). Or them. Or them.

The reasons to stay with CVS would be largely dictated by practical issues.

Finally, we agree. Pretty much the only meaningful reason to stay with CVS these days is backwards compatibility with tools & user training. And even those are fading, as SVN support is added to pretty much everything and it turns out it's not that different from the basic users' point of view (it is different for the more advanced users who need to tag, branch & merge, but those can learn it just as they did CVS; I'd argue that conceptually it's even simpler). Another big reason might be that they simply can't be

I'm such a moron... I can't believe I entirely forgot about a great piece of Linux photo management software - F-Spot! Larry Ewing (of Tux fame) has been working on it for some time for Novell.

It looks to be an iPhoto work-alike for Linux.

Yes, it is faster. And it has had quite a bit of complexity analysis:
http://primates.ximian.com/~federico/news-2005-09. html#gtkfilechooser-profile-1
http://primates.ximian.com/~federico/news-2005-09. html#gtkfilechooser-profile-2
http://primates.ximian.com/~federico/news-2005-09. html#gtkfilechooser-profile-3
http://primates.ximian.com/~federico/news-2005-10. html#gtkfilechooser-profile-4
http://primates.ximian.com/~federico/news-2005-10. html#gtkfilechooser-profile-5
http://primates.ximian.com/~federico/news-2005-10. html#gtkfilechooser-profile-6
http://primates.ximian.com/~federico/news-2005-10. html#gtkfilechooser-profile-7
http://primates.ximian.com/~federico/news-2005-10. html#gtkfilechooser-profile-8
http://primates.ximian.com/~federico/news-2005-11. html#gtkfilechooser-profile-9

In fact, someone wrote up about it at O'Reilly, in an article entitled all hail the speed demons.

Yes, it is faster. And it has had quite a bit of complexity analysis:
http://primates.ximian.com/~federico/news-2005-09. html#gtkfilechooser-profile-1
http://primates.ximian.com/~federico/news-2005-09. html#gtkfilechooser-profile-2
http://primates.ximian.com/~federico/news-2005-09. html#gtkfilechooser-profile-3
http://primates.ximian.com/~federico/news-2005-10. html#gtkfilechooser-profile-4
http://primates.ximian.com/~federico/news-2005-10. html#gtkfilechooser-profile-5
http://primates.ximian.com/~federico/news-2005-10. html#gtkfilechooser-profile-6
http://primates.ximian.com/~federico/news-2005-10. html#gtkfilechooser-profile-7
http://primates.ximian.com/~federico/news-2005-10. html#gtkfilechooser-profile-8
http://primates.ximian.com/~federico/news-2005-11. html#gtkfilechooser-profile-9

In fact, someone wrote up about it at O'Reilly, in an article entitled all hail the speed demons.

Yes, it is faster. And it has had quite a bit of complexity analysis:
http://primates.ximian.com/~federico/news-2005-09. html#gtkfilechooser-profile-1
http://primates.ximian.com/~federico/news-2005-09. html#gtkfilechooser-profile-2
http://primates.ximian.com/~federico/news-2005-09. html#gtkfilechooser-profile-3
http://primates.ximian.com/~federico/news-2005-10. html#gtkfilechooser-profile-4
http://primates.ximian.com/~federico/news-2005-10. html#gtkfilechooser-profile-5
http://primates.ximian.com/~federico/news-2005-10. html#gtkfilechooser-profile-6
http://primates.ximian.com/~federico/news-2005-10. html#gtkfilechooser-profile-7
http://primates.ximian.com/~federico/news-2005-10. html#gtkfilechooser-profile-8
http://primates.ximian.com/~federico/news-2005-11. html#gtkfilechooser-profile-9

In fact, someone wrote up about it at O'Reilly, in an article entitled all hail the speed demons.

Yes, it is faster. And it has had quite a bit of complexity analysis:
http://primates.ximian.com/~federico/news-2005-09. html#gtkfilechooser-profile-1
http://primates.ximian.com/~federico/news-2005-09. html#gtkfilechooser-profile-2
http://primates.ximian.com/~federico/news-2005-09. html#gtkfilechooser-profile-3
http://primates.ximian.com/~federico/news-2005-10. html#gtkfilechooser-profile-4
http://primates.ximian.com/~federico/news-2005-10. html#gtkfilechooser-profile-5
http://primates.ximian.com/~federico/news-2005-10. html#gtkfilechooser-profile-6
http://primates.ximian.com/~federico/news-2005-10. html#gtkfilechooser-profile-7
http://primates.ximian.com/~federico/news-2005-10. html#gtkfilechooser-profile-8
http://primates.ximian.com/~federico/news-2005-11. html#gtkfilechooser-profile-9

In fact, someone wrote up about it at O'Reilly, in an article entitled all hail the speed demons.

Yes, it is faster. And it has had quite a bit of complexity analysis:
http://primates.ximian.com/~federico/news-2005-09. html#gtkfilechooser-profile-1
http://primates.ximian.com/~federico/news-2005-09. html#gtkfilechooser-profile-2
http://primates.ximian.com/~federico/news-2005-09. html#gtkfilechooser-profile-3
http://primates.ximian.com/~federico/news-2005-10. html#gtkfilechooser-profile-4
http://primates.ximian.com/~federico/news-2005-10. html#gtkfilechooser-profile-5
http://primates.ximian.com/~federico/news-2005-10. html#gtkfilechooser-profile-6
http://primates.ximian.com/~federico/news-2005-10. html#gtkfilechooser-profile-7
http://primates.ximian.com/~federico/news-2005-10. html#gtkfilechooser-profile-8
http://primates.ximian.com/~federico/news-2005-11. html#gtkfilechooser-profile-9

In fact, someone wrote up about it at O'Reilly, in an article entitled all hail the speed demons.

Yes, it is faster. And it has had quite a bit of complexity analysis:
http://primates.ximian.com/~federico/news-2005-09. html#gtkfilechooser-profile-1
http://primates.ximian.com/~federico/news-2005-09. html#gtkfilechooser-profile-2
http://primates.ximian.com/~federico/news-2005-09. html#gtkfilechooser-profile-3
http://primates.ximian.com/~federico/news-2005-10. html#gtkfilechooser-profile-4
http://primates.ximian.com/~federico/news-2005-10. html#gtkfilechooser-profile-5
http://primates.ximian.com/~federico/news-2005-10. html#gtkfilechooser-profile-6
http://primates.ximian.com/~federico/news-2005-10. html#gtkfilechooser-profile-7
http://primates.ximian.com/~federico/news-2005-10. html#gtkfilechooser-profile-8
http://primates.ximian.com/~federico/news-2005-11. html#gtkfilechooser-profile-9

In fact, someone wrote up about it at O'Reilly, in an article entitled all hail the speed demons.

Yes, it is faster. And it has had quite a bit of complexity analysis:
http://primates.ximian.com/~federico/news-2005-09. html#gtkfilechooser-profile-1
http://primates.ximian.com/~federico/news-2005-09. html#gtkfilechooser-profile-2
http://primates.ximian.com/~federico/news-2005-09. html#gtkfilechooser-profile-3
http://primates.ximian.com/~federico/news-2005-10. html#gtkfilechooser-profile-4
http://primates.ximian.com/~federico/news-2005-10. html#gtkfilechooser-profile-5
http://primates.ximian.com/~federico/news-2005-10. html#gtkfilechooser-profile-6
http://primates.ximian.com/~federico/news-2005-10. html#gtkfilechooser-profile-7
http://primates.ximian.com/~federico/news-2005-10. html#gtkfilechooser-profile-8
http://primates.ximian.com/~federico/news-2005-11. html#gtkfilechooser-profile-9

In fact, someone wrote up about it at O'Reilly, in an article entitled all hail the speed demons.

Yes, it is faster. And it has had quite a bit of complexity analysis:
http://primates.ximian.com/~federico/news-2005-09. html#gtkfilechooser-profile-1
http://primates.ximian.com/~federico/news-2005-09. html#gtkfilechooser-profile-2
http://primates.ximian.com/~federico/news-2005-09. html#gtkfilechooser-profile-3
http://primates.ximian.com/~federico/news-2005-10. html#gtkfilechooser-profile-4
http://primates.ximian.com/~federico/news-2005-10. html#gtkfilechooser-profile-5
http://primates.ximian.com/~federico/news-2005-10. html#gtkfilechooser-profile-6
http://primates.ximian.com/~federico/news-2005-10. html#gtkfilechooser-profile-7
http://primates.ximian.com/~federico/news-2005-10. html#gtkfilechooser-profile-8
http://primates.ximian.com/~federico/news-2005-11. html#gtkfilechooser-profile-9

In fact, someone wrote up about it at O'Reilly, in an article entitled all hail the speed demons.

Yes, it is faster. And it has had quite a bit of complexity analysis:
http://primates.ximian.com/~federico/news-2005-09. html#gtkfilechooser-profile-1
http://primates.ximian.com/~federico/news-2005-09. html#gtkfilechooser-profile-2
http://primates.ximian.com/~federico/news-2005-09. html#gtkfilechooser-profile-3
http://primates.ximian.com/~federico/news-2005-10. html#gtkfilechooser-profile-4
http://primates.ximian.com/~federico/news-2005-10. html#gtkfilechooser-profile-5
http://primates.ximian.com/~federico/news-2005-10. html#gtkfilechooser-profile-6
http://primates.ximian.com/~federico/news-2005-10. html#gtkfilechooser-profile-7
http://primates.ximian.com/~federico/news-2005-10. html#gtkfilechooser-profile-8
http://primates.ximian.com/~federico/news-2005-11. html#gtkfilechooser-profile-9

In fact, someone wrote up about it at O'Reilly, in an article entitled all hail the speed demons.

http://primates.ximian.com/~federico/news-2005-11. html#moz-imagesFederico Mena-Quintero firefox memory useage analysis

" When you run Mozilla or Firefox and load a web page with images, it stores the uncompressed images as pixmaps in the X server. In particular, it seems to maintain live pixmaps for all the images in all the tabs that you have open; even if a tab is not visible, the images will be in your X server's memory."

Wine is most certainly a reverse engineering effort. The problem is that you don't fully understand what reverse engineering includes.

Reverse engineering also includes the following process:

1. Write test (e.g. figure out some undocumented detail for CreateProcess)
2. Run test, get results (CreateProcess doesn't format your hard drive)
3. Write your own code to duplicate the results of the test written in (1)
4. Repeat 1..3 until complete.

This is black box reverse engineering. You treat some piece of software as a block box, write tests for it, figure out what the "box" is doing, and recreate that behavior. No decompilation required, no source code required, just lots of tests and ingenuity. This has the benefit that no copyright violations are required (since you never decompile the original program). This process is also used in clean room design, except step 3 is replaced with a documentation step -- instead of code being the result of the process a specification is the result. Compaq did this to reverse-engineer the IBM PC BIOS.

Wine is most certainly doing this, as it's the only way to determine undocumented connections between various APIs. Mono certainly does this ("what's this member supposed to do, and is Mono's version following that behavior properly?"). Another way to think of this is for bugs -- does this Mono code do what the .NET equivalent code does? If not, we'll get a bugzilla entry for it, and (eventually) fix it. This bug-report/fix cycle can also be considered as black box reverse engineering, since the bug-report is itself a test, through which we can determine what the actual functionality should be.

Decompilation is generally not legal, since it can lead to copyright violations. Black box reverse engineering is legal, and any attempt to limit black box reverse engineering would kill the interoperability market, since no compatible hardware/software could ever be created unless the original manufacturer permitted it.

Mono provides only a small subset of .NET.

You are welcome to go one all you like about how you like the Java standards story better than the .NET standards story, but you really need to stop making this demonstrably false claim about Mono's API coverage.

As you can see here, Mono covers about 98% of the v 1.1 (Everett) framework, which is what most shops still use. This is comparable to the JDK 1.5 implementation you just touted!

And as you can see here, Mono already covers about 90% of the just-released v 2.0 (Whidbey) framework.

And of course, these statistics leave out all the LDAP, GTK, CORBA, and other Unix-centric APIs that are in Mono but not in the .NET Framework.

Mono provides only a small subset of .NET.

You are welcome to go one all you like about how you like the Java standards story better than the .NET standards story, but you really need to stop making this demonstrably false claim about Mono's API coverage.

As you can see here, Mono covers about 98% of the v 1.1 (Everett) framework, which is what most shops still use. This is comparable to the JDK 1.5 implementation you just touted!

And as you can see here, Mono already covers about 90% of the just-released v 2.0 (Whidbey) framework.

And of course, these statistics leave out all the LDAP, GTK, CORBA, and other Unix-centric APIs that are in Mono but not in the .NET Framework.

• OpenOffice.org Hackers - note that the domain is ooo.ximian.com.
• Hacker's guide says CVS checkout is based at :pserver:anonymous@anoncvs.gnome.org:/cvs/gnome.
• Planet OOO features a few faces I remember from Planet GNOME, in particular, Michael Meeks.

• OpenOffice.org Hackers - note that the domain is ooo.ximian.com.
• Hacker's guide says CVS checkout is based at :pserver:anonymous@anoncvs.gnome.org:/cvs/gnome.
• Planet OOO features a few faces I remember from Planet GNOME, in particular, Michael Meeks.

"... parts of GTK that have, over the last few months, *FINALLY* been optimized by someone who knows what they are doing..."

"... parts of GTK that have, over the last few months, *FINALLY* been optimized by someone who knows what they are doing..."

"... parts of GTK that have, over the last few months, *FINALLY* been optimized by someone who knows what they are doing..."

Excuse me for being contrarian (and I don't have all the links), but TFA's headline is a good example of what's wrong: "Google throws bodies at OpenOffice"

OpenOffice is not self-sustaining. It only exists because people are being paid to work on it. I believe a decent link is the following...

http://www.openoffice.org/editorial/interview_joer g_heilig.html:
"""What is your role now in OpenOffice.org/StarOffice and what was your role in architecting the OpenOffice.org project at its inception?

I am responsible for the StarOffice engineering and in this role also responsible for all engineering work on OpenOffice.org done by Sun employees. At the time of OpenOffice.org's inception I was responsible for StarOffice's base technology and involved in all the engineering discussions around open sourcing StarOffice. """

IANAOSOSC (I am Not an Open Source Office Software Contributor)... but contrast that statement with AbiWord, KOffice, Evolution, InkScape, etc. (AbiWord and KOffice both had their versions of kernel-traffic-like summaries which allowed me keep up with various development issues and see how their insides worked at one point or another. OpenOffice needing an FTE to manage other FTE's who are writing code is a recipe for "code because we tell you to".

It seems like certain types of companies exist solely to make the most complicated build processes, technology decisions, etc. This is as opposed to the OSS way of "Keep it Simple, Stupid" ... when you start making it complex with $n+1 dependencies and steps the project either gets refactored or dies (and "Large(tm)" corporate invovlement generally has higher resistance to both the refactor and die options, as some areas seem to be personal vanity areas or have other political rather than technical motivations ... aka: Java).

http://ooo.ximian.com/hackers-guide.html:

"""Building and hacking on OpenOffice.org (OO.o) entails climbing a fairly lengthy incline. Hopefully this document will make the learning curve somewhat steeper and more abrupt, and will give you a walking stick to help you out."""

Which isn't to say that having somebody "big" like Sun behind an office suite is all bad. It's because of them that we have the clippy-like thing, the chm-like thing, the templates, wizards, import filters, and all the other mostly boring "feature checkboxes" that we do now in OO.o.

If I could wave my magic wand and have everything the way that I want, I'd split out the OO input filters (seem to get really good reviews and good personal results). Kill the really-tight integration between Presenter, Writer, Drawer, etc... (although if that's the way MSOffice handles embedded tables, etc., maybe it's a necessary evil?). And a healthy helping of de-cruftify, especially the preferences panels. Maybe a FireFox-like project to strip down OpenOffice would be helpful.

Just my outsider's perspective....

--Robert

Then after clicking a few links, I found Fernando Magariños, Ramón Morales López, and Mauricio Hernandez.

I'm sure there are countless others...

10,000 /doters render http://betterdesktop.ximian.com/video/ unusable.

Evolution port for OSX is already in progress according to Novell
http://mail.gnome.org/archives/evolution-list/2005 -March/msg00592.html
working with fink
http://primates.ximian.com/~aaron/doing/evo-osx.ht ml

While Tor Lillqvist and few others works on Windows port
http://evolution-win32.sourceforge.net/newsrss.php
screenshots
http://tml-blog.blogspot.com/2005/06/evolution-lim ps-along-on-windows-and.html

I have always felt that Linux is a nice operating system (for hobbyists and geeks), but there are some areas where it is seriously lacking, especially when compared to its main competitor, Microsoft Windows.

* File sharing. Windows has long been superior when it comes to making large amounts of files available to third parties. Even early versions of Windows automatically detected and made available all directories thanks to the built in NetBIOS-powered file sharing support. But Microsoft has realized that this technology is inherently limited and has added even better file sharing support to its Windows XP operating system. Universal Plug and Play will make it possible to literally access any file, from any device! I think universal file sharing support needs to be built into the Linux kernel soon.

* Intelligent agents. With innovations like Clippy, the talking paperclip and Microsoft Bob, Microsoft has always tried to make life easier for its customers. With Outlook and Outlook Express, Microsoft has built a framework for developers to create even smarter agents. Especially popular agents include "Sircam", which automatically asks the users' friends for advice on files he is working on and the "Hybris" agent, which is a self-replicating copy of a humorous take on "Snow-White and the Seven Dwarves" (the real story!). Microsoft is working on expanding this P2P technology to its web servers. This project is still in the beta stage, thus the name "Code Red". The next versions will be called "Code Yellow" and "Code Green".

* Version numbers. Linux has real naming problems. What's the difference between a 2.4.19 and a 2.2.17 kernel anyway? And what's with those odd and even numbers? Microsoft has always had clear and sophisticated naming/versioning policies. For example, Windows 95 was named Windows 95 because it was released in 1995. Windows 98 was released three years later, and so on. Windows XP brought a whole new "experience" to the user, therefore the name. I suggest that the next Linux kernel releases be called Linux 03, Linux 04, Linux 04.5 (OSR1),
Linux 04.7B (OSR2 SP4 OEM), Linux 2005 and Linux VD (Valentine's Day edition). Furthermore, remember how Microsoft named every upcoming version of Windows after some Egyptian city? Cairo, Chicago and so on. I think that the development kernels should be named after Spanish cities to celebrate Linux' Spanish origins. Linux Milano or Linux Rome anyone?

* Multi-User Support. This has always been one of Microsoft's strong sides, especially in the Windows 95/98 variants, where passwords were completely unnecessary. Microsoft has made the right decision by not bothering the user
with a distinction between "normal" and "root" users too much -- practice has shown that average users can be trusted to act responsibly and in full awareness of the potential consequences of their actions. After all, if your operating system doesn't trust you, why should you trust it? (To be fair, Linux is making some progress here with the Lindows distribution, where users are always running as root.)

With Windows XP, Microsoft has again improved multi-user support. Not only does Windows XP come with a large library of user pictures that are displayed on the login screen, such as a guitar and a flower, i

Sure, OpenOffice is great, but commercial enterprises will stick with commercial solutions for which there is support.

I don't exactly get what you mean by support. My impression from the people and businesses I know personally is that Microsoft Office format is a big success not because of "support", but because there's a wealth of products built around it by third parties.
These 3rd-party products are crucial for the enterprise, stuff like Eletronic Content Management, being able to create document workflow and revision systems, and groupware. All this stuff integrates seamlessly with the Windows desktop and the Windows office applications. In any enterprise with a huge amount of paper and workflow, document management systems are a necessity. This is point OpenOffice proponents frequently forget: office applications are not about just the single desktop user but they are also about integrating seamlessly in an eco-system of content management software provided by theird-parties and accessing legacy documents. For instance, in my country, Brazil, legislation demmands that certain financial documents be stored for a period that outruns any document format you might have seen. This means people have to migrate very old sofware document records.
This is an area ISV working on open-source platforms could explore, an unexplored niche market. AFAIK, not even COLD solutions exists and COLD goes way back decades (ever since computers started processing bills.) And there are no equivalents of proprietary software in the open-source market (this shows you that open source developers are sometimes out of touch with their would-be customer base). People are developing groupware, but there are no ECM (Enterprise Content Management) solutions. Groupware, ERM, and ECM are the bulk of enterprise software.
If only the open-source community would take something like OpenOffice, or further develop AbiWord (which has nice plug-in functionalities), and integrate these with Mono, you would have made a serious dent in the Windows dominance. I mean, who wouldn't want to avoid expensive per-seat Microsoft licenses, plus per-seat ECM licenses? And software houses that provide ECM solution (e.g., the market leader OnBase) work with year-round support and customization, and we know this is a way of doing business that is viable for open-source (of course, they have per-seat licenses).
BTW, I really mean Mono, and not Java. Java is not an alternative on the long term, not only because of the Java's proprietary nature, but because Mono is gearing itself towards Windows-*Nix interoperability, to the point where software build with Windows.Forms will work on Mono. Additionally, having to depend on Sun's finances is a a suicidal investment of resources.
But open-source has major hurdles: it nees to standardize on OpenGroup and LSB That is to say, the Free Standards Group has to advanced by libre *Nix distros and vendors, so that software developers have an easier time with all the distros. De Icaza wrote something about this in this essay. Linux distros need to be reliable in terms of time frame for releases (which the commercial ones are), too.
My feeling is that Microsoft has foreseen a trend going against its closed-source format (OASIS, the Massachusetts imbroglio) and anticipated any possible open-source incursion in the field of content management. If these formats are truly opened, they've raised the bar for the arguments of any future switching to FOSS platforms+OO.org solutions (because, right now, as I've argued, there are no FOSS replacements for content management for the enterprise AFAIK, and there's a huge amo

here

Fork in the Open Source Java world.

Does anyone know where to get binaries of this little gem? A few higher-quality icons REALLY goes a long way...

I know he can tell you why Brazil is so great for FOSS Projects and developers

I know he can tell you why Brazil is so great for FOSS Projects and developers

I know he can tell you why Brazil is so great for FOSS Projects and developers

I know he can tell you why Brazil is so great for FOSS Projects and developers

I know he can tell you why Brazil is so great for FOSS Projects and developers