Over the past few years, the idea had already surfaced a few times, but I never actually got myself to start this little project. But a few days into January, the bug suddenly hit me hard, and I couldn't resist anymore: I wanted to build my own arcade cabinet.

Every nontrivial endeavour starts out with a little bit of research, and luckily the idea wasn't exactly original; there are a lot of tips and howtos, as well as some very strong opinions on How It Must Be Done to be found online.

Now one of the tips given most often is not to start from scratch, but to get an existing cabinet an repurpose it to your needs. It is less work, and much cheaper than going at it yourself.

But hey. Where's the fun in that?

Despite not having any significant woodworking skills (and, now that I'm done, to be honest, apart from some common sense needed to keep your fingers attached, you don't really need to be that advanced at it for a project like this), I wanted to build my own; partly because it is fun (or at least, that was what I hoped, and I was right), and partly because strangely enough, I don't really like most cabinet designs. IMO they are often too big and too flashy, especially if they are intended to be placed in a home instead of an actual arcade.

So after some basic research (there are lots of good tips on ArcadeCab, and a couple of initial designs, I went out to the local hardware store, got a bit of wood and some tools I did not have already. And I was off!

I shall not bore you with a step-by-step guide, there are enough of those on the Internet already, but here are a few pictures:

The whole process took a couple of saturdays (sorry for the noise, neighbours!), and a lot of obsessing over How To Do It, but I'm quite happy with the results:

Some observations and lessons learned:

• Building Stuff Is Fun.
• I'd do lots of things completely different if I were to do it again.
• Routers (of the woodworking, not the packet switching kind) are awesome!
• Covering a room with plastic to paint big pieces of wood feels pretty awkward if you have just watched two seasons of Dexter.
• The people at arcadewinkel.nl are great.

Again, I am pretty happy with how it turned out!

Now I only need to find a place to put it.

CV of Jelte Jansen

Personal Information

• Name: Jelte Jansen
• Date of Birth: February 7th, 1979
• Sex: Male
• Nationality: Dutch

Profiles

• LinkedIn: Jelte Jansen
• Twitter: @twitjeb
• GitHub: tjeb
• Website: tjeb.nl

Experience

• Programming languages

  • C, C++, Go, Python, Perl, Ruby, Java, Javascript, Lua

• Hands-on experience in protocol implementation

  • DNS, DNSSEC, TCP/IP, HTTP(s), AS2, SMTP, S/MIME, PKCS#11, OpenID (1.0)

• Operating Systems developed for

  • Linux, *BSD, Solaris, Windows, OS X

Employment History

• 2013-present: Stichting Internet Domeinregistratie Nederland

  • Description: Foundation that administrates the .nl country-code top-level domain
  • Function: Research Engineer
  • Tasks: Technical Advisor, Internet protocol research and development
  • Specifics:
    • Involved in protocol design and standardization (IETF, PEPPOL)
    • Technical Lead SimplerInvoicing (SI-UBL and PEPPOL transport)
    • Prototype Development for new protocols and services, this ranges from brand new services, such as the Domain name Surveillance system (www.sidn.nl/a/internet-security), to extensions of the PEPPOL Transport network (www.peppol.eu)
    • Member of the Privacy Board at SIDN, as a technical expert
    • Editor for Privacy & Informatie (www.uitgeverijparis.nl)
    • Program Committee Member for RIPE Meetings (meetings.ripe.net) (2015-2017)
    • Member of the Board of Advisors for SIDN Fund (https://www.sidnfonds.nl/excerpt/)

• 2009-2013: Internet Systems Consortium www.isc.org

  • Description: Non-profit public benefit organization that produces and distributes quality Open Source software, and provides professional services based on that software.
  • Function: Software Engineer
  • Tasks: Software design, Software development, Protocol engineering, Scrum Master, member of Best Practices board
  • Specifics:
    • Design and development of the http://www.isc.org/bind10 software.
    • Involved in standards work at the Internet Engineering Task Force http://www.ietf.org
    • Scrum master. Since ISC is a very distributed company, with small teams consisting of people working all over the world, this involved applying the Scrum methodology as befits our team, which posed a unique set of challenges.
    • Represented my engineering team at a best practices board, where common practices from different teams were combined and formed into a set of company-wide best practices for software engineering.

• 2004-2009: NLnet Labs NLnetLabs.nl

  • Description: Foundation to develop, implement, evaluate, and promote new protocols and applications for the Internet.
  • Function: Developer
  • Tasks: Research, development, protocol engineering, application testing, systems maintenance
  • Specifics:
    • One of the two original developers of the ldns DNS library, a C library to simplify DNS programming. It supports RFCs like the DNSSEC documents (RFC4033-4035). Apart from being a general library, this contains several specific tools, amongst which:
      • Simple Resolver and debugging tool (drill)
      • DNSSEC signer (ldns-signzone)
      • DNSSEC validator (drill)
      • DNS traffic analyzer (ldns-dpa)
      • DNSSEC zone walker (ldns-walk)
    • With ldns, created an example and interoperability testing implementation for the DNSSEC extension NSEC3 (http://www.rfc-editor.org/rfc/rfc5155.txt)
    • Involved in the creation and validation of several RFCs, most notably RFC4033-4035, RFC4648 and RFC5155.
    • Developer and maintainer of a second iteration of NLnet Labs' and RIPE NCC's DISTEL Testlab, a test setup for performance and regression testing of DNS authoritative servers. Created a way to do basic classifications of differences between server implementations. Reimplemented the control and configuration tools of the testlab in Python.
    • Provided assistance with the design and code reviews of NSD 3, an authoritative name server.
    • Provided assistance with the design and code reviews of Unbound, a validating recursive name server
    • Involved in the first iteration of the OpenDNSSEC software suite. Mainly responsible for the initial signing engine, and transparent abstraction from HSM devices.

• 2000-2004: First8 B.V. www.first8.nl (part-time)

  • Description: ICT Company specialized in creating inter- and intra-net applications
  • Function: Software Engineer
  • Tasks: Design and development of Java-based Internet applications

• 1998-2000: InterNLnet B.V. www.internlnet.nl (part-time)

  • Description: Internet Provider
  • Function: Helpdesk for an Internet provider.
  • Tasks: Provide technical help to customers with their network and Internet connections

Publications

• Author of IETF RFC 5702
  • http://tools.ietf.org/html/rfc5702
• DNSSEC Key maintenance
  • http://www.internetdagarna.se/arkiv/2008/www.internetdagarna.se/images/stories/doc/13_DNSSEC_Key_maintenance.pdf
• An Introduction to the use of HSM
  • http://nlnetlabs.nl/downloads/publications/hsm/index.html
• Measuring the effects of DNSSEC deployment on query load
  • http://nlnetlabs.nl/downloads/publications/dnssec/dnssec-effects.pdf
• A privacy Framework for DNS Big Data
  • https://www.sidnlabs.nl/downloads/whitepapers/SIDN_Labs_Privacyraamwerk_Position_Paper_V1.4_ENG.pdf

Education

• High school: Gymnasium Beekvliet
• University: University of Nijmegen (now known as Radboud University)
  • Master's degree in Computing Science
  • Graduated on Security and Development
  • Aia Master award for master thesis Slicing Midlets

Other

• Several personal projects can be found on http://tjeb.nl/Projects and http://www.tjeb.nl/blog
  • One notable personal project is Mailbox Alert (AMO link), an addon for Thunderbird with over 16.000 daily users.
• 1999 - 2001: Chair of Thalia, the student association for Computing Science at the University of Nijmegen
• 2000 - 2001: Treasurer of 'Stichting Beet', a student association encompassing the technology studies at the University of Nijmegen
• 2001 - 2002: Chair of 'Stichting Beet'

CV of Jelte Jansen, short version

Go To Extended version

Personal information

• Name: Jelte Jansen
• Date of Birth: February 7th, 1979
• Sex: Male
• Nationality: Dutch

Employment History

• 2013-present: Stichting Internet Domeinregistratie Nederland

  • Description: Foundation that administrates the .nl country-code top-level domain
  • Function: Research Engineer
  • Tasks: Technical Advisor, Internet protocol research and development

• 2009-present: Internet Systems Consortium

  • Description: Non-profit public benefit organization that produces and distributes quality Open Source software, and provides professional services based on that software.
  • Function: Software Engineer
  • Tasks: Software design, Software development, Protocol engineering, Scrum Master

• 2004-2009: NLnet Labs

  • Description: Foundation to develop, implement, evaluate, and promote new protocols and applications for the Internet.
  • Function: Developer
  • Tasks: Research, development, protocol engineering, application testing, systems maintenance

• 2000-2004: First8 B.V. (part-time)

  • Description: ICT Company specialized in creating inter- and intra-net applications
  • Function: Software Engineer
  • Tasks: Design and development of Java-based Internet applications

• 1998-2000: InterNLnet B.V. (part-time)

  • Description: Internet Provider
  • Function: Helpdesk for an Internet provider.
  • Tasks: Provide technical help to customers with their network and Internet connections

Education

• High school: Gymnasium Beekvliet
• University: University of Nijmegen (now know as Radboud University)
  • Computing Science
  • Graduated on Security and Development in 2004

Awards

• Aia Master award for master thesis, Slicing Midlets

Other

• Several personal projects can be found on http://www.tjeb.nl/Projects and http://www.tjeb.nl/blog
• 1999 - 2001: Chair of Thalia, the student association for Computing Science
• 2001 - 2002: Chair of 'Stichting Beet', a student association encompassing the technology studies at the University of Nijmegen
• 2000 - 2001: Treasurer of 'Stichting Beet'

Publications

• Author of IETF RFC 5702
  • http://tools.ietf.org/html/rfc5702
• DNSSEC Key maintenance
  • http://www.internetdagarna.se/arkiv/2008/www.internetdagarna.se/images/stories/doc/13_DNSSEC_Key_maintenance.pdf
• An Introduction to the use of HSM
  • http://nlnetlabs.nl/downloads/publications/hsm/index.html
• Measuring the effects of DNSSEC deployment on query load
  • http://nlnetlabs.nl/downloads/publications/dnssec/dnssec-effects.pdf

(tl;dr: use latest rdup for backups, and thecus has problems with some drives, even from the compatibility list, if so, try updating firmware).

So I recently saw a reasonably good deal on the Thecus N5550, a 5-bay hot-swappable NAS machine. This seemed as good a time as any to finally clean up my backups and Do Them Right.

So the plan is to see how much the already excellent rdup has progressed (last time I used it was at version 0.5, it is now at 1.1.13, the version from the repositories on my systems was 1.0.5).

Initial setup for the N5550 is quite OK, I setup NTP, NFS access, Samba access, and enabled SSH login to have a lowlevel look at what's going on inside.

Setting up the RAID array was a breeze; For my first experiment I chose a RAID-5 array of 3 Seagate 3TB disks, totalling in about 5.5TB of space.

I installed rdup on my vps, and on a local always-on machine (a lowpower fanless box acting as a fancy gateway), and initially I mounted the big drive as a samba mount (there were some unidentified problems with nfs4, see below). Read and write speed were not as high as I would have thought, about 1-3 MB/s. But that was a problem for later, and I don't really need that much speed anyway.

I only needed simple incremental backups, so the rdup-simple script should be fine.

Then the first problem arised; there were a lot of 'no such file or directory' errors. After retracing the steps rdup-simple takes manually, I found out that sometimes rdup-up missed creating a directory. And then of course when it tries to write files in it it fails. This happens for different directories on every run, so I suspect this is some form of race condition.

I asked around and a friend who uses it says he had never seen this with his version (1.1.11 IIRC).

Time to upgrade.

Ater getting rid of the repository versions, and building a fresh rdup from the latest release (long live apt-get build-dep!), rdup-simple proceeded without a hitch.

I also has a number of media files I wanted to copy, so I simply scp'd them to the mounted share.

And then the real trouble started.

While it was copying one of the video files, scp aborted with an I/O error. I tried to copy again, and this time the failed file worked. But shortly after that, while copying another big file, the thecus started beeping continuously.

Looking at the diagnostics, it reported a failing disk (drive 2). Since I had already run the smart checks on this brand new disk, I didn't think it was actually dying on me, so I tried to find what was really happening. Good thing I had that SSH access; dmesg showed lots and lots of problems:

Periodic exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen from sata drive
hard resetting link

followed by a number of messages:

device reported invalid CHS sector 0

And of course the RAID was in a degraded mode. Telling it to fix itself started a rebuild. As you may now, RAID rebuilds take a long long time, and after about 10 hours (at 92 percent), disks 1 and 3 dropped with similar errors. Bye bye RAID.

This seems to be a problem with the driver, as similar problems for other systems are all over the web. It is often blamed on bad cabling, but there are no cables in this machine (the sata connections are directly wired on a board, and if that board was bad, I'd expect to see much, much more complaints on the Thecus forum).

Another thing I noticed is that these are 6GB/s disks, and the thecus should handle them fine (they are on the compatibility list), but they are connected at 3.0GB/s, not 6.0.

This might be related.

So, I almost contemplated getting rid of the firmware and trying to install a real OS on the system. But there was one thing else to try first.

The version of the disk firmware was CC4B, and there were some reports with other Thecus machines that depending on the firmware version, some disks of the same model worked and some did not.

I put my disks in another machine and updated firmware to CC4H. Fun!

Steps updating seagate disks: - Boot my main Linux machine to windows for Seagate firmware update tool - firmware update tool reboots the machine into a mini linux version - which updates the disk - then reboots the machine (defaulting to main linux) - Repeat for other disks

Shoving the disks back into the Thecus, I got a small disappointment; the disks were still negotiated to 3 GB/s. Oh well.

Rebuilt the RAID array (this time as a RAID-1, I care more about redundancy than write speed and size). And this time I found out the nfs problem (or at least a workaround); when mounting with nfs4, the shares got a weird UID, and Invalid Argument if you try to chown something. However, mounting it using nfs3 makes it work.

Using RAID-1 and nfs(3) gave me 10 MB/s write speed and 2 GB/s read speed. Now that is more like it! (Again, don't care too much about write speed, but 10 MB is a lot better than 1). (EDIT: hmm, that was with a zeroed test file I just created, for normal files it appears to be about 10 MB/s read speed as well).

I have been stresstesting it all day now, and have just started the backups again. No disk I/O errors so far.

So if you get those, before doing anything drastic, check your disk firmware updates.

Happy RAIDing!

I got my Raspberry Pi yesterday!

Installation of the provided Debian image is a breeze (just make sure you have an SD card and a micro-USB cable lying around). And I am happily playing with it right now.

I didn't have a real Plan to use it yet, so in the meantime I'm using it to control my Ultimaker over a network; Due to physical constraints, I have my printer in the same room as my main desktop system, but out of reach for any sane USB cable. I have a laptop sitting right next to it to control it now, and I am thinking of getting an Ulticontroller.

But the laptop is slow, and I want to at least be able to send prints from my main machine to the Ultimaker. Also, should I get rid of the laptop, I have more room to stuff tools and prints. It's getting a bit messy.

So, Use 1 for the Raspberry Pi was born!

Originally I was thinking of writing a fake serial driver, that passed on all data to a fake serial client, running on the Pi, but it turns out that isn't even necessary; we can use the socat tool.

I have not fully fleshed out all details yet, and there are some current problems, but I thought I'd share.

Basic steps:

1. Install socat on client and on raspberry pi
2. Connect Raspberry to network
3. Connect Raspberry to Ultimaker
4. On raspberry, run:

   socat -d tcp-listen:<some port>,fork /dev/ttyACM0,raw,echo=0,b<your Ultimaker firmware baudrate>

5. On client machine, run:

   socat -d PTY,link=~/ttyACM0,raw,echo=1,wait-slave tcp:<IP address of raspberry>:<same port as previous command>

(I used port 12346 for no reason at all)

Go to your controller tool (e.g. PrintRun), and set the port to ~/ttyACM1.

And start printing!

Well, not exactly. While the above works with PrintRun, it does not with Cura.

Cura appears to have a fixed set of possible ports (I can't edit the field), so we'll have to use one of the standard names. This presents us with a problem, since in order to use, for instance /dev/ttyACM0, we'll need to run socat as root. And if we run socat as root, our client (which we will certainly not run as root), can't connect.

A quick workaround is to change ownership of /dev/ttyACM0 once socat is running;

sudo socat -d PTY,link=/dev/ttyACM0,raw,echo=1,wait-slave tcp:192.168.8.24:12346
chown <your username> /dev/ttyACM0

I suspect there may be some option within socat for this, but I have not looked for it yet.

Obviously, this also 'opens' your printer to your entire network. You can also do it without the listening side, though, but you probably want to set up ssh-keys first, so you do not need to enter a password every time. Once you have, you can use something like:

 socat PTY,link=~/ttyACM0,raw,echo=1,wait-slave EXEC:'"ssh \
 pi@<IP address of raspberry> socat - /dev/ttyACM0,nonblock,raw,echo=0,\
 b<your Ultimaker firmware baudrate>"'

There are more issues:

• The socat instances can quit, in which case you need to run them again, so at this point it is not a fire-and-forget kind of initialization.
• I have no idea what will happen if you plug in something that might initialize a serial port itself. I hope socat is nice in registering itself (so the tty will not be assigned to something else), but I have not tried this out.
• You may not want to do this over a flaky WiFi connection.

Anyway, I'm using this to print out a case for my raspberry right now. Let's see how it goes!