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

> How about case-insensitive filesystems? [...] Negligible.

I don't buy this. Finding collisions is pretty easy. In one repository I have these files:

  rank2.cpp
  rank4.cpp
  rankN.cpp
The last two have the same case-insensitive Base84 encoding:

  mz{QkARW;1cB
  mz{QkaRW;1cB

> I really like this website design

Reading it on my phone, I beg to differ.


The mobile design is compromised as hell, it looked worse before.

I could probably figure out a way to make mobile work with some time but I don't care enough for my blog. It's just Markdown docs and some styling.


Doesn't pressing "back" in the browser repost the same message?

Ideally browser history hacking will reduce that.

https://developer.mozilla.org/en-US/docs/Web/API/History_API


How do you decide who is going to pull the tokens?

And how do you decide who is going to throw that one die?

That's why you need those 5 dice to decide it.

Literally doesn't matter, player closest to dice at the moment you open the box.

> this is just structs.

Yes. And structs are just bytes. Levels of abstractions don't do anything the underlying levels don't already do, they just give you means to express your intent in a clearer form.


But there are "cubic bazillions" of possible URLs that are being requested. Even if they boil down to "only" some millions actual commits, their rendered HTMLs are all different.


Yes, this is very difficult to solve for sites with many URL variations, like git repos and heavily threaded forums. Your cache is always full, but the hit ratio is abysmal.


remember, its only difficult for you. at the end of the day its just 7gb of data...


no its only difficult for you. and only at this moment... any minute now you will see the way. btw, the OP is just saying "its OK for now". And the OP is just telling us: this is what has been happening... maybe its difficult for OP also, but they didnt say that. they just said their current setup cant handle it. old tech...have a hackathon to solve for this. OP says it's not a problem for him right now but if we extrapolate what he's talking about it's definitely a problem aaaaaaand It's totally solvable, Even with all of the crazy combinations he's talking about it's still solvable. And it's already been solved using patterns we see in streaming services. This is completely hackathonable. but why do we even need to bother with this? The slurpers are the cause of this, and they can cause this problem because of Murphy's Law. well you can only account for Murphy's Law with good architecture or something like that or whatever. Ha ha hackathon.


have a hackathon to solve for this. OP says it's not a problem for him right now but if we extrapolate what he's talking about it's definitely a problem aaaaaaand It's totally solvable, Even with all of the crazy combinations he's talking about it's still solvable. And it's already been solved using patterns we see in streaming services. This is completely hackathonable. but why do we even need to bother with this? The slurpers are the cause of this, and they can cause this problem because of Murphy's Law. well you can only account for Murphy's Law with good architecture or something like that or whatever. Ha ha hackathon.


Tangent question: what about NPU performance? I always read about CPU vs GPU, but nobody talks about NPUs; I don't even know if llama supports them.

Why do phones and laptops get equipped with NPUs if there's no use for them?


There are uses for them but as a sibling comment mentions they're currently extra work to target per vendor. If you squint a bit they're all basically stripped down GPU compute elements with everything except the matrix multiplication hardware removed, a few MB of cache, no RAM of their own, and a nonstandard API.

OpenCL and Vulkan are supposed to gain support eventually but given their extremely constrained instruction sets and the wide variance in capabilities between different hardware models I don't imagine they're the sort of thing you'd want to target manually.


NPUs, at least for apple, are built for relatively small scale efficient background processing. Theyre taking care of extracting structured metadata from freetext, recognizing people & text in photos, indexing file contents, etc. they do this really well with crazy low power draw. Theyre generally not even a target for current inference frameworks ala ollama, pytorch, etc.

I did see one prototype someone built using private ios APIs a few months back. They were able to run a reasonable SLM about an order of magnitude slower than GPU but with a tiny power draw.


I dont think llama does. There has been some work. They were originally designed for image processing (remove background from calls) and many exist because Microsoft mandated them for "AI laptops". Often they don't have much memory bandwidth, and are limited in compute and they are all incompatible with each other.


This is for iPhones only. Do I assume correctly that the issue is solved for Android, instead?


Mightytext does some of this for Android phones: It lets you read and send SMS on your phone from your computer. It also shows notifications from your phone when they happen. It's an app on your phone and a website on your computer.

No affiliation; just a satisfied user.

I don't use Mightytext a lot any more except for 2FA since I mostly use Signal for messaging. And of course Signal has an Electron app for desktop that works for both text and voice.

For file and photo sharing I just use Dropbox. I have Dropbox on my phone set to upload photos as soon as I take them, which means they also show up immediately in a folder on my desktop (on MacOS. I assume this works in Dropbox for Linux but haven't tested it.) Caveat: Dropbox still doesn't support ARM Linux. It's Intel only. WTF Dropbox??


Also curious. I keep messages.google.com in a pinned tab but the number of times I have to go find my phone and re-authenticate is too damned high.


On Android, you can use KDE Connect on KDE and GSConnect on GNOME. It has a Messaging app that syncs with your phone's SMS.


I don't know the specific ones, but there are android apps that replace Google Messages (dark pattern warning: enabling this makes your previous messages inaccessible as Google Messages won't let you read them unless it's your default SMS app) as well as apps that can send and receive in parallel to Google Messages. I'm not sure if there are also apps that can read your message history out of Google Messages.


I've been using SMS Backup & Restore (from SyncTech) for years - it reads full history out of Google Messages any time I've used it.


If your first word is four greens it's actually pretty good: you get to know four letters to avoid with just one undo!


Sure, but if you count undo as a partial game over (which is heavily implied), it's better to just be able to see what the word is and move on.


> count undo as a partial game over

Not at all. Contrary to other games where undos are cheating, here they are part of the game. Without them it would be 80% luck and only 20% strategy.

> which is heavily implied

I can't find anything that implies this. It explicitly says:

> This uses undos deliberately rather than only as an emergency

while avoiding undos is mentioned at the end as "The Purist approach", which I read as slightly mocking.

I see it like a chess problem where you have to find the best sequence of moves, so you start off with an intial move, then backtrack, explore another idea, etc. Not like a chess match where of course you cannot undo any move.


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

Search: