Last Sunday I spent a few hours revisiting LISP-related languages, partly because I miss writing Clojure and partly because I wanted to do a relatively simple thing: issue a bunch of HTTPS requests, collate the resulting JSON data and then issue a final POST request. And I wanted to do it with an HTTP library that didn’t suck, in the smallest possible amount of space, and with a static binary. Two out of three wouldn’t be bad, right?

Well, nobody expects getting three out of three in real life, for sure, but as it turns out getting even two out of three is a sizable challenge in modern programming languages.

This particular rabbit hole came about partly because of my k3s and Azure API shenanigans and partly because I have a very similar problem I’ve been tackling with Python and requests, but which needs to run in a more restricted environment.

And it’s always surprising to consider that many people have no idea of what it takes to do an HTTPS request in this day and age–you’d expect that “fetch this URL and parse JSON output” would be the modern day equivalent of “Hello World” in any current programming language, and yet it is often a remarkably tortuous task…

The Usual Suspects

Most of my friends told me “why not just use NodeJS or Go?”.

Well, ignoring the static binary requirement for a moment, because NodeJS is still a complete mess. Just Google for nodejs http request and watch how many times this particular wheel has been reinvented (or better still, look at the change history for the built-in http library). If I had to do it in NodeJS, I’d use a wrapper like request for the sake of sanity and readability, at the expense of instantly sucking (pun intended) in a bunch of dependencies that really ought to be built-ins…

Don’t believe me? Look at the core https version, which requires an explicit data pump:

const https = require('https');

https.get('https://endpoint', (resp) => {
  let data = '';
  resp.on('data', (chunk) => { data += chunk; });
  resp.on('end', () => {
    console.log(JSON.parse(data));
  });
}).on("error", (err) => {
  console.error(err.message);
});

…and the request version, which is vastly more readable:

const request = require('request');

request('https://endpoint', function (error, response, body) {
  if(error) {
    console.error('error:', error);
  } else {
    console.log(JSON.parse(body));
  }  
});

…and I’m not even going to get into customizing request headers and cookie handling (which is where request really makes things easier for me), or how works the same way for buffers, streams, etc.

As to Go, for all its merits, simple things like this are comparatively harder and error-prone to write.

For instance, here’s part of what I’ve been working on (still largely untested, mind you) to port those 7-line Python requests I did against the Azure instance metadata APIs. And note how much more cumbersome the whole thing is when (for extra brownie points) you start parsing a nested JSON document using struct annotations for unmarshaling:

import (
    "encoding/json"
    "io/ioutil"
    "log"
    "net/http"
)

type InstanceMetadata struct {
    Compute struct {
        ResourceGroupName string `json:"resourceGroupName"`
        SubscriptionID    string `json:"subscriptionId"`
    } `json:"compute"`
}

func getInstanceMetadata() *InstanceMetadata {
    client := &http.Client{}

    req, err := http.NewRequest("GET", "http://169.254.169.254/metadata/instance", nil)
    if err != nil {
        log.Fatal(err)
    }
    req.Header.Add("Metadata", "true")

    q := req.URL.Query()
    q.Add("api-version", "2018-10-01")
    req.URL.RawQuery = q.Encode()

    resp, err := client.Do(req)
    if err != nil {
        log.Fatal(err);
    }

    defer resp.Body.Close()

    body, err := ioutil.ReadAll(resp.Body)
    if err != nil {
        log.Fatal(err);
    }

    metadata := InstanceMetadata{}
    err = json.Unmarshal(body, &metadata)
    if err != nil {
        log.Fatal(err)
    }

    return &metadata
}

And it’s about as crufty in Rust, which I find interesting but hard to justify against the sprawling Go ecosystem.

Looking for Options

So no, this isn’t the kind of developer experience I want for my own projects, even if it is one that has pretty much taken over the entirety of modern “systems” programming over the past few years.

For my hobby stuff, I’m looking for a more concise language (hence more likely to be dynamic/interpreted) that I can read and write without so much hassle, and that brings some fun into the process.

And I miss LISP (I am one of those people who actually enjoy it because it is an intellectual antidote for drudgery, even if I do love Python and Go).

So I decided to use that particular problem I had to solve as an excuse to check out the state of the art in that corner of the computing universe. I’ve been tracking a lot of Scheme implementations over the years including a few that compile down to C or native code, so it was time to see how useful they were.

All the tests below were run on Ubuntu 18.04.2, both in WSL and a standalone machine I used for testing standalone binaries (I also used a 16.04 machine on occasion), since it’s usually the target Linux I build for.

Fennel

Version: 0.2.1, installed via luarocks atop Ubuntu’s standard Lua 5.1

Fennel is not the first thing I tried, but it was the first one that nearly hit the spot. It is a LISP that compiles to Lua, and it does so in a quite elegant way, turning this:

(local http (require "ssl.https"))
(local ltn12 (require "ltn12"))
(local inspect (require "inspect"))

(fn request [url]
    (local resp {})
    (let [(res code headers)
          (http.request
            { "url" url
              "method" "GET"
              "sink" (ltn12.sink.table resp)
              "headers" {"User-Agent" "lua"} })]
      (print (inspect resp))))

(request "https://endpoint")

…into this:

local http = require("ssl.https")
local ltn12 = require("ltn12")
local inspect = require("inspect")
local function request(url)
  local resp = {}
  do
    local res, code, headers = http.request({headers = {["User-Agent"] = "lua"}, method = "GET", sink = ltn12.sink.table(resp), url = url})
    return print(inspect(resp))
  end
end
return request("https://endpoint")

The results are pretty decent considering that ltn12 is the kind of thing you can seldom avoid in Lua and that the resulting code is pretty much idiomatic if you ignore the lack of human-crafted whitespace.

The above does not do any JSON parsing, but there is also a requests rock for Lua, which brings in a few more dependencies (xml and cjson) and makes everything even more readable:

(local requests (require "requests"))
(local inspect (require "inspect"))

(let [res (requests.get "https://endpoint")]
   (print (inspect (res.json))))

…becomes:

local requests = require("requests")
local inspect = require("inspect")
do
  local res = requests.get("https://endpoint")
  return print(inspect(res.json()))
end

Fennel is a thing of concise beauty, and I can (theoretically) compile everything down to a ~1MB executable (which is the rough footprint of the Lua runtime plus dependencies) with tools like luapak.

But I could not manage to get luasec to play along, otherwise I would have likely stopped here.

It is very tempting, though, since using Lua would also make it possible for this to run on an ESP8266/ESP32, which would be perfect for another use I have in mind.

Chicken Scheme

Versions: 4.12 (shipping with Ubuntu), 5.1 (built from source)

My next stop was Chicken Scheme, an old acquaintance that compiles down to C and does everything I need rather elegantly–the simplest possible HTTPS and JSON decode call looks like this on Chicken 4:

(use http-client json)

(pp (with-input-from-request
    "https://endpoint"
    #f
    json-read))

The above compiles down to a dynamic executable that is only 35112 bytes and obviously depends upon a number of dynamically-linked libraries. But not just the ones it reports via ldd:

% ldd request
        linux-vdso.so.1 (0x00007fffc34bf000)
        libchicken.so.8 => /usr/lib/libchicken.so.8 (0x00007f0f8d830000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0f8d430000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f0f8d090000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f0f8ce80000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f0f8e600000)

What stood out to me was that this does not include openssl nor the extensions I had to install in order to get it to build:

export CHICKEN_REPOSITORY?=$(HOME)/.chicken

build:
    csc request.scm

deps:
    chicken-install \
            openssl \
            http-client \
            json

init-repo:
    chicken-install -i $(CHICKEN_REPOSITORY)

Running the executable with strace and filtering the output to capture all the openat calls reveals it dynamically loads around 17MB of libraries, so that would be its maximum footprint.

As to building a re-distributable binary, trying to build with -static and the openssl extension as a dependency didn’t work out in Chicken 4 (which is what I had handy), but I got a bit closer today with Chicken 5–I managed to get some libraries linked in, but not all of the extensions I was using.

Racket

Versions: 6.11 (bundled with Ubuntu), 7.3 (via this ppa)

As far as Schemes go, Racket is a very popular choice (and Ubuntu 18.04 ships with 6.x packages), so I had a quick stab at it:

#lang racket/base

(require net/url)
(require json)

(define (get-json url)
     (call/input-url (string->url url) get-pure-port read-json))

(print (get-json "https://endpoint"))

And, surprisingly, it was the only one that gave me a set of re-distributable files with nearly zero hassle.

The above builds down (using raco exe) to a 6MB file that still requires racket to run, and that can be packed (using raco distribute) into a roughly 10MB bundle:

dist
├── [4.0K]  bin
│   └── [6.0M]  request
└── [4.0K]  lib
    └── [4.0K]  plt
        ├── [3.9M]  racket3m-6.11
        └── [4.0K]  request
            ├── [4.0K]  collects
            └── [4.0K]  exts
                └── [4.0K]  ert
                    └── [4.0K]  r0
                        └── [1016]  dh4096.pem

More to the point, it just worked when I copied the files to a “blank” machine and ran the executable, and was the only solution so far that did so (in fact, both versions did, with marginal differences in final binary sizes).

Chez

Version: 9.5 (shipping with Ubuntu)

Next up was Chez Scheme, which is becoming the underpinnings of Racket 7.x releases, but where I drew an almost complete blank–because Chez, despite shipping with Ubuntu as well, currently lacks a comprehensive set of libraries (although thunderchez and scheme-lib have plenty of material to go through…).

Gerbil & Gambit

Versions: 4.9.3 (Gambit), 0.15.1 (Gerbil)

A few days later, I decided to take a look at Gerbil, which is a nice wrapper around Gambit Scheme that happens to oriented towards systems programming.

Gerbil wraps Gambit in much the same way Racket wraps Chez, but with a more pragmatic, low-level twist in its libraries.

As a result, my little sample program was quite straightforward to get going:

(import :std/net/request)
(import :std/text/json)

(export #t)

(def (main)
    (displayln
      (json-object->string
        (request-json
          (http-get "https://endpoint")))))

As to my requirement for binaries, building one with an explicit linkage to libssl and other system libraries was relatively easy:

% ldd request
        linux-vdso.so.1 (0x00007ffffbef7000)
        libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f10ecac0000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f10ec8b0000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f10ec510000)
        libssl.so.1.1 => /usr/lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007f10ec280000)
        libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f10ebdb0000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f10eb9b0000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f10ed600000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f10eb780000)

Building a fully static binary, however, wasn’t something I managed to do inside of a couple of hours, since it requires getting to grips with both Gambit and the wrappers Gerbil puts in place and I kept coming up against lack of documentation in that regard.

Conclusion

I’m going to be looking at Fennel and Chicken again in the near future, the former because it affords me the ability to target other architectures and the latter because I suspect I will be able to build a fully standalone (and insanely fast) executable with Chicken 5.x, and I like its portability.

In the meantime, nothing seems to beat Racket for “just working” on Intel architectures, and I will be setting up 7.3 for my little project. I recomend it if you want to get started quickly and want something that is very thoroughly documented.

But I’m going to dive into Gerbil afterwards, since it is likely to be more suitable for my needs in the long run–and I’ve already started building multi-architecture Docker containers for it so I can try it out.

A Minor Note Regarding VS Code

In other news, I recently switched from VSCodeVim to amVim because I found VSCodeVim hung the editor randomly.

But, more relevant to this post, I came across Calva while searching for a barebones paredit mode (which it ships as a separate extension).

I still prefer vim‘s paredit (it’s wired into my typing reflexes by now), but it is good enough to deserve a mention.

Never have I have been so sheepish as when I got in my “dinosaur-powered” VW Jetta, after tonight’s PEI Electric Vehicle Association meeting, and rumbled off. While everyone else was alighting their silent electric cars and smoothly gliding home.

I wasn't getting any work done today on my to-do list, so I decided to write some code.

One of my learning exercises to open the Summer of Joy is to solve the term frequency problem from Crista Lopes's Exercises in Programming Style. Joy is a little like Scheme: it has a lot of cool operations, especially higher-order operators, but it doesn't have much in the way of practical level tools for basic tasks like I/O. To compute term frequencies on an arbitrary file, I need to read the file onto Joy's stack.

I played around with Joy's low-level I/O operators for a while and built a new operator called readfile, which expects the pathname for an input file on top of the stack:

    DEFINE readfile ==
        (* 1 *)  [] swap "r" fopen
        (* 2 *)  [feof not] [fgets swap swonsd] while
        (* 3 *)  fclose.

The first line leaves an empty list and an input stream object on the stack. Line 2 reads lines from the file and conses them onto the list until it reaches EOF, leaving a list of lines under the input stream object on the stack. The last line closes the stream and pops it from the stack.

This may not seem like a big deal, but I was beaming when I got it working. First of all, this is my first while in Joy, which requires two quoted programs. Second, and more meaningful to me, the loop body not only works in terms of the dip idiom I mentioned in my previous post, it even uses the higher-order swonsd operator to implement the idiom. This must be how I felt the first time I mapped an anonymous lambda over a list in Scheme.

readfile leaves a list of lines on the stack. Unfortunately, the list is in reverse order: the last line of the file is the front of the list. Besides, given that Joy is a stack-based language, I think I'd like to have the lines on the stack itself. So I noodled around some more and implemented the operator pushlist:

    DEFINE pushlist ==
        (* 1 *)  [ null not ] [ uncons ] while
        (* 2 *)  pop.

Look at me... I get one loop working, so I write another. The loop on Line 1 iterates over a list, repeatedly taking (head . tail) and pushing head and tail onto the stack in that order. Line 2 pops the empty list after the loop terminates. The result is a stack with the lines from the file in order, first line on top:

    line-n ... line-3 line-2 line-1

Put readfile and pushlist together:

    DEFINE fileToStack == readfile pushlist.

I'll admit that I'm pleased with myself, but I suspect that this code can be improved. Joy has a lot of dandy higher-order operators. There is probably a better way to implement pushlist and maybe even readfile. I won't be surprised if there is a more idiomatic way to implement the two that makes the two operations plug together with less rework. And I may find that I don't want to leave bare lines of text on the stack after all and would prefer having a list of lines. Learning whether I can improve the code, and how, are tasks for another day.

My next job for solving the term frequency problem is to split the lines into individual words, canonicalize them, and filter out stop words. Right now, all I know is that I have two more functions in my toolbox, I learned a little Joy, and writing some code made my day better.

If you’ve checked the news or some social media platform in the past few days, maybe you’ve stumbled over a photo of sled dogs that walk on meltwater and a chart like this one from The Economist:

It’s a powerful chart. The red 2019 line drills itself out of the light blue area. This interdecile range and its really nice explanation (“80% of readings fall within this range”) seem to tell us: “Normally, you know, it stays down here”.

This chart evoked in me something that Hans Rosling calls “The Straight Line Instinct” in his book “Factfulness”. “OMG,” I thought. “So this red line will continue and will go where no line has gone before, and Greenland will be actually green in no time.”

I was curious if that is the case. So I charted the data myself:

Turns out, it’s not the case quite yet. Yes, it’s getting worse. Yes, the climate catastrophe will probably lead to Greenland being green at some point in the future, and it won’t be a good future.

But there isn’t this OMG moment that the chart by The Economist and other sources suggest. It’s not a completely new situation that so much ice has melted in Greenland. We’ve had similar alarming readings in 2002 and 2007. And we had readings of 1,400k sq. km being melted in July 2012; which is almost double of what was measured a few days ago.

“So it’s not that bad?”

I feel uncomfortable writing this article. My criticism of the Economist chart is that their chart nudges me to think that this year, the situation is worse than ever before. Which means that it nudges me to believe something that’s not true. And I’m all for the truth.

But I also want global warming to get more attention. I want people to feel like it’s bad, and that they need to do something. I want people to feel what I felt when I first looked at The Economist chart: “OMG.”

My redesign doesn’t achieve that. It doesn’t scare me. It makes me think: “Many dots, complex topic, well well.”

But our readers trust us writers. They trust us to communicate the truth so that they can form their own opinion; they trust us that we won’t nudge them. Even if the nudging has a short-term effect which is objectively positive – make more people care about global warming –, it might lead to distrust in the long-term. And to fewer readers who we could make care about these topics in the first place.

So I think we should find ways to achieve both: Communicating complexity & making people care. Some charts that achieve that are this one by Derek Watkins I’ve written about before, the “warning stripes” or the “climate spiral” by Ed Hawkins.

Edit June 21: Alex Selby-Boothroyd, Head of Data Journalism at The Economist, replied with a tweet in which he showed the print version of this chart – as powerful as the first one, but with more context. Thank you, Alex!

Getting the data proved to be not easy in this case. The data is published in a Highcharts chart on nsidc.org. My coworker Gregor wrote a short R script to get the data. You can find the script and the data for the chart above in this Github repo. Download it from there, or click on “Edit this chart” in the chart at the top – I’m curious to see what you’ll come up with. See you next week!

When I heard that ARM was to stop doing business with Huawei, I was a little bit puzzled as to how that worked: ARM is a British company owned by a Japanese conglomerate; how was the US able to extend its influence beyond its citizens and borders? A BBC report indicated that ARM had concerns over its US origin technologies. I discussed this topic with a friend of mine who works for a different non-US company that has also been asked to comply with the ban. He told me that apparently the US government has been sending cease and desist letters to some foreign companies that derive more than 25% of their revenue from US sources, threatening to hold their market access hostage in order to coerce them from doing business with Huawei.

Thus, America has been able to draw a ring around Huawei much larger than its immediate civilian influence; even international suppliers and non-citizens of the US are unable to do business with Huawei. I found the intent, scale, and level of aggression demonstrated by the US in acting against Huawei to be stunning: it’s no longer a skirmish or hard-ball diplomacy. We are in a trade war.

I was originally under the impression that the power to pull this off was a result of Trump’s Executive Order 13873 (EO13873), “Securing the Information and Communications Technology and Services Supply Chain”. I was wrong. Amazingly, this was nothing more than a simple administrative ruling by the Bureau of Industry and Security through powers granted via the “EAR” (Export Administration Regulation 15 CFR, subchapter C, parts 730-774), along with a sometimes surprisingly broad definition of what qualifies as export-controlled US technology. The administrative ruling cites Huawei’s indictment for willfully selling equipment to Iran as justification for commuting a broad technology export ban upon Huawei’s global operations.

Going Nuclear: Executive Order 13873
If a simple administrative ruling can inflict such widespread damage, what sorts of consequences does EO13873 hold? I decided to look up the text and read it.

EO13873 states there is a “national emergency” because “foreign adversaries” pose an “unusual and extraordinary threat to national security” because they are “increasingly creating and exploiting vulnerabilities in information and communications technology services”. Significantly, infocomm technology is broadly defined to include hardware and software, as well as on-line services.

It’s up to the whims of the administration to figure out who or what meets that criteria for a “foreign adversary”. While no entities have yet been designated as a foreign adversary, it is broadly expected that Huawei will be on that list.

According to the text of EO13873, being named a foreign adversary means one has engaged in a long-term pattern or serious instances of conduct significantly adverse to the national security of the US. In the case of Huawei, there has been remarkably little hard evidence of this. The published claims of backdoors or violations found in Huawei equipment are pretty run-of-the-mill; they could be just diagnostic or administrative tools that were mistakenly left into a production build. If this is the standard of evidence required to designate a foreign adversary, then most equipment vendors are guilty and at risk of being designated an adversary. For example, glaring flaws in Samsung SmartTVs enabled the CIA’s WeepingAngel malware to listen in on your conversations, yet Samsung is probably safe from this list.

If Huawei has truly engaged in a long-term pattern of conduct significantly adverse to national security, surely, some independent security research would have already found and published a paper on this. Given the level of fame and notoriety such a researcher would gain for finding the “smoking gun”, I can’t imagine the relative lack of high-profile disclosures is for a lack of effort or motivation. Hundreds of CVEs (Common Vulnerabilities and Exposures) have been filed against Huawei, yet none have been cited as national security threats. Meanwhile, even the NSA agrees that the Intel Management Engine is a threat, and has requested a special setting in Intel CPUs to disable it for their own secure computing platforms.

If Huawei were to be added to this list, it would set a significantly lower bar for evidence compared to the actions against similarly classified adversaries such as Iran or North Korea. Lowering the bar means other countries can justify taking equivalent action against the US or its allies with similarly scant evidence. This greatly amplifies the risk of this trade war spiraling even further out of control.

Supply Chains are an Effective but Indiscriminate Weapon
How big a deal is this compared to say, a military action where bombs are being dropped on real property? Here’s some comparisons I dug up to get a sense of scale for what’s going on. Huawei did $105 billion revenue in 2018 – 30% more than Intel, and comparable to the GDP of Ukraine – so Huawei is an economically significant target.

Above: Huawei 2018 revenue in comparison to other companies or country’s GDP.

Now, let’s compare this to the potential economic damage of a bomb being dropped on a factory: let’s say an oil refinery. One report indicated that the largest oil refinery explosion since 1974 caused around $1.8 billion in economic damage. So carving Huawei out of the global supply chain with an army of bureaucrats is better bang for the buck than sending in an actual army with guns, if the goal is to inflict economic damage.

Above: A section of “The 100 Largest Losses, 1974-2013: Large Property Damage Losses in the Hydrocarbon Industry, 23rd Edition”.

The problem is, unlike previous wars fought in distant territories, the splash damage of a trade war is not limited to a geographic region. The abrupt loss of Huawei as a customer will represent billions of dollars in losses for a large number of US component suppliers, resulting in collateral damage to US citizens and companies. Even though only a couple weeks have passed, I have first-hand awareness of one US-based supplier of components to Huawei who has gone from talks about acquisition/IPO to talks about bankruptcy and laying off hundreds of well-paid American staff; doubtless there will be more stories like this.

Reality Check: Supply Chains are Not Guided Missiles
The EAR was implemented 40 years ago, during the previous Cold War, as part of an effort to weaponize the US dollar. The US dollar’s power comes in part from the fact that most crude oil is traded for US dollars – countries like Saudi Arabia won’t accept any other currency in payment for its oil. Therefore sanctioned countries must acquire US dollars on the black market at highly unfavorable rates, resulting in a heavy economic toll on the sanctioned country. However, it’s worth taking a moment to note some very important differences between previous sanctions which used the US dollar as a weapon, and the notional use of the electronics supply chain as a weapon.

The most significant difference is that the US truly has an axiomatic monopoly on the supply of US dollars. Nobody can make a genuine US dollar, aside from the US – by definition. However, there is no such essential link between a geopolitical region and technology. Currently, US brands sell some of the best and most competitively priced technology, but also little of it is manufactured within the US. US may have one of the largest markets, but it does not own the supply chain.

It’s no secret that the US has outsourced most of its electronics supply chain overseas. From the fabrication of silicon chips, to the injection molding of plastic cases, to the assembly of smartphones, it happens overseas, with several essential links going through or influenced by China. Thus weaponizing the electronics supply chain is akin to fighting a war where bullets and breeches are sourced from your enemy. Victory is not inconceivable in such a situation, but it requires planning and precision to ensure that the first territory captured in the war hosts the factories that supply your base of power.

Using the global supply chain as a weapon is like launching a missile where your enemy controls the guidance systems: you can point it in the right direction, but where it goes after launch is out of your hands. Some of the first casualties of this trade war will be the American businesses that traded with Huawei. And if China chooses to reciprocate and limit US access to its supply chain, the US could take a hard hit.

Unintended Consequences: How Weaponized Trade Could Backfire And Weaken US Tech Leadership
One of the assumed outcomes of the trade war will be a dulling of China’s technical prowess, now that its access to the best and highest performing technology has been cut off. However, unlike oil or US dollars, US dominance in technology is not inherently linked to geographic territories. Instead, the reason why the US has maintained such a dominant position for such a long time is because of a free and unfettered global market for technology.

Technology is a constant question of “make vs. buy”: do we invest to build our own CPU, or just buy one from Intel or ARM? Large customers routinely consider the option of building their own royalty-free in-house solutions. In response to such threats, US-based providers lower their prices or improve their offerings, thus swinging the position of their customers from “make” to “buy”.

Thus, large players are rarely without options when their technology suppliers fail to cooperate. Huge companies routinely groom internal projects to create credible hedge positions that reduce market prices for acquiring various technologies. It just so happens the free market has been very effective at dissuading the likes of Huawei from investing the last hundred million dollars to bring those internal projects to market: the same market forces that drove the likes of the DEC Alpha and Sun Sparc CPUs to extinction have also kept Huawei’s CPU development ambitions at bay.

The erection of trade barriers disrupts the free market. Now, US companies will no longer feel the competitive pressure of Huawei, causing domestic prices to go up while reducing the urgency to innovate. In the meantime, Huawei will have no choice but to invest that last hundred million dollars to bring a solution to market. This in no way guarantees that Huawei’s ultimate solution will be better than anything the US has to offer, but one would be unwise to immediately dismiss the possibility of an outcome where Huawei, motivated by nationalism and financially backed by the Chinese government, might make a good hard swing at the fences and hit a home run.

The interest in investing in alternative technologies goes beyond Huawei. Before the trade war, hardly anyone in the Chinese government had heard about RISC-V, an open-source alternative to Intel and ARM CPUs. Now, my sources inform me it is a hot topic. While RISC-V lags behind ARM and Intel in terms of performance and maturity, one key thing it had been lacking is a major player to invest the money and manpower it takes to close the gap. The deep irony is that the US-based startup attempting to commercialize RISC-V – SiFive – will face strong headwinds trying to tap the sudden interest of Chinese partners like Huawei directly, given the politics of the situation.

Collateral Damage: Open Source
The trade war also begs a question about the fate of open source as a whole. For example, according to the 2017 Linux Foundation report, Huawei was a Platinum sponsor of the Linux Foundation – contributing $500,000 to the organization – and they were responsible for 1.5% of the code in the Linux kernel. This is more influence than Facebook, more than Texas Instruments, more than Broadcomm.

Because the administrative action so far against Huawei relies only upon export license restrictions, the Linux Foundation has been able to find shelter under a license exemption for open source software. However, should Huawei be designated as a “foreign adversary” under EO13873, it greatly expands the scope of the ban because it prohibits transactions with entities under the direction or influence of foreign adversaries. The executive order also broadly includes any information technology including hardware and software with no exemption for open source. In fact, it explicitly states that “…openness must be balanced by the need to protect our country against critical national security threats”. While the context of “open” in this case refers to an “investment climate”, I worry the text is broad enough to easily extend its reach into open source technologies.

There’s nothing in Github (or any other source-sharing platform) that prevents your code from being accessed by a foreign adversary and incorporated into their technological base, so there is an argument that open source developers are aiding and abetting an enemy by effectively sharing technology with them. Furthermore, in addition to considering requests to merge code from a technical standpoint, one has to also consider the possibility that the requester could be subject to the influence of Huawei, in which case accepting the merge may put you at risk of stiff penalties under the IEEPA (up to $250K for accidental violations; $1M and 20 years imprisonment for willful violations).

Hopefully there are bright and creative lawyers working on defenses to the potential issues raised by EO13873.

But I will say that ideologically, a core tenant of open source is non-discriminatory empowerment. When I was introduced to open source in the 90’s, the chief “bad guy” was Microsoft – people wanted to defend against “embrace, extend, extinguish” corporate practices, and by homesteading on the technological frontier with GNU/Linux we were ensuring that our livelihoods, independence, and security would never be beholden to a hostile corporate power.

Now, the world has changed. Our open source code may end up being labeled as enabling a “foreign adversary”. I never suspected that I could end up on the “wrong side” of politics by being a staunch advocate of open source, but here I am. My open source mission is to empower people to be technologically independent; to know that technology is not magic, so that nobody will ever be a slave to technology. This is true even if that means resisting my own government. The erosion of freedom starts with restricting access to “foreign adversaries”, and ends with the government arbitrarily picking politically convenient winners and losers to participate in the open source ecosystem.

Freedom means freedom, and I will stand to defend it.

Now that the US is carpet-bombing Huawei’s supply chain, I fear there is no turning back. The language already written into EO13873 sets the stage to threaten open source as a whole by drawing geopolitical and national security borders over otherwise non-discriminatory development efforts. While I still hold hope that the trade war could de-escalate, the proliferation and stockpiling of powerful anti-trade weapons like EO13873 is worrisome. Now is the time to raise awareness of the threat this poses to the open source world, so that we can prepare and come together to protect the freedoms we cherish the most.

I hope, in all earnestness, that open source shall not be a casualty of this trade war.

Rehashing something I posted to an internal forum because I haven’t posted here for what feels like aaagggeeessss….

I think our mode of delivery — narrative based courses presented primarily as written texts, interspersed with other forms of media, as well as dialog in the form self-test/supported open learning/tutor at your side SAQs and exercises — is an engaging and powerful one.

I personally think that a medium that supports embedded rich media and interactive activities provides many opportunities for us as educators to engage learners with more than just a static written text (although such activities may or may not actually make a positive impact on learning, and may affect it negatively, either directly, because the activities are not supportive of the learning, or because the material around the interactive is geared towards the activity creating an opportunity cost against using that material for other purposes).

Michel mentions platforms like Codio and (the new to me) Stepik, which in many ways are just an evolution of platforms that allow you to easily create and publish quite traditional e-learning (remember that?!) quizzes. It’s not too hard to roll your own course, either: https://course.spacy.io/ was a single person’s DIY effort, but it’s also produced a framework from which you can create your own course.

Something I’m noticing more and more are pages that embed read/write interactions as well as presenting the document as a whole via a personal read/write web style interface. You could argue these are just an iteration on a personal wiki, but I think calling them cell based, notebook style interfaces is more apposite. (OpenCreate was a cell based authoring environment, at least in the iteration I saw.)

The spacy course provides one example of inlining free text editable areas in a course. (The course also mixes linear text with slideshow expositions, which I thinks work nicely. It would be even more powerful if there were an area beneath the slide show where you could enter, and save, your own notes / commentary.)

Applications like Observeable provide you with in-browser documents editable at the cell level (click on the vertical ellipsis in the sidebar of a cell to make it editable). These interfaces also support code-based activities fully supported within the browser. (The spacy course executes code against a remote code environment; Observeable allows js code editing that is executed within the browser; Iodide is a similar, but more generic, framework from Mozilla; here’s a demo document; you can click the Explore button in the top right corner to edit, and preview, the source code. Another part of the same project,  Pyodide, brings a fully blown scientific Python stack into the browser using Webkit. Epiphany.pub is a very new (also solo) project demoing inline editing of docs that make use of Pyodide; click on a cell tool icon (in the toolbar at the right side of each cell) to edit the cell).

Something that I think these new read/write interfaces offer is the opportunity for students to take ownership of these documents and make marks on them, much as they might write comments or underlines on a print study guide. (Yes, I know about OU Annotate, but it’s not the nicest of experiences…)

Annotated documents can then be saved to personal file spaces. In the case of epiphany.pub, it wasn’t working yet when I tried yesterday (which is not to say that it might not have already been fixed today), but the model seems to be that you log in with something like Github and it saves the file there… This means that the site publisher: a) doesn’t really have to worry about managing user accounts, perhaps other than in a very simple, account secret token keeping, way; b) doesn’t “own” your document, it just hosts the editor; c) doesn’t have to pay for any storage for files edited using the editor. This pattern seems to be becoming more and more prevalent; you log in to a service with credentials and permissions that allow the service you are logging in to to store and retrieve stuff using the service whose credentials you logged in with. It’s becoming popular because me as a service provider can create a web app with minimal resource – not much more than hosting for a single page web app.

Just by the by, making annotations on top of documents is also becoming easier. eg the RISE slideshow in Jupyter notebooks, which lets you specify certain cells in a notebook to use as part of a presentation, also supports the ability to draw over a slide https://www.youtube.com/watch?v=Gx2TnIdt0hw&t=28m30s .  Things like Jupyter graffiti also go a bit further in terms of allowing you to create not-really screencasts that are actually replays over a live notebook with support for free annotation over the top (the replay element means the user can step into the “screencast” and take over control of the notebook themselves and go off in a different direction from the screenplay). At the moment Jupyter Graffiti is intended for instructors to make tutorials over the top of notebooks, but I wonder how elements of it might be tweaked or co-opted as an annotation tool for students…

One thing to note about the above is that the tech is starting to get there, but the understanding of how to use it, let alone a culture of using it, is still some way away.

Things like Noteable are fine, but they provide a base experience. An argument we keep having in TM351 is the extent to which we provide students with a vanilla notebook experience, or a rich environment built on Jupyter with loads of extensions and loads of exploitation of those extensions in the way we write the notebooks. Another way might be to find extensions that students can use to enrich their experience of our vanilla notebooks, but that requires skilling up the students so that they can make most effective use of the medium on their own terms.

You know those sped up videos where there’s a long line for something and someone walks the length of it? The New York Times did the scrolly equivalent for the recent Hong Kong protest, using snaps from aerial video and stringing them together geographically. A lot of people showed up.

Tags: Hong Kong, New York Times, photography, protest

This post is being written on, and about my settler user of, unceded Mi’kmaq land. I am grateful to live here under the Peace and Friendship Treaties. The garden’s coming along nicely. Parsley and genovese basil patches are finally perking back up, though we...

I’m curious Rosie what the import of your first paragraph is. I read the wikipedia entry on Mi’kmaq, and based on that I have a notion, also as it is 21 June, but curious about the specific components / references.

It is high school graduation day for Oliver, and we went up to the field house at the University of PEI this morning for a dry run of his walk across the stage. It was overcast when we entered; it was pouring torrential rain as we left, and so I learned that my shoes have holes, as they quickly filled up with water.

When I got back to the office an hour later the following conversation with the church sexton ensued:

Me: I learned today that my shoes have holes in them.

Him: I guess you’ll be making a trip to the store.

Me: They’re perfectly fine shoes, it’s just that the body has separated from the sole.

Him: There’s nothing worse than getting separated from your soul.

He is right.

August 2019: We’re not excepting applications for this position anymore. Thanks to everyone who applied!

Hi! We are Datawrapper, a company that makes it easy to create responsive, interactive and beautiful charts, maps & tables. Our tool already helps lots of people. We want it to be helpful to even more people – people who don’t know us yet.

To change that,

we’re hiring a marketer in Berlin (Prenzlauer Berg).

For a while now, we’ve had a successful blog and an relatively successful Twitter account. We send out newsletters and redesign our website from time to time. But we’re aware that we could do so much more.

Working closely together with our marketing lead Lisa, you will improve the marketing at Datawrapper by handling strategy and implementation. Our goal? We want to introduce our product to more people out there, and help them decide if Datawrapper is a good fit for them.

What you’ll be doing:

We will analyze what we could improve, think about how we can improve, and then improve our marketing. And then we’ll start all over again. We’ll try things out and sometimes fail, make evidence-based decisions and learn a ton on the way.

• Analyze what we could improve. We’ll crunch some numbers: How are we reaching people so far? What works, what doesn’t? If we try something out, does it have an effect? What should we measure? How? We’ll do A/B testing, user interviews, some SQL-ing and use external platforms to find out.
• Think strategically how we can improve. We’ll brainstorm in a structured way and come up with ways to reach, help & delight different people.
• Improve: Reach, help & delight more people. We’ll try to quickly reach more potential users of our app, for whom it would be most helpful. This might include articles, SEM, events, emails, tweets, ads, videos, etc. Together, we’ll organize and keep an overview of these different channels.

Who we’re looking for:

• You have an intrinsic curiosity about marketing in general and get some thrill out of improving metrics. To answer the question “how”, you learn, experiment and iterate.
• You have great writing skills – in English. Writing in English is what Lisa and you will do a lot of the time; be it on our blog, on LinkedIn or Twitter or on our landing page. Bonus points if you’re a native speaker.
• You’re working from our office in Berlin. Due to the collaborative nature of this job, it will not be possible to do this job remotely. Please save yourself and us some time and only apply if you want to work with us in Berlin.
• Not a must-have, but a plus: German skills, interest in or experience with data visualization and experience of working in a software company.
• We’re curious what other skills & talents you have. Are you a video pro? Or an amateur coder? Did you study graphic design back in the days? Do your friends say you’re a social animal? Let us know. We’d love to use all of your strengths.

What we can offer:

• A big desk in our office in Berlin Prenzlauer Berg, where eleven of us work (David, Gregor, Ivan, Anna, Daniela, Hans, Simon, Fabian, Nika, Elana and Lisa). We have a library of data vis books, a coffee machine, snacks, tea en masse & interesting conversations about mapping, data vis and UX. Also, we honor lunch breaks. It’s cool in the summer and we hear birds chirp instead of cars roar. That’s where we sit:
• Impact of your work. We’re a small team building a product that has a huge impact on how charts & maps look like in print and web all over the world. We’re growing – and not planning to stop. Together with Lisa, you’ll decide how people get to know our increasingly important company; how we communicate with them, how they remember us.
• Impact within Datawrapper. We’re all learning, and we’re open to ideas. You can help shape our team by teaching us methods and approaches.
• Flexible working hours. We’re looking for someone who wants to work for us at least three days a week. There’s no 9-to-5 culture in our office, though. Some people come at 11 am, some come early and leave at 4 pm, others like to work from home from time to time.
• A question-happy, communication-happy atmosphere. We’re all learning, and we want you to learn with us. If someone has an idea or a problem, we just talk. We have feedback sessions, tiny talks in which we teach each other and an education budget for you.
• Oh, and you’ll get money for doing this job.

We want you to apply especially if you’re from a group that’s underrepresented in our office. (That includes women, still, but we’re working on it!) Also: We don’t care about CVs, just skills and attitude. If you don’t find yourself 100% in the description, write Lisa an email anyway.

How to introduce yourself to us

To hire the best possible person, we decided to give you three small tasks:

1. Find three things you’d like to improve on our website and explain them in 280 characters each, max.
2. Choose one tweet from our Twitter account and re-write it.
3. Write about at least one thing you’d like to learn and explain why. Keep it short.

Please understand that we don’t have the time to answer emails that don’t at least mention these tasks. Besides your answers, talk a bit about yourself and how your skills & experience could be a good fit for this job, and ask us aaaaall the questions you might have:

→ Write to lisa@datawrapper.de

We’re looking forward to hearing from you!
Lisa & the Datawrapper team

Sebastiaan Andeweg

Recently, the call for private posts became louder again. Aaron Parecki is trying to get a group of people together to exchange private posts between Readers. I would like to be one of them...

Private posts is something I’d like to have too. In WP it is possible, by having posts you need a login for. Finding a way to smooth that, which doesn’t require me to have other people having an account here, would be great. Automating IndieAuth access looks like a viable path.

However, private posts is just a first step in my mind. On my wish list is a deeper form of allowing selective publishing: private elements in otherwise public postings. Where one site visitor might read ‘my daughter’, friend might read her name. Where other read ‘a client’, colleagues would read the organisation’s name. Building a smooth spectrum from fully public to fully private. Along the lines of how we in conversations also continuously switch between different degrees of disclosure, and not just between conversations.

I can't really do better than to simply link to Tony Hirst's latest newsletter on Jupyter Notebook. I can't summarize it except to say that there is a lot of current information - MyBinder as a federated service, and epiphany.pub (billed as "Jupyter mixed with Medium"), and much much more. You can subscribe to the email newsletter or follow it on Twitter.

No – but really – we’re going to need to stop sucking…

Created alongside activists from the Rethink Plastic Alliance, whilst focusing on World Ocean Day, using the Visual Thinkery – 10 ideas process.

The post Stop Sucking appeared first on Visual Thinkery.

A Whole New Way to Fold a Bike: Tern Launches the Ultra-Compact BYB Folding Bicycle. This innovative new folding bike will arrive in bike stores in July. Read more and take a look at this good-looking folding bicycle in our post.

The post A Whole New Way to Fold a Bike: Tern Launches the Ultra-Compact BYB Folding Bicycle appeared first on Average Joe Cyclist.

Required: Windows 10 version 18362.0 or higher. This is the current release.

More >

Writing novels is hard, and requires vast, unbroken slabs of time. Four quiet hours is a resource that I can put to good use. Two slabs of time, each two hours long, might add up to the same four hours, but are not nearly as productive as an unbroken four.

Neil Stephenson on Why I’m a Bad Correspondent

It looks like Google wasn’t satisfied with the Pixel Slate since it isn’t going to make any more ChromeOS tablets in the near future.

Google was working on two smaller tablets, according to Computerworld, but now the company has scrapped those plans and decided to work on laptops.

A Google spokesperson confirmed these details to Computerworld. 

When MobileSyrup reviewed the Pixel Slate, we thought it was a solid device with a few issues. It’s sad that Google is killing it off since it felt like a product that, with a few more iterations, might have been something really cool.

The silver lining is that we now know Google is working on a new laptop, and since the Pixelbook was so well reviewed, we’re excited to see what Google makes next.

Source: Computerworld

The post Google says it’s done making tablets, will focus on laptops appeared first on MobileSyrup.

While hardly as glamorous as Google leaking its own phone, or as exciting as spotting what could be the Pixel 4 in the wild, case render leaks are a consistently reliable way to get details about upcoming devices.

This time around, a Pixel 4 case render posted on SlashLeaks gives us an even better glimpse of the phone than what we’ve seen before.

The render shows us the back of the Pixel 4 when it’s in a clear silicon case. Despite the low resolution of the image, you can clearly make out two cameras in the large square module, along with a flash and another sensor of some kind.

Also, the image includes a look at the left and right sides of the device outside of the case. You can see the power and volume buttons on the right edge of the phone. Further, the camera bump looks quite large.

Some comparisons have already been made between the upcoming Pixel 4 and the rumoured iPhone XI design, both of which feature a large, square camera module on the rear of the device.

One thing this render doesn’t show off is the display. Aside from a few renders, there’s been no sighting of the Pixel 4’s screen yet. We have, however, learned the screen’s possible dimensions. We may learn more closer to the phone’s launch in October.

Source: SlashLeaks

The post Pixel 4 case render shows off massive camera bump appeared first on MobileSyrup.

After pushing the June 2019 security patch to the Galaxy S9 and Note 9, Samsung is starting to roll out the update to the Galaxy S10 family — except the S10+ 5G — as well as the nearly two-year-old Galaxy Note 8.

Several Galaxy S10 users in Hong Kong first spotted the update, signalling that an imminent wider rollout was on the way, according to 9to5Google.

The June security update only contains minor tweaks and the usual security improvements. SamMobile says the new software patched at least a dozen Android OS vulnerabilities and 11 Samsung Vulnerabilities and Exposures or SVE items.

Regarding the Galaxy Note 8, the update brings the June patch but not the dedicated camera Night Mode that came to the S9 phones back in April.

Since the rollout comes in phases, S10 and Note 8 owners in Canada should exercise patience.

Source: 9to5Google

The post June security patch starts rolling out to Samsung Galaxy S10 line, Note 8 appeared first on MobileSyrup.

Samsung’s Galaxy Note 10 isn’t a handset that people usually connect with car branding. Huawei and Oppo have partnered with individual automakers, but Samsung seems to work differently than the China-based smartphone companies.

However, a recent rumour has suggested otherwise.

A leaked image has appeared on Chinese social media website Weibo showing a promotional image of the Note 10 Tesla Edition with a brushed metal back, red accents and the ‘T’ Tesla logo.

It turns out, the image was created by well-known U.K. tech YouTuber ‘MrWhoseTheBoss’ who is known for creating renders of devices. The YouTuber tweeted at Elon Musk, the founder of Tesla, a photoshopped Galaxy Note 10 rendering with the Tesla aesthetic and branding.

If @Tesla and @SamsungMobile had a baby…

What do you think @elonmusk ? pic.twitter.com/XxbytxLymp

— Arun Maini (@Mrwhosetheboss) June 12, 2019

While ‘Mrwhosetheboss’ didn’t say that the phone was a fake, it was quite obviously a rendering.

However, someone from China saw the tweet and irresponsibly posted it onto the Weibo microblogging site, leading to a game of broken telephone.

Don’t get me wrong; in the future, Samsung might work with Tesla, similar to how Oppo works with Lamborgini. However, this isn’t the case here.

At this moment, we aren’t sure of the design of the Note 10. And we won’t know about any brand deals unless they get leaked, or until after Samsung officially launches the Note 10

Previously Samsung made a brand deal with Olympics and created the PyeongChang  Olympic-themed Note 8.

A couple of years ago a leak circulated about the ‘Ultra Pixel‘ that was also completely fake.

With all the leaks circulating, it’s always good to take everything with a grain of salt. Three rumours have suggested that Samsung will launch the Galaxy Note 10 on August 7th, August 8th or August 10th. One rumour suggests that Samsung would launch the Galaxy Note 10 without physical buttons, while another says otherwise.

It’s so hard to trust rumours and leaks, so it is always good to wait for Samsung to make the official announcement, or when a manufacturer, officially leaks its device — looking at you Google.

Source: Twitter

The post Say hello to the Ultra Pixel of Note 10 rumours appeared first on MobileSyrup.

Netflix is currently testing a picture-in-picture ‘pop-out player’ on desktop.

With the pop-out player, users can continue to watch Netflix content in a small tab while carrying out other activities on their computers.

Engadget, which first reported on the pop-out player, says the feature can be accessed by clicking a small icon at the bottom of the screen. The new pop-up window can then be resized and position as desired. The pop-out player doesn’t support subtitles at this time.

Engadget notes that it’s only appeared to one of its senior editors so far. Meanwhile, some Twitter users discovered it earlier this month.

PSA!!!!! NETFLIX FINALLY HAS A POP-OUT MEDIA PLAYER!!!!!!!! pic.twitter.com/87wMYyoNic

— Jerard (@TomAndJerard) June 8, 2019

For what it’s worth, I couldn’t get the feature to appear in Chrome on my MacBook, either, so your mileage may vary.

When reached out to for comment by Engadget, Netflix simply sent a ‘This is a test‘ image. Therefore, it’s unclear if the pop-out player will ever roll out officially to all users.

Via: Engadget

The post Netflix is testing a picture-in-picture feature on desktop appeared first on MobileSyrup.

Google’s Chrome browser may be the culprit behind Final Cut Pro X’s annoying performance issues, according to Felipe Baez, creative director and founder of Cre8ive Beast.

In a tweet dated to June 20th, Baez claims that Chrome is “locking down the VideoToolBox framework,” causing FCPX to slow down and even crash. Even though his Mac workstation has 64GB of RAM, Baez said that shutting down Chrome before using the Apple editing suite solved the problem.

If you use FCPX, don't use Chrome. Well, if you use any editing app, don't use Chrome. Just discovered Chrome locking down the VideoToolBox framework and making FCPX REALLY slow and crashing.

— Felipe Baez (@baezfelipe) June 20, 2019

VideoToolBox, which may sound like a finicky YouTube video converter, is actually a low-level Apple framework that allows compatible video editing suites and transcoders to leverage the fastest (hardware-based) video encoders and decoders available on a Mac.

If Baez’s claims are accurate, Chrome has a tendency to seize control of the VideoToolBox, forcing FCPX to fall back on slower software-based encoders and decoders that rely on a Mac’s CPU. He also pointed out his CPU usage went above 300 percent, which adds to the plausibility that Chrome is causing trouble.

Appleinsider tried to recreate the issue using Chrome and Handbrake, a hardware-demanding video transcoder and found a 30 percent degradation in encoding speed when the Google browser is on. The publisher is looking further into the situation.

Source: Felipe Baez

The post Google Chrome may slow down and crash Apple Final Cut Pro X appeared first on MobileSyrup.

Google Chrome unveiled a new extension that will allow users to report sketchy or suspicious websites.

The Google-developed extension is called the ‘Suspicious Site Reporter,’ and is currently available as a free download in the Chrome Web Store.

Users, for example, can report a website if it’s asking for your personal information or is attempting to download something on your computer without permission. Users will be able to flag any website they find suspicious.

The extension appears in your browser as an orange flag. The flag will change colours if it believes that a website is suspicious. It will also give you information about why it thinks the website is suspicious.

Once you file a report, it is sent to Google Safe Browsing, which is Google’s database of dangerous websites.

Source: Google 

The post Google Chrome unveils ‘Suspicious Site Reporter’ extension appeared first on MobileSyrup.

With the impending shutdown of Google Hangouts next year, we’re going to lose another beloved tool in ‘Hangouts on Air.’

The feature allowed people to easily create content like podcasts by starting a Hangouts call and clicking a button to start streaming it. However, the replacements for Hangouts — Hangouts Chat and Meet — won’t offer the same functionality. Plus, Google is pushing Chat and Meet for business and recommends consumers use Android Messages and Duo.

YouTube also doesn’t offer a replacement for the feature. YouTube’s ‘Webcam’ feature only lets one person go live and not a whole group.

Some podcast groups have switched to using Open Broadcaster Software (OBS) instead, but it’s odd that neither YouTube nor Google seem interested in offering a replacement for Hangouts on Air, which is slated to shutdown later in 2019.

The feature originated as part of Google+ — which also bit the dust recently — and later migrated to YouTube.

Source: Google Support Via: Android Police

The post Hangouts on Air to shutdown later this year, no replacement for podcasters appeared first on MobileSyrup.

Google has fixed a bug related to Chrome’s recent searches Autocomplete feature.

Last month, Chrome users began reporting an issue where the browser’s address bar would autofill with recent search queries instead of the most visited search terms from the browser history.

For example, beginning to type the ‘Y’ in ‘YouTube’ would instead bring up your most recent search that began with a ‘Y,’ even if you regularly visit YouTube.

Now, an employee in the Chromium bug thread has confirmed the issue has been resolved. To enable the fix, the employee says you should restart your Chrome browser.

Source: Chromium Via: TechDows

The post Google has fixed Chrome address bar recent searches Autocomplete bug appeared first on MobileSyrup.

The Atlantic: Trump’s Sinister Assault on Truth. “The president appears committed to destroying the very idea of facts.” By Peter Wehner, contributing editor at The Atlantic and senior fellow at EPPC.

“Trump is not simply a serial liar; he is attempting to murder the very idea of truth, which is even worse. “The point of modern propaganda isn’t only to misinform or push an agenda,” according to the Russian dissident and former world chess champion Garry Kasparov. “It is to exhaust your critical thinking, to annihilate truth.”
[…]
Destroy the foundation of factual truth, and lies will be normalized. This is what the Czech dissident (and later president) Václav Havel described in the late 1970s when he wrote about his fellow citizens making their own inner peace with a regime built on hypocrisy and falsehoods. They were “living within the lie.” In such a situation life becomes farcical, demoralizing, a theater of the absurd. It is soul-destroying.

The United States is still quite a long way from the situation Havel found himself in. But to keep it that way—to keep civic vandalism from spreading—we all have a role to play, including calling out lies, including the lies of Trump, in every way we can.

The most obvious thing Americans can do is to vote for men and women who prize integrity and are, in the main, truth-tellers. It doesn’t seem too much to ask that we not vote for those who are chronically dishonest and corrupt. Americans can also end their financial support for parties that are aiding and abetting compulsive liars.“

(Emphasis mine.)

Link via MetaFilter.