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

Forcing people to keep up with SDK updates is a bad thing in itself. Let people target the earliest possible feature set and make the app run on as many phones as possible rather than showing scary messages to people due to targeting an older API.

I think the problem is that older SDK versions allowed you to do things like scan local WiFi names to get location data, without requiring the location permission.

So bad actors would just target lower SDK versions and ignore the privacy improvements


The newer Android version could simply give empty data (for example, location is 0,0 latitude longitude, there are no visible WiFi networks), when the permission is missing and an app on the old SDK version requests it.

Of course, they don't like this because then apps can't easily refuse to work if not allowed to spy.


That can have some very extreme legal ramifications.

Consider - it's a voip dialing client which has a requirement to provide location for E911 support.

If the OS vendor starts providing invalid data, it's the OS vendor which ends up being liable for the person's death.

e.g. https://www.cnet.com/home/internet/texas-sues-vonage-over-91...

which is from 2005, but gives you an idea of the liability involved.


Phone companies are required to make sure 911 works on their phones. Random people on the internet aren't required to make sure 911 works on random apps, even if they look like phones.

The comment you're replying to literally has an example of an internet calling service being fined $20,000 for not properly directing 911 calls.

I guess Vonage should try to appeal the case and say pocksuppet said they're not required to do that.


It can't have "extreme ramifications", Google's own phone couldn't call 911 for a while.

And you can manually force only the voip dialing apps instead of everyone


WASM + Zig (even compiling C code) will make some really tiny WASM files with no dependencies. The problem is that you don't have a standard library, then your code gets really big as you add more of that in there.

Exactly right. 2.7KB works because it's pure computation — slot counting, no allocator, no stdlib, no WASI. The moment you need I/O it balloons. This use case fits a glove

> "I used Claude to create an approximate version of the game loop in JavaScript based on the original DOOM source"

This is the real horror here, Uncanny-Valley gameplay Doom. It's like those Doom maps where people tried to recreate the game levels from memory, but still made a few mistakes and got some details wrong. This is like that, but for the gameplay rather than the level layouts. It's different enough to be wrong.

We have Green Armor that sets your armor to 200%. Health Bonuses that reset your health to 100% if you exceeded that number, too bad if you recently collected a Soul Sphere. Switch-activated doors that are supposed to stay open, but instead automatically close, but then the secret wall unexpectedly activates like a manual door.


This is so disingenuous. You literally clipped the full sentence that changes the context significantly.

> "Once I’ve proven to myself that rendering was feasible, I used Claude to create an approximate version of the game loop in JavaScript based on the original DOOM source, which to me is the least interesting part of the project"

This post is about whether you can render Doom in CSS not whether Claude can replicate Doom gameplay. I doubt the author even bothered to give the game loop much QA.


Seriously? Your takeaway from this is bad armor bonus computations?

Cell phones know what time it really is.

You can use CRU (custom resolution utility) to add 50Hz to most screens.

"Complex concept"

I see what you did there.


In 32-bit windows, you used to be able to see if a pointer was valid or not by seeing if it pointed to the last 2GB of address space. If it did, it was pointing to Kernel memory that was not valid for user mode code.

But then Large Address Aware (4GB limit) changes everything, and you can't do that anymore. In order for a program to be Large Address Aware, you need to not try to do things like check high bits of pointers, then every single library and DLL you use also needs to do the same.


That sounds like the same ugly hack that caused programs not to be “32 bit clean” back in the day for Macs

One difference is that the Mac OS itself was not initially 32-bit clean, with the top byte being used by the Memory Manager.

Ah yes, these 68000 pointers have a spare 8 bits for me to use! Because nothing will ever need more than 16 MB of memory. Sigh.

It's all good if you have 128kb ram but they should have had a plan to escape it from day one.

This is how pointer authentication codes work on Arm64.

JS and WASM share the main arraybuffer. It's just very not-javascript-like to try to use an arraybuffer heap, because then you don't have strings or objects, just index,size pairs into that arraybuffer.

Anyway, Javascript is no stranger to breaking changes. Compare Chromium 47 to today. Just add actual integers as another breaking change, then WASM becomes almost unnecessary.


Is there a list of these that are actually in real shipped software and not created as a joke?

New TI graphing calculators are sold today for the same price as they were in 1999.

(Obligatory XKCD: https://xkcd.com/768/)


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

Search: