If you have a CLI, you can even script this yourself, if you don't trust your tool to actually try to compile and run tests on its own.

It's a bit like a PR on github from someone I do not know: I'm not going to actually look at it until it passes the CI.

Or are you only considering a certain warnings?

Well, it wasn't my codebase yesterday, because I didn't work here.

Today I do. When I build, I get reports of "pkg_resources is deprecated as an API" and "Tesla T4 does not support bfloat16 compilation natively" and "warning: skip creation of /usr/share/man/man1/open.1.gz because associated file /usr/share/man/man1/xdg-open.1.gz (of link group open) doesn't exist" and "datetime.utcnow() is deprecated and scheduled for removal in a future version"

The person onboarding me tells me those warnings are because of "dependencies" and that I should ignore them.

I'm also referring to all the warnings you might get if you use an existing library. If the requirements entail that I use this library, should I just silence them all?

But I'm guessing you might be talking about more specific warnings. Yes I do fix lints specific to my new code before I commit it, but a lot of warnings might still be logged at runtime, and I may have no control over them.

What would you do if the code you inherited crashed all the time?

Come up with a strategy for fixing them steadily until they're gone.

But that's not what we're discussing here, we're discussing warnings that have been ignored in the past, and all of a sudden I'm supposed to take the political risk to fix them all somehow, even though there's no new crash, no new information.

I don't know how much freedom you have at your job; but I definitely can't just go to my manager and say: "I'm spending the next few weeks working on warnings nobody else cared about but that for some reason I care about".

2 Years later, you have hundreds of warning.

If your management won't resource your project to the point where you can assure that the software is correct, you might want to see if you can find the free time to look for another job. You'll have to do that anyway when they either tank the company, or lay you off next time they feel they need to cut more costs.

Has this ever been considered?

The problem with warnings is that they're not really observable: few people actually read these logs, most of the time. Making the deprecation observable means annoying the library users. The question is then: what's the smallest annoyance we can come up with, so that they still have a look?

With presage, Whisperfish has a high-level Rust library that wraps the official libsignal libraries (which are also written in Rust) and makes it much easier to write clients. The official Signal repo only contains Java/Typescript/Swift wrappers. As presage is rather obscure, I thought that some HN readers might appreciate the link.

I seem to have access to Gemini CLI due to one google sub or other, but each time I have a reason to try it, it underwhelms me.

Do you then think it'll improve to reach the same stability as other kinds of infra, eventually, or are there more fundamental limits we might hit?

My intuition is that as the models do more with less and the hardware improves, we'll end up with more stability just because we'll be able to afford more redundancy.

There's probably something with the position of the hand when you move the mouse as well. At least I seem to be moving mostly the wrist when I use my mouse, meaning that my hand and forearm are not always aligned; without this alignment, I feel there's more strain on the wrist when typing.

Could you do a thing with magnets where you have a special mousepad as well with the pad being all one pole pointing up and the device the same pole pointing down?

Also my imagined device would not need the full keyboard, just the full right side of a qwerty keyboard.

Or they're dead.

If you save an extra $2000/year, what are you supposed to do with the money if you're always hungry, if you're always cold? I'm guessing you could buy food and clothes; you'd end up at $0, just slightly better off. If there's no safety net to rely on, you'd save to be able to face the next problem, and maybe pay it less with your health (which is a kind of invisible debt).

And that's even assuming there's some certain income you can rely on. In my case, I know that for the next few months, I'd at least get unemployment benefits if I lost my job. Not everyone get that, and if you don't, the income floor is $0 and it's way harder to budget.

Another aspect to consider is that maybe the case of a single person who would be in poverty throughout a long life is not representative of poverty. Some people get out of poverty, some fall into it, some die early from it. If we're considering a single person always starting at $0 and always ending up at $0, several years in a row, we already dismiss these nuances. I'm sure you can find such examples, someone who lived to be 80 with a constant wealth of $0, but how common are they really?

Is there evidence that their revenues are growing faster than their costs?

Very little data about expenses, but it looks like they may be growing a little slower (3-4x a year) than revenue. Which makes sense because inference and training get more efficient over time.

> We don't have evidence one way or the other

I don't see how both of these things can be true. How can we know something to be likely or unlikely if we have no evidence of how things are?

If we don't have any evidence they're moving towards profitability, how is it likely they will become profitable?

You wouldn't demand that a restaurant jack prices up or shutdown in its first month of business after spending ~1 MM on a remodel to earn ~20k in the first month. You would expect that the restaurant isn't going to remodel again for 5 years and the amortized cost should be ~16k/mo (or less).

> it's hard to directly figure out what is true CapEx vs. unsustainable burn.

Exactly, and yet you're so certain they'll achieve profitability. The cost for pickles could get cheaper but if they're constantly spending more and more on the rest of the burger and remodeling the building all the time to add yet another wing of seating that may or may not actually be needed it doesn't really matter in their overall profitability right?