> But i can see ko being good alternative if you for some reason do not want to install docker on your computer but still be able to build docker containers.
Docker is a much bigger dependency than ko, involving a daemon and a socket you have to manage and secure. ko is a only a go program, and builds are straight-forward and lightning fast compared to Docker.
Importantly, ko also removes the need for a Dockerfile. Yes, as you point out a Dockerfile can be simple, but but the best part is no part. Dockerfile has plenty of foot guns and best practices to learn so if at the end of the day all you need is a go binary on a container ko will serve you much, much better.
Although Dockerfiles have the benefit of migrating existing workloads to containers without having to update your toolchain, I definitely prefer the container-first workflow. Cloud Native Buildpacks(https://buildpacks.io/) are a CNCF incubating project but were proven at Heroku. Buildpacks support common languages, but working on a Go project I've also had a great experience with ko(https://ko.build/). Free yourself from Dockerfile!
I live in the neighborhood and have bought a few sodas from the machine. I always assumed it was locksmith, they are powering the machine and I've never seen nor heard a reason to believe it was anyone else.
It was a cute novelty, and if you're not picky it's a fast soda, but honestly it was just stocked with cheap, off-brand gross soda. Would have been genius if occasionally it gave you something interesting (or at least good).
> Google might do this for a lot of reasons, and none of them seem to be good.
As a Play Store developer, I give Google the benefit of the doubt. By the way, before you assume a nefarious purpose, consider all Android phones connecting to the Play Store (by definition) have an auto-updating root process. Why does Google need to impersonate an application developer? This is fundamentally why Commonsware scare tactics don't resonate with me, the application has less privileges than the system and the app store, the calls are coming from inside the house!
But, there are more common and mundane reasons. Honestly, a lot of people lose their private signing key. And if that happens, no more updates to your app. By using App Signing, Google can help regenerate a key for you. They want to make this ability consistent across their whole store, that's why they're making the change.
They can also optimize the app bundle the device downloads from the store, as the store will know the target screen size, localization, CPU architecture, etc. The current workflow forces the application engineer to upload separate apk configurations. So this is also an improvement.
You're correct that some Google Cloud zones are in the same physical building. However, the separate zones are designed with independent power, cooling, and networking. So, failure events usually affect only a single zone.
> There's this idea that people must be 100% "professional", non joking, always zen-calm, all the time. That is, dry and passive aggresive.
This idea is likely held by people who have not had a lifetime of discrimination and insults and made fun of for X. When you have been such a victim, being in a professional, zen-calm work environment is a luxury, and honestly not too much to ask for.
All things considered, I'd say Apple has done an excellent job wrt security for iOS devices. All modern iOS devices are updated on a regular basis with a high uptake rate, and Apple monitors its store and is increasing its use of bug bounties. And with these exploit chains, Apple has addressed the issues quickly.
The downside of Android being an open platform is that Google is limited in forcing vendors to update their devices - and most do not. That said, Android has had regular monthly security releases for years, and the Pixel devices are excellent from a security perspective. Google also monitors its app store - as well as the full Android ecosystem (as far as Google Play Services is installed) for potentially harmful applications. This is why you regularly see articles along the lines of "Google removes malware from the Play Store that has had X installs!"
I'd say the biggest vulnerability for Android users given its impressive scale is a vulnerability in a vendor's supply chain. Given the complexity of devices, a vendor likely has multiple places where a malicious actor could insert malware into an Android device. I think this is why US intel has ultimately decided devices from China - Huawei in particular - are untrustworthy. If you can't validate every component of a device and trust the vendor will always audit its security, then it's hard to trust a device, even if it is safe right now.
Surprised such a comprehensive guide for geeks didn't get into bluetooth headphones! As a rider for a few years now, I've had good luck with the headphone inserts which fit into most helmets. Riding with your favorite music truly feels like playing the best of games and sports combined.
I'm an Apple fan - congratulations to Apple - but on the other hand Apple being the biggest company in the world is pretty uninspiring. After seeing Tesla build a mass market electric car factory, or SpaceX launching a Roadster into space, a company with hundreds of billions of dollars in the bank making phones and headphones feels like a wasted opportunity.
I would be happy with laws clearly requiring a presidential candidate to disclose their full income taxes for the past 5 years, and also required them to put their assets into a blind trust / index fund when inaugurated into office. We should not have to question the president's basic motivations or allegiances.
Stronger anti-nepotism laws, restraints on the ability to pardon, and ending the electoral college also all seem helpful and would have bipartisan support.
I doubt anyone will steal Android from Google. I can see two scenarios where the Android SDK (which includes Kotlin, Java, NDK) + Google Play Services is really threatened:
1) the WeChat scenario. Amazon is probably the best positioned so far and their platform and services are also available on iOS and Web. The potential WeChat could avoid the Google tax by handling payment, but would likely have to offer many of the Google Play Services (notably voice recognition, maps, and location) so Google would likely still be involved (also e.g., GV invests in Lyft and Uber).
2) Future OS includes Android compatibility. Another platform that can also run Android (and therefore has Google Play) apps isn't really a loss for Google, but it is a way for Android to be commoditized in favor of another. Steve is betting on Amazon, but Samsung is probably the most successful with their store (which doesn't seem very successful). If anything Google itself has the advantage here - they mostly have it working on ChromeOS and I'm willing to bet Android compatibility with come to Fuchsia.
My disclaimer: my coworkers are using Scala and SBT. Gradle + Java isn't slower than Ant or Maven. Gradle + Kotlin is a little slower, they just need to make the annotation processors incremental.
But for Java, incremental builds with compiler avoidance combined with the build cache, parallel builds (incubating features close to maturity) mean I write more sophisticated, easier to maintain builds than I ever have with Maven.
Did you not finish the rest of the post? Yes, it's true that compressed json is not materially different in size vs protobufs. But when it comes to the speed of serializing and deserializing protobufs there is a huge gain across languages. So if you're using gRPC in backend environments you'll gain huge speed benefits.
Although the Android ecosystem is probably the biggest OS deployment on devices right now, Google has done a pretty impressive job maintaining its overall safety. The primary mechanism they use is what they call GMS (Google Mobile Services), built on top of AOSP.
GMS includes the Google Play Store, which they reported this year had 2B monthly active users. The most notable AOSP derivatives that do not run GMS are Amazon's Fire OS and whatever Chinese companies are doing. Whenever you see somebody trying to implement "Android without Google", they are (misguidedly) replacing GMS.
Anyway, GMS on the device auto-updates and works with cloud services to detect and act on malware the user may have installed. This year Google branded this "Google Play Protect". Because GMS doesn't require firmware, kernel, or platform updates to work, Google is able to police the ecosystem effectively.
Also, because all apps are signed by the developer and Google controls the Play Store, its also able to work with developer community to mitigate libraries / sdks that are harmful. The overall end result is harmful apps are only on 0.05% of devices that only install apps from the Play Store (the most common scenario, and the default).
Docker is a much bigger dependency than ko, involving a daemon and a socket you have to manage and secure. ko is a only a go program, and builds are straight-forward and lightning fast compared to Docker.
Importantly, ko also removes the need for a Dockerfile. Yes, as you point out a Dockerfile can be simple, but but the best part is no part. Dockerfile has plenty of foot guns and best practices to learn so if at the end of the day all you need is a go binary on a container ko will serve you much, much better.