Comments URL: https://news.ycombinator.com/item?id=48465610

Points: 2

# Comments: 1

After that I started writing opub.dev because even minimal success in recent oss showed me just how much has changed, and I’m worried about how expensive everything will get for maintainers.

So, now I’m trying to GIVE people compute so they can start building a helpful filter layer above their projects.

Comments URL: https://news.ycombinator.com/item?id=48416221

Points: 3

# Comments: 1

The furthest I've gone in these jazz style culture interviews is asking people what they do outside of work for fun. This was for fully remote async positions. And it was important to know you had other stuff going on because the mental/personal health risk in failing at remote work is massive and life altering.

If, through wherever that discussion went, I wasn't 100% sure that you could stand on your own feet and wouldn't sink into the abyss, it was impossible to move forward. It was a tough line to walk sometimes because you don't want to pry personally. But that doesn't appear to be a universal opinion, it turns out.

Comments URL: https://news.ycombinator.com/item?id=48282724

Points: 2

# Comments: 0

I hacked together an open source project not too long ago that became somewhat popular on GitHub. It was a fun way to reconnect with programming after spending more time on the management side of the house.

It also showed me firsthand how much open source has changed.

The volume of generated issues and pull requests took a toll. Some of it was helpful. A lot of it was not. Either way, maintainers now have to review, triage, and respond to a growing amount of "AI"-generated work, on top of everything they were already doing for free.

One practical response is to use these tools on the maintainer side too: filtering issues, doing first-pass PR review, helping with security patches, writing tests, or handling some of the repetitive work around a project. That is not everyone’s cup of tea, and I respect that. But used carefully, it can help.

The problem is cost.

Open source maintainers should not have to personally pay for the compute needed to keep up with the generated workload around their projects.

This emerging pressure is why I built open public (opub).

opub lets donors fund donated compute for open source projects. Maintainers can create dollar-limited compute keys and use them with coding agents and tools across 30+ models. Token usage and spend are linked back to the project, alongside donations, so the project’s compute balance is visible in the open.

Registration is open, and I’d love feedback from the HN community.

If you maintain an open source project with 100+ GitHub stars, the first 20 to register can claim $50 in starter donated compute from us.

Comments URL: https://news.ycombinator.com/item?id=48223870

Points: 2

# Comments: 0

That said: If handy works, no need whatsoever to change.

But in this case I built hyprwhspr for Linux (Arch at first).

The goal was (is) the absolute best performance, in both accuracy & speed.

Python, via CUDA, on a NVIDIA GPU, is where that exists.

For example:

The #1 model on the ASR (automatic speech recognition) hugging face board is Cohere Transcribe and it is not yet 2 weeks old.

The ecosystem choices allowed me to hook it up in a night.

Other hardware types also work great on Linux due to its adaptability.

In short, the local stt peak is Linux/Wayland.

It's also in many flavours, from tiny to turbo, and so can fit many system profiles.

That's what makes it unique and hard to replace.

Not sure how you're running it, via whichever "app thing", but...

On resource limited machines: "Continuous recording" mode outputs when silence is detected via a configurable threshold.

This outputs as you speak in more reasonable chunks; in aggregate "the same output" just chunked efficiently.

Maybe you can try hackin' that up?

Apparently they do have a better model, they just haven't exposed it in their own OS yet!

https://developer.apple.com/documentation/speech/bringing-ad...

Wonder what's the hold up...

For footpedal:

Yes, conceptually it’s just another evdev-trigger source, assuming the pedal exposes usable key/button events.

Otherwise we’d bridge it into the existing external control interface. Either way, hooks are there. :)

On Linux, there's access to the latest Cohere Transcribe model and it works very, very well. Requires a GPU though. Larger local models generally shouldn't require a subordinate model for clean up.

Have you compared WhisperKit to faster-whisper or similar? You might be able to run turbov3 successfully and negate the need for cleanup.

Incidentally, waiting for Apple to blow this all up with native STT any day now. :)

In better times, perhaps we have the collective will to try.

This is - at best - ignorant hyperbole.

Love the people and their software.

Great blog Jaromir!

If entrants are not artificially inflating "organic" signals via fake content spam (Twitter/X), then the criteria themselves are losing their signal strength (StackOverflow/GitHub).

The diffusion makes it increasingly difficult to understand which channels are important and which correlate to strength in the market.

Unfortunately, these can be more than vanity metrics.

Some VCs or financial markets may use these as methods towards valuation.

Comments URL: https://news.ycombinator.com/item?id=38642912

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=38550236

Points: 5

# Comments: 0

https://mega.nz/folder/A1BjnSYQ#NQe5qhYLVBqiRwhWRmcVtg

Article is updating too.