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

New tools are cool, but from what I have seen jj is literally just git with aliases

If down the line this model could create 3D model from 2D images that would be very neat way to pay less for war gaming models

Gaussian splats and neural radiance fields already exist.

I dont know how that solves this. How do you get STLs out of gausian splats?

Not splats as such but text to polygon model and image to polygon model exist and for the use case of figurines that's fine to convert to formats for 3D printers.

You can already do this with apps like Kira. I believe it is especially good on the iPhone variants with LiDAR.

I dont know that app specifically, but from all videos of different lidar and other 3d scanning tools I have seen the results are pretty bad and require a lot of sculpting after the scan. Whole point was that with few images the ML model could construct the actual 3d model for you

Already done. Cults generally has stls of 40k models before release. Its just a matter of finding them.

doesnt really help if I cant find them and I guess if I could find them so could GW and they would be taken down. Having an application you can host at home that could do the job from pictures would be awesome

Cults used to be really good at avoiding this stuff, but Scrungaloids, which is just a parody of 40k that apes some rogue trader aesthetics got nuked within 48 hours of going live on cults so the dream seems to be dead.

How you burn 300 requests in a day? From my Copilot usage Opus consumes surprisingly few requests to do a lot of stuff. It isn’t paying by token but instead by prompt or something.


If you are using subagents for asynchronous work, you can burn through 300 requests in a workday easily.


Copilot didn't charge for subagents. You could do an insane amount of work with dozens of subagents with a single request and a deep enough prompt to kick it off.

I setup entire virtual teams (Dev, QA, product, reviewers etc with the initiating model just acting as the agent manager to keep it's context minimal) to one-shot some stuff and it kept churning and making progress.

Those days are just about over with the change to token pricing but for a time....


I guess you need automation for that. Run claude with cron to find fulnerabilities, suggest and implement improvements, automatically dig through backlog


Hope people doing those kinds of automations are paid to waste prompts and tokens. Any cron based LLM run is just stupid waste


Copilot charges a 27X multiplier on Opus 4.7 prompts.


Review-fix rounds after generation of text or code, until convergence to a solution that doesn't need more improvements.


You are prompting the same model to review what it just did?


300 prompts in a day isn't that unreasonable to achieve on a heavy day? And Opus has a significant multiplier as well


That is a lot of prompts. What kind of prompts do you usually give?

Mine are usually giving specification and telling Claude to implement some part of it, referring to existing code base, writing unittests and running e2e until it passes. This can easily take 4-5 hours.

Then again, I have seen colleagues prompt “are you sure?” And other nonsense like that


I think we use it differently then, I tend to go heavy on the back and forth.

For speccing things out, I have a back-and-forth with the grill-me skill, break things down into tickets, as well as kicking off subagents. That said, I significantly overestimated the number of human messages I send.

My daily 90th percentile wrt number of prompts sent is sitting at 160 queries / day and average at 97 queries / day.

Ran an analysis of my last 2000 messages, with the following breakdown

Task delegation / execution: 23% Investigation / diagnosis / “what’s going on?”: 21% Planning / architecture / brainstorming: 15% Testing / verification / release ops: 10% Review / cleanup / quality control: 9% Course-correction / constraints / preferences: 8% Agent / ticket / workflow orchestration: 6% Providing context / evidence / pasted material: 4% Social reactions / acknowledgements / vibes: 2% Other: 2%


Yeah that’s not good for current Copilot usage since you are paying per request not by token


Yeah, copilot is only my backup - Codex and Claude are my primary, where it's per-token. Just looked up my user prompt count from my opencode db


Yeah, thats 20 Opus 4.7 prompts.


Opus 4.7 has a 7.5x multiplier when it's used from Copilot. Falling back to 4.6 it's only 3.5x


It recently went up to 15x in our org.


Because there is no negatives, only positives.

I can maintain the Python code myself and I can execute it everywhere.

If I let my LLM write in Rust then when things break I am out of luck. Also Rust needs to be compiled which means I can't just share the code as freely.


>I can maintain the Python code myself and I can execute it everywhere. [and share it more easily]

Python can be kind of a pain in the butt to execute everywhere because of libraries. I thought uv script headers and she-bang was going to fix a lot of that, but I'm still running into issues (machines firewalled off, uv can't grab the deps. I have some code that just doesn't seem to work in uv on a Mac...). And for sharing code once the code splits out into multiple files and modules, sharing the code starts looking like sharing any code.

Don't think I'm a Python detractor; I'm a PSF Fellow, I love Python, and Claude has been writing quite good python for a while here. But I just tried a serious project with Claude writing golang (an apt proxy/cache that is resilient against upstream DDoSes, a fairly complex piece of software), and I must say it did a fantastic job. I end up with an executable I can easily run and copy around.

I'm still going to be using python for a lot, but I can definitely see myself having Claude write golang for more things in the future.


Is this actually dithering?

I have dabbled with some dithering algorithms and while this is way faster than my naive js implementations, this looks pretty bad


Yes it is dithering. Unusual dithering though - I don't see why it is coloured. Is this intended for printers?


The image gets de-saturated but the noise that's mixed in is colored. This looks like a mistake.

I think the noise is also way too 'soft'. At high frequencies it just becomes near-uniform gray so it barely affects the thresholding.


Yeah they could add grayscale to the filter rule to make the colors go away.

  #dither-demo img.dithered {
    filter: url(#dither) grayscale(1);
  }


Maybe hot take in this age, but loot boxes for cosmetics aren't a problem when you can get cosmetics by just playing.


There's a lot of evidence showing that gambling as a child leads to gambling problems as an adult, and loot boxes are just gambling aimed to a large degree at children.

Valve games are even worse for this because Steam trading allows 3rd party sites to sell cosmetics directly for cash, and some of these cosmetics are worth tens of thousands of dollars. It's just children gambling money but with a thin veneer of video game over the top.


Almost every game that has lootboxes, even only for cosmetics, is super stingy with cosmetics you can earn in-game through normal gameplay.


And I see no problem with that. I have never bought a single skin for Counter Strike nor Team Fortress 2 and I have bunch. Well, I used to, but then CS2 came out and all of a sudden my skins and unopened boxes were valued at hundreds of euros and I sold them on steam.


If you think enabling childhood gambling addictions and unregulated gambling systems aren't a problem then I don't know what else to say to you. Lootboxes are gambling, plain and simple.


Let’s put age limit on gaming then.

Gamblers will always find a way to gamble. I like getting cosmetics for free even if they are randomized. I don’t think I have ever bought keys to loot boxes, I just don’t see the point.


That's not the problem. Valve enabling people selling them for real money is.


Even in these comments I keep hearing the same complaint: "when you do open source people come asking for support and complaining about your software"

I don't get why this is such an issue. You can just ignore these people if you don't want to interact with them. You shouldn't take bug reports or support requests personally.


That is just being pedantic. Why did they absolutely need to release this into the wild now? Why couldn’t they have waited?

“30 days should be enough time” why? Why is 30 days a magic number? Especially in open source.

Yeah it isn’t the researchers problem to tell every distributor of the kernel about the fix or verify that everyone has the fix, but fuck maybe wait until at least someone has the fix and maybe don’t drop it on a Friday. That is just malicious


They didn’t release anything into the wild. It existed. The irresponsible thing would be letting it keep existing without telling anyone.


You cannot deny that telling the entire world about this vulnerability before it is patched won't cause a lot of abuse that would not have happened otherwise.


AFAICT it was a Linux kernel maintainer who first "told the entire world about the vulnerability" on 2026-03-31: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryp...

The CVE was officially announced on 2026-04-22: https://lore.kernel.org/linux-cve-announce/2026042214-CVE-20...

Theori were simply the last team to publicly disclose the vulnerability on 2026-04-29, 37 days after reporting it to the vendor. They were simply more effective at communicating it, and they told you that you were vulnerable. That's why you're mad at them instead of the people who put the bug there in the first place, didn't bring its severity to your attention, and silently sat on the patch.


I do deny that, mostly because we’ve entered the time of automated vulnerability detection and abuse. A human need not be in the loop at all anymore.

But, even if I agreed with you, how do you propose they tell the patchers this that doesn’t tell the whole world?


Why not?


So why not just tell immediately on discovery? After all every flaw exists already so what’s the difference?


That would have been fine too?


What number of days do you want? If nobody tells the distros it could be months or years, and while it would be nice for the researchers to monitor/notify distros it's really not their job. They might not have thought of it.

And they dropped it on a Wednesday.


Yes. I misspoke. It dropped very very late on Wednesday, most of the work started on Thursday and Friday was a Mayday which is a holiday in many if not most places. So fine, on a technicality it wasn't a Friday release, but it might as well have been. They could have easily waited for Monday.


This is really stretching. Releasing very very late on a "Thursday" is fine. That gives you an entire day to pause everything else, set up mitigations, and see if things still seem to be working. If a whole work day isn't enough then you were probably going to have trouble no matter what day of the week they published. Late late "Thursday" doesn't have to be your favorite but it's not malicious.

Also it was evening UTC but only like noon Pacific time.


As someone who used to do this. OpenAI models refuse to look up calories unless you explicitly tell them to and even then it is a hit and miss even if you tell them exactly what the product is. Easiest way to get good calculation is to just take a photo of the nutrition label or feed that info in by hand.

Funny thing is 4o did look up calories but I guess it was too good for this world


I exclusively use thinking mode, which is slower but much more likely to double-check things with web search etc.


Maybe. I stopped using OpenAI a while ago. But taking pictures of the nutrition labels was good enough


And it can be made better easily. Take a picture of the nutrition label of the bread and cheese first and then feed in this picture and you should get way better results


The sandwich example is silly because you almost certainly know the fill nutiritonal info from the packaging so just use that...


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

Search: