HNHacker News
TopNewBestAskShowJobs

stong1

326 karma · joined October 26, 2021

Hack the Planet
submissionscomments
stong1··on Calling All Hackers: How money works (2024)
Well said. To expand on what you wrote, I like to think of there being three components (axes) to activities: fun, value, and meaning.

Fun is you enjoy doing it. Playing video games and watching TV is fun.

Valuable is it makes money. Importantly, it's what other people are willing to pay you money for, not what you think is important or even good.

Meaningful is it's spiritually enriching. These are things you would regret not doing on your deathbed. Spending time with your family or going to church are common examples of things that are meaningful to people (and potentially fun). This one is defined based on one's internal compass and varies significantly from person to person.

You can come up with activities that are pure fun, value, or meaning. Measuring activities against these three axes has been a valuable mental model for my time management and life design.

There's jobs that are fun and meaningful, but don't pay much. This is like charity work or passion tax industries such as game dev, music, or art.

There's also jobs that are fun and valuable, but are meaningless. Working at a trading firm/hedge fund is a common example (though some people may find that it's all three or only one). Another example is being a successful startup founder working on the wrong problem.

Finally, there are jobs that are valuable and meaningful, but maybe not all that fun. To me, this is what being a startup founder (working on the right problems) or how I imagine a professional athlete is like.

The grand slam would be having all three, but in my experience these are exceptionally rare. If it's fun and meaningful, everyone wants to do it, and supply and demand pushes the value down. Most of these cases are due to unusual personalities that let one find fun or meaning in activities others don't. This ties into the common startup advice of paying attention to "founder-problem fit" and "what are your unfair advantages".

stong1··on Calling All Hackers: How money works (2024)
This is my article! I was surprised to see it here again. I hope you all enjoy it, I had a blast writing it. Thanks again everyone for the kind words and valuable feedback.
stong1··on Solving LinkedIn Queens with SMT
Reminds me of a small project I did back in undergrad: Minesweeper using a SMT solver. https://github.com/stong/smt-minesweeper
stong1··on TL;DW: Too Long; Didn't Watch Distill YouTube Videos to the Relevant Information
Cheap. Less than $10/GB and since we only scrape metadata and transcripts, the traffic usage is low.
stong1··on TL;DW: Too Long; Didn't Watch Distill YouTube Videos to the Relevant Information
1.) We do no TTS of our own. We either use the original transcripts uploaded manually by the YouTuber or we use the auto-generated ones supplied by Google.

2.) No, I plan to keep it free as the operational costs are relatively minimal.

stong1··on TL;DW: Too Long; Didn't Watch Distill YouTube Videos to the Relevant Information
This should be fixed!
stong1··on TL;DW: Too Long; Didn't Watch Distill YouTube Videos to the Relevant Information
This should be fixed now. There was temporary outage due to proxy running out of bandwidth.
stong1··on TL;DW: Too Long; Didn't Watch Distill YouTube Videos to the Relevant Information
Hi HN! I'm the author of this service. Thank you for your support.

There may have been some temporary downtime due to residential proxy running out of bandwidth. I have purchased additional bandwidth. (I run this service for free.)

There also may be some errors with particular videos because they are not accessible in certain regions. For now all requests to YouTube originate from United States, but open to change in the future to some kind of round-robin or fallback system.

I know it's not perfect. I developed the tool originally for my own use. It's open source and I'm open to any patches or pull requests.

Enjoy!

stong1··on Resigning as Asahi Linux project lead
I would work on something else then.
stong1··on Calling All Hackers
This is my article. Thank you for your kind words, I'm glad you all enjoyed it! I was very surprised to wake up this morning to see it on HN, haha.
stong1··on Reverse engineering a software crack
Oh hey, this is my thread. Thanks for reading, yall! <3

I also do reverse engineering streams on YouTube: https://www.youtube.com/basteg0d69

stong1··on I'm looking for a cybersecurity company for an affordable smart contract audit
Hey there--I'm the founder and CEO of Zellic: https://zellic.io

We work across all major ecosystems and platforms. Our specializations include EVM, Cosmos, Solana, Move (Aptos/Sui), and L1 code as well. We're a full-service provider and can do anything from auditing ZK circuits to web frontends to hardware wallet firmware. Clients include LayerZero, Solana Foundation, Aptos Labs, Sui Foundation, Starkware, Jump.

Me and my cofounder also previously founded the #1 CTF team in the world, perfect blue. In general our talent is top-notch, we exclusively recruit and retain the world's top hackers.

You can get in touch with me directly at https://t.me/gf_256

stong1··on What are elliptic curve pairings?
Pictures can be found here! https://x.com/zellic_io/status/1745874206695596427?s=20
stong1··on A bug that doesn’t exist on x86: Exploiting an ARM-only race condition
Right. The challenge is written incorrectly on purpose, otherwise the code isn't vulnerable. The use of volatile is a bit of a misdirection for the CTF players, since you're right that it's a common misconception that volatile acts like a barrier.

> You cannot write a single-writer, single-reader FIFO on modern processors without the use of memory barriers.

I am not sure about this. From my understanding, on x86, given the absence of compiler reordering, processor reordering should not cause a problem for a single-reader-single-writer FIFO. Normally I just use atomics but I think in this specific instance it should still be okay anyways. Obviously it will not work on ARM.

From my testing if you compile the code on x86 with clang or gcc, the resulting binary is not vulnerable.

stong1··on A bug that doesn’t exist on x86: Exploiting an ARM-only race condition
Great points. I made some minor edits to address that and clarify some things. Thanks!
stong1··on A bug that doesn’t exist on x86: Exploiting an ARM-only race condition
Nice catch. I fixed it. I should have said "execute" rather than "retire".