zenware

That being said, a huge amount of the work being done (arguably all of it) is in support of humans. It would follow then that the more of us there are the more work is required, whereas if there were fewer of us less work is required. — I think the real concerns about birth-rate/population decline come from “borrowing against the future”, if that future never materializes then you cashed bad checks.

Your criteria must be faulty, it shouldn’t be tested in production if it wasn’t already production ready.

I think similarly when considering if I’m willing to deploy something though; if there isn’t a long running sample why would I trust it?

I haven’t needed to do such a thing in a while, but my “rule” for explaining how unreasonable is to say “if I only glanced at each line of code for 1 second, without bothering to understand the details, it would take me 3 and a half full 24hr days non stop to simply look at”. So it’s definitely more than 1 work week because presumably other stuff is going to need to get done in that time too. Actually understanding it is going to be at least a multiple of that, and probably the multiple is ~30x.

Not for nothing but the vast majority of people doing the kind of work that’s done on TV & Film just-so-happen to be geographically co-located for some reason.

It’s possibly worth noting that both activities require humans and even fully operational end-to-end supply chains of rare-earth minerals and semiconductor fabrication. Among many, many other things involved.

I just don’t think we can freely discount that it takes heavy industrial equipment and people and transport vehicles to move and process the raw materials to make LLM/AI tech possible, and that the … excitement has driven those activities to precipitous heights. And then of course transporting refined materials, fabricating end products, transporting those, building and deploying new machines in new data centers around the world, massively increasing global energy demand and spiking it way beyond household use in locales where these new data centers are deployed. And so on and so forth.

I suspect that we will find out someday that maybe LLMs really are more efficient, possibly even somehow “carbon negative” if you amortize it across a long enough timespan—but also that the data will show, for this window of time, that it was egregiously bad across a full spectrum of metrics.

Except that you can, because every software company did this for decades… Want to upgrade to a new version of our product? That’s another one time fee for that version.

If you squint, this looks a lot like a subscription model, but with extra steps. Why it’s different is because those extra steps actually matter.

They matter to the people who aren’t subjected to subscription dark-patterns to keep them from unsubscribing for just a little bit longer. They matter to the product, development, and sales teams who know they actually have to produce and deliver something meaningful if they want repeat customers. The matter to the accounting teams on all sides of the transaction, in particular because subscription revenue or expenses can always be counted as “recurring” and this has implications on cash flow which itself can impact many things.

The pitch has always been “we grow with you, this is a win-win”, implying that perpetual license fees are actually good for you to pay. Ostensibly because keeping your supplier in business keeps you in business, but in reality it was totally possible for a software supplier to go out of business and for their customers to continue operating without issue for 5, 10, even 15+ years, before even considering finding a replacement software.

And despite the pitch seeming so sweet, the literature on why you want your software business to operate on a subscription model was always about gaining an advantage over your customers, however marginal it may be, and now the data has borne out that the advantage is stark.

Well, I hate to be the bearer of bad news, but Apple Silicon CPUs are entirely based on ARM architecture, and they elected to use ARM architecture, among other reasons, because it has lower power consumption and lower heat generation compared to CISC architectures.

Perhaps they are hoping Google will pay them ~$500m/yr to be the default search engine.

"Phones don't die"

You're probably right.

"Weight removed from vegetable bin, vegetables are $x/lb"

This already happens at... most stores.

I think Bluetooth enrollment would be good enough or they'll send you a barcode on a PVC card stock maybe even with RFID, but sure poor people can't shop at the nice grocery store, that's always been true right?

I sort of agree, but I also think there is a real market for it. Blah blah capitalism blah. "The market will show whether the problem was real." I'm pretty sure it's going to work out and be profitable for Amazon like always.

My current best guess is, basically what you've suggested. The Amazon Go page says "Computer Vision" which means "Cameras, Cameras Everywhere!". It also says "Sensor Fusion," I bet that means at the very least "Wifi and Bluetooth," with which they'll use to place your location on a virtual map of the store. That location could then be compared with the computer vision object tracking location to "double check" that you really are at that location. And so on.

Most libraries RFID all their books now so you can just drop them on a scanner that detects all the books you have, swipe your library card and go.

I don't think that's actually what Amazon Go is doing though.

Not that I'm terribly familiar with the functional approach, although after reading some of this I will definitely be examining it more thoroughly and exploring its use in personal projects, but would memoization appease you?

Someone wrote a browser extension for Flash to be replaced with VLC on twitch.

https://www.reddit.com/r/WatchPeopleCode/comments/3273es/pro...

It wouldn't be hard to make that work on other sites that have a flash player. But we aren't quite sure if it improved the performance or anything, it just felt right.