2,203 karma · joined July 24, 2022
I suspect that the postage is actually generic and can be reused, but for obvious reasons don't want to try.
You can also take postage paid envelopes and stick them on anything. People used to stick them to bricks back in the day just for fun.
My understanding of umbrella coverage is like what you said: it's an adjunct product and a way to increase the fees on their other lines, which is why if you get umbrella via your existing carrier they generally enforce minimums on your auto (and home).
As someone with kids who drive, umbrella was much more complicated than expected.
I wish you guys operated in my state so I could run my numbers through you.
Presumably there are some data centers that use water cooling. I think google and amazon's big ones do. But even then, they're not "polluting", they're using them as heat sinks.
There was a lame rolling stone article that claimed amazon was "polluting" in Eastern Oregon, but what Amazon was doing was taking brined water from an aquifer and putting more concentrated brined water back into the water table. Air conditioning doesn't really add brine, so even the premise is ridiculous. I know that article has been referenced a lot by the "Data Centers Pollute The Water" folks.
Don't people actually read anymore?
Previously the blur on iPhone was all software, apparently. I've set mine to do wide open with no bokeh, and i'll put it in after.
But to be honest, the iPhone is the camera I have on me, so the limits are acceptable. Can I force focus it? No. Can I get the glow? No. But iPhone + zoom + crop is better in some ways than my 50mm 1.2 with bokeh.
"Trillions of parameters? Trillion my ass. Back in my day we got by with millions. And now here we are, washed up has beens."
Apple went wide, not deep. I believe even the A series were wider than normal. Also that MMU overhead must be a killer for everyone else.
In NZ there's a famous story about gold miners who were mining one side of a river, and didn't go to the other side because it was too much work. One miner's dog swam over, so the dude went to get his dog and found a motherlode.
After all, the whole LLM thing started because they started increasing the parameter counts, even though there was no particular reason an AI would get better with more parameters.
"The right tool for the job" is too complicated for a lot of people to understand. Tradeoffs? Tradeoffs require understanding.
"XYZ is the best, just use it" is much easier, especially if you don't know how to make decisions and don't really care. Then you defend your non-decision by parroting what you read.
I remember a product manager talking crap about Kafka years ago, and I started digging in as to why he didn't like it, and all of his reasons were marketing FUD from competitors. It was odd, his understanding of it was a Potemkin village.
All tools presumably solve a problem. If you understand that envelope you can figure out if it works for you and your envelope.
Everyone comes at it from a different point of view, and some approaches work, some don't. And when people do this themselves they learn. Existing projects have their mistakes worked out already.
Maybe one of these people is going to come up with the thing that nobody else thought of because of their experience working the problem from scratch. You may not get that from someone working from an existing project, because existing projects have their approach "baked in."
What all these projects are showing so far is that it's possible to stream from disk, but that the performance isn't ideal. But I'm sure you could take this approach with smaller models and get better performance.
In addition, it's a given that when you work with large data sets performance means organizing the data to take advantage of caches, both disk and cpu. It's not clear how that would work, exactly, given that each run is a not-quite-random walk through the data. The Big Data way is to prebuild all of that as much as possible, which is probably impossible with a big model. But what about a smaller model?
Two benefits to Cognito are (1) it allows you to log into a service without having any credentials locally, and (2) that Cognito identity allows you to provide access to AWS resources. You can probably do that now, but plenty of solutions still require an on-device key...which is an obvious security issue.
Also, using your own backend for authentication made it easier to manage things because your auth wasn't trapped inside Cognito.
What's the speed of service/response time relative to the data source?
At that point it might be enough to replace your multiple caches with fewer in-RAM databases?
It's an interesting problem.
If you go to a goodwill outlet you'll see bins of books on their last stop before the landfill.
There are tons and tons of books being disposed every day. And statistics show that most books aren't read after their release date, if ever. So really, publishing books is mostly a waste of resources from an environmental and economic viewpoint.
Qwen3 4b params distilled/trained with fable 5
Fetishizing books isn't going to help.
In fact, most of those "rare" books don't sell because nobody wants them. The AI companies are making them even more rare, so the booksellers should be thankful.
Was Europe planning to do anything about ISIS? Not really. Syria? Iraq? The USSR? Russia? Serbia? Not really. They let Dad take care of it while they whined and played in their sandbox.
In the end Europe will rot and collapse from within, the way the Ottoman Empire did.
In most other countries the state is mother and father.
Really, there are people that play ATC games for fun.
Microinverter: 400 Panels (used): 250 for both Cables: 50
I also picked up two LiFePo4 batteries and two Kasa smart plugs and time shifted my computing infrastructure's electricity usage. That made much more of a difference in my bill, since a few hundred watts moved to .09/kwh. If the bms was smarter i could charge the batteries with solar, but alas i can't cap the recharge current.
Api gateway calls are limited to 30 seconds. This is obviously a problem if your processing takes longer than 30 seconds, especially for direct calls.
Provide a way to shut off processing and continue ingesting. Ingestion can never stop, because handling client retries is a nightmare.
Retried/poison sqs messages are a problem. They will eventually clog up your queue id not handled. Throw them away or send them to an error queue.
The best ingestion method depends on your response time and cost requirements. If possible, ingestion without API calls at all is the best solution. If not, then lambdas front ended by cloudflare or fastly are great. Lambdas, as long as they don't do work, scale unbelievably well and are unbelievably cheap.
Oh lastly, dom't let your edge lambdas touch your database. Always moderate via processing, because if you don't you (or a ddos, or a bad cloent) will crush your db.
Fyi.
The point of these engineering tricks is to see the envelope of what's possible. You can use these tricks to both run a bigger model on smaller hardware or run a smaller model on smaller hardware.
It does pretty well, but you need to iterate. I was trying to get it to disallow internet access for non-DHCP clients, and in the end there were so many limits to what was possible that it wasn't worth it. But it did it, and when I was testing I found them.
So like everything for best results you need to know what you're doing so you can test effectively...but it saves you from learning the syntax etc.