Hacker News new | past | comments | ask | show | jobs | submit | bwoodward's favorites login

NTSC being 60Hz and PAL being 50Hz, there is compensation implemented in code such as shorter autorepeat delay (16 to 12 frames) and rate (6 to 4 frames), as well as gravity drop speed past level 10 (-1 frame) to keep the gameplay sort of similar to casual players.

But then details matter at these insane player levels, NTSC is 1 row every 2 frames on levels 19 to 28 then 1 frame starting with 29, but PAL is 1 row every 1 frame ever since 19, so given that frames are not the same duration PAL is comparatively harder than NTSC starting with 19 but easier starting with 29 (... provided one can survive up to that).

So wall-clock PAL gravity ends up being 1.25x faster than NTSC (but with quicker DAS: 1.5x faster delay, 1.33x faster movement), then at 19+ is 1.67x faster, then at 29+ 0.8x "faster".


Somewhat surprisingly, Linux support for Apple Silicon MacBooks seems to be shaping up to be better than that for pretty much any other laptop. The Asahi team don’t have support for everything yet (notably no GPU) but what they do have support for seems to be high quality, well integrated with Linux’s conventions, and upstreamed into the mainline kernel! How much other hardware can claim that?

The Asahi developers have also stated that Apple tends to keep hardware peripheral interfaces stable across generations (they speculate that this is to keep things easy for their own OS dev teams), and that this has so far proven to be true for M2 (and several iPhone generations before that), and thus once support is available , it should stay relevant for some time.

Given this, it seems like MacBooks could easily end up becoming the laptop of choice for Linux developers in the years to come.


Yes! I've been begging for this for years. It's IMO the biggest enabler of phishing out there.

Every time I give a talk on DMARC, SPF and DKIM people seem generally unaware that any IP address can send email claiming it's from your domain until you have explicitly turned it off.

By default all domains should come with a strict reject policy on email until you intentionally turn it on. I usually go through this example with my fictional pirate themed gym, Slimmer Ye Timbers.

Go turn off email for all of your currently unused domains. If you don't, odds are high that phish are using them.

Just go set an SPF and a DMARC entry. You can look at slimmeryetimbers.com for an example.

_dmarc.slimmeryetimbers.com. 5 IN TXT "v=DMARC1; p=reject; aspf=s; adkim=s;"

slimmeryetimbers.com. 5 IN TXT "v=spf1 -all"

Looks like the article goes even further, but I'm not sure the extra steps they are taking are necessary.


This commit in the PR

https://github.com/obsproject/obs-studio/pull/5875/commits/8...

provides an excellent example of why commit messages matter. This is more than 1000 lines diff to the build system (and thus potentially very dangerous because of possible supply chain attacks) which has the commit message of

"CI: Update build scripts and Github actions workflow"

Never say what you ware doing (it's obvious this commit is updating build scripts). Say why you are doing it, especially when your commit feels unrelated or at most very tangentially related to the objective of your PR.


Regarding the histogram issue, I worked on a project that had a few hundred histograms based on data from over 3 billion data points. It turns out that after a few thousand data points many histograms will stop changing significantly.

So, unless you really need to show exactly how many data points each bucket contains, it's much easier to run the analysis once offline, then serve just the histogram percentage data. From that you can make an SVG and overlay additional user-specific data on top. The point is that this histogram data is small and easy to cache.

You can then rerun the histogram analysis later if you'd like. However, for this project I never saw anything change with more data. It was overkill even to run it as a cron job.


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

Search: