Indeed, I've got good, no, very good news from Real Life !

About one month ago me and Antje married, so she is now Mrs. Neundorf

Here's a photo of us two:


(made by our photographer from Fresh Fotostudio, which we can only recommend)

As you can see, we were quite happy (and still are).
The weather that day was slightly rainy and misty in the morning, but became better as soon as we were married, and we had a great party in the evening with our relatives and friends

Here's a photo of our rings made of white gold, which are obviously the most beautiful pair of rings ever made :
(made by the best goldsmith there is, see http://www.schmuckx2.de)

Alex & Antje

P.S. this is also one of the reasons why I didn't have a lot of time for KDE during the 4.3 cycle...

Ok, this blog is not really KDE related (well, it makes the network installation of a KDE developer more convenient, so...), but anyway here we go.
Main purpose is to get the compatibility information out there, so others can find it.

So, I recently purchased a QNAP TS 109 Pro.
This is a small NAS, i.e. basically it is a small Linux server. It has a 500 MHz ARM processor from Marvel, 128 MB RAM and its main purpose is to be used as a NAS. That's what I'm doing. For that, it supports among others NFS, Samba and also a web interface. I'm using it here over NFS from my different Linux machines.
Additionally it can also be used as a printer server over Samba.
This is also nicely working, both from SUSE 11.1 and Slackware 12.1. Finally we can now print wireless

Some nice points of the device:

• it's small, roughly the size of an external 5.25" drive
• it's very silent, no fans at all !
• in idle mode it consumes only 6W
• the power-on switch is also an power-off switch (AFAIK e.g. for the NetGear 2150 it is only a power-on switch)

I'm using it with hardware which is not on the official compatibility list at QNAP, but it seems to work flawlessly.
So, the harddisk is a Samsung HD322HJ 320 GB Spinpoint F1. No problems until now, also very silent.
The printer is a HP DeskJet 5151, connected via USB to the QNAP and exported via Samba.

I just did a quick benchmark, reading 261 MB of data and piping it into /dev/null took 28.3 s, gives 9.2 MB/s.
I guess this is not too far away from the maximum one can get over a 100 MBit ethernet cable. And it's more than you can get over WLAN anyway.

So, all in all, a nice, silent and small device

The TS 109 II has more RAM, but I think I don't need that.
The "Pro" versions of the TS 109 and TS 109 II support NFS (that's what I'm using), the versions without "Pro" AFAIK don't.

Alex

P.S. one bad point: for setting it up they ship a Windows-only software, so I had to do this on somebodys else PC. AFAIK there is also a Linux-only way to set it up initially, but I didn't feel like doing this since it seemed slightly complicated.

I'm just trying to compile Battle of Wesnoth (yes, for me gaming means compiling games... ).
I just built it with CMake, which first complained that it didn't find Lua 5.1. I checked, it really wasn't there. So I downloaded the sources for lua, make, make install, and now lua is in /usr/local/.
Then I run cmake again on Wesnoth and it happily finds Lua, so CMake now succeeds and I can build Wesnoth.

To have more fun, I'm trying right now the autotools build for Wesnoth:

checking for LUA... checking for LUA... configure: error: Package requirements (lua5.1 >= 5.1) were not met:

No package 'lua5.1' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix.

So it uses pkg-config to find Lua, and fails with that. Why ? Because Lua doesn't install a pkg-config file:

lua-5.1.4$ sudo make install
cd src && mkdir -p /usr/local/bin /usr/local/include /usr/local/lib /usr/local/man/man1 /usr/local/share/lua/5.1 /usr/local/lib/lua/5.1
cd src && install -p -m 0755 lua luac /usr/local/bin
cd src && install -p -m 0644 lua.h luaconf.h lualib.h lauxlib.h ../etc/lua.hpp /usr/local/include
cd src && install -p -m 0644 liblua.a /usr/local/lib
cd doc && install -p -m 0644 lua.1 luac.1 /usr/local/man/man1
hammer:~/src/packages/lua-5.1.4$     

So, now I'm sitting here fiddling around with this stuff, even although Lua is in the number 2 location where you would expect it (i.e. /usr/local, not /usr)...

So, let's just not rely on an optional additional tool for our builds.

Alex

I thought I share a few interesting links:
Gnome switches to git: http://mail.gnome.org/archives/desktop-devel-list/2009-March/msg00086.html

But not everybody does so, e.g. Python is switching right now to Mercurial: http://mail.python.org/pipermail/python-dev/2009-March/087931.html

Eric Sinc has an interesting blog about DVCSs: http://www.ericsink.com/

Ah, yes, Joel also mentions git
http://www.joelonsoftware.com/items/2009/03/09.html

Alex

I think we are getting one step closer to World Domination (TM) of Linux !

How come that I think that ?
Have a look at that page (it's german):
http://www.dm-digifoto.de/gratis-download.html

It's a page from a big german drug store chain, and I wanted to download their photobook software. I had already started installing wine on my box just for the purpose of creating a book of my own photos. And I remember one year ago that software was available only for Windows (or at least not for Linux). And I didn't expect that this would have changed.

Now, what did my eyes see ?
"Die Foto-Software im Komplett-Paket für Linux"

So this year the photobook software is also there in a version for Linux !
Now if that's not cool !
Great job, dm ! Way to go !

Here's a screenshot:

Alex

P.S. the application uses Qt4

P.P.S. as you can see, a KDE 3 desktop is still good enough to build KDE 4 It has even the advantage that the build breaks really bad if some include directory order goes wrong (and I get KDE3 includes in KDE4)

• The iGo universal charger with interchangable tips

Clever idea? Nope, this is one you can definitely skip...

There was this blog entry about the state of packaging for the Mac.
Containing "Then you think to yourself, if only those nice boys and girls in KDE-land had a native solution for installing their software,"

So, if you want a native solution, please join kde-buildsystem and let's see what needs to be done to get the packaging support you need for OSX. I don't have an OSX box here, so your help is needed.

Looking forward to hearing from you
Alex

Since a few days Kitware is hosting a cdash dashboard for kdelibs. The ctest config file in kdelibs svn has been adapted accordingly.
So if you run now "make Experimental" in kdelibs the build and test results will be submitted to http://www.cdash.org/CDash/index.php?project=kdelibs .
It would be very useful if we could get nightly builds for OSX, FreeBSD, Solaris and Windows, so we can make sure they stay compiling.

I tried it with an Experimental build. On the first run, the tests where not built, so they were all marked as "Not Run". To enable them the cmake option "KDE4_BUILD_TESTS" has to be enabled. I did that and did another "make Experimental". Now the tests where executed. I did this while working in a KDE3 desktop.
Apparently some things fail then, and I had to kill a few processes, otherwise some tests where hanging for a long time. I guess we could set the timeout lower, to 1 minute or so. But ideally the tests should succeed nevertheless.

So, we want you to set up a Nightly build of kdelibs fopr the dashboard, preferably on a platform != Linux. If you have questions how to do this, come over to kde-buildsystem@kde.org

Alex

If you subscribe to this blog, you might want to unsubscribe.

I'm not sure what to do about this space. I've quit paying much attention to it and I don't miss it. I don't read blogs much any more either. I've replaced that part of my informaion consumption with listening to netcasts (aka podcasts) on-the-go -- i.e. on my mp3 player/phone (I recently bought a Nokia 5300 in case you're curious).

Also, I guess, there are aspects of blogging that leave me feeling cynical about it. Sometimes really cynical. It sure seems look-at-me'ish and quest-for-hits'ish and monologue'ish. Doesn't it? In other words, not very social.

(By the way, at times, I've been just as guilty of that here as anybody. In fact, one could argue that I'm doing it with this post. Though like anything, it's a matter of degrees really.)

So I thought about this space, and narrowed it down to 3 choices: delete it, leave it as-is (an archive of old posts), or mirror my other (i.e. non-blogging) posts here, such as Twitter. I'm not sure which one I'll eventually settle on, but I'm going to try the latter first and see if that feels right. My theory is that because blogs.sun.com is high on google's radar, people who might like to participate in the public conversations that I participate in will have a better chance of finding them.

So this blog title is "KMail and bikeways in Germany". You may wonder what they have in common. You may wonder whether there will be an eloquent Aaron-style nice little story behind that.

But sorry, no, I have to disappoint you. At least from my point of view kmail and bikeways in Germany have absolutely nothing in common, two completely unrelated things, no surprising lovely details they share.

So, to get to the point: what I wanted to say for a long time: congratulations to KMail ! I use it since years and it always just works. And one IMO huge achievement: I have thousands of emails in my mail folders, and it starts really really fast, basically immediately. Sorting or searching the mail folders - instantly. Greak work ! Not all applications manage to do that.

Now to the sad part, the german bikeways. No, I won't complain that there are no or too few bikeways in Germany. More the opposite. There are too many, or, too many unusable bikeways in Germany. I mean, bikeways could be a nice thing. Not so here in Germany. The trend here is to put bikeways on the sidewalk together with the pedestrians. Does that make sense ? Does it make sense to have me riding with let's say 25 to 35 km/h through the pedestrians ? I don't think so. I also don't think that would be especially safe, neither for me nor for the pedestrians. But, well, in these cases, one could just ignore the bikeways on the sidewalks.

But now the really annoying effect of that is, that car drivers have come to expect that bikers belong on the sidewalk to the pedestrians: "This is my street, get off !".
I mean, it's not enough for them to honk at you, some of them go so far they lower their window just to scream that at you as biker.
Even if there is no bikeway visible, just sidewalks.
How to put it, I'd suggest to split bikers into two groups: sporty bikers, i.e. faster than 20 km/h and comfy bikers, slower than that. Consider the sporty bikers like motor bikes, and the comfy bikers like pedestrians.
IMO this would make a lot of sense. If I'm going relatively fast, e.g. at 30, I much rather prefer to share the street with the cars at 50, than to mess around between pedestrians moving at 5 km/h. At 30 I also don't want to circle around trees on sidewalks, go up and down the sidewalks at each crossing and also drivers don't expect somebody almost as fast as them selves on the sidewalks on crossings. OTOH if I'm going slow all that is ok.

So my proposal: either split bikers into two groups, or much better build bikeways as part of the street, not as part of the sidewalk, so we get accepted again on streets.
(children biking on sidewalks is ok of course)

Alex

Ok, we all know, blogs are the new mailing lists, so here just some quick comments from my side on all the release-cycle stuff.

About being in sync with releases of other projects: I am caring for our buildsystem which uses CMake, so the releases of CMake and KDE matter to me. I want to provide a stable (as in "not chanigng too often") build environment. If project A (KDE) depends on project B (CMake), it doesn't help project A anything if it's releases are in sync with project B. Why ?
Because, well, in order to have a stable environment I don't want to force developers to have to update their cmake from non-distro packages (the binary cmake packages provided by Kitware work flawlessly on all systems I tested so far, btw). This is frustrating ("damn, which package do I have to update today to make KDE build again ?") and takes away a lot of time (not for a single developer, but accumulated for all).
So, before we (KDE) require a new version of CMake, I personally want this not to happen before that version of cmake is shipped by the most common distros (i.e. a few months after its release).
So I see also a value in not depending on always the latest and greatest releases of other projects.

Regarding DVCS: I don't have much experiences with them, but when I tried git, it wasn't really easy. Mercurial is said to be much more user friendly, which for me would be a big advantage, lowering the entry barrier to KDE development etc.

But, what I wanted to say: I big part of the value cvs/svn provide is IMO that all code in development is visible to all developers immediately, not only once a while. Especially for KDE with its many many developers this means that current code will be tested (at least built, maybe also run) immediately by many developers, so problems should be found quickly. We don't have that many developers on "exotic" platforms like Windows, OSX, Solaris, *BSD. For keeping KDE working on these platforms it is IMO important not to create more work for them, by requiring them to deal with more repositories.

About "always summer in trunk": sounds really good, but I also see the risk that less people will be working on the stable branch as soon as it is created.

About the 6 months vs. 9 months vs. 3 weeks: I agree with Aaron that 6 months is quite short. It leaves 4 months for feature development. Which also means you should start with the features really soon after the release, otherwise you may have only 2 or 3 months left for that. At least for me it has always been the case that there are weeks where I just don't have the time to do anything significant on KDE. E.g. when I was student, there were the weeks with the exams, sometimes you go on vacation, real-world stuff like moving, visiting friends and relatives etc. add up from time to time. For me this also means a time span like proposed by Aaron of 3 to 4 days for a stabilizing period absolutely wouldn't work for me, since it will happen often that just during these days I won't have anytime at all.

So, this was probably not as nicely written as the other blogs on this topic, but I just wanted to share my view on this too.

Alex

Different groups of people use different ways to measure performance of computers. Kernel developers test their kernels by, well, compiling the kernel. KDE developers may measure the startup time of KDE.
So what does the buildsystem maintainer do ?

He measures how long it takes to build CMake cvs (including curses and Qt4 based interface).

So here are the numbers:

On my desktop machine, which is still an AMD Athlon 2000XP+ (already over 5 years old), 1GB RAM, new hard disk: 5 min 59 s.

On my new Dell Inspiron, Intel Core 2 Duo 2 GHz, 2 GB RAM, 5400 hdd, shipped with Ubuntu (which instantly became a kUbuntu): 2 min 17 s

So although they claim about the same frequency, it's really almost three times as fast !

But, wait, it's a Core Duo, so let's try make -j2: 1 min 15 s. That's only 20 percent of the time the Athlon needs. Not bad !

(I also tried make -j3, this gave also 1 min 15 s, so no additional gain here).

Alex

P.S. so maybe it's really time to upgrade my desktop machine, I didn't expect such a big difference. OTOH it still feels fast, and so it's a good machine to test the speed of KDE on not too fast hardware.

Hi,

CMake 2.6 will rock. Latest news: Clinton Stimpson has started to work on a Qt4 based GUI for CMake, so there will be a modern GUI to CMake also on UNIX, here's a screenshot from CMake cvs today: .

The first commit is only a few days ago and it is already working nicely. Now that there is a GUI written with the best toolkit in the world , there is a lot of room for cool features and improvements (ok, as cool as a feature for something as boring as a buildsystem can be... ).
I guess we need a Plasmoid for it, to make it more sexy

Anyway, if you feel like hacking on this, join on the cmake list

Now to something completely different: all my three distros I currently use are working absolutely flawlessly, Slackware 12 is as great as only Slackware can be , to get WLAN working on kUbuntu 6.10 all I had to do was to install wireless tools and to plug the card in (really, I just plugged it in and it just worked), and kUbuntu 7.10 on my new work machine also just works, even with OpenGL support enabled automatically (Intel graphics ).

That's it for now
Alex

An exciting event will be happening later this month: Indiana's new OpenSolaris distro is due for its first preview (milestone) release. Also, the OpenSolaris/Indiana Developer Summit is happening this weekend.

With this in mind, allow me to post a reprise or two of some of the core issues that were on a lot of our minds a while back as this new initiative struggled to find its footing.

Probably the most core of the core issues is this: Is the Indiana project a true collaborative effort? There are many shades to that question, but overall, I believe it is. I base this on the the following two things. (Note, the second rests on the first.)

• This definition of collaborative development
  
• The fact that at the technical level what "Indiana" boils down to -- which is to say, what it is comprised of and defined by --  is the IPS-LiveMedia-Constructor project. And that project is massively engineer-driven, as opposed to upper-management driven.
  

 
Just wanted to blog a copy of a post I made yesterday about Indiana vis-a-vis BeleniX...

Date: Thu, 28 Jun 2007 09:30:23 -0500 (CDT)
To: Indiana Discuss <indiana-discuss at opensolaris.org>
Cc: Ian Murdock, Glynn Foster, Peter Tribble
Subject: Re: [indiana-discuss] scope
From: Eric Boutilier

On Tue, 26 Jun 2007, Ian Murdock wrote:
> Peter Tribble wrote:
> > On 6/26/07, Glynn Foster <Glynn.Foster at sun.com> wrote:
> > > I agree, and perhaps all these thoughts need to get down on paper, and start
> > > fleshing out the details. We need to, I believe, get to a stage where we are
> > > producing bits that people can download and install. It might not be fully
> > > functional, but it's a defined release and something that people can base their
> > > work around.
> >
> > By people, what's the target audience at this stage? I think my question is
> > really whether the first "release" is aimed at users, or whether there should
> > be a 0.0 "release" solely for the purpose of Indiana bootstrapping?
>
> The latter.. We need a starting point of some sort we can improve
> iteratively.

Glynn, Peter, Ian --

If a 0.0 starting point is what we need (and I couldn't agree more) why aren't we considering making a.) Moinak co-"BDFL" and b.) Adopting BeleniX version 0.6 to become "Bel-Indy" version 0.0, aka our bootstrapping starting point?

Sorry to keep being a pest about this, but indiana-discuss is collectively and increasingly suffering elephant in the room syndrome in this regard. (http://en.wikipedia.org/wiki/Elephant_in_the_room)

Eric