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❗

Today appears to be my Microsoft rant day. Sorry, that might have been prompted by an awful experience claiming the warranty for a broken Microsoft keyboard. Readers who are free of Microsoft products have my apologies (and much luck).

As Ned Flanders brilliantly illustrates in The Simpsons, left-handedness is an economic problem. Mass production of artefacts for a majority of right-handed consumers disadvantages left-handed people. Keeping 2 items in stock - for one thing - comes at a price.

On the other hand, when a company produces software, being friendly to left-handed people shouldn't be costly. There is no marginal cost to a software sale, right? Well, it appears that the Microsoft Mouse and Keyboard Center isn't right at the center on the issue of handedness.

The ability to invert the mouse buttons has been present since at least Windows 95. Not a surprise, since handedness is possibly the most important mouse setting. However, when I bought my Microsoft keyboard, Windows automatically installed the modern Microsoft Mouse and Keyboard Center. I had previously noticed that the center was a regression for people often moving their mouse to the other side like me. Rather than controlling a checkbox in the control panel, inverting the buttons requires to redefine the behavior of each button via the Microsoft Mouse and Keyboard Center. Microsoft's configuration center removed the checkbox from the control panel.

What I hadn't noticed is that if your mouse is not supported, it does not appear in the Microsoft Mouse and Keyboard Center. And the control panel's checkbox is still gone. So if you own a Logitech or some even rarer mouse like I do, you're not dreaming. There is actually no way to invert your mouse buttons with this software installed, even in Windows 8.1. And this is not a new problem! Worse, I believe Microsoft Mouse and Keyboard Center had at least one useful feature: when you invert buttons with it, your RDP sessions will handle clicks correctly, as opposed to the default behavior from Windows, which I will be forced to live with.

In a sense, I'd like to think that this is an abuse of vendor lock-in. Because if it's not, this is proof of terrific incompetence.

After catastrophic issues with our file server caused by Outlook PST files, I've been trying to move from POP to IMAP at the office. A few months ago I did a first step, migrating my own mailbox. This was a very painful process.

Even though I'm using version 2013, which has had "a significant investment in IMAP", the result is impressively bad. The system tray's envelope icon, which shows when you have unread mail, now appears every few minutes. This feature becomes worthless and I gave up on it.

2 weeks ago, I started working from home thanks to our VPN. I was amazed to see huge bandwidth usage on the VPN ever since. I realized yesterday that the culprit was Outlook, which wastes close to a megabyte of bandwidth per minute, even when it's merely idling. That's right - even if I'm not using Outlook and not even receiving mails, Outlook will download about 28 GB per month, which is about half of my bandwidth limit. This happens even though I reduced my number of folders below 50 and my mailbox's size just above 1 GB. It doesn't depend on whether the server interval is 1 or 10 minutes (the latter being the maximum). Traffic shows that Outlook is doing something at a regular interval, about 18 times per hour. Yet, it seems to support IMAP IDLE (that is, mail is fetched instantly).

To be fair, I haven't tried to reproduce this with a fresh profile. I'll just dump Outlook for the time being.

Update: There is a pretty straightforward workaround: changing the send/receive interval. One way to do it is via the Advanced options, Send and receive section. Click "Send/Receive..." and adjust the interval for the default group.

Unfortunately, even though I thought my inbox showed mail instantly, it apparently doesn't. After changing the interval to an hour, it now takes time to notice new mail.