For a little while it was possible to spend Bitcoin twice. Think of it like a coin on a string, you put it into the vending machine to get a delicious snack, but if you pull the string quickly enough you could spend it again on some soda too. Except this coin is worth something like eighty-grand.
On September 20, the full details of the latest fix for the Bitcoin Core were published. This information came two days after the fix was actually released. Two vulnerabilities were involved; a Denial of Service vulnerability and a critical inflation vulnerability, both covered in CVE-2018-17144. These were originally reported to several developers working on Bitcoin Core, as well as projects supporting other cryptocurrencies, including ABC and Unlimited.
Let’s take a look at how this worked, and how the network was patched (while being kept quiet) to close up this vulnerability.
It seems a simple enough concept for anyone who’s spent some time hacking on open source code: once you release something as open source, it’s open for good. Sure the developer might decide that future versions of the project close up the source, it’s been known to happen occasionally, but what’s already out there publicly can never be recalled. The Internet doesn’t have a “Delete” button, and once you’ve published your source code and let potentially millions of people download it, there’s no putting the Genie back in the bottle.
But what happens if there are extenuating circumstances? What if the project turns into something you no longer want to be a part of? Perhaps you submitted your code to a project with a specific understanding of how it was to be used, and then the rules changed. Or maybe you’ve been personally banned from a project, and yet the maintainers of said project have no problem letting your sizable code contributions stick around even after you’ve been kicked to the curb?
Due to what some perceive as a forced change in the Linux Code of Conduct, these are the questions being asked by some of the developers of the world’s preeminent open source project. It’s a situation which the open source community has rarely had to deal with, and certainly never on a project of this magnitude.
Is it truly possible to “take back” source code submitted to a project that’s released under a free and open source license such as the GPL? If so, what are the ramifications? What happens if it’s determined that the literally billions of devices running the Linux kernel are doing so in violation of a single developer’s copyright? These questions are of grave importance to the Internet and arguably our way of life. But the answers aren’t as easy to come by as you might think.
When we first heard Nim, we thought about the game. In this case, though, nim is a programming language. Sure, we need another programming language, right? But Nim is a bit different. It is not only cross-platform, but instead of targeting assembly language or machine code, it targets other languages. So a Nim program can wind up compiled by C or interpreted by JavaScript or even compiled by Objective C. On top of that, it generates very efficient code with — at least potentially — low overhead. Check out [Steve Kellock’s] quick introduction to the language.
The fact that it can target different compiler backends means it can support your PC or your Mac or your Raspberry Pi. Thanks to the JavaScript option, it can even target your browser. If you read [Steve’s] post he shows how a simple Hello World program can wind up at under 50K. Of course, that’s nothing the C compiler can’t do which makes sense because the C compiler is actually generating the finished executable, It is a bit harder though to strip out all the overhead yourself.
There is a widely derided quote attributed to [Bill Gates], that “640k should be enough for anyone”. Meaning of course that the 640 kb memory limit for the original IBM PC of the early 1980s should be plenty for the software of the day, and there was no need at the time for memory expansions or upgrades. Coupled with the man whose company then spent the next few decades dominating the software industry with ever more demanding products that required successive generations of ever more powerful PCs, it was the source of much 1990s-era dark IT humour.
In 2018 we have unimaginably powerful computers, but to a large extent most of us do surprisingly similar work with them that we did ten, twenty, or even thirty years ago. Web browsers may have morphed from hypertext layout formatting to complete virtual computing environments, but a word processor, a text editor, or an image editor would be very recognisable to our former selves. If we arrived in a time machine from 1987 though we’d be shocked at how bloated and slow those equivalent applications are on what would seem to us like supercomputers.
[Nikita Prokopov] has written an extremely pithy essay on this subject in which he asks why it is that if a DOS 286 could run a fast and nimble text editor, the 2018 text editor requires hundreds of megabytes to run and is noticeably slow. Smug vi-on-hand-rolled GNU/Linux users will be queuing up to rub their hands in glee in the comments, but though Windows may spring to mind for most examples there is no mainstream platform that is immune. Web applications come under particular scorn, with single pages having more bloat than the entirety of Windows 95, and flagship applications that routinely throw continuous Javascript errors being the norm. He ends with a manifesto, urging developers to do better, and engineers to call it out where necessary.
If you’ve ever railed at bloatware and simply at poor quality software in general, then [Nikita]’s rant is for you. We suspect he will be preaching to the converted.
We live in a time when you don’t have to know assembly language to successfully work with embedded computers. The typical processor these days has resources that would shame early PCs and some of the larger ones are getting close to what was a powerful desktop machine only a few years ago. Even so, there are some cases where you really want to use assembly language. Maybe you need more speed. Or maybe you need very precise control over timing. Maybe you just like the challenge. [Robert G. Plantz] from Sonoma State University has an excellent book online titled “Introduction to Computer Organization: ARM Assembly Langauge Using the Raspberry Pi.” If you are interested in serious ARM assembly language, you really need to check out this book.
If you are more interested in x86-64 assembly and Linux [Plantz] has you covered there, too. Both books are free to read on the Internet, and you can pick up a printed version of the Linux book for a small payment if you want.
If you’ve ever written any Python at all, the chances are you’ve used iterators without even realising it. Writing your own and using them in your programs can provide significant performance improvements, particularly when handling large datasets or running in an environment with limited resources. They can also make your code more elegant and give you “Pythonic” bragging rights.
Here we’ll walk through the details and show you how to roll your own, illustrating along the way just why they’re useful.
Modern operating systems insulate us — as programmers, especially — from so much work. Depending on how far back you go, programmers had to manage their own fonts, their own allocation space on mass storage, or even their own memory allotments. Every year, though, it seems like things get easier and easier. So why is it so annoying to open a simple serial port? It isn’t hard, of course, but on every operating system it seems to be painful — probably in an attempt to be flexible. And it is even worse if you want portability. I needed to write some C code that read data from an FPGA’s embedded logic analyzer, and I was annoyed at having to write yet more serial port code. I have my own shim library, but it isn’t well tested and isn’t all that flexible — it does what I need, but I wanted something better. What I wound up with the serial library from Sigrok. You know Sigrok? The logic analyzer software.
You might counter that the serial port is old hat, so no one wants to support it with modern systems. While the physical serial port might be on life support, there’s no shortage of equipment that connects via USB that appears to be a serial port. So while I was talking to an FTDI chip on an FPGA board, you could just as well be talking to an Arduino or a USB voltmeter or anything.
I guess the Sigrok developers had the same problem I did and they took the time to write a nice API and port it to major platforms. Although Sigrok uses it, they maintain it as a separate project and it was just what I needed. Sort of. I say sort of because the version installed with Ubuntu was old and I needed some features on the newest release, but — as usual — the Internet came to the rescue. A quick Git command, and four lines of build instructions and we were ready to go.
