If we're talking a government site, chances are you don't have the budget to be able to hire much above junior or midlevel devs. And the project manager probably has a small budget [^1] and little experience with what the web design choices really mean (and what the trade off are).

I think you'd be surprised who ends up making those decisions.

Which goes back to the original point (that's valid for any project) - keep your user in mind. If your users will be using recent-ish iOS or Android devices, use as much flair as you'd like. If your users will be using mass-market low-end devices or used devices from 4+ years ago, then maybe dial down the interface.

Knowing your user is important, no matter what level you're at.

[1] Unless we're talking about some kind of large system that's being redesigned by a consulting company on a cost-plus contract. Who knows how those decisions are made.

Even if this were the case, and I wouldn't be surprised, it's still misplaced blame.

> Knowing your user is important, no matter what level you're at.

I agree, but it's absolutely ridiculous to expect a junior dev to make excellent decisions on this. Software development is a massive industry with no prescribed methods. It's not like these folks are going through a residency before getting the job. Even if they went to uni for CS those programs don't teach these skills.

I'm somewhat in agreement. I like building 1:1 code for that specific agent.

Where I'm starting to question this is maintainability. When I come up with a new technique or way of doing something in my new agent, how can I update an older agent. Do I want to update the older agent?

But, I get what you're talking about w.r.t. building for the exact problem at hand. For example, I'm guessing that Apache Burr has support for a plugin-able vector RAG system (or at least it will if it doesn't now). That's great, but I want my RAG system to add documents to the context and keep them as part of an updated system prompt with some very specific tweaks that happen as part of that process. This is a bespoke way of working with an existing concept (RAG) that doesn't lend itself to using any specific framework.

In my use-case, bespoke is the way to go. But then I'm still stuck with having to make engineering choices for updating older agents. So, I see your point.

I’m not sure I agree with all of your takes either. For example, I’m not anti-AI for coding, so that immediately made me click away. I’m glad I read the comments though because I think the take of “not using your code to train AI” makes a lot more sense.

But, I wanted to say thanks for posting this and being really open in the comments. It’s hard to get so much feedback so quickly. It’s a firehouse of criticism that’s hard to deal with.

You’re handling it well.

thank you mbreese, i know folks can be mean and i also recognize where they're coming from (we are certainly far from perfect), but this comment is nice to read.

thank you for the empathy.

Why would you even generate fake pictures of this type? Don't you already have real ones? I mean, it's actually more work, unless you don't have the real ones.

I’m not going to defend Fisher here. It was a stupid thing for someone to do.

But unless you’re in the field, you won’t realize exactly how big ThermoFisher actually is. They are the major supplier of everything for molecular biology work. From freezers (the Thermo part) to plates and pipettes (Fisher) to enzymes and antibodies. In many ways they are like Amazon. They sell everything. Some of it from outside companies, but a good deal of sales are from in-house brands. They could use their position as a reseller to know which products sell the best and with the highest margins.

In a company of this size, it’s easy to have one group feel pressure and cheat on running the gels to confirm results. Particularly when the real results are ambiguous or dodgy. It’s not a good look, but I doubt it will put a dent in people from buying things (non-antibodies) from them.

She has her own GitHub account. It’s funny weird, but in a good way methinks.

I’m thinking of it this way - if your spouse’s GH account was breached and blocked, would you let them use your account? I would not… This isn’t her account issue, it’s his.

I have to agree. I’m interested in the project, so congrats. It’s something I might really like using.

But the one thing I expected to see in the Readme was an example of: takes this tool run output: XXXXXX and converts it to: XX for a savings of 40% of tokens.

This looks like a nice (and useful) project, so thanks for sharing!

Yes it is common, just not always to the scale of a Veritasium video. Usually it’s just the press office for a university putting out a press release or a summary article in Scientific American.

But in the case where the story is interesting to a larger audience, having a push behind a story across non-academic media is not unheard of. If you can get some media coverage of an academic topic, it can be very beneficial to the researchers’ careers. One goal for a researcher is to bring notoriety to their research, to their institution, and to the field in general. This is the main motivation I see.

The authors may have pushed the arxiv paper out earlier due to the timing of the release of the video.

I don't think I've ever installed a printer's app on my Mac. I have a reflex against it. The Mac has decent support for printers and scanners built-in, so did you need an App at all?

That's one thing that bugs me about hardware companies -- they all want you to install their app to monitor/configure/bedazzle their hardware. But really, it probably is just going to work anyway. And a printer or a mouse shouldn't need much.

At least on a Mac. On Windows, sometimes the vendor apps are helpful, but usually it's still not absolutely needed (except maybe for GPUs...)

I second this...in my experience, just the WebUI the printer spins up, and maybe grabbing drivers from their site has always been enough. I'll do anything in my power to avoid that cursed HP app. Although I'm sure there is good money in increasing app downloads, so maybe things have changed, especially on the consumer-side of things

I also despise these apps but wanted to see if it had the automatic feed feature. This printer it turns out can fax using the automatic feed but can't scan. Which is fine but they had the opportunity to upsell me on a new printer with that feature but instead failed miserably.

Many HPC jobs aren’t simulations that are CPU bound. In fact, most of the jobs on the clusters I’ve used have been single-node jobs (so technically HTC, but that term is rarely used).

I do genomics work and my jobs tend to be bursty. They may use a lot of CPU initially, but the second half of the job is writing results. This takes only one core, but still the max amount of memory. Or, I can have jobs that are CPU light, but need the max amount of memory for only a fraction of their wall-time.

Here is an example for you. Let’s say I’m processing a genome sequencing experiment. This requires about 8 different steps between preprocessing the data, alignment, post filtering, QC stat collection, etc. These are large input files, so my jobs end up being IO bound. If I were reading and writing at each step, it would add days of time to the pipeline. Instead, what we do is read the data once, and pipe the data from program to program. But each program has different CPU and memory requirements. We need to reserve the $MAX requirements for each. As the data moves through the pipeline though, we eventually end up with max utilization for only a portion of the walltime. If I optimize for efficient walltime, I leave CPUs and memory idle for a large portion of the job.

People also tend to like to manage fewer jobs. So instead of splitting a job into multiple dependent submissions that are tailored to each program, people will write a bash script that runs, but is not efficient.

Many times, these patterns are difficult to predict and you can’t submit a job that says I need 20 cores for an hour, but only 2 for the last two hours. It’s difficult to balance utilization vs wall-time. No one likes waiting, but there is usually little incentive to have high utilization rates. And sometimes the balance is total walltime. Sometimes it’s execution complexity.

This is the problem this group is trying to solve - dynamically adapting the scheduler to know when a job isn’t going to use its full allocation of resources. I’m not sure there is a good way to do it. HPC users are concerned only with getting their jobs done fast. HPC admins want to see resources used efficiently. This is a classic pipelining problem: do you optimize for individual task time or overall system throughput?

I think the only way to really do this well is to make HPC jobs a market system where resources cost money to the users. When money is involved, people are incentivized to optimize their workloads. But that’s rarely the case for large HPC clusters and I’d personally hate it if I had to deal with a HPC processing budget.

In lieu of this, a common way to handle this lack of efficiency is to do “fair share” scheduling. This means that a users prior work load is taken into account when prioritizing their queue position. So, if I did a lot of work last week, jobs for a user that didn’t run jobs last week would get a priority boost over me. This doesn’t address the utilization efficiency directly, but it does make access to the cluster seem more “fair”.

> I think the only way to really do this well is to make HPC jobs a market system where resources cost money to the users. When money is involved, people are incentivized to optimize their workloads. But that’s rarely the case for large HPC clusters and I’d personally hate it if I had to deal with a HPC processing budget.

I also got that, there aren't many incentives in HPC. Users want results and don't have the time or skill to invest in rewriting the software stack to be as efficient as possible.

An intuition that I have is that this problem could be solved at the application/framework layer. Instead of launching jobs, which are glorified bash scripts, control the logic of the resource allocation dynamically from the application software.

It will solve the problem of load balancing based on your actual compute needs, but what happens if a program requests resources in a loop? At least the current schedulers know in advance the requested resources and can stall huge allocations

I think it’s a question of cost/benefit.

For the researcher, it can take a lot of extra time and effort (and skill) that they might not have. A unoptimized job that takes four days to run is still faster than taking a week to optimize the code to run in 1 day.

For the researcher, the main limit is time. In many places the cost of the HPC hardware isn’t passed onto them, so their main pressure is time. And running code is generally faster than optimizing code.

(Unless you’re running a week long analysis thousands of times)

Thinking of this as an allocation program for the application to manage is an interesting approach. But the program will need to be able to model their resource requirements from start to end, and know about how long each step will take. This sounds like a variant of the halting problem, but instead of predicting when a program will end, it’s predicting when it will need more resources.

I'm not sure that's such a bad thing. It's not going to challenge the Apple M5, but if you're specifically looking for something in the "not-Mac" market, having a laptop-sized version of the DGX is probably going to be pretty successful.

Then they better release it within the next two weeks.

What's coming out in two weeks?