/tech/ - Technology

Probably. Can squeeze a little more if there's any applications you could use a terminal app for, but depends how comfortable you are with those.

Some kernel options that could help like opportunistic sleep which android uses by default.
There is no clear consensus on whether the powersave or ondemand cpufreq governor is more power efficient. Powersave prevents the cpu from drawing to much power by capping the frequency. Ondemand runs workloads at the highest frequency, so the cpu can be idle faster.

>>22368
On my laptop, powersave CPU governor definitely saves battery charge most.

>>22482
I would be curious how your workflow looks like:
Running computing intensive tasks like many compile jobs will draw much power either way. Frequency scaling can generally save the most on varied, in this case interactive, workloads.
I would guess a cpu with the powersaving governor is fast enough to run a shell or terminal editor on a single core. At that level the ondemand governor would be more likely to overshoot the most efficient frequency or not scale back optimally fast.
The workload where an ondemand governed cpu may become more efficient than a powersaving one woulde be when servicing computing intensive interactive processes, so they run faster and potentially occupy less cores. This could be a web browser, a repl or a single compile job.
Considering much of linux power management is aimed at server usage, the ondemand governor may also be tuned for server workloads and generally not scale accurately to interactive usage with very short bursts of processing. Someone could investigate by varying up_threshold sampling_down_factor in sysfs.

>>22484
>I would be curious how your workflow looks like:
Just Ratpoison WM, Firefox ESR with 1-3 tabs and possibly Emacs for note taking. Also, I searched the web and it seems that powersave governor should always be used on semi-recent Intel hardware and conservative on AMD but the commenters didn't explain why.

Shouldn't Openbox be as good as a tiling WM too? Also I would never throttle the CPU to raise battery life because the quality of your experience is just gonna get fucked.

>>22494
>Shouldn't Openbox be as good as a tiling WM too?
Dwm is one of the lightest wm memorywise, but some stacking wms like twm, cwm come close and tinywm, wm2 and 9wm consume even less than it. Openbox is in the same class as heavier wms like awesome and i3.
>the quality of your experience is just gonna get fucked
Depends entirely on how fast a core is at the lowest frequency. When user experience degrades because of throttling, usually the cpu also takes significantly longer to idle and needs to power up more cores for the sustained workload, resulting in fewer battery savings overall.

THIS IS THE ONLY WAY TO SAVE BATTERY ENERGY:
0. manually partition the disk and make a file system on the partition(bonus points if you can create the file system on the disk directly without any partitions)
1. manually configure/build the kernel
2. manually configure init(systemV, openrc, s6, runit, dinit… all good, though I prefer systemV and openrc personally)
3. manually compile and install each package individually for the system with specific ./configure options, make options, and fully optimized flags specific for each package. who fucking needs a package manager
4. manually create all config files and symlinks on the system
5. manually create all users and all groups yourself
6. manually create all internet config files yourself
7. manually configure udev
8. manually create the virtual file systems
9. manually create the /* directories yourself (complaint to the FSH standard)
10. manually configure bootloader
11. dwm (the window manager)
12. install command-line/ncurses applications instead of using GUI
13. use startx instead of a display manager
14. buy better battery
15. get better ventilation for the notebook
16. underclock it
17. always keep notebook plugged if battery is bad or removed
18. remove the CPU backdoor(Intel IME/AMD PSP) that glows in the dark and wastes battery for the CIA agents
19. only use free software

>>22498 (me)
20. hail richard stallman
21. donate money to the FSF

>>22498
>7. manually configure udev
>not creating static device nodes
ngmi

>>22492
Jesus, couldn't they have made a more aesthetically pleasing grid? Also, isn't that super unsafe in case liquids get spilled or whatever?

I wonder if not connecting the touchpad and only using the clit will save at least some battery.

>>22501
wtf how do you do that, LFS didn't teach me that. LFS teaches udev from systemd but uses systemV
>static
something tells me that static device nodes would be worse than dynamic device nodes(100% sure it is), if devices changes on the system "by-path" I would have to configure it again unlike if it is recognized "by-id" instead of "by-path"
>ngmi
I'm almost perfect, I just need to learn a udev alternative, I will make it. what is the (better) alternative?????

>>22501
>>22511
Slow down, what is this? In English, please.

>>22512
>In English, please
alright:
https://linuxfromscratch.org/lfs/view/stable/chapter09/udev.html
https://linuxfromscratch.org/lfs/view/stable/chapter08/udev.html

>>22512
>>22513 (me)
anon >>22501 still haven't told me what is better than udev!

>>22511
>>22514
A *dev daemon creates device nodes based on default rules and hotplug events. You can create all devices manually with mknod, the difference being the presence of a device file will will not correspond to the presence of the actual device.
You can learn more in various 2000s linux forum threads and this recent one from the gentoo forums https://forums.gentoo.org/viewtopic-t-1103142.html

>>22515
No hotplug daemon also means no automount and no automatic xorg device configuration.

>>22511
>if devices changes on the system "by-path" I would have to configure it again unlike if it is recognized "by-id" instead of "by-path"
IMO the device nodes under by-id,by-uuid and by-label are unnecessary clutter. Mount accepts all of these identifiers as special arguments (see the man page). The only situation without access to mount would be booting without an initramfs and in that case you have to rely on kernel device naming or raw device numbers either way.
Xorg has its own options to access devices by ID and AFAIK it is impossible for alsa to use anything but the given soundcard IDs.

>>22515
gentoo manages to be even more hardcore than LFS I'm impressed, gonna take a look at making device nodes with mknod(and make rules files and etc) but I'll probably stick with udev(even current gentoo uses it, since they dropped eudev in favor of udev)

but if I really wanted to escape everything related to systemd then static /dev may be the only way out but I feel like dynamic nodes are better than static nodes I think

though I can't help it but it feels like udev is evil, I think I'll do a static /dev gentoo either on a VM or on my gentoo

>>22516
hardcore
>>22517
I just feel like by-id is safer than by-path, it may be clutter but a very convenient clutter

>>22518
>I just feel like by-id is safer than by-path
No, i mean you can just write ID=device-id or UUID=device-uuid in fstab or as a mount argument and it will access the device without any elaborate hierarchies in /dev.

>>22518
>gentoo manages to be even more hardcore than LFS
LFS is essentially one linux toolchain that can bootstrap one type of linux environment. For a different approach see http://jfxpt.com/2019/gales-linux-initial-release/
The system uses gcc 4.7.4, the last version without C++, busybox, daemontools and an init that is 47 lines of C. It has a very cool install medium, where the initramfs contains all files necessary for installation needing only a boot partition.

>>22519
oh lol now I understand, forgot fstab could be used that way, guess I should use that when I make a static /dev gentoo or use an alternative to udev on gentoo

>>22520
feels like gales is static everything(even libraries lol). wait it is lol I'm impressed lol

>>22522
/bin only contains dynamic links :^)

>>22523
/bin , /lib and /sbin are not real

>>22524
/bin is real on gales, /sbin links to /bin and /usr links to /. Links to the actual commands are copied from a package hierarchy similar to gobolinux stow. If linux had a proper union mount implementation, the package/bin/s could be be mounted to /bin though.

You can also use mdev or mdevd for managing /dev
Alpine Linux supports both and also udev.

>>22494
>Shouldn't Openbox be as good as a tiling WM too?
Yes. But, as far as I know, OpenBox development has stalled. I think IceWM is still being developed (it's very similar WM). There is also JWM.

Consider switching to Wayland. During the early days of Wayland, so much focus was on embedded and low power devices, where X is an absolute train wreck, and Wayland is now undisputed king.
Taking that mentality forward has real advantages for anything battery powered, like a laptop.

https://www.phoronix.com/news/KDE-Plasma-Wayland-Power