Profile cover photo
Profile photo
Dominik Honnef (dominikh)
Dominik Honnef (dominikh)'s posts

Post has attachment
$ cat =go-find
foo=$(echo -e "package main\nvar _ = $1" | goimports)
godef -i -o $((${#foo}-1)) <<<"$foo"

$ go-find fmt.Scanner.Scan

(defun go-find (name)
  (interactive "MIdentifier: ")
  (godef--find-file-line-column (shell-command-to-string (format "go-find %s" name)) nil))

Post has shared content
Another reason to avoid XML.  Windows' compiler decided to use a XML config file.   Parsing this involved pulling in a DLL which several DLL dependencies later, pulled in Internet Explorer.   Developer tried doing a parallel build (i.e, the equivalent "make -j 12").

Hilarity ensued.

Post has shared content
 A realization that I recently came to while discussing the whole systemd controversy with some friends at the Collab Summit is that a lot of the fear and uncertainty over systemd may not be so much about systemd, but the fear and loathing over radical changes that have been coming down the pike over the past few years, many of which have been not well documented, and worse, had some truly catastrophic design flaws that were extremely hard to fix.   For example, I still have the following magic installed in /etc/polkit-1/localauthority/50-local.d/dont-bug-me.pka:

[Don't Bug Me]

I added this because Network Manager insisted on popping up a window and asking me to type my password whenever I tried joining a new network.   And figuring out how to make Network Manager not do such a brain-damaged thing was so painful, that after going through reams of poorly documented XML schemas, and 50 language translations interspersed with actual configuration in various XML files, I just gave up and used the Big Hammer to make policykit just Completely Go Away.

I could tell similar horror stories about dbus when I had to debug various suspend/resume failures, which is something else which is similarly opaque and impossible to understand, but the point is that many of these failures have caused many people to want simple shell scripts, instead of having to crawl through badly designed XML schemas, or someone else's complex C or C++ code, just to figure out what the hell they did and how to patch around their design fail.

It's not entirely fair to charge all of this to Systemd's account, but I think one of the reasons why this happens is because +Kay Sievers and +Lennart Poettering often have the same response style to criticisms as the +GNOME developers --- go away, you're clueless, we know better than you, and besides, we have commit privs and you don't, so go away.

That being said, I recently did try moving my laptop to systemd, and I was pleasantly surprised by the Debian's integration --- it didn't blow away my rsyslog configuration, or do any number of a things that I'm worried about.  +GNOME  may start depending on more and more of systemd's features, and thus make it even harder to configure away its design failings, but that's +GNOME's problem, not systemd.   And besides, this is why I'm using XFCE and not GNOME.   :-)

I do find it very difficult sometimes to figure out why a particular systemd service gets started, and when I tried putting together a battery target which would automatically shut down various daemons that I don't need when I want to save power, it apparently somehow caused the brightness keys (fn-F5 and fn-F6) to mysteriously stop working --- and as I expected, it was impossible to debug.   So instead of using a systemd target, I'll just hack together a shell script that runs the necessary "service <foo> stop" instead of using a systemd target.  If things start breaking horribly, I'll file debian bugs, and try to find ways to work around the brain damage.   The fact that I won't be able to edit shell scripts to work around brain damage is still a little anxiety-producing, and the fact it's much more difficult to create a runlevel which is "just like runlevel 3 but without certain services running" is unfortunate, but I'll give it a try and see how much pain is involved.

At least with Debian, it's relatively easy (at least at this point) to roll back to sysvinit if systemd proves to be intolerable.   I figure I might as well try it now before I'm forced off of sysvinit and then discover all of the things that break and which can't be easily worked around.

Post has attachment

Post has shared content
I'm waiting for someone from the Ada Initiative to call the author Susan Sons a sexist....

Post has attachment

Post has attachment

Post has shared content
Please spread this video, because we should not allow big companies like Tupperware to treat customers like they did in my case:

As you can see in the video, this new product is clearly broken. I tried two times to get a replacement through my Tupperware consultant and described to her exactly what was wrong with the box. Both times, it just came back directly from the local Tupperware branch, because the manager there had just decided that it was "apparently okay". It never went to the complaints department. At that point I began to feel ripped off, because if I pay 25€ ($33) for a box that contains cheese, I want it to work properly and to get it replaced easily if it is broken. It especially clashes with their widely advertised "lifetime guarantee".
Then I wrote an e-mail to their contact address on the website and I got an answer from their "Supervisor Customer Relations", asking who my Tupperware consultant was. I though that I finally reached someone who was willing to help, but I was proven wrong: After my answer, I just got back a mail telling me to get in contact with my local Tupperware branch, exactly the ones who declined my request two times. Fail!

Post has attachment
"What's happening in Go tip" is back for Go 1.3! The first article in 2014 covers the new sync.Pool type.

Post has attachment
I wrote a quick article on uses of cgo that you might not have expected, and how they can interfere with cross-compiling Go programs.
Wait while more posts are being loaded