Monthly Archives: February 2014

Prezi

Posted on 2014-02-12 by pappp

My Instructional Technology class asked us to play with Prezi, Some thoughts:

  1. I don’t think I’ve ever seen a presentation using Prezi that wasn’t made worse by it. Sometimes because the internet connection wasn’t good enough to support it, and it wasn’t installed locally. Usually because the transitions were distracting. Sometimes because there were better less spatial schema available for the information.
  2. I don’t think this is necessarily a general problem with Prezi, I think it is just that we have decades of experience designing slides, and (at least in principle) roughly know how not to suck at it, while no such body of knowledge exists for zooming presentations. Especially because it plays on our tendency to use novel features because they are there, just like we’ve slowly learned to exercise restraint with the awful things that can be done with fonts and colors in most slideware.
  3. Prezi’s designers clearly read Jef Raskin’s The Humane Interface and took it as gospel. It looks like a subset of a ZUI (Zooming User Interface) that he advocated for, unselfconsciously ignoring subsequent criticisms.
  4. Building something like that on top of Flash in this day and age is utter, inexcusable insanity. I went through four OS+Browser combinations before I found an environment where it didn’t crash Flash immediately.
  5. Their motion interpolation is the most annoying, nauseating motion in a world of annoying, nauseating smooth scrolling schemes.
  6. Sign up with your .edu address through the “for education” link if you have one. You basically get the small paid plan for free.
  7. By default, they appear to send you email every fucking day, and have one of those intentionally obtuse tools (not accessible except for via the unsubscribe link in the email footer, unsubscribe button set up to look like it might delete your whole account, etc.) to fix it.

Bah. 99 times out of 100, I’m sticking with Beamer.

Posted in Computers, General, Objects, School | Tagged , , , | Leave a comment

WNR3500L Repair

Posted on 2014-02-11 by pappp

Some years ago the KAOS lab bought a number of Netgear WNR3500L routers to use as network glue. A pair of them have been in constant service since 2011 in the lab and machine room, and both of those died in the last two weeks. I’ve finally satisfactorily tracked down the culprit, and figure it’s worth a quick write up.

The WNR3500L is a bit of a false-promise machine; it was sold as an “open router” with excellent community firmware support, but it has some pretty extensive blobs that mean it really only runs versions of DD or Tomato with a small range of 2.6 kernels.

I initially just swapped the first one to die out for a spare (which happened to be flashed with Tomato instead of DD, it was an experiment when they were first set up), and reloaded most of the settings by hand (we failed to save or document many of the settings elsewhere. Our fault.) until I had time to investigate. When the second one died, it became urgent.

WNR3500LScrew

Conveniently, the WNR3500L has a 3.3V RS-232-like serial port (115200/8/n/1) under an easily removed panel, retained by one small torx screw/pin thing (Both are out in the picture while I was figuring out which side was which).

WNR3500LBP

This leads to another victory for the Bus Pirate. Any 3.3V compatible UART adapter would work, but the bus pirate has much nicer cables for this sort of thing. In retrospect, those headers are correctly sized to just plug the female harness ends directly, but I used clips out of habit.

It turns out they were booting right up with only warnings, but the configuration was sufficiently garbled that neither the WLAN nor the Ethernet ports were coming up. I blew the first one’s settings away (note: at least on the old version these were running, reboot TWICE after clearing the NVRAM to get back to a consistent state: the first time it writes default values, the second time it boots cleanly). With the software-only nature of the problem established, I took more time to investigate the second one, at which point…

nvram show
[1310 lines excluded]
size: 32782 bytes (-14 left)
Well, There’s Your Problem.

Turns out the tiny little log fields for monthly traffic statistics filled up the nvram and were causing configuration corruption, and thus failures.

There are some forum threads and bug reports on the matter, and it was fixed about two years ago with a test to prevent writing past the end of the file, a default setting to automatically delete traff logs after 12 months, and various other enhancements. Now that we’re up and running again it isn’t desperate, but it looks like there is a DD release from mid-2013 with the fixes applied that still supports these things, and they are probably due to be re-flashed to keep this from happening again.

Lessons:

  • My home OpenWRT on a TP-Link 1043ND uses a connected USB key for logging and such. This is a much better behavior (like most things in OpenWRT: DD-WRT appears to be kind of an unmaintainble mess).
  • Keep an eye on appliances like routers, they’re still just computers.
  • Back up your damn configurations, or at least retain copies of the information required to regenerate them. Regenerating settings, especially when it involves manual tasks like MAC address hunting, sucks.

Other notes:

  • These things’ bootloaders appear to always look at 192.168.1.2 through the non-WAN ports for a tftp payload named vmlinuz. There may be a way to disable that, but I think I’d prefer to leave it on, since it only enables local attacks and provides a rescue mechanism.
  • The WNR3500L has a documented weakness about WAN-LAN throughput with various firmwares. Our uplink is actually good enough for it to matter, so perhaps one of the newer versions will improve that.
Posted in Computers, DIY, Electronics, General, Objects, School | Tagged , , , | Leave a comment

Debian init Decision

Posted on 2014-02-09 by pappp

The Debian ctte init discussion, which has been the drama that keeps on giving, appears to have finally had a decisive vote for systemd [EDIT: I was over-ambitious about decisive. The drama continues.] as the jessie init. Some notes:

  1. I found out that the FLOS neologism that is my fault is being used in the discussion. I’m not sure that I’m entirely happy about that, but I do think that we should be self-aware about building something very different from the Unix tradition.
  2. Even with my well-documented distaste for some of the philosophy (and rider components) in systemd, my experience and taste is that Upstart is the worst possible choice, and nothing else seems to have a chance. Letting the Canonical folks continue to act like Upstart isn’t universally technologically and philosophically unsatisfying to is wasting everyone’s time.
  3. The FDO agenda has largely succeeded, a bunch of the upper layers of the ecosystem are developing dependencies on systemd-coupled interfaces. This is largely because the previous interfaces being used for much of that functionality were the same developers’ now-abandoned earlier projects, which turned out to be disasters. This would be fine if there were even signs of competing implementations of those interfaces, or if the design of those interfaces weren’t such that it would be almost meaningless to attempt one, because the parts were designed as part of an integrated stack. I don’t see, for example, a clean standalone logind implementation (since it assumes things that only sysmted does further down the stack) or a nice healthy syslog-ng/rsyslog arrangement for journald. The FDO folks made an end-run around any kind of discussion of the merits of their plans by implementing quickly, getting a few of them widely adopted (initially by sheer political blustering), then coupling the rest of their design to the parts others were on board with. I’m pretty sure they consider that some kind of virtue.
  4. Related to (3) the integrated service manager over rcconf system discussion seems to have been decided on Linux up and down the ecosystem. I may not like the decision, but we should probably make the best of it and start working on/around the most annoying things about systemd. They seem willing to accommodate at least on cosmetic things like ISO dates.
  5. With that in mind, my preference would have been “We will adopt systemd iff a series of ecosystem assurances/development projects happen,” but that is unrealistic and (AFIK) forbidden by the Debian process. Especially a move from putting dist configs in half a dozen cryptic paths in /usr (which offend me in a variety of ways) to, giving credit to the merits of the “/usr belongs to the package manager” retcon, /usr/etc the way some of the BSDs use /etc/defaults.
    While we’re dreaming, forcing an interface/adapter to use a syslog in place of journald, or at least an alternative journald implementation with a simpler back-end (graceful feature degradation acceptable) would be great. I’m not even necessarily advocating using it, just that I don’t tend to take software without competing implementations as credible. Perhaps pressure from the volume of the Debian community will make some of this happen.

  6. I will agree with their vote in the “Fuck it, go with systemd, get the uniformity and feature advantages, try to mitigate the misfeatures, and leave as much room for coming back to the decision later if someone succeeds in writing and agitating for something more satisfying” sense.

Even with all that said, I’m a little surprised OpenRC wasn’t taken more seriously, since it is the conservative incremental progress choice – objectively, it is currently more featured than Upstart by most metrics – but the developers haven’t been politicking the way the Upstart and systemd folks have, and their incidentally combined efforts managed to discredit it. It has better portability (already runs on Hurd and FreeBSD) than the other options, and is one of two with a (admittedly, less featured) cgroups mechanism. The latter one is interesting because via some impressive politicking the cgroups discussion was at some point re-framed from “makes use of cgroups” to “uses cgroups in exactly the same way as systemd.”

I’m curious how the procd/ubus/hotplug2 stack coming out of OpenWRT is going to interact with the rest of the ecosystem, I suspect we’re going to see that stack meet midway with systed/dbus/udev and some of the light distros using it and shims even for PC-like applications, which will likely be the next time things get really interesting, barring a couple skirmishes where user-level software dictates the stack to the metal.

Posted in Computers, General | Tagged , , | Leave a comment