Systemd Starts Tapping ChromeOS For USB Devices That Support Auto-Suspend Well

[jacob]

Actually, I haven't really seen any of them on this thread. I think we've drowned them out with all the mockery...

Maybe it's a case of Poe's law.

[intelfx]

Hm.

I thought that ChromeOS is only supported on a few select devices so there's not much to gain by reusing hardware-dependent bits from it? Or does Google maintain a master list of commonly used peripherals unrelated to Chromebooks themselves?

[tildearrow]

Just using arch doesn't automatically make you one of the noted people, and if you haven't seen them yet then count yourself lucky as they seem to be everywhere.

Well, I'm not lucky then.

There was this player with Arch in its name, and every time it made a frag it'd say "btw I use Arch". How annoying!

[tildearrow]

All right, let's take a short break from the (arguably very fun) trolling in this thread and look at the ridiculousness of the situation.

Thanks.

Someone has imported a dataset that allows Linux distros to properly manage USB suspend/resume. The benefit of this to the community should be self-evident and a no-brainer. But because the tool that actually performs that management happens to be distributed under the loose systemd brand, then the usual suspects report for duty and immediately see some sinister conspiracy, probably trying to take away their God given freedom to have dysfunctional USB or something.

Exactly...

It depends on whether said tool will perform well or not (it seems that it will be the former though)

[archsway]

All of these devices are either made by Google or used inside Chromebooks, so I don't think it will help other devices much.

It might make it easier for when Google switches to using SystemD in Chromebooks in a few months time, though...

[carewolf]

I wish, in a future USB version, there would be feature flags, so we could drop the destined-to-be-buggy device ID's. It's like browser sniffing.

There is a huge list of device ids in libmtp as well.

The problem is not that the devices don't have the feature. It is that some devices are crap and buggy.

[mrugiero]

Arch uses systemd for everything. Real Men use Devuan, Gentoo or Void Linux because fifty years ago there was nothing wrong with using buggy, unmaintainable shell scripts.

Not sure if mocking. But just in case, setting a cronjob to restart sendmail every few hours was really elegant, go Unix!

I thought that ChromeOS is only supported on a few select devices so there's not much to gain by reusing hardware-dependent bits from it? Or does Google maintain a master list of commonly used peripherals unrelated to Chromebooks themselves?

AFAIK, that's what this is about, a whitelist of peripherals.

[jacob]

Not sure if mocking. But just in case, setting a cronjob to restart sendmail every few hours was really elegant, go Unix!

Not mocking, but I would never use "cronjob" (let alone sendmail) and "elegant" in the same syntax:

1. Cron has no API. It's impossible for an application to programatically set up a job to be executed at certain times.
2. Being loosely coupled, it has no notion of interdependencies with other OS events and resources, It's impossible to set it up to run for example sendmail every hour if the system is online, or to automatically back up a folder if a storage device is connected, etc. "Loose coupling" has recently became a new slogan for the anti-systemd people but core components of the OS, which the timer scheduler is part of, must be tightly integrated and interdependent to provide any real value to developers (in 2019 the concern is developers, not traditional *nix sysadmins).
3. Like all unix tools it has an arbitrary, arcane and error-prone syntax.