Things n' Stuff Thoughts about the universe in general

They’re so weird that even the explaining the context will cause many listeners to lose patience.

This post was originally written in response to The Linux Experiment’s “Redis ditches FOSS” item, where Nick, the presenter, was critical of the recent Redis license change where they moved from the original BSD license to MongoDB’s SSPL, a change that was portrayed (and I’m paraphrasing a bit) as “the company taking the code the open source volunteers have given them and closing it in order to monetize the volunteers’ work”.

TL;DR – the fact that OSI labels SSPL as “not open source” is nothing more than FUD by the major cloud providers, as the only meaningful difference between that and the GPL is section 13 that makes life harder for cloud providers.

I like to have some kind of slideshow as a desktop background wallpaper, and there are various ways of doing that – using your local picture library or multiple variations of remote image sources (everyone love NASA’s Astronomy Picture of the Day), and you can find a lot of discussions online about how best to go about automating setting the desktop’s background wallpaper image – in KDE Plasma it is particularly not that easy as you have to contend with multiple “activities”, with each has multiple screens, with each has multiple “desktop containments” – fortunately Plasma no longer supports different wallpapers for different virtual desktops – otherwise it would really have been a massive mess.

But sometimes I don’t want to change the wallpaper – just to figure out which one I’m looking it (maybe I want to delete it?). There isn’t any discussion about that on the internet, so I wrote this script and here it is for posterity (and also in this Github Gist):

I’ve ranted before about Client-Side Decorations (CSD), here and elsewhere, and here’s another one – mostly as a reminder to myself about how to disable CSD on Google Chrome web application windows.

The gist is – CSDs are horrible – they make your desktop look like a mishmash of different operating systems on the same screen, where it is often not clear how to interact with the application windows. The worst case is of course the MS-Windows XP RTL reflected UI, where you had some windows with normal operation buttons (close, maximize, etc) on the right side of the title bar and some windows were in “RTL” mode, so their buttons were on the left side 🤯.

Most people who have been involved in Linux development/administration/advocacy already know that Linux operating systems are in the middle of a big shift (or actually, almost at the end of it) in the graphics stack used in Linux desktops – from the old and gnarly X11 protocol to the new hotness: Wayland compositing. And it sucks.

This is a public response to Johan Thelin’s post “The API wars – 16 years later. His blog commenting system looks a bit broken and regardless – I think its an important enough discussion to publish here. The main premise of the article is that the web APIs have won the “API war” in the context of Joel’s Spolsky’s “How Microsoft lost the API war” article from 2014 but the main winner is the globally domineering Google and we should subvert their victory by moving to the new runtime – the WebAssembly, that is better in every way.

Here’s what I had to say about that:

This is a bit of a weird script day – the script is pretty simple but the integration is interesting. I’m scratching my own itch here and also demonstrating how to:

• Use dbus-monitor to listen to D-Bus events
• Use SystemD user services to run a session service
• Update KDE configuration safely from scripts

(more…)

Recently I had to move a lot of data between an old GSuite Business account and a new GSuite Business account. Google support for such a migration is… well… can stand to be improved. The main pain points are email¹, Drive², Team Drives³, Calendar⁴, and for everything else – there is no migration. Google+ posts, password storage, Sites, Forms have to be recreated manually, and my pet peeve: Google Groups Archives.

If you’re not familiar with this awesome GSuite feature, which is based on the Google Groups usenet-like service, Google Groups for Business is a mailing list manager that in addition to distributing emails to recipients, also stores each email in an accessible archive – so new users can have access to old communications (this is great for accounting and support) and on top of that you can get forum like features with posting replies to topics and such. Unfortunately Google Groups has no export feature and because the archive is all about past communications, you can’t actually reproduce that data manually when you move to a new GSuite account.

(more…)

1. The built-in data migration tool in the admin console – which is the only data migration tool available – only moves emails, and is not 100% reliable with that, and doesn’t move rules or other settings [↩]
2. There are external tools available, I’m using Multcloud, but sharing is a problem – the best you can get is to get a copy of each shared file and Google Docs without any sharing information attached, so that breaks the sharing. Other tools may convert all your Google Docs to Microsoft formats [↩]
3. Which surprisingly works very well – you just share the team drive to a user on the new domain and they can move all the files to a new team drive they create on the new account. Sharing information is lost and you have to reshare, but documents retain comments by the old users and there is no duplications [↩]
4. You can manually export all calendars to ical format and then manually import them one by one. Also not 100% [↩]

With version 8, Java finally jumped on the asynchronous programming bandwagon with its own Promise-Oriented programming model, implemented by the CompletableFuture class and a set of interfaces and implementations it uses. The model is generally useful and not as horribly complicated as we sometimes get in the Java foundation class library¹, and it lends itself to fluent programming much better than the comparable model from fluent API proponent Vert.x project.

The Problem

One thing that most asynchronous computing models suffer from – and Java’s CompletableFuture is no exception – is the loss of typed exception handling. While CompletableFuture.exceptionally() is a good model that does not introduce a lot of boilerplate², you do lose the ability of the try..catch..finally syntax to effortlessly ignore exceptions you are not ready to handle and just letting them propagate up the stack. (more…)

1. especially for things that claim to be “enterprise versions”, aughh [↩]
2. again, compare to Vert.x AsyncResult handlers. Other APIs, such as RX also do a good job in reducing boilerplate around error handling [↩]

In case you’re looking to host a Polymer application, S3 is a great and cheap option. The main problem is with no rewrite rules, you must use hash tag routing.

But with a simple configuration hack and a Cloudfront distribution you can use proper URLs for your S3 hosted polymer application – as detailed by Keita Kobayashi in his blog.