Stories
Slash Boxes
Comments

SoylentNews is people

What's the Deal with Chromium on Linux? Google at Odds with Package Maintainers

posted by Fnord666 on Wednesday January 27 2021, @03:21PM   Printer-friendly
from the browser-non-grata dept.

MrPlow writes:

Submitted via IRC for TheMightyBuzzard

Linux users are more likely than most to be familiar with Chromium, Google's the free and open source web project that serves as the basis for their wildly popular Chrome. Since the project's inception over a decade ago, users have been able to compile the BSD licensed code into a browser that's almost the same as the closed-source Chrome. As such, most distributions offer their own package for the browser and some even include it in the base install. Unfortunately, that may be changing soon.

[...] To the average Chromium user, this doesn't sound like much of a problem. In fact, you might even assume it doesn't apply to you. The language used in the post makes it sound like Google is referring to browsers which are spun off of the Chromium codebase, and at least in part, they are. But the search giant is also using this opportunity to codify their belief that the only official Chromium builds are the ones that they provide themselves. With that simple change, anyone using a distribution-specific build of Chromium just became persona non grata.

Source: https://hackaday.com/2021/01/26/whats-the-deal-with-chromium-on-linux-google-at-odds-with-package-maintainers/

Original Submission

 
This discussion has been archived. No new comments can be posted.
What's the Deal with Chromium on Linux? Google at Odds with Package Maintainers | Log In/Create an Account | Top | 126 comments | Search Discussion
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

  • (Score: 0) by Anonymous Coward on Thursday January 28 2021, @03:26AM (3 children)

    by Anonymous Coward on Thursday January 28 2021, @03:26AM (#1105849)

    "There are plenty of places for Rust code to shine..."

    And what would those be? I haven't found any.

  • (Score: 2) by The Mighty Buzzard on Thursday January 28 2021, @01:37PM (1 child)

    by The Mighty Buzzard (18) Subscriber Badge <themightybuzzard@proton.me> on Thursday January 28 2021, @01:37PM (#1106058) Homepage Journal

    Anywhere your needs are faster development than C and a smaller footprint than interpreted languages.

    --
    My rights don't end where your fear begins.

    • (Score: 2) by Pino P on Thursday January 28 2021, @02:04PM

      by Pino P (4721) on Thursday January 28 2021, @02:04PM (#1106070) Journal

      And when it runs on an instruction set that has a bunch of money behind it.

      Rust targets only those instruction sets that LLVM targets. In particular LLVM does not target m68k (aka Motorola Freescale NXP MC68000), the instruction set of a few popular retro computing platforms such as Amiga and Sega Genesis. This is because there isn't enough money behind those platforms to support hiring someone to maintain a back end for ten years. From a May 2019 post to the mailing list [llvm.org]:

      AFAICT the problem has always been code ownership - we would need people with some knowledge of both m68k and llvm to be willing to actively support the target: steering it through the setup/experimental target stages, providing (and maintaining) test/buildbot coverage, managing reported bugs, and handling any changes to the llvm APIs that require changes in the backend.

      Even if there's a demand for it (and AFAICT from the amiga community alone there definitely is), without real code owners I don't think this will go anywhere.

      Thus developers of software for m68k platforms [spritesmind.net] are stuck with GCC and those languages it supports.

  • (Score: 0) by Anonymous Coward on Thursday January 28 2021, @06:54PM

    by Anonymous Coward on Thursday January 28 2021, @06:54PM (#1106212)

    Well, librsvg was rewritten in rust for a minor version bump, pulling in an exciting new build dependency as something of a happy little surprise.
    And while this may not have been appreciated by those running anything GTK-related on non-LLVM (and thus non-Rust) platforms, as they get stuck with no security patches and no upgrade path, for me it merely added an extra 8+ hours of compile time for Rust, and I assume also a longer build for librsvg itself. As a masochist (and I wouldn't be running Gentoo on a dinky netbook CPU if I weren't), that was obviously the good kind of surprise.