Security? What security?

Since I'm often messing around with electronics near my workstation, which is 2-3 meters away from the equipment rack, I've started looking into making a remote control for my lab power supply. The thing is has LXI support, which means I can hook it up to the network and send commands to it -- both to query state and to change the state.  Setting voltage and current limit, turning outputs on and off etc.

The idea was to use an ESP8266, hook up a display to it and a couple of buttons and rotary encoders, and then write some firmware for it which allows you to talk to the power supply -- setting voltage and current for the outputs, plus add support for a few other things.  Perhaps not terribly useful for anyone but me, but a fun project.

While reading the documentation for the SCPI commands of the lab supply it struck me that this stuff has no security whatsoever.  None.  Zero.  No username, no password, no standard keying scheme. You just connect and you send commands and the machine does stuff.  There may be some lab equipment that has security features, but none of the stuff I have has any protection whatsoever.

Which means that in just a few lines of code, you can build a network scanner that will look for LXI-enabled devices, figure out what they are and then manipulate them.  Actually, one of the open source tools for talking to LXI/SCPI enabled devices has a scanning feature for finding devices -- so figuring out how to do this is trivial.

This means that if you connect to a lab network with LXI-enabled devices, you could query a power supply to find out how much juice it can deliver on each channel and then crank up the voltage and current limits to the maximum value on every output.   If you are building electronics that operate at 3.3 or 5.0 volts and have them hooked up, that would probably fry them.  Perhaps you could even start a fire that way.

Or you could be more subtle and introduce small intermittent problems.  Like monitoring the current draw of a device and then reduce the current limit on an output to deliver slightly less current in order to provoke erratic behavior in electronics.

I started looking for security information on LXI on the web.  Not a big research project, but just a few google searches to get some feel for what's going on here.

I stumbled across a talk by a representative of some instrument manufacturer talking about this.  His take was that "well, you'll have to deal with this in routers...create VLANs and deal with whitelists and packet filters etc".

Well, sure, this is lab equipment, but really?  This fellow lives in la-la-land.  If he thinks that this works in real life he is mistaken.  If you need to get some lab equipment up quickly and perhaps log some data or remote control some gear, you'll do whatever you can to get it working and then leave it at that.  You will not be having meetings with the IT department to have your network configured every time you get a new piece of gear.  And if you do have a messy network setup with all manner of access control, it is going to be slow and time-consuming to make any changes.  You'll be screwing over your engineers or your production staff.

I'm not so sure I want to implement a remote for my power supply now.  I wouldn't want to be sitting with my nose hovering over some piece of electronics and then suddenly have stuff blow up in my face because someone decided to write malware that targets LXI enabled devices.  I know myself well enough to know that I'm not going to bother setting up a separate network for my lab equipment.


Escaping the open plan office.

I'm often having a hard time getting much done in my office at work. In an open plan office the interruptions are constant, and if you want to escape your only option is to bring your laptop and escape into a meeting room with highly uncomfortable furniture.  In meeting rooms the chairs are usually bad, the desk is the wrong height, often the lighting is sub-optimal, there are on windows that can be opened to admit fresh air and the ventilation systems...well.  And then, of course, you have to lug all your notes, books, and whatnot to the meeting room.
So then you sit there and squint at a screen that is less than 1/4 the area of your large desktop screen while trying to find a comfortable seating position on pretty terrible furniture.
While my home office is pretty good, working from home isn't exactly optimal since it tends to make you feel like you're constantly at work -- or that you should be working. And it is tempting to do things that aren't work because "it'll only take ten minutes". The delineation between work and play becomes fuzzy.
For this reason I've started experimenting with working different places. From cafes to libraries and even sneaking into hotels and using their lounge areas. Here are some observations:
  •  Even in somewhat noisy environments it is easier to concentrate than at the office since the conversations around me do not involve me, the company or anything I do. It gets easier to mentally block them out.
  • Being able to work for hours on end without having people approach me is a real productivity boost. At an office you need a room with a door that can be closed to accomplish that. If you are sitting in a hotel lounge, people will leave you alone.
  • The biggest limitation of most spaces I've tried to do work in is the furniture. The chairs are often uncomfortable, the table is the wrong height, power outlets may be missing etc.
  • Being able to vary your surroundings is great. I tend to get bored of working in the same place day in and day out. Working in new surroundings somehow helps my creativity.

I have considered having "work weeks" where I go abroad and just focus on work for a week or so. Renting an appartment through Airbnb and perhaps bring a co-worker or two. Just to get more focused work time. I haven't had the opportunity to try it yet. I'd be interested in even trying this with people who are not my coworkers -- people from other companies.
I haven't tried working at coworking-spaces yet, but I have visited a few to have a look, and most of them are open plan, so that's a no-go. For focused work, that won't do.

Occasionally I end up discussing open plan offices with people who design offices, and most of these inevitably have a very different experience.  They have a hard time understanding why it is so hard for someone like me to function in a noisy environment.  This inevitably leads to a discussion of the fundamental differences between the way you do different jobs.
There are some jobs you can perform with very shallow levels of concentration.  For instance, I spent a few weeks designing physical objects in a 3D modeling system last year as part of a project at work.  For me, this requires very little concentration.  The mental process of designing and realizing three dimensional objects appears to be a completely intuitive, wordless process.  Meaning that I can have a conversation going with someone on an entirely different topic even while designing.  I listened to podcasts while designing 3D objects that need to fit together in a particular way and which need to be designed so that they work for the manufacturing process being used.  For instance orientation matters when you 3D print something -- for strength, printability, non-uniform dimensional changes etc.  You have a lot of constraints that need to be balanced.  But as I mentioned, for some reason, for me, this requires very little mental effort.  Very little concentration.

However, when I do algorithmic design or system design, or similarly mentally ardous tasks, things are very different.  It can often take up to an hour to arrange all the ideas, information and context in your head just so you can start to reason about things.  And it is very hard to maintain that state over time.  I think the best comparison would be to build a house of cards.  You have this very fragile structure in your head and you are trying to do work on it without losing it.  And when something threatens to disturb it, you get stressed out -- you feel unease and discomfort.

Working in an open plan office for someone who needs to concentrate deeply is like trying to build a house of cards in a daycare center full of hyper kids.  It isn't exactly where you would expect to get a lot of great work done.
All it takes to tear down parts of, or you whole, house of cards is for someone to interrupt you to ask a question.  The cost of an interruption can be great.  Even total.  It has happened innumerable times that I've been very close to solving a probleme, or getting significant work done -- only to have the opportunity yanked away from me because of an interruption at the wrong time.  And then have been unable to get back to where I was for the rest of the day.

To be honest, I don't think most of the work interior architects and office designers do requires all that much deep focus.  Yet I am often confronted with these kinds of professionals who seem only too happy to project the way they work onto everyone else.   It works for them and then for some reason they think this means that it'll work for people who do fundamentally different forms of work.

I'm not sure if this is lack of empathy or just very telling of an overall lack of professional depth.

I've tried to look at some productivity metrics for myself over the years.  Measurements are, of course, never perfect.  How do you measure how productive a programmer is?  Number of tasks finished?  Lines of code written?  Level of quality achieved?  Amount of functionality produced?  
For the most part I've used metrics that roughly measure "amount of work done" and "results delivered". I look at how many tasks I've finished, how many changes I have made and what milestones I've achieved and then "squint" to arrive at some rough estimate.
Unlike a factory worker who stamps out parts, where a doubling in productivity would be almost unheard of, the difference in productivity for a knowledge-worker often fluctuates by an order of magnitude.  That is, in very productive phases, I can be more than 20 times as productive as when I experience periods of low productivity.
The peaks in my productivity completely dwarf the periods of low productivity.  At my peaks I can do months of work in just a week.  Given that this is taxing I can't do this constantly, but when the conditions are right I can achieve this state more often.  Perhaps every two weeks or so.
From a cost/benefit point of view you would think that the obvious way to get the most out of my pay would be to try to keep me as close to the conditions where the peaks occur as possible.  The rational thing to do would be to run the numbers.  To look at the factors that make people more productive and to find places where you can spend N amount of money to get a N*X (where X > 1) increase in productivity.

Of course, this generally never happens.  And if I am going to be a bit mean:  it isn't surprising when taking into account that many of these people claim that they can function in noisy environments.  Of course they can.   They don't think very hard about things.


Get off my lawn.

"We need to get some young programmers with fresh ideas", my friend told me.  And since he is a fairly cerebral fellow who occasionally has ideas I could have come up with myself, and thus confirm my secret suspicion that I am an undiscovered genius, I said "sure, that sounds like a good idea".

In retrospect I am not 100% sure if I said it because I felt I had used up my daily quota of being dismissive of other people's ideas and needed to say something positive, or if I really believed him.  But to delegate the miserable suffering of turning flimsy ideas into running code had a definite appeal.  I told myself it would free up my time to focus on important stuff.

At first, wearing the rosy-tinted glasses of confirmation bias, I figured that this was a good decision.  That the younger generations were indeed better than my generation at the same age and that these kids were born into a world of easy access to everything they needed to learn.  I stood by, watching as they toiled away at the code.

Sure, much of the time they'd end up in unproductive dead ends like a Roomba getting caught in some unfortunate configuration of furniture, but they got things done once you discretely nudged them.  And often it wasn't as clunky as the underlying code might suggest.

As programmers we often needlessly fret over the fact that our stuff is pretty bad.  Hidden behind a nice opaque surface, nobody can actually see our code. I remember the first time I shipped real production code in a hurry before it was done.  I remember the salesperson praising our work in front of the customer and tried to imagine what elaborate torture they would come up with for him once they figured out that the code had no business working.

Because they would understand it was HIS fault, right?

I figured that, unlike a Roomba, the kids would eventually learn.  I mean, how many times can you fuck up the same way without that pink lump of biomass in your head identifying that you have a pattern going?

Turns out, most people do not learn on their own.  Most people are not capable of taking a step back and drawing conclusions from their own failings.  And we programmers are the worst.

Unless someone told you something at a conference or you read it in a book hip people have told you to read (preferably from the stage at a conference), it isn't real.

Normal people are not allowed to have thoughts or to draw conclusions. That's for people with book-deals and speaking engagements.  We proudly say that we believe in science -- that something isn't true merely because someone says so, but because we can confirm it.  And then we go on doing exactly that: believing in some authority and disregard our own experience.

There are innumerable examples of this.  But I'm going to leave it up to you to find some yourself, because in giving you an example I would probably call someone you worship an arrogant, ignorant ass.  At least indirectly.  And that would just be, well, mean and arrogant.

I've been arrogant all day today and I need to be nice.

Of course, there were signs.  Code that so severely under-performed I started wondering if they had stopped teaching kids about algorithmic complexity.

There was the inevitable "performance isn't important -- we'll just throw more hardware at it".  And then the realization that you're faced with one of those hard cases where nine women can't make one baby in one month.

Because that's the problem they chose to solve.

Because making sure that the problems you end up having to solve are good problems to have is "premature optimization".

Of course, not a single idiot who yammers about premature optimization has bothered reading the text where the "idea" comes from -- or even understanding the context of it.  Some authority said it and so it has to be true.  And applicable to anything that might be construed as "optimization". Premature or otherwise.   (Again, if you don't know what I'm on about, you have some reading to do.)

I'm starting to realize that young programmers are no better than I was at their age.  And it is mostly my fear of sounding like a tiresome old fart that prevents me from saying that out loud on a daily basis. Nobody wants to be that stereotype;  the old fart that talks about "at your age I had to do X, Y and Z myself.  Barefoot.  In the snow".

Sure, you can ruthlessly exploit young kids to put in more hours of work since they are too young to understand the value of time.  But just because they have a more elaborate vocabulary with which to express their lack of instinct, you should remind yourself that occasionally you might have something to contribute to the mix. 

These kids are just about as dumb as you were at that age.

Now, get off my lawn!


Printing using PVAc glue on the build plate.

Doing my first 3D print with glue on the build plate instead of painter's tape.  I got tired of poor adhesion for the first few lines and then too much adhesion when you want to pull the part off -- resulting in parts that have fragments of painter's tape stuck to them.

I mixed 1 part Polyvinyl Acetate (PVAc) to 4 parts water in a jar, shook it until the glue dissolved and then painted the mix onto the build plate while keeping the build plate at about 50 degrees celsius.  The water evaporates, leaving a thin residue of glue on the surface.   I put down layers of this, letting each layer dry before putting on the next.  After about 3 layers the surface gets a slightly milky look.

I probably should have allowed it to dry completely.  The surface was a tad sticky when I started printing.  But this didn't seem to matter.  The initial lines of the skirt (a line the software draws around the part in order to get good filament flow before starting to print the actual part) stuck beautifully.

I decided to try PVAc glue since this weekend I am bulk-printing enclosures for a camera prototype. It is a simple, low cost GSM connected webcam to explore what we can accomplish using cheap off-the-shelf parts.  I designed a very simple enclosure for it and next week we are going to put together a bunch of these devices.  We've tried to keep things as simple as possible,  but we still have to solder some wires to the board to hook up a switch and an LED.


Reviewing 3D printers

I've read quite a few 3D printer reviews over the last months and now that I have had the opportunity to collect two months worth of practical experience with a well known 3D printer, I have to conclude that most 3D printer reviews are worthless.

In general, you can disregard magazine reviews.  These are the worst.  The problem with these is that they are usually performed under time pressure and it seems more important for magazines to have a review of 3D printers than to do it well.

Magazine 3D printer reviews at this point are nothing more than glorified unboxing videos in text form and you should probably not take them seriously.   I say "probably", because sooner or later I guess some magazine will start applying serious evaluation methodology.  So far though, I have not seen this.

You will find the most useful reviews in blog postings and forums.  People who own the device and who have used it for at least a few months.   For example Nick Lievendag is pretty good at reviewing 3D printers since he actually uses them to do work.

Here is a brief list of what a proper review should minimally involve:

  • Test the machine for at least a couple of months.  It should have at least 350-500 hours of printing on it before you conclude anything.  If you think this is a lot: this is rather typical load when you do a project.  Prints take a long time so you try to minimize the idle time so that you can get more done per day.  50-60 hours of printing time per week is a relatively moderate load during a project.  You can easily double that if you time things properly and you have 24/7 access to the machine.
  • Test it until something breaks.  Some machines have weak parts.  You need to know which parts fail first and you need to know what it will take to repair the machine.  What is covered by warranty is really not interesting.  Breakdowns cause downtime and if you have to return parts and wait for new parts to turn up, that will cost you valuable time.  Also calculate the cost of running the machine over time given the cost of repairs.  (Some 3D printers need spare parts that add up to more than the printer costs within a year.  I have yet to see a single magazine review that addresses this rather important aspect of 3D printer ownership).
  • Take the machine apart and have someone with technical insight analyze the design and the parts used.  Down to looking at what chips have been used for stepper control, what CPU it uses, what kind of firmware, PSU, technology used for calibration etc.  Also get someone who knows about mechanical design to look at the mechanical design.  Precision, durability etc.  If you are squeamish about taking printers apart because you are afraid to piss off manufacturers, reviewing hardware is not for you.  If they try to make you sign NDA agreements you are, of course, disqualified from reviewing the product.
Taking the product apart is more or less a requirement for a serious Magazine review at this point. For privately owned 3D printers this may not be feasible, so it would be unreasonable to expect this from owners.  But people who make a living reviewing stuff:  if you don't you are not serious about what you do.

If you want to learn about tearing down products, I suggest you watch videos by Dave Jones.  He routinely reviews equipment and a standard part of a thorough review is him taking the product apart and analyzing what is inside.  Here's an example of Dave having a look at the GoPro Hero 2.

And if you are a manufacturer and worry about teardowns:  you need to learn how you can benefit from this.  Dave Jones tore apart a Rigol bench lab power supply a while back.  Which uncovered some design errors in the thermal handling of the product.  Rigol responded to this by fixing the problem, and guess what:  since they have fixed it and since Dave has had a thorough look at the product: people now feel safe when buying it.  Because they know it is a good product and that Rigol deals with problems.

PS: I'm in the process of trying to resolve problems with a 3D printer I use for work.  No magazine review I have read correctly reflects what I am experiencing and what other users I have met through forums are experiencing.  I am giving the manufacturer time to resolve issues.  At the end of my current project I plan to write a blog posting or an article about the product and whether or not the issues got resolved.  If the problems with the machine cannot be resolved and if we can't return it for a refund I hope I'll have time to tear it down and possibly rebuild the machine using different 3D printer components.  We'll see what I have time for.