Hacker Newsnew | past | comments | ask | show | jobs | submit | ece's commentslogin

The only benchmark that matters anymore is minimizing felonybench. Ok, long horizon benchmarks still matter too.

You'd almost think supporting a phone for a longer amount of time might actually be better than trying to sell a new phone every year or two.

Only if you find a way to create revenue beyond the time-of-purchase, to offset the cost of development and maintenance, aka service revenue.

So far only Apple achieved this by ensuring a walled garden around their ecosystem, securing additional revenue-share for every single 3rd party app and every transaction of the user.

All other vendors are structurally prevented to properly compete in services, and have to rely on Google paying some minor revenue-share on Services, while having only limited control over the user-experience to distinguish themselves...


This would be a bit convincing if there weren't other hardware and services providers like Fairphone, GrapheneOS and Google themselves, who do support and maintenance for longer.

The fact that you put "Google themselves" in this list makes the conversation moot, because Google is de-facto the service-revenue recipient of the entire Android device-ecosystem and the culprit of the problem.

Samsung and Xiaomi have bigger ecosystems than Google in some ways. If they want to fix their development and support for issues like this, they can.

1. Fairphone actually demonstrates that it's not a matter of "want" for sustainable/repairable/longevity, the market still doesn't reward sufficiently for it.

--> If the total potential is an increase in sales of 100k units at ~450 USD/device, there is no fiscal justification for a stock-trading company to actually build such a product. That's why e.g. the EU keeps mandating more and more of this, they "artificially" create the need for it because the market doesn't do it itself.

2. They don't have a comparable service revenue-ecosystem to Google, not even remotely.

Even in sum across their entire mobile ecosystem, the majority of service-revenue their products generate is actually Google's service revenue of the Android ecosystem, of which they get a miniscule revenue-share via Google's RSA program.

The only substantial revenue is still generated at the hardware time-of-sale only, which needs to finance the lifecycle maintenance of the product. So the objective becomes to sell a critical-mass of hardware to sustain the maintenance of the device.

And then, the next level: The market-pressure for in-time software-maintenance can only be fulfilled by not deviating too much from Google's baseline (minimizing the effort of upgrading to newer Android versions). Not deviating from Google's baseline means either contributing back any disruptive changes to Google for integration in the baseline or (more likely) to not disrupt the smartphone landscape on platform-level at all.

Disrupting with hardware innovation only works either on very-large scale or on small-scale, because either you can contract a component supplier for a huge volume of a component exclusive for you, or you pick a innovative component which cannot be supplied in huge quantity yet (and is therefore out of reach for larger brands)

As result, the established players on the smartphone market don't make any more innovative leaps, because the risk/benefit ratio for the ROI is just not there.

--> Vendors ship devices based on common hardware available at that time, combined with software available at that time.

Chinese vendors changed the game a bit by announcing devices with innovative hardware which then never reached the global market, because the components were not available at-scale yet (under-display camera, wrap-around displays, new battery composition, 5G,...) --> This was a game-changer because e.g. Samsung, Apple, Motorola, LG would not announce a device they knew they can't launch at-scale. Oppo, Xiaomi et al could do a limited run for a device-launch in China, with chinese component-suppliers shipping to assembly-factories in China with low ramp-up costs.


Fairphone is on their 6th generation now, and in the US on Amazon. Easy repairability is as much an engineering feat as adding a button or light bar. Their support window is as long as anyone else. I'll even mention Essential who did day-one updates for monthly android patches, and that was a startup.

Longer support windows are possible and would mean people wouldn't be left behind without updates for problems like this.


If bigger, better models aren't also leading to better safety, something is broken. Models seem to no longer argue with people, or output verbatim text, maybe the next step is cheating less.

I've learned to be wary of these cars in the bay area, they seem to cut it close often, and they get stuck because they're not L5. I hope municipalities know what they're getting.


So what's with the increased variance since 2021? Better tracking of pages maybe...


Every website that wants to, can just charge for dumps. Anubis or even Cloudflare can handle the rest I think.


Scrapers will ignore the dumps.

You can link to them in 10 million HTTP 429 responses, they will still ignore them.


Those scrapers can be blocked. Some scrapers won't ignore the responses, and maybe it'll lead to a meaningful reduction in scraping traffic.


This would be interesting on a Spark or two. I don't know how seamless the GPU and networking cluster setup would be when resource sharing between agent and post-training VMs.


Unfortunately as of today DGX Spark doesn't support GPU PCI passrhru for KVM

A good alternative is incus and running LXC and or OCI containers, GPU works in those and can be shared with multiple instances


What these people want is same thing people in every other field want too, which is being able to use AI as a tool and nothing more. Off course, some of the people that signed this might not recognize this, and the people who didn't sign it are actively working against such an equilibrium.


"It is difficult to get a man to understand something..."


Controlling how to train, not over fitting, making sure training data is good, and being able to do distributed training are all reasons why open weight isn't like open source. You can't fork during pre-training with open weight-only models.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: