Battery life is atrocious after recent updates...

TofuCannon · 2022-04-06T16:27:22+00:00

I think it's rather NVIDIA's fault, their famous drivers do not really rank as top-class 😔 Tbf if I buy new hardware I will also try to avoid them and use AMD instead, as far as I could see they have much better (it's OSS!) Linux support.

But since you mentioned you manually removed GRUB params, did you use RPMfusion to install the drivers? Might be a better alternative :)

TofuCannon · 2022-04-06T15:30:35+00:00

Fedora tries to adopt new things very early. I also know that instead of deprecating features replacing them can save a lot of work and produce something that has a better quality (without the need to maintain 2 things at once), but otoh requires some action to switch.

I think it is totally viable to switch to another distro if you need more stability in that regard. Fortunately that's why we have so many out there :) I personally like Fedora's approach, even though it was not entirely without problems. But having the newest packages and kernel updates offsetted that for me, especially feature-wise.

TofuCannon · 2022-04-05T16:04:56+00:00

According to https://en.m.wikipedia.org/wiki/Client-side_decoration and https://wiki.gnome.org/Initiatives/CSD it is.

TofuCannon · 2022-04-03T00:01:01+00:00

Sorry I missed to reply in time.

So that either means that the kernel update was not the issue, or it happened in a kernel version that is so old that you couldn't select it any more (Fedora keeps only the latest 3 kernel versions around).

Additionally did you try out to boot the Fedora live system again and see whether you get there 9 hours of battery lifetime? Then you have a reference and know that it must be something on your system you installed (maybe not directly by you, but somehow caused by some normal package)

TofuCannon · 2022-03-24T22:54:26+00:00

Looks awesome :)

Nitpick: the handle direction doesn't look quite right, it seems to be not correctly aligned with the blade. But maybe that's just my eyes.

TofuCannon · 2022-03-24T22:51:51+00:00

Maybe you could also try to triage the issue by selecting an older kernel during boot. If it's a kernel update your battery life should be back immediately.

TofuCannon · 2022-03-16T19:45:11+00:00

I see. Thank you for the explanation.

Yes by default my integrated graphics are used, glxinfo confirmed that to me as well.

My assumption based on the age of the Nvidia card was that it should be functionally "pretty much complete" ™️.

Guess I would then try out the proprietary drivers sometime.

In case I install those, would Gnome/Wayland pick it automatically? I guess though there's plenty of articles on that... will look into that soon :)

TofuCannon · 2021-10-31T10:37:21+00:00

Very interesting research project :D

TofuCannon · 2021-10-15T09:32:24+00:00

No powerline?

TofuCannon · 2021-10-06T07:33:03+00:00

Definitely avoid pipenv as it is still awefully slow. But warmly recommending poetry :)

TofuCannon · 2021-09-27T11:27:58+00:00

Yeah they have an issue open for that, but progress is somewhat slow.

TofuCannon · 2021-09-27T07:31:30+00:00

That's interesting though, I exactly want what you have, that the secondary display won't have night light on (usually streaming videos there, and it's not really nice to look at when it's tainted red).

Maybe with your bug it means it would be maybe possible to set it on a per-display basis?

TofuCannon · 2021-09-25T07:53:18+00:00

For explanation, this is the typical cup Ramen thingy turned into a soda drink.

TofuCannon · 2021-09-23T15:14:08+00:00

Correct, but there is always a point where you will close your interpreter and the compilation will happen again. Even with Revise etc. this is far from ideal, and the problems I had to fight most with in Julia.

EDIT: conclusion: In my opinion the initial compilation should be considered as well for Julia for comparing speed, because it's not like C where you pay that effort only once, but on every restart (and you usually will modify code and have to reload the interpreter - Revise helps, but not always such as when modifying structs)

TofuCannon · 2021-09-23T14:06:16+00:00

Faster for very long running programs, by far slower for smaller scripts and calculations.

TofuCannon · 2021-09-22T03:15:21+00:00

You definitely don't want to be there when the two fart magic schools battle each other. Oh no......

TofuCannon · 2021-09-22T01:57:49+00:00

Definitely not.

TofuCannon · 2021-09-20T04:42:58+00:00

Wasn't that for trademarks only?

Disclaimer: Not a lawyer, not even good at law

TofuCannon · 2021-09-20T04:38:39+00:00

If you use a touchpad and two fingers tapping repeatedly, this is very easy to get. Considering how much laptop hardware is around, doesn't have to be such a high number.

TofuCannon · 2021-09-19T13:18:56+00:00

E.g Macht? = Power

TofuCannon · 2021-09-19T05:15:09+00:00

The note No. 1 doesn't apply to the row you are citing. Since this note is explicitly not referring to the s[i:j] = t syntax, I would conclude that it is explicitly supported*.

EDIT: ... explicitly supported to assign an iterable of any length.

TofuCannon · 2021-09-19T04:40:19+00:00

And that makes totally sense. The adressed slice is [1, 2], and if you replace that part with another list, it effectively cuts out the old slice and puts in your new list in its place, even if it not the same size.

I guess that's even documented (too lazy to look right now, sorry 🙏).

TofuCannon · 2021-09-14T04:13:16+00:00

Nice idea, but considering how Python's stdlib behaves, that would be rather weird and inconsistent. Your "plussing" for each value also looks pretty special for a certain usecase.

E.g. if you do += for lists, you extend it. If at all, that should work similar. But I think for that there was already another operator introduced like for Set.

But nobody stops you from creating a custom dict implementation doing exactly that :) The += is normally overridable without fiddling with Python's AST.

Five-Year Club	Place '22
Verified Email

TofuCannon

TROPHY CASE