Edit: As pointed out by doakes [1], the project is built by a 13 year old. With that context, I want to preface my original comment by congratulating TheGoodDuck on this project. What follows is criticism, but also do not take it too harshly. These are things I'd expect a developer with experience to know, but not a junior. As you might gather, the issues are even common among seasoned developers. So take the comments as a learning opportunity and remember that criticism of a work is not a criticism of you. These are also soft skills which are often not explicitly taught, but critical to growing as an engineer/developer. If you're doing this at this age and you keep up the work and dedication, you will be a force to reckon with in no time. I am not editing my original comment as this is how I would talk peer to peer and you're a peer ;) But I also wanted to give this context and preface because the style of language is a bit strong. Also note that these issues are very solvable and solving them will make your project even better.
The comments are there to help you improve, not to put you down.
---------------------------------------
You're not alone. Even worse when it is a product page. Just how often I see some product or project and are unable to actually determine what the thing does or why I would want to use it or even HOW to use it.
I can give GitHub projects a pass when someone else links them, but the poster is the author so no pass. This is "Show HN". Please __show__. I do like to try out new projects and tools, but where's the hook?
Also, do not underestimate the importance of documentation. Hell, I document predominantly for myself. I know I'm not alone in forgetting how things work if I haven't touched a project in awhile (which can even be going to lunch on bad days). This is also critical for any users. Encourage them to add docs, make it easy, and when addressing issues recognize that just because it is in the docs does not mean it's interpretable from user context.
If you want to demonstrate a CLI or TUI tool, a common helper is asciinema[0]. You can record your terminal and they'll host the output for you. You'll frequently see these on GitHub and even a 10 second video that is clunky/slow with key presses (or way too fast) is better than nothing. UIs matter and aren't as simple/obvious as many think.
Also, drop a license file in there. Not just a line in your README. Come on, GitHub even hands these files to you so it is the same work to write in your README as it is to drop that file in (though you should always mod those licenses headers to be about you and your project). Without the license file, your license is ambiguous and may not actually protect your project as intended. The full text needs to exist.
No worries, you're all good. Getting the experience to understand expected norms takes time. Just not that often you see such a young developer on the front page of HN, and especially without mention of age in the title.
And just remember: never fear pushing back (even against seniors) and never confuse criticism about your work with an attack on you as a person. I mean all our code is shit. If a year from now you don't look back at your code and think "this is shit" then it probably means you are no longer improving (conversely if you are feeling discouraged and like you're getting nowhere, go back and look at your old code because it makes the improvements rather obvious lol).
Good luck. Keep it up and you'll do great. So don't stress and don't forget to have fun (very common mistake, especially by adults)
Talking about my shit code: https://github.com/thegoodduck/winternet_social Its a social media framework is started builiding maybe 6 months ago now i look at it its just such a mess... I will need to refactor it... It was time when i was working directly on prod server(even on fridays) and occasinally a bug would make the server go down :-)
FYI: If you can access the website on your phone (I'm assuming you can since you made this comment), you can make small edits like this from there. Navigate to your repo, click on the ".gitignore" file, select the 3 dots to the right, and click "edit in place". You can then add the line and make the commit. But note that this will not remove the __pycache__ file from the repo, though you can also perform that from your browser through a similar process.
I just tried termshark a couple weeks ago. It _was_ just like wireshark, which was nice. However:
* There's a "screensaver" which activates after a couple seconds and requires extra button presses to get back to real data
* In several sessions the TUI output got corrupt
* It has problems with remembering field expansion - I'd expand one field and it'd expand all the other fields after a second delay, while looking at the same message even.
* It felt pretty slow to start up
* I felt like I had some issues with filter accuracy
But it got the job done and most issues were easy enough to work around.
I commend the effort, it’s always nice seeing people working on usability improvements for staple systems tools. But I have to ask the following since given your ubiquity comment:
What’s the advantage of this over using tcpdump directly?
It is basically Scapy with 200 lines of code to make it easier to start. That means tshark is alot better as a cli/DSL. Interactiveness is not what Scapy is good at, it is marvelous when you need to e.g. send events to other services based on custom packet event.
EDIT: I wonder if there is some nice TUI debugger interface/IDE that one could reuse for this. Handling traces Live like this has always been a special skill so I guess specialized tools is a must.. But one would think that all the tooling around KUtrace/ebpf/tcpdump could be generalized in some way.
Writing "layout next" in GDB gives you a TUI: Text user interface, like midnight commander. There are so many good debuggers in graphical environments I just wondered if there were any better ones for text.
Edit: I really like this simple Scapy wrapper though! Works like a charm.
I just tried tshark, it outputs just raw packet info without any formatting. My code frmats the packets and gives more usefull insights only when prompted
DoS attacks attempt to overwhelm your system or your system's connection by sheer amount of packets. And here you are capturing those packets and keeping them in memory - this just makes your system fall over faster.
I mention asciinema in my other comment[0], but there are a number of tools. The one to use depends on your system and the archwiki has a good list[1]. Assuming you're not using Wayland, ffmpeg is probably going to work[2]. Gimp and ImageMagick also provide tools to help.
I would look at one of the many other projects that have them in their readme and see how they do it, I think it's with a certain markdown syntax but I don't know it off the top of my head. Hope this helps.
