Most of my posts are about shell scripting and messaging-based architectures. I wrote a small module framework for Bash that allows you to send messages (point-to-point and pub-sub) between scripts, so I'm doing a small series about enterprise integration patterns in Bash.
I'm planning to cover some of my other projects (embedded, hardware, baking -- everything I do is pretty low-level) once I get around to it.
Let's be honest, "you can change what you want" should really be "you will have to change certain things". Which is fine for developery people and people with a lot of time and patience on their hands. But for the overwhelming majority, even fiddling with the contents of /etc or $HOME/.whatever is too much of a hurdle.
People don't choose Windows or Mac despite not being able to change things, they choose it so they don't have to change things.
And let's not forget that, eventually, "you can change what you want" becomes "you have to change what you want" because the developers of your distro / desktop environment / window manager / UI toolkit decide to change the default behavior (if they don't change the entire thing).
I don't understand? What are these things you have to change?
Your second paragraph mentions changing defaults. Of course software evolves over the decades. You may not like every change, but evolving along is always an option, of you don't want to tinker. Also, most UI config is stored in dotfiles. Upgrading doesn't apply the new defaults to an existing account.
A long time ago, I attempted to reverse-engineer the protocol of a game because I wanted to host a dedicated server on a Linux box, but the developers only provided a (bug-infested) Windows version. That's how I found this treasure trove of game-related PoCs and reverse-engineering knowledge.
Thanks! I didn't realize it's been almost a year already.
I decided very recently to publish this project on Github and write about it here, so documentation has not been a top priority. While writing about it, I realized that documentation will crucial though, so it is at the top of my list now (I was even pondering whether I should postpone posting on HN until the documentation is done).
I would have expected an article like this to discuss the different CPUfreq scaling governors, especially since it recommends switching to acpi_cpufreq, which allows them to be adjusted more freely than intel_pstate. I have doubts about switching to acpi_cpufreq though, especially when you're going to use it with ondemand.
But either way the author never actually measures battery life, so its impossible to tell if any of the things mentioned had any impact at all (a screenshot doesn't tell anything about the actual battery life).
Is it this one?