Log in

No account? Create an account

Tue, May. 3rd, 2005, 11:19 am
Ian Murdock

I received over 80 e-mails complaining about Ian's post about Componentized Linux RC1, most suggesting that it was using Planet Debian as a medium for sending out press releases. Personally, I enjoyed Ian's posts and didn't have any particular problem with them being on Planet.

Ian's blog was removed with a comment left in the config file asking for a feed without the advertising content; being 12,000 miles away from home, without any local network (I'm borrowing bandwidth off an anonymous NETGEAR benefactor to type this), and with my home network unreachable (it appears dead) I hadn't had a chance to compose an email yet.

When I do get online again, I not only get mobbed but have some incredibly outrageous accusations made against me. I'm sure if you read Planet Debian, some of them will still be visible on the blogs of those who made them. I don't expect to receive any apologies, that's just the way Debian works.

So I've decided that I'm not going to maintain Planet Debian any longer, Mako has offered to do so instead. Direct your requests, problems and complaints at him now.

Tue, Aug. 17th, 2004, 08:17 pm
Dear Auntie Planet...

My partner complains every time I stab him with a fork, is he being unreasonable or am I just not doing it right?

Tue, Aug. 10th, 2004, 11:02 pm
Squash makes Keybuk achey

Another long day today, woke up deciding that the squash last night with Thom was perhaps a bad idea and another hour in bed won over a pre-breakfast visit to the gym.

I ended up being the first dish of the day again, yesterday with my almost Nat-like "demo coded the night before" and today with a BOF to gain insights on what our distro developers would like from the infrastructure management tools.

(Yes, Mark is wearing a "First African In Space" T-Shirt there.)

Just enough of a break to write up what we discussed when joined in the BOF on improving package management tools. Some interesting ideas put forward by a few people, hopefully once the current mad rush is out of the way I'll get some time to work on dpkg and do some cool new development there, it really needs it after all.

Mon, Aug. 9th, 2004, 10:51 pm
Brocolli is a Weapon of Mass Destruction

So the first day of the Canonical Conference is now over, it was pretty successful I think, mostly a day of planning for the two weeks ahead and setting the agenda.

It's definitely going to be a fun couple of weeks, long days of working though, but the hotel's got plenty of ways to unwind. Got pleasantly thrashed at Squash by Thom May before dinner.

Thu, Aug. 5th, 2004, 11:02 am
Canonical Conference

The two-week Canonical Conference starts on Monday, it's going to be a pretty intense time but should be great fun. We're often mistakenly called a UK company, in fact our staff are spread out across the world, and we've just as many Australian staff as we've got UK ones. Our company conferences are when we all get together in the same place for some high-bandwidth interaction rather than on IRC.

It's really refreshing to work for a company that gets why community involvement is so important. Our mini-conference at Debconf4 was open to anyone who wanted to drop in and we've extended an open invite to anyone else who wants to join in.

Mon, Aug. 2nd, 2004, 10:25 am
Evolution Data Server

Because I'm not going to let this lie ... here's the memory map table of evolution-data-server running on my machine.

08048000    184K r-x--  /evolution-data-server-1.0
08076000      8K rw---  /evolution-data-server-1.0
08078000    660K rw---    [ anon ]
b3bed000    272K rw---    [ anon ]
b3c31000      4K -----    [ anon ]
b3c32000   8192K rwx--    [ anon ]
b4434000      4K -----    [ anon ]
b4435000   8192K rwx--    [ anon ]
b4c35000      4K -----    [ anon ]
b4c36000   8192K rwx--    [ anon ]
b5436000      4K -----    [ anon ]
b5437000   8192K rwx--    [ anon ]
b5c37000      4K -----    [ anon ]
b5c38000   8192K rwx--    [ anon ]
b6438000      4K r----  /libc.mo
b6439000     32K r-x--  /libgcc_s.so.1
b6441000      4K rw---  /libgcc_s.so.1
b6442000    632K r-x--  /libstdc++.so.5.0.6
b64e0000     88K rw---  /libstdc++.so.5.0.6
b64f6000     20K rw---    [ anon ]
b64fb000     28K r-x--  /libfam.so.0.0.0
b6502000      4K rw---  /libfam.so.0.0.0
b6510000     28K r-x--  /libfile.so
b6517000      4K rw---  /libfile.so
b6519000      4K -----    [ anon ]
b651a000   8192K rwx--    [ anon ]
b6d1a000      4K rw---    [ anon ]
b6d20000      4K -----    [ anon ]
b6d21000   8192K rwx--    [ anon ]
b7529000     16K r----  /evolution-data-server-1.5.mo
b7530000     32K r-x--  /libnss_files-2.3.2.so
b7538000      4K rw---  /libnss_files-2.3.2.so
b7539000     32K r-x--  /libnss_nis-2.3.2.so
b7541000      4K rw---  /libnss_nis-2.3.2.so
b754f000     28K r-x--  /libnss_compat-2.3.2.so
b7556000      4K rw---  /libnss_compat-2.3.2.so
b7565000   1556K r----  /locale-archive
b76eb000      8K rw---    [ anon ]
b76ed000    684K r-x--  /libasound.so.2.0.0
b7798000     16K rw---  /libasound.so.2.0.0
b779c000     76K r-x--  /libsasl2.so.2.0.18
b77af000      4K rw---  /libsasl2.so.2.0.18
b77b0000      4K rw---    [ anon ]
b77b1000     16K r-x--  /libcrypt-2.3.2.so
b77b5000      4K rw---  /libcrypt-2.3.2.so
b77b6000    156K rw---    [ anon ]
b77dd000   1184K r-x--  /libc-2.3.2.so
b7905000     36K rw---  /libc-2.3.2.so
b790e000      8K rw---    [ anon ]
b7910000    500K r-x--  /libglib-2.0.so.0.400.4
b798d000      4K rw---  /libglib-2.0.so.0.400.4
b798e000     52K r-x--  /libpthread-0.60.so
b799b000      4K rw---  /libpthread-0.60.so
b799c000     12K rw---    [ anon ]
b799f000     16K r-x--  /libgthread-2.0.so.0.400.4
b79a3000      4K rw---  /libgthread-2.0.so.0.400.4
b79a4000      8K r-x--  /libdl-2.3.2.so
b79a6000      4K rw---  /libdl-2.3.2.so
b79a7000     12K r-x--  /libgmodule-2.0.so.0.400.4
b79aa000      4K rw---  /libgmodule-2.0.so.0.400.4
b79ab000    224K r-x--  /libgobject-2.0.so.0.400.4
b79e3000      4K rw---  /libgobject-2.0.so.0.400.4
b79e4000      4K rw---    [ anon ]
b79e5000     28K r-x--  /libpopt.so.0.0.0
b79ec000      4K rw---  /libpopt.so.0.0.0
b79ed000    280K r-x--  /libORBit-2.so.0.0.0
b7a33000     36K rw---  /libORBit-2.so.0.0.0
b7a3c000      4K rw---    [ anon ]
b7a3d000     16K r-x--  /libORBitCosNaming-2.so.0.0.0
b7a41000      4K rw---  /libORBitCosNaming-2.so.0.0.0
b7a42000     72K r-x--  /libbonobo-activation.so.4.0.0
b7a54000     12K rw---  /libbonobo-activation.so.4.0.0
b7a57000     56K r-x--  /libresolv-2.3.2.so
b7a65000      4K rw---  /libresolv-2.3.2.so
b7a66000      8K rw---    [ anon ]
b7a68000     24K r-x--  /librt-2.3.2.so
b7a6e000      4K rw---  /librt-2.3.2.so
b7a6f000     64K r-x--  /libz.so.
b7a7f000      4K rw---  /libz.so.
b7a80000     12K r-x--  /libgpg-error.so.0.1.2
b7a83000      4K rw---  /libgpg-error.so.0.1.2
b7a84000      4K rw---    [ anon ]
b7a85000     68K r-x--  /libnsl-2.3.2.so
b7a96000      4K rw---  /libnsl-2.3.2.so
b7a97000      8K rw---    [ anon ]
b7a99000    284K r-x--  /libgcrypt.so.7.3.0
b7ae0000     20K rw---  /libgcrypt.so.7.3.0
b7ae5000     60K r-x--  /libtasn1.so.2.0.7
b7af4000      4K rw---  /libtasn1.so.2.0.7
b7af5000    364K r-x--  /libgnutls.so.10.1.4
b7b50000     20K rw---  /libgnutls.so.10.1.4
b7b55000    136K r-x--  /libm-2.3.2.so
b7b77000      4K rw---  /libm-2.3.2.so
b7b78000    936K r-x--  /libxml2.so.2.6.11
b7c62000     32K rw---  /libxml2.so.2.6.11
b7c6a000     40K rw---    [ anon ]
b7c74000    324K r-x--  /libbonobo-2.so.0.0.0
b7cc5000     40K rw---  /libbonobo-2.so.0.0.0
b7ccf000    196K r-x--  /libgconf-2.so.4.1.0
b7d00000     12K rw---  /libgconf-2.so.4.1.0
b7d03000    352K r-x--  /libgnomevfs-2.so.0.700.3
b7d5b000     20K rw---  /libgnomevfs-2.so.0.700.3
b7d60000    132K r-x--  /libaudiofile.so.0.0.2
b7d81000     12K rw---  /libaudiofile.so.0.0.2
b7d84000     32K r-x--  /libesd.so.0.2.29
b7d8c000      4K rw---  /libesd.so.0.2.29
b7d8d000     76K r-x--  /libgnome-2.so.0.702.0
b7da0000      4K rw---  /libgnome-2.so.0.702.0
b7da1000      4K rw---    [ anon ]
b7da2000     44K r-x--  /liblber.so.2.0.130
b7dad000      4K rw---  /liblber.so.2.0.130
b7dae000    196K r-x--  /libldap.so.2.0.130
b7ddf000      4K rw---  /libldap.so.2.0.130
b7de0000    756K r-x--  /libedataserver.so.3.2.0
b7e9d000     20K rw---  /libedataserver.so.3.2.0
b7ea2000    536K r-x--  /libecal.so.6.1.1
b7f28000     60K rw---  /libecal.so.6.1.1
b7f37000     12K rw---    [ anon ]
b7f3a000    148K r-x--  /libsoup-2.2.so.3.2.0
b7f5f000      8K rw---  /libsoup-2.2.so.3.2.0
b7f61000     68K r-x--  /libegroupwise.so.3.0.0
b7f72000      4K rw---  /libegroupwise.so.3.0.0
b7f73000      4K rw---    [ anon ]
b7f74000    132K r-x--  /libedata-cal.so.5.1.2
b7f95000     12K rw---  /libedata-cal.so.5.1.2
b7f98000    160K r-x--  /libebook.so.8.0.1
b7fc0000     16K rw---  /libebook.so.8.0.1
b7fc4000     92K r-x--  /libedata-book.so.1.0.1
b7fdb000      8K rw---  /libedata-book.so.1.0.1
b7fea000      4K rw---    [ anon ]
b7feb000     84K r-x--  /ld-2.3.2.so
b8000000      4K rw---  /ld-2.3.2.so
bfffc000     16K rw---    [ stack ]
ffffe000      4K -----    [ anon ]
 total    70292K

As you can see, by far the largest number of maps are shared libraries code mapped into the address space. There's also some read-only data (such as the locale archive, which is one of the largest).

If your argument is that you don't want a GNOME application to load the GNOME libraries, well you're on crack. It's a GNOME application, it's written to use the GNOME libraries. A huge number of these are shared with other things so this isn't an issue unless you're just being silly.

So what's the rest of it? There's a small collection of 8MB anonymous executable maps, these aren't heap, these are the stacks of each thread. It's a copy-on-write overhead so it's a possible 8MB, not an actual 8MB (unless you manage to recurse so deeply you hit your stack limit).

Then we're left with a bunch of read/write data, most of these are backed by file to represent data taken directly from shared libraries of other files. There's a 16KB stack in there and finally a bunch of anonymous read/write data maps -- this is the heap, and if you total them up you'll see they only come to around 1MB.

Neither ps nor top give you an accurate idea of the memory usage of a process because they tell you the virtual memory size, which is not a useful indicator. I'm always surprised when people believe this is a good indicator, have you never tried adding up the totals?

Here's a quick thing to do that:

ps aux | awk '{if (NR > 1) print $5; if (NR > 2) print "+"} END { print "p" }' | dc

On my machine the total (which is in KB, remember) comes to over twice the available memory of my machine!

Sun, Aug. 1st, 2004, 05:01 pm
Memory again...

Uh, Erich, if eds loads every shared library and takes 80MB ... then the amount of memory you need for every other app is also 80MB, not 512MB.

79MB of that is shared with every other application loading the shared library, they all use the same copy.

Actually, the largest load time isn't anything to do with the size of the libraries, it's the symbolic relocation that needs to be performed -- this won't be any faster having loaded eds first.

GNOME do have a relatively slack attitude to memory management, but then memory *is* cheap these days. But you're vastly exaggerating it.

The GNOME footprint is 80MB, not 512MB. That's 432MB left for all your heap requirements, more than enough. In fact, on this GNOME-running machine with evolution, mozilla, xchat, gaim, etc. all running -- there's enough free memory that 280MB is being used for the page cache!

Sun, Aug. 1st, 2004, 11:41 am
Learn about Memory Usage, Please!

Erich thinks Evolution is hogging memory, it isn't!

Most of that 80MB of memory eds is using is shared between the various processes. On my machine it's actually using around 1MB of memory and that's with quite a large calendar loaded into it.

The alarm notifier is using 68MB? On my machine it's only actually using about 850KB.

These two could probably be shrunk a little by more efficient structure layout and perhaps a little fine-tweaking of what memory is allocated and what is shared.

Out of the rest of the memory you think Evolution is using, the largest chunk is actually libc6 and the locale archive, that's a block of memory shared by nearly every single process.

Next you'll be going on a crusade why X needs over 128MB of memory ... when the largest chunk of that is just your video card memory mapped directly into its address space.

Fri, Jul. 23rd, 2004, 02:13 am
Epson Printers

Lars, my Epson Stylus C82 has a similar affliction; when not used for a while the ink clots up and doesn't print very well.

On the front there's a button with an ink drop above it, normally used for telling the printer you want to change the ink cartridges. If you hold this down for three or four seconds, the printer will clean the head instead and let you print again.

I use my printer so rarely that I have to do this nearly every time.

Tue, Jul. 20th, 2004, 04:43 pm
General Resolution: Force AMD64 into Sasrge

I will be voting against this proposal, and urge everybody else to exercise their vote and do the same.


Because I utterly oppose using the GR system to make decisions like this. I'm not against having AMD64 in the archive, in fact I think it should be there, but forcing it through GR is just wrong.

Sensible debate and discussion, with decisions made by those who have earned the trust and respect to do so is the right way. The decision of when AMD64 should be in a release belongs in various hands, FTP Masters and the Release Managers most notably.

10 most recent