> not everything that triggers the detector is in fact a flamewar that should be suppressed
Scott and I get emailed every time that software trips so we can quickly look at which threads are being penalized and reverse the penalty when it isn't helpful. The only time we don't do that is when we're sleeping.
We tend to call it the 'overheated discussion detector' these days, since it detects more than flamewars. However, that phrase is more awkward to say than 'flamewar detector'. If anyone can come up with a better name I'd love to hear it.
Turning that software off is not an option, because HN would be overwhelmingly more dominated by flamewars if we did so. It's not primarily the individual threads that I fear, it's the systemic effects of having them be more dominant. HN exists most of all for the quieter, deeper, more out-of-the-way finds that would be the first to get excluded under such a regime. That would really be an existential risk to HN.
Incidentally, that last point generalizes. When people complain that we don't do X, for some obvious X, it isn't because we don't value X (e.g. free speech or whatnot). It's because we're worried about systemic effects.
Here's your list - you have to use double newlines:
- torrents work if they are shared more than they are leeched, so it's just easier to have it run in the background. There's very little reason to not use the existing client/server models like transmission or tTorrent
- indexing and search still relies too much on third parties. Integrate magnetico (passive indexing), bep 33 (dht-based scraping) and bep 51 (dht-based indexing) and the user gains an order of magnitude of autonomy because they don't rely on centralized authorities anymore
- is there a possibility yo go further ? Make sharing files easier with bittorrent, or something like that ? Bittorrent clients should help with that
I don't think decentralized indexing is a solvable problem. There's too much crap, and too little in the way of useful signal to tell it apart.
What would be really useful, though, would be a way to separate indexing from the actual torrents.
Let me give you an example: say you're a member of a private tracker, and you see some release that looks nice. You click it in your torrent client. It then tries to find the same torrent on a public tracker (e.g. by hash), and downloads from and seeds to both.
If a system like this existed, then you could use private trackers just for the indexing, and then the computers could be left to do the actual work of finding the data.
Also, as a nice side bonus, this would allow for the "long tail" style of seeding that the more old-fashioned protocols have. If you're not seeding a whole torrent, but just a series of single files, nothing prevents you from just opening up e.g. the 'Downloads' folder to the public, and allow them to download if they can provide the hash of the file. This would make it much easier to find seeds, since the limit usually isn't bandwidth but storage.
I think at 7 YOE, you’re at a very good spot where you have the flexibility of being picky with what types of interviews you can choose to interact with.
Especially in this current market where it’s one of the rare times that candidates have some semblance of power in the hiring process.
An issue I often ran into when using the repo myself was I’d find a company that sounded awesome, and then find that they didn’t have any open positions. I created nowhiteboard.org to act as a way to pull all the jobs from the companies listed on that repo (and other companies that I’ve manually found that don’t use LeetCode).
I think there’s a matter of education and shining a light on the companies that don’t use LeetCode as I feel that the prevailing notion in online communities is that companies only use LeetCode to interview. I’m obviously biased since I’m obsessively researching this, but I’ve read a good few comments online of engineers who’ve stated that they haven’t had to use LeetCode for any of their interviews over their career, and that all of those companies aren’t listed on the repo above.
If companies had a good way to source candidates that are hesitant to jump jobs specifically because of LeetCode, I could see our industry starting to make some semblance of progress towards making LeetCode less prevalent in interviews.
Anyways, rant over, hope your job searching goes well!
Scott and I get emailed every time that software trips so we can quickly look at which threads are being penalized and reverse the penalty when it isn't helpful. The only time we don't do that is when we're sleeping.
We tend to call it the 'overheated discussion detector' these days, since it detects more than flamewars. However, that phrase is more awkward to say than 'flamewar detector'. If anyone can come up with a better name I'd love to hear it.
Turning that software off is not an option, because HN would be overwhelmingly more dominated by flamewars if we did so. It's not primarily the individual threads that I fear, it's the systemic effects of having them be more dominant. HN exists most of all for the quieter, deeper, more out-of-the-way finds that would be the first to get excluded under such a regime. That would really be an existential risk to HN.
Incidentally, that last point generalizes. When people complain that we don't do X, for some obvious X, it isn't because we don't value X (e.g. free speech or whatnot). It's because we're worried about systemic effects.