Language Selection

English French German Italian Portuguese Spanish

Chrome OS 78 Rolls Out to Chromebooks with Improved Linux Support, Virtual Desks

Filed under
OS
Linux

Google has released today the Chrome OS 78 operating system for Chromebooks, a release that will arrive to users over the next several days and which brings several exciting new features, such as the Virtual Desks functionality we reported the other day, allowing Chromebook users to be more productive.

"You can now create up to 4 separate work spaces. Virtual Desks are for focusing on a single project or for quickly switching between multiple sets of windows. Create your first desk by opening Overview and tapping New Desk," said Google in the release notes.

Read more

Chrome OS Virtual Desks, Click-to-Call now available

  • Chrome OS Virtual Desks, Click-to-Call now available on some Chromebooks

    With the new PixelBook Go, Google is positioning Chromebooks as the ultimate productivity computer, especially on the go. It may not always feel that way considering the missing features and software on Chrome OS. Fortunately, just like the browser on which it is based, Chrome OS is constantly and regularly evolving and the latest update brings new features that promise to take users’ productivity to the next level.

Microsoft Tim: Google Bringing Back What it Removed From Gentoo

  • Chrome OS: Yo dawg, I heard you like desktops so we put a workspace in your workspace

    Google has added virtual desktops to its Chrome OS, used in Chromebooks, enabling users to create multiple workspaces and switch between them.

    The virtual desktop feature is the biggest of several updates. Once the update is installed, a New Desk icon appears in the top right corner of the desktop. You can display virtual desktops full screen or side by side, and drag windows between desktops. These operations can be done with touch, mouse, trackpad or using keyboard shortcuts.

    Virtual desktops have been available in Windows 10, macOS and Linux for some time so Google is catching up with these established operating systems.

    Another new feature is the ability to right-click a phone number in Chrome and send it to an Android phone. This requires enabling sync between the Chrome browser on both devices.

Chrome OS 78 rolling out

  • Chrome OS 78 rolling out: Split browser/device settings, YouTube for Android PiP, more

    Chrome is getting another cross-device sharing feature after “Send this page” widely rolled in September. With “click-to-call,” you can right-click on phone number links — like tel:800-800-8000 — to have them sent to your Android device. It’s quicker than manually entering those digits or transferring via email.

    Chrome OS 78 will separate browser and device settings. The former is accessible directly at chrome://settings and what opens when clicking “Settings” at the bottom of the Overflow menu in the top-right corner of any browser window. It opens as a tab and provides web-related preferences. Meanwhile, chrome://os-settings opens as its own window, and can be accessed from the quick settings sheet. It provides device options like Wi-Fi, Bluetooth, and Assistant in a white Material Theme UI with an icon in the launcher/app shelf.

  • Chrome OS 78 Rolling Out With Picture-In-Picture Support For YouTube, Split Browser/Device Settings, More

    The latest version of Chrome OS, version 78, adds separate browser and device settings, click-to-call, and picture-in-picture support for YouTube. It also introduces virtual desktop support for the operating system with a feature called Virtual Desks.

Chrome OS 80 will start using Debian 10 Buster on new Linux

  • Chrome OS 80 will start using Debian 10 Buster on new Linux installations

    At Google I/O last year, Google announced Linux app support for Chrome OS. This is made possible thanks to installing a GNU/Linux distribution, specifically Debian 9 “Stretch”, in a Linux container. Earlier this year, the Debian project announced Debian 10 “Buster,” but Google wasn’t ready to upgrade the default Linux container on Chromebooks just yet. Now, after months of testing and bug fixing, Google is ready to enable Debian 10 “Buster” as the default Linux container in Chrome OS.

    According to a recently merged commit we spotted in the Chromium Gerrit, new Crostini (the code-name for Linux apps on Chrome OS) installations will get Debian 10 by default. The commit doesn’t mention how Chromebooks with existing Debian 9 “Stretch” installations will be migrated to the newer version, but users can easily upgrade the container themselves by running a few commands. Upgrading to the newer version of Debian enables new features and should also bring greater application support. For the truly enterprising, it’s even possible to replace the Debian container with Arch Linux.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More in Tux Machines

Programming Leftovers

  • Quicksort in Python

    Quicksort is a popular sorting algorithm and is often used, right alongside Merge Sort. It's a good example of an efficient sorting algorithm, with an average complexity of O(n logn). Part of its popularity also derives from the ease of implementation. We will use simple integers in the first part of this article, but we'll give an example of how to change this algorithm to sort objects of a custom class. Quicksort is a representative of three types of sorting algorithms: divide and conquer, in-place, and unstable.

  • GCC 10.0 Status Report (2019-11-18), Stage 3 in effect now
  • GCC 10 Feature Development Is Over - Now The Focus Turns To Bug Fixing

    GCC 10 has moved to its next stage of development that shifts away from feature work to instead general bug fixing with hopes of shipping the GNU Compiler Collection 10 release in the months ahead. GCC 10 release manager Richard Biener of SUSE announced this Monday morning that "stage three" development phase.

  • ttdo 0.0.4: Extension

    A first update release to the still very new (and still very small) ttdo package arrived on CRAN today. Introduced about two months ago in September, the ttdo package extends the most excellent (and very minimal / zero depends) unit testing package tinytest by Mark van der Loo with the very clever and well-done diffobj package by Brodie Gaslam.

  • Adventures optimizing a bytecode based scripting language
  • Keeping a simple markdown work-log, via emacs

    For the past few years I've been keeping a work-log of everything I do. I don't often share these, though it is sometimes interesting to be able to paste into a chat-channel "Oh on the 17th March I changed that .."

  • Implement C++ coroutines.
    This patch series is an initial implementation of a coroutine feature,
    expected to be standardised in C++20.
    
    Standardisation status (and potential impact on this implementation):
    ----------------------
    
    The facility was accepted into the working draft for C++20 by WG21 in
    February 2019.  During two following WG21 meetings, design and national
    body comments have been reviewed, with no significant change resulting.
    
    Mature implementations (several years) of this exist in MSVC, clang and
    EDG with some experience using the clang one in production - so that the
    underlying principles are thought to be sound.
    
    At this stage, the remaining potential for change comes from two areas of
    national body comments that were not resolved during the last WG21 meeting:
    (a) handling of the situation where aligned allocation is available.
    (b) handling of the situation where a user wants coroutines, but does not
        want exceptions (e.g. a GPU).
    
    It is not expected that the resolution to either of these will produce any
    major change.
    
    The current GCC implementation is against n4835 [1].
    
    ABI
    ---
    
    The various compiler developers have discussed a minimal ABI to allow one
    implementation to call coroutines compiled by another; this amounts to:
    
    1. The layout of a public portion of the coroutine frame.
    2. A number of compiler builtins that the standard library might use.
    
    The eventual home for the ABI is not decided yet, I will put a draft onto
    the wiki this week.
    
    The ABI has currently no target-specific content (a given psABI might elect
    to mandate alignment, but the common ABI does not do this).
    
    There is not need to add any new mangling, since the components of this are
    regular functions with manipulation of the coroutine via a type-erased handle.
    
    Standard Library impact
    -----------------------
    
    The current implementations require addition of only a single header to
    the standard library (no change to the runtime).  This header is part of
    the patch series.
    
    GCC Implementation outline
    --------------------------
    
    The standard's design for coroutines does not decorate the definition of
    a coroutine in any way, so that a function is only known to be a coroutine
    when one of the keywords (co_await, co_yield, co_return) is encountered.
    
    This means that we cannot special-case such functions from the outset, but
    must process them differently when they are finalised - which we do from
    "finish_function ()".
    
    At a high level, this design of coroutine produces four pieces from the
    original user's function:
    
      1. A coroutine state frame (taking the logical place of the activation
         record for a regular function).  One item stored in that state is the
         index of the current suspend point.
      2. A "ramp" function
         This is what the user calls to construct the coroutine frame and start
         the coroutine execution.  This will return some object representing the
         coroutine's eventual return value (or means to continue it when it it
         suspended).
      3. A "resume" function.
         This is what gets called when a the coroutine is resumed when suspended.
      4. A "destroy" function.
         This is what gets called when the coroutine state should be destroyed
         and its memory returned.
    
    The standard's coroutines involve cooperation of the user's authored function
    with a provided "promise" class, which includes mandatory methods for
    handling the state transitions and providing output values.  Most realistic
    coroutines will also have one or more 'awaiter' classes that implement the
    user's actions for each suspend point.  As we parse (or during template
    expansion) the types of the promise and awaiter classes become known, and can
    then be verified against the signatures expected by the standard.
    
    Once the function is parsed (and templates expanded) we are able to make the
    transformation into the four pieces noted above.
    
    The implementation here takes the approach of a series of AST transforms.
    The state machine suspend points are encoded in three internal functions
    (one of which represents an exit from scope without cleanups).  These three 
    IFNs are lowered early in the middle end, such that the majority of GCC's
    optimisers can be run on the resulting output.
    
    As a design choice, we have carried out the outlining of the user's function
    in the front end, and taken advantage of the existing middle end's abilities
    to inline and DCE where that is profitable.
    
    Since the state machine is actually common to both resumer and destroyer
    functions, we make only a single function "actor" that contains both the
    resume and destroy paths.  The destroy function is represented by a small
    stub that sets a value to signal the use of the destroy path and calls the
    actor.  The idea is that optimisation of the state machine need only be done
    once - and then the resume and destroy paths can be identified allowing the
    middle end's inline and DCE machinery to optimise as profitable as noted above.
    
    The middle end components for this implementation are:
     1. Lower the coroutine builtins that allow the standard library header to
        interact with the coroutine frame (these fairly simple logical or
        numerical substitution of values given a coroutine frame pointer).
     2. Lower the IFN that represents the exit from state without cleanup.
        Essentially, this becomes a gimple goto.
     3. Lower the IFNs that represent the state machine paths for the resume and
        destroy cases.
     4. A very late pass that is able to re-size the coroutine frame when there
        are unused entries and therefore choose the minimum allocation for it.
    
    There are no back-end implications to this current design.
    
    GCC Implementation Status
    -------------------------
    
    The current implementation should be considered somewhat experimental and is
    guarded by a "-fcoroutines" flag.  I have set out to minimise impact on the
    compiler (such that with the switch off, coroutines should be a NOP).
    
    The branch has been feature-complete for a few weeks and published on Compiler
    Explorer since late September.  I have been keeping a copy of the branch on
    my github page, and some bug reports have been filed there (and dealt with).
    
    The only common resource taken is a single bit in the function decl to flag
    that this function is determined to be a coroutine.
    
    Patch Series
    ------------
    
    The patch series is against r278049 (Mon 11th Nov).
    
    There are 6 pieces to try an localise the reviewer interest areas.  However
    it would not make sense to commit except as possibly two (main and testsuite).
    I have not tested that the compiler would even build part-way through this
    series.
    
    1) Common code and base definitions.
    
    This is the background content, defining the gating flag, keywords etc.
    
    2) Builtins and internal functions.
    
    Definitions of the builtins used by the standard library header and the
    internal functions used to implement the state machine.
    
    3)  Front end parsing and AST transforms.
    
    This is the largest part of the code, and has essentially two phases
     1. parse (and template expansion)
     2. analysis and transformation, which does the code generation for the
        state machine.
    
    4) Middle end expanders and transforms
    
     As per the description above.
    
    5) Standard library header.
    
    This is mostly mandated by the standard, although (of course) the decision
    to implement the interaction with the coroutine frame by inline builtin
    calls is pertinent.
    
    There is no runtime addition for this (the builtins are expanded directly).
    
    6) Testsuite.
    
    There are two chunks of tests.
     1. those that check for correct error handling
     2. those that check for the correct lowering of the state machine
     
    Since the second set are checking code-gen, they are run as 'torture' tests
    with the default options list.
    
    ======
    
    I will put this patch series onto a git branch for those that would prefer
    to view it in that form.
    
    thanks
    Iain
    
  • Initial Patches Wire In C++20 Coroutines For The GCC Compiler

    The GNU Compiler Collection continues picking up new features aligned for the upcoming C++20 standard. The latest are patches pending on the mailing list for implementing coroutines in C++. C++20 is expected to have coroutines per the pending technical specification. Coroutines allow a function to have its execution stopped/suspended and then to be resumed later.

  • Faster Winter 1: Vectors
  • Faster Winter 2: SPECIALIZE
  • Attention! Attention! Tutorial Proposal Deadline Approaching
  • Python Software Foundation Fellow Members for Q3 2019

    Congratulations! Thank you for your continued contributions. We have added you to our Fellow roster online. The above members have contributed to the Python ecosystem by teaching Python, maintaining popular libraries/tools such as cryptography and pytest, helping document on packaging.python.org, organizing Python events, starting Python communities in their home countries, and overall being great mentors in our community. Each of them continues to help make Python more accessible around the world. To learn more about the new Fellow members, check out their links above.

  • Why Sponsor PyCon 2020?

    Sponsors help keep PyCon affordable and accessible to the widest possible audience. Sponsors are what make this conference possible. From low ticket prices to financial aid, to video recording, the organizations who step forward to support PyCon, in turn, support the entire Python community. They make it possible for so many to attend, for so many to be presenters, and for the people at home to watch along.

  • Pandas GroupBy: Your Guide to Grouping Data in Python

    Whether you’ve just started working with Pandas and want to master one of its core facilities, or you’re looking to fill in some gaps in your understanding about .groupby(), this tutorial will help you to break down and visualize a Pandas GroupBy operation from start to finish. This tutorial is meant to complement the official documentation, where you’ll see self-contained, bite-sized examples. Here, however, you’ll focus on three more involved walk-throughs that use real-world datasets.

  • Solving CAPTCHA with Web automation

    CAPTCHA is no longer an alien term to the users. An acronym for Completely Automated Public Turing test to tell Computers and Humans Apart. CAPTCHA is basically a computer program built to distinguish between the human and machine to prevent any type of spam or data extraction from websites. The entire concept of CAPTCHA is based on the assumption that only a human would pass this test and bot or automated scripts would fail.

Intel: BIOS, Mesa and Devices

  • Intel To Drop Very Old Drivers/BIOS From Their Site, But The Linux Impact To Be Minimal

    Making waves today is that Intel will be removing very old BIOS and driver downloads from their site on or after 22 November. Though these software downloads for the products in question are around ~20 years old so the real-world impact should be small plus with Linux drivers being in the mainline kernel, all you'd really be losing out on are BIOS updates that themselves haven't seen updates in years. Intel is said to be removing old drivers and BIOS from their original Pentium era product offerings later in the week. Intel hasn't provided an exact list of all the products affected, but they are all close to 20 years old and beyond. Besides vintage hobbyists and those relying upon the outdated hardware still in niche use-cases, there shouldn't be much real impact. This Reddit thread has additional details on some of the affected products and unofficial mirrors of the files now that the removal of the files are imminent.

  • Intel's Vulkan Driver To Lower CPU Overhead With Mesa 20.0

    A patch series was merged today for the in-development Mesa 20.0 to further lower the CPU overhead of Intel's open-source Vulkan driver. Lead Intel "ANV" driver developer Jason Ekstrand merged the 15 commits focused on CPU overhead reductions. These reductions come after analyzing traces from rapid bind-and-draw benchmarks and seeing that the binding tables and push constants were in the hottest of hot paths.

  • Intel's oneAPI / DPC++ / SYCL Will Run Atop NVIDIA GPUs With Open-Source Layer

    With yesterday's much anticipated Intel oneAPI beta being built around open-source standards like SYCL, the "cross-device" support can at least in theory extend beyond just Intel platforms. Codeplay is already showing that's possible with a to-be-open-source layer that will allow oneAPI and SYCL / Data Parallel C++ to run atop NVIDIA GPUs via CUDA. Codeplay, which is already known for their several Vulkan / SYCL / SPIR-V initiatives, is working on this layer to run oneAPI / DPC++ / SYCL codes atop NVIDIA hardware while still leveraging NVIDIA's CUDA drivers. You could think of it akin as DXVK or VKD3D that map Direct3D 11 to Vulkan but this is about allowing Intel-focused code to run on NVIDIA's drivers. Or similarly, AMD's Radeon ROCm that allows some CUDA codes to be compiled for execution on AMD hardware.

  • Mini Type 10 dev board supports extended mini-PCIe I/O modules

    Acromag’s rugged “ACEX4041” Mini-ITX carrier is equipped with a Linux-friendly, Apollo Lake based COM Express Mini Type 10 module plus 4x mini-PCIe based “AcroPack” slots that support 25+ I/O modules. Acromag announced a Mini-ITX form-factor carrier board for COM Express Mini Type 10 modules sold in three configurations: barebones (ACEX4041); equipped with an Intel Apollo Lake Mini Type 10 module (ACEX4041-2000); or a Development Lab System sold with the Apollo Lake module and 1TB storage (DLS4041-2110). The ACEX4041 is equipped with 4x AcroPack I/O slots that support third-party mini-PCIe cards but are designed primarily to load one of Acromag’s 25+ AcroPack modules.

  • Some FUJITSU FUTRO Thin Clients are Powered by Intel Gemini Lake Refresh SoC’s

    Six new Intel Gemini Lake Refresh processors were just announced a couple of weeks ago, and some of the first systems to feature the processor are part of FUJTISU Thin Client FUTRO family.

  • Gemini Lake based Lattepanda Delta SBC relaunches for $188

    DFRobot’s previously Kickstartered, Ubuntu-ready LattePanda Delta SBC has relaunched for $188 with a quad-core Gemini Lake SoC. The Intel Core-based Lattepanda Alpha is already available starting at $379 for a model that recently switched from a 7th Gen to an 8th Gen Amber Lake-Y CPU. Back in Dec. 2017, DFRobot’s LattePanda project went to Kickstarter to launch a community-backed LattePanda Alpha SBC with a 7th Gen Kaby Lake Intel Core m3-7Y30 and an almost identical LattePanda Delta with a Celeron N4100 from the “Gemini Lake” follow-on to Apollo Lake. Both boards shipped to backers late, with the Alpha ARRIVING in late 2018 and the Delta being fulfilled this spring. The Alpha relaunched for public sales in January, and now the Delta is available.

Audiocasts/Shows/Screencasts: System76, Linux Headlines and More

  • The System76 Superfan III Event: Gardiner and Jay Chat About Their AWESOME Experience There

    The System76 Superfan III event occurred on November 16th, 2019 and it was a ton of fun! Gardiner Bryant and I talk about our experience there, some of the things they revealed, and other geeky topics around System76 and their computers

  • 2019-11-18 | Linux Headlines

    The Oracle vs. Google copyright case goes to the Supreme Court, NextCry attacks Nextcloud servers, Chromebooks prepare to use LVFS, and Debian takes the systemd debate to the next level.

  • Things are Looking Pod-tastic | Fall Time Blathering

    I started to produce some video content on YouTube and this site to enhance some of my content and later, I thought I would cut my teeth on a podcast of my own to talk about the nerdy things I enjoy. My reoccurring topics consist of my additional thoughts about a subject or two of the last BDLL show and an openSUSE corner but truth be told, openSUSE weaves itself throughout my “noodlings”. In September of 2019, the formation of Destination Linux Network was announced where these well established content creators have pooled their resources to draw together their somewhat discrete communities and provide a forum for interaction in greater depth than what Telegram, Discord or YouTube can provide on their own.

  • Test and Code: 94: The real 11 reasons I don't hire you - Charity Majors

    If you get the job, and you enjoy the work, awesome, congratulations. If you don't get the job, it'd be really great to know why. Sometimes it isn't because you aren't a skilled engineer. What other reasons are there? Well, that's what we're talking about today. Charity Majors is the cofounder and CTO of Honeycomb.io, and we're going to talk about reasons for not hiring someone. This is a very informative episode both for people who job hunt in the future and for hiring managers and people on the interview team.

  • Bluestar Linux 5.3.11 Run Through

    In this video, we are looking at Bluestar Linux 5.3.11. 

Fedora: Fedora Toolbox, Building Successful Products, Nano Promoted and Apparel

  • Fedora Toolbox. Unprivileged development environment at maximum

    Fedora Toolbox is a tool for developing and debugging software that basically is a frontend to the Podman container system. A simple way to test applications without getting billions of dependencies and cluttering up your operating system. First, Podman (Pod Manager tool) is a daemon less container engine for developing, managing, and running OCI Containers on your Linux System. With Podman, you can manage pods, containers, and container images. You can consult (Podman.io) the official website to learn more about Podman and container tooling. Fedora Toolbox gives you a quick frontend to Podman and it also creates an interactive container based on your current system. Toolbox (actually, Fedora Toolbox is now just Toolbox) use is particularly useful for the development and testing environment.

  • Building Successful Products

    Building a new product is hard. Building a successful new product is even harder. And building a profitable new product is the greatest challenge! To make things even more interesting, the fundamental customer requirements for a product change as the product and market mature. The very things that are required for success in an early stage product will hinder or even prevent success later on. Markets, technologies and products go through a series of predictable stages. Understanding this evolution – and understanding what to do at each stage! – is vital for navigating the shoals of building a successful and profitable product.

  • Fedora Developers Looking To Change The Default Text Editor From Vi To Nano

    Fedora will be adding the Nano text editor to their default Fedora Workstation installs as complementary to Vi but their stakeholders intend to submit a system-wide proposal that would change the default installed editor from Vi to Nano. The Fedora Workstation flavor can add the Nano text editor by default to their spins without replacing it as the default terminal-based text editor, which is currently held by Vi. At today's Fedora Workstation meeting they refrained from trying to change the default text editor just for Fedora Workstation and instead will issue a system-wide proposal to change it to Nano for all of Fedora's spins.

  • Fedora shirts and sweatshirts from HELLOTUX

    Linux clothes specialist HELLOTUX from Europe recently signed an agreement with Red Hat to make embroidered Fedora t-shirts, polo shirts and sweatshirts. They have been making Debian, Ubuntu, openSUSE, and other Linux shirts for more than a decade and now the collection is extended to Fedora.