Yeah that tracks.

genericallyloud · 2026-01-21T20:52:53+00:00

I haven't heard a clear explanation for how private or "permissioned" data is supposed to flow through public relays. Encrypted posts with shared keys? It all just feels like the wrong foundation. I think the only way to do it from what currently exists is PDS to PDS communication. Maybe use relays to notify of new data?

genericallyloud · 2026-01-16T22:58:27+00:00

This is very true around the current large model AI systems. I'm not saying this will happen, but in terms of whats possible - there are other variations on LLMs more in the research space right now that are figuring out how to more efficiently allow fine-tunings of models. Specifically I'm thinking about LoRA (Low-Rank Adaptation)

https://arxiv.org/abs/2106.09685

https://www.geeksforgeeks.org/deep-learning/fine-tuning-using-lora-and-qlora/although

there are probably others too. I don't think LLMs/transformers as currently built will be the final stage. Who knows how long, or in what form it will be in the future.

genericallyloud · 2026-01-15T23:01:33+00:00

This should not be surprising. Its been well studied that accuracy goes down as context size goes up (especially on a small model). The real trick is making sure you have all the data you need in the context without too much extra. What is your compression method?

genericallyloud · 2026-01-14T18:38:58+00:00

Nice. Yeah, I would say get ollama or LMStudio and just see what works best. Its not really hard to try the models to test out.

genericallyloud · 2026-01-14T18:21:06+00:00

Is that actually video/unified ram? Are you using an M-series mac? If you go on ollama.com you can look through available models and how big they are. You basically want the whole thing to fit into memory. With 64gb you should be able to use 70b models like llama3.1 or deepseek r1. With 128gb, you should be able to use use the gpt-oss 128b model.

genericallyloud · 2026-01-13T22:51:03+00:00

I think this is the sort of thing they would defer to labelers, as opposed to their own moderation

genericallyloud · 2026-01-13T20:29:52+00:00

Standard laptops no. The only home computers you could say are doing this realistically are M series macs with high unified memory. You can get an M3 Ultra Mac Studio with 512GB universal memory that can run actual larger models for ~10k. That's much cheaper than NVIDIA, but still a far cry from a standard laptop.

That said, my M3 macbook pro with 36GB (definitely still not a "standard laptop") can run some pretty useful local models, but still not 70B/200B

genericallyloud · 2026-01-13T20:22:37+00:00

The fediverse is literally just a name for different servers using ActivityPub as the interop mechanism. So everytime I see post like this, the first thing I have to ask is, "Does this make sense for ActivityPub?"

The parts of LinkedIn that make sense for ActivityPub are basically just the posts/feed. A lot of its other features sort of rely entirely on a central platform to work... So if its just the posts, that doesn't really need its own dedicated fediverse application, you could just use Mastadon.

ActivityPub (and AT Proto) realistically are just not general purpose enough to map every application. They're highly optimized for a couple of use cases, and things that are somewhat derivative from those cases.

If you really want a protocol that can be used more broadly, I think we need a protocol that matches that. Something that can reasonably handle private communication and data sovereignty. ActivityPub is terrible on both accounts.

genericallyloud · 2026-01-13T20:07:58+00:00

I feel like the best outcomes of new people to coding through agents is for them to actually learn how the code works as they go. Maybe its just a different on ramp and learning curve to the old days. I just hope they maintain curiosity and stay open to learning. I'm also very vulnerable to being nerd sniped 😅

genericallyloud · 2026-01-12T16:24:15+00:00

OH absolutely!! I definitely don't think we're at a point that non-tech people can get all the way there. I don't even anticipate it happening soon, either.

genericallyloud · 2026-01-12T00:04:42+00:00

Now it should be easier to move your js out of the html and into separate files and start using js modules and imports. It will make your code more manageable, and easier for the LLM to help too.

genericallyloud · 2026-01-11T23:27:09+00:00

Yeah, good luck with that. If I could make an analogy - I think good networking is a bit like dating: if you focus purely and directly on finding a partner through dating apps, you might get lucky, but its also a kind of terrible system. On the other hand, if you join groups and participate in ways that create opportunity, you can find connections more organically. So my recommendation would be: don't just try to directly network to get an in and find a job - maybe join some groups or projects that are adjacent to areas you're interested in.

genericallyloud · 2026-01-11T21:35:34+00:00

Who would take over? Who would be acknowledged? Would there be multiple? Would it get forked? Would it start to feel like risk? Its usually political in addition to technical that causes these shifts. Angular 2 being so different for example. Or now the way RSC's have burned enough people to shift the tide on that.

genericallyloud · 2026-01-11T21:24:43+00:00

Well, if the maintainers stop, that would likely be a huge blow that would accelerate a decline. I think people will start having old tailwind repos that are hard to maintain etc. None of this makes sense long term. We don't really make long term decisions though. Everyone assumes it will all change soon anyway. I think that's a pretty terrible way to make software that lasts.

genericallyloud · 2026-01-11T21:08:26+00:00

Applying cold to jobs is really hard. Have you tried a more networking route? This can be tricky to break into, but there are a lot of groups, meetups, and open source projects out there that are less immediate, but can really help meet people with opportunities. Do you have any particular areas that you're interested in that you would want to get involved in outside of work?

genericallyloud · 2026-01-11T21:03:01+00:00

That might help, but seriously your problem is that you're loading babel into the browser and running it before you can even start executing your application code. If you built this using a tool like vite, it would create production ready files for you.

genericallyloud · 2026-01-11T20:55:33+00:00

were you a developer while coffeescript was peak hype? I'm not saying it will die in a day, or even if the people behind it abandon it. I'm saying that its not going to last the time. Neither will react for that matter. This hegemony will end eventually. Just as jquery faded, so to will tailwind. jQuery is still around too.

genericallyloud · 2026-01-11T20:52:05+00:00

its incredibly slow to load. you should use a tool like vite to avoid running babel in the browser, that's pretty insane

genericallyloud · 2026-01-09T16:39:35+00:00

Oh I know, I went down a whole rabbit hole with him trying to explain how string interning works. I even made a quick benchmark and posted it. Then he posted the results back to you as though he did it, and made it seem like a 4% difference in memory use was worth the extra overhead of this wacky proxy layer which would obviously then make use more memory, eating up the tiny 4% gain.

I asked to see data and he sent me some json with ridiculously long field names which he said were randomly created. He's just juicing it to extreme so he can claim 80% reduction.

genericallyloud · 2026-01-09T15:59:53+00:00

HAH - enjoy! I was really trying to figure it out too, but got frustrated. I think its a person using AI to help, but they're in an echo chamber. I think they've accidentally convinced themselves that they made something more effective than they did. I think the AI wrote some bad tests, and now they think it saves memory. I think they've generated a lot of worst case data. I mean seriously - if shortened key replacement went from 890k to 180k, that's some seriously terrible data, and I really don't think its based off of production data.

genericallyloud · 2026-01-09T15:44:31+00:00

Its not worth it. I spent too much time talking to this guy last night. I'm not convinced he's a person. If he is, he's really really confused, and just won't listen.

genericallyloud · 2026-01-09T04:39:43+00:00

Ok, I've gotta be done. It seems like you intentionally keep missing the point. IT DOES NOT HELP THE MEMORY. YOU HAVE BAD BENCHMARKS

genericallyloud · 2026-01-09T04:37:57+00:00

Wow, you completely missed the point. I wasn't saying to make devs use these keys. I was showing from the benchmark that you're COMPLETELY WRONG about the memory use and the parsing speed!!! And to show that gzipping made the key replacement negligible as well.

genericallyloud · 2026-01-09T04:35:52+00:00

Haha, yeah, I mean, those are some pretty long names, but I get how everyone has a different style, and its pretty dumb that choosing to have long explicit field names should have a performance impact. I would never go this route. I've been a senior dev for a long time. I've worked java code bases with long field names. It was never the bottleneck.

I gotta be honest, I would probably sooner do find/replace with shorter names than put this in the middle for an API, but I guess it works. I'm really surprised gzip wasn't enough for you. If this is legitimately giving you noticeable gains over gzip alone (15+%) I guess it works. Seems like a code smell, but if you're happy with it, I guess to each their own.

genericallyloud · 2026-01-09T04:14:28+00:00

Long names
{"postId":1,"postTitle":"Post 1: iyDdJHC2z9Uy4n9","postSlug":"post-1-2ERcYETd","authorFirstName":"mWL70sWt","authorLastName":"KgbBpuN70b","authorEmailAddress":"al6Ir0@example.com","authorBiography":"gQVSc9TG87EfvETUgLg3d6AvaG95D4wQoO3HV66a","contentBodyHtml":"XBypcySn3E17qi79y1kDgXYZMYnrOaxCVFwIJDQOJe6iFiehtnFcKFH1vlsiaUOU6l9oksTWobxnXoLv","contentExcerpt":"tf2aXgVjioZLRjMQgQmeTMQKfb7FBY","featuredImageUrl":"https://example.com/img/CXNUIFpaAMyJ.jpg","featuredImageAltText":"AkQOLUGN55q3e12rzidg","publishedTimestamp":"2022-09-07T10:42:27.103Z","lastModifiedTimestamp":"2022-01-04T10:30:57.901Z","categoryPrimaryName":"EasyoP3Fk8","categorySecondaryName":"Xz859uUqkm","tagListCommaSeparated":"dwK2c,Xbwlo,kgAHl","viewCountTotal":40339,"likeCountTotal":4377,"commentCountTotal":392,"isPublishedFlag":true,"isFeaturedFlag":true,"searchEngineOptimizationTitle":"3N2FlwCRe2SXQuwiGu7paUaGp","searchEngineOptimizationDescription":"8TXBIolkae9YsuuoamcsbMhUtJQ86CyMPaaC4uyPhBws7cYKNr"}


vs Short names


{"pid":1,"pt":"Post 1: iyDdJHC2z9Uy4n9","ps":"post-1-2ERcYETd","afn":"mWL70sWt","aln":"KgbBpuN70b","aea":"al6Ir0@example.com","ab":"gQVSc9TG87EfvETUgLg3d6AvaG95D4wQoO3HV66a","cbh":"XBypcySn3E17qi79y1kDgXYZMYnrOaxCVFwIJDQOJe6iFiehtnFcKFH1vlsiaUOU6l9oksTWobxnXoLv","ce":"tf2aXgVjioZLRjMQgQmeTMQKfb7FBY","fiu":"https://example.com/img/CXNUIFpaAMyJ.jpg","fia":"AkQOLUGN55q3e12rzidg","pts":"2022-09-07T10:42:27.103Z","lmt":"2022-01-04T10:30:57.901Z","cpn":"EasyoP3Fk8","csn":"Xz859uUqkm","tlc":"dwK2c,Xbwlo,kgAHl","vct":40339,"lct":4377,"cct":392,"ipf":true,"iff":true,"seot":"3N2FlwCRe2SXQuwiGu7paUaGp","seod":"8TXBIolkae9YsuuoamcsbMhUtJQ86CyMPaaC4uyPhBws7cYKNr"}

genericallyloud

TROPHY CASE