> The idea of the dashboard is the following: I run the Codex through a web chat to identify the relevant quotes — relevant for my dissertation topic — and how they are relevant, it combines them into a number of claims connected with each quote with a link. And then I review each quote and each claim manually and tick the boxes.
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?
FWIW, folks on lobste.rs are (mostly) friendly and willing to extend invites if you seem like a real person. My understanding is that the invite system is primarily in use to avoid drive-by spammers and the like.
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.
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.
“The Elements of Computing Systems”, by Nisan and Schocken, starts at logic gates and works up to a functional computer that can play Tetris. So not quite Ohm’s Law, but close.
I’ve seen most of these recommendations before, but the “mic-drowning case” to muffle room audio is new to me. Certainly makes sense, but are there any common commercial phone cases that advertise this feature?
Many large companies have structured mentorship programs, but this is mostly for onboarding. Your mentor will help you learn about the company itself, e.g. all the different internal practices, tooling, teams, etc. (This is nothing to sneeze at, given how big these orgs can be!) It may include some more general career development but this is often aimed at early-career folks.
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. :)
One of my favorite recurring team conversations is the one where everyone shares stories of the outages they've caused or the systems they've broken. This conversation has happened eventually on every SRE (sysadmin/PE/devops/whatever) team I've joined, usually when a junior team member causes their first outage and is having an emotional meltdown. I remember my own meltdown of that form, and I remember it helped hearing about the terrible problems my friends and mentors had caused in their turn.
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.
There are rack designs out there built on this idea, but they are usually pretty specialized. For example, the Cray XC series has racks with built in power, network, and out of band monitoring.
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 doesn’t support OpenVPN, but I’ll leave a plug for the Outline VPN from Jigsaw (Alphabet). [0]
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.
"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. :)
I’ve worked in a few different settings on large-scale scientific computing. For those applications:
- 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.
For networking in particular, Andrew Tanenbaum's book "Computer Networking" [0] is quite good, and covers everything from the physical layer on up. The most recent edition is from 2010, but much of this doesn't change quickly so it's still quite relevant. I've found it extremely helpful at times.
Honestly, I think the most effective thing to do is find an organization doing social good, who is hiring programmers, and go work for them. There are plenty of non-profits and governments that do a ton of good, and employ developers to work on their web sites and infrastructures. A good friend of mine is a developer for the ACLU, for example.
There are also organizations like Code for America that do open source work with local governments. Since those projects are open source, you could probably volunteer your time and contribute to those. Or simply volunteer in a non-developer capacity! :)
Doing actual social good -- helping people in ways that will actually solve their problems, understanding the consequences of changing their lives -- requires a ton of context and communication. I think it's very, very difficult to do so without either dedicating most of your time to that cause, or working closely with an organization that is already doing so. (E.g., volunteering for a food bank is a lot more effective than just picking up food and distributing it on your own.)
There's occasionally a little overlap between these, but I mostly find that they cover different ground. SRE Weekly in particular has good coverage of outages and incident reports that I find interesting.
gcc also supports OpenMP 4.x and OpenACC, both of which are used extensively in the HPC world to support automated parallelization and offloading to accelerators like GPUs. clang only recently added support for OpenMP 3.1, and my understanding is that there are no plans for OpenACC support.
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?