Hey everyone, I wrote this tool for inspecting linux signals across proceses
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
92% Positive
Analyzed from 803 words in the discussion.
Trending Topics
#software#project#code#before#control#didn#don#consider#life#tool
Discussion (13 Comments)Read Original on HackerNews
With the first and only commit 2 hours ago, the author of this project didn't let it "bake". They didn't exercise it locally to see what issues it might have, and I have a hard time believing the very first iteration of this software is perfect. With how easy it is to prompt/push anything, I'm not interested in engaging with anything that hasn't aged a bit.
You have no idea whatsoever how many iterations were done before the initial commit. The VCS log is not representative of anything that happened before the first public release. Even before LLMs, people would grind away on stuff until they were happy and then put it in a VCS for public consumption.
I won't begrudge anyone who feels like it's too big a risk to engage with just yet.
Sigh. We shouldn’t have modeled signal handling in a cross-platform, lowest-common-denominator way in HLLs. Signals have way less in common across OSes than files/sockets and the like.
Anyway, rant over. Not much to be done about it now.
> Hey everyone, I wrote this tool...
Hey there. And yes, I don't you believe it's you who "wrote" it (where even the Readme file seems to be generated), nor you have experience enough in the so crucial subjects raised, to invest my own life time in the project, too, sorry.
I'll better consider projects where actual effort and human was involved believing in their art, knowledge, and experience of life they express in their actual, authentic, and accountable work.
This tool was built on top of our engine: yeetd.
We put a lot of work into abstracting BPF into a JavaScript framework to give builders, human or agentic, the ability to use complex kernel primitives with a familiar programming model to build production grade, scalable infrastructure tools.
Our hope is that everyone here will soon be able to build their own tools on-demand, versus buying them.
We separate a lot of the data layer code from the presentation-level code, to make them re-usable and keep the test surface on the actual data's accuracy manageable across all the random edge cases that arise across CPU architectures, kernel versions, and environments like AWS ECS network namespace voo-doo.
As an aside, I've been vibe-cooking for a few months on a personal project that's accomplished something lovely. For me. I sometimes wonder if I should give it away much like this project. But public reactions like yours temper the thought.
[1] https://yeet.cx/
Let me project it back at you; neighbors I sit around the fire pit with having beers talk of how sick of "software people" they are as we over complicated the world.
Everyone else happy to move on regardless of how it impacts software engineers same as software engineers ignored their work upended careers of others.
Of all the skills I have; learning from Michelin chefs, to playing multiple musical instruments, to hardware and software engineering; the only people who care about the eng skills are rich people who want to exploit my labor then lay me off.
As you requested; software devs are being held accountable for the role they had in ending others gigs. Call the waaaahmbulance.
This applied to most of my side projects before AI. Most of them I would never touch again.
Thanks to AI I'm working on them way more, and at a much higher level of engineering standards (especially the recent models are voluntarily adding tests, looking for bugs etc.).
(Well, except for the part about barely reading the code, but I said higher, not high!)
Also I realized the other day that I already reached the point where I don't understand my own code, several years before involving AI in the process!
I don't know if I'm an outlier but I thought that was pretty funny.