Language Selection

English French German Italian Portuguese Spanish

Lessons in Vendor Lock-in: Google and Huawei

Filed under
Android
Google

Vendor lock-in isn't new, but until the last decade or so, it generally was thought of by engineers as a bad thing. Companies would take advantage the fact that you used one of their products that was legitimately good to use the rest of their products that may or may not be as good as those from their competitors. People felt the pain of being stuck with inferior products and rebelled.

These days, a lot of engineers have entered the industry in a world where the new giants of lock-in are still growing and have only flexed their lock-in powers a bit. Many engineers shrug off worries about choosing a solution that requires you to use only products from one vendor, in particular if that vendor is a large enough company. There is an assumption that those companies are too big ever to fail, so why would it matter that you rely on them (as many companies in the cloud do) for every aspect of their technology stack?

Many people who justify lock-in with companies who are too big to fail point to all of the even more important companies who use that vendor who would have even bigger problems should that vendor have a major bug, outage or go out of business. It would take so much effort to use cross-platform technologies, the thinking goes, when the risk of going all-in with a single vendor seems so small.

Huawei also probably figured (rightly) that Google and Android were too big to fail. Why worry about the risks of being beholden to a single vendor for your OS when that vendor was used by other large companies and would have even bigger problems if the vendor went away?

Read more

More in Tux Machines

Annual Report 2018: LibreOffice development

Throughout the second half of 2018, the developer community worked on a new major release: LibreOffice 6.2. Details about the end-user-facing new features are provided on this page, and in the following video – so in the rest of this blog post, we’ll focus on developer-related changes. Read more

Programming Leftovers

Linux Kernel: Chrome OS, Direct Rendering Manger (DRM) and Char/Misc

  • Various Chrome OS Hardware Support Improvements Make It Into Linux 5.3 Mainline

    Various Chrome OS hardware platform support improvements have made it into the Linux 5.3 kernel for those after running other Linux distributions on Chromebooks and the like as well as reducing Google's maintenance burden with traditionally carrying so much material out-of-tree.

  • The Massive DRM Pull Request With AMDGPU Navi Support Sent In For Linux 5.3

    At 479,818 lines of new code and just 36,145 lines of code removed while touching nearly two thousand files, the Direct Rendering Manger (DRM) driver updates for Linux 5.3 are huge. But a big portion of that line count is the addition of AMD Radeon RX 5000 "Navi" support and a good portion of that in turn being auto-generated header files. Navi support is ready for the mainline Linux kernel!

  • Char/Misc Has A Bit Of Changes All Over For Linux 5.3

    The char/misc changes with each succeeding kernel release seem to have less changes to the character device subsystem itself and more just a random collection of changes not fitting in other subsystems / pull requests. With Linux 5.3 comes another smothering of different changes.

today's howtos