Readit NewsIt worked but Android killed it mercilessly if it used too much memory or the rest of the system needed it.
Ad the other commenter wrote: The 25% is assumed - this has nothing to do with competence but to what level an assumption is true.
Everybody can point fingers at 25 year old code and call the developers incompetent because surrounding requirements have changed.
#define VAT 0.25
"Humancentric technology at the edge" - love this in my sci-fi books but what does it do?
Kind of HN for the masses. I don't remember if there were comments but one could vote links up or down.
Or is this because most developers got complacent in only using GitHub and similar?
one local repo per developer (or more repo if they wished so),
one central shared repo,
push a feature branch to the central repo,
somebody pulls the branch, reviews the changes and poss the merge them in the preproduction branch, or go back to the developer,
some test build deploy procedure,
acceptance tests, pass or go back to development,
merge in the production branch,
test build deploy.
If you're a backbone-of-the-internet project like FFmpeg is, living on GitHub seems horrible. You will be subjected to thousands of low quality pull requests and issues from people searching for typos to fix, adding a line of white space for a contrived reason, or similar nonsense changes. Just so they can put "FFmpeg contributor" on their CV (or whatever).
> Contributing
> Patches should be submitted to the ffmpeg-devel mailing list using git format-patch or git send-email. Github pull requests should be avoided because they are not part of our review process and will be ignored.
An agentic LLM bot is likely to have no problems at creating a patch and mailing it but it's a major pain for most human developers. Furthermore they can ban source email addresses and vet potential contributors before letting them in the mailing list.
Energy from thin air or "you won't push that pedal hard enough to use those extra HPs," except maybe a couple of demo runs, "so you're paying a subscription to please your ego but not to go any faster"?
So does this imply that if insurance companies charge higher rates for higher hp, that non subscribers incur higher costs for a feature that they don't get the benefit of?
My theory is that power accumulates like money so you end up having few people with all the power. It's not that original, I must've read it somewhere.
Edit: Spain too. Probably every single European country except the UK.
* "people" generally don't spend their time compiling the Linux kernel, or anything of the sort.
* For most daily uses, current-gen CPUs are only marginally faster than two generations back. Not worth spending a large amount of money every 3 years or so.
* Other aspects of your computer, like memory (capacity mostly) and storage, can also be perf bottlenecks.
* If, as a developer, you're repeatedly compiling a large codebase - what you may really want is a build farm rather than the latest-gen CPU on each developer's individual PC/laptop.
The CI system is still slower that my laptop. We are not really concerned about it.
I'm waiting for something to fail because $3000 on a laptop won't make me gain $3000 from my customer.