Linux Apps Are Not Coming To Many Still-Supported Chromebooks (betanews.com)

While we know that Linux app support is coming to a range of Chromebooks from Lenovo, Acer, Dell and others, a post on the Chromium Gerrit reveals that devices running Linux 3.14 or older will miss out. BetaNews: Chrome OS is able to run Linux apps through the use of containers which help to keep the rest of the operating system safe from harm. As container support requires features that are only found in more recent versions of the Linux kernel, it means that many Chromebooks -- whose kernels are usually not updated -- will not be able to run Linux apps.

Here's the full list of Chromebooks that won't be getting the Linux love: AOpen Chromebase Mini (Feb 2017; tiger, veyron_pinky), AOpen Chromebox Mini (Feb 2017; fievel, veyron_pinky), ASUS Chromebook C201 (May 2015; speedy, veyron_pinky), Acer C670 Chromebook 11 (Feb 2015; paine, auron), Acer Chromebase 24 (Apr 2016; buddy, auron), Acer Chromebook 15 (Apr 2015; yuna, auron), Acer Chromebox CXI2 (May 2015; rikku, jecht), Asus Chromebit CS10 (Nov 2015; mickey, veyron_pinky), Asus Chromebook Flip C100PA (Jul 2015; minnie, veyron_pinky), Asus Chromebox CN62 (Aug 2015; guado, jecht), Dell Chromebook 13 7310 (Aug 2015; lulu, auron), Google Chromebook Pixel (Mar 2015; samus), Lenovo ThinkCentre Chromebook (May 2015; tidus, jecht), Toshiba Chromebookk 2 (Sep 2015; gandof, auron).

Comments

Should add .NET support

[bluefoxlucid]

I had suggested they use containers to add .NET support instead of straight Linux apps. Linux needs a whole underlying support system in a VM; .NET can inherit that from the local system and the .NET runtime.

Stuff .NET Core or Mono in there and provide a /home/$USER directory. Mount /home/$USER, mount local Documents to /home/$USER/Documents, and mount the Google Drive folder to /home/$USER/Drive.

When you install a .NET application, it would mount all of those things, as well as a .NET runtime for the app. The runtime could include a modification to call for additional libraries: if it tries to load an assembly, it calls through a socket to tell ChromeOS to add that library to the container (additional mount), and ChromeOS may fetch the library via nuget.

The container would expose a Chrome browser stub which also calls on ChromeOS to open the browser. It could do the same for opening various files. A ChromeOS file dialogue would display the mounted paths the same way ChromeOS exposes them, unifying the UI.

Now you have native .NET applications. You can get a Python and Java VM running on .NET, which may allow extending this to other types of native applications using the same runtime. You can isolate those applications from the system so they only have access to their own configuration and specific paths, rather than the whole of your files.

It's less reach than a whole Linux VM; it's also less overhead and tighter integration.