Is this vibe coded or is it just the readme that's AI-generated?
I was skeptical at first, but this does stink of auto-generated code. I want to believe it is not.
Show HN: A fast, dependency-free traceroute implementation in pure C
11–20 of 34 posts
Re: Show HN: A fast, dependency-free traceroute implementation in pure C
#12I take issue with the Author section. You’re the only one listed. Shouldn’t you give ChatGPT credit, or even further afield, all the developers who wrote the code and answers that ChatGPT trained on to produce this, as far as I can tell, meaningless tool?
ChatGPT isn't an author, so it shouldn't be listed. Instead, every single piece of human creation that's been sloshed and slurried to produce this drab drivel should be put as authors. That would be fair.
If FSF trained a net on all the code that has Copyright assigned to FSF, could it be used to ethically vibe code free software retaining the same Copyright and license? Perhaps even pointing to a file on fsf.org with all the author's names?
Re: Show HN: A fast, dependency-free traceroute implementation in pure C
#13It used to be that if someone released a tool that's 700 lines of C, they probably had an actual need and a problem they solved by writing that code because debugging even that amount of C tends to be non-trivial. Today all bets are off. Does the tool do anything anybody needed? Does it work? Who knows. It might just be 700 lines of convincing-looking C churned out by a model.
Well I was surprised that it actually makes use of "-Wall -Wextra" as good practice.
However both PVS-Studio and clang-tidy have a few complaints about the code, since it is a single file, it is rather easy to try out on Compiler Explorer.
https://godbolt.org/z/n4M1vGccq
As for your remark, most folks seem to have not followed that C authors also created lint in 1979, Dennis Ritchie proposed fat pointers to WG14, Plan9 was going to use Alef, which failed but its ideas were re-used for Limbo on Inferno, and they were also involved with Go.
Finally Rust's borrow checker ideas steam from AT&T research with Cyclone, as way to create a safe C.
As such the real question is why still use C in new projects, when even the language authors have moved beyond it, or at least reduce their use of it on userspace applications.
Re: Show HN: A fast, dependency-free traceroute implementation in pure C
#14Honest question: why would this code clamp the reported round-trip time? By default, min = 0.05 ms and max = 800 ms [1]. if (rtt config.max_rtt) rtt = config.max_rtt; Wouldn't this hide bugs in the code or network anomalies? Replies from localhost seem to typically arrive in less than 50 µs. Comments in an earlier version [2] make no sense to me: /* Use standard timersub for more accurate results */ if (rtt 1000) rtt…
[deleted]
Re: Show HN: A fast, dependency-free traceroute implementation in pure C
#15It used to be that if someone released a tool that's 700 lines of C, they probably had an actual need and a problem they solved by writing that code because debugging even that amount of C tends to be non-trivial. Today all bets are off. Does the tool do anything anybody needed? Does it work? Who knows. It might just be 700 lines of convincing-looking C churned out by a model.
Well I was surprised that it actually makes use of "-Wall -Wextra" as good practice. However both PVS-Studio and clang-tidy have a few complaints about the code, since it is a single file, it is rather easy to try out on Compiler Explorer. https://godbolt.org/z/n4M1vGccq As for your remark, most folks seem to have not followed that C authors also created lint in 1979, Dennis Ritchie proposed fat pointers to WG14, Pla…
We live in a world where now using "-Wall -Wextra" is a positive outlier. :D God damn. I have ALWAYS used these options, along with "-pedantic", "-std=c99" and so forth.
Re: Show HN: A fast, dependency-free traceroute implementation in pure C
#16Even if it's simple or AI-made, projects like this still help people learn and explore, every start matters.
Re: Show HN: A fast, dependency-free traceroute implementation in pure C
#17It used to be that if someone released a tool that's 700 lines of C, they probably had an actual need and a problem they solved by writing that code because debugging even that amount of C tends to be non-trivial. Today all bets are off. Does the tool do anything anybody needed? Does it work? Who knows. It might just be 700 lines of convincing-looking C churned out by a model.
It could be a vehicle to learn about traceroute / ICMP.
For whom? What is the creator going to learn from pasting code they've never read? What are readers going to learn from reading code the "author" themselves didn't read, let alone write? If you want to learn about something, reading an LLM-generated repo seems to be about the worst possible way to do it. That's not even to say LLMs are useless for learning; you could ask directly about concepts without having it write all the code for you, but this is the lowest effort application of the tool and is more of a vehicle for anti-learning than anything.
Re: Show HN: A fast, dependency-free traceroute implementation in pure C
#18Earlier quoted context omitted.
Well I was surprised that it actually makes use of "-Wall -Wextra" as good practice. However both PVS-Studio and clang-tidy have a few complaints about the code, since it is a single file, it is rather easy to try out on Compiler Explorer. https://godbolt.org/z/n4M1vGccq As for your remark, most folks seem to have not followed that C authors also created lint in 1979, Dennis Ritchie proposed fat pointers to WG14, Pla…
We live in a world where now using "-Wall -Wextra" is a positive outlier. :D God damn. I have ALWAYS used these options, along with "-pedantic", "-std=c99" and so forth.
I picked up C for fun last year and this is exactly the flags I have always used by default. Can't remember where I picked that up, but glad to hear I'm doing it right
Re: Show HN: A fast, dependency-free traceroute implementation in pure C
#19Honest question: why would this code clamp the reported round-trip time? By default, min = 0.05 ms and max = 800 ms [1]. if (rtt config.max_rtt) rtt = config.max_rtt; Wouldn't this hide bugs in the code or network anomalies? Replies from localhost seem to typically arrive in less than 50 µs. Comments in an earlier version [2] make no sense to me: /* Use standard timersub for more accurate results */ if (rtt 1000) rtt…
Because it's AI generated.
Re: Show HN: A fast, dependency-free traceroute implementation in pure C
#20Earlier quoted context omitted.
We live in a world where now using "-Wall -Wextra" is a positive outlier. :D God damn. I have ALWAYS used these options, along with "-pedantic", "-std=c99" and so forth.
I picked up C for fun last year and this is exactly the flags I have always used by default. Can't remember where I picked that up, but glad to hear I'm doing it right
[deleted]