Protecting my sleep

My another attempt to break the habit of being up until very late into the night and as such very tired the next day.

For years I thought of configuring my computer to suspend at around night time so I will be somehow forced to go to sleep. Well, the main problem with this was that I only thought about it and never actually did any research on this subject.

At normal times under my normal user I suspend my machine with elogind loginctl command and this works fine but there might be a problem with sessions and stuff around that which I refuse to work with. So I searched a bit and found out that there is nice system API to manage power state.

The system/kernel API consist of a file located at /sys/power/state.
When I try to print the content of this file it shows the currently available states (or values it accepts) which is my case are:

$ cat /sys/power/state
freeze mem disk

And when I looked at the printed values I saw mem option which is probably what I want (I was lazy and did not look at any docs) to suspend my machine into RAM. The power state can be changed by writing desired state into /sys/power/state file.

$ echo "mem" > /sys/power/state

Sure, you need to be root to do so, but so what? This is my machine and I can. Since I figured this out I put it into a file, set it executable and configured cron to start it at 23:00 from Sunday to Thursday like this.

0 23 * * 0-4 root /usr/scripts/suspend

And done, now I hope it can help me get my desired rest.

Articles from blogs I follow:

Agentic test processes, LLM benchmarks, and other notes on agentic coding from Galapagos Island

I've been using AI fairly heavily since last November and the whole thing is a funny experience. An agent will do something that, if a human did it, you'd immediately fire them. My reaction, of course, is to act as if this is great and spin up a t…

via danluu.com July 3, 2026

Stop telling people to sanitize user input

Whether you're dealing with a web application or some other application, all user input should always be considered "hostile" and "dangerous", but you should not just universally sanitize user input.

via Unix Digest - Articles March 7, 2026

GPG Update 2026

A recent toot of mine got the response “friends don’t let friends use GPG” which, I suppose, is true enough. It certainly isn’t the attestation-friendly thing to use, and the opsec failures that are so easy with GPG-encrypted mail make it a hazard there. …

via [bobulate] February 3, 2026

Generated by openring