Windows 10 – the horror of upgrade to 1903+ releases

I had the misfortune the other day that one of my machines updated beyond 1809 release. There are three changes that immediately infuriated me.

1. Colour scheme change and removal of availability of black colour menus

The colour scheme changes upon upgrade. Not only is it a rather bright one going back to the ’90s style and contrary to dark themes that are easier on the eyes, laptop batteries and screen burn, but there is no way to full revert back. In order to get anywhere near black it is now necessary to disable the transparency effects, and even then it is still not black but dark grey.

Visually, this is a huge downgrade that cannot be fully mitigated or undone. And a bit of googling will show that I am far from the only one infuriated by this change.

2. File explorer grouping by default instead of continuing with previous default

As soon as you open your file folders after the upgrade, the files are now grouped by default. I can understand that this might be a new default setting, but on an upgrade, old behaviour should be preserved. If somebody chose not to view their files grouped, they should not be overriden by the upgrade and made to waste their time putting things back the way they were. Worse, this seems to revert the the new annoying default randomly.

Microsoft needs to understand that the ONLY reason why anyone uses Windows instead of a different operating system is long term inertia of familiarity. Chipping away at that familiarity will just push more users away from Windows and toward other operating systems. This is user alienation by a million paper cuts.

3. Start menu auto-expand

This one is incredibly annoying for a change so minor. There is supposedly a way to disable this using the mach2 tool, but it doesn’t seem to have worked for me – no matter what I do, I couldn’t get it to turn off and stay off.

Conclusion

So what did I do? Well, this is a VM – I refuse to run Windows on bare metal since over a decade ago, because it is too prone to getting itself into a state where various things break in a way that all the googlable solutions just don’t work and the only solution is to format and reinstall (windows update getting broken is a common show stopper). Being a VM, it doesn’t run on a real disk but a virtual one. I run my VMs on ZFS zvols, which are regularly snapshotted. So I powered off the VM, performed a zfs rollback to a pre-upgrade snapshot, and as if by magic, all of the damage done by releases after 1809 have been undone and things are back in a state where at least the new annoyances are gone. Best of all, zfs rollback took a few milliseconds instead of the lengthy rollback using Windows restore that probably wouldn’t have put things back quite to exactly the same state the machine was in before.

The upgrade will no doubt be forced on me at some point, in a way that I can’t avoid it any more. The feature upgrades can only be postponed by 365 days and disabled for another 30. But at least – today is not that day.

Plea to Microsoft

Please, for the love of God, stop changing things in ways that nobody asked for, nobody wanted, and nobody likes. Make your designers and developers learn from the fiasco of the ribbon interface.

Hardware Accelerated SSL on ARM – Redux

A long time ago, I posted an article about advantages of hardware accelerated SSL encryption, and how to get it working on Fedora Linux. Since then, some things have improved, and some things have regressed.

Improvements:

Regressions:

  • RedHat have broken OpenSSH with their audit patch. This is particularly inconsistent with the fact that the distro supplied openssh package in EL6 is built with the –with-ssl-engine option, to enable support for hardware crypto acceleration, yet this is clearly completely untested, which begs the question of what the point of it is.

Thankfully, the regression mentioned above can be fixed to make sshd work properly with hardware crypto offload.

Here are links to patched OpenSSL and OpenSSH packages for EL6, current at the time of writing this article:

http://ftp.redsleeve.org/pub/el6-staging/packages/soc/SRPMS/openssl-1.0.1e-30.el6.11.cryptodev.src.rpm

http://ftp.redsleeve.org/pub/el6-staging/packages/soc/SRPMS/openssh-5.3p1-104.el6.1.cryptodev.src.rpm

While ssh with using the blowfish algorithm in software is very fast and good enough for general purpose ssh usage, for some operations, such as transferring ZFS snapshots over ssh, using hardware offloaded AES provides a very welcome performance boost, because it leaves more CPU available for other processes.

ZFS-FUSE 0.7.1 Released

The last official release of zfs-fuse was years ago, and it was seriously starting to fall behind other implementations. It was effectively abandoned, which is quite inconvenient considering it is still the only viable option on 32-bit Linux installations (e.g. on ARM or those who are still tied to i686 for legacy reasons).

Since I use Linux on ARM heavily, I have been working on changing this for the past few weeks. The last official release 0.7.0 was made by Seth Heeren a few years ago, and this supported ZFS pool versions up to v23. Emmanuel Anne was maintaining an unofficial post-0.7.0 branch that had support for pool versions up to v26 added. Over the past couple of years, other people have contributed a few patches here and there (manual ashift setting at boot time, some patches to add support for ARM, a couple of patches maintained out of tree shipped with the Fedora package). Over the past few weeks I need a few additional features that have existed in other implementations, particularly for running a root file system on it (mount.zfs for legacy mount points, and better systemd/initramfs), so I added those features. It also transpired that a few of the patches that made it into the official 0.7.0 release weren’t in Emmanuel’s code tree since it was forked before the official 0.7.0 release. I located and backported those from Seth’s maint branch on github.

With all this done, and with no other volunteers showing any interest in further maintaining zfs-fuse, it seems to have fallen to me to make the decision to take the 0.7.1 release. I have tested this extensively on my ARM systems with pools of various sizes (16GB to 16TB) and complexities (single disk to RAIDZ2) and it has been very stable.

If you are stuck on a 32-bit Linux platform and would love the features of ZFS, you can find the latest release of zfs-fuse on on github:

https://github.com/gordan-bobic/zfs-fuse

Future work will include adding support for additional pool versions. I have already created branches for those, but, this will need extensive testing before I deem it stable enough for a release. If you are interested in helping with either development or testing of zfs-fuse, please, do get in touch.