Yonle

I have one funny reason that still keeps me up doing it despite being a bit lazy.

I encountered a problem that has no optional fix around it that i wanted so i had to create one to solve the damn problem in any way myself. To be frank, i moved on and had a burnout a lot, but even so, i still began to create another kind of tool for myself, and if that still interests me, i often try to maintain it.

the thing is that, open source or foss stuff is not really my first passion to begin with when the first time i managed to code stuff by myself (that was before chatgpt even existed, god lord!)

and to this day, even though it seems like that i contribute to the open source / foss spaces with my own code being published for free, i wasn't here to contribute to the environment actually. i simply made a tool, once found it usable for myself, i simply share it as both archival/preservation and for other to be able to use my thing. because i do not like it when the thing that i code wasn't being used by anyone other than myself.

i might looked like helping some project by sending PR to them to fix certain bug, I might do helping them, yes. But the initial idea is still pretty much because i use their thing, and their thing is problematic, then finally it's technically resolveable, and somehow that's the healthier position for me.

Thing is, i liked creating and then expecting people to use it.

Because i do not like making a project that had no user.

and because i want to have people use my tools, i tend to make some of my projects flexible and controllable while still being easy to use.

for example, vsink, a project of mine that does some stuff with virtual pulseaudio sink, have these options:

$ vsink -help
Usage of vsink:
  -bypass string
    	Comma-separated application names to bypass capture
  -defaultSinkMode
    	Set the virtual sink as default sink. May help with some apps, but can cause issues with volume control.
  -monitor string
    	Comma-separated application names whose recordings should use the capture sink monitor
  -noLoopback
    	Disable loopback. Any app in the virtual sink will not be played back to the main speaker (except bypassed apps)
  -onlyCapture string
    	Comma-separated application names to exclusively capture into the capture sink
  -vSinkName string
    	The name of the virtual sink (default "SystemCaptureSink")

also, go-bwhero, an image compressor/thumbnailer proxy have these options:

$ ./go-bwhero -help
2026/08/20 13:28:14 bwhero, rewritten backend.
Usage of ./go-bwhero:
  -animSizeLimit int
    	Original animation size limit in bytes (default -1)
  -imgSizeLimit int
    	Original image size limit in bytes (default -1)
  -listen string
    	Listen address (default "localhost:8080")
  -userAgent string
    	User agent that go-bwhero should use. (default "Mozilla/5.0; go-bwhero [https://github.com/Yonle/bwhero]")
  -videoSizeLimit int
    	Original video size limit in bytes (default -1)
  -vipsConcurrencyLevel int
    	libvips concurrency level to use
  -workers int
    	Amount of workers to spawn (default 8)

and the most obvious one, unlockata, a tool for doing ATA security on ATA storage drives, have these options too:

$ unlockata -help
Usage of unlockata:
  -device string
    	ATA device ("list" to list ATA devices)
  -master
    	use the ATA master password instead of the user password
  -maximum
    	use maximum security level
  -noreadpart
    	do not reread the partition table after the ATA command
  -op string
    	ATA security operation ("help" to list supported operations) (default "unlock")
  -passwd string
    	Path to 32-byte binary password file
  -serial string
    	ATA device serial number ("list" to list ATA devices)
  -verbose
    	show CDB and Payload bytes being transmitted to the ATA drive.

$ unlockata -device test -op help
Available ATA security operations:
  set              SECURITY SET PASSWORD (0xf1)
  unlock           SECURITY UNLOCK (0xf2)
  freeze           SECURITY FREEZE LOCK (0xf5)
  erase            SECURITY ERASE UNIT (0xf4)
  erase-prepare    SECURITY ERASE PREPARE (0xf3)
  disable          SECURITY DISABLE PASSWORD (0xf6)

from there you can really see which part i really tried my best to convince people to use it in the most indirect way possible.

---

despite all of that, i do have one very common problem though. if the tool that i create already has a perfect code that then i had no idea what to add or what to fix let alone improve, most of the times, these became pretty much a stall,

which is funnily what happened with most of my go projects. but i don't think i should worry these though given how safe go already is (compared to javascript, heh)

well. with all that being said, now you know why i'm still around and still interested experimenting random things.

but yes. the fact that i use go is deadly for everyone.

cuz i have no longer need to suffer through python, node, c, c++, c##, lua, perl, java, erlang, or even rust problems just to fight one problem