ryanschneider
ryanschneider on Hacker News
I'm only going to skim any subthread that gets into "next token predictor" territory, but for anyone looking for a somewhat deep video about _why_ this view is wrong Casey Muratori and Demetri Spanos spent almost two hours on the subject recently:
https://www.youtube.com/watch?v=aQvSG8paVjMA couple of highlights to pique people's interests:
- Attention is kind of like "Global Illumination" for next tokens (they both have a game dev background)
- Attention is constantly being recalculated _for the next token_. This part never "clicked" before.
- LLMs are "next token predictors" in the same way that games are "next frame predictors".
Semi-related, but I was just thinking today I wonder what sort of performance improvements, if any, one could see by having one of the frontier models build a operating system from scratch that targets the subset of imports WINE uses as the standard library? Basically, build whatever syscalls (or shims) WINE and the open source vulkan drivers need and nothing more.
Probably outside the scope of what an individual could pull off on thier own in a reasonable time, but I could totally see for example Valve considering that approach for a later iteration of SteamOS.
> I trained a 125M model to autocomplete piano on-device
I first parsed the "on device" as _on the piano_ and was intrigued how that worked :) maybe someone can make "dynamic" rolls for a player piano somehow (like one of those braille "screens")?
The trick I learned from a kind manager is to make your last day something early in the month and your first day on the new job the last week of the same month. In short if your time off doesn’t actually cross a month boundary your old insurance will still be in effect.
Just make sure when doing so you don’t work at the sort of place that’ll let you go as soon as you put in your notice.
Wait am I in the minority talking to Claude in markdown? I just assumed everyone does that, or at least all developers. It seems to work really well.
A reverse engineer friend once taught me I could patch an x86 function with `0xEBFE` to get the CPU to spin forever. It wasn’t until much later that I understood that (IIRC) 0xEB is the “single byte” jump instruction and that of course 0xFE is -1 as a signed byte. Hence the spin.
Even cooler, let's say you need to "update" a subset of your parquet files after they are written. Once you have your parquet files in a ducklake, you can "virtually" update them (the files themselves aren't touched, just new ones created). Something like:
- create your frozen ducklake
- run whatever "normal" mutation query you want to run (DELETE, UPDATE, MERGE INTO)
- use `ducklake_rewrite_data_files` to make new files w/ mutations applied, then optionally run `ducklake_merge_adjacent_files` to compact the files as well (though this might cause all files to change).
- call `ducklake_list_files` to get the new set of active files.
- update your upstream "source of truth" with this new list, optionally deleting any files no longer referenced.
The net result should be that any files "touched" by your updates will have new updated versions alongside them, while any that were unchanged should just be returned in the list files operation as is.
Not that I expect them to fix it at this point since it seems to be a known issue, but just in case anyone from Notion is watching please fix the macOS app’s CPU usage. On a brand new M3 MacBook Pro each tab takes about 10% of one core _non-stop_ even in the background. I have to constantly cull tabs or my machine becomes noticeably less responsive.
It’s fun to guess what something is on HN just from the title before going there or the comments. In this case my guess was that someone was
- rendering Doom then using an LLM to get a text description of the scene
- asking the user what to do
- converting their text action into a couple seconds of doom input
- re-render and repeat until dead or stage clear.
I was wrong but still fun to think about!
I really thought this was going to be a new LLM-backed GOOG-411 type thing.
Aha! This post finally made it click for me that that is exactly what’s going on, thanks for putting it so succinctly.
I think one of the big differences between AI and most other previous technologies is that the potential impact different people envision is very high variance, anywhere from extremely negative to positive with almost all points in between as well.
So it’s not just different risk tolerances its also that different people see the risks and rewards very differently.
As other have mentioned I’ve used it for diagrams in code comments and READMEs (before GH added mermaid integration).
Making readable diagrams with 80 character width can be a challenge.
I bought it back in either late 2017 or early 2018 and used it a fair amount at first but will admit it’s been a couple years since and haven’t tried reinstalling since my last clean OS wipe.
Seems like the technique only works in highly controlled scenarios (e.g. you have tens of phenotypes and images and want to have a better than random chance of assigning one to the other):
> Nevertheless, re-identification risk in the wild does not appear to be especially high. While we observe a success rate as high as 25%, this is only achieved when the genomic dataset is extremely small, on the order of 10 individuals. In contrast, success rate for top 1 matching drops quickly and is negligible for populations of more than 100 individuals. Moreover, it should be kept in mind that this result assumes that we can predict the phenotypes perfectly.
I just wish they would make more compact shows that tell their entire story in a single self contained season. If 1899 for example had only been given a single season from the outset it actually might’ve been a much better show.
I just took a break from reading a scene from Anathem revolving around tiling and came across this thread. :)
This sort of “HN coincidence” has happened to me several times this week, is there a term for it I don’t know?
There’s actually a lower bound for integer ops:
https://twitter.com/DavidVorick/status/1719097248699879831
> (i) any model that was trained using a quantity of computing pow greater than 10^26 integer or floating-point operations, or using primarily biological sequence data and using a quantity of computing power greater than 10^23 integer or floating-point operations;
It probably matters for Go since presumably the go runtime starts up some of it’s worker threads before calling your main. Though actually now I’m not so sure, seems worth digging into.
iPhones and iOS have had this for quite awhile. My iOS dev knowledge is rather dated now but IIRC Grand Central Dispatch let you indicate the type of workload your task needed and thus which core type it was typically scheduled on.
I think the whole point is that you only have a limited “cutting edge budget” so if you are somewhat forced to spend that budget on cutting edge ML models then don’t overload your team _also_ using cutting edge languages or infrastructure or databases.
So save your budget for what will really make your product unique instead of “wasting” it on things that in the end won’t give you a real competitive advantage.
I’m in the same boat in that I’m losing my vision very slowly from an inherited retinal disorder. One thing I’ll add is I’ve started going to the gym as much as I can while I can, I figure I’ll be much more confident once blind if I have good core strength, and it’s probably much easier to learn good gym habits while sighted.
While not in the same league as those tubs, when we first signed up for Fresh Amazon was using frozen Amazon-branded bottled water to keep the groceries cold. They switched to insulated bags a couple weeks later though, but we had plenty of free bottled water for a bit.
I was just thinking this weekend about that in fact: was wondering who’s idea it was and if they got recognition for the idea or not.
Quick feedback: I really thought the “ROI Calculator” on your landing page was meant to be interactive not a screenshot so was wondering why it didn’t work. Any chance it could easily be made interactive by embedding the actual software there?
One more wrinkle: authorization starts with “author” but in computer security is no longer about who wrote the data but rather if they are allowed to. It has its origin in “to determine the author of” but the modern usage is at least twice removed from that, in that it’s really checking if the _token_ was written by the _system_ not if the user was the content author.
I think the problem is further compounded by team size and insistence on 40 hour work weeks. As soon as you have people on “manager schedule” that feel the need to look busy the number of meetings starts growing exponentially. I’m all for having enabling people on the team, just don’t expect them or anyone else to meet an arbitrary amount of hours per week quota.
One thing I really really miss from working in person on a small team was that we did all PR reviews in person, almost like a little “thesis defense” session. This was medical adjacent signal processing software so that rigor was necessary, but it really helped make sure we all knew exactly what was changing and why, as part of the review was going over any output changes in our test corpus and making sure they were all for the better and understood _why_ an output value changed.
You just can’t do that async inside a GitHub PR to the same level.
Good call, I use “minor:” as a comment prefix for this but just realized that I got into that habit awhile back and the team composition has changed since then so newer members don’t have that context.
I wish there was something like semantic commits “fix/feat/chore” for review feedback, specifically a keyword for these little things that are more future advice than must fixes.
I also try to be clear when I don’t expect to do a second review if they make the minor changes, that the green check mark carries forward.
More. broadly I’ve been trying to favor “rough consensus and running code” in my PR reviews, even if I don’t fully agree with an approach I’ll give the writer the benefit of the doubt since they’ve most likely spent more time thinking about the problem than I have. Or at least that’s my hope!
I’m pretty sure I first heard this anecdote in Andrew Ng’s original machine learning course on Coursera.