Month and a half

Current death count stands at about quarter of a million.

The first peak seems to be over in Europe, countries are heading towards easing up the restrictions - with an eye towards a second (hopefully less tragic) peak in summer. The outliers, who tried out unorthodox strategies - UK, Sweden, USA. Well, UK now has the most deaths of all EU countries. Sweden has four times the mortality ratio of Norway or Finland. USA...

USA is still before the peak. There's now talk about "stabilising" at 3000 deaths per day. Which is about the total world death count at the moment. States are already opening up, with protesters demanding end to social distancing measures.

The "month and a half" seems to be the point where most "stable" companies are running out of liquid cash. Mass layoffs are likely to happen at the May/June boundary, unless there's either a heavy government intervention or business can start again.

I'm starting my third week of the unplanned holiday leave. My bread baking is getting much better (all the supply shortages seem to be over, confirming that they were mostly due to panic buying in March) - even though the last loaf was a real "dwarven bread" offensive weapon grade one. But I do know why it came out like this, and can improve. There's some gardening work, some house improvements, a bit of open source. In general, time is passing slowly. If this was a normal situation, it'd be a rather pleasant spring.

Exponential

In the last 7 days, number of diagnosed cases went from roughly 350k world-wide to over 700k. A lot of people are going to learn what "exponential growth" means.

The tourism/travel business not so much crashed as completely disappeared in the 4 working days after I wrote the previous post. Numerous corporate groups simply terminated all contractors in that week, my contract included.

Several countries are using "temporary" epidemic regulations to permanently erode civil liberties (UK, Hungary, Poland are the ones I'm following) - nothing like panic and emergency to get things rushed through.

It's not looking good.

Pandemic

I've been told recently that the best time to keep a journal is when things change rapidly. To be able to inspect one's views and perceptions, as they change. Thus, this post.

A week ago on Saturday, Italy has just quarantined the northern regions. It seemed extreme, but on Monday already they've extended the quarantine to the whole country. Today, Sunday again, one week later, most European countries have followed. UK and Sweden were two notable outliers, until UK decided to (mostly) also accept WHO guidelines. Poland shut down international trains and flights, severely limit personal cross-border transit. USA looks extreme in their lack of response.

We've started cancelling our holiday plans as Italy announced Lombardy quarantine. Almost everything is refunded by now, except Ryanair obviously sees no reason at all to issue refunds or cancel flights. During the week, we've also decided - together with my siblings - to not travel to my Mother's birthday. She was, in the end, celebrating with my Dad and my brother who still lives with them, without any of the other planned guests. This seemed extreme by the beginning of the week, but as Saturday came, was just "new normal". We're video-calling again, daily - something I haven't done (for non-work reasons) since my early days in London in 2013.

Gyms, bars, restaurants, offices, cinemas, everything shut. Preemptively, so far. There's no confidence yet if this will slow down the growth enough to be meaningful, or will it only shift the peak without flattening it. UK was trying to bet on "herd immunity", but there's no consensus yet - and even some counterexamples - to whether COVID-19 can or can not re-infect.

I'm lucky enough to be working from home, most of the time. But my business travel took me to Germany a week ago - and while right after returning, I've laughed at the suggestion of self-quarantine, by the end of the week, it was - again - normal. Random cough was inspected extremely suspiciously - is it my normal allergies, just sped up by a month? Spring has come extremely early this year, after a mild and wet winter; we've had Wild Garlic at the beginning of February, usually it would start growing at the end of March.

Few weeks ago, SETI@Home announced shutting down their compute clients. Its "offspring", Folding@Home, is now donating most of its compute power to projects related to the ncov-19 virus analysis and vaccine work. They've just announced that with the signup spike they've experienced, they've assigned all currently available work units. Sitting at home, at least this feels like doing something to contribute. It's also heating the room up noticeably, especially when both CPU and GPU were running on full power. The electricity from solar panels is coming in handy.

Economic impact? Well it's officially a recession now. Probably the fastest one in history, with information (and panic) flowing faster than ever, plus with zero-fees brokers that have sprouted last year. There's definitely going to be a big global impact. Travel industry got hit immediately, with Flybe going bankrupt (they were really just dangling on a lifeline before); LOT is looking how to get out of promised purchase of Condor; Norwegian airlines are down 80% at the stock market, even BA is struggling. There's public calls from the airlines to postpone or scrap planned emission taxes, as they would start from the very low current baseline of extremely limited air travel. Lot of bankruptcies and takeovers are definitely on the horizon.

This brings me to the main point, what are likely to be the long term effects? The emission drop we're seeing is strictly temporary, and limited in time to quarantine (even though e.g. airlines are using it to retire old fleet), and is unlikely to last. Remote work and shopping and e-government (e.g. Polish government offices right now are not open to citizens in person, but are all still working) will likely stay afterwards at significantly higher levels, as the crisis is forcing them to happen - and thus showing where it is possible to continue "work as usual" without the commute. US is possibly looking at the most redefining experience of all Western countries - whereas in most, a health system reform afterwards is likely - in US it's either going to be a full scale "European style social support net" (which has been voted down by GOP this week already) or massive fatalities on the scale of several millions. This is not something - this would be comparable to fallout from their involvement in WW2. And disproportionately impacting the lower income part of the population, as the wealthy, the office workers, are the ones where it's easiest to self-quarantine and work from home. Even if controlled, if COVID-19 spreads through European population with "low" (under 1%) death rates as it has so far in South Korea, where (currently) it seems to be controlled - this still leads to an unprecedented numbers of deaths among the elderly, in turn leading to an unprecedented wealth transfer to the younger generation.

Even the most optimistic predictions are suggesting this to be a defining moment for future decades.

Automated installation of VS 2017 build tools

Visual Studio 2017 has re-done the whole installation procedure, with the goal of making what used to be very painful - preparing a UI-less build agent image for automated .NET builds - nice and simple. And fast. Well, it's not quite there yet. So as I was reading Chris' post on building AMI images for TeamCity build agents with Packer I was nodding along until I came to the bit where VS 2015 tools get installed. What about current tooling?

I wouldn't recommend using chocolatey to install it, unfortunately, even though a package is available. The new installer has a nasty habit of exiting silently (or hanging) if something is amiss - and you'll want to be able to choose your VS workload packages which chocolatey doesn't support.

What can fail? The installer tends to abort if any of the folders it tries to create already exists. That's why you're likely to have more luck if you don't install the .NET 4.7 framework separately - also, any .target or task dlls that are not yet provided by the installer, should be scripted for installation later, not before. Took me a whole day to find this out.

The command line parameters for the installer aren't too obvious either. "wait" doesn't wait unless you wrap it in a PowerShell script. "quiet" prints no diagnostics (well, duh) but "passive" displays a UI - there's no option for "print errors to the command line". If you're struggling, you'll end up re-creating your test VMs and switching between multiple runs of "passive" and "quiet" to see if things finally work. Oh and the download link isn't easy to find either (seriously, it seems to be completely missing from the documentation - thankfully, StackOverflow helps). And getting the parameters in the wrong order end up with the installer hanging.

The short PowerShell script that finally worked for me is:

$Url = 'https://aka.ms/vs/15/release/vs_buildtools.exe'
$Exe = "vs_buildtools.exe"
$Dest = "c:\\tmp\\" + $Exe
$client = new-object System.Net.WebClient
$client.DownloadFile($Url,$Dest)
$Params = "--add Microsoft.VisualStudio.Workload.MSBuildTools `
--add Microsoft.VisualStudio.Workload.WebBuildTools `
--add Microsoft.Net.Component.4.7.SDK `
--add Microsoft.Net.Component.4.7.TargetingPack `
--add Microsoft.Net.ComponentGroup.4.7.DeveloperTools `
--quiet --wait"
Start-Process $Dest -ArgumentList $Params -Wait
Remove-Item $Dest

Is it faster than the VS 2015 installation? Not really, the old one had an offline version you could pre-load, the new one is completely online (if you re-run it you'll get newer components!). And with VS15, a t2.micro instance was enough to run the AMI creation job - this one needs a t2.medium to finish installation in a reasonable amount of time. At least it includes most of the things that were missing before (still waiting for dotnetcore-2.0 to be included).

Using zram for memory compression on Gentoo

After reading an excellent compression on LWN about memory compression in Linux kernel and learning from a Google engineer that they employ zram to increase their workstation available memory (on top of the installed physical 48 GB ...), I've decided to give it a go. There are currently three different algorithms for memory compression being trialed in the Linux kernel, of those, zram is the simplest, but also the most mature - it's also battle tested, as it is enabled by default e.g. on Google Chromebooks. It's also available as an option in Android 4.4

zram works by presenting itself to the kernel as a swap device, while it is in fact backed by RAM. It has a fixed compression ratio of 50% (or, to be more exact, swapped out pages are either stored two-in-one for actual RAM page used or one-in-one if for some reason they don't compress). This simplifies access, keeping page offsets predicatable. A recommended configuration reserves up to 100% of physical RAM for compressed access - this memory will be released back when the memory pressure subsides. This also assumes the pessimistic scenario of incompressible pages - in practice, the zram devices should not take much more than 50% of their advertised capacity, resulting in 150% potential memory load before swapping would need to occur.

Configuration starts with enabling the kernel module:

Device Drivers  --->
    [*] Staging drivers --->
        <M> Compressed RAM block device support

This is done as a module, so that configuration can be easily changed via /etc/modprobe.d/zram.conf:

options zram num_devices=3

I've got the module set to auto-load via /etc/modules-load.d/zram.conf containing just a single line:

zram

Also needed is an entry for udev telling it how to handle zram block devices and setting their size (in /etc/udev/rules.d/10-zram.rules):

KERNEL=="zram[0-9]*", SUBSYSTEM=="block", DRIVER=="", ACTION=="add", ATTR{disksize}=="0", ATTR{disksize}="2048M", RUN+="/sbin/mkswap $env{DEVNAME}"

And the last step is an /etc/fstab entry so that those block devices are actually used:

/dev/zram0  none  swap  sw,pri=16383  0 0
/dev/zram1  none  swap  sw,pri=16383  0 0
/dev/zram2  none  swap  sw,pri=16383  0 0
/dev/zram3  none  swap  sw,pri=16383  0 0

I've seen guides recommending creation of ext4 volumes on zram devices for temporary folders. I would not advise that. Instead, create a standard tmpfs volume, with the required capacity, which will result in better performance - as unused zram device will release the memory back to the kernel.

I've been using this setup since November and haven't had any issues with it. I highly recommend enabling this on your workstation as well - after all, there's no such thing as too much RAM.

Przelewy zagraniczne do Polski i wymiana walut

A teraz coś bez związku z programowaniem. Jeśli pracujesz za granicą albo spłacasz kredyt walutowy (euro/franki/etc.) to temat pewnie jest Ci znany: masz pieniądze na koncie w innym kraju (albo tylko w obcej walucie) i potrzebujesz je przelać do Polski lub przekonwertować, płacąc oczywiście jak najmniejszą prowizję. Wypróbowałem już kilka wariantów, więc przedstawię pokrótce metodę, którą aktualnie stosuję oraz parę alternatyw.

Zacznę od sytuacji najprostszej, czyli kredytu walutowego: od września 2011 banki działające w Polsce muszą za darmo udostępnić klientom rachunek techniczny umożliwiający spłatę rat bez płacenia spreadu. A ten, w zależności od banku, potrafił dojść i do 6%. Tak, tyle dodatkowo oddajesz swojemu bankowi, jeśli pozwalasz mu, żeby wymieniał walutę za Ciebie. Dwa lata temu, kiedy KNF wymusił na bankach zmiany, internet wysypał kantorami online, pozwalającymi wymieniać pieniądze po kursie zbliżonym do rynkowego, z minimalną prowizją. Ze sprawdzonych przeze mnie najlepszą ofertę (prawdopodobnie ze względu na największe obroty) ma Walutomat, założony w Poznaniu przez byłych pracowników Allegro. Firma zarejestrowana jest jako kantor i podlega takiemu samemu nadzorowi Ministerstwa Finansów jak fizyczne punkty wymiany walut, co jak dla mnie jest wystarczającym uwierzytelnieniem. Prowizja za wymianę wynosi 0.2%, wpłaty i wypłaty do większości dużych banków są darmowe. Korzystając z usług banku, w którym Walutomat ma swoje konto, zazwyczaj wymiana pieniędzy zajmuje około 4 godzin, z czego większość czasu to oczekiwanie na zaksięgowanie przychodzącego przelewu przez bank. Serwis wszystkie operacje potwierdza kodami SMS, w ten sam sposób może też informować o realizacji zleceń i otrzymaniu przelewu. Jedynym mankamentem jest nieobsługiwanie przelewów zagranicznych (wymagania KNF).
Jeśli często zdarza Ci się robić zakupy w zagranicznych serwisach internetowych, warto założyć kartę płatniczą do konta walutowego (oferuje taką np. Alior) i zamiast zostawiać przewalutowanie w gestii Visa/Mastercard (ok. 4% prowizji), wykonywać je samemu.
Wariant drugi: pracujesz poza granicami Polski, ale w strefie euro. Sytuacja właściwie taka sama, jak w wariancie pierwszym, bo dzięki SEPA przelewy w obrębie Unii są bezpłatne (praktycznie - przepisy wymagają, by były "nie droższe niż lokalne"). Potrzebne Ci będzie konto walutowe w polskim banku (każdy porządny prowadzi takie za darmo). Ot i cała filozofia - przelew SEPA powinien być zaksięgowany następnego dnia roboczego, co czasem prowadzi do absurdów, bo potrafi dojść szybciej niż lokalny (Irlandia, khem, khem). Co do wymiany walut, odsyłam znów do Walutomatu, nie znalazłem tańszej alternatywy. Zdecydowanie nie wykonuj przelewu walutowego na konto prowadzone w złotówkach, bo bank skasuje do 10% za wymianę.
Najciekawiej (czytaj: najbardziej upierdliwie) robi się, gdy pracujesz poza strefą euro, np. w Wielkiej Brytanii. Splendid isolation i te sprawy. Przelewy zagraniczne z UK są drogie, w okolicach 20£ (albo i więcej, zależnie od banku). WBK udostępnia tańsze przelewy (2.5£), ale z niskimi limitami (750£) i koniecznością noszenia gotówki na pocztę. Dużo z tym zachodu. Z drugiej strony, jeśli zarabiasz naprawdę dużo, to Citi oferuje darmowe przelewy między swoimi placówkami w dowolnych krajach - ale każe sobie sporo płacić za konto które nie wykazuje wystarczających miesięcznych wpływów (1800£ + 2 Direct Debit w Wielkiej Brytanii / 5000 zł w Polsce). Najwygodniejszym rozwiązaniem, jakie dotychczas znalazłem, jest TransferWise (link z moim identyfikatorem polecającego, pierwsza wymiana bez prowizji). Normalna prowizja jest wyższa niż w Walutomacie, bo 0.5% (minimum 1£), ale brak opłaty za przelew znacząco zwiększa jej atrakcyjność. Z prostych obliczeń wychodzi, że poniżej 6500£ w jednej transakcji tańszy będzie TransferWise (zakładając 20£ za przelew). Teoretycznie wymiana może trwać do 4 dni roboczych, moje jak dotąd realizowane były w około 4 godziny (od przelewu w Wielkiej Brytanii do wpłynięcia pieniędzy na konto w Polsce). Firmę założył pierwszy pracownik Skype; siedzibę mają w Shoreditch, wylęgarni londyńskich start-upów, są też zarejestrowani w brytyjskim Financial Services Authority jako pośrednik w międzynarodowym transferze pieniędzy. Od czerwca oferuje też alternatywę dla pobierania płatności (usługi typu PayPal) pod nazwą GetPaid.
Podsumowując te wszystkie opcje w jednym akapicie: jeśli potrzebujesz wymienić waluty w Polsce - skorzystaj z Walutomatu. Jeśli chcesz przekazywać pieniądze do/z Wielkiej Brytanii albo Stanów Zjednoczonych, skorzystaj z TransferWise.

SquashFS Portage tree saving time and space

Gentoo Portage, as a package manager, has one annoying side-effect of using quite a lot of disk space and being, generally, slow. As I was looking to reduce the number of small file writes that emerge --sync inflicts on my SSD, I've came back to an old and dusty trick - keeping your portage tree as a SquashFS file. It's much faster than the standard setup and uses less (76MB vs almost 400MB) disk space. Interested? Then read on!

Requirements:

• SquashFS enabled in the kernel: File systems -> Miscellaneous filesystems -> <M> SquashFS 4.0 - Squashed file system support and [*] Include support for ZLIB compressed file systems
• Installed sys-fs/squashfs-tools
• Distfiles moved out of the portage tree, e.g. (in /etc/portage/make.conf): DISTDIR="/var/squashed/distfiles"

I'm also assuming that your /tmp folder is mounted as tmpfs (in-memory temporary file system) since one of the goals of this exercise is limiting the amount of writes emerge --sync inflicts on the SSD. You are using an SSD, right?

You will need an entry in /etc/fstab for /usr/portage:

/var/squashed/portage /usr/portage squashfs ro,noauto,x-systemd.automount 0 0

This uses a squashed portage tree stored as a file named /var/squashed/portage. If you are not using systemd then replace ro,noauto,x-systemd.automount with just ro,defaults.

Now execute mv /usr/portage/ /tmp/ and you are ready to start using the update script. Ah yes, forgot about this part! Here it is:

#!/bin/bash
# grab default portage settings
source /etc/portage/make.conf
# make a read-write copy of the tree
cp -a /usr/portage /tmp/portage
umount /usr/portage
# standard sync
rsync -avz --delete $SYNC /tmp/portage && rm /var/squashed/portage
mksquashfs /tmp/portage /var/squashed/portage && rm -r /tmp/portage
mount /usr/portage
# the following two are optional
eix-update
emerge -avuDN system world

And that's it. Since the SquashFS is read only, this script needs to first make a writeable copy of the tree (in theory, this is doable with UnionFS as well, but all I was able to achieve with it were random kernel panics), then updates the copy through rsync and rebuilds the squashed file. Make sure you have a fast rsync mirror configured.

For me, this decreased the on-disk space usage of the portage tree from over 400MB to 76MB, cut the sync time at least in half and made all emerge/eix/equery operations much faster. The memory usage of a mounted tree will be about 80MB, if you really want to conserve RAM you can just call umount /usr/portage when you no longer need it.