Log

The ANGRY Whopper, with ANGRY onions and ANGRY jalapenos!

Hey, BurgerKing?! Your ANGRY advertisement just caused you to loose an ANGRY customer. Angry onions? Spare me. There's no way this ad wasn't made up by an American advertisement company. Well, guess what? I don't like companies making me feel stupid when buying their products, so I'll never buy one of your products again.

Hof veroordeelt bedreiger Balkenende tot celstraf.

Ik vraag me af waarom deze man wel celstraf krijgt, en iemand als Theo Maassen, die toch ook zo'n beetje heel de wereld al heeft bedreigd met de dood, niet. Lekker kieskeurigheid weer in Nederland. "Straf optreden, zolang we maar geen slechte publiciteit krijgen!". Want het is natuurlijk meer dan duidelijk dat Theo Maassen alleen maar vrijheid van meningsuiting vertoont, maar dat deze man een werkelijk grooootte bedreiging vormt voor Balkenende..

Als het zo door gaat in Nederland met de burgerrechten, dan zou het me niet verbazen, noch spijten, als er eens een paar mensen omgebracht worden. Balkenende moet dood, omdat zijn kapsel me niet bevalt. Zo, eens kijken of ze ook achter mij aankomen; heb gehoord dat het goed vertoeven is in zo'n gevangenis. Gratis eten; beetje tv kijken, en als ze je slecht behandelen, dan zoek je gewoon even de media op. Helemaal top.

Nederland holt achteruit. Nog even, en het is hier net zo gesteld met de burgerrechten als in die fijne U.S. of A.

(The latest version of this introduction to IPython can always be found here)

[todsah@jib]~$ python
Python 2.4.4 (#2, Apr  5 2007, 20:11:18)
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> print('hello')
hello

[todsah@jib]~$ ipython
Python 2.4.4 (#2, Apr  5 2007, 20:11:18)
Type "copyright", "credits" or "license" for more information.

IPython 0.8.0 -- An enhanced Interactive Python.
?       -> Introduction to IPython's features.
%magic  -> Information about IPython's 'magic' % functions.
help    -> Python's own help system.
object? -> Details about 'object'. ?object also works, ?? prints more.

In [1]:

If you're trying out Mako (the templating language) and you happen to get this error:

Traceback (most recent call last):
  File "/usr/lib/python2.4/site-packages/CherryPy-3.0.1-py2.4.egg/cherrypy/_cprequest.py", line 551, in respond
    cherrypy.response.body = self.handler()
  File "/usr/lib/python2.4/site-packages/CherryPy-3.0.1-py2.4.egg/cherrypy/_cpdispatch.py", line 24, in __call__
    return self.callable(*self.args, **self.kwargs)
  File "./pua.py", line 82, in index
    return Template('index', {'title': 'Title!'})
  File "./pua.py", line 35, in Template
    return(t.render(**vars))
  File "/usr/lib/python2.4/site-packages/Mako-0.1.8-py2.4.egg/mako/template.py", line 114, in render
    return runtime._render(self, self.callable_, args, data)
  File "/usr/lib/python2.4/site-packages/Mako-0.1.8-py2.4.egg/mako/runtime.py", line 287, in _render
    _render_context(template, callable_, context, *args, **_kwargs_for_callable(callable_, data))
  File "/usr/lib/python2.4/site-packages/Mako-0.1.8-py2.4.egg/mako/runtime.py", line 304, in _render_context
    _exec_template(inherit, lclcontext, args=args, kwargs=kwargs)
  File "/usr/lib/python2.4/site-packages/Mako-0.1.8-py2.4.egg/mako/runtime.py", line 337, in _exec_template
    callable_(context, *args, **kwargs)
  File "index_html", line 20, in render_body
TypeError: 'int' object is not callable

Check if your template lookup default_filters has an decoding for utf-8:

template_lookup = mako.lookup.TemplateLookup(
    directories=[path_templates],
    output_encoding='utf-8',
    encoding_errors='replace',
    default_filters=['decode.utf-8']
)

If it does, change 'decode.utf-8' to 'decode-utf8' (remove the dash). This will fix the error. No idea where it comes from, probably the utf-8 decoding doesn't exist. Me and Michiel now have both suffered from this problem, so there's bound to be more.

Theo de Raadt on virtualisation security:

> Virtualization seems to have a lot of security benefits.

You've been smoking something really mind altering, and I think you
should share it.

x86 virtualization is about basically placing another nearly full
kernel, full of new bugs, on top of a nasty x86 architecture which
barely has correct page protection. Then running your operating
system on the other side of this brand new pile of shit.

You are absolutely deluded, if not stupid, if you think that a
worldwide collection of software engineers who can't write operating
systems or applications without security holes, can then turn around
and suddenly write virtualization layers without security holes.

> Anything we can do to increase security, *including* setting up VMs (of any
> flavor) is an improvement [that also increased hardware utilization].

This last sentence is such a lie.

The fact is that you, and most of the other fanboys, only care about
the [that also increased hardware utilization]. The yammering about
security is just one thing — job security. You've got to be able to
sell increased harwdare utilization in a way that does not hang you up
at the end of the day.

Of course, de Raadt is right… in his own tiny little world at least. Running services which would normally run on multiple machines on multiple hypervisored instances on a single host machine would indeed be less secure than running them from multiple physical machines.

But running multiple applications on virtualized machines which would normally run on a single machine is more secure, simply because it adds another layer of protection.

But, as usual, de Raadt's complete ineptitude when it comes to communications totally negates any point he's trying to make and only serves to rile up people against his cause.

It's the chrooted story all over again. Yes, chroot isn't completely secure. Yes, chroot isn't meant as a security construction. Yes, running multiple services on a single machine that would normally be run on several separate physical machines is less secure. That doesn't mean chroot (and virtualisation for that matter) can't add an extra layer of security if used properly!

Theo de Raadt's problem is that he views security the way cryptography experts view cyphers: as an absolute. But security isn't like math. It's not absolute. There are right and wrong ways of doing security. De Raadt is like that security consultant who says: "You must have randomly generated passwords consisting of at least eighteen characters, lower and upper case, numbers and symbols, nothing repeated twice, completely unique and changed every week, or your being insecure!", all the while ignoring the fact that that kind of password policy will only force people to write down passwords on a yellow-note under their keyboards. In theory, they're right. In practice, they're wrong. These people become blinded by their own viewpoint. Just as these so-called security consultants are blinded by their belief that strong passwords equal security, so is Theo de Raadt blinded by his belief that virtualization doesn't improve security.

Perhaps it's time to stop listening to de Raadt, and start listening to people with a broader overview of the situation.

(This article is also available here)

(more…)

Dutch minister of Justice, Hirsch Ballin, is being pressured by dutch christian and labour parties to force Dutch ISP's to start censoring the Internet:

A translation of the dutch NU.nl article:

AMSTERDAM – The NOS [Dutch Broadcasting Institute] on friday reports that a majority of the Dutch parlement have demanded that internet providers be forced to block child pornograpy.

Currently, providers have the freedom to cooperate with blocking activities, but they are not required to. The Korps Landelijke Politiediensten [red; Dutch National Police Corps] keeps a list of websites that spread child pornography, which ISPs can use to filter. The UPC cablecompany is the only one currently using the list.

The CDA [red; Christian Democrats], the ChristenUnie and the PvdA [red; labour party] parties have demanded that minister Hirsch Ballin forces ISP to start blockin child pornorgraphy, according to the NOS. The topic has been a long-running point of discussion between Hirsch Ballin and Internet providers.

First off, I'd like to explain that I am NOT AT ALL for child pornography or anything of the sorts. That said, censorship is never the solution to a problem. If you're thinking 'But what about..', NO! Censorship is never, ever the solution to a problem.

Now, who is this blocking of child pornography supposed to help (or stop)? There are only three possible answers: The children, the people trying to get their hands on child pornography or the people who accidentally stumble upon child pornography. Does this solution really help any of these parties? No. Children featured in child pornography are already hurt, so it doesn't help them. Paedophiles looking for child pornography aren't going to be stopped by this blocking. They'll simply use any of the existing routing networks such as Tor, which don't allow blocking, or they'll find some proxy in a foreign country. The only party it might help are people not actively looking for child pornography but who see it by accident. But come on, have you ever encountered child pornography by accident?

A big problem with this kind of blocking is that it is about fighting symptoms instead of causes. We shouldn't be blocking this content; we should be prosecuting the people hosting it and those that are actively looking for it. By blocking child pornography you run the risk of hiding the actual problem. It appears as if something is actively being done about child pornography, but the problem is still there; except now it's hidden from the public's view. And paedophlies? Where will they go for their needs? Underground, perhaps, making them harder to trace? Or will they simply create their own supply, harming even more children in the progress?

Another problem is that once you start censoring, where do you stop? Right now, the Dutch government is planning on blocking child pornography, terrorist sites and sites with content possibly useful to terrorists (bomb-making manuals, etc). Next up? Who knows? Sites presenting views our government doesn't agree on (anti-religion, discriminating sites, right-wing, left-wing)? Where does it stop? As we all should know, when looking at history, it won't stop anywhere. The entry barrier to censoring is high, but after that it's just like dancing: Getting on the dance floor and making the first step is hard, but after that, all bets are off.

And something that hasn't been discussed by our government is: Who monitors the monitors? Right now, there are no plans for actually making anybody accountable for what gets on the censoring list and what doesn't. Smells ripe for abuse to me.

So we're looking at a system that won't actually help anybody. A system which, in fact, will do more harm than it'll do good. A system that's open to abuse and can only lead to an uncontrollable, unmonitored system.

Sounds like another good idea by our government to 'think of the children!!'.

I have given up on PHP. I will still need to use it at my job, but in private I refuse to even touch it anymore.

Lately, I've been busy creating a framework, or a bunch of libraries actually, which where meant to negate some of PHP's worst qualities. It had better error reporting (the kind you can't just ignore), logging, sane naming schemes, better configurability, etc. But at every turn, it felt like PHP was actively trying to fight my efforts at overcoming its obscene shortcomings.

I will not rehash here those shortcomings of PHP, except that it's a pathetic excuse for a programming language written by a bunch of particularly bad programmers. The same goes for PEAR. They're simply horrid.

Some time ago I wrote a little web application in Python, and I actually had fun doing it. It felt liberating not having to fight your programming language every step of the way for once. I revelled in the professionalism with which basically everything in and for Python is constructed. It's invigorating to work with libraries that aren't written in a fundamentally broken way just so the authors can use every Design Pattern under the sun.

It's not strange that Ruby (On Rails) has become so popular. Even though Rails is severely limited in its abilities, people will gladly put up with it because of Ruby. Anybody speaking in favour of PHP compared to Python or Ruby simply hasn't worked with either Ruby or Python, or has never done anything significant in PHP. Or, like me, where so blinded by how much time they've invested in PHP, that they couldn't and didn't want to admit what a total piece of crap PHP really is.

Thank you, PHP, for finally exposing yourself as the leper you are. Our ways part here, and may I never run into you again. I'm running off with Python, and we'll live happily ever after.