Comment by coryrc

3 years ago

Here's one: someone wrote a battery status "middleware" which reports battery status on DBus. Fine.

Then they coupled in "shutdown on low battery" and refuse to allow it to be disabled. https://gitlab.freedesktop.org/upower/upower/-/issues/64

So since xfce, gnome applets use this library, I either have no battery status applet or intermittently my computer goes into shutdown after resume because the battery falsely appears dead for a few seconds.

(The kicker: it doesn't log why it decided to initiate the shutdown. Took years to find the bloody cause..)

26 comments

coryrc

Reply
zozbot234  3 years ago

> and refuse to allow it to be disabled

Why don't people fork these terribly managed projects? Even just working on the feature and then submitting the .patch file to be merged in by downstream distros would be a very meaningful signal.

  • grumbel  3 years ago

    Big problem is that just forking it isn't enough, you also have to convince every distro out there to switch to your fork to make any real difference. It becomes a truckload of boring work for what might be a trivial one-line fix in the code.

    I blame the package managers we use for this, as most of them make it incredible difficult to change anything and make you a slave to whatever the distribution ships, which in turn is slave to whatever upstream ships. The effort to fix the issue just far outweighs the issues the problem is causing in the first place.

    NixOS is one of the few that seems to get this right by making code changes pretty much trivial. Just fork the upstream repository, point the package to the new fork and you are done. With a Nix flake you can even make the repository itself installable directly. No need to try to convince any maintainer to include your patch. And having package names be hashes means you can switch between old, new and patched versions of a software easily, no need to worry about conflicts or having to un/reinstall all the time. Downside is the lack of binary compatibility in NixOS, meaning if you change a package deep down the dependency tree you might end up recompiling half your distribution and can no longer use the precompiled binaries (there is `patchelf` to workaround this, but haven't used that myself yet).

    • rssoconnor  3 years ago

      Not only can you do that in NixOS, but you can even do something lighter weight and apply a patch to an existing package. This has the advantage that the patch often persists through software updates.

      For example, I used to patch OpenSSH to increase the minimum field size for DH key exchanges [1]. Eventually OpenSSH did update their minimum field sizes so I do not use this patch anymore.

      [1] https://r6.ca/blog/20150111T040537Z.html

      For those interested, patching OpenSSH in NixOS involves adding the following to one's system configuration:

          nixpkgs.config.packageOverrides = oldpkgs: {
      openssh = pkgs.lib.overrideDerivation oldpkgs.openssh (oldAttrs: {
        patches = oldAttrs.patches ++ [ ./openssh-dh-grp-min.patch ];
      });
    };

      where openssh-dh-grp-min.patch is the patch file you want to apply.

      4 replies →

    • zozbot234  3 years ago

      Debian-based distros make it easy to rebuild .deb's with extra patches. Source package management and build-time dependency tracking is integrated in the package manager, so it's just a matter of downloading the source, adding your own .patch file and rebuilding.

      3 replies →

    • pabs3  3 years ago

      The patch looks pretty simple and is in a part of the code that probably doesn't change much, I bet it would be possible to get it included in several distros.

      2 replies →

    • flyinghamster  3 years ago

      Ansible can also come in handy for changing irritating defaults or substituting packages. If I'm setting up a plain Debian desktop, it makes it nice and quick to rip out Firefox ESR and grab the non-ESR Firefox from Sid.

mikepurvis  3 years ago

> because the battery falsely appears dead for a few seconds.

Uuughh, I have this with Windows on my Dell XPS as well. Basically every time it comes out of sleep/hibernate, it will briefly think the battery is at 0% and try to shut itself down, and if you boot it up again without it being plugged it, it won't start up at all.

But when plugged in (either coming out of sleep or for the follow-on boot), after a few seconds it'll go "lol yeah no you are actually at 100%, no further charging is required, hooray!"

Would love to know how to disable the critical battery shutdown altogether in order to get around this. It's a bizarre and terrible bug to have in what is supposed to be a flagship developer machine.

Cthulhu_  3 years ago

> Then they coupled in "shutdown on low battery" and refuse to allow it to be disabled.

Isn't that to protect user's data? There's been numerous reports that modern-day high performance SSD's don't actually neatly write data to physical storage after a flush command; I wouldn't want to lose data if my system unexpectedly shuts down due to power / voltage issues.

Or is there additional low power protections at a hardware level?

  • vladvasiliu  3 years ago

    That could be the reason why it's done, and maybe it's helpful in such cases.

    But what if I have some "pro-grade" SSD that doesn't need this? What if I have some huge battery that lasts for 2 hours when there's only 2% left?

    Point is that the user should be able to have the final word, even if the default looks to be helpful.

  • dijit  3 years ago

    we have journalled filesystems these days, even without hardware protections it does not mean the machine should forcefully make decisions for us.

    Depending on the brand of flash storage, there are power loss protections (the same as harddisks, actually) where a little capacitor stores enough charge to park the head or flush the DRAM component of the flash to SLC solid flash storage.. if you have a huge write in progress (enough to blow the SLC cache and the NAND cache) then you might lose that write.

bhedgeoser  3 years ago

> Then they coupled in "shutdown on low battery" and refuse to allow it to be disabled

Would you rather have your computer crash when it runs out of battery, or shutdown gracefully at 2 percent battery.

  • throw0101a  3 years ago

    > Would you rather have your computer crash when it runs out of battery, or shutdown gracefully at 2 percent battery.

    If I want my computer to crash then that is a policy I should get to make on my own. It is not the job of the software vendor/developer to dictate policy to me.

    If they have to have a default then they can pick whatever, but not being able to change a particular setting is a bug.

  • detaro  3 years ago

    Would you rather have to pay a bit of attention or have a computer that just randomly shuts down when it gets confused about battery state, since that's the scenario parent is describing?

  • coryrc  3 years ago

    Xfce power manager will handle that on its own. I tell it to sleep instead of power off. Then, worse case laptop just falls back asleep and I wake it a second time.

  • ungamedplayer  3 years ago

    Why would there be a software fault (crash) at any battery percentage?

    What function of battery charge causes an error on a modern operating system?