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.