Centering in CSS is not easy. But each time I must vertically center, I must search the web to convince myself that I have no choice other than using a hack. So I found it comforting to see this admission, coming from the W3C itself:

I hate firewalls. One of the first things I do on any personal Windows I install since Vista is to disable Windows Firewall. Usually, that's all it takes... plus disabling the maintenance center's firewall monitoring so it stops harassing you about the firewall, of course.

So when I noticed my PC's Apache was no longer reachable from other machines and that it would no longer ping, Windows Firewall did not come to my mind as an obvious suspect. Only after I realized that the problem started shortly after I joined the install to the entreprise domain did I start suspecting that some GPO was now forcing the firewall. Of course, I then went to check the firewall's status, using the maintenance center. In order to check its status, I clicked Turn on messages about network Firewall. The maintenance centre then displayed:

In English: "The Windows Firewall is disabled or configured incorrectly."
I was quite sure the firewall wasn't configured incorrectly, since the only configuration I had done was to disable it, so I assumed the firewall was disabled and proceeded to waste at least 10 minutes in further troubleshooting before finally realizing that the damn firewall was actually enabled... despite the button offering me to "Enable now".

In the end, this had nothing to do with Group Policy. The problem is you can't even directly turn off the firewall completely; you have to disable for every network type: private, public and - when you're on a domain - domain networks, which wasn't done on my install. So I clicked Disable Windows Firewall, closed the window, and proceeded to verify that the network was working again - which, of course, was not the case. After trying to reset the network card without success, I went back to the panel to notice that my change hadn't taken effect. Great, so for that specific panel, your changes are discarded without warning unless you select OK.

Conclusion

If your Windows machine's networking stopped working after joining a domain and won't even send ICMP replies, do verify Windows Firewall, and do so by going to the configuration panel and to the Windows Firewall panel. And if you need to disable it, select OK.

Addendum

After more issues with Windows Firewall, I dedicated it a new post.

This semi-random Debian package list with several KDE elements suggests it tries to portray itself that way.

I switched my TP-Link TL-WR1043ND v1 from TP-Link's firmware to OpenWrt 15.05 "Chaos Calmer" a couple of weeks ago. Besides errors when trying to connect from PPTP clients, there were no unfortunate surprises.

I was happy to see OpenWrt now includes a web interface (LuCI) enabled by default. It is not exactly the user-friendliest, but I found my way easily enough.

Although I did not do much with it, I found a few bugs, notably:

• Broken realtime graphs
• ddns-scripts sending unencrypted passwords without warning
• SSH server (Dropbear) apparently only accessible from LAN, despite the configuration

The documentation is extensive, but its quality is poor. Installing while playing safe took me quite some time, though part of that was due to a bug in the previous firmware not accepting long filenames. Overall, I am not impressed, but I have no regrets. Coming from a bunch of volunteers, fair software.

I eventually realized that we have been experiencing "constant" intermittent wireless connectivity problems in 2 locations of the house. One of these is a decameter away from the router. The other is slightly more, but at the same floor and there is no exterior wall in between. At times, there was high packet loss and extreme latency. After discovering OpenWrt bug #12372, which possibly persists in OpenWrt 15.05, I suspected that our issue might have been a symptom of this bug, but the same problem persisted after going back to the manufacturer's firmware or to DD-WRT, so I ended up replacing with a TP-Link Archer C8.

Today, I realized my PPTP connections from Windows 7 and 8 machines were no longer able to connect to the PoPToP server I setup at the office. Strangely, nothing had changed on the server (still Debian 7 running PoPToP 1.3.4), on the server-side router, and my clients obviously had not both been changed enough to explain the breakage. The Windows error messages were not too precise. Server logs were also unhelpful, apparently pointing to a bug in PoPToP, which timed out after 30 seconds:

Oct  3 16:47:25 deimos pptpd[24176]: CTRL: Client 173.178.241.108 control connection started
Oct  3 16:47:25 deimos pptpd[24176]: CTRL: Starting call (launching pppd, opening GRE)
Oct  3 16:47:25 deimos pptpd[24176]: GRE: Bad checksum from pppd.
Oct  3 16:47:55 deimos pptpd[24176]: GRE: read(fd=6,buffer=804f620,len=8196) from PTY failed: status = -1 error = Input/output error, usually caused by unexpected termination of pppd, check option syntax and pppd logs
Oct  3 16:47:55 deimos pptpd[24176]: CTRL: PTY read or GRE write failed (pty,gre)=(6,7)
Oct  3 16:47:55 deimos pptpd[24176]: CTRL: Reaping child PPP[24177]
Oct  3 16:47:55 deimos pptpd[24176]: CTRL: Client 173.178.241.108 control connection finished

I finally realized the change to blame was me switching my TP-Link router from TP-Link's firmware to OpenWrt (15.05). I do not understand much of how PPTP works, but it's quite complicated. Apparently, it uses non-standard GRE packets. Therefore, I am not sure if this is a PPTP bug or an OpenWrt bug, but for me the solution was most simple.

As explained in this description of error 619, there are several possible causes, but even if the client is clearly reaching the server, the issue can be client-side. If there is no firewall on the client OS, you should verify any client-side router, which I did by plugging one of the affected PC-s directly on the modem. The VPN could connect again, which confirmed the router was to blame.

OpenWrt does not have a "PPTP VPN passthrough" option to check, but a package to install (which is not installed by default in Chaos Calmer). Following the instructions on OpenWrt's PPTP NAT Traversal document (installing kmod-nf-nathelper-extra), I managed to get the clients to connect while NAT-ed behind OpenWrt.

Short version

Do not use WampServer.

Long version

The first time I installed an AMP on Windows, I chose EasyPHP. When I came back to PHP development on Windows, around 2013, I chose WampServer. I knew about XAMPP and EasyPHP, but for some reason (probably the precise software offered), I went with WampServer. That decision would cost me several hours...

The good

PHP is already buggy, but I suppose I didn't realize the distribution you chose could make it much more buggy. I sticked with WampServer, initially in version 2.4, because it contained Xdebug, was simple to install and worked immediately. I must admit the UI looks good - the design is good, and it lets you choose your PHP and MySQL versions.

The bad

Things changed when I started configuring PHP. Inevitably, the first problem you'll notice is that WampServer ignores your changes to php.ini. It turns out that is because WampServer installs (at least) 2 different php.ini files, one in php/, one in apache/. The file used by Apache is the latter... but of course, the one linked by WampServer's UI is the one Apache ignores.

That must be when I had to familiarize myself with the wamp directory's hierarchy. Duplication can be deplored, but the worst part is naming. Indeed, both of WampServer's php.ini files are found in... wamp\bin\. Well, I suppose whoever decided that scheme considered that all files were binary, indeed.

Eventually, some development required me to enable 2 PHP extensions disabled by default - intl and ldap. In both cases, I must have wasted an hour until I figured out that icu and sasl DLL-s needed to be copied from php\ to apache\ for the extensions to work with Apache.

The really bad

After hitting some bugs possibly in PHP, I tried upgrading it to 5.5, which required me to upgrade from WampServer 2.4 to 2.5. Unfortunately, WampServer does not offer upgrades. What do you do with such Windows programs? Of course, you download the new version and run the installer. I did that and everything went fine, except servers would no longer start, throwing cryptic errors. That's when I headed to the net and found a post on WampServer's forum explaining that upgrading is not supported. Good thing I had the presence of mind to backup wamp\ first!

It turns out the way to upgrade is indeed to uninstall, and only then to install the new version. You must think I had surely ignored a README which warned against such a crazy idea. But... there is no README. The "official" upgrade instructions are in a forum post!

The only good thing about this part is the honesty of the instructions' writer, who warns that upgrading will take 2 hours, up to 4 for inexperienced users. And indeed, if you had enabled a few extensions, had a few virtual hosts and some customization, it will take hours, even if you've been using PHP, Apache and MySQL for a decade.

The ugly

One of my projects used extensions which are disabled by default. Even after enabling them, they wouldn't show in phpinfo. PHP would merely log a useful error each startup:

PHP Warning:  PHP Startup:  in Unknown on line 0

After an hour of searches, I eventually applied the same workaround I had used (and since forgotten) when enabling them for the first time, copying the missing DLL-s to apache\.

The workaround

After so much frustration, I realized that the huge release notes for 2.5 (again in the form of a forum post) mentioned a simple fix, not only for extensions not loading, but for the tray icon shortcut pointing to the wrong php.ini. That workaround is to click on Apache->Version->2.4.9 via the tray icon. Yes, clicking on that will create symlinks (yes, symlinks on Windows!) from apache\ to php\ for the missing DLL-s, and make the php.ini in apache\ a symlink to the php.ini in php\. Yes, that is the fix, even if that version is already checked. But do not do that without first backing up your php.ini - it will be silently overwritten.

Still think you might give WampServer a go? Here's one last reason why you shouldn't. Playing with the version made me realize one more issue - the links to get different Apache, PHP and MySQL versions are all broken.

The non-lesson

After wasting all of these hours, I figured I would at least go contribute something to the issue tracker. But WampServer has no issue tracker. Not even a forum about issues. Are WampServer developers aware of these issues, and since when? Who knows.

So the only lesson here is already known - avoid software without an issue tracker. OK really...
Even if the website is fancy,
Even if the project seems active,
Even if you share your native language with the developers...
Do not use software without an issue tracker if you don't have some kind of contract with its developers.
And please, developers, avoid versioning your release 2.x until your software is reasonably functional and has an issue tracker.

Unfortunately, this is fundamentally a rant, not a review (and the list of issues is not complete). I will only dump WampServer when the next time to upgrade comes, and I won't recommend an alternative I have not tested until then. Meanwhile, I found a fairly complete review of WAMP stacks, but it's from 2012. If you're starting PHP development, I'm sure you'll find a better WAMP stack than WampServer 2.5. You may want to read about my unsatisfactory experience with XAMPP or about my similarly unsatisfactory experience with EasyPHP.

Missing Wikipedia's fundraising campaigns? The mail I received from Fair Vote Canada misses Jimmy Wales's picture and the personal aspect, but at least they tried hard.

Dear FVC action coordinator {sender.first_name},
Your efforts are nevertheless invariably appreciated!

Philippe Cloutier
Fair Vote Supporter

3 days ago, so discreetly that I didn't notice before now, a major event in the Web's history occured - the W3C released a new major version of HTML, for the first time in nearly 17 years.

This is extremely good news for the Web. Here's hoping the next version will happen faster.

Users often choose unsafe passwords. Administrators wanting to prevent that will sometimes implement requirements on passwords. While these usually try to enforce complexity, any computer scientist will see why they also ease cracking, theoretically. And as Matthew Palmer explains, theory is quite right at times.

Ah, if only users would always choose passwords as complex as heuristics.

So after a long time, summer is back in Quebec... what we call summer anyway. With these high temperatures, bugs are back too. Yesterday I came back at 1 AM. With the street lamps, I noticed that - obviously - bugs were also back on the door, just waiting for me to open it before infesting the basement. At that time a great idea came to mind, which resulted in me coining Chealer's architectural law:

Cloutier's architectural law can be generalized - external doors and door frames should reflect as little light as possible on their outside part. Unless insects would seek darkness to sleep safely.

Yes, I hate bugs. I must have become an adult the day a summer camp destroyed my childhood dream of a bug-free world, presenting insects as an essential link of the food chain. Bugs should be small, but they're stealing a big part of my life.

Thankfully, I'm mostly an inside person. A few minutes after enunciating my architectural law, I was enjoying the insect-free inside by eating dinner in a well-illuminated but very silent kitchen. At some point, I realized there were some noises coming from one window. After nearly starting to get scared, I realized one awful huge bug was repeatedly trying to go through the windows.

Fortunately, the kitchen stayed bug-free despite the stupid bug's tens of impacts. Bugs can't go through windows, right? Unfortunately, even though I rarely open Windows, my PC attracts lots of bugs. In fact, an important part of my contribution to free software is to report bugs I hit when using or trying software.

I certainly file several tickets per week, but many are never resolved or even investigated. That's why the following view hit me today:

packages.debian.org has been lagging a little more lately. I take more time to confirm resolutions, so now the 7 latest mails in my inbox are bugfix notifications in 7 different projects/packages, which all arrived in less than 100 hours. If that rate was maintained, all of my open bugs would be solved by 2016. Unfortunately, I experienced 2 bugs just in the process of writing this post, one which was already fixed, and one which I reported (my fifth ticket against Debian's issue tracking system), which made me hit a Thunderbird bug (which I didn't report this time). So that schedule might slip a little with the software I use - or should I say, test.

Debian developers don't always treat tickets diligently, but now is an occasion to send a big kudos to my squashing colleagues. The bugs above weren't the most difficult, but there's one which has already started making my desktop less buggy.

I won't surprise anyone announcing that my favorite Firefox extension is Firebug. But as Firebug doesn't apply to Thunderbird, my favorite Thunderbird extension is FireTray. FireTray works around Mozilla's biggest issue on GNU/Linux - new mail notifications.

FireTray still has some way to go before reaching maturity, but my biggest issue with it was by far #119, a show-stopper if a show is expected to be attractive. I expected an easier fix - all I wanted was a non-broken notification icon. But I didn't expect the result to be so pleasing:

After hard work by Foudil Brétel, I now get this superb new icon (at least until I switch back to KMail, to which I'm hoping to give another chance soon). And you too will with version 0.5. Thanks to you too, foudfou! The next bug-squashing spree will be even more enjoyable

Now, let's just hope that shiny new icon won't attract more bugs... otherwise, it will take the door.

Update 1

In French, the colloquial verb 'to bug' means software is misbehaving due to a software bug.

13 years later, after many more started offering such certifications, it is well overdue to put this timeless work of art in the public domain so it can be adapted to your favorite(?) software provider.

Update 2

Years after writing this, I realized the publication date didn't make sense. And eventually figured out that the update I did in 2016 had changed the year from 2014 to 2016. Because the blog engine wasn't designed to publish a post with a past date... so the HTML dropdown's options only started at the current year, causing the date to be silently changed - ah, bugs