Device

An old find I found an old cubieboard3 (cubietruck) collecting dust in a drawer, so I took the chance to try out Rust cross compilation and collect here some notes about the process. Here’s the baby: Give it a penguin First of all, I installed an ARM linux distro on a MicroSD card and started the device: [user@arm ~]$ cat /proc/cpuinfo processor : 0 model name : ARMv7 Processor rev 4 (v7l) BogoMIPS : 50.52 Features : half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xc07 CPU revision : 4 processor : 1 model name : ARMv7 Processor rev 4 (v7l) BogoMIPS : 50.52 Features : half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xc07 CPU revision : 4 Hardware : Allwinner sun7i (A20) Family Revision : 0000 So our device is ARM model v7l ; this means is a 32bit CPU, if you are curious there’s also a reference manual around. Now we will work from a development machine. ...

Prelude This is a followup from my previous post and a sort of continuation on the series of the topic, where we are exploring ways to make our test system more “unreliable” in order to observe if our applications behave nicely under challenging and not-ideal environments. In this article we are going to explore some linux technologies: Network Namespaces (netns) Virtual Ethernet Devices (veth) Network Emulation (netem) scheduling policy The goal is to setup a virtual network link inside our system, make the two network devices talk each other and then simulate a bad/slow/glitchy/flaky communication to test how applications behave under difficult conditions. ...

“You sound like a broken record” Is something we complain when someone repeats again and again the same concepts. But even broken disks can sometime be useful DISCLAIMER: No filesystem or device were harmed in the making of this experiment 😉 Image credits: Mick Haupt In this article I would like to explore the powerful tools we have in Linux to simulate dealing with broken disks, that is, drives that more or less randomly report errors. Why is this important ? Because by simulating errors that will also happen sooner or later in the real world, we are able to create software that is more robust and can withstand any problems on the infrastructure. ...