Stephan Paukner :: syslog

Since ham radio call signs can contain both the letter O and the digit 0 at the same time, the zeros are often represented as a slashed zero in print. But because there's no ready-hand (Unicode) character for this, the letter Ø is used most often instead, since one cannot always use a monospace font which already represents the zero in slashed form. (This problem could also occur in other cases, such as printing hashes or codes.)

There's a lot of ham radio logging software outside that supports a workflow for printing QSL cards or label stickers, and I'm not sure if any of these supports the replacement of zeros with Ø before print—only in call signs, and not in other data such as date, time or frequency. The software I use on Ubuntu, CQRLOG, exports QSOs into a CSV file that can be read in by gLabels to perform or prepare the actual print. I wanted a step in between that transforms that CSV file by substituting that Ø only in call signs. It took me some time, but here's my solution (showing a bogus CSV line):

My experiment with crypto coins is over. (No, these are no currencies.)

Last summer, when the crypto hype started taking off, I decided to get my hands dirty and to learn what’s up with this stuff. I decided to spend around €50 on each of a few established crypto coins and expected to lose them all.

My take-away now is: I’m so glad I got everything back into real money. Crypto coins are a fad and will not revolutionize anything in this shape but scam. Crypto coins only work in times of (relative) stability and working infrastructure. Crypto coins are no way to protect wealth from disasters such as weather, government, nuclear meltdown or financial system meltdown. Crypto coins need way too much energy, they live in a world of busily buzzing networks and heated-up CPUs and GPUs. All this crypto stuff is not ready for prime time (or has its prime time already passed?), it’s much too complicated, you have to have too much and too deep technical knowledge to be able to handle your funds. Here are some examples I experienced myself:

• You have to manage a scattered and varied set of crypto wallets to actually store your funds. Mine included online wallets, local wallets on my (Linux) PC and an exchange.
• Because you do not want to save your passwords, you have to memorize them very well, and to not forget them, you have to log into your wallets regularly. If you try a few wrong passwords, your IP is slowed down or blocked, and you locked yourself out, right when you actually needed access. Of course, you use 2FA, and you’re thus dependend on your smartphones or tablets happily running.
• For every transfer, you have to click through a wall of confirmations, captchas, more 2FA codes, and verifications via e-mail. You depend on access to your e-mails. (Do your internet access points and e-mail providers anticipate large-scaled disasters?)
• If you’re too sloppy and forget to include the payment ID in your transfer to an exchange, you need their support and have to wait for days to get your funds back.
• Your balance might suddenly show up as zero. (In my case, it was my local IOTA client.) You have to do research, update your client and try pointless “reattachments to the Tangle” until you finally see your balance again and get rid of it, rid of it, exchange it into real money, my ass.
• Exchange of regular (small) amounts might be artificially slowed down or made impossible, because the networks don’t scale.

It might well be that blockchain and smart contracts reach a plateau of productivity one day, but I downright hope that crypto coins will not. Mining rigs are placed in containers next to power plants! Finance portals publish crypto reports as if these were a regular asset class! For the times ahead, better invest into something tangible or into capital that cannot be raided, like social capital or knowledge capital. I want to know something, be able to do and rely on something that does not depend on a running and ever-consuming industrial infrastructure.

I noticed that Tresorit Solo suddenly ramped up total space from 1 TB to 2 TB without any notice or extra charges. I hope this change is permanent.

Btw, since my (somewhat forced) migration from Wuala 2½ years ago I’m even more convinced of their service. Their clients for Windows, GNU/Linux & Android are very convenient and reliable. Recently they made a big revamp of their visual appearance and clients (even that for Linux).

The only thing that’s a bit odd is that they make artificial restrictions to file and directory names. In earlier versions, these files were simply and silently(!) not uploaded if they ended with a blank or dot. I was surprised and slightly shocked that these files were simply not protected, without being aware of it. Luckily, with their recent client updates, there’s now a possibility to view a list of affected files. Boy, was I surprised that there were even more restrictions: They disallow characters that Windows does not support in file names, such as

In addition, there are name collisions reported when file names only differ in capitalization, all of which are perfect features of Linux file systems that I got used to over the years. Another thing is hidden directories in Linux, which start with a dot. Some day they simply and silently didn’t get uploaded anymore. Luckily, I didn’t have to rename that many files and directories, but they were in the dozens, though. Other users could be off much worse. Finally, after renaming, those affected files got uploaded—they were in the hundreds, and I had thought they’d already been in the cloud since months.

Apart from that, I can fully recommend their service, even more now that they cost me 0.09 €/GB per year.

A roaring went through the tech-savvy finance community when Yahoo suddenly shut down its Finance API on Nov 1, 2017. Dozens of libraries and scripts that had parsed HTTP output from this API for years ceased to work. No longer could libraries such as Finance::Quote query prices of stocks, funds and currencies and hand these over to other applications such as GnuCash. By using Finance::Quote—I even wrote an extension module for it—I was affected as well, and finally I stumbled upon a solution: Version 1.41 recently introduced an Alpha Vantage module, and querying this source instead of Yahoo is straightforward.

Unfortunately, using Debian or Ubuntu one has to install this version from source, but it's not that hard to do. And for using Alpha Vantage, you have to register for an API key, but that's also no issue. One of the things that still don't work is currency conversion, as that module is still tied to Yahoo's interface. Alpha Vantage does provide currency conversion through its API, though. Looking at AlphaVantage.pm I recreated a simple Perl logic to perform currency conversion. Note that I haven't packed it into a real Finance::Quote module, it's just a simple Perl script that Works For Me™. For simplicity, I don't do any error handling. It relies on an environment variable that contains the API key. Here's how I did it:

I recently managed to reactivate my dear old Epson HX-20, a retro computer released in 1983 which I used at the end of the 1980’s and early 1990’s to learn programming. Since I even could read in some BASIC programs that were still stored on the micro cassette, I wondered if I could rescue the code directly, without using OCR on printouts or even typing it off by hand. I was aware that I was very lucky that this machine still worked after all those years—the soldering seemed to have been much more rigid back then, it might cause more issues to attempt to run old PCs which are a decade younger! To be on the safe side, I invested into a new NiCd battery pack and replaced the original one.

My research first led me to the machine’s RS-232 output, internally called “COM0”. Someone had used that some years ago to directly connect an HX-20 to a PC’s serial port, using a special cable and some adapters. Sadly, it seems that this is no longer an option, since these cables disappear, and serial-to-USB adapters only seem to work with a certain chip in this case.

Then I stumbled upon the GPL software HXTape, and I was totally baffled: What, the Epson HX-20 had an external cassette interface as well? I knew that concept from our even older machine, the Texas Instruments TI-99/4A. It connected to a special music cassette recorder and encoded data into simple “magnetic bits” onto the tape:

It was quite funny to listen to the noisy sounds when playing the MCs on an ordinary player.

This bidirectional data transfer works over ordinary mono audio cables, one for each direction. And now, it turns out the HX-20 had such an interface as well, and we never used it. But the point is, one could exploit it to decode the audio signals into the original bits and bytes by connecting the HX-20’s “MIC” port to the microphone input of a PC using a simple mono audio cable with standard 3.5 mm jacks! (How tremendous the analog world was! Keep a music cassette lying around in the basement for decades and then just play it. Try this with your ¡Phone!) And that audio decoding is exactly what HXTape is doing.

Eight years ago, I wrote in the history of my computer usage,

In 1988, when I entered grammar school, [...] I did a bit more serious BASIC programming on an Epson HX-20, which I still own today, but isn’t working anymore. [...] My cousin René taught me some BASIC things like how to use the random number generator.

Well, it turns out that this machine is still alive, as you can see in this video:

You can even watch me loading my cousin’s learning program from the micro cassette—that very lines he’d written for me on Dec 29th, 1988. Though, its output was designed for a separate and larger screen that I don’t own anymore.

I’m pretty sure that this machine had slept from ~1995 until I woke it up now. I hope I can also have a look at my other programs on that micro cassette.

Being so content with Wuala’s features I gulped when I read that they shut their service down. At least they partnered with Tresorit, another Swiss zero-knowledge cloud storage provider, to provide a dedicated transition path. Tresorit had failed for me in my research last year, because they didn’t provide a Linux client—meanwhile, they do, but it’s still a beta. In addition, there’s no easy way to test their service other than during a 14-day trial. [Update 25 Aug: The trial period is now 30 days.]

Rather than looking at what they had in common, I checked Tresorit against my usual requirements, and sadly, it misses a few points:

• There’s no on-demand-only download of files like in Wuala. You either sync 100% of a GB-heavy “Tresor”, or not at all. In Wuala, you could browse through the directory tree without allocating much disk space. [Update 25 Aug: Their desktop client is also a cloud file browser, where you can explicitly download files from unsynced Tresors.]
• The client doesn’t provide an unencrypted view of an encrypted data container on the disk while it runs. If the client shuts down, the files remain plainly unencrypted in the file system like with Dropbox. [Update 25 Aug: Files remain unencrypted only if you actually sync a Tresor.]
• There’s only a Premium plan with 100 GB for one user, or a Business plan with 1 TB for at least two users. If you only need 200 or 300 GB, you’re out of luck, as it seems. [Update 25 Aug: For Wuala switchers, their Business plan is now also available for a single user, what means 1 TB for just double the price.]

Luckily, they have planned to implement the first two, but that could take a while.

And, other than Wuala’s and Tresorit’s recommendation to export Wuala’s data once and import it as a single Tresor into Tresorit, I found out it’s much better to reorganize Wuala’s subfolders into dedicated Tresors. This makes sense, because you can configure which Tresors to sync on each machine. This way, you could e.g. create a dedicated Tresor for each employer and sync only that, so you don’t accidentally put private or third-party data onto your employer’s machines. Should you need access to one of those unsynced Tresors, though, you either do have to sync it (100%), use their web client (but file download failed in my first test), or use one of your mobile clients. [Update 25 Aug: Their desktop client is also a cloud file browser, where you can explicitly download files from unsynced Tresors.]

But, so far their service looks promising. Their clients are much more modern; e.g. Wuala’s Java desktop app or Android app have been an inferior UX. I neither know Wuala’s nor Tresorit’s user numbers, but that kind-of “merger” might generate a user base that helps Tresorit survive for a while.

And never forget: Any item in the cloud should only be a copy of an item on one of your disks.

I’m using Wuala’s cloud storage for some years now, and I tried to challenge the status quo to see if there are better alternatives available in the meantime. The main requirement for me is a zero-knowledge provider, a provider that does not know my password and cannot decrypt my data (without brute force). I found these candidates:

Wuala, Tresorit, SpiderOak, MEGA, SeaFile

(Note that SeaFile is a self-hosted open-source solution.) The next requirement is location: Servers should not be located in the USA, and there should be an Android client that supports upload ...

Wuala, Tresorit, SpiderOak^{Double-Plonk!}, MEGA, SeaFile

... and there should be an official Linux client ...

Wuala, Tresorit^Plonk!, MEGA, SeaFile

... and the service shouldn’t require exotic TCP ports such that clients work behind a corporate firewall ...

Wuala, MEGA, SeaFile^Plonk!

... and the service should support file revisions, download on demand only, and files should stay encrypted on client exit ...

Wuala, MEGA^{Triple-Plonk!}

Way to go, Wuala!