Comments URL: https://news.ycombinator.com/item?id=48128600

Points: 3

# Comments: 0

I’d be most concerned about this component of your process, tbh. IIUC, you’re not just using the LLM to identify relevant papers, i.e. a fancy search engine. You’re also extracting specific statements, divorced from their context in a given paper, and using these to make claims for your research.

Even if you validate that the quotes are actually present in the papers, are you also reading the full papers to ensure you understand the overall results of the paper and what the quotes mean in that context? Or are you just identifying hopefully-relevant snippets and combining them?

Feel free to send me an email (findable via my HN profile) mentioning that you found it via this thread, and I’m happy to extend an invite.

Comments URL: https://news.ycombinator.com/item?id=36741836

Points: 24

# Comments: 1

While the underlying model is certainly different, and my understanding is that current LLMs don’t learn “live”, the principle seems worth keeping in mind.

https://www.nand2tetris.org/book

Comments URL: https://news.ycombinator.com/item?id=29026623

Points: 366

# Comments: 244

Combination of family and a more favorable climate. The somewhat lower cost of living doesn’t hurt, but it’s not like Denver is cheap.

Comments URL: https://news.ycombinator.com/item?id=23622623

Points: 5

# Comments: 0

For more general mentorship, especially as your career develops, it’s the same as anywhere, you have to find someone you get along with and who can help you learn. The advantage at a big company is that there’s a huge pool of potential mentors, and you can see their calendars and coordinate more easily than if you were hunting in the community. :)

Comments URL: https://news.ycombinator.com/item?id=22309078

Points: 4

# Comments: 1

The first outage where I thought I was going to get fired: I was working on a system that had a single-point-of-failure server, and through a mishap with rsync I accidentally destroyed the contents of /etc. That SPOF also had no backups. (I'm not claiming it was well-designed...) Thankfully the job that depended on that server would not kick off until morning, so my team slowly reconstructed its functions on a separate machine and swapped it in behind the scenes. I helped as much as I could while vibrating with anxiety, and my team was incredibly kind throughout. I was not in fact fired. :-)

The most recent outage I caused? Yesterday! I accidentally rebooted most of the machines in a development cluster. It's a dev system, there's no SLA, on the whole I don't feel horrid, but it definitely ruined a few people's work for an hour. This morning I spent a few minutes putting in a guard rail to prevent that particular mistake again...

If you're in this job long enough, everyone breaks things -- it just happens.

A downside of this kind of thing is that it makes upgrades and maintenance harder, and you often have to do any hardware work on a whole rack at once. Heterogeneous setups get really hard. And it’s usually very vendor specific.

It’s similar in concept to Algo, in that you deploy your own VPN server on a VPS rather than use a hosted service. However, it provides a polished desktop app for deploying the server, and walks you through creating a VPS on DigitalOcean very easily.

This is incredibly helpful, because most folks I’ve helped with VPN setups are not comfortable aren’t handy with a CLI, and I’ve been able to walk more than one person through setting Outline up very easily.

[0] https://www.getoutline.org/en/home

"Unfortunately this tool doesn't exist for blb++, but we should still improve our coding style for this application. Is there another way to improve our correctness testing? If we allocate some time to improving unit testing, maybe we can do this refactor once we have X% coverage in these critical parts of the codebase."

I.e., acknowledge that both goals are valid, and look for alternate solutions to make incremental progress towards both. Finding middle ground is unlikely to be satisfying from either viewpoint. In this example, Dev A isn't getting a quick win from fixing the coding style right away, and Dev B needs to allocate some time to improving testing. But especially when working on big teams and projects, this kind of piece-wise progress is where I've seen most things get done.

This kind of solution might be pointed out by either Dev A or B, or they might need to bring in a fresh pair of eyes if they're both already frustrated. :)

- Not cost-efficient at large scale. When you expect and plan to run thousands of nodes at near 100% CPU and memory usage for years at a time, running a machine room can still be less expensive.

- Specialized hardware not available in public clouds, e.g., very low latency networks configured in an optimal topology.

- Lack of control over hardware upgrade schedule. E.g., a cloud probably won’t give you those shiny new GPUs as early as you can shove them in your own servers.

The balance is shifting in many of these areas, and there’s plenty of scientific computing that can use a public cloud now. But I still wouldn’t use it for problems that are both highly CPU-intensive and require low latency networks, especially if I have long-term workloads.

[0] https://www.goodreads.com/book/show/8515228-computer-network...