I just finished rewriting an old firewall tool from Perl to Python. Since it's in Python and about firewalling I dubbed it Pyroman. I investigated a dozen of firewall-tools before, including shorewall and firehol. Each had it's stength and its weaknesses. After writing iptables rules in a shell script every now and then for a more complex project (with like 6 networks of which 3 are bridged together) and two dozen of differently configured hosts, NATs, VPN, everything. My predecessor had written a shell script to configure the firewall, but this was really bad to maintain. So I ended up writing a perl application to generate the rules from a modular configuration (read: usually one file per host, containing a perl hashmap) Well, after happily using this script for two years, I dedcided it's about time to rewrite it and document it extensively. I chose python for the rewrite. You can get the result here: Pyroman 0.1.1. The good:

• Written in pretty python
• Extensively documented (Python docstrings)
• Much faster than sh+awk based solutions
• Really easy syntax to add hosts, nats
• You can add custom iptables rules when needed
• Designed for complex networks
• Lots of verification checks done before execution
• Designed to use the same configuration files on multiple hosts (e.g. failover firewalls or the destination host itself; it will detect if you are talking about a local or a remote host
• It will report file name and line number on parser errors, verification errors and execution errors.
• If any rule fails to setup, a rollback will occur, restoring your previous firewall
• (will likely have auto-rollback if you lock yourself out in the next version with a simple timer)
• Extensive configuration example

The bad:

• Not yet tested in production
• Doesn't completely hide iptables complexity (some core config files are just containing iptables rules, but why invent a new syntax?)
• Only iptables, no TC/Shaping, no IPsec, proxy arp setup, VPN, ifconfig (I use other tools for that, e.g. heartbeat)

To tease you a little more into testing, here's an example host configuration: ("dmz" is an interface alias - where the web server is connected to -, as are "INT", "DMZ" and "ANY" for clients on these interfaces)

"""
A really simple webserver configuration.
These examples are just boring... ;-)
But without NAT they would be even more boring. ;-)
"""
# web server
add_host(
        name="web",
        ip="10.100.1.2",
        iface="dmz"
)
# offering, well, web service.
allow(
        client="ANY DMZ INT",
        server="web",
        service="www ssh ping"
)
# internal hosts may access FTP, too
allow(
        client="INT",
        server="web",
        service="ftp"
)
# setup NAT
add_nat(
        client="ANY INT",
        server="web",
        ip="12.34.56.80"
)

(Yes, this is a python script. No, you probably won't care to write your configuration in a programming language, will you?)

Sun! Sunlight is a wonderful thing. Yesterday I came back from a six day vacation in Madrid. The weather was not warm, a bit warmer than in Finland, but especially it was dry and sunny. Pretty good autumn weather, actually. The best week I've had for a while. This was my Quest for Sun '05. I stayed at Amaya's place, slept well and long every night, had a wonderful time with some Debian people, and walked outside and visited a couple of wonderful art museums. Thank you, especially, Amaya, Holger, and Miriam. And also vi and emacs, the feline foot fetishists who rule Amaya's apartment. I took some pictures. They're touristy snapshots, not meant to be art. I meant to make notes about my experiences during the week, but the nice, classy Moleskine notebook I bought especially for the trip got lost the first full day. Some moments stuck into my mind, however.

• Amaya's cats attacking my feet while I slept. At one point, one of them sat on my knees for a while and pounced every time I moved in my sleep.
• Tapas is a very good never-ending style of food. It just keeps coming: every time you get to the end of the plates you now have, the waiter brings more.
• Food in general was very good. Even cheap fast-food like kebab.
• Art museums in countries with a long history of art are bloody big. Both the Museo del Prado and the Museo de Arte Thyssen-Bornemisza seem to require about seven straight hours for a proper visit (I spent about three at each, and saw half of each). I think this is so that people will attract fewer cats by being too tired to move their feet during the night.
• Telling the history of love, bed, and sex to Amaya and Holger over a meal. I really should write that down some day. (They're editors.)
• One of Amaya's cats is crazy and likes showers. Or at least likes to sit in the shower after someone's used it.
• The Retiro park is wonderful. I could spend a lot of time just walking about in it. I did.
• Food in Spain is good. Spanish eating times are crazy, but you get used to them.
• Me: "Back when I was working on Kannel...". Person next to me: "Oh you worked on Kannel? It is such a nice program". Moments to live for. Enough to motivate me to write and publish some more free code.
• "Gracias", "buenos noches", and "de nada" is enough Spanish to get you live well for a week. Helps to have native speakers as guides, of course.
• Did I mention that the food is great?

Since the Quest for Sun '05 was a success, I definitely will do it again. A week of light (and sleeping properly) really improved my mood. Maybe even enough that I will be able to deal with the remaining months of dark, gloom, wet, and cold of the winter in Helsinki. The only big negative thing about this trip was flying. I suggest that international air travel henceforth shall be called "The Cattle Drive".

My "test" boxes (well, they are in fact production systems) are now all up and running SELinux with a "strict" policy and in enforcing mode, after some weeks in "permissive" mode to detect the last missing policy rules (well, maybe I'm still missing something in cron.monthly?) What took most of the time was in fact to write policy for some services or custom applications that didn't have one before. And that I basically was just checking the logs every day to see if some new audit errors had appeared. Oh, and inbetween we completely emptied the server racks and their wiring and redid the room... Just to mention a few things that were "missing": My OpenVPN is running a custom script to update DNS on login and logout, which obviously was missing from the SELinux policy. I'm also using heartbeat to failover between the two firewalls and two mailservers; that policy took me probably one hour (without much previous experience) to write. Then I have another custom LDAP to aliases for a Lotus directory (which hopefully will be replaced by a sane application soon... whoever invented "implicite email adresses" should be shot. Just put all email adresses into the directory, so any app can look them up without trying to guess what your generation rules are... firstname.lastname@domain.tld sounds easy, but what with non-ascii characters?) Anyway, the systems are doing pretty well. Maybe I'm going to enabled SELinux on the web server next. ( (cra-)PHP and typo3 will probably make that more difficult, though...) Oh, and I need to sort out which of my policy changes are local changes, and which I should feed "upstream".

I think I agree with Ian Holsman's analysis of this article on "How to make money from open source" - actually I would go a bit further. Ian says that you don't need to be a committer to make money from open source. Indeed, in some ways the big question in terms of "open source economics" has been how to more tightly couple the people doing the valuable work with some percentage of the rewards - at least enough to let them keep hacking. While it's evident that open source works, and that there are big economic benefits involved, it's a tough nut to crack in terms of renumeration for people working on stuff. Selling software is, if nothing else, a really simple mental model that is very easy to grasp - you write software, you sell it. If it's good, people buy it and you can either reinvest that money, or take it as profit. Open source software that scratches an itch has immediate benefits to the author, especially if the author manages to get other people on board to help out. But the category that's not really covered is the group of people writing something "out of the blue" because they think it's a cool idea. If it is, and it takes off, they really aren't guaranteed anything at all for their troubles. I don't see too many ways around this while still playing by the rules of the game. There are some clever ideas like dual licensing, but they aren't applicable everywhere. I suppose you could declare software a public good and get the government involved in its production, but I'm not very enthusiastic about that... In any case, it's an interesting topic, and perhaps some day clever entrepreneurs will find better ways of financing the production of open source software.

The opening of AnimeFest went great - there were few cosplayers and a huge lot of general public. Anime is on the high.
The fest was opened by two cute girls - one of them was speaking in Latvian and the other in Russian. At first they were translating each others lines both then they diverged and even started a small dispute. You had to know both languages to "get" the joke, but I think most of the people in Latvia do know Russian enough for that.
The opening program consisted of "Howl's Moving Castle" - a truly wonderful anime movie from the same director as the "Spirited Away". A great fairy tail as expected from Studio Ghibly.
Also:
I have no idea why, but I would like to check out half of it, please :)

Via Ugo Cei I found this reading list: http://www.joelonsoftware.com/articles/FogCreekMBACurriculum.html, some of which looks to be interesting, but I'm not convinced that it's a selection where each book is a 9 or a 10. Books like the Mythical Man Month stand the test of time, and some of the books there are good ones by that measure, others look less convincing, at least judging by their contents (too focused on the 90ies, the bubble, a particular company), or some of the reviews on Amazon. Perhaps those aren't always worthwhile, but the real winners don't seem to have much flack thrown at them. I'd enjoy hearing why Joel et al. recommend them. I've read these:

• Crossing the Chasm
• Information Rules: A Strategic Guide to the Network Economy
• The Computer Consultant's Guide : Real-Life Strategies for Building a Successful Consulting Career
• The Innovator's Dilemma

in addition to Microeconomics (6th Edition) as a textbook on Economics. What are your recommendations? All things considered, though, I have a hunch that it would be better to be out trying to *do* rather than reading books about doing...

(Reposted from old blog) Inspired by Matthew Palmer’s writings (1, 2) on his experiences about the Australian judicial system, I decided to write a series of essays on the Finnish legal system, mostly to contrast it with the universally familiar United State system (even if that universal familiarity is a little skewed by generally having been obtained from dramatizations and not actual court practice). I will concentrate on criminal cases. I will write based on my personal experience as a part of the judicial system, and I will be supplementing the experience with my personal research into law. I am not legally trained, but I have read a fair bit of law and related literature. I am a lay judge in the Jyv skyl District court. I will explain the significance of that later, but I hope it suffices to say, here, that I have sat on the bench, as part of four-judge panels, since March this year, in ten sessions each a day long, and each containing at least two, usually four or five criminal cases. Some highlights:

• There are no plea bargains. With some minor exceptions, every criminal case is tried in a full court session.
• There is no jury. Criminal cases are tried as a rule by a panel of four judges, of which one is legally trained and three are lay judges, each having an equal vote.

Later essays in this series:

• The main hearing in a Finnish criminal trial (November 16, 2005)
• The Finnish lay judge system (November 16, 2005)

Fictional depictions of court cases in this series:

• Driving While Intoxicated – A Glimpse of Finnish Criminal Justice, Part One

Read more

Thanks to Algernon, I also discovered my true Perl name:
''=~('(? '.('^/@@[ '^'.])./]').'"'.(':^@@]/ /,;_'^' +..<]]*@@] ').',$/ )')
Isn't it crystal-clear?
...Seems I'll have to repeate Algernon's hint: Perl, enter, paste, Ctrl-D.

I claimed yesterday that the council of minister looks very much like an upper house of a bicameral parliament. It is somewhat unusual in that the members are not chosen for a certain term but serve by virtue of holding an office in a member state, but it is not a decisive unusuality. Martin-Éric Racine countered: No, it is not. The council is bureaucracy overruling the Parliament, thus invalidating the very principle of democracy. We have seen this in action with the new EU Patents law: the Parliament had passed several amendments to the original proposal, yet the Council ended up ignoring those democraticly voted amendments and passing an even worse legislation than the original draft. This is clearly different than what happens between a higher and lower chambers each examining new legislation before it is ratified. Wouter Verhelst already said most of what I would have said myself; the bottom line is that Martin-Éric is mistaken about the powers of the council of ministers. Does he by any chance confuse the council of ministers and the commission? It would explain his calling the council a "bureaucracy", which it really is not. The power balance between houses in bicameral parliaments varies. My claim cannot be dismissed just because the two organs do not work exactly like the English parliament, for example. An important thing is that the lower house is almost always directly elected and the upper house comprises often representatives of areas or member states. Finally, I would like to note that the bicamerality of the EU parliament system is independent of my claim that the EU is a country; if a non-country can have a parliament, it certainly can have a bicameral parliament. So you don't have to rebut it just because you don't believe in my claim about the countriness of EU. Oh, BTW, Martin-Éric, please don't mess with your posting dates. It makes your postings to appear more recent in PD than they actually are and to float to the top, where they obscure legitimately new postings by others. For example, your response to my previous posting appears much later in PD than Wouter's reply to it.

Jordi Mallach expressed fear, uncertainty and doubt about the European Union Consitution. I would like to make the following two points:

1. Much of what is in the proposed Constitution is already in force as part of the current foundational treaties. So, if you read the Constitution and want to bash it, please read also the current treaties. I expect you to find it to be clearer and content-wise quite similar to them. So don't think that this document is an evil attempt to seize power or something (well, it might be that but I doubt it).
2. A change to the current foundational treaties would be necessary in any case. The acceptance of new member states makes decision-making by the current rules difficult, if not impossible.

I assume most of the FUD spring from the grand name of the new document, a Constitution. It deserves the name quite rightly. It is the sole foundational document after it is accepted, replacing quite a few treaties. However, its impact is mostly illusory. A similar change was done in Finland a few years ago, when the three constitutional statutes (none of them called the Constitution) were combined and updated into a single law called the Constitution. (Long-time Debian developers probably remember my ill-conceived ITP from four years ago:) Perhaps this FUD is exactly why the consitution should not be subjected to referenda. I don't doubt that Jordi is not alone in his feelings, and such feelings could easily cause it to fail in a referendum. The only effect of such a failure would be making decision-making in the EU painful, without actually addressing the issues people have, such as Jordi's regional issues.

''=~('(? '.('[_@@*@'^'+-).^ ').'"'.('>,<%_@/@ '^'_@[@-.@.^').',$/ )')

Generate your own perl name! Sick, sick, sick, but I love it. Hint: run perl, paste the code, and hit ctrl+d

I've found a couple of issures with my SELinux backports. One is actually a bug present in sysvinit and cron (at least): The debian/rules makefiles uses dpkg-architecture to detect a Linux system (as opposed to GNU hurd or FreeBSD or Solaris) since SELinux only works on Linux. This code queries the DEB_HOST_ARCH_OS variable via dpkg-architecture, but this variable isn't available on sarge (yet)... When building with either my dpkg backport or by using code similar to the following:

dpkg-architecture -qDEB_HOST_ARCH_OS   dpkg-architecture -qDEB_HOST_GNU_SYSTEM

the packages will actually have SELinux support enabled. I've already filed a bug against sysvinit, but should I also file bugs against logrotate and cron, who apparently use the same code to detect SELinux? (openssh and coreutils have better fallback code than suggested above in place)

Since interviewing the creator of Ruby on Rails, David Heinemeier Hansson, I've been thinking a little more about what he calls "opinionated software." That handy little phrase seems to sum up what attracts me to a lot of technology, at all levels. What I like Free software--it's not really economics that drew me to free software, but the principles and aims. When you release or use free software, you're exercising your right to free speech and adding your voice to an argument. Desktop environments--GNOME 2.0: The move from GNOME 1.0 to version 2.0 was highly opinionated (Mac users, think OS 9 to OS X). Complexity of user interface was thrown out in favour of sensible defaults. Web standards--CSS, RDF, XHTML: not only is there a right way to do things, but it turns out to be better too! I don't automatically fall in love with everything that emerges from the W3C, but some things are so obviously the right way it's impossible not to love them--warts and all. Muine music player--this player throws out the paraphernalia of iTunes clones and gets you close to the music. Queue, play. What I want to do. Epiphany web browser--a simple text bar does for bookmark lookup, search and URLs. The bookmarks work like del.icio.us tags. Despite the lure of Firefox extensions, simplicity and efficiency keeps me with Epiphany. Make friends and enemies The thing about opinions is that people are inclined to disagree with them. Opinions won't please everybody and, being opinionated, you will never carry everybody with you. But opinions give you something with which to scythe through indifference. In both my writing and software development work taking a particular stance enables me to create interest, and gives direction to my projects. I tend to get bored easily, and if I'm bored, then my readers and users will never make it. Being opinionated in software development is easier when there's a strong leader, or it's a one-person project. It's more of a dilemma if you're running a free software project with multiple contributors. Such projects need such contributions, but run a risk of losing focus and style. I think that there we need to be brave again. If being opinionated means losing potential users, it also means losing potential contributors. Opinions help in dealing with users, too. It's obvious that the mere act of listening to users isn't good enough. They often won't say what they mean, or their requests mask a deeper issue. How often have you given your boss exactly what he asked for, to find it wasn't what he wanted? A combination of reading-between-the-lines and having opinions helps cut a way through the noise of user feedback. Stirring the pot Here are a few wishes for some free software projects that I want to see succeed further, but which really need to get opinionated to be effective. These projects aren't failing, but they're not reaching the potential I know is there. Each of them are infrastructural in some way, and that's probably where the temptation to avoid being opinionated is strongest. But here's the genius: the rewards of being opinionated here are high. Ruby on Rails is the existence proof.

• Beagle, live search technology for GNOME. Needs to decide where its primary use will be, and get on and hit the 1.0 point for that use only. Choose one or two neat applications for integration, and be so utterly cool that every other app author flocks to integrate too.
• Synchronization. First MultiSync, then OpenSync, have rumbled on for ages, without ever being truly effective for any particular device. My take: choose a few "must-have" target devices--say, iPods and Nokia phones--and make them work completely. Nearly-but-not-quite pleases nobody.
• Mono. Mono's great, but where's the story? There's loads of potential in the people and the ideas behind the project, but playing catchup with Microsoft isn't very inspiring. Early projects like Muine helped Mono's cachet here, but we need more. My personal favourite option would have been a completely free alternative to ASP.NET for web applications. (I've seen a project called MonoRail, but don't know if it's the one...)

What's better? A handful of users with the "right" idea about how fundamentally important you are to everything, or loads of users who only see a portion of the capabilities of a project? Copy the experts It may seem like cheating to copy Apple's lead, but a lot of what they've done in OS X is to take a stand on what's useful and not. On many occasions this has inconvenienced people, but it's not eroded that special lure that Apple products hold. There's not harm in asking "What have Apple done?" with some of our projects. Another poster-child for being opinionated is Ubuntu Linux. Technically, it's only marginally better than other Linux distributions. Strategically, it's miles ahead. Its founder, Mark Shuttleworth, had very solid opinions about where Ubuntu should go, and pursued them. Over time, these have pervaded the product itself, but at the start it was the message and the style that made the difference. Opinions not expressed are rarely effective.

Andrew: to work out the fourth Thursday of the month, use this instead:

function nth_day($instance, $dow, $month, $year)

  $first_dom = date("w", mktime(0, 0, 0, $month, 1, $year));
  return 1 + ((7 + $dow - $first_dom) % 7) + 7 * ($instance - 1);


Or, using Zeller s rule and avoiding function calls:

function nth_day($instance, $dow, $month, $year)

  if($month < 3) $year--; $D = $year % 100; $C = (int)($year / 100); $m = 1 + (($month + 9) % 12);
  $f = 1 + (int)((13 * $m - 1) / 5) + $D + (int)($D / 4) + (int)($C / 4) - 2 * $C;
  $first_dom = $f % 7;
  return 1 + ((7 + $dow - $first_dom) % 7) + 7 * ($instance - 1);


Update: thanks to Andrew for spotting the error in the second version. Due to my misunderstanding of a hack in Zeller s rule, I had forgotten to decrease the year when the month was January or February. Also, PHP was not doing proper integer divisions and I had to cast results back to int despite all operands being ints.

Well, there's nothing like posting a really rubbish program to your blog to find out the right way to do it. Firstly, Philipp Kern has come up with another, even shorter version than his version I posted in the update to my original Ruby post, this time blowing me away with the strangeness of explicit casts in Ruby. Apparently, casting an input stream to an array produces an array with one-line-per-element, as in this example:

 STDIN.to_a.sort_by rand .each l puts l 

As Philipp warns, however: "Ruby is full of fun and power; one must watch out that the scripts remain readable". For a fairly toy example, this solution is still fairly readable, however I can see hair growing on this thing if your program grows large. Next, Pierre-Charles David showed his qualifications for becoming a co-author of the next edition of the Pickaxe (AKA "Programming Ruby: The Pragmatic Programmers' Guide"), with his example and explanation. He's kindly given permission for me to reproduce his e-mail in it's entireity, since it's too good to chop up:

Here is the shortest and most readable version of your "randomize stdin" script I can think of:

  #!/usr/bin/env ruby
  print ARGF.readlines.sort_by   rand  
 

ARGF is a special variable representing either stdin or, in the case where file names are passed on the command line, the content of these files (think of Perl's <>). ARGF behaves like an IO object (although I think it is not one). In particular, it responds to the #readlines method which splits the receiver's content into lines and returns an array. In other words,

  lines = ARGF.readlines
 

is the idiomatic way of doing

  lines = []
  while line = gets() do
    lines << line
  end
 

in your example. The next part (sort_by) uses a new form of the sort method, which I think is not documented in the Pickaxe. It implements the Schwartzian transform technique. In essence, a random number is associated to each element of the array, which are then sorted based on this index. As a general style remark, note that although Ruby supports "while" and "for x in y" loops, they are rarely used, in favor of iterators and/or higher order methods. For example, to gather all the input lines in an array without using readlines, one might write

  lines = Array.new
  ARGF.each_line    l  lines << l  
 

or

  lines = ARGF.inject([])    lines, l  lines << l  
 

Hope it helps, and welcome to Ruby!

Pierre, your explanation definitely helped, and I hope it helps others too. The third person to help me out is Decklin Foster, through a post in his blog. What particularly caught me about his solution was the neat demonstration of another feature of Ruby which I think I will really learn to love: the ability to dynamically add methods to an existing class. "Aiee!" I hear all the purists scream -- and I can see the potential for severe misuse, too. But, since every good idea seems to get deeply perverted, we may as well have some real useful features to pervert while we're at it. Decklin has the clever idea of adding methods to the Array class that shuffle the elements of the array in a random fashion. His code is beautiful in it's simplicity:

 class Array
    def swap!(a, b)
        self[a], self[b] = self[b], self[a]
        self
    end
    def shuffle!
        each_index do  i 
            j = i + rand(length - i)
            swap!(i, j)
        end
        self
    end
 end

He then goes on to rewrite my bumbling example in probably the most comprehensible manner I've yet seen:

 STDIN.readlines.shuffle!.each    line  puts line  

Decklin writes, "Now that is cool.". I couldn't have put it better myself. My thanks to Philipp, Pierre-Charles, and Decklin, for helping me along the Ruby path. So, two new Ruby Rules for me to live by:

• Whenever you reach for a while, first take a good look around for any iterator methods which might apply.
• Never dismiss the power of defining your own methods on an existing class if it will improve the comprehension of your program.

Hmm, is it possible that Ruby is nothing more than Functional Programming by Stealth? Aiee!