Using USB-C to charge a laptop while simultaneously providing display and other IO traffic sounds a little bit too good to be true in practice. Maybe it would work for a set of devices from a single manufacturer (like a Thunderbolt-based USB-C-attached dock from the same vendor as a laptop). However, recently I was surprised (in a good way) when it turned out that I had accidentally got myself a USB-C-based single-cable-to-the-laptop setup. USB-C promises a lot, in this case it delivers perfectly, but what bothers me is the fact that there is really no way I could have figured this out ahead of time.Continue reading “USB-C Works, but how would you Know?”
The USB standard has spawned quite a few connector variants over the year. Apart from the basic “A” connector (the one that you put in one way, then the other way, and finally the right way), there have been quite a few mini and micro variants of the “B” connector. Now, with “C” we seen to be approaching, finally, a reduction in the number. But it seems to me that there is a need for another variant…
Last year (2015), a paper called “Don’t Panic: Reverse Debugging of Kernel Drivers” was presented at the ESEC/FSE (European Software Engineering Conference and the ACM SIGSOFT Symposium on the Foundations of Software Engineering) conference. The paper was written by Pavel Dovgalyuk, Denis Dmitriev, and Vladimir Makarov from the Russian Academy of Sciences. It describes a rather interesting approach to Linux kernel device driver debug, using a deterministic variant of Qemu along with record/replay of hardware interactions. I think this is the first published instance of using reverse debugging in a simulator together with real hardware.
There is a very interesting worm going around the world right now which is specifically targeting industrial control systems. According to Business Week, the worm is targeting a Siemens plant control system, probably with the intent to steal production secrets and maybe even information useful to create counterfeit products. This is the first instance I have seen of malware targeting the area of embedded systems. However, the actual systems targeted are not really embedded systems, but rather regular PCs running supervision and control software.
I have an old Canon LIDE 30 scanner that I purchased sometime late in 2003. At that time, it was connected to a PC running Windows XP, and drivers worked just fine. However, after I got my new computer in early 2009, with Vista 64, there are no more drivers available. There is a funny way around this though, using a virtual machine.