141–150 of 230 posts
This is the true power of Rust that many are missing (like Microsoft with its TypeScript rewrite in Go): a gradual migration towards safety and the capability of being embedded in existing project. You don't have to do the Big Rewrite™, you can simply migrate components one by one instead.
> Merely keeping up with the stream of issues found by fuzzing costs Google at least 0.25 full time software engineers I like this way of measuring extra work. Is this standard at Google?
I think this means the engineer fuzzes 4 projects?
Earlier quoted context omitted.
macOS dropped it a few years ago, primarily because there are no Macs with non-HiDPI displays any more (reducing benefit of subpixel AA) and to improve uniformity with iOS apps running on macOS via Catalyst (iOS has never supported subpixel AA, since it doesn’t play nice with frequently adjusted orientations). Windows I believe still uses RGB subpixel AA, because OLED monitor users still need to tweak ClearType setti…
> because there are no Macs with non-HiDPI displays any more That is not true. Apple still sells Macs that don't come with a screen, namely Mac Mini, Mac Studio, and Mac Pro. People use these with non-HiDPI monitors they already own all the time.
Earlier quoted context omitted.
I sort of have this perspective, slowly changing… I think it comes from a fallacy of take a small 20-line function in C, it can be made bug-free and fully tested, a program is made of small functions, why can’t the whole thing be bug free? But somehow it doesn’t work like that in the real world.
> why can’t the whole thing be bug free? But somehow it doesn’t work like that in the real world. It can be, if the composition is itself sound. That's a key part of Rust's value proposition: individually safe abstractions in Rust also compose safely. The problem in C isn't that you can't write safe C but that the composition of individually safe C components is much harder to make safe.
This is the true power of Rust that many are missing (like Microsoft with its TypeScript rewrite in Go): a gradual migration towards safety and the capability of being embedded in existing project. You don't have to do the Big Rewrite™, you can simply migrate components one by one instead.
Earlier quoted context omitted.
> because there are no Macs with non-HiDPI displays any more That is not true. Apple still sells Macs that don't come with a screen, namely Mac Mini, Mac Studio, and Mac Pro. People use these with non-HiDPI monitors they already own all the time.
Subpixel AA for Macs is useless anyways, the fonts will look blurry no matter what you do on a Mac.
Where it falls apart is at densities any lower, for example it struggles on those awful 1366x768 15.6” panels that it seemed like every other laptop was built with for a while. Similarly 24” 1080p and 32” 2560x1440 are pretty bad.
Earlier quoted context omitted.
Yes, a SWE-year is a common unit of cost. And there are internal calculators that tell you how much CPU, memory, network etc a SWE-year gets you. Same for other internal units, like the cost of a particular DB. This allows you to make time/resource tradeoffs. Spending half an engineer’s year to save 0.5 SWE-y of CPU is not a great ROI. But if you get 10 SWE out of it, it’s probably a great idea. I personally have use…
Note that this can lead to horrid economics for the user. An example being Google unilaterally flipping on VP8/VP9 decode, which at that time purely decoded on the CPU or experimentally on the GPU. It saved Google a few CPU cycles and some bandwidth but it nuked every user's CPU and battery. And the amount of energy YouTube consumed wholesale (so servers + clients) skyrocketed. Tragedy of the Commons.
Earlier quoted context omitted.
Yes, a SWE-year is a common unit of cost. And there are internal calculators that tell you how much CPU, memory, network etc a SWE-year gets you. Same for other internal units, like the cost of a particular DB. This allows you to make time/resource tradeoffs. Spending half an engineer’s year to save 0.5 SWE-y of CPU is not a great ROI. But if you get 10 SWE out of it, it’s probably a great idea. I personally have use…
Note that this can lead to horrid economics for the user. An example being Google unilaterally flipping on VP8/VP9 decode, which at that time purely decoded on the CPU or experimentally on the GPU. It saved Google a few CPU cycles and some bandwidth but it nuked every user's CPU and battery. And the amount of energy YouTube consumed wholesale (so servers + clients) skyrocketed. Tragedy of the Commons.
On the whole, since clients are so constrained, it usually pays to be efficient there - make websites load quickly to increase revenue, require only weak hardware to get more game/app sales, etc. Clients are also untrusted, so there's so many things you can only do on the backend.
If fresh code in Rust truly reduces the number or severity of CVE in a massively tested and fuzzed C library like this one it will be a major blow to the “carefully written and tested C/C++ is just as safe” perspective. Just need the resources and Rust performance to rewrite them all.
If fresh code in Rust truly reduces the number or severity of CVE in a massively tested and fuzzed C library like this one it will be a major blow to the “carefully written and tested C/C++ is just as safe” perspective. Just need the resources and Rust performance to rewrite them all.
There are no major blows required. The idea that carefully written C/C++ code is just as safe was never tenable in the first place, and obviously so.