101–110 of 230 posts
> 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?
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.
FreeType was written when fonts were local, trusted, resources, and it was written in low-level C to be fast. The TrueType/OpenType format is also made for fast access, e.g. with internal pointers, making validation a pain. So though FreeType is carefully written w.r.t. correctness, it was not meant to deal with malicious input and that robustness is hard to put in afterwards.
I've recently been learning about how fonts render based on subpixel layouts in monitor panels. Windows assumes that all panels use RGB layout, and their ClearType software will render fonts with that assumption in mind. Unfortunately, this leads to visible text fringing on new display types, like the alternative stripe pattern used on WOLED monitors, or the triangular pattern used on QD-OLED. Some third-party tools…
I'm pretty sure windows dropped subpixel anti-aliasing a few years ago. When it did exist there was a wizard to determine and set the subpixel layout. Personally I don't bother anymore anyway since I have a HiDPI display (about 200dpi, 4K@24"). I think that's a better solution, simply have enough pixels to look smooth. It's what phones do too of course.
But it only applies to Linux, where the small fonts can be made look crisp this way. Windows AA is worse, small fonts are a bit more blurred on the same screen, and amcOS is the worst: connecting a 24" FHD screen to an MBP ives really horrible font rendering, unless you make fonts really large. I suppose it's because macOS does not do subpxel AA at all, and assumes high DPI screens only.
Earlier quoted context omitted.
Despite mounting evidence this perspective remains shockingly common. There seems to be some effect where one might convince oneself that while others are constantly introducing high severity bugs related to memory un-safety, I always follow best practices and use good tooling so I don't have that issue. Of course evidence continues to build that no tooling or coding practice eliminates the risk here. I think what's…
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.
It can't. You can make yourself 99.9...% confident that it's correct. Then you compose it with some other functions that you're 99.9...% about, and you now have a new function that you are slightly less confident in. And you compose that function with other functions to get a function that you're slightly less confident in. And you compose them all together to get a complete program that you wouldn't trust to take a dollar to the store to buy gum.
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.
C and modern C++ are so different that lumping them together in a blanket assertion doesn't really carry much meaning.
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.
You're right that there's nothing stopping someone from hooking up an HDMI-to-VGA adapter for their 22" Trinitron from 2001, but that doesn't mean boat anchors are a meaningful market segment. It's not a consideration for why they should retain a font rendering feature for a modern OS. You're just going to have to suffer with fuzzy fonts for your retrogaming hobby.
Earlier quoted context omitted.
This is the worst. I was in France recently and tons of mobile websites were just suddenly in French. It was a real chore to read through them, and I can only imagine how frustrating this is when you can't read the language put in front of you at all.
This is always infuriating, because browsers send the Accept-Language header, that these sites just ignore.
At the very least sites that do this should detect that there's a mismatch between expected language given geolocation and the header and have a toast notification about how to change the language settings back manually.
It's very annoying that Google's websites, including this blog, are automatically translated to my browser's preferred language. Sillicon Valley devs clearly believe that machine translation is a magical technology that completely solved internationalization, like in Star Trek. No, it's far from it. Ever since internet has been flooded with automatically translated garbage, the experience of international users, at l…
This is not a just Silicon Valley problem though; Redmond had similar issues if you just use the newer parts of Windows in a non-English language.
Earlier quoted context omitted.
This is always infuriating, because browsers send the Accept-Language header, that these sites just ignore.
The thing I don't get is that there are plenty of Googlers traveling internationally. They've been aware of the problem for over a decade now, yet it persists. If I'm traveling from Spain to Poland with a browser set to use UK-English, why would the site immediately switch to Polish? It makes no sense that this common corner case isn't addressed at all after all this time. At the very least sites that do this should…