"Training a monkey would be easier"

I think I may start a new series in my “Rants” category: things you shouldn’t do. First one: Never ever use “strange” characters on your wifi’s AP name, where strange is defined as non-ascii. I made the huge mistake of choosing a name with an ñ on it, then had to spend an entire evening hacking on a printer driver with no unicode support. No, I couldn’t have changed the AP’s name. That would have required me to physically connect a computer to my router, and I was too lazy to get up from the couch.

Why am I using Windows, you may ask? I’m still in the process of discovering which features will be broken and which hardware will work out of the box. So far I’m actually quite surprised, with only the video card and the touchpad not working. Luckily bash doesn’t use either of those. Who needs a mouse anyway?

Hacking away on a little side project of mine, I found myself checking Stack Overflow for implementation tips about things I don’t usually work with. Android UI stuff, mostly, which apparently is a very dynamic and ever changing ecosystem. After more than a few wasted hours, I noticed a worrying trend: in SO, answers tend to age horribly. If you are looking for “How to do X in platform Y”, you may find a 4 year old answer that solves the problem, but only for platform Y, version “ancient”.

Information ageing is quite a problem on its own. The answer is still valid, and, for people working on that specific platform, probably relevant. This will make it the first answer, leaving a lot of people (like myself) frustrated because the solution won’t work in newer platforms. Is there a solution? Implement some kind of ageing time-window for information? Make the date a more prominent search parameter? Explicitly specify your platform and environment’s version when asking a question? I have no idea.

While Stack Overflow seems to exacerbate the issue, this is a problem even for products with a company actively maintaining their documentation. A very annoying example; looking for ways to manage the media key I ended up in a page which (as of August 2016) points to a very outdated API (registerMediaButtonEventReceiver, in case you are wondering). If even Google encounters problems when managing documentation ageing for their own products, what can we expect of people like us, who only have a tiny fraction of that budget?

Ahh, shared pointers! A nice, magical pointer type that will make all of your memory problems go away. Sprinkle some shared_ptrs here and there and, voilà, Valgrind is now happy. Sounds like a silver bullet, doesn’t it? That should be your first clue that something’s up with the promise of getting Java-like memory management in your c++ application.

Java and C(++) have a very different concept of memory management. My Java-foo, obviously enough to anyone reading this blog, is not that great, but, from experience, memory management is seen as a chore better left to the bowels of your system, something you don’t need (nor want) to care about. Sure, you can tweak and somewhat manage memory allocations if you really want to; the default mindset, however, is to ignore those concerns. The garbage collector will, eventually, find any unused resource and deal with it accordingly.

C++ programs, at least those that have been more or less successfully designed as opposed to organically grown, tend to have a radically different approach. Memory management is an integral part of a program’s design and it can’t be left to some automagic memory manager. This leads, again, for those more or less successful designs, to programs with a tree-like hierarchy in which a child or dependent object must live at least as long as its parent scope. This hierarchy leads to easier to understand programs. Some idioms (RAII!) depend on this hierarchy. Some tools (like scoped and unique pointers) make its implementation much simpler. I’ve seen that Rust really builds on this idea (and seems to take it to 11! I’m still trying to figure out if that’s a good or a bad thing, but so far I quite like it).

The tree-like structure of the scopes in C++ also implies single ownership (again something Rust seems to be very idiosyncratic about). While you may “use” someone else’s objects (for example, via a reference) there is always one single owner. If this owner goes away while someone holds a reference to one of its children… well, you get a bug. But sure enough this bug is clear as long as you can visualize the tree scope structure of your program. Shared pointers completely obliterate this tree.

A shared pointer means an object can have multiple owners. Whoever goes out of scope last needs to clean it. Why is that bad? In my (highly subjective but experience based) opinion:

It becomes harder to reason about your program. You never know if all the “pieces” you need are in scope. Is an object already initialized? Who is responsible for building it? If you call a method with side effects, will any of the other owners be affected by it?

It becomes harder to predict whether going out of scope is trivial, or an operation that can take a minute. If you’re the last one holding a reference to an object through a shared pointer, you may be stuck running its destructor for a long time. That’s not necessarily a bad thing, but not being able to predict it can lead to all sort of obscure bugs.

There are also many ways to avoid shared pointer usage:

Try restructuring your code. This will usually yield the biggest benefits, you’ll end up with a clearer structure and less clutter.

Try to use scoped pointers from boost or unique pointers if you can. Way too often shared pointers are used when a scoped pointer would be enough.

Don’t be scared of copies! Sometimes you can just copy your object and end up with cleaner (and maybe even faster) code. Are you really sure you need to share state?

Does that mean you should never ever use shared pointers? Of course not. In some cases it’s unavoidable. Some algorithms are probably impossible to implement without them (or even impossible without GC). A shared pointer is just one more tool. Just like gotos. And, just like gotos – although not quite as dangerous – they have some appropriate use cases. Just try not to make it your default goto (lol) tool for memory management.

// TODO: There is a very good reason I found to use shared pointers: to create weak_ptr’s. Is there a good solution without actually using shared_ptr’s? I don’t know!

I have been using Ubuntu for a while now. From the time when Canonical actually mailed real, physical CDs of the distro. So get of my lawn.

In all of my Linux years I have never, ever, had such a horrible installation experience as I did this weekend with Ubuntu 15.10. I may go as far as saying not even Windows ME was this horrible to install. I hit dozens of critical show-stopper bugs, from poor UEFI support to an installer that crashed when clicking “Go back”. And that’s only the installation, don’t get me started on the new KDE Plasma 5 desktop… (hint: my big desktop screen is NOT a phone. Swiping to login? Bad idea for a mouse).

A few hints for any other poor souls that made the fatal mistake of installing Ubuntu ME:

UEFI? Say no. Get a different computer if you can. Try to set it in legacy mode if you can not.

Try not to repartition and install Ubuntu on the same go. Even more so if you have UEFI. First install, then rearrange partitions with a live cd.

If you get a few (or a few dozen) “system crash notifications” when starting up your GUI, check /var/crash. Delete everything from there.

If you want Kubuntu, don’t install Ubuntu and then apt-get install kubuntu-desktop. That’s broken. If you want Kubuntu just get its install image.

Don’t install Kubuntu. Really, it’s horrible and it crashes. (You though I called 15.10 Ubuntu ME for no reason?)

Don’t like Gnome? XFCE is usable and can be configured to look more or less like a sane version of KDE. It still crashes but at least it’s quick to boot.

If you get a disk check on every startup just disable it on fstab. No, it’s not nice. I haven’t found any other workarounds yet.

I have no idea when has Ubuntu gone so horribly bad, but I’m not looking forward to installing any Ubuntu distro anytime soon. I wonder what Slackware looks like these days.

2016? Still not the year of the Linux desktop.

Update: XFCE is great… except it doesn’t really support moving the mouse. Seems Ubuntu is having a nostalgic release and decided to introduce old bugs from 2012!

Recently I found out Microsoft’s Visual Studio doesn’t support alternative tokens (ie “and” instead of “&&”). Even worse than that, apparently they don’t think it’s even necessary. And by the looks of this thread, the people working on MSVC need to take some time to actually READ the cpp standard. You know… it’s kind of like a spec for your product. It’s always good to take some time to understand the specs for your product…

I can only imagine how incredibly ugly their lexer must be to say it’s not a fixable problem.

I just noticed a very silly “pattern” I usually fall into: since I like vim (perhaps a bit too much) to work with text, even free-form text like this blog post, most of the times I type a lot of text which then must be spell checked (so far I haven’t found a spell checking extension I like for vim). While spell checking I correct the original text in vim, and to do this I usually search for the mispel in Vim, thus typing the wrong spelling one more time. This has the side effect of reinforcing the bad spell instead of forcing me to type the correct spelling.

There’s nothing better for Monday mornings than the smell of hundreds of template errors after a make clean all. When using template metaprogramming, a tiny misplaced coma can generate enough error code that, if printed, would crush you under tones of paper. And don’t even try to read them, it’ll make your head explode.

Luckily STLFilt can be quite a relief when dealing with this kind of errors. Granted, it won’t make a steaming pile of poo seem to be a nice poem, but if you have something like the dog in the picture, to use a metaphor, at least it would put a blanket on its face.

To be completely fair, this is a dual fuckup between Dell and Ubuntu: after an upgrade I started noticing that sometimes the CPU slows to a crawl, for no apparent reason. The only fix for this is a complete shutdown, as not even a reboot would make this problem go away. WTF?

A lot of time after I had given up on trying to solve this problem and decided that submitting to the gods seemingly random will was the best option, a coworker told me what this was about: apparently when you have a 3D GUI (say, a screensaver) and a double monitor the graphics card has to “work too much”, drawing too much power. When the power consumption reaches 90 watts, the power supply’s limit, the CPU enables something called CPU scaling, bringing the CPU clock speed to about the speed of a wristwatch. (No, really: “Even setting aside the negative performance effect of FSB downshifting in II above, the effective processing power is reduced to 1/8 of 798 Mhz = 100 MHz. This is a reduction to less than 5% of full capacity, from http://www.sigmirror.com/files/44490_iweoz/throttlegate.pdf).

I have been writing some documentation lately (crazy, I know) and needed due to some bizarre business requirements all the documentation for the application was supposed to be in a single .doc file. That’s write, a single file for user manual, technical manual, administration manual and so on. And I had no LaTeX either (damn those MS Office files, I hate them) so using multiple tex files and including them together wasn’t an option.

Choosing the least of all evils, I decided to use Open Office and master documents. With them you can create several different .doc files and then join them together in a single .odm file, which can then be exported to pdf (or .doc, if your boss says so). It’s a nice feature, but for such a simple thing as having multiple documents #included in a single one you would expect it to work better. From OO manual:

Yes, master documents do work in OOoWriter. However, their use is full of traps for inexperienced users[…]