The Okular team has never been all that big. Recently we lost Pino as the maintainer. His reasons are his reasons, but I can't say I blame him. I can personally no longer tolerate the level of abuse that we're seeing on bug reports. The latest example is Wishlist item 157284

I'm unsubscribed from the okular-devel mailing list. I'm not going to be in #okular. I'll still look at XPS bugs if I notice them.

Today we enjoy 11th anniversary of disclosure of Microsoft's best business and development practices:

I recently had a crash that was hard to fix. Well, it IS hard to fix because I am still on it. It is again one of these "from the middle of nowhere" bugs KDE is so good in producing. I means those bugs that originate from a wrong-understood idea of automation. The programmer does not have to do anything because the framework will do it for him. Super. That leads to a problem if the framework does not do it correctly. The programmer will not see any way how to debug the problem at all and will have to become a framework-developer.

Recently, let's say in the past year, I saw a growing number of email messages on the KDE lists with the following content only:

+1

Do you want to write something about KDE's memory usage? Simple, just follow these steps:

1. Launch KDE.
2. Run some random tool for measuring memory usage, preferably top.
3. Pick a column you think you know what it means. If you can't decide, just pick one, preferably something with big numbers (big numbers look better, remember).
4. Complain that the numbers are way too big. For higher bonus, compare it to something else, preferably something that gets nowhere near KDE's usage of shared resources (=libraries, mostly, but not only).
5. ???
6. Profit!

Really, it's as simple as that. So many people do it, you can too. See, for example, this review of KDE4.3. I have nothing against the review itself, since, I admit, I mostly skimmed over it, only two things caught my attention. First one was getting it backwards who copied from who the filtering feature in Present Windows compositing effect, which slightly amused me, and second one was the part talking about resources, which didn't.

The first item there is about kioslaves supposedly staying running for way too long, and it's not interesting here (although I like how it says "I suspect", like if checking it for real and then creating a bugreport is way too much work). The second item is about KWrited taking, imagine it, 18M of memory, and the last one is about the nVidia libraries wasting a good amount of memory, again.

Checking the KWrited item (I guess I was curious, or maybe bored) showed me several things. First of all, I don't have any KWrited daemon - openSUSE has libutempter, which allows building KWrited just as a KDED module. So instead I took KAccess, which should get similar treatment and not run on every system when it's mostly useless. Looking at numbers in top showed resident memory usage (RSS) 40M and shared memory usage (SHR) 25M. That was interesting for several reasons, like 40M being quite a lot, even for shared usage (since resident memory usage includes also all shared stuff, and so it doesn't really mean that much), or the fact that unshared memory usage for a small daemon being 40M-25M=15M is just plain rubbish.

The 40M is actually easy to explain - it is loaded using kdeinit, so it includes all memory from the basic libraries that are preloaded by kdeinit and shared by everything it launches. That includes the ~10M unshared bonus from nVidia libGL libraries that kdeinit helps to share.

The seeming 15M of unshared memory was more interesting and strange. Checking /proc/PID/status confirmed that data of the process is nowhere near that and that there must be something wrong going on. Checking /proc/PID/smaps in details showed similar results, again nothing anywhere near 15M. It is also not nVidia, since the memory is marked as dirty, but shared. And then it suddenly was obvious. The kernel (since that is whose numbers top blindly repeats) doesn't consider dirty shared memory to be really shared. A major portion of the 15M is the position-fixing of the non-PIC nVidia libraries, and some of it is also memory taken by symbol-binding to libraries. If a shared memory is dirty, then it may be dirty, but it is still shared. It got dirty before kdeinit started forking off new processes for launching, so it must be shared. Checking with Exmap, the only memory tool I trust so far, confirms. It is still some memory taken (and still big enough for those who don't know which year it is), but it's much smaller than what it seemed like.

Now, no wonder pretty much nobody can get KDE's resource usage right, when both people don't understand it and tools report nonsense. As it is said, two wrongs don't make a right. Here, they usually just make only a bigger wrong.

So, John, I think I might know what you could add to KSysGuard, after all. You could try to make KSysGuard a memory measuring tool that, unlike the rest, doesn't suck and make people write nonsense about KDE's resource usage. The magic line, in bash terms, is:

Where PID is pid and TYPE is:

• Size - that, as http://ktown.kde.org/~seli/memory/analysis.html says, means next to nothing in practice, so if you use it, make sure to hide it well.
• Rss - resident memory usage, all memory the process uses. While somewhat interesting as the grand total, not really that good number on its own, as a good portion of it is shared with many other process. Put it somewhere in the back.
• Shared - (i.e. Shared_Dirty and Shared_Clean together), the total amount of memory shared, what would SHR in top be, if it wasn't broken. Not really that interesting, unless somebody wants to admire how good we are at reusing stuff.
• Private - (again, both Private_Dirty and Private_Clean), the memory of the process itself, its own memory that is not shared with anything. It is probably worth the second memory column, after Pss below.
• Swap - I guess it says something useful too, but with my machine's swap being pretty much useless, I can't quite say .
• References - with documentation for smaps not being what it should be (that is, existing), I can't quite say what it is, but I think it is for measuring statistics about how much memory a process accesses over a time. There seems to be a way to reset the number. For KSysGuard, probably useless. However, when trying to find out in kernel sources about it, I found a nice little gem, the next entry.
• Pss - this is the thing I love about Exmap. It is not as good as what Exmap can do, but it's good enough. It means, according to the sources, Proportional Set Size, and it is Rss adjusted for sharing. If a process has 1M private and 10M shared between 10 processes in total, Pss is 1+10/1=2M. In other words, this is the number that can take into account the fact that KDE applications massively share memory. This should be THE memory column in KSysguard.

I hope this can work out for KSysGuard. I am slightly worried that fetching all these numbers from kernel will take too much time, but that needs to be tried. But, if it will work, do we all now know what will be so special about KSysguard?

When people used to say that blogs are the new usenet, they meant that discussions and flamewars which used to happen on usenet newsgroups, now happen in blogs and their comment sections.

Some bloggers even use their new publishing channel for making inquiries, i.e. the famous and infamous "dear lazyweb" postings.

See? I wrote unconsciously even used "postings", not something like "personal log entry"!

Anyway.

I've come to the conclusion that there is another shift of media going on, this time a move away from mailing lists. I have to say that I haven't yet been able to determine where the usage shifted to, so in case you have ideas, please let me know.

It is probably also quite dependent on target audience because at least our developer mailing lists seem still to be used for questions, announcements and so on.
Since, as a free software community contributor, I am primarily a developer nowadays, I wasn't aware of this change in other areas of contributions.

For example about a month ago I sent an invitation to the two main Free Software Desktop projects, cunningly addressing their "external relationship" mailing lists (or what I percieved to be their most likely mailing list for promotional activities): GNOME's marketing-list and KDE's promo list (same posting on both links, called cross posting in the good old times).

Unfortunately, I have missed the memo about switching to a different communication channel, see above.

Or neither project has any interest in getting in touch with their Austrian users or just trying to attract Austrian contributors.

I know, I know! Even thinking about this possibility is absurd, it must be the change of communication channels.

So, dear lazy web (see? can do this as well, I am quick study), if you have any hint on what this new channels are, the Austrian Free Software enthusiasts would be very greatful to know, in particular the organizers of Grazer Linuxtage.

It is often said that many open-source-software is not enterprise-ready. But in order to be enterprise-ready, software must first be user-ready. I want to give you a feeling what I mean.

Hi,

in the good old times(TM) using Linux was simple.

If you wanted to access some drive, e.g. CD-ROM, floppy disk (you know these 3.5" square plastic things which could hold a whopping 1.44 MB of data, if you formatted them with special tools you could push even a bit more on it), you just had to know the device file and the file system and if you knew that, it just worked (TM):

$ mount -tiso 9660 /dev/hdb /media/cdrom

The human race has been living and thinking in terms of borders for a long time, since the first people decided to settle down instead of keeping a nomadic life style.

Ideally each individual's respect for everyone else's needs and personal boundaries would be sufficient to control access to shared resources and such things, however I am not holding my breath that this would happen any time soon (soon as in terms if centuries).

Therefore we happen to need borders and ways to enforce them, such as protecting political borders through military forces, legal borders through law enforcement, etc.
Sometimes people separated by such borders decide that whatever reason they had to create these in the first place are no longer sufficiently imporant (if they exist at all) and work on removing these obstacles reap the benefits of what basically is a reunion.

I know that all of you reading this blog understand this very well, because we, communities like KDE, are an unprecedented reunion of people separated by all kind of borders.
This is why people within these communities are or really should be offended by any attempt to enforce borders that have actually been removed even outside our own spheres.

Attempts like artificially segmenting markets for the sole benefit of big corporations which want to keep control over what consumers are allowed to purchase beyond their financial restrictions.

Obviously these corporations are really good at hiding this, quite often by mollifying consumers using half-truths.
One such half-truths is the often encountered "localization problem", i.e. the extra effort of getting things translated, correctly layouted and formatted, etc.

The nice aspect of this half-truth is the true part, i.e. that it is quite some considerable work to do this properly and that basically everybody knows that first hand, e.g. by having been abroad in a country with a different native language.

The false part is implied consequences.

For example lets have a look how this is applied on TV shows.
It usually takes a year(!) or even longer after the original airing in North America until the episodes reach Europe.

True: doing good translations and dubbing takes time

False: it doesn't take a year (or longer) and episodes aren't broadcasted right after being shot either

One actual reason: "test drive" in one market and quit if it tanks. The studios don't want to get into a situation where one market likes the show and another doesn't, i.e. actually let the consumers decide, $DETIY beware!

"Unfortunate" results:

• consumers outside the "test" market don't even get a chance of liking something that didn't fit the expectations of the test group
• genre or franchise fans outside the "test" market are either cut off from participating in international fan communities or need to use illegal back channels to stay up-to-date

Or as an more on-topic example for an IT related blog, check how OEMs like Dell abuse this excuse to sell certain configuration in one country but deny delivery to customers of a neigbouring country dispite this two countries having exactly the same localization and despite all trade barriers having been abolished between those countries for years.

The very same companies will happily move production to countries with cheap labour, consolidate preivously distributed support centers, etc.
In other words they will take the benefits of globalization and not let you have any of it!

Therefore it is imporant that we as a really global community demonstrate continuously that thinking and acting globally is not only doable but also possible to do in a timely manner!

Because despite being largely based on voluntary work, the KDE community manages to release products and their localizations synchronously across the globe.

I'm developing and maintaining a small application called Plutimikation for my daughters. It's a math learning game for children. Today I did a release of the current state as Plutimikation 0.2. It's the second release. The first release was four years ago. It's interesting how tools and infrastructure have evolved since then. Today releasing software is almost fun.

Four years ago I hosted the code in a private Subversion repository and manually built a package for SuSE Linux 9.1, which was the current SUSE version back then.

Today I host the code on Github, and the openSUSE Build Service builds packages for openSUSE 10.2, 10.3, 11.0 and Factory and for SLED. It's amazing how much more easy it has become to develop free software openly and distribute it to the world.

There are some small pieces still missing, though. Getting the source code from github to the build service still involves some manual work. I would prefer to just type in the URL of the git repository in the build service and let the rest be handled automatically. It's just a little bit of code, which is missing here and it could be added easily as the build service is free software. Would be a nice project for a cold winter evening.

The other missing bit is the distribution of the software. SUSE has the fabulous one-click-install mechanism, but apparently it requires some work to create a one-click button I could put on the homepage for Plutimikation. I see no reason why the build service couldn't provide the HTML for such a button automatically. This would probably mean dynamic creation of the ymp file which is used by the one-click-install mechanism and a suitable graphics. Another nice project for cold evenings.

So even, if for perfection there are still some bits and pieces missing, the tool chain for maintaining and releasing software has become incredibly great.

One thing hasn't changed in the four years. I'm still using the KDE 3 platform for Plutimikation. It provides everything what's needed to develop this kind of small application in no time, including stuff like translations. There is not much to be wished for here. That really tells about the quality of the KDE platform.

But the next version of Plutimikation will use KDE 4, so it also gets all the beauty, portability and functionality goodness which other apps already enjoy for a while. I'm looking forward to Plutimikation 0.3.