65 karma · joined May 6, 2019
Not for everyone obviously. But there are many, many, many, options at this level of quality.
I am not claiming these Sennheisers are the best. The parent claimed the Airpods are the best. Which is not true. That's all I'm saying.
Top-shelf wireless earbuds aren't from Apple. Same for smart watches.
One concrete example I'm sure these Skyrim mods aren't using is: enums in structured outputs [1] with a finite list of locations/characters/topics/etc that are allowed to be discussed. The AI is not allowed to respond with anything that is not in the enum. So you can give it a list of all the locations in the game in a huge array and it would be forced to pick one.
[1] https://platform.openai.com/docs/guides/structured-outputs#a...
I think the thing you brought up at the beginning is the most practical path forward, someone with the technical know-how and business acumen needs to start a company. Apple and Google are quite weak now, and there are lessons to be learned from the Librem 5 and PinePhone. If enough people try, someone will eventually break through.
Unsolicited advice: Stop using the Github web UI asap. It will slow you down. VScode has git integration. There's an upfront cost to learning it but it's worth it.
If you're willing to take the plunge it's best to use the git command-line interface directly. It pays in the long run. But I understand it's kind of daunting at first.
Whatever you decide, whether its VScode or the git CLI, just get off of the Github web UI. Trust me. I look at my old projects from when I was in high school and I deeply regret that I didn't do version control. So much information that gets lost.
To be honest this librebox project looks kinda fishy to me. Seems like the author never used version control before. They put everything into one commit [1] and are making changes to the repo using the Github web UI. I wish the dev the best of luck but I wouldn't be surprised if this project gets abandoned in a few months
[1] https://github.com/librebox-devs/librebox-demo/commit/e70ea3...
Other than for the "live transcription" usecase (that they made unnecessarily complicated), I don't see how this is any better than running Whisper.cpp directly. Other people in this thread are basically saying "ffmpeg's interface is better understood" [2] but LLMs make that point moot since you can just ask them to do the drudgery for you.
[1] https://medium.com/@vpalmisano/run-whisper-audio-transcripti...
Of course you could disagree with my prediction and that these big tech companies are going to build MASSIVE gpu farms the size of the Tesla Gigafactory which can run godlike AI where nobody can compete, but if we get to that point I feel like we will have bigger problems than "AI react code is better than AI solidjs code"
Not saying the mods of HN are conspiring to bury these comments. But the fish rots from the head in upvote-ordered comment trees
To be honest I am trying to move away from LuaJIT, now that q66's cffi-lua project exists I don't have a reason to use LuaJIT from a dev productivity perspective. For speed, sure. But for my use-case regular Lua is fast enough and the added features in 5.4 over 5.1 are really nice. Plus having the option to easily edit the Lua source code if I want gives me a lot of comfort, since the codebase is way simpler than LuaJIT's.
I have removed LuaJIT from everything I use other than OpenResty. If I could, I would remove it from OpenResty but that is a huge undertaking
Yeah the garbage collector is one of the things in Lua I really don't like - in Lua 5.4 Roberto added the <close> thing and generational GC but I'm not sure how well these work in practice. I guess I'm lucky enough in that I have never hit the upper limit where a GC cycle totally kills performance and if that ever happens I have the option of rewriting that code in C
One of the things I suspect your team is doing wrong is you are using the PUC Lua C API instead of the LuaJIT FFI. That is one of those things which just completely destroys the "happy path". The PUC Lua C api is effectively a deprecated feature at this point. A few years ago you could have made the argument that the PUC Lua C API is more portable than LuaJIT which is absolutely true. But q66's (from Chimera Linux fame) cffi-lua project nullifies that argument since you can now use the luajit-style FFI in PUC Lua, which works on every platform that libffi supports.
Again I understand your frustrations with the language since you are working within a fundamentally adversarial environment. Perverse incentives can easily destroy any good patterns you can establish since the language is so flexible. I implore you to explore the language outside of your day job.
This is why it has been an ordeal. I came to a similar impasse. It went away when I changed my mind. It's a little bloated I'll give you that, but it's not that bad. Certainly better than bootstrapping 10+ years worth of language features