mistercow

Yeah, that’s the only explanation that makes sense. It’s just so strange to think that color pixels would use more energy.

> It seems obvious that a higher perceived brightness can be achieved for any given pixel if using greyscale instead of using colors, just because less of the backlight's area is occluded.

When converting to grayscale, you typically calculate the value of the pixel and then set all color components to that value. The point of this is to keep the luminance the same as it was in the original color pixel. If you’re doing this correctly, the perceived brightness stays the same.

And just as a smell test: have you ever converted an image to grayscale and flinched away because it seemed twice as bright? Of course not; it just loses its color.

The only way you would get more perceived brightness at lower backlight intensity would be if you physically removed the color gels that overlay the LCD matrix. Which is obviously not what they’ve done here.

I’m pretty sure the increase in battery life they observed is simply because they’re using their phone less, which is very much the main upshot of the other benefits they listed. The idea that color pixels drain more energy is just obviously nonsense.

> Color pixels drain more energy than grayscale ones. Personally found my phone lasting twice as long as before. Over time, a considerable extension of your phone’s lifespan.

What? Why? Why would you even entertain that as a hypothesis?

> and don’t think that the programmer more than the languages contribute to those problems

This sounds a lot like how I used to think about unit testing and type checking when I was younger and more naive. It also echoes the sentiments of countless craftspeople talking about safety protocols and features before they lost a body part.

Safety features can’t protect you from a bad programmer. But they can go a long way to protect you from the inevitable fallibility of a good programmer.

Multiple severe attacks on browsers over the years have targeted image decoders. Requiring an implementation in a memory safe language seems very reasonable to me, and makes me feel better about using FF.

Seems like the normal usage to me. The post above lists other criteria that have to be satisfied, beyond just being a Rust implementation. That would be the consideration.

1. “High resolution” in this kind of context is generally relative to previous work.

2. “Postage stamp sized” is not a resolution. Zoom in on them and you’ll see that they’re quite crisp.

Yes, and those glyphs don’t fit the grid. Try to redraw the n from the original font yourself. You can’t, because you can’t add points between the grid dots.

I tried to do that, and now I’m just confused. The included glyph for the lower case n doesn’t actually fit the grid, so you can’t seem to replicate it. But also that grid doesn’t have enough resolution to do the tilde. Maybe I’m missing something?

WebGPU is the only one of those I’ve really followed, but hasn’t that had a huge amount of input and changes due to other voices in the working group? That seems to contradict the simplistic picture painted above of Google just dictating standards to the industry.

If you use base64 with the intention of hiding the encoded information, surely it’s as much a cipher as rot13 is, right?

> How to calculate π for n-metrics numerically. The general idea of "divide the circle into segments and calculate the length by the metric" is explained, but the exact algorithm or formulas are not shown.

I feel like that would have been a bit in the weeds for the general pacing of this post, but you just convert each angle to a slope, then solve for y/x = that slope, and the metric from (0,0) to (x,y) equal to 1, right? Now you have a bunch of points and you just add up the distances.

There’s an almost mystical belief among certain tech and science journalists that computers are bad at randomness, and it’s really bizarre, and in my opinion, pretty harmful.

> ... all believe that the universe is not destined to grow more disorganized forever, but more complex and rich with information.

Maybe it's just a problem of being loose with terminology, but this seems to be contrasting entropy and information content, which is backwards?

Yeah, apparently I didn’t communicate that well enough. But I think this is a subtle and common point of confusion.

There are machines which are very, very hard to determine whether they halt or not, and so people end up thinking that there must be specific machines for which no Turing machine can decide halting correctly. But that’s just not true. Every “attempted halting decider” has its own infinite set of failure cases, which are specific to that machine, and not fundamental to the input machines.

This feels really strange, and trying to turn that other intuitive sense into something meaningful and reasonably formal is an interesting exercise, but it’s tricky.

> In 1936, the pioneering logician Alan Turing proved that there’s no universal procedure for answering this question, which became known as the halting problem. Any method that works for some programs will fail for others, and in some cases, no method will work.

This is weirdly stated. The first sentence is correct. But trivially, either a machine that always says “yes” or a machine that always says “no” will give the correct answer for any given case.

Given a particular set of axioms, there are machines which do not halt, but which cannot be proven not to halt, and maybe that’s what the article means. But that’s going beyond the halting problem.

This is pretty clear from the readme though?

> While Grant Sanderson continues to maintain his own repository, we recommend this version for its continued development, improved features, enhanced documentation, and more active community-driven maintenance. If you would like to study how Grant makes his videos, head over to his repository

Every source I can find says that most homeowners insurance will cover direct damage from volcanic eruptions, including fires, with some exclusions like mudflows.

I would argue that home owners insurance is a commercial application of volcanos. No, it doesn’t harness them, but if you live somewhere that could potentially be affected by an eruption, your insurance company is paying attention to the science in figuring out how to cover that risk.

OK, so this author doesn’t like James Randi. So what? We’re discussing in a thread about his post, so his word is gospel?

> I'm guessing studios enjoy not paying for all of that now that everyone streams everything and has no time for ancillary content.

Is it that, or is it just that they realized that that stuff is easy material for promoting the film, so they just let various media produce free content about it and put stuff on YouTube?

Actually, no, we don’t know what they mean. This is the foundation of the great motte and bailey that so much nutrition nonsense is based on. People say “chemicals”, and then they can gesture at a food label with a few obscure sounding ingredients and say “ooh, look how scary”. But for the vast majority of these “chemicals”, there is absolutely no reason to think that consuming them is a problem.

Anyway, since “we all know”, why don’t you go check out the ingredients for beyond burgers, and report back which “chemicals” you think are so disastrous.

Consider how broad the phrase “treating food with chemicals” is, and you’ll start to see the problem with this kind of thinking. The word “chemical” includes literally everything that food is made of.

> Makes you dream there could be an equivalent for our own universe?

But would we even notice? As far as we were concerned, it would just be more physics.

There’s something very aesthetically amusing about these shaders fitting into tweets, and those tweets also having videos attached which very roughly approximate the same information using many orders of magnitude more data.

Yeah, and I think it’s worth asking why there. Why do we not just have a standard for PWAs with privileged OS access?

There are two obvious answers. The first is portability. And sure, but Electron provides an answer here, so why can’t we provide one with PWAs? We could even have OSes define this interface for different browsers to target in a standardized way. Yes, you need platform specific code, but that’s often the situation with Electron too.

The other answer is security. But how is Electron / any other installed app any better? Because we require more explicit consent before installing a “real” app than for installing a PWA? OK so, just let’s just do that for PWAs too.

I keep thinking that this could be solved by just building Electron into the OS as a shared framework so we don't have to have a separate copy for every app, but the more I dig into it, the more I realize I'm just reinventing the web browser.

Very nice! I wasn’t even sure that the approach could be fixed without major rethinking. Great job figuring that out.

Also, even if, as the author wishes, there were a protocol for learning the subpixel layout of a display, and that got widespread adoption, you can bet that some manufacturers would screw it up and cause rendering issues that would be very difficult for end users to understand.

Even more obviously, the squares in the front aren’t bigger than the squares in the back. It looks like each square has equal area even as their shapes change.

It’s fascinating how plausible it looks at a glance while being so glaringly wrong once you look at it more closely.