• 61 Posts
  • 13 Comments
Joined 1 year ago
cake
Cake day: July 28th, 2023

help-circle


  • I’m a masochist, so I usually do “New”. Lemmy is small enough that I can usually get through most of the new posts in a reasonable amount of time.

    That said, if I want to a bit chiller experience, I will use “Scaled” which sometimes bubbles up something I might have missed.

    Finally, I will use “Active” if I’m really bored and what to see what most people are engaged with… but that is pretty rare.

















  • I’m not so sure… for the following reasons:

    1. Despite using a version of the Linux kernel in ChromeOS, Chromebooks don’t always have the best hardware (ie. driver) support from the mainline kernel used by most distributions. That’s why there are niche distributions like GalliumOS which provide tweaks to support the touchpad and audio devices in many Chromebooks. It’s similar to how Android is Linux, but it’s not standard Linux as we are familiar with (so the hardware support is different).

    2. Many Chromebooks have really poor specs: low-wattage CPUs, small amounts of storage, low amounts of RAM. While they may be newer, they are actually probably less performant than older laptops. This has changed in recent years with the new Chromebook plus program (or whatever it is called) which mandates a reasonable set of baseline features, but that is talking about current Chromebooks and not the ones from the COVID era.

    3. Related to the previous point, many Chromebooks are not serviceable or upgradeable while Thinkpads and some recent laptops are. You are unlikely to open up a Chromebook and be able to replace say the RAM or SSD, which would be a show stopper for a lot of people that like Thinkpads.

    So… unfortunately, I think this take is a bit of a miss and I dont’ really see it happening. I would be happy to be proven wrong though since my kids have two Chromebooks from the COVID era :}







  • No, most likely Pipewire would be used to implement the protocol for various compositors.

    Think of the protocols as high-level descriptions of interfaces (or designs) that specify what needs to be implemented to support a particular feature (in this case capturing images of a “screen”). Looking at this one, it describes a ext_image_capture_source_v1 object that has various methods such as create_source and destroy. Different compositors could then implement or support this interface with whatever technology they wish (most will rely on Pipewire).

    This is already the case with the existing screensharing protocol. For instance wlroots uses pipewire buffers in xdg-desktop-portal-wlr.