I do not have a paypal account.

I do have a credit card (AMEX) and I'm living in Italy.

Today I tried to setup an account and bind it to my card. I dislike localizations so the first thing I did was having it keeping the English language after I had to tell the system I'm Italian.
Well I registered and everything went smooth till the point of telling paypal the card I want to use...
I followed the links and... =_= Oh, my card isn't in the list...
Strange. Let's try to use the contact module to see what's wrong and... Oh, it says that it isn't available for "U.S. English", I should go to my preferences and switch it to Italian...

In the end apparently IF I'm Italian I cannot use AMEX...

Paypal sucks?

Last week I spend some time visiting some friends in Massa, a quite nice city near a quite nice seaside. It's all fine with sand, sea and the usual places where to relax. We went in a crepe and piadina shop, there we found the owner pretty depressed: he is thinking about closing the shop by the summer.

Though times you think, well no, Creppolo is quite known and lots of people gather there by the day and by the night, if you want to eat something tasty during the night and you are around there you'll probably end up there... So, why closing? Well apparently the municipality council/major doesn't like to have shops open the whole night (even if it's a tourist city in the seaside...) and decided that by 2AM every shop MUST be closed. Creppolo made most of its sells between midnight and 4AM.

That is pretty annoying since I liked that place and pretty annoying for all the other shops that sell stuff at night (there are many). I always appreciate the short-sightedness of the people elected by people.

Today it's an election day for the Europe, please make sure you don't miss this chance to vote somebody that won't spoil your hard work ^^

That's a follow up from Diego about somebody quite angry that went to vent a bit too much and got quite a backslash. Then he got also some issues with his blogging software hiding all the comments about his rant. Now things are more or less normal and you can read the comments again.

Given I'm the first using strong words about software I dislike (like cmake) I try to be ready to be proven wrong. Since that usually means that that either I got somebody planting some clues on me with the proper bat or things improve in the mean time, both cases usually I'm happy/happier to be proven wrong. Being wrong is something that may happen.

Now, I hope that what Matti and Boudewijn did was out of frustration, since I assume that after stupidity and before malice. If you release something it's YOUR FAULT if it's broken since YOU are the committer in your tree. Smearing other people to cover the fact YOU, too, messed up is plainly wrong...

Here a bullet list about doing benchmarks

• Reproducibility: your numbers worth nothing if nobody could reproduce them, so you have to give along them a script or a detailed description of what you did.
• Statistics: outliers and other artefacts may screw your results, make sure your script is run enough times
• Indices and values: if you want to proof something you need hard numbers possibly something everybody can understand easily and cannot be misunderstood: cpu cycles, time to complete, memory usage, are quite good, given you aren't testing on particularly different architectures or systems.

Quite short, isn't it? Still many people just state their values by inference (like "it ought to do 2x the syscalls thus should be twice slow"), or just tries to benchmark something that isn't what you want to test (like "glxgears is slower now, mesa is slower at rendering complex scenes") or have a quite different settings and configurations (think about having your application with a minimal configuration and the same one with a larger one)

Usually the best way to get a meaningful benchmark is preparing a script and give instructions about how to use (like which version of companion software are you using) and then provide the numbers (media with variance if you are inclined) and a summary of the system, this way others can play and try themselves. This is quite useful since the optimization you are working on may be great on gcc4.3 on PowerPC but be problematic on x86 with gcc-2.95.

Other times you want just people to compare something that is _quite_ influenced by the surrounding system or is annoying to setup, in those cases having a full system image is quite a boon, _everything_ could be the same. And given how easy is to use virtualization/emulation software nowadays it just take a bit of bandwidth.

You may already know that I have some complaints about pidgin:
- its developers use a brain damaged dvcs (yes monotone sucks, yet another application written in C++ that sucks after cmake)
- The ability to listen to the user feedback is severely reduced.

Since we are talking about alternatives looks like somebody tried to make things a little nicer and forked the code so far and made something fun out of that.

Seems promising, I hope it works well enough to be put on Gentoo soon if the pidgin devs don't come to their senses =P

I'm completely unhappy of the result of those elections, obviously I cannot tell it was unexpected (Idiots watching TV and believing are quite many) anyway today I'll write about alternatives.

You know that I consider cmake one of the worst item available if you want to get a build system sane. I know that people usin cmake won't use those alternatives, most of the time because they aren't that known, fashionable or with spiffy names.
My list
- linux (kbuild) or ffmpeg like systems (note, we need to find a name for it) since those are relatively hard to get working on new projects,
- quagmire seems to provide something you can use but is still its infancy, yet I'll give a stab at it.
- waf seems scons done right, still it lacks the completeness and ease you can archive using the autotools the right way (reusing the good .m4 bits from aclocal and not wasting time rewriting stuff every time)
- bitbake could make some windows oriented people happy while giving the rest of the world the tools expected, but maybe those people cannot stand an heavy known markup (xml based) while loving the cmake's one.
- autotools have the main issue that some part of them are either over engineered (libtool) or annoyingly broking from release to release (automake), still the most useful part now it's autoconf, but iff ffmpeg configure would be chopped into the right bits to be reusable w/out feeling the pain even it could be replaced with ease, recently I discovered dolt, a replacement for libtool that maybe could help a bit.

Right now if you want to build a project autotools, with all their defects and glitches, are the best all around. If you want to get something saner probably you may start looking at dolt and quagmire, if you want to do something for everybody you may start modularizing ffmpeg configure and makefiles or linux kbuild so everybody could enjoy it. In the middle I put other tools that look more or less useful but that for a reason or another I dislike a little.

In a perfect world we don't have people wanting to use microsoft visual studio to build opensource projects, every library would provide a pkg-config file with all we need to know to link against it, and every system has a identical way to build shared libraries (passing --shared to the compiler and linker?).

In a perfect world probably we won't witness human stupidity with a Berlusconi III (the government).

PS: The hunt to .la files is open, please try to remove them from your system and tell us if something must be fixed. The treasure trove about pkg-config files is opened too, if you find a library not exposing one please notify us and upstream possibly with a pkg-config for them ^^

Quick and easy task for this day: check which is the status of openwengo since seems that's the only client providing what skype does, at least in theory...

Part one, get the source - delivered from the site as a nifty .zip

- wget + unzip worked as should

Part two, build the beast.

- cmake! The worst build system since imake, sadly brought into the fashionable stuff because of KDE4,
Now we get something interesting, on a phenom you get:

qlop -tH cmake
cmake: 5 minutes, 12 seconds for 1 merges

A comparison:
perl: 3 minutes, 43 seconds for 1 merges
m4: 29 seconds for 1 merges
automake: 14 seconds for 3 merges
autoconf: 16 seconds for 2 merges
libtool: 44 seconds for 1 merges
make: 30 seconds for 1 merges
cmake: 5 minutes, 12 seconds for 1 merges

Using something less new makes the whole thing even more interesting. Let's say that to build something using cmake I need the 3/2 the time to build perl, just to start.

gentoo has an ebuild for it so it it's just getting it, (why cmake needs xmlrpc-c is a question I'll left unanswered...)

Now back to openwengo.

I have to create a build dir and run cmake from there, it obviously finds something wrong with ffmpeg even if supposedly it has its stale internal version (remind: ffmpeg changed the include paths some time ago) as fallback (no, you have to run cmake a first time, have it fail, run ccmake, find the right option and turn it on, start again).

I'm not sure if this brain damage is due wengo people or cmake, still I find this annoying. The *oh* so despised configure from autotools can be smarter and does not require that many lines if you know what you are doing...

It still doesn't take in account that there are different endianess for linux (autotools have a nice builtin for this...)...

Once the thing built (took a while), I just got more or less the same thing I got last time I tried it, looks like the 2.2 isn't quite up to date and they are working on the new mayor release =/

Back looking for other alternatives for skype =_=

Recently I happened to use the newest adium for few minutes (the time to erase my data from the macosx partition while I'm sending the laptop to repair (more on it once it is back, hoping it is back)

Adium probably is the best IM I ever tried, it works fine, in an unobtrusive way, it has all the gloss you may like (from none, to everything), but has just one defect: works just on macosx (that I don't like that much for developing since I'm not into BDSM).
Now, everybody and his dog knows that adium uses the fine libpurple from the pidgin project, and there is a pretty nice gtk client called pidgin that people usually use...
The problem is that seems that some of its developers spend too much time castrating the UI

http://developer.pidgin.im/ticket/4986

NEXT in row: have the chat window unresizable.

PS: no I won't try to hack pidgin, monotone sucks.

A moral prize to the people that could guess what's wrong relevant part of the config

  {5222, ejabberd_c2s, [

                        %%
                        %% If TLS is compiled and you installed a SSL
                        %% certificate, put the correct path to the
                        %% file and uncomment this line:
                        %%
                        {certfile, "/usr/local/etc/ejabberd/ssl.pem"}, starttls,

                        {access, c2s},
                        {shaper, c2s_shaper},
                        {max_stanza_size, 65536}
                       ]},

relevant log message when you try to login

**      Data  == {state,#Port<0.367>,<0.374.0>,gen_tcp,"2667452897",
                        {sasl_state,"jabber","jabber.stuff",[],
                                    #Fun<ejabberd_c2s.1.132950982>,
                                    #Fun<ejabberd_c2s.2.53796002>,undefined,
                                    undefined},
                        c2s,c2s_shaper,false,true,false,false,
                        [{certfile,"/usr/local/etc/ejabberd/ssl.pem"}],
                        false,undefined,[],"jabber.bofh-land.net",[],
                        undefined,
                        {0,nil},
                        {0,nil},
                        {0,nil},
                        {0,nil},
                        undefined,undefined,undefined,false,none,[]}
** Reason for termination = 
** {{badmatch,{error,"SSL_CTX_use_certificate_file failed: error:02001002:system library:fopen:No such file or directory"}},
    [{ejabberd_c2s,wait_for_feature_request,2},
     {gen_fsm,handle_msg,7},
     {proc_lib,init_p,5}]}

relevant file that surprisingly doesn't seem to exist.

ls -al /usr/local/etc/ejabberd/ssl.pem
-rwxrwxrwx  1 ejabberd  wheel  1956 Feb  8 14:21 /usr/local/etc/ejabberd/ssl.pem

I started setting up some stuff on a jail I'm sharing with some friend, freebsd-6.2

- installing ejabberd is quite painless through the port (good)
- configuring it was alike gentoo (nice)
- having ejabberdctl working needed some tweaking (and learning what a cookie means for erl)

now, time to test the beast

- web stuff working as should
- connecting doesn't using tls ?!
-- trying on gentoo shown the same issue -> solution on gentoo: set proper perms to the ssl.pem and using absolute paths.
-- on freebsd that isn't working for unknown reason.

Time to play with gentoo on freebsd in a chroot inside a jail.

humor me plenty!

There are many ways to get an opensource project fit better your needs:

- you contribute to it by doing the missing bits yourself.
- you contribute to it by funding somebody so you get the bits done.
- you ask politely about those bits and you make a point on how those bits could be useful for the developers too (so they will use their time and skill to implement them)

There are also many ways to hinder an opensource project (trying and failing to have it fit better your needs):

- you assume you can lead who is doing since you are using what's done by them
- you assume that there is democracy and the fact "everybody"* want something (but the people actually doing something) makes that relevant
- you try to annoy people till they give in or give up.

* from interestingly inflated self made estimation

Let me give a bullet list about ways to contact developers:

- IRC: most developers are present on irc, you may query them, talk to them in the topic channels (e.g: #gentoo-media) or ask for voice in the #gentoo-dev channel. Irc logs may or may not be available for past digging.

- email: again you can either contact the developer privately using the ${nick}@gentoo.org email or using the mailing list (gentoo-dev, gentoo-project, gentoo-$topic), you may also read the archived discussions.

- jabber: we got IM too, you may again use ${nick}@im.gentoo.org to contact them directly.

Those are two way communication routes, you ask and you got replies, most of those let you have a nice log so you can even point past discussions for clarification. If someone disregard about you usually can voice it and it remains.

There are 1 and 1/2 way communication routes like blogs, it's up to the blog owner let the comment appear or not (so he could make like he got full support by everybody just silencing who isn't exactly keen on what's there).

There are even 1 way routes like the GWN and GMN in which the editor can write whatever he wants.

If you wonder why I'm just stating the obvious like this, well, seems that some people got a disconnected perception on how communication works so it's sorely required even if dead boring.

You probably know that I’m a fierce antagonist of anything that isn’t simple, that is over engineered or that is plainly ugly.

Now I’ll spend some lines of this rant^Wlog writing about how HAL is annoying, conceptually broken and ill conceived.

You may start thinking about other technologies that now are maturing in something nicer like dbus (even if could be lighter and faster) or udev, they improved a lot even if I would avoid force feeding ingenuous lambs (I mean people using linux and posix systems before and not yesterday windows converted users that really NEEDED that stuff NOW and that now appear to be the main target for opensource applications nowadays, see David’s post)
) with them.

Now, udev is good at reacting to hw events and dbus is good at passing messages, why something that should be just a little layer of glue between them has to be that complex?
Why it needs to have lots of square wheels reinvented, while we have perfectly round ones available for free?

Cardoe already voiced his frustration about it and I’m plainly not using it while I can, still I’d like to have something lighter, simpler, saner to notify userspace applications that something in the hardware changed, since the idea isn’t that stupid.

Lately I happened to read something that made me think, basically Miguel de Icaza stance on microsoft's pseudo xml format and microsoft's flash workalike.

He tried to remove some polarization we have on anything made by Microsoft and tried to compare in a less biased way the 2 spec AND flagship programs, most of the people could stop at the first part and get the message "ms stuff isn't that bad afterall" or even the "ms stuff has nice ideas here and there". I read it as in "there is MUCH work to do and ignoring them isn't productive", I'd add my point of view as in, instead of following them and doing their same errors or supporting their same horrors, we could just learn and try to do something different (and broken in different ways) starting for our own foundations and nothing that could be undermined by them?

Having a microsoft offerings workalike may be good for some, but since there are way better tecnologies out there waiting to be improved it's just a waste. (e.g. Vorbis, wavpack, mkv, nut, XUL, D, parrot, Dirac, snow, SVG...)

Anyway the nice thing of opensource is that everybody is free to do whatever he wants and usually sharing good ideas works in the end, if more people make usable/better tools more people will use them.

Lately I happened to not tolerate anymore the ugly dirac spec, the pdf produced is w/out a index, the font are horrible and the reason is that they made use of latex instead of something saner (docbook anyone?)

This rant isn't about the dirac spec anyway, the content isn't bad at all, is just the presentation.

This rant isn't even about their usage of latex, it is pretty much correct and produces documentation even if you have an ancient tex distribution (tetex).

Now my angry words are at latex in itself since it is the root of the problem.

Latex pros:
- large library of modules, styles stuff
- large userbase
- very nice programs that makes use it less annoying (kile)

Latex cons:
- Doesn't support truetype fonts out of box, nor lots of image formats.
- It's default fonts are anything but beauty on screen
- the syntax is between bad and ugly
- you end up with overcomplicated systems to keep your documents in shape
- you spend more time figuring out what to use instead of using it (and the time isn't short)
- the document build system isn't exactly an example of clarity.

Seems that many of those issue got addressed on texlive, that sadly we don't have in portage since few people would touch tex since it is an ugly monster.

All in all you may think that latex is good enough since there aren't saner alternatives if you want produce a book that doesn't look a wordprocessor printout... Well, there are nicer alternatives IMHO, one being xml markups since you can convert them with ease (almost), you may produce them using maybe quicker markups (e.g. texy), you can mix and match them (including mathml and svg in docbook isn't difficult. Sadly there aren't good authoring tools like kile. Would be simpler make a good authoring tool (yea, I know emacs is wonderful for xml editing) or make latex less ugly from an user and developer POV?

Please have a look at this

http://www.governo.it/GovernoInforma/documenti_ministeri/innovazione/protocollo_microsoft.pdf

If you don't know Italian isn't a problem since it isn't even written in proper Italian.

Summary for this trash: Microsoft got a cofinancing in order to plant 3 new centers in certain cities of Italy (that also happen to be the ones in which you have active open source centers for innovations), the government grants some founds and Microsoft adds 1M$ in 3 years(in software licenses and other non-cash stuff like that). Note Microsoft receives at least 1000 times from the Italian public administration every year (the yearly cost of Microsoft licenses).

Why IBM, Canonical or even Novel won't start making such deals?

Everybody and your dog knows that microsoft tried to rerelease ActiveX with a cool name and trying to play again the .NET card over it to make it look less stale. Miguel obviously got another dose of crack^W^W^W of optimism and tried to find something good in something that should be shot on start, well, restart.

He said that Silverlight will be something useful and 1/5 sites will use it in few years. Well I have lots of fun with standard tecnologies: javascript, SVG, HTML5 and so on...

Now, if you want richer applications there is something that binds everything together it's called XUL, works EVERYWHERE (hi, minimo) it's quite documented, mature, has an opensource implementation and a compact runtime (xulrunner).

and Oh, btw it has already more than the 1/10 of the market share and is steadly growing...

Now if we got a standard multimedia framework (maybe based on RTP, RTSP, codecs like Dirac, snow or vorbis) in the mix I think we are completely done, isn't it?

Probably some of us already read about how the playstation3 firmware runs linux (the "OtherOS")

Some insight:

1- it uses as bootloader a very minimal linux system that then loads the right kernel using the kexec call (yai!, after the gamecube the other ppc platform with kexec implemented is the playstation3...)
2- the instructions obviously are scarce and seems to point out that the provided loader has a nice script to install just one kind of distro (I'll let the reader the exercise of guessing witch) and doesn't seem to provide anything useful if you happen to prefer something else...
3- [update] you can access the busybox shell from kbuild and just install gentoo the usual way (suggested using recent ppc64 stage3 and then build a cell-sources kernel using the cell_defconfig)

The kboot is quite neat in itself: it has a great deal of features (like ssh or tftp) and uses pretty standard tools (busybox, linux, kexec-tools, dropbear) plus something specific (the ps3pf-utils).

I'll add the ps3pf-utils once I have them mirrored on powerdeveloper and maybe adding an unofficial svn/git for it and libspe2 (since looks like they will be improved a lot in the next weeks and keeping track fo the patches is a bit easier this way)

I just did some comparisons about cmake and something better like... autotools?

Step 0:

Some numbers just for fun:

nemesi lu_zero # qlop -tH cmake
cmake: 13 minutes, 35 seconds for 1 merges
nemesi lu_zero # qlop -tH make
make: 1 minute, 0 seconds for 2 merges
nemesi lu_zero # qlop -tH bash
bash: 2 minutes, 32 seconds for 3 merges
nemesi lu_zero # qlop -tH perl
perl: 7 minutes, 52 seconds for 4 merges
nemesi lu_zero # qlop -tH m4
m4: 32 seconds for 1 merges
nemesi lu_zero # qlop -tH automake
automake: 1 minute, 8 seconds for 7 merges
nemesi lu_zero # qlop -tH autoconf
autoconf: 30 seconds for 4 merges

Ok cmake is a ugly hog at least while building.

Step 1:
What you want from your build system:

- take as little resources as possible
- have it as much portable as possible
- have as little as possible to write
- have a good way to express conditionals
- let you have your program correctly built on a large number of arches.
- automagically spot dependencies
- let you use tools like distcc and ccache in an effective way

Step 2:

Uglyness scale before cmake:

imake, scons: bad ideas with a bad implementation, everybody knows that, somebody is workarounding scons a lot, I hope for a fork.

qmake: not sure which part is bad, nobody likes to use it that much for a reason or another.

plain make: simple and to the point, it may not scale that well.

autotools: most people misuse them, many despise certain choices. The lack of good documentation and the version incompatibilities made them in a bad light, things are getting better little by little. The most used system despite the ugly Makefiles produced. I'd use them with their reference at hand.

kbuild: it is wonderful, works really well once you lay it out, it is even simple! Problem: you don't have a stand alone template to fill so it is much an hacking over existing deployments.

Step 3:

put cmake in the scale:

1- takes forever to build
2- is compact
3- uses the same approach as aclocal m4 files (call them Modules/*.cmake) but has a risible number of them.
4- supports less platforms than autotools
5- the syntax is a brain damage between imake and autotools
6- Hype points because kde4 could use it

Step 4:

When it could have sense:

1- your project is targeting what cmake supports already
2- you like its brain damages more than others
3- you misused autotools and now you are trying to misuse another build system (hopefully it won't make you misuse it that much).
4- you absolutely love the ability to have project files for some commonly used proprietary ides out of the cmake native files.
5- you want to gain some hype points to your project.

Summary:

cmake is a wonderful technology that should take the way of the dodo and never touch your hard disk, gives nothing more than a lobotomized autotools (and that is good since you can commit less mistakes) has the good mix of hype points and laziness compliant features.

In short cmake developers feel free to ignore me, this is a rant, I hadn't wrote a build system that will be used by a large project and probably I'm not so entitled to write such large stain of venom.

You obviously can take it seriously and prove me wrong with a next version with 1/2 the build time, less overhead and a nicer syntax.

UPDATE:

flameeyes told me that cmake doesn't have a way to set cflags/ldflags/asflags on a per target basis. So it is a wonderful regression to pile up to the rest...

UPDATE2:

http://dev.gentoo.org/~lu_zero/development/cdrkit-1.0pre3.tar.bz2
I played a bit with autotools to see how bad they are and/or how good cmake is...
I started from scratch for the first time using autotools...
There are some minor changes but nothing interesting.

New release from IBM!

New and improve Cell SDK!

The new mambo works and works quite fine! I have already provided an ebuild for it and probably in short time I'll add some gentoo custom bits to make working with it less annoying. You may check my overlay for it, I couldn't get tile play with the tk UI yet but maybe I could try harder and have the simulator gui a tad nicer.

On the other side, there is the rest of the SDK is a nightmare =/

I bitched already about improper software distribution and seems that somebody read it since now the proposed medium is even more awkward: alloycanwatlowcarbnosourceincluded DAMN ISO IMAGE!

The fantastic iso image:

nemesi mnt # mount -o loop /tmp/CellSDK11.iso /mnt/iso/
nemesi mnt # ls iso
README.txt autorun css images pdfs
ShelExec.exe autorun.inf html media software

ShelExec.exe!?!

nemesi mnt # file iso/ShelExec.exe
iso/ShelExec.exe: MS-DOS executable PE for MS Windows (GUI) Intel 80386 32-bit

I hope that's a joke...

Bright side: the pdfs in the same named dir are quite nice and is quite good have all the documentation in one place.

Dark side: again this is a fedora only distribution and the sources from bsc.es are again a messy tarball.