This is just false. Macro-economics is not just micro-economics on a larger scale. Governments are fundamentally different: your mom-and-pop store cannot print money, cannot raise taxes, does not have a AAA rating on the international financial markets, does not have a central bank as a lender of last resort, and does not have to take multiplier effects into account when trying to reduce a deficit. And governments don't have to (and shouldn't in many case) balance their budgets - it's okay if the national debt grows perpetually, as long as it grows slower than the economy.

Well, the court says that: 1) Article 21 of the Dutch constitution requires the government to protect the environment; and 2) the government has signed treaties (which are legally binding) committing the Netherlands to reducing CO2 emissions. So arguably the court is just telling the government to obey the law. Which is not on the face of it unreasonable.

Now, it may not be a great idea if courts start setting specific emission targets, but the 25% is actually the bottom end of what the IPCC considers necessary. (The plaintiffs demanded 40%.)

According to Wikipedia, that makes you slightly shorter than the average Dutch male, but significantly taller than the average Dutch female, so it's not surprising that you would be taller than most people.

Maya has been available for Linux for years. See http://www.autodesk.com/produc...: "Available for Windows, Linux, and Mac OS X operating systems." It's just the free trial that isn't available for Linux.

A long time ago, I saw Bertrand Meyer (the Eiffel guy) give a keynote at ICSE, where he pointed out that the "given enough eyeballs, all bugs are shallow" claim is unscientific, because it can't be falsified: if a bug is not found, people can always say that there were not enough eyeballs, so "Linus' Law" still holds.

Of course, Krugman, a Nobel prize winning economist, does actually know about the broken window fallacy:

Mind you, Keynesians don't actually propose that the government should go around smashing windows, given that there is plenty of useful infrastructure spending to be done.

Having said that, military spending apparently has a negative multiplier, so it may be a bad idea even if you're down with Keynes.

How is systemd's use of D-Bus a problem for anybody? Do you have any evidence that its use of D-Bus is causing a performance problem anywhere? D-Bus is not an appropriate IPC in every situation (e.g. if you need to send huge amounts of data), but for systemd's usage scenario (sending occasional messages between processes), it seems perfectly fine.

The claim that systemd is somehow causing "tivoization" makes no sense whatsoever. If the systemd developers feel that it's fine for proprietary code to make API calls to systemd via D-Bus, then so what? They're not forcing anybody else to use D-Bus. (Systemd is licensed under the LGPL, by the way.)

This is just more anti-systemd FUD very light on actual facts.

First you assert that it's somehow a bad thing that systemd uses a standard, established IPC mechanism (D-Bus). Would it have been better if it had invented its own?

Then you claim that a crash of one systemd daemon "might" cause deadlocks/hangs/crashes, but you don't give any example. What daemons are intertwined in such a way that a failure of one would bring down the system? As far as I know, you can kill any systemd daemon (other than PID 1, obviously), and systemd will notice and restart it. Daemons like systemd-journald even use systemd's watchdog mechanism to ensure that they get restarted in case of a hang. In other words, systemd provides a much stronger basis for a reliable system than SysV init.

Fun fact: I just did a "kill -9 -1" to kill every process in a NixOS VM except PID 1. Systemd restarted every system service perfectly. Try that on SysV init.

Your post captures what most anti-systemd posts have in common: it spouts reasonably-sounding slogans ("Unix philosophy!", "dependency hell bad!") - which have nothing to do with how systemd actually works.

Take the supposed dependency hell. In reality, systemd has a fairly small number of dependencies, almost all of which are already ubiquitous on a modern Linux system (e.g. libacl), and many of which are optional (e.g. PAM). Gnome depending on systemd is hardly systemd's fault - if systemd provides useful functionality that Gnome wants to use, then why does that count against systemd? In any case, it's irrelevant for your "stripped down and hardened server", because surely you're not running Gnome there.

Or take the Unix philosophy. I'd say systemd (as in the PID 1 program) exemplifies the Unix philosophy: it does one thing, namely managing system services, and it does it really well. Now, systemd the *package* contains lots of other stuff, but most of it is optional. For instance, it does contain an NTP client now, but you don't have to use it. In fact, there even is a configure flag to disable it at build time. Also, the existence of systemd-timesyncd in no way prevents you from running whatever NTP client you want under systemd.

The idea that systemd is only relevent on the desktop could not be further from the truth. I would say it's even more relevant on servers, where I expect services to be managed reliably. SysV init cannot do that. (E.g., there is no guarantee that after "/etc/init.d/httpd stop" all httpd processes are really gone. It cannot even tell me if a service is currently running.) Systemd can. It cannot imagine going back to a situation where I can't do "systemctl" or "systemd-cgls" to get an overview of what is running on a system, or do "systemctl status " to see the status of a service, including its most recent log messages.

It's so simple that it's broken. See for example http://utcc.utoronto.ca/~cks/s... for a nice overview of all the limitations of SysV init, the most important being that it doesn't actually keep track of what services are running and what processes belong to what services.

You've just answered your own question. It's a problem because it requires programmers to concern themselves with low-level tedious details that the compiler could handle for them - details that they are in fact likely to get wrong. (E.g., you have to pass the correct size value, you have to remember to check it everywhere, and so on.)

Decades of buffer overflows should be sufficient evidence that this is not a good approach. Unfortunately, many programmers stubbornly refuse to see the obvious.

Now you're propagating sensationalized British tabloid stories yourself, as explained here.

The prisoner voting thing was a decision by the European Court of Human Rights, which is not an EU institution. If you want to criticize the EU, please inform yourself a bit better first.

Regarding immigration: yes, you have to let those foreigners in because that's what your government agreed to after a democratic process. In fact, the UK has traditionally been one of the biggest supporters of freedom of movement...

Or maybe he wasn't "criticizing" them but was just reminiscing about the old days when interviewed for this book?

I have driven in several states in the US and haven't noticed traffic being more "aggressive" than in the Netherlands. But that's of course anecdotal.

You're wrong. There were 9.6 million traffic citations in the Netherlands last year, on 10 million people with a driver's license. That appears to be a lot more (per capita) than in the US. The book "Traffic" by Tom Vanderbilt suggests that the much higher enforcement level may be the reason that the number of traffic fatalities is much less in the Netherlands than in Belgium (3.9 vs 8.1 per 100,000 according to the map).