Craving Discovery

Blog

  • Motorola’s Software Update Policy: One Step Forward, Two Steps Back

    motorola logo

    Motorola has consistently launched value-for-money devices in the budget and mid-range segments of the Android smartphone market. While it’s not among the most innovative brands, many users have remained loyal due to its reliable and affordable offerings.

    However, one area that has held Motorola back from becoming the go-to recommendation for smartphone buyers is its software update policy. With policy reversals, poor update quality, and inconsistent release schedules, Motorola devices have often lagged behind competitors—especially as other brands are now beginning to match Apple in terms of long-term software support for flagship phones.

    The Great Restart

    With the launch of new budget and mid-range models like the Moto G75 and Moto Edge 50 Neo, Motorola appeared to turn a new leaf by promising five years of OS updates and six years of security patches. This move was widely praised, from tech reviewers on YouTube to everyday smartphone users.

    Unfortunately, Motorola has now backtracked, reducing the promised five OS updates to just three. This reversal has led to a significant trust deficit between users and the company, with many feeling misled by what now seems like a classic bait-and-switch.

    Motorola Is Not a Struggling Brand

    Unlike many smartphone manufacturers that have exited the market in recent years, Motorola has maintained a consistent global presence. It continues to launch multiple devices across major markets and holds a strong market share in developed countries like the United States, where competition in some segments is minimal.

    Backed by a strong parent company and an extensive product portfolio, Motorola has the resources and potential to be a major player. However, inconsistent and unreliable software support policies could undermine long-term user trust and loyalty.

    Source

  • Freedom Gone Wrong – Hassles of an Everyday Linux User

    The world of GNU/Linux has long touted its open-source foundation and the freedom to choose—right down to the bare metal of your operating system. Hate systemd? Choose another init system. Hate a full-blown desktop environment? Use the terminal. The choices available to users can top any other competitor out there, bar none.

    But what happens when this intrinsic strength of the Linux world becomes the very thing that derails its rise as a worthwhile product for the average Joe?

    What we are now witnessing is an endless wastage of manpower and talent into fragmented projects that could have been better focused elsewhere. It all starts with defaults—or the lack thereof. The developer community has a long history of pouring effort into projects that often lead nowhere.

    Take the systemd controversy as an example. When the community tries to switch to a new technology, an opposing group emerges to declare, “This is not the right way,” and starts a new alternative project. From package managers to compiling driver binaries, there is no single way that fits all distributions in the Linux world.

    Binaries and Valve

    The problem with binaries for the Linux desktop is simple: You don’t build binaries for Linux—you build binaries for Fedora, Ubuntu, SUSE, etc. When an OEM builds a binary for Windows devices, they build it once and ship it for all Windows systems. No one complains that it doesn’t work on their version of Windows because of strong backward compatibility and legacy support.

    Even Valve, with all its resources, couldn’t handle the herculean task of managing the required legacy files to run all native Linux games across the vast array of distributions.

    End User Woes

    This fragmentation ultimately affects the average user—someone who just wants to try Linux or is looking for a new OS because their version of Windows is no longer supported. From display servers, bootloaders, drivers, kernel firmware, and package managers, the user must wade through countless hurdles just to get their device working without errors or crashes.

    That is—until a driver misconfiguration or random update kills their system.

    Conclusion

    The chaos, duplication of effort, and endless mediocrity of fragmented Linux projects need to stop. Currently, the only major player pushing any kind of standardization in the Linux ecosystem is Red Hat. From systemd, Flatpak, to Wayland, they have shown that it’s possible to set the sails of the Linux ship in one direction.

    Let us wait and see what shore awaits in its future.