Table of Contents
I’ve become a proud PinePhone owner a few days ago. This is an open and privacy-respecting alternative to Apple-Google duopoly in the smartphone market. This phone is capable of running mainline Linux kernel, which makes it not that different from a typical Linux desktop.
Most of the Linux distributions have certain assumptions about your screen size as well as the availability of a keyboard, mouse, trackpad and other input devices. Now that we have Linux smartphones, we still need to make those distributions aware of mobile screens and touch input methods. That’s exactly why I didn’t expect PinePhone to be usable as a daily driver.
It turned out, a lot of the heavy lifting has been already done by a diverse group of mobile Linux enthusiasts. In fact, many popular Linux distributions work pretty well on PinePhone. Let’s start with the basics: phones should be able to make and receive calls and they’re also expected to handle SMS messages. PinePhone already does it pretty well, although it still lacks MMS support, and it’s unknown if it’s able to receive emergency broadcasts. I never used MMS, so I don’t care about it. Being able to receive an emergency broadcast is something I expect from a “daily driver” phone, but we’ll have to wait for the next few emergencies to find out if those broadcasts will arrive.
Basic phone stuff is cool, but what about touchscreen support? There are two popular touch-enabled mobile shells available:
Phosh is based on GTK, a popular Linux widget toolkit. It does a good job at adapting desktop GNOME experience to smartphone screens and it also supports touch input. Plasma mobile is KDE-based, and I didn’t try it yet. The screenshots look pretty good, though. These two projects did a lot of heavy lifting in order to bridge the gap between traditional Linux desktops and Linux smartphones such as PinePhone.
Having basic phone functions and a touch interface is essential but there are a lot of other things that work a bit different on smartphones. Here are a few examples:
- Power consumption. There is a huge room for improvement.
- GPS. Figuring out device location and keeping it up to date isn’t as easy as it may sound.
- Alarms. Yes, it’s actually a surprisingly complex thing to implement, and it’s not working yet. Desktop computers aren’t used as alarm clocks that often, so it’s a new use case that needs to be implemented. Don’t rely on PinePhone if you don’t want to miss your alarms!
As you can see, PinePhone is still work in progress. It’s usable, and it’s pleasant to use, but you have to know its quirks. All of its hardware components work great, and you can easily replace them if something goes wrong. As usual, the software has to catch up with the hardware in order for PinePhone to be accessible to non-techies. I’m pretty sure I will be able to recommend such a phone to users without Linux knowledge in about a year or so.
State of the Lightning Network
I continued my experiments with Lightning Network. My focus was on the things that can go wrong if you decide to operate a Lightning node. It turned out, a lot of things can go wrong ranging from the typical ops problems such as hardware failures to the exotic and counterintuitive ones, such as Lightning backups.
Let’s start with counterintuitive ones, as they’re more interesting. Every good systems’ administrator knows that having regular backups is essential to make sure your data is safe. Having a backup is always good, it protects you from losing your precious data. When it comes to managing Lightning nodes, having a full backup can be an extremely dangerous thing because it can lead to the loss of your funds. The thing is: Lightning Network prevents cheating by punishing people for presenting an outdated states of their channels.
The reason is pretty simple, let’s say you opened a channel with a local bar, and it started with $100 on your side and $0 on the side of the bar. After a few great evenings, all the money ends up on the side of the bar, since you paid with Lightning Network. What makes Lightning Network so fast and cheap compared with Bitcoin is the fact that you can move money from one side of your channel to another without triggering a costly and slow Bitcoin transaction, but as some point, you’ll want to close the channel and both sides will be able to reclaim their bitcoins. Both sides know the latest state of the channel and if any side tries to cheat and broadcast a previous state ($100 on your side, for example), the other side can prove that it has a newer state and get all the money as a reward for detecting cheating. Well, the problem is: backups have an older states, so they can be seen as cheating, that’s why it isn’t a good idea to use full backups.
That’s crazy, right? How can we back up a Lightning node? There is a mechanism called Static Channel Backup. It’s not ideal, but it should work. The problem with this kind of backup is that it won’t recover your channels in case of a node failure. It can only recover your bitcoins by force-closing all of your channels.
There are currently no reliable ways to back up and restore Lightning channels. The best thing an operator can do is to minimize the probability of a node failure. What can fail if you’re running Raspiblitz on a Raspberry Pi 4?
- The board itself. Just buy more boards and you’ll be fine.
- An SD card. Again, redundancy is you friend. Just keep a spare SD card and you’ll be able to recover your node without using backups.
- An SSD/HDD. Failure of a main storage device would be a problem. Luckily for us, SSD/HDD failure rates are pretty low, and it’s unlikely to happen. If you’re paranoid, set up a RAID array with a comfortable level of redundancy. I think it’s an overkill unless your node is handling a lot of money.
- Electricity shortage. Unexpected shutdowns can corrupt your data, and you have to avoid such situations. Buying a good UPS should solve that problem.
As you can see, good old redundancy can solve most of your problems if you want to operate a highly available Lightning node. Backups are tricky because using wrong backups can lead to the loss of money and using proper backups leads to force-closing all of your channels. Losing your channels is unfortunate, but it’s a “worst case” that shouldn’t really happen. Even if you’re unlucky, the only thing you would lose is blockchain transaction fees.
Android Smartphones Will Live Longer
Android smartphones are notoriously short-lived. Recently, I found my old Nexus 6 in an old storage box. The hardware still works and works perfectly, but this phone was abandoned by Google 18 months since its initial release. Samsung’s phones are no better. In fact, there are no manufacturers who support their Android devices for more than a couple of years. Why is it so?
Well, because they can, that’s why. Consumers were busy updating their phones every year of two, why would a phone or a chipset manufacturer support them for a longer time? The smartphone market was “hot”, but it cooled down quite a bit recently and now consumers want their phones to last much longer.
Most of Android smartphones use Qualcomm chips and now it promises to provide all the necessary updates for four years. That’s a good start, but it’s still not enough. There needs to be more pressure from the consumers when it comes to device longevity and repairability.
Automatic Updates on Linux Severs
Outdated software is a security nightmare and there are good reasons to keep it up to date. That’s kind of a general rule which I tend to apply everywhere. Lately, I was involved in a discussion about the risks and benefits of automatic security updates applied to servers running “hot” Bitcoin wallets.
It turned out, a lot of people in Bitcoin industry are strongly against automatic security updates. Their main concern is the possibility of supply chain attacks. By running certain software you put a lot of trust in its developers, and you should never run the software made by people you don’t trust. The naive assumption would be: I already trust the developers, so I should enable automatic updates. If those developers feel that the update is necessary, it probably is.
I used to think like this, but this approach has some flaws. When I install and run a certain program, I can’t avoid trusting the developers as well as the distribution channel and all the things in between. Why shouldn’t I trust the updates then? Well, developers can get hacked, as well as the distribution channels. Every update can be compromised, it’s not a risk-free action after all. On the other hand, not having the latest security updates is also risky, although it really depends on how you use unpatched software.
That said, how can we balance those risks and benefits? It’s more of an art than science, I guess. Let’s say a hacker manages to get access to a hundred of Bitcoin wallets via supply chain attack. He’d be very happy, indeed, and he’d likely to try to transfer all the money to his own wallet, triggering a lot of drama in the community. This kind of attack can only harm people who updated from “poisoned” sources. That’s why it might be wise to not update your software too often, especially if it runs something critical such as “hot” Bitcoin wallet. It’s a kind of compromise, you don’t want to miss on years of security updates but having a healthy “lag” of a few weeks can actually be beneficial. Of course, some updates might be critical, but you’ll likely hear about them from many sources and be able to perform a manual out-of-schedule intervention.
Bond Market Updates
It was an interesting month for a bond market. The interest rates on 10-year American Treasuries have risen from ~1.10% to ~1.45% during February. Bonds are low-risk assets, some people even call them risk-free assets. When interest rates go up, the value of the bonds goes down. This can mean many things, such as:
- People are less interested in risk-free assets because they’re optimistic about the future of the economy, so they want to put their money into more risky and profitable assets.
- People expect more inflation in the future and demand some compensation.
Many factors can be at play at any given time. Let’s not forget that the Fed has been quite pro-inflationary lately. That doesn’t mean people aren’t optimistic about the end of the Coronavirus pandemic, for example. They have a reason to be optimistic, after all.
The main problem with rising interest rates is the fact that a lot of countries and corporations have a huge amount of debt. It’s not a problem when the interest rates are near zero, but it’s hard to find money to pay interest on your loans once the rates go up. The corporations may be forced to cut their spending, the governments may introduce austerity measures and all of those things slow down the rate of economic growth. Needless to say, it never fully recovered from the Great Recession, and the perspective of further slowdown might blow up our already unstable political systems.
VS Code Supports ARM
Visual Studio Code is a popular multi-purpose text editor and IDE. It’s one of my favorite code and configuration editors, but it also comes bloated with a lot of shady code from Microsoft. Fortunately, there is an open source project called VS Codium and it uses only the good and open parts of the original VS Code.
I’ve written a small post about my experience visiting Hellfire Pass and reading a few books about its history.