This is not another rant to praise one in spite of the other (an everybody knows I love Ruby, so it would not be impartial), but sometimes people seems to live in another world and do things for the wrong reasons.
I just read
this blog post by Kanwei Li in which he gives 2 or 3 reasons he ditched Ruby in favor of Python. First of all, both are great languages and, although I favor Ruby, I use Python for some projects and they are not all that different. Of course, everyone is free to choose which language one favors, but Kanwei seems to be ditching Ruby out of not knowing much about it, or out of preferring one style over the other
His first reason is that in Python white spaces matter. I used to think this is just a matter of style, but every now and then mandatory alignment hurts me (just try to put together a code generator and you ll notice it). Although my code is always correctly aligned, I like that it s done so because I want it that way, and not because some language demands it. Rants and more rants have been written about Python s mandatory alignment (or other languages lack of it), and I am not going through all of it Just I don t think it s a good reason to ditch Ruby
After, he makes a big deal out of Ruby s
ternary if. As written by him, he prefers
#python
if len(a) > 0:
v = a[0]
a = a[1:]
else:
v = None
over Ruby s
ternary if
#ruby
v = a.empty? ? a.shift : nil
Hey! Come on Ruby s
ternary if is not mandatory It was copied from C just as a syntax sugar. You can do without it, just as in Python:
#ruby
if ! a.empty?
v = a.shift
else
v = nil
end
Better yet! you can use if s return as v value:
#ruby
v = if ! a.empty?
a.shift
else
nil
end
How beautiful is that!
Python lacked
ternary if for a long time, and when it finally acquired one via
PEP 308 its syntax was made different from every other language! Although I don t think that is a problem, some people might think it would be better not reinventing the wheel.
Next, Kanwei goes over a famous problem of Ruby: the lack of a sum method for Array. I admit it s strange, but that is completely coherent: Ruby s Arrays are ordered collection of objects and not mathematical arrays. How do you sum objects that are not numbers? Many different people will have many different answers to that, so Ruby leaves this decision for the programmer and provides basic methods to deal with collections of anything (that can be used to apply sum to numbers, if wished). So, in Ruby you have to use Array#inject to perform a sum:
[1,2,3].inject(0) sum, value sum + value
Array#inject (actually Enumerable#inject) was borrowed from Smalltalk and allows you to loop through an array, building up an accumulator value as you go. When it s done, the final value of this accumulator is returned. Very useful for combining array elements, whether by summing them, building up a pretty display string, whatever. In the example above, I am initializing the accumulator with 0.
If you use Array to mathematical operations and you want your arrays to work that way, you can always add a sum method to Array class:
class Array
def sum
self.inject(0) sum, value sum + value
end
end
Maybe it would be better if you just use Arrays as containers (as it was intended to) and implement that sum inside your own class I completely agree with
Reg Braithwaite here.
Kanwei also mention Python is faster than Ruby. That is true, but was more true some time ago. First of all, Python is older and has had more time to improve its speed. Ruby,
ITOH, just now acquired a good VM and improvements to it finally can run parallel to improvements in the language itself, so I am expecting this to be
less true every release. Python is already not getting much faster between releases, unlike Ruby (the differences between 1.8.7 and 1.9.1 are really impressive!).
IMHO this is not a good reason to choose one instead of the other: if you really need speed, go for C :-)
Now this is something I find interesting Kanwei has mentioned: Python is more production ready . He argues that Google is using it, so it must be good. Well I cannot argue against that: Google is really using Python. But
IBM, Oracle, EA, Cisco, Siemens, etc are using Ruby so that is just a matter of preferring one or another company. Both are production ready I agree, though, that Ruby 1.9.1 has many differences from 1.8.7, and that that may be seen as some inconsistency, but Python also has changed a lot since its 2.0 version, for that matter. And the changes to Ruby brought many benefits I think they worth it.
At last, Kanwei compares Python and Ruby docstrings. Here I also have to agree with him: Ruby docstrings sucks. Actually that s why everybody uses rdoc instead (and that is much more powerful than Python s docstrings). Again, I don t think that is reason enough to ditch Ruby (actually, the existence of rdoc, rubygems & friends should bring people to Ruby instead), but that is a matter of personal taste.
Surely, Kanwei s reasons were easy to argue against. There are areas were Python shines much more than Ruby (and vice-versa), but those Kanwei mentioned are not among them.
I think both languages are powerful enough, and both are way better than Perl or
PHP, so either one you choose would be fine. Better if you don t have to choose and use both ;). If you have to,
ITOH, pay more attention on how you feel while coding in each one, and not to some cheap reasons such as above. If you are a programmer, what matters most is that you ll spend a lot of time coding with any given language let that be something pleasant then.
I ve been back from KDE (4.2!) to Gnome and with the mighty powers of Compiz my desktop is the envy of my Windows coworkers and still geeky functional. Well, somehow functional. For a while I wondered why I can t properly use VNC to remote-control my desktop from home. The connection works and I see the desktop but nothing seems to happen when I click or type. Now I figured out the desktop in the VNC client window is just not refreshed while my mouse and keyboard actions really do what they were supposed to on the VNC server. This is my sad tale of how I learned that a regression may mean driving the motorcycle to work in the middle of the night after cursing VNC. 
After a little searching through the lazyweb I found out that it s a bug reported on Ubuntu already. Apparently Compiz doesn t use the XDAMAGE extension properly. Somehow when using the graphics adapter s magic 3D powers X11 loses control of what sections are changed I m not an X11 guru. At least the client doesn t know when to redraw areas of the screen that have changed. The suggested workarounds were pretty ridiculous. Start another x11vnc session without compiz and connect to that. Very funny. I want to control my running desktop not create a new one. So I switched off compiz at work and voila VNC works again. Some eye-candy and shortcuts are gone but remote controlling the desktop is far more important while im on call. But I quickly missed Compiz. The missing eye-candy wasn t that bad. But metacity s window placement algorithm sucks as badly as back in 2002. As if I can hear it whisper: I have no idea where to put that stupid window. You tell me.
I researched a little further and somehow the bug is known to Gnome, too. And other users suffering from the problem are pointed to the VirtualGL page of Wikipedia. Apparently the problem was fixed for several people until a regression was reported where things failed again. Seems like the vino developers removed the piece of code that detected the use of 3D window managers as a 2008 christmas present. Their reason: This should work fine nowadays. Hell, no, it doesn t!
Somehow I downgraded vino to version 2.24.1-3 and ran the vino server manually (/usr/lib/vino/vino-server sm-disable) to see if it prints any error message. Indeed it does:
[Sorry to my sponsorees who's package sponsoring requests were delayed again due to this mess.]
I was requested to forward this information to as wide an audience as possible.
Possibly two months ago the legality/legitimacy of the actions carried out by the Hondurean armed forces, which captured a democratically elected president and without a judicial order or trial process forced him out of the country, starting a de-facto government, was something questionable. Each day, however, it becomes clearer and clearer the Hondureans are suffering a represive military-backed system which cannot be expected to fulfill as a trustable entity to conduct fair, credible elections.
I got this message from a Hondurean friend (of course, whose identity I am not divulging) denouncing the government's invasion of the .hn domain name registry, which is handled by the Sustainable Development Network (Red de Desarrollo Sustentable RDS-HN). The National Telecomunications Comission (Comisi n Nacional de Telecomunicaciones, CONATEL) demands all domain name registration under the .hn top-level domain (TLD) to be suspende, and all the lists and databases regarding said TLDs to be handed over, detailing the IP ranges and the responsibles. They did this under the argument that RDS-HN is an Internet Service Provider (which it is not Being a registrar means they are responsible for the well-keeping of public information and of handling a public good, the .hn TLD, not that they provide any kind of regulated service to individuals or organizations), with military personnel disguised as civilians (and who refused to identify themselves).
If you are interested, please read further on the 
A while back, Intel defined a 
Just under a week after 
Most of the Debian kernel team members are attending the
Here's another round of the semi-regular bulletin about FusionForge.
First item: FusionForge 4.8.1 was released this week. It's not
exactly an important update, but the 4.8 branch had been accumulating
fixes over time and we felt that it would be good to push these fixes
out. If you don't encounter particular problems, there's probably no
need to upgrade in a hurry.
A follow-up for the rewrite of the SCM subsystem: I now consider the
Bazaar and Git plugins complete. The missing part, in both cases, was
a proper integration of a repository browser and the collection of
commit statistics; since one of my clients wants to use Bazaar and
another one wants Git, both features have been completed recently.
The code still lives on a branch based off 4.8 (for people who need a
4.8-based instance), but it's also been pushed into trunk so the next
release will have it natively.
Another branch I've been working on (for clients) was about making the
Mediawiki plugin able to handle one wiki per project rather than one
shared wiki. This is now possible with yet another 4.8-based branch,
where the wiki creation is completely automated. A nice feature is
that the FusionForge identification is used as a basis for Mediawiki,
with different groups on the wiki depending on project membership and
role in the forge. That allows specifying wiki permissions in a
simple way, for instance to say that only project members can create
new pages, authenticated users can only edit existing pages, and
non-authenticated users are read-only. This code will be pushed to
trunk in the coming weeks.
Thanks to Alain Peyrat, we now have a
Recently I was viewing 
this weekend while giving a bit of TLC to the php packages, i
thought i'd finally get around to tackling 
Modern daemon implementations can be run in a variety of ways, in a range of contexts. The daemon software itself can be a useful tool in environments where the associated traditional system service is neither needed nor desired. Unfortunately, common debian packaging practice has a tendency to conflate the two ideas, leading to some potentially nasty problems where only the tool itself is needed, but the system service is set up anyway. How would i fix it? i'd suggest that we make a distinction between packages that provide tools and packages that provide system services. A package that provides the system service foo would need to depend on a package that provides the tool foo. But the tool foo should be available through the package manager without setting up a system service automatically. Bad Examples Here are some examples of this class of problem i've seen recently: 
Two organizations I care deeply about are having elections this month.
The first is the