Google Chrome and Mozilla Firefox

• If you want an example of how user concerns do not drive software development, check out this Google-backed API

  A nascent web API called getInstalledRelatedApps offers a glimpse of why online privacy remains such an uncertain proposition. In development since 2015, Google has been experimenting with the API since the release of Chrome 59 in 2017. As its name suggests, it is designed to let web apps and sites determine whether a corresponding native app is installed on a user's device. The purpose of the API, as described in the proposed specification, sounds laudable. More and more, the docs state, users will have web apps and natives apps from the same source installed on the same device and as the apps' feature sets converge and overlap, it will become important to be able to distinguish between the two, so users don't receive two sets of notifications, for example.

• Mozilla Releases DeepSpeech 0.6 With Better Performance, Leaner Speech-To-Text Engine

  DeepSpeech 0.6 currently achieved a 7.5% word error rate for this open-source speech-to-text engine. The new release has various API changes, better training performance with TensorFlow 1.14 cuDNN RNN support for their training graph, trimmed down their language model to be using the top 500k words, adding various data augmentation techniques, a tool for bulk transcribing large audio files, and various other changes.

• [Older] Give Firefox a chance for a faster, calmer and distraction-free internet

  Using Firefox gives you peace of mind and keeps you away from the advertising companies constantly following you around, profiling you and tempting you to purchase their products.

Linux 5.5-rc1

• Linux 5.5-rc1

  We've had a normal merge window, and it's now early Sunday afternoon,
  and it's getting closed as has been the standard rule for a long while
  now.
  
  Everything looks fairly regular - it's a tiny bit larger (in commit
  counts) than the few last merge windows have been, but not bigger
  enough to really raise any eyebrows. And there's nothing particularly
  odd in there either that I can think of: just a bit over half of the
  patch is drivers, with the next big area being arch updates. Which is
  pretty much the rule for how things have been forever by now.
  
  Outside of that, the documentation and tooling (perf and selftests)
  updates stand out, but that's actually been a common pattern for a
  while now too, so it's not really surprising either. And the rest is
  all the usual core stuff - filesystems, core kernel, networking, etc.
  
  The pipe rework patches are a small drop in the ocean, but ended up
  being the most painful part of the merge for me personally. They
  clearly weren't quite ready, but it got fixed up and I didn't have to
  revert them. There may be other problems like that that I just didn't
  see and be involved in, and didn't strike me as painful as a result ;)
  
  We're missing some VFS updates, but I think we'll have Al on it for
  the next merge window. On the whole, considering that this was a big
  enough release anyway, I had no problem going "we can do that later".
  
  As usual, even the shortlog is much too large to post, and nobody
  would have the energy to read through it anyway. My mergelog below
  gives an overview of the top-level changes so that you can see the
  different subsystems that got development. But with 12,500+ non-merge
  commits, there's obviously a little bit of everything going on.
  
  Go out and test (and special thanks to people who already did, and
  started sending reports even during the merge window),
  
  Linus
  
  

• Linus Torvalds Kicks Off Development of Linux Kernel 5.5, First RC Is Out Now

  The two week-long merge window that opened with the release of the Linux 5.4 kernel series last month ended today with the launch of the first release candidate of Linux kernel 5.5, which was announced by Linus Torvalds himself. That's right, Linus Torvalds has officially kicked off the development cycle of the next major Linux kernel series, Linux 5.5, which is now available for public testing from the kernel.org website. Linux kernel 5.5-rc1 is the first milestone in many to come and gives the community a first look at the new features and changes. "We've had a normal merge window, and it's now early Sunday afternoon, and it's getting closed as has been the standard rule for a long while now," said Linus Torvalds. "Everything looks fairly regular - it's a tiny bit larger (in commit counts) than the few last merge windows have been, but not bigger enough to really raise any eyebrows. And there's nothing particularly odd in there either that I can think of: just a bit over half of the patch is drivers, with the next big area being Arch updates."

• Linux 5.5 Feature Overview - Raspberry Pi 4 To New Graphics Capabilities To KUnit

  Linux 5.5-rc1 is on the way to mirrors and with that the Linux 5.5 merge window is now over. Here is a look at the lengthy set of changes and new features for this next Linux kernel that will debut as stable in early 2020. Among the many changes to find with Linux 5.5 are support for the Raspberry Pi 4 / BCM2711, various performance changes still being explored, support for reporting NVMe drive temperatures, a new Logitech keyboard driver, AMD HDCP support for content protection, wake-on-voice support from Chromebooks, the introduction of KUnit for unit testing the kernel, new RAID1 modes that are quite exciting for Btrfs, and much more. Below is a more detailed look based upon our original monitoring and reporting.

• Unified sizeof_member() Re-Proposed For Linux 5.5

  After not being merged for Linux 5.4, the new sizeof_member() macro as a unified means of calculating the size of a member of a struct has been volleyed for Linux 5.5 for possible inclusion on this last day of the merge window. The Linux kernel to now has supported SIZEOF_FIELD, FIELD_SIZEOF, sizeof_field as means of calculating the size of a member of a C struct... The new sizeof_member looks to clean-up that code cruft that has accumulated over the years with converting all usage of the old macros over to this new unified macro.

The Linux Setup – Kezz Bracey, Web Designer/Developer

I found Kezz on Twitter and I’m so glad I did because this is a wonderful interview. First of all, I love the KDE details. Because while I don’t use KDE, I respect it. I wish I could tame it the way Kezz has. Instead, I tend to bow to its will, when really, if I knew how, like Kezz, I could bend it to mine. I also appreciate the screencasting information. I don’t do it very often anymore, but I do know that at some point, there were concerns about the lack of a good Linux screencasting program. Apparently that’s no longer an issue, which is great to hear.

Contributing to KDE is easier than you think – Porting websites to Markdown

This will be a new series of blog posts explaining different ways to contribute to KDE in an easy-to-digest manner. I plan for this series to be parallel to my keyboard shortcuts analysis so that there can be content being published (hopefully) every week. I was also feeling a bit bad about the fact that this blog is available over planet.kde.org (a feed for blog posts made by KDE contributors that also shows a bit of their personal lives and projects), but my other series was focusing more on other DEs, despite also being a project to improve KDE. The purpose of this series originated from how I feel about asking users to contribute back to KDE. I firmly believe that showing users how contributing is easier than they think is more effective than simply calling them out and directing them to the correct resources; especially if, like me, said user suffers from anxiety or does not believe they are up to the task, in spite of their desire to help back. It is true that I had the initiative to contact Nate Graham and Carl Schwan through Reddit, but it is also true that, had they not shown me how contributing back can be done in several small, feasible ways too, I would likely not have started contributing back. Out of respect and due to the current need for help with updating the KDE websites, my first post on this subject will document how to help Carl Schwan port older websites to Markdown, despite there being easier tasks than that. Currently, and as to my knowledge, Carl Schwan and Adrián Chaves Fernandez are the only two main KDE websites contributors, with help and mentorship from other KDE contributors such as Jonathan Riddell and, of course, the whole Promo team, who handles websites as well. This is quite the low number of contributors for such a huge amount of websites to be updated, you see; that’s why your help would be much appreciated!