Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Memory safety for web fonts

developer.chrome.com

Post reply on HN
Print view View original

221–230 of 230 posts

Re: Memory safety for web fonts

#221

Post by ksec »

acdha wrote: post #169
okeuro49 wrote: post #147

Earlier quoted context omitted.

Do you have an article about this? What is the state now?

They did this during the period where Chrome was eating into Firefox usage, after telling Mozilla that they would drop H.264 in favor of open codecs but never keeping that promise. Here’s some period discussion: https://www.osnews.com/story/24263/google-h264-stifles-innov... What this meant in practice was that Firefox would play YouTube videos at close to 100% CPU and Chrome would use H.264 and play at like 5% CPU,…

Unfortunately some 10 years later Google is still pretty much the same with regards to video codec understanding.

Never attribute to malice that which is adequately explained by stupidity. If there was something outside of stupidity, zealotry would be another one. Although I guess one could argue zealotry is also a form of stupidity.

Re: Memory safety for web fonts

#222

Post by jdlshore »

sanbor wrote: post #201
nairb774 wrote: post #16

Earlier quoted context omitted.

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’m pretty sure FTE stands for full-time employee

When used to compare costs, “equivalent” is used instead of “employee.”

“The cost of one full-time employee is equivalent to X CPUs.” —> “The full-time equivalent is X CPUs.”

Re: Memory safety for web fonts

#223

Post by rs186 »

jstimpfle wrote: post #177
rs186 wrote: post #100

Earlier quoted context omitted.

That perspective was never correct to begin with. Along with laughable comments I have seen like "memory safety is easy. Memory related bugs are created by bad programmers". See comments under this video: https://youtu.be/gG4BJ23BFBE We are all humans, and humans make mistakes. The obvious way to avoid mistakes is to formalize "correct code" and get code chekced by machines, and in this context, let the compiler guar…

Only "obvious" if the things you are doing match simple ownership patterns for example. If you want to do performance-oriented things: for example compressing the size of certain data structures, shaving off a few pointers/integers of or even compress them in some way. Or applying various concurrency patterns, or otherwise speed up the code... ... then it's not all obvious anymore. In these situations you'd rather dr…

I think the center of the conversation is "general purpose safety" (a term I just made up), i.e. if you just want to get things done, how to write thr code in a safe way. If your other needs like performance are critical, things need to be looked at differently.

Which is why the video I linked is not so relevant to HFT guys, for example. (Context: some people try to use HFT as "counter example" to that video.) Let's be realistic -- nobody cares about whether your code running trading algorithms inside your company is memory safe.

Re: Memory safety for web fonts

#224

Post by steveklabnik »

GoblinSlayer wrote: post #204
steveklabnik wrote: post #164

Earlier quoted context omitted.

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.

Counterexamples would be s2n, grpc, putty, postfix, that are either C with classes or non-PDP C. I suppose in postfix security design was an afterthought and added gradually, but at least it was thought.

I think this means you're making the opposite argument that most C++ folks do, which is that C with classes is bad, and more prone to security issues than "modern C++" is.

Re: Memory safety for web fonts

#225

Post by MForster »

kiicia wrote: post #50
declan_roberts wrote: post #8

> 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”

It's quite the opposite. This is intended for engineers to make good trade-off decisions as a rule of thumb without financial micromanaging.

Re: Memory safety for web fonts

#226

Post by pradn »

izacus wrote: post #175
interroboink wrote: post #167

Earlier quoted context omitted.

I think what they're suggesting is that yes, Google spent some SWE hours to implement it, but they have (or will, over time) saved more than that in equivalent compute (by pushing it onto users). So, from Google's point of view, they saved SWE hours on the company balance sheet, so it's a win. But from the larger point of view of "everyone," this actually made the total cost worse. The cost/benefit analysis from Goog…

I'm don't think that metric applies here - "SWE years" is when you want for determine whether investing in certain optimisation is worth doing. In case of VP9, there was no such tradeoff - it used more storage, more CPU time and age SWE hours. What it saved was a very clearly quantifiable financial cost of bandwidth and SWE hour tradeoff didn't have much to do with it. It would be applicable if the debate would be in…

SWE-years are actually used for two things: a) measuring ongoing cost and b) for calculating if an investment will pay off.

There's a few benefits over just using a dollar figure. It's a unit that natural ties time to value. SWE-years is a natural unit for thinking about the time of SWEs. It's also convertible to other units. The conversion factors to other units can change over time, without having to pay attention to the minutiae.

All these factors make it useful for both measuring ongoing cost and making investment tradeoffs.

Re: Memory safety for web fonts

#227

Post by tatersolid »

p_ing wrote: post #138
truncate wrote: post #134

Earlier quoted context omitted.

Since you are so sure about how Mac Mini's are used, is it 2k on 24" or 27" that these customers use? My impressions based on limited anecdotal data I've is that most people with mac mini are using it as their secondary device (everyone has a Macbooks). Everyone is using 27" 4k monitors. 4k monitors are not that far from 2k monitors, and I think most people who are preferring to buy 2k are gamers that want higher ref…

24"-ish 4K, 27" is 5K, 32" 6K. Outside of that is not HiDPI and will lead to fuzzy fonts (your eyes may vary). PPI needs to be near 220.

Viewing distance matters. ppi isn’t the target metric, it’s pixels-per-degree-of-vision that determines if a display setup is “retina”. 60 ppd is equal to 20/20 vision in a human.

My 34” monitor is only 4K but is “retina” at the viewing distance in my home office according to this calculator: https://qasimk.io/screen-ppd/

Re: Memory safety for web fonts

#228

Post by GoblinSlayer »

steveklabnik wrote: post #224
GoblinSlayer wrote: post #204

Earlier quoted context omitted.

Counterexamples would be s2n, grpc, putty, postfix, that are either C with classes or non-PDP C. I suppose in postfix security design was an afterthought and added gradually, but at least it was thought.

I think this means you're making the opposite argument that most C++ folks do, which is that C with classes is bad, and more prone to security issues than "modern C++" is.

My argument is that C with classes is bad when it uses bad security practice, not because it must be bad.

Re: Memory safety for web fonts

#229

Post by codedokode »

snvzz wrote: post #198
codedokode wrote: post #191

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.

They made a choice that safe addition takes 3-4 instructions, and wrapping one (rarely used except for cryptography) takes 1 instruction. Doesn't it make more sense to make often-needed safe addition 1 instruction and rarely needed one to take 3-4 instructions?

Re: Memory safety for web fonts

#230

Post by vardump »

mastax wrote: post #214
vardump wrote: post #140

Earlier quoted context omitted.

I haven’t seen any aligned double or long tearing for over 20 years on workstation or server CPUs.

X86 has a strong memory model, so tearing isn’t an issue for 64-bit or smaller quantities. Other architectures (ARM) are different. AIUi

A bit late reply.

Memory model strength has nothing to do with tearing. Total store order and total load order does not matter in any possible way.

There's no tearing, because all memory operations are wider than 64-bits. Unless someone purposefully performs two 32-bit operations on a single 64-bit value.

Post reply on HN