bleistift2

joined 8 months ago
[–] bleistift2@sopuli.xyz 20 points 2 days ago* (last edited 2 days ago) (1 children)

What you deserve for not voting democrat.

I guess the Palestinians should’ve voted democrat, too.

[–] bleistift2@sopuli.xyz 73 points 2 days ago (4 children)

What a high it was when I did titration in high school and managed to get so close that the liquid appeared colorless unless you held a white sheet of paper next to it.

It was tinted, but just barely.

[–] bleistift2@sopuli.xyz 9 points 2 days ago* (last edited 2 days ago)

Rick and Morty, season 4, episode 7, “Promortyus”

[–] bleistift2@sopuli.xyz 13 points 2 days ago

You’re absolutely right. In my mind “feature parity” got garbled into “backwards compatibility”.

[–] bleistift2@sopuli.xyz 25 points 2 days ago

Email to all:

“Due to budget constraints, resources will shift from $oldThingy to $newThingy. As a result, $oldThingy’s availability can no longer be maintained at the previous level.”

Then randomly kill oldThingy for more and more hours each day.

[–] bleistift2@sopuli.xyz 20 points 2 days ago (5 children)
location /old_api {
  redirect /new_api
}

(can’t be bothered to check the syntax).

[–] bleistift2@sopuli.xyz 32 points 2 days ago

“The other 98% of the codebase.”

[–] bleistift2@sopuli.xyz 8 points 2 days ago* (last edited 2 days ago)

Nitpick: There are elevators which are fine to use in case of fire. They have protections against serving as a chimney and somehow ensure that the passengers have air to breathe.

I’ve never seen one, though.

[–] bleistift2@sopuli.xyz 2 points 3 days ago

Meanwhile I’m squashing spiders that are already dead, just to be sure.

[–] bleistift2@sopuli.xyz 14 points 1 week ago (4 children)

Each their own or is there some partnership thingy going on? Or weekly rotations?

Or is it one big mandatory circular anus-washing meeting ‘to get to know each other’?

[–] bleistift2@sopuli.xyz 2 points 1 week ago

One of the Ursas could have been The Game of Ur

https://en.wikipedia.org/wiki/Royal_Game_of_Ur

 
 

First, some context.

I’ve written a program that starts running when I log on and produces data every two seconds. This daemon keeps all the collected data in memory until it gets terminated (usually when I shutdown the system), when it will dump the collected data to a file on disk.

(These are questionable design decisions, I know, but not the point of this post. Though feel free to comment on them, anyway).

I’ve written another program that reads the data file and graphs it. To get the most current data, I can send the USR1 signal to the daemon, which causes it to dump its data immediately. After restarting the renderer, I can analyze the most current data.

The tech (pregnant women and those faint of heart, be warned)

  • The daemon is written in TypeScript and executed through a on-the-fly transpiler in Node.
  • The data file is just a boring JSON dump.
  • systemd is in charge of starting and stopping the daemon
  • The renderer is a static web page served via a python3 server that uses compiled TypeScript to draw pretty lines on the screen via a charting library.
  • All runs on Linux. Mint, to be specific.

As I’m looking for general ideas for my problem, you are free to ignore the specifics of that tech stack and pretend everything was written in Rust.

Now to the question.

I would like to get rid of the manual sending of the signal and refreshing the web page. I would like your opinions on how to go about this. The aim is to start the web server serving the drawing code and have each data point appear as it is generated by the daemon.

My own idea (feel free to ignore)

My first intuition about this was to have the daemon send its data through a Unix pipe. Using a web server, I could then forward these messages through a WebSocket to the renderer frontend. However, it’s not guaranteed that the renderer will ever start, so a lot of messages would queue up in that pipe – if that is even possible; haven’t researched that yet.

I’d need a way for the web server to inform the daemon to start writing its data to a socket, and also a way to stop these messages. How do I do that?

I could include the web server that serves the renderer in the daemon process. That would eliminate the need for IPC. However, I’m not sure if that isn’t too much mixing of concerns. I would like to have the code that produces the data to be as small as possible, so I can be reasonably confident that it’s capable of running in the background for an extended period of time without crashing.

Another way would be to use signals like I did for the dumping of data. The web server could send, for instance, USR2 to make the daemon write its data to a pipe. But This scenario doesn’t scale well – what if I want to deliver different kinds of messages to the daemon? There are only so many signals.

 
 
178
submitted 1 month ago* (last edited 1 month ago) by bleistift2@sopuli.xyz to c/programmer_humor@programming.dev
 

[Meme transcription:]

– Hey, why is the shell prompt on the production server red now?
– Earlier: me@prod:~$ docker container remove --force the-application

Protip: If you’re used to shutting down your computer via the CLI, make it a habit to use an alias like off.

This way you will never, ever turn off a remote server by accidentally using throwing poweroff at a residual SSH connection.

455
IEEE 754 (cdn.fosstodon.org)
 

cross-posted from: https://lemmy.ml/post/24332731

~~Stolen~~ Cross-posted from here: https://fosstodon.org/@foo/113731569632505985

 
 
265
submitted 1 month ago* (last edited 1 month ago) by bleistift2@sopuli.xyz to c/programmer_humor@programming.dev
 
 

Image transcription: A lengthy source code comment. The details are irrelevant. Github Copilot autocompletes: “This is a bit of a hack, but it works.”

 
 
view more: next ›