RaisingSpear

Joined 6 years ago

Karma

126

Submissions

Member since

Jun 8

View on Hacker News

Recent submissions

Comment · 7 days ago

So if the definition is based off personal preference, how do you know mobile game players aren't gamers?

Mobile gacha/micro-transaction games often encourage frequent/repetitive play (e.g. via dailies, limited time quests etc). Would someone engaging in this likely consider the game to be a hobby?

Comment · 8 days ago

> they aren't "gamers," they're just people who sometimes play games

I thought that basically fits the definition of "gamer" so I'm clearly mistaken. How do you define "gamer"? Someone who "always" plays games? (for some definition of "always"?)

Regardless, non "gamer" game players can still benefit from higher refresh rate screens, and they're not insignificant in number.

Comment · 9 days ago

It's worth pointing out that mobile gaming surpasses PC and console combined, in terms of marketshare and revenue. https://playercounter.com/gaming-industry-revenue-statistics...

I don't know how "mobile" gamers are using iPads (or tablets), but considering the size of the market, I doubt it's particularly niche.

Comment · 1 year ago

From memory, the SpacemiT K1 doesn't support extensions like Zvkt?

EDIT: okay, looks like the official documentation lists it, but many places I looked didn't. Maybe it wasn't being detected in cpuinfo?

Comment · 1 year ago

If you scale up the multipliers, you should be able to eliminate the variable shift, which would reduce the lookup table to 512 bytes.

Comment · 1 year ago

For CPUs that support AVX-512 VBMI, there's a faster reciprocal-based approach: https://avereniect.github.io/2023/04/29/uint8_division_using...

A VBMI2 example implementation can be found in the function named divide_with_lookup_16b: https://godbolt.org/z/xdE1dx5Pj

Comment · 2 years ago

I suspect Intel uses 32x32b multipliers instead of his theorised 16x16b, just that it only has one every second lane. It lines up more closely with VPMULLQ, and it seems odd that PMULUDQ would be one uOp vs PMULLD's two.

PMULLD is probably just doing 2x PMULUDQ and discarding the high bits.

(I tried commenting on his blog but it's awaiting moderation - I don't know if that's ever checked, or just sits in the queue forever)

Comment · 2 years ago

> Does every dev need to write the same line now?

Yes.

> Or should your one-liner be a library?

Definitely not.

Particularly if I can write the one-liner faster than it takes one to search, check, include and install the library.

Comment · 2 years ago

Yeah, you can write it in less than a minute:

const tryNew = (f, ...a) => {

  try {

   return new f(...a);

  } catch(x) {

   return undefined;

  }

 };

const myUrl = tryNew(URL, 'http://example.com/');

I don't get why JS devs like to whinge about the smallest things. And we get stuff like leftPad because of huge aversion to writing utility functions.

Comment · 2 years ago

Search engines: they scrape the web, but get narky when scraped themselves.

Comment · 2 years ago

Tangentially related, but I've had a case where GCC 9.4.0 shipped a broken arm_acle.h header [https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100985] - code which includes the header would always fail to compile.

Since users could be trying to compile it on GCC 9.4.0, and as the functionality dependent on the header isn't critical to the application, if the build detects the header is broken, it just disables the functionality and emits a warning.

Back to xz: If security isn't your top priority, it seems reasonable to just ignore the failure of an optional feature and just move along. Of course, in hindsight, it's easy to point fingers, but without that, it doesn't sound completely unreasonable to me.

Comment · 2 years ago

I think we're talking past each other a bit here.

If I were trying to phish someone, I wouldn't attack the public key crypto part, so how domains come into play during authentication doesn't matter. I'd just grab the "unencrypted" session token at the end of the exchange.

Even if you somehow protected the session token (sounds dubious), there's still plenty a phisher could do, since it has full MITM capability.

Comment · 2 years ago

From my understanding, FIDO isn't MFA though (the authenticator may present its own local challenge, but I don't think the remote party can mandate it).

There's also the issue of how many sites actually use it, as well as how it handles the loss of or inability to access private keys etc. I generally see stuff like 'recovery keys' being a solution, but now you're just back to a password, just with extra steps.

Comment · 2 years ago

The phisher can just pass on whatever you sign, and capture the token the server sends back.

Sure, you can probably come up with some non-HTTPS scheme that can address this, but I don't see any site actually doing this, so you're back to the unrealistic scenario.