#techpost

2025-12-17

**GitHub - doobiusP/cmexl**: Công cụ CLI xây dựng dự án CMake và template module linh hoạt, hỗ trợ pipeline full (from cấu hình đến đóng gói), tích hợp vcpkg, quản lý component riêng biệt, và cấu hình module linh hoạt. Dự án side project giúp tác giả học sâu về CMake & Go. 🚀 Học hỏi & chia sẻ kinh nghiệm về hệ thống build!

#CMake #OpenSource #SideProject #ViệcHọc #LậpTrình #GitHub #DevTools #MãMở #CôngCụPhátTriển #HọcCMake #ViệcSide #TechPost #DevLife #Cplusplus #Golang #Vcpkg #CMakeTool #Co

Paul SomeoneElsepkw@snac.d34d.net
2025-11-24
#techpost

I like the idea of chasing uptimes, because it sits in stark contrast
to the need to update update update everything all the time.

I updated my kobo and regretted it, because I forgot that updates
aren't always (especially from corp.) for things that help me as the
user.
Paul SomeoneElsepkw@snac.d34d.net
2025-11-06
#techpost

I don't know if zig is it.
The C interop isn't as easy as purported, and that's the basis
for wanting to use it.

Like for me maybe having Tcl drive C code would be better
in almost every area I would use zig.

I should look at hare again maybe.
Last time I looked into hare I wasn't as deep into C
as I am, so my perspective might have changed.

I have a problem with not being happy with a programming language.
But actually in a way this recently has made me a little more
happy in C.

Paul SomeoneElsepkw@snac.d34d.net
2025-11-05
#techpost

I have decided that hardcoding the interpreter path at the top of a script is fine, BECAUSE
it's a convienience to calling the script like:
<script-interpreter> <script-name>
Convieniences are not where you standardize things.

This is about saying I don't like 'env' as a standard to put
at the top of shell scripts

$!/usr/bin/env <script interpreter>

echo "this is bad"

[grenade pin pulled sound]

Paul SomeoneElsepkw@snac.d34d.net
2025-11-02
I'm writing expect scripts like a boss.
As I've waxed poetic before, I think Tcl is a very great programming
language.

It's interesting doing expect, because it's so antithetical to most typical
good programming practices, yet it is sooo new jersey correct.

#techpost

Paul SomeoneElsepkw@snac.d34d.net
2025-10-25
#techpost #C

I really like C and have really leveled up in it.

One of the downsides of C is no namespacing.
But one of my lessons from learning lots of programming languages is
that you can take a good thing from one language and apply it
to another even if it doesn't support it. Typically by adopting
some convention. For example C figuratively does have namespaces
if you are diligent about naming files and functions.

Anyways one of my patterns that I like is that I use a make target like
this:


\#makefile target to copy in lib files
libs:
cp ../libs/log/log.[ch] .

I have a repo of basic C stuff like file handling and binary math
stuff called "libs". I also have one called "learn". The distinction
is that "libs" is stuff I might re-use, where "learn" is stuff
(like pointer math) that is more of a reference.

So I like this pattern of copying in files from another repo.
And then I just add them to whatever repo locally. It's cool because
it lends itself to developing those libs further in either place.
Like I can re-run that make target to get new changes to
those files, and because they are in git locally, I can see what's
changed. And I can copy the files back to "libs" if the changes
are local. This is a compromise, but very good, especially
since I am learning, so I enjoy the development churn.

Like if I update some code in "libs" it might break something
where I am "importing" it, but then I just fix that up and
commit it all. It's like I don't have to remember, to do
something, because the code breaking will notify me :)


Paul SomeoneElsepkw@snac.d34d.net
2025-10-20
#techpost

I want to write a C program that does the double fork unix thing.
I feel like that is something that would make me a better person.
But it's so fiddly :P
And then of course I need to add socket handling to talk to it.
(sockets are also very fiddly :P)

#C

#OpenBSD
Paul SomeoneElsepkw@snac.d34d.net
2025-10-20
#techpost

Lisp predates python with meaningful white space, because the
atom separator syntax is white space.

This is not a serious thought.
Paul SomeoneElsepkw@snac.d34d.net
2025-10-19
#techpost

Choose OpenBSD if you are migrating from windows and thinking about linux.
It is easier and it makes more sense.

This is my deep wisdom. The many choices of linux is not a feature, especially
to new people. And the OS itself is more complicated to use.


People that use linux because it does specific things for them are obviously,
i hope, not the target of this message. The many choices of linux is good
in the sense it is broadly compatible with things.
Like if you are going to trawl thru a bunch of drives to see what you
have and grab data ... linux* is probably the best.
(but you still have to choose one ...)
Paul SomeoneElsepkw@snac.d34d.net
2025-10-05
#techpost #C

This helps me understand C's "extern":
extern is implicit in C's function declarations.

Paul SomeoneElsepkw@snac.d34d.net
2025-10-01
#techpost #SDL3 #C

This sprite image stuff is SOOO FIDDLY!

I mean it makes sense, and I think it's a great idea, but so fiddly.

I should put the code on codeberg, I'm write a C struct sprite that abstracts
an arbitrary multi-sprite sprite file. The only constraint is that the image must
be cut into squares of equal size.
(Which it seems is how sprites files work, except I bet I will find ones
where the individual sprites are not all the same dimension.)

SO like I instantiate a sprite with an image file. (and the relevant SDL3 renderer
texture and surfaces needed, but that's more bookeeping just to draw them to
the screen)


/* the important params are the image file, and the image dimensions, and dimension of each sprite */
struct sprite_sprite * sprite1 = NULL;
sprite1 = sprite_make_sprite([...sdl-stuff...], "media/image-file.png", 700, 400, 16, 16);

Then I can draw it with:


/* 3, 7 is row and column */
sprite_render(sprite1, 3, 7);



So the virtual row and column gets turned into the actual coordinates to
sub-index into in the sprite file.


Currently I have one good sprite file that has walls, players, monsters, ... etc. in it.
So my program will just have one instance of struct sprite_sprite * like above.

This seems like a decent trade-off (so far) between convienience and over-engineering.

I like how C makes this stuff harder, but in a good way. Because it feels good to struggle
through this stuff and think about it.

Like I am imagining that the better designs that it forces on me would also be better
in a higher level language. For example, lots of times I worked with python devs that knew the cost of
nothing. [0]


[0] yeah that's the lisp saying applied to python.
Paul SomeoneElsepkw@snac.d34d.net
2025-09-29
#techpost

I'm straying from my C deep dive.
I don't want to because I have a good base SDL3 setup going
with sound and keyboard input.
(Which translates to gamepad input too, because that's basically what SDL is.)

I started doing golang and I already am lost interest.
That's OK because I just needed a refresher, I am really comfortable with go.

So I'm sorta thinking do the SDL3 game thing but have it talk to a
server made with common lisp. It would make sense to NOT make a
game state/multiplayer server with C.

(Because:
1. The server, unlike the clients can be assumed to be NOT
overly resource constrained.
and 2. Since we already have internet latency there is no
reason to use C for the speed/latency.)

* I could use common-lisp to driver SDL3 with cffi, but then
it would be harder to get it to run on every device.
Paul SomeoneElsepkw@snac.d34d.net
2025-09-27
#techpost

I'm digging out my openbox window manager config.
I was a big fan of blackbox to fluxbox to openbox

(i think that was the order)

Since I have a newish laptop I want to run the gkrellm stuff
and other WM apps in the dock.

It's fun so far, most of my keybinding finger memory still works,
probably because this is where I got it from.
(Like my CWM virtual screen switching is pulled from this originally.)

#openbox #blackbox #fluxbox
Paul SomeoneElsepkw@snac.d34d.net
2025-09-23
#cringy #techpost

Hot take using hot words.

AI is just the same shitty software computer ecosystem reified into something with
a different name.

TLDR: We never "got good" with computers and software in "industry".
And normies don't know that. Many "programmers" don't know that.

Case in point javascript and NPM being taken seriously with no reservations.
Server side javascript ...

TLDR for me is that I shouldn't pay heed to the marketing of it. Let them spoil
the word AI. It's fine, it's just a word, let them have all of the words.

Is this profound or obvious?
Paul SomeoneElsepkw@snac.d34d.net
2025-09-22
#techpost

A firefox "1" style browser. With html5.
And built in WASM bindings and no javascript.

I'm ambivalent about CSS level support.

Desktop first, just because it's tractable by mortals.
IOW mobile platforms are not something that mortals can
build w/o the support of BIG CORP.

But if you built something for the desktop that worked
for a small but reasonable number of enthusiasts, then
BIG CORP would make it work with their stack. (mobile)

I think there is a LOT of developers like me just aching
and thirsting for a platform they can get behind and build
stuff w/o thinking they are wasting their time on a tech stack
that they don't really like. [0]

The browser would be in C. Not rust. But that should not matter,
because it's WASM right ...
You build apps by using html/css UI and whatever language you
want that has WASM support (i'm sure rust has this)


[0] And could get rug pulled at anytime.

Paul SomeoneElsepkw@snac.d34d.net
2025-09-15
#techpost

Installing git for windows is the quickest best way to get a terminal onto windows that can do stuff. (like ssh and scp)
Paul SomeoneElsepkw@snac.d34d.net
2025-09-13
member using kernel.org to test internet speed ?

#techpost
Paul SomeoneElsepkw@snac.d34d.net
2025-09-05
#techpost

It's annoying when people standardize on bash.
language features are not why shell scripts are used.
The clearly dominant trait of shell scripts is easily
running everywhere.

bourne and bash are not good languages. bash doesn't make
bourne better like c++ doesn't make c better.

Use a different language if language quality is more important
than running everywhere.

Like if you are gonna use bash because you need arrays
or something, then just use perl. perl is more ubiquitous
than bash (where it matters). \-- i added that for safety :P

Paul SomeoneElsepkw@snac.d34d.net
2025-08-14
#techpost

I am very pleased with myself ...

I am speedrunning this C course and there is a "robot" exercise.

You have to implement the robot turning right and then the robot turning left.
This turning happens on the four compass axises N S E W.

I implemented the code for turn left...

And then instantly w/o thinking just called "turn left"
three times in the implementation for the code that turns right :P

I have a stupid programming joke ...

Two wrongs don't make a right, but three lefts do.

lalalala it's so stupid but very funny to me :P

Paul SomeoneElsepkw@snac.d34d.net
2025-08-08
#OpenBSD

#techpost

One of my problems with using relayd for tls is that I lose the origin IP in my httpd logs.

(background:)
I am adding IPs to my PF blocklist because I don't like my server getting spidered/crawled.
Specifically repeatedly hitting dynamic links that are not valid.

So I find the bad hit in my httpd log, and then use the time stamp to find
the origin IP in the relayd log.

I can probably add more info to either the httpd log or the relayd log
to mitigate this. Or I can script some tools to help me.

I was meaning to script some log stuff anyways just to get an idea
of how often it happens. Also writing helper code to look for
stuff in log files is fun for me. I was thinking for ease I would wait
until they "roll" and access the .gz versions. Then I don't have to
do "last line accessed" kind of record keeping. But I am more thinking
I WILL access the live logs, because doing that "last line accessed"
record keeping is also a fun exercise.

Client Info

Server: https://mastodon.social
Version: 2025.07
Repository: https://github.com/cyevgeniy/lmst