Hacker Newsnew | past | comments | ask | show | jobs | submit | throwaway314155's commentslogin

> told disgruntled iPhone 4 users that they were holding their phones wrong

That was never proven. Although their PR response was atrocious.


> That was never proven

“All phones have sensitive areas,” Jobs wrote. “Just avoid holding it in this way.”

https://arstechnica.com/gadgets/2010/06/jobs-on-iphone-4-ant...

https://www.macrumors.com/2010/06/24/steve-jobs-describes-ip...

Jobs wasn't exactly wrong - bridging the antenna with your finger was not a good way to hold the iPhone 4.

What's hilarious is how they "fixed" it in software - by changing the signal bar display curve, and then making the lower bars appear taller.

https://9to5mac.com/2025/10/08/a-15-year-mystery-solved-the-...


How is that relevant?

Playing two Steam games simultaneously typically results in a logout from the second (offending) PC.

> Microsoft licensing rules mean that you are not allowed to hide Windows.

What do you mean? As in - manufacturers can't create an overlay similar to Steam Deck's "Gaming Mode"?


As in

> manufacturers can't replace Explorer with a desktop similar to Steam Decks GameScope.

You have to use Microsoft's OOB experience. Improved with "handheld mode", but still not as slick and you are not allowed to improve it.

You can have a "full screen launcher", but you have to boot to Explorer and then run your Big Picture Mode.


Steam do on Windows through "Big Picture" mode.

My first job did IRL code reviews with at least two senior devs in the loop. It was both devastating and extremely helpful.

Yeah when we first started, "code review" was a weekly meeting of pretty much the entire dev team (maybe 10 people). Not all commits were reviewed, it was random and the developer would be notified a couple of days in advance that his code was chosen for review so that he could prepare to demo and defend it.

Wow, that's a very arbitrary practice: do you remember roughly when was that?

I was in a team in 2006 where we did the regular, 2-approve-code-reviews-per-change-proposal (along with fully integrated CI/CD, some of it through signed email but not full diffs like Linux patchsets, but only "commands" what branch to merge where).


Around that time frame. We had CI and if you broke the build or tests failed it was your job to drop anything else you were doing and fix it. Nothing reached the review stage unless it could build and pass unit tests.

Right, we already had both: pre-review build & test runs, and pre-merge CI (this actually ran on a temp, merged branch).

This was still practice at $BIG_FINANCE in the couple of years just before covid, although by that point such team reviews were reducing in importance and prominence.

Yeah, I'm calling bullshit as well. The OP responds but doesn't seem to acknowledge that --dangerously-skip-permissions is a thing.

I don't know if it's real any better than you but they do seem to acknowledge that.

> This is the first time I've had any issues with yolo mode and I've been doing it for as long as it's been available in these coding tool

https://www.reddit.com/r/ClaudeAI/comments/1pgxckk/comment/n...

I don't know what else "yolo mode" would be.


Ah fair enough.

Do skills get access to the current context or are they a blank slate?

They execute within the current context - it's more that the content of the skill gets added to that context when it is needed.

> which presumably hasn't done a fresh pre-training over the web

What makes you think that?

> Did they figure out how to do more incremental knowledge updates somehow?

It's simple. You take the existing model and continue pretraining with newly collected data.


A leak reported on by semi-analyses stated that they haven't pre-trained a new model since 4o due to compute constraints.

GPT 4o was an MoE model as well.

> it is really hard to look at for me.

What were you expecting?


Affine texture mapping is kinda jarring to look at, especially in this GBA port since there is no fixup with huge ground polygons drifting around.

One of the listed features in the PS1 port in the OP article is tesselation to reduce the issues of the PS1 HW affine texture mapper, on the GBA you have some base cost of doing manual software texture mapping but also oppurtunities to do some minor perspective correction to lessen the worst effects (such as doing perspective correction during the clipping process).


The GBA version does actually leverage dynamic polygon splitting in direct reference to how PS1 games used this approach https://www.youtube.com/watch?v=1Oo2CZWbHXw&t=271s

I think the resolution makes it particularly rough though.


Almost felt like the second video (despite being older) looked better in terms of texture jumping, looking closer now the wandering textures actually seems more to be more of an clipping issue than directly perspective correction related.

I am probably misremembering but wasn’t super Mario 64 “flat shaded” ie no textures just colors?

You’re misremembering. SM64 was fully textured, outside of specific models.

Also flat shading (vs. say gouraud shading) is isomorphic to the question of texture mapping, and concerns how lighting is calculated across the surface of the polygon. A polygon can be flat shaded and textured, flat shaded and untextured, smoothly shaded and textured, or smoothly shaded and untextured.


(Too late to edit but did not mean “isomorphic”, meant “orthogonal”. Wrong smart person word trying to look smart, how embarrassing, sigh.)

Like a lot of N64 titles, there were many solid colour objects to save on RAM, but lots of things in the environment especially were textured too.

Nothing. I have zero expectations. Giving an honest take on what I saw is all.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: