201–210 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?
FTE. Full time equivalent. Mosts costs are denominated in FTE - headcount as well as things like CPU/memory/storage/... The main economic unit for most engineers is FTE not $.
I get it, but switching to Rust places the codebase on an Island I can't easily get to. I am already switching between C++, Swift, Kotlin, and Python on an almost daily basis.
Earlier quoted context omitted.
This becomes a vicious circle. Language developers do not want to make the language safer because legacy CPUs do not support overflow trapping, and CPU designers do not bother to add it because nobody needs it. For example, RISC-V spec says that they decided to not add overflow trapping because it is "easy" to do in 3 or 4 existing instructions.
>RISC-V spec says that they decided to not add overflow trapping because it is "easy" to do in 3 or 4 existing instructions. It is not just "easy" to do, but actually easy to do, without quotes. And much, much easier than as an exception/trap. And it is explicit, which makes it even better. No hidden behaviour.
> it is explicit, which makes it even better. No hidden behaviour.
Which is why we do virtual address translation and populate (and evict!) L1/L2 caches in software, and the reason why CHERI project is misguided.
Earlier quoted context omitted.
From a safety perspective they aren't very close, there is a reason that all these CVE bugs are C code.
I haven't seen conclusive evidence that this is the case, do you happen to have an analysis of this somewhere? Of course, C++ offers you tools that C doesn't, but some of those tools have their own sharp edges as well. Plus, many C++ codebases are "C with classes" style or similar hybrids, those are still ultimately C++ programs, not C ones.
Earlier quoted context omitted.
As I understood their arguments it was not about the effort needed to rewrite the project. It was about being able to have two codebases (old and new) that are so structurally similar, that it won't be a big deal to keep updating both
No, it was absolutely about the effort needed to rewrite the project. They couldn't afford a rewrite, only a port. They're not going to keep maintaining the Typescript version once they have transitioned to the Go version.
A Go port looks roughly the same as TypeScript, same “shape”, same concepts, so they don’t need to re-architect the code, they can just “translate” TypeScript to Go, then clean up where makes sense or needed. For a good while (definitely years, probably half a decade, if you ask me) while both projects are maintained, adding fixes and features will be therefore easy. The two codebases can be expected to have almost the same output and bugs, both is good for maintainability.
With Rust, the translation wouldn’t work as Rust is significantly different. This would mean rethinking everything, the architecture would diverge, resulting in two possibly very different set of bugs. With different structure, tweaking both at the same would be very difficult.
I hope that if we switch away from FreeType, we'll still have a way to use TTF hinting instructions fully. Windows/macOS don't seem to have a way to enable proper hinting anymore [0], and even FreeType (since 2.7 [1]) defaults to improper hinting (they call it "subpixel hinting", which doesn't make sense to me in theory, and practically still seems blurry, as if it's unhinted). In case anyone's wondering what properl…
> 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?
Yes, all those well paid C-level managers cannot handle multiple units so they require everyone to use one “easy to understand unit so that everything is easy to compare and micromanage”
Earlier quoted context omitted.
I don't think you understand how backwards it is. My patch that makes SDF rendering 4x faster was not accepted, presumably because floating point-maths is some strange new-fangled technology. Freetype uses antiquated fixed-point integer maths everywhere. See https://gitlab.freedesktop.org/freetype/freetype/-/merge_req...
Did you check to see if Freetype supports platforms that don't have floating-point math, or where it's very slow? I agree that fixed-point math is unnecessary on modern hardware and architectures, but they may prioritize support for hardware you don't personally care about. Sure, a compile-time option to use one or the other might sound reasonable, but then that's two different code paths that need to be maintained a…
No, that's why I will change to a better font rendering system when I get a chance.
Earlier quoted context omitted.
I don't think you understand how backwards it is. My patch that makes SDF rendering 4x faster was not accepted, presumably because floating point-maths is some strange new-fangled technology. Freetype uses antiquated fixed-point integer maths everywhere. See https://gitlab.freedesktop.org/freetype/freetype/-/merge_req...
I know how to read, and that MR comment sounds 100% reasonable to me. Normally you'd take a comment like that, go "oh, okay let me do some more investigations" and start a dialog instead of going "they rejected my MR on the first pass, they don't know what they're doing and their library is antiquated". Where's the follow-up, or did you just walk away?
Earlier quoted context omitted.
Yes, all those well paid C-level managers cannot handle multiple units so they require everyone to use one “easy to understand unit so that everything is easy to compare and micromanage”
If you want to decide which of several options is better, how do you propose doing that without using a single number? You can’t, in general, compare multi dimensional quantities.
as for if you can compare multidimensional quantities - of course you can do it and it is done every day with engineering and medical data, it's just tad more complicated than adding and multiplying so it's a no-go for c-suite
you cannot expect people earning six figures to understand actual math, can you?