5 ms·

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 t

by coryrc 5y 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 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..)

bhedgeoser 5y 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.
- ungamedplayer 5y 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?
- detaro 5y 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?
- throw0101a 5y 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.
- Agamus 5y ago
  It's fun that they assume that any of my computers have ever had a battery other than the CMOS one.
  - detaro 5y ago
    Where do they assume that?
- coryrc 5y 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.
zozbot234 5y 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 5y 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).
  - zozbot234 5y 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.
    - grumbel 5y ago
      I wouldn't call that easy. Downloading source, doing a patch and rebuilding once is doable[1] with some manual work. But even that doesn't last, it's extremely brittle the moment you try to update anything. Debian isn't build with forks in mind, it wants one big monolithic dependency tree and when you move away from that it falls apart quickly. Which is the reason why they recommend to remove all third party stuff whenever you do a dist-upgrade. [1] https://unix.stackexchange.com/questions/324680/how-to-apply-a-patch-in-a-debian-package https://unix.stackexchange.com/questions/324680/how-to-apply...
Cthulhu_ 5y 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?
- dijit 5y 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.
- vladvasiliu 5y 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.
mikepurvis 5y 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.

by coryrc 5y ago

bhedgeoser 5y 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.

ungamedplayer 5y 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?
detaro 5y 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?
throw0101a 5y 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.
Agamus 5y ago
It's fun that they assume that any of my computers have ever had a battery other than the CMOS one.
- detaro 5y ago
  Where do they assume that?
coryrc 5y 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.

zozbot234 5y 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 5y 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).
- zozbot234 5y 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.
  - grumbel 5y ago
    I wouldn't call that easy. Downloading source, doing a patch and rebuilding once is doable[1] with some manual work. But even that doesn't last, it's extremely brittle the moment you try to update anything. Debian isn't build with forks in mind, it wants one big monolithic dependency tree and when you move away from that it falls apart quickly. Which is the reason why they recommend to remove all third party stuff whenever you do a dist-upgrade. [1] https://unix.stackexchange.com/questions/324680/how-to-apply-a-patch-in-a-debian-package https://unix.stackexchange.com/questions/324680/how-to-apply...

Cthulhu_ 5y 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?

dijit 5y 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.
vladvasiliu 5y 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.

mikepurvis 5y 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.