[Flameeyes] has heard complaints (and at times, he admits, has complained himself) about big companies not contributing improvements to projects they seem to find useful, or rolling their own implementation rather than use and contribute to an existing code base. Having recently left Google after seven years, he has some insights into some of the reasons big corporations (at least Google, anyway) may sometimes seem to eschew making code contributions, and some of the reasons might come as a surprise.
The biggest issue is the software license. Without one, there is no legal structure to use, distribute, or contribute to the code, and no corporate entity will want to touch it. Google specifically forbids creating patches for projects with either no license, or incompatible licenses. An example of an incompatible license is one that forbids commercial use, because everything a corporation like Google does — even research –is considered a commercial endeavor. In addition, on the corporate side making contributions might trigger a code review process of some kind for some licenses, but not for others. [Flameeyes] suggests the MIT license as one that is acceptable to pretty much everyone with a minimum of fuss. Another caution: if a project’s code resides in an online repository, make sure the repository is licensed as well.
A few other small suggestions (such as maintaining an AUTHORS file to track contributors in a tidy way) rounds out the advice. It sounds simple, but software licensing is so critical to the whole affair that it’s important to get it right — he suggests the REUSE tool for anyone wanting to make sure a project’s licensing is tidy.
[Flameeyes] makes a point that none of this guidance is based on secret or institutional knowledge. Google has a public document detailing exactly how they use and deal with open source, and it’s a solid guide for how to make your project more accepting of contributions from a corporate entity like Google. (Or, if you prefer, a guide on how to set up as many barriers as possible for your project.)
In case you missed it, we just want to remind you that our favorite recent open source project from Google is definitely Pigweed.
About a year ago, Zachary McCoy took a bike ride around his neighborhood in Gainesville, Florida. It may have been forgettable to him, but not to history. Because McCoy used an app to track his mileage, the route was forever etched in the Google-verse and attached to his name.
On the day of this ill-fated bike ride, McCoy passed a certain neighbor’s house three times. While this normally wouldn’t raise alarm, the neighbor happened to be the victim of a burglary that day, and had thousands of dollars worth of jewelry stolen. The Gainesville police had zero leads after a four-day investigation, so they went to the county to get a geofence warrant. Thanks to all the location data McCoy had willingly generated, he became the prime suspect.
Setting up an environment for Embedded Development was traditionally a pain and so vendors provide integrated development environments to help bridge the gap. Google has open-sourced their version of an embedded targeted environment designated as embedded-targeted libraries which they trademarked Pigweed.
The repository contains what Google is calling modules but taking a better look reveals that it a little more than that. Packaged in a Python Virtual Environment is a number of tools including an ARM compiler, the clang-format tool and Python 3.8 interpreter which runs more than a few things. The modules that come with Pigweed assist developers by running micro-automations such as the pw_watch module that monitors files for change and triggers a build, test and even flash and debug on hardware. There is also a module that allows pre-submit checks such as linting and formatting.
Google still does not consider this offering production ready though from what we have seen so far, it is a great place for many to start experimenting with for their embedded development automation needs. Anyone tried it out yet?
The current state of virtual personal assistants — Alexa, Cortana, Google, and Siri — leaves something to be desired. The speech recognition is mostly pretty good. However, customization options are very limited. Beyond that, many people are worried about the privacy of their data when using one of these assistants. Stanford Open Virtual Assistant Lab has rolled out Almond, which is open and is reported to have better privacy features.
Like most other virtual assistants, Almond has skills that determine what it can do. You can use Almond in a browser, on a Google phone, or as a command line application. It all lives on GitHub, so if you don’t like something you are free to fix it.
The ESP8266 has become the hacker’s microcontroller of choice because it’s exceptionally easy to get the chip connected to the network and talking to other devices. The fact that it’s also absurdly cheap is just a bonus. Since nearly every piece of electronics you buy today is “smart” enough to include some form of Internet control, that means there’s no shortage of gadgets these MCUs can potentially poke and prod.
In their latest tip, [TecnoProfesor] shows how you can interface the ESP8266 with Google’s Cloud Print, a service that enables simple remote printing over the web without having to worry about having the proper device drivers. Remote printing from the ESP8266 might seem like little more than a gag at first glance, but if you’re the kind of person who likes to have hard copies of data, adding the capability to generate a daily printed report to your weather station could be a nice weekend project.
[TecnoProfesor] provides explanations and source code for printing documents of various sizes from both the ESP8266’s internal flash storage and an SPI-attached SD card. Towards the end of the write-up, there’s even some explanation of how the setPrintDocument() function of the Cloud Print API can be used in more advanced scenarios, such as printing web pages or documents stored in Google Drive.
New grounds were paved and anyone who wanted to become an animator or a web designer could manage it in a few tutorials. Only a few years before Flash took off, people had started talking about computers as a source for art in mostly theoretical terms. There were demoscenes, university studies, and professional communities, of course, but were they truly public? Suddenly Flash made computer art an everyday thing. How could computers not be used for art? In schools and offices all over the world people of varying technical skill would get links to games, animation, and clever sites sent by their friends and colleagues.
For 23 years Flash has had this incredible creative legacy. Yet it’s not perfect by any means. It’s a constant headache for our friendly neighborhood super-conglomerates. Apple hates how it drains the battery on their mobile devices, and that it’s a little village outside of their walled garden. Microsoft sees it as another endless security violation. They all saw it as a competitor product eating their proprietary code bases. Continue reading “Blend Your Last Frogs. Google Turns A Blind Eye To Flash.”→
Apple is known for a lot of things, but opening up their platforms to the world isn’t one of those things. According to a recent Google post by [Brandon Azad], there do exist special iPhones that are made for development with JTAG ports and other magic capabilities. The port is in all iPhones (though unpopulated), but is locked down by default. We don’t know what it takes to get a magic iPhone, but we are guessing Google can’t send in the box tops to three Macbook Pros to get on the waiting list. But what is locked can be unlocked, and [Brandon] set out to build a debuggable iPhone.
Exploiting some debug registers, it is possible to debug the A11 CPU at any point in its execution. [Brandon’s] tool single steps the system reset and makes some modifications to the CPU after key instructions to prevent the lockdown of kernel memory. After that, the world’s your oyster. KTRW is a tool built using this technique that can debug an iPhone with a standard cable.