Android Leftovers

• For Android Users, Europe's Google Ruling Leaves Unanswered Questions

• Mobile apps: America's favorite fast-food apps for Android: A Foolish Take

• Android Circuit: New Galaxy S10 Leaks, Expensive Note 9 Revealed, Google's Massive Pixel 2 Mistake

• How To Promote Your Android App Continuously

• Google Fuchsia OS development hits overdrive, could replace Android in 5 years

Jonathan Dieter: Small file performance on distributed filesystems - Round 2

Last year, I ran some benchmarks on the GlusterFS, CephFS and LizardFS distributed filesystems, with some interesting results. I had a request to redo the test after a LizardFS RC was released with a FUSE3 client, since it is supposed to give better small file performance. I did have a request last time to include RozoFS, but, after a brief glance at the documentation, it looks like it requires a minimum of four servers, and I only had three available. I also looked at OrangeFS (originally PVFS2), but it doesn’t seem to provide replication, and, in preliminary testing, it was over ten times slower than the alternatives. NFS was tested and its results are included as a baseline. I once again used compilebench, which was designed to emulate real-life disk usage by creating a kernel tree, reading all the files in the tree, simulating a compile of the tree, running make clean, and finally deleting the tree. The test was much the same as last time, but with one important difference. Last time, the clients were running on the same machines that were running the servers. LizardFS benefited hugely from this as it has a “prefer local chunkserver” feature that will skip the network completely if there’s a copy on the local server. This time around, the clients were run on completely separate machines from the servers, which removed that advantage for LizardFS, but which I believe is a better reflection on how distributed filesystems are generally used. I would like to quickly note that there was very little speed difference between LizardFS’s FUSE2 and FUSE3 clients. The numbers included are from the FUSE3 client, but they only differed by a few percentage points from the FUSE2 client.

GNOME 3.30 Desktop Environment to Enter Beta on August 1, GNOME 3.29.4 Is Out

With a two-day delay, the GNOME Project through Javier Jardón announced today the release of the fourth and last development snapshot of the GNOME 3.30 desktop environment before it enters beta testing next month, GNOME 3.29.4, which continues to add improvements to various of GNOME's core components and applications. However, due to the summer vacation and the GUADEC conference, GNOME 3.29.4 isn't a major snapshot as many would have expected. It only adds some minor changes and bug fixes to a handful of components, including GNOME Shell, Mutter, Evolution, GNOME Photos, GNOME Builder, GNOME Online Accounts, Polari, Bijiben, Evince, Epiphany, Baobab, GNOME Control Center, and File Roller. Also: GNOME 3.29.4 Released As Another Step Towards GNOME 3.30

Google’s iron grip on Android: Controlling open source by any means necessary

Today, things are a little different. Android went from zero percent of the smartphone market to owning nearly 80 percent of it. Android has arguably won the smartphone wars, but "Android winning" and "Google winning" are not necessarily the same thing. Since Android is open source, it doesn't really "belong" to Google. Anyone is free to take it, clone the source, and create their own fork or alternate version. As we've seen with the struggles of Windows Phone and Blackberry 10, app selection is everything in the mobile market, and Android's massive install base means it has a ton of apps. If a company forks Android, the OS will already be compatible with millions of apps; a company just needs to build its own app store and get everything uploaded. In theory, you'd have a non-Google OS with a ton of apps, virtually overnight. If a company other than Google can come up with a way to make Android better than it is now, it would be able to build a serious competitor and possibly threaten Google's smartphone dominance. This is the biggest danger to Google's current position: a successful, alternative Android distribution.