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

27 unique levels. 40KB minus a handful of spare bytes and some unused code. The max the NES can support without mappers. Modern NES homebrew and demoscene can do fancier stuff with this budget given the extra decades of learned tricks, but for the state of console gaming in 1985, SMB1 is damn impressive.

Also remember all of that was ROM, the NES had a mere 2 kilobytes of RAM for all your variables and buffers.


Best (for older kids) would be a dumb cell phone like we had in the 2000s. Good for phone calls, texting, and simple offline apps like casual games, camera and music player. Maybe email. Definitely no web browser, youtube, or social media crap.

I don't know the extent to which such devices are still manufactured today.


There are: https://www.hmd.com/en_int/nokia-3210

(and it's not the only one, also check KaiOS phones)


Problem with f16 is that hardware support is still "new" and can't be relied on in consumer grade CPUs yet.


GP is asking about the text prompt itself, not the generated image. If pure text can qualify as CSAM in Australia then it's a logical question.


Really LLMed this one, thank you for pointing that out.


I believe this means "VBMACXOR16X16X16" is now officially the longest x86 mnemonic


It almost reads like "visual basic macro 16x16x16". And if you told me the x86 ISA had instructions to speed up visual basic commands, I would believe it.


Question: why did they decide to make /usr/bin the "primary" and /bin the symlink? Methinks it should have been the other way around as was the original Unix design before the split.

Also the first URL is serving me scam popup ads that do a crap job at pretending to be android system alerts. Next time please try to choose a more reputable source.


Using /usr/bin instead of /bin comes down to that is much easier to mount one /usr instead of doing bunch of bind mounts for /bin /sbin /lib /lib32 /lib64,

Also some more background info https://systemd.io/THE_CASE_FOR_THE_USR_MERGE/


There is some logical grouping. Everything under /usr is "executables+libraries+docs, mostly immutable" so there is some logical grouping.

Whereas /etc is for configuration and /var is for mutable data.


Thankfully it's trivially easy to disable OneDrive via the task manager startup tab. Never had any issues with MSFT sneakily turning it back on either.

This super aggressive OneDrive shit is also why I've stopped putting most things in the standard folders and now just have my own alternative hierarchy in %USERPROFILE% instead.


And on macOS if you need bash > 3.2


What is the alternative to PGP for the specific use case of secure email? That doesn't mandate dealing with the X509 certificate bureaucracy?



The only alternative suggested by the linked article is giving up email completely in favor of centralized solutions like Signal. My short answer is “no”. My long answer is: <https://news.ycombinator.com/item?id=45390332>


I wrote the linked article. I don't care what secure messenger you use. But if you choose encrypted email over Signal because "centralization", you're LARPing. The first criteria for a secure messenger has to be that it is plausibly secure, and email isn't. You'd use encrypted email (for "decentralization") because you understand the cost of losing the plaintext of your message is nil. If you tell strangers to do that, without certainty that their messages are also valueless, you're committing malpractice.


Something that doesn't require securing email. Both S/MIME and PGP were solutions for 1980s problems (TFA is slightly off about PGP's start date, the PGP design dates from 1987 and MSDOS, not the 1990s, and S/MIME via PEM is from 1986). They're pretty much irrelevant today because almost all email is encrypted anyway via StartTLS and if you need full end-to-end encryption you use Signal or something similar.


What's your usecase here? Internal or external messaging?


Use case? We're crypto LARPing dammit, we don't need a use case!


As long as you don't have any security compliance requirements and/or can afford the cost of self hosting your LLM, sure.

Anyone working in government, banking, or healthcare is still out of luck since the likes of Claude and GPT are (should be) off limits.


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

Search: