Tangentially related lecture: The hard parts of open source.

Collaborative engineering has more problems in collaboration than engineering. Those 'soft' skillsets do not correlate well with technical expertise, especially when filtered through asynchronous (and often pseudonymous) text-based communication. Additionally, some foundational assumptions about the nature of improving technology and society turn out to not work so good.

The patterns of behavior that people fall into because of software are rarely positive for themselves or others. Use and development both invite what Skinner would call superstitions: spurious connections between actions and outcomes. […]This extends to human interactions about software. People can be driven to sociopathy, apathy, obsessive placation, or anything in between, thanks to the sparse, arbitrary, and frankly batshit crazy stimuli they're subjected to.

We're not dutifully working around harmful narcissists out of conscious tolerance or demographic over-representation. They just blend in with all the other assholes we've become.

Reddit user "mindbleach" on Why I'm not collaborating with Kenneth Reitz.

I inherited a simple Telegram bot from someone. The ease of programming these small things really makes programming fun again.

You don't need any more than plain python and the requests module to run it.

The SonyDevWorld bot

• trawls the Latest updates and Open source archives pages from developer.sony.com
• and posts found items
• to the SMDW_downloads Telegram channel.

While working on the bot, I familiarized myself once again with deploying small isolated services with systemd and it's --user features. Pretty neat.

I also wrote a small ansible role to deploy the bot onto a server.

I've recently reworked a whole lot of my pages to work with prefers-color-scheme. Not nearly as much work as I'd thought, lots of fun and the results look stunning.

See Dark Mode rework for details.

Doesn't it still miss the major sticking point; Google Play Services? That's not a problem for Huawei in their native China, where Google barely have a presence, but every western market consists of Android users who already have access to Google Play Services, and already have phones loaded with applications that take advantage of it.

Not having access to Google Play Services has historically crippled anyone who's tried to launch an alternative OS that could otherwise run Android apps.

Blackberry BB10 could run Android apps. Despite being a recognised and trusted name, Blackberry got nowhere with it.

Amazon launched the Fire phone, which was based on AOSP, ran Android apps, and even had it's own preexisting app store loaded with Android apps. In the end, Amazon couldn't give those phones away.

Samsung have Tizen; the in-house OS from the world's largest Android OEM. It too runs Android apps. Tizen's mobile market share is below 1%.

It's the Google Play Services that matter; not just the Android branding or access to Android apps.

Without Google Play Services, every developer whose app relies on location services will have to redevelop their app for whatever alternative location service Huawei provide.

Without Google Play Services, every developer will need to redevelop their app for whatever payment process Huawei provide for buying apps and making IAP's.

Without Google Play Services, any developer whose app relies on SafetyNet validation (nearly every banking app, many DRM related media apps) will need to redevelop their application for whatever alternative Huawei provides. It took years for banks to get onboard with things like mobile payments with Android; will they be any quicker with Huawei?

Without Google, any apps that rely on Firebase (Google estimates there are over a million devs using Firebase), will need to be redeveloped to work with whatever alternative Huawei can provide.

Without Google Play Services, any apps that run as app bundles will need to be redeveloped to run on Huawei devices.

What's the incentive for app developers to do any of the above, when they already have their hands full supporting hundreds of devices and billions of users in an established market?

Furthermore, without Google Play Services, any Android user moving to a Huawei device will lose the ability to backup and restore to their new Huawei device, making Huawei phones uniquely hard to migrate to.

None of the Huawei devices running their own OS will be able to Cast, or access Google Assistant. And, regardless of what OS Huawei use, none of them can be sold in the US.

Not to mention, any existing Android users who move to Huawei's in-house OS will need to repurchase the Android apps they already own, and the executive order blocking Google from engaging with Huawei applies to other US companies too; so in addition to Google's apps being unavailable, Huawei's app store won't include any apps by Microsoft, Amazon, Facebook, Twitter, eBay, PayPal, Amex, etc.

Given the big names who have tried and failed without some of the disadvantages Huawei now face, and in light of the above challenges, how likely is Huawei to succeed here?

Commenter Jimk4003 on Huawai's plans to forge its own path without Google's Play Services

Simplicity and elegance are unpopular because they require hard work and discipline to achieve and education to be appreciated.

Edsger W. Dijkstra

Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it.

Alan Perlis

MusicBrainz

There’s a plugin for MusicBrainz Picard that works with tango.info, which has previously been discussed. Support for tango releases on MusicBrainz is notoriously spotty, since its focus lies mainly on English-language music released by major record labels in the Anglosphere. Hence, relying on MB tag data is not a viable option for mass tagging.

Tango-dj.at

‘El Tango - Pasion y Emoción’ is a good example. The tango.info listing makes a few critical mistakes, so another source is needed. Probably the most complete and accurate information is provided by tango-dj.at.

This script that takes any tango-dj.at URL as input and spits out formatted text that can be pasted into puddletag or MP3Tag:
scrape-tango-dj-at.py

The pattern, which of course can be modified: %title%~%artist%~%album%~%genre%~%year%~%composer%~%lyricist%~%vocal%
Best to use only a single album at a time.

Tango.info

Before writing the plugin for Picard, I had been using a hacked-together snippet of code for scraping tango.info. It is available here: tinfo.py.

Since there wasn't a working one, I wrote a small plugin for picard that automatically fetches album and track information from tango.info.

Just put it into your plugin directory, and if your tracks have barcode tags, it will do all the magic for you. It currently sets genre, date and vocal(singer/s) metadata, but it can be easily adapted for other fields.

The code is here, including usage instructions.

Update: The plugin has been merged into picard-plugins, which means you should be able to download it directly from the picard website. It should be included in the next release of picard, which will be version 1.4.0.