Slashdot Mirror

For something that's more completely considered a bug, check the long and sorry history of bug 108951. Only about 6 years old, but one of the more irritating ones. Sad to see such an issue bounced from distro to project to DE and back again, then finally closed because the feature it affects is removed.

Cheers. I see no reason therefore to include Tomboy + Mono by default with Gnome on Debian - or do other parts of Gnome depend upon Mono now?

There ARE reasons, why not listen to the distro maintainers instead of armchair speculation from reading Slashdot posts? http://www.archivum.info/fedora-desktop-list@redhat.com/2009-04/msg00005.html [archivum.info] [archivum.info] :

- We're using tomboy as an applet, which gnote currently does not support. I'm far from a notification area purist, but I do think that a note-taking application has no place in it... - If we are talking about replacing tomboy with gnote, we need to have some data migration that is more automatic that 'open terminal, cp .tomboy .gnote'. - While gnote on the surface looks like a clone of tomboy, if you look at the addins that come with tomboy, you'll probably find that gnote is not yet a full replacement for tomboy power users (it certainly works fine for my tomboy use...).

I guess Tomboy is a nice test-case. But all that junk to install just for a note-taking program?

Tomboy is not 50MB, the whole Mono framework is that much, Tomboy is relatively small. If you use F-Spot or Beagle, Mono runtime is installed anyway. Debian had reason to include Tomboy instead of Gnote. Also Tomboy does not have Applet support, which is why Debian wants it in the Gnome install instead of Gnote. From http://www.archivum.info/fedora-desktop-list@redhat.com/2009-04/msg00005.html [archivum.info] :

- We're using tomboy as an applet, which gnote currently does not support. I'm far from a notification area purist, but I do think that a note-taking application has no place in it... - If we are talking about replacing tomboy with gnote, we need to have some data migration that is more automatic that 'open terminal, cp .tomboy .gnote'. - While gnote on the surface looks like a clone of tomboy, if you look at the addins that come with tomboy, you'll probably find that gnote is not yet a full replacement for tomboy power users (it certainly works fine for my tomboy use...).

Our stance on Gnote is that it is counterproductive to maintain identical software in two languages. It will be harmful to the community, especially as these two apps inevitably diverge. It will result in duplication of effort, duplication of bugs, and a lot of wasted time for those who are trying to add value to the user experience. Tomboy is not going away, and it will continue to be developed on the extremely productive Mono/GTK# language platform. Anyone thinking about distributing Gnote should consider the impact on users and their data. When we develop, we should always be asking ourselves, "is this adding value for our users?"

Also Tomboy does not have Applet support, which is why Debian wants it in the Gnome install instead of Gnote. From http://www.archivum.info/fedora-desktop-list@redhat.com/2009-04/msg00005.html :

- We're using tomboy as an applet, which gnote currently does not support. I'm far from a notification area purist, but I do think that a note-taking application has no place in it... - If we are talking about replacing tomboy with gnote, we need to have some data migration that is more automatic that 'open terminal, cp .tomboy .gnote'. - While gnote on the surface looks like a clone of tomboy, if you look at the addins that come with tomboy, you'll probably find that gnote is not yet a full replacement for tomboy power users (it certainly works fine for my tomboy use...).

You can use gnote if it fits your desires, but claiming that it should be default for ALL users is misguided. The Debian packagers know better than you.

update: I did a quick search (before trying to reverse engineer it myself) and with a bit of hex editing (and repairing), you can open it with Access

This smells of arse covering wrapped up in finger-pointing.

Microsoft followed the ODF specification to the letter and now the ODF Alliance have the cheek to blame them for the fact that the documentation turns out to be incomplete, poorly written and makes a bucket load of assumptions?

This is going to do nothing to help ODF adoption and whilst Microsoft deserve some critisism for not being flexible when came to implementing it, the Alliance shouldn't think it is entirely blameless in the whole matter.

Ironically, they did it precisely the other way - they've implemented the ODF spec to the letter, and ignored any conformance bugs in OpenOffice (and in pretty much all other existing ODF implementations, which tend to follow OpenOffice behavior). The result is that you will have problems moving ODF documents between MSOffice and OpenOffice, but Microsoft gets to point a blaming finger at OpenOffice guys if asked.

I wonder, also, how it will affect any government tenders on Office suites. If one of the requirements is support for ODF, then Microsoft can just say that they're the only ones on the market with a fully compliant implementation, and point out flaws in OO.org...

We definitely need this AcidTest for ODF rendering. I just ran across this post that highlights a few potential problems in Microsoft's implementation: http://www.archivum.info/comp.os.linux.advocacy/2008-08/msg00757.html

Some of Sun's PostgreSQL contributions can be found in that link.

More importantly, Sun provides PostgreSQL support on Solaris.

According to Larry Ellison, Solaris/SPARC is the leading platform for Oracle deployments.

Oracle has been lagging with Solaris/x86 support so it would have been a great opportunity for sun to do more with PostgreSQL on Solaris and increase their revenues by making a more affordable alternative to Oracle.

PostgreSQL/Solaris/ZFS/DTrace could really eat into Oracle's market if there was more effort put into it.

I think they should have done more with pgsql, and missed a big opportunity, but I wouldn't belittle their contributions.

I've been waiting this for ages. When OpenSolaris gets it, it will blow away many supposedly "Enterprise" storage systems.

zpool remove will eventually support the removal of any vdev, not only hotspares like it does now.

It has been filed as a bug by the OpenSolaris developers.

Admittedly it looks rather old, but they say work is under way to do it.

I currently use http://www.archivum.info/ - while the interface is not perfect, I still like it much better than the current Google interface. It is unfortunately not a complete replacement.

BTW, DejaNews already started to get worse before Google acquired them. That was around the time when they changed their name from DejaNews to just Deja.