Harvard Business School of Echec - gnome - Commentaires

ABI vs. API compatibility - Mart Raudsepp

Mart Raudsepp — Fri, 25 Apr 2008 21:10:11 +0200

err, yes, you need to implement PSS in all other platforms if you want to add it and not leave it empty for non-linux. Obviously. But you don't need to implement anything else already done yet again with the suggestion in comment #8...

ABI vs. API compatibility - Benoît Dejean

Benoît Dejean — Wed, 23 Apr 2008 11:11:02 +0200

Whenever i add a new functionnality (which is implemented as 3/4 functions), it has to be ported on linux, the 2 BSD arch and eventually solaris, darwin or aix. I can't do all these ports because of a lack of time/interest. So adding a new function for a single guint64 is too much work/breakage.

I was looking for alternatives where i would be able to do all the work myself:
- breaking the ABI moves all the work to distro packagers
- breaking the API would let me submit trivial patches to upstreams

ABI vs. API compatibility - Mart Raudsepp

Mart Raudsepp — Tue, 22 Apr 2008 23:22:30 +0200

Benoît> "Well, i cannot deprecate anything because that would mean throw away all the different/untested implemtentations on all !linux arch. Adding a new function also means breaking all !linux arch until someone test it (which almost always happens after the first stable release)."

How about adding the PSS support to the existing functions, but afterwards renaming glibtop_get_proc_mem to the new name, while adding a compatibility wrapper of the old name (keeping API and ABI in effect) that constructs the old style struct out of the results it gets from the new one that has more data - should be just some struct field copying and throwing away the bigger struct before returning the copied (deprecated) compatibility one from glibtop_get_proc_mem

ABI vs. API compatibility - Bronson

Bronson — Tue, 22 Apr 2008 21:32:40 +0200

I gotta agree with Rob... Leave this code alone, deprecate it, and just add a new call that takes a selector to tell what value to return.

Otherwise, you'll have to figure out hack upon hack upon hack every time you want to make this sort of change in the future. And, given kernel development, it won't be long before you'll need to extend it again...

ABI vs. API compatibility - James Henstridge

James Henstridge — Tue, 22 Apr 2008 17:22:04 +0200

If you decide to break the API, one option would be to add a "version" field to the start of the struct. Require the caller to fill it in before calling glibtop_get_proc_mem() so you can tell how big the caller thinks the struct is. Include the current version as a #define in the header so the caller can use it to initialise the structure to the right version.

If you need to expand the struct in the future, increment the version number and add new fields to the end. Then make glibtop_get_proc_mem() only fill in the fields if the version number is appropriate.

ABI vs. API compatibility - Benoît Dejean

Benoît Dejean — Tue, 22 Apr 2008 16:04:37 +0200

Well, i cannot deprecate anything because that would mean throw away all the different/untested implemtentations on all !linux arch. Adding a new function also means breaking all !linux arch until someone test it (which almost always happens after the first stable release).

Storing pointers is not an option because the struct may be marshalled across a pipe. And the marshalling code is already terribly broken.

Adding reserved members is very hard when you don't want to bloat your struct. I've already provisioned glibtop_cpu for 32 CPU, that makes sizeof ~ 2KiB.

ABI vs. API compatibility - Jeff Licquia

Jeff Licquia — Tue, 22 Apr 2008 15:04:22 +0200

You could start using symbol versioning, and provide both.

ABI vs. API compatibility - Mart Raudsepp

Mart Raudsepp — Tue, 22 Apr 2008 14:20:00 +0200

Looks like that duplicated guint64 could fit a pointer that could point to a new struct with more padding. However, I'm wondering what's the point of this public structure - wouldn't separate function APIs for a set of these be more ABI proof? if that's a good idea, could just not expose PSS in that struct at all and introduce some new API for this, say glibtop_proc_get_pss. Then again, I assume it's all retrieved in one go and that would reduce efficiency when one needs to call get_pss, get_rss and so on in a row?
If you need to stick with a struct, it might be a good idea to at some point introduce a new one that has some padding available for future expansion and a new function, say glibtop_get_proc_mem2 (yes, need a better name) that returns it, having library users that need PSS information convert to the API and depend on the new libgtop version.
Sorry, just thinking out loud, maybe something useful

ABI vs. API compatibility - Rob

Rob — Tue, 22 Apr 2008 14:06:55 +0200

Well, all these options are ABI breaking - the 'break the API' options also break ABI, just subtly. which is worse, as its not obvious to developers or package maintainers that something has changed.
IMHO, the best option is to deprecate glibtop_get_proc_mem and add a new function (say glibtop_get_process_usage or such) that takes a pid and an enum value for which field to return.

ABI vs. API compatibility - Murray Cumming

Murray Cumming — Tue, 22 Apr 2008 14:03:37 +0200

If it's this simple then you can just add a new function that returns a new struct, and deprecate (not break) the old one.

Power management failure - Calum

Calum — Thu, 21 Feb 2008 15:49:28 +0100

Watching Extreme Makeover makes me go "peeeeeeeeeeeewwwwwwwwwwwww", too. Only in America do people think veneers look like real teeth...

Power management failure - Benoît Dejean

Benoît Dejean — Thu, 21 Feb 2008 12:18:41 +0100

Yep there are bugs like http://bugzilla.gnome.org/show_bug.... and http://bugzilla.gnome.org/show_bug.... . But i'm sure it's really related since i already know there are some problems with hal/s2ram.

Power management failure - Rui

Rui — Thu, 21 Feb 2008 11:47:08 +0100

Yep, gnome-power-manager isn't doing what it's told on my Fedora 8 laptop either. Maybe there's a bug reported about it somewhere already.

bootparam mem=128M - Benoît DEJEAN

Benoît DEJEAN — Mon, 26 Nov 2007 09:09:29 +0100

I know that GNOME 2.6 would run almost fine with 128MiB. But that was years ago, i'm talking about 2.20.

bootparam mem=128M - Scott

Scott — Sun, 25 Nov 2007 22:14:50 +0100

My wife runs GNOME on a laptop with 128MB of RAM---she usually is running firefox and abiword on top of that!

bootparam mem=128M - mike

mike — Sun, 25 Nov 2007 21:21:15 +0100

Remind us on the 7th please

(and write a guide for newbies :D)

most import: disable your gnome-panels before logging in ^^

bootparam mem=128M - AdamW

AdamW — Sun, 25 Nov 2007 20:27:08 +0100

I ran GNOME on a P2/450 with 128MB of RAM full time from 2.4 to 2.12. It was slow, but generally worked fine.

bootparam mem=128M - Havoc

Havoc — Sun, 25 Nov 2007 18:55:50 +0100

Finishing just a short list of stuff might have a big impact: dconf/gsettings, gvfs, and nicer dbus-glib bindings including single instance app support. Those things are the last barriers to dropping big piles of old library code, and the people working on them could probably use help testing (and porting apps).

bootparam mem=128M - Philip

Philip — Sun, 25 Nov 2007 18:10:36 +0100

I've got Fedora 8 running on my old Amilo M laptop with 128MiB of RAM. I've removed the services I don't need as well as quite a few other processes, but I haven't had to be excessive in my pruning, and it does run OK (although definitely not brilliantly).

redundant UI - Steve

Steve — Sat, 11 Aug 2007 01:55:23 +0200

This has been the topic of quite some debate, recently! I mentioned it in a blog post (http://www.stevenbrown.ca/blog/arch...) and on the developer's mailing list, and the lead developer just did a post exclusively about the status icon in the tabs.

http://www.pidgin.im/~seanegan/cgi-...

It's getting better.

redundant UI - Craig

Craig — Fri, 10 Aug 2007 19:53:09 +0200

I found this useless at first, and I admit it does take up some screen real estate, but I use aliases and some people have multiple screennames so I can identify if I'm talking to someone at work or home.

redundant UI - Alexandre Franke

Alexandre Franke — Fri, 10 Aug 2007 14:23:51 +0200

Maybe you should try using Aliases and Metacontacts, then you would understand the purpose of this

redundant UI - Kevin

Kevin — Fri, 10 Aug 2007 13:22:55 +0200

I find it quite useful but am surprised this feature is turned on by default without an option to turn it off. The feature is useful when you have several screennames grouped under 1 alias for a person. Under that case, the top name shows the alias, while the bottom one shows the screenname. It's useful in the case, but not in others so they should really have an option to turn it off.

redundant UI - fct

fct — Fri, 10 Aug 2007 12:35:58 +0200

I wrote a post in ubuntuforums about the new Pidgin:

http://ubuntuforums.org/showpost.ph...

I don't like the way pidgin is "evolving".

redundant UI - iain

iain — Fri, 10 Aug 2007 12:06:27 +0200

I was thinking the same thing as well.

redundant UI - Jeff Waugh

Jeff Waugh — Fri, 10 Aug 2007 11:59:49 +0200

Funny, I made a similar screenshot earlier this week too!

http://www.gnome.org/~jdub/2007/pid...

redundant UI - Benoît DEJEAN

Benoît DEJEAN — Fri, 10 Aug 2007 11:17:44 +0200

xchat-gnome merges consecutive messages from the same contact if they are close enough in time. This is a simple but space-saving feature.

redundant UI - boke

boke — Fri, 10 Aug 2007 10:53:00 +0200

I felt exactly the same when trying it yesterday.

You can turn off the second one in the preferences but then you lose the buddy icon...

redundant UI - tm

tm — Fri, 10 Aug 2007 10:40:15 +0200

yeah, the new pidging kicks ass in this respect
and quite a lot of green balls also, eh?

redundant UI - mrroboto

mrroboto — Fri, 10 Aug 2007 10:01:08 +0200

yeah, you're right. that's the first thing i thought using pidgin!

desklets - Flecko

Flecko — Sat, 30 Jun 2007 00:43:43 +0200

No offense to the gdesklet folks, but gdesklets is not good software. I tried to love it for years, but it develops at an incredibly slow pace, is extremely buggy, and is prone to breakage. I had high hopes that gdesklets would get better with time, but it doesn't seem that way. (And before you tell me to go help them, I'm not a Python coder, and never will be.) Thats not to say that this new Moonlight desklets thing is the answer, but I wouldn't use gdesklets now anyways.

That being said, sorry to be negative. If gdesklets is improved, I will absolutely make sure I say so and give it a try, but I can't recommend it to anyone as it is.+

Filesystem ACL - erik

erik — Fri, 29 Jun 2007 11:18:11 +0200

It's sad but it will take still years until ACL stuff will be used on free desktops, even despite the huge advantages over the ancient traditional way.

desklets - Jeff Schroeder

Jeff Schroeder — Thu, 28 Jun 2007 22:05:16 +0200

gdesklets also suffers from a mostly dead upstream, memory leaks, and made code.

Ask pyguy, the guy who wrote gdesklets.

desklets - Miguel de Icaza

Miguel de Icaza — Thu, 28 Jun 2007 18:53:58 +0200

Ah, that is a shame.

Anyways, I have posted a blog entry in my blog that explains why we are doing this. Basically: we want to toy, experiment and learn.

And we have a very nice platform that *we* like. Others might not like it, others might prefer SuperKaramba, gDesklets or to run a plain X server with twm. But like with language taste you cant really force the same on everyone.

miguel.

desklets - erik

erik — Thu, 28 Jun 2007 18:38:41 +0200

gDesklets failed. Completely.

Most of the desklets are really buggy. They also do not know about themeing. Meaning that they are bolted to some specific gtk/gnome themes etc, and you must use only the ones from the same set. And there are many sets, of bad quality. Bugs, lack of features, ..

Blah. gDesklets is a miserable failure, one of the worst I have ever seen on open source.

desklets - Jon

Jon — Thu, 28 Jun 2007 18:21:23 +0200

It's just NIH syndrome.

desklets - Benoît DEJEAN

Benoît DEJEAN — Thu, 28 Jun 2007 18:18:13 +0200

Hum, sorry Miguel, i don't know what happened. I can't see your comment anywhere.

desklets - Miguel de Icaza

Miguel de Icaza — Thu, 28 Jun 2007 17:56:59 +0200

Odd. I had a long post explaining our position on innovation and Moonlight desklets and it got deleted.

Maybe a database corruption issue?

desklets - anonim

anonim — Thu, 28 Jun 2007 17:53:08 +0200

yet another desklet technology... the fun about them is the hability to do desklets quick and easy, and that they would work everywhere. With so many different frameworks I don't think it's going to be easy... At least kde and gnome could get a freedesktop spec and both plasma & gdesklets implement them.

desklets - Benoît DEJEAN

Benoît DEJEAN — Thu, 28 Jun 2007 17:12:28 +0200

Benjamin > but gdesklets does exactly that ! You can even do simpler : ship the XML UI + some python scripting within the same XML file. Easy to get desklets. And you can use gdesklets with gnomevfs i.e. gdesklest http://...

Etienne > Moonlight is a demo ... so give you back your "It's not even part of Gnome desktop"

I don't want to ad for anything, but some people think that the SomethingLight approach is new. It's not. There are already many popular desklets engine, gdesklets being the more GNOMEish.

desklets - Benjamin Otte

Benjamin Otte — Thu, 28 Jun 2007 16:59:09 +0200

There's one huge advantage in using Flash or Silverlight for desklets: You can download new ones from the web and have them run in a sandboxed environment without them being able to do evil things.

That's about the cool things. The rest is just "we need a way to pimp our cool technology."

desklets - bersace

bersace — Thu, 28 Jun 2007 16:37:35 +0200

Hi,

You're right, but gdesklet needs more love. It's not even part of Gnome desktop :s. I'm pretty sure MacSlow could do some great job on it !

Étienne.

desklets - Ceasar

Ceasar — Thu, 28 Jun 2007 16:34:41 +0200

Not to mention it means another opportunity to look good in front of Microsoft...

desklets - Miguel de Icaza

Miguel de Icaza — Thu, 28 Jun 2007 16:33:26 +0200

Hey!

We know about gdesklets, but we want to build our own because building them with XAML and C# is quite fun.

Miguel.

we need distributed control system - Benoît DEJEAN

Benoît DEJEAN — Mon, 25 Jun 2007 11:32:36 +0200

No James, this isn't enough. I'm already doing it with git, and it just doesn't work. With this kind of work, you end up pushing again and again ... and upstream just can't merge.

we need distributed control system - James

James — Sun, 24 Jun 2007 13:38:34 +0200

You might want to use bazaar!

By installing the subversion bzr plugin, you can:

bzr clone http://path/to/svn

then when you want to merge, call

bzr pull

and to publish your changes

bzr push sftp://path/to/public/html

we need distributed control system - jmmv

jmmv — Thu, 21 Jun 2007 23:22:52 +0200

Jeff: It may be completely reasonable for *you* because you *already* have access to the repository. But those who don't (such as me) can really take advantage of a DVCS. You have to be on this side to understand the problems that arise; otherwise it's hard to explain. DVCS break the traditional "gain commit access" methodology, and all the elitism behind it. But anyway, and as Benoit already said, this is not the place to discuss whether DVCS are better or not.

we need distributed control system - Benoît Dejean

Benoît Dejean — Thu, 21 Jun 2007 23:18:23 +0200

Andrew > Thanks, stg is a very smart tool.

we need distributed control system - Jeff Waugh

Jeff Waugh — Thu, 21 Jun 2007 22:07:16 +0200

SVN is completely reasonable for a centralised mainline branch (and a project like GNOME does need a clear central mainline). With tools like git-svn and bzr-svn, it's very easy to branch into DVCS land and commit back to SVN. So, don't cry about GNOME's use of SVN -- use the tools that exist out there to make it work better for you!

we need distributed control system - Uzytkownik

Uzytkownik — Thu, 21 Jun 2007 16:36:52 +0200

I've never used git so I can't compare but bazaar (http://bazaar-vcs.org/) is great (it also have a svn plugin) - I prefere it over svn and cvs.

we need distributed control system - jmmv

jmmv — Thu, 21 Jun 2007 16:33:42 +0200

Murray: Sure the VCS cannot simplify the creation of big branches. But by using a DVCS it is extremely easy *for other people* to keep their personal branch in sync with the main one. It's not your job (as the maintainer) to do the syncing; it's the developers one. And with a DVCS it is much, much easier for them. Plus if you want (again, as the maintainer), you can merge the foreign branch (after a review, be it based on patches or whatever) and keep the *development history* for that foreign branch.

Let me suggest this talk about Git, given by Linus at Google: http://www.youtube.com/watch?v=4Xpn...

You have to be working "on the other side" (i.e. without access to the main project's repository) to really value the advantages of a DVCS.

we need distributed control system - Benoît DEJEAN

Benoît DEJEAN — Thu, 21 Jun 2007 15:56:42 +0200

It's a myth that DVCS are harder to use. A DVCS is not a toy for angry kids like me. I'm not having that discussion, sorry that you don't understand all the opportunities brought by DVCS. I think SVN sucks.

we need distributed control system - Murray Cumming

Murray Cumming — Thu, 21 Jun 2007 15:35:41 +0200

> If someone wants to work a new feature, would you be
> OK if he would throw you a 10Kline patch

That doesn't happen very often. No VCS can make it easy to do big branches. Big branches are fundamentally difficult to merge.

When you do need to branch, I'm currently fairly happy with how svn does it. People have used bzr to branch from my svn, though I guess that doesn't make it so easy to merge back.

Most work is just small patches. I am very afraid of making life difficult for all those people, doing normal work, just because one or two people would like something that has a special feature.

we need distributed control system - Benoît DEJEAN

Benoît DEJEAN — Thu, 21 Jun 2007 14:32:53 +0200

stgit looks fine, but svn + git-svn + stgit is too much.

Let's just switch to git. Moreover, managing patch is only good if you don't care about the revision log. A patch is the merge of all your work. On the other hand, when you merge, you get everything.

The problem is the upstream VCS and everyone seems to think that it's going to be solved by stacking again and again on the contributor side. This is just wrong. Managing patches feels quite stupid when you're used to use branch and do cherrypicking. cherrypicking makes patches useless i think.

we need distributed control system - Andrew Sutherland

Andrew Sutherland — Thu, 21 Jun 2007 13:51:02 +0200

Have you tried using stacked git? (stgit) It's like quilt for git, and allows you to work in a patch-centric way. Basically, your current 'state' in a stgit-managed branch is managed in a bunch of patches, which are then applied in series.

Any changes you make are applied to the top-most active patch in your 'stack' when you invoke 'stg refresh'. The revision history of each time you do a refresh is there too, and 'qgit' (the best git GUI I've seen) understands the patches and their intermediary state.

The result is that you are always breaking things up into patches as you would submit them in a single unified workspace. The other option I could think of (but don't have a lot of experience with) is having one branch or workspace per patch you would want to submit, merging things across between them as desired.

The one downside to stgit in my mind is that when you push/pop patches onto the active stack (or just re-order them), timestamps of affected files may change even if their contents do not, which will confuse most build systems...

we need distributed control system - Benoît DEJEAN

Benoît DEJEAN — Thu, 21 Jun 2007 13:08:22 +0200

Murray > forking and branching are obviously not the same. I'am talking about how hard it is to merge when your VCS sucks at it. If someone wants to work a new feature, would you be OK if he would throw you a 10Kline patch ? And that guy would certainly quit because maintaining a 10K line patch against upstream is very very hard. Now it would be awesome if he could often pull/merge from upstream to update his new branch. In the end, to get the feature from upstream, you'd just have to pull from his branch. Or you could cherry-pick.

Jeff > git-svn does the opposite. And merging inside git-svn just blows the full revision history. And if everyone has to setup git-svn on his side, let's move to git/mtn/hg/etc

jmmv > I'm glad that you read that post. I was really thinking about your job. I know NetBSD has a patchset for GNOME. It's hard for you to maintain. And it's hard for me to get your patch. With DVCS, we could happily pull/merge/cherrypick from each other.

we need distributed control system - jmmv

jmmv — Thu, 21 Jun 2007 12:32:31 +0200

Wholeheartedly agreed. I, as a long-term maintainer of GNOME on NetBSD (not very active now, though), would really welcome a trivial way to maintain my portability fixes before they get integrated (which sometimes never happens, but that's another frustrating story). A DVCS could certainly simplify this.

Murray: It's OK if you want to see patches instead of a URL... it's the *tool* who should automatically be able to generate those patches. But the *developer* should be able to manage them more easily, and that is basically what a DVCS offers.

we need distributed control system - Jeff Schroeder

Jeff Schroeder — Thu, 21 Jun 2007 12:13:25 +0200

sudo apt-get install git-svn

we need distributed control system - Murray Cumming

Murray Cumming — Thu, 21 Jun 2007 12:07:26 +0200

If you were a contributor to my project, I'd want to see patches, not a URL of some fork of my project, even if the VCS made it relatively easy to merge.

And if it was my project, I'd rather not see you suggesting that people use a fork of it.

a system crash ruined my weekend :/ - Nermal

Nermal — Tue, 05 Jun 2007 13:09:43 +0200

Try ALT-SYREQ-S-U-B to try and reboot cleanly in such a situation

git-merge vs. git-log - Benoît Dejean

Benoît Dejean — Mon, 04 Jun 2007 21:11:26 +0200

I don't want the summary : i would like all the revisions from a branch to be merged as they are. But instead, i can only see one big commit "Merge branch X" with a cumulative diff ...

git-merge vs. git-log - Peter

Peter — Mon, 04 Jun 2007 13:42:05 +0200

I'm not sure what you are trying to do, but have you looked at "merge.summary" in man git-config?

a system crash ruined my weekend :/ - Benoît DEJEAN

Benoît DEJEAN — Mon, 04 Jun 2007 09:49:24 +0200

well, try gnomevfs and cry :/

git-merge vs. git-log - Benoît DEJEAN

Benoît DEJEAN — Mon, 04 Jun 2007 09:48:32 +0200

Maybe you are right, maybe git-svn is actually destroying the merge history :/

git-merge vs. git-log - S.F.

S.F. — Mon, 04 Jun 2007 00:01:08 +0200

Well, as I see it, it would be hard, because SVN per se doesn't support "real merges" (a merge is a simple patch).

Maybe you could use git-rebase, which will "re-commit" all the commits of the merged branch into the current one, thus keeping the history.

a system crash ruined my weekend :/ - Ryan

Ryan — Sun, 03 Jun 2007 23:45:58 +0200

The status of samba client on Linux is absolutely horrendous. Feature support isn't there... stability isn't there... and performance certainly isn't there. I'm lucky to pull 12MB/s over gigabit using {cifs|smb}mount.

memory upgrade - K

Mon, 23 Apr 2007 08:31:31 +0200

you might be living in a cave dude, look around you maybe?

memory upgrade - ken

ken — Sat, 21 Apr 2007 02:33:36 +0200

"I personally am switching to the desktop which uses the object oriented language"

There's a Smalltalk desktop?

memory upgrade - Benoît Dejean

Benoît Dejean — Fri, 20 Apr 2007 19:12:25 +0200

You may then want to open a bug against system-monitor.

memory upgrade - Bob

Bob — Fri, 20 Apr 2007 14:34:52 +0200

Me too ! Currently evolution -> Memory : 5.6MB

memory upgrade - Benoît DEJEAN

Benoît DEJEAN — Fri, 20 Apr 2007 14:09:04 +0200

I am talking about private_dirty + X server memory which is displayed in "Memory" column of system-monitor

memory upgrade - Bob

Bob — Fri, 20 Apr 2007 14:05:46 +0200

Depends if you count shared or not…

memory upgrade - Benoît DEJEAN

Benoît DEJEAN — Fri, 20 Apr 2007 13:15:46 +0200

Bob > ahahahhaah. I don't know how you get your stats, but they are plain wrong...

memory upgrade - Bob

Bob — Fri, 20 Apr 2007 11:19:58 +0200

I hope that the GMAE project will lead us to a reduced memory usage. Am I dreaming ?

gnome-terminal 20MiB ? 2.2MiB with ten tabs
evo is just 6.3MiB
Tou've got an old GNOME version ? 2.14 ?

memory upgrade - Benoît DEJEAN

Benoît DEJEAN — Fri, 20 Apr 2007 11:08:50 +0200

This is about my laptop. I reboot it only for kernel upgrades. Having 300-400MiB of swap means constant disk trashing. There's nothing wrong with my computer : application just take to much memory. Many of my friends experience the same issues.

Come on, my iceweasel with no plugin, started a week ago and only a couple of tabs takes 114,3MiB privated_dirty. Evolution is 35MiB. Xorg 55MiB. liferea 30MiB. gnome-terminal 20MiB. Nautilus 7MiB. etc You just can't run this with 256MiB of RAM.

memory upgrade - Gilles Dartiguelongue

Gilles Dartiguelongue — Fri, 20 Apr 2007 10:35:48 +0200

Not sure what you are doing with your computer but even if I agree that running gnome with 256Mo of RAM is a little to low, 512 is largely enough for epiphany (~tabs), tracker, evolution, deskbar-applet, terms.

FYI, I'm running this on a PIII 500 with only 128Mo of swap (yes that means my box would die with your numbers :p).

memory upgrade - C

Fri, 20 Apr 2007 10:08:47 +0200

You're not alone with that kind of gnomish performance. There is one less reason to use gnome since it has grown too slow.
I personally am switching to the desktop which uses the object oriented language, it really can't be much slower than this. At least the features are not crippled down to someones grandma's level.

memory upgrade - Bob

Bob — Fri, 20 Apr 2007 09:04:32 +0200

"starting a new terminal now only takes 1s where it lasted up to 10s !"

There is something wrong with your computer ! It takes one second max to do this with my 512MB.

memory upgrade - Diego

Diego — Fri, 20 Apr 2007 00:16:52 +0200

You aren't serious, are you?

What the hell does eat so many memory? 1.25 GB is sure better than 512, but with 512 it shouldn't take 15 seconds to switch evolution functions...unless evolution is a memory pg, which it is But it's easier to switch from evolution than adding more ram.

memory upgrade - Eugenia

Eugenia — Thu, 19 Apr 2007 23:53:24 +0200

Hmm, I don't know what is wrong with your system, but you might want to reboot more often or something or check your mem usage in general for strayed processes... 512 MBs is enough for normal usage with Linux (and Windows, and OSX). That includes firefox, evolution, terminals, rhythmbox open at the same time, and occasionally some light OOo open at the same time too.

Up to last year I even ran Arch Linux at a 128 MBs laptop without major problems (1-2 apps open at the same time, optimized services), so I would imagine something heavier, like fedora/suse/ubuntu will do fine on a 512 MB machine. I have two laptops running ubuntu with 512 MBs each and they are fine...

webcam integration - Benoît Dejean

Benoît Dejean — Mon, 12 Mar 2007 23:30:41 +0100

This evolution bug is the first step, but i was talking about webcam integration into evolution. You don't want extra storage for contact photo : you only want to add the photo. So yes, evolution needs to display the photo, but it also has to store it. And to add a photo, you should either be able to select it from a file or directly use the webcam.

webcam integration - Gilles Dartiguelongue

Gilles Dartiguelongue — Mon, 12 Mar 2007 17:33:43 +0100

And the relevant bugzilla entry

http://bugzilla.gnome.org/show_bug....

webcam integration - mike

mike — Mon, 12 Mar 2007 17:15:20 +0100

Look at this link as kikdonk already said.

http://raphael.slinckx.net/blog/200...

webcam integration - kikidonk

kikidonk — Mon, 12 Mar 2007 12:58:40 +0100

Expect something quite soon, i programmed some kind of photo booth clone with gstreamer and gtk to be used in a public fair. I expect to release a first version next weekend when it survived the crowd test

libsexy bugs - Christian Hammond

Christian Hammond — Fri, 02 Mar 2007 21:48:02 +0100

I'm deferring that to David Trowbridge, who is responsible for that module. I think the plan though is to deprecate that widget. It wasn't really complete, and we haven't found a backtrace that's been very useful. If you happen to have one, though, we'd love to see it.

gnome-system-monitor 2.17 has been compromised - Benoît

Benoît — Thu, 01 Mar 2007 08:53:14 +0100

Quand tu ne sais pas pas du tout qui est la personne, quand tu n'as reçu aucun mail d'approbation ni rien, c'est un problème. Moi je me lève le matin, je vois qu'une release a été faite pendant que la nuit, je n'ai aucune info dessus, j'agite le drapeau rouge.

gnome-system-monitor 2.17 has been compromised - liberforce

liberforce — Wed, 28 Feb 2007 23:37:19 +0100

Tout cela vient d'une stupide confusion dan la précipitation pour essayer d'avoir un module ok pour la release... Je trouve que le ton indigné est franchement exagéré. Il y a eu boulette, certes, mais ce n'est pas comme si un pirate avait fait une release malveillante...

gnome-system-monitor 2.17 has been compromised - jk

jk — Wed, 28 Feb 2007 20:45:49 +0100

Wow on se croirait sur une mailing list debian... Franchement sans te connaître et en lisant ça tu fais un peu "control freak" paranoiaque

gnome-system-monitor 2.17 has been compromised - Me

Me — Wed, 28 Feb 2007 19:42:01 +0100

Get a life. You screwed up and someone fixed it. You should be thankful.

gnome-system-monitor 2.17 has been compromised - Yanko Kaneti

Yanko Kaneti — Wed, 28 Feb 2007 17:58:40 +0100

If it were me I'd rather _thank_ mariano and kmaraas for fixing stuff that was obviously problematic in the "official" release.

gnome-system-monitor 2.17 has been compromised - rangzen

rangzen — Wed, 28 Feb 2007 13:20:55 +0100

Autant sur le SVN, y a rien de particulier, autant dans le tarball ... Y en a pour une semaine à vérifier le m4 :/

gnome-system-monitor 2.17 has been compromised - andre

andre — Wed, 28 Feb 2007 13:02:51 +0100

and here's the explanation:
http://mail.gnome.org/archives/rele...

"compromised" is a strong word. this isn't binary stuff that we're talking about, a diff shouldn't be that hard?

evolution + bogofilter - Mikhail Zabaluev

Mikhail Zabaluev — Mon, 19 Feb 2007 10:22:22 +0100

Thanks Ritesh for the link above; I'm the author of that code. See, I thought that running Bogofilter was simple enough to just take a sample plugin in C and write up the executable launch code.
The plugin has also made it to Ubuntu.

evolution + bogofilter - Ritesh Khadgaray

Ritesh Khadgaray — Sun, 18 Feb 2007 16:54:29 +0100

evolution bogofilter plugin
http://people.altlinux.ru/~mhz/soft...

ps : a part of fedora extras.