Pretty big side-effect

Timing and side-channels are not normally considered side-effects, meaning compilers and cpus feel free to do whatever they want. And they do. Unfortunately, I consider leaking my passwords to remote attackers prety significant side-effect... Imagine simple function.
void handle(char secret) {}
That's obviously safe, right? And now
void handle(char secret) { int i; for (i=0; i<secret*1000000; i++) ; }
That's obviously bad idea, because now secret is exposed via timing. Now, that used to be the only sidechannel for a while, but then, caches were invented. These days,
static char font[16*256]; void handle(char secret) { font[secret*16]; }
may be bad idea. But C has not changed, it knows nothing about caches, and nothing about side-channels. Caches are old news. But today we have complex branch predictors, and speculative execution. It is called spectre. This is bad idea:
static char font[16*256]; void handle(char secret) { if (0) font[secret*16]; }
as is this:
static char small[16], big[256]; void foo(int untrusted) { if (untrusted<16) big[small[untrusted]]; }
CPU bug... unfortunately it is tricky to fix, and the bug only affects caches / timing, so it "does not exist" as far as C is concerned. Canonical fix is something like
static char small[16], big[256]; void foo(int untrusted) { if (untrusted<16) { asm volatile("lfence"); big[small[untrusted]]; }}
which is okay as long as compiler compiles it the obvious way. But again, compiler knows nothing about caches / side channels, so it may do something unexpected, and re-introduce the bug. Unfortunately, it seems that there's not even agreement whose bug it is. Is it time C was extended to know about side-channels? What about
void handle(int please_do_not_leak_this secret) {}
? Do we need new language to handle modern (speculative, multi-core, fast, side-channels all around) CPUs?
(Now, you may say that it is impossible to eliminate all the side-channels. I believe eliminating most of them is well possible, if we are willing to live with ... huge slowdown. You can store each variable twice, to at least detectrowhammer. Caches still can be disabled -- row buffer in DRAM will be more problematic, and if you disable hyperthreading and make every second instruction  lfence, you can get rid of Spectre-like problems. You may get 100x? 1000x? slowdown, but if that's applied only to software that needs it, it may be acceptable. You probably want your editors & mail readers protected. You probably don't need gcc to be protected. No, running modern web browser does not look sustainable).

Crazy complexity

Its crazy how complex PCs have become. ARMs are not exactly simple with the TrustZone and similar stuff, but.. this is crazy. If you thought you understand x86 architecture... this is likely to prove you wrong. There's now non-x86 cpu inside x86 that performs a lot of rather critical functions...
...and shows that SGX indeed is evil.

Microsoft sabotaging someone else's computers

My father got himself in a nice trap: he let his Lenovo notebook to update to Windows 10. Hard to blame him, as user interface was confusing on purpose.Now 2 out of 3 USB ports are non-functional (USB 2 port works USB 3 ports don't), and there's no way to fix that. And apparently, Microsoft knew about the problem. Congratulations, Microsoft...

Ouch and they are also sending people to jail for producing CDs neccessary to use licenses they already sold. Microsoft still is evil.

O2 attacking their own customers

Just because you are paying for internet service does not mean O2 will not try to replace web-pages with advertising. Ouch. Seems like everyone needs to use https, we need better network-neutrality laws, and probably also class-action lawsuits.

Dark design patterns

Got Jolla installed. Ok, it looks cool. But already some unnice things can be seen. You _need_ jolla account to install apps. You need to agree to nasty legaleese. You are asked for name and password, it looks like that's all, and then it wants to know real name, email address, birthday... Appstore looks cool... but does not list licenses for software being installed. Still better than Android. Miles away from Debian.
It also seems to require login separate from app store login to get the "really" interesting stuff. Unfortunately, I don't know how to get that one.
I'd quite like to get python/gtk to work on Jolla (or maybe Android). If someone knows how to do that, I'd like to know. But I guess running Maemo Leste is easier at the moment.

Motorola Droid 4 is now usable

23.4.2018, around 12:34... I realized how unix ttys are sabotaging my attempts to send SMS.. and solved it. So now I have Motorola Droid 4, running 4.17-rc1 kernel, with voice calls working, SMSes, data connection, GPS working and have some basic GUIs to control the stuff. WIFI works. Screen locks, and keyboard map still could be improved. Battery life will probably will not be great. But hey, its a start -- I have GNU/Linux working on a cellphone. More precisely Maemo Leste, based on Devuan, based on Debian. Sure, some kernel patches are still needed, and there's a lot more work to do in userland... Today, Microsoft sold out last Windows Mobile phones. I guess that's just a coincidence.

Fun with Rust (not spinning this time)

Rust... took me while to install. I decided I did not like curl | sh, so I created fresh VM for that. That took a while, and in the end I ran curl | sh, anyway. I coded weather forecast core in Rust... And I feel like every second line needs explicit typecast. Not nice, but ok; result will be fast, right? Rust: 6m45 seconds, python less then 1m7 seconds. Ouch. Ok, rust really needs optimalizations to be anywhere near reasonable run-time speed. 7 seconds optimized. Compile time is... 4 seconds for 450 lines of code. Hmm. Not great. .. but I guess better than alternatives.

Hey Intel, what about an apology?

Hey, Intel. You were selling faulty CPUs for 15+ years, you are still selling faulty CPUs, and there are no signs you even intend to fix them. You sold faulty CPUs for half a year, knowing they are faulty, without telling you customers. You helped develop band-aids for subset of problems, and subset of configurations. Yeah, so there's work around for Meltdown on 64-bit Linux. Where's work around for Meltdown on 32-bit? What about BSDs? MINIX? L4? Where are work arounds for Spectre? And more importantly -- where are real fixes? You know, your CPUs fail to do security checks in time. Somehow I think that maybe you should fix your CPUs? I hearing you want to achieve “quantum supremacy". But maybe I'd like to hear how you intend to fix the mess you created, first? I actually started creating a workaround for x86-32, but I somehow feel like I should not be the one fixing this. I'm willing to test the patches...

(And yes, Spectre is industry-wide problem. Meltdown is -- you screwed it up.)