When I first saw the OP, panic started to set in that I am fucked and Chat-Completions/LLMs/AI/whatever-you wanna-call-it will soon be able to create anything and eat away at my earning potential. And I will spend my elder years living with roommates, with no wife or children because I will not be able to provide for them. But upon reading that you used a reference implementation, I've realized that you simply managed to leverage it as the universal translator apenwarr believes is the endgame for this new technology [1]. So, now I feel better. I can sleep soundly tonight knowing my livelihood is safe, because the details still matter.
Less licensing headache, it seems. Kokoro says its Apache licensed. But it has eSpeak-NG as a dependency, which is GPL, which brings into question whether or not Kokoro is actually GPL. PocketTTS doesn't have eSpeak-NG as a dependency so you don't need to worry about all that BS.
Btw, I would love to hear from someone (who knows what they're talking about) to clear this up for me. Dealing with potential GPL contamination is a nightmare.
Kokoro only uses Espeak for text-to-phoneme (AKA G2P) conversion.
If you could find another compatible converter, you could probably replace eSpeak with it. The data could be a bit OOD, so you may need to fiddle with it, but it should work.
Because the GPL is outdated and doesn't really consider modern gen AI, what you could also do is to generate a bunch of text-to-phoneme pairs with Espeak and train your own transformer on them,. This would free you from the GPL license completely, and the task is easy enough that even a very small model should be able to do it.
If it depends on espeak NG code, the complete product is 100% GPL. That said, if you are able to change the code to take off the espeak dependency then the rest would revert to non-GPL (or even if it's a build time option that you can disable like FFMPEG with --enable-gpl)
I wish this post went into the actual how! He glossed over the details. There is a link to his repo, which is a start I suppose: https://github.com/piercefreeman/autopg
A blog post that went into the details would be awesome. I know Postgres has some docs for this (https://www.postgresql.org/docs/current/backup.html), but it's too theoretical. I want to see a one-stop-shop with everything you'd reasonably need to know to self host: like monitoring uptime, backups, stuff like that.
People use C not because they like it, but because its the lingua franca [1]. As long as The Unix Programming Environment [2] remains dominant, The C Programming Language [3] will too.
> [...] But nowadays they tend to punt to some AI. Beginning developers should not do this.
I don't know how I feel about this. I get the sentiment, I really do. But it almost reads like a chess Grandmaster in the 90s telling up-and-coming players to not practice against Deep Blue because it will teach you bad habits.
It's not so much that, although I'd argue that LLMs can certainly teach you some bad habits from time to time, much more so than Deep Blue ever would.
Rather, it's because early on, when beginners are learning the basics, they need to do the hard work of figuring stuff out so they develop problem-solving skills. It's not the code-writing skills they need to develop--that's easy. It's the problem-solving skills.
If I could figure out a way to grade on effort rather than correctness, I'd do that every time. Bust your ass and get a program 80% working and learn a ton doing it? You get an A. Spend 2 minutes copying ChatGPT output of a perfectly-working solution? F.
The effort is where you build the skill. And the skill is critical problem-solving. Having someone (or something) else do that work does not improve your skill.
Now, eventually, when you get to be better than the AI (and it's not hard to do that), stuff that you find easy is not longer beneficial to your learning. I've implemented linked lists a hundred times by now; I no longer learn anything from doing it. When you're that experienced with a subtopic, then sure, get ChatGPT to write it, and you verify it.
Going back to the weight lifting analogy, once you've been lifting the 2 kg weights for a while, you're not going to get much out of it. At that point, if the 2 kg weight must be lifted because it's part of your job description, have your robot do it. Meanwhile, you go on to the 4 kg weights and build muscle.
Maybe we crossed the Rubicon and there's too much opportunity cost to learn how to implement the fundamental DS&A. Instead of memorizing the ~10 lines of code for binary search, memorize the words "binary search". Thanks to the C compiler, we don't have to remember to push our registers and then jump to the subroutine. I think LLMs provide similar benefits. It frees your headspace for other stuff.
The analogy isn't perfect since a compiler will error if it can't create valid output. LLMs hallucinate. But still. Time is limited. I don't think it's a good idea to spend your formative years learning how to manage registers.
We don't tell chemists they shouldn't spend their formative years learning how to manage electron orbitals. You need to understand the fundamentals of how a computer works, or else you get people who write software with the wrong mental model of the machine (namely, that it's some sort of inscrutable, magic black box). Learning the fundamentals of the machine teaches you that is not, in fact, magic at all, it's just a lot of simple circuits built on top of each other, providing what we know as computation. Will you sling bits in assembly all day at your job? Probably not, but that knowledge is invaluable to being a better programmer.
We make surgeons learn anatomy. We make hardware engineers learn physics. I think we can expect programmers to learn how computers work.
Especially if your job will be to let Deep Blue play against others so you should know how to control it well. That maybe doesn't satisfy the purists around here but it makes Juniors way more competitive in the short term, hence they are well-advised to use it.
> But it almost reads like a chess Grandmaster in the 90s telling up-and-coming players to not practice against Deep Blue because it will teach you bad habits.
No idea if chess grandmasters did do that in the 90s, but frankly it would have been good advice. Just as it is good advice today for up-and-coming players not to practice against stockfish, leela or whatever. Unless you are already very proficient in chess, practicing against those engines will teach you very little .
terrible analogy. It's more like a chess grandmaster telling you not to let Stockfish play for you. Which would be a very obvious thing to not do anyway, just like for a learning programmer.
Vendoring wouldn't really affect this at all. If anything it would keep you vulnerable for longer because your vendored copy keeps "working" after the bad package got removed upstream. There's a tiny chance that somebody would've caught the 10MB file added in review but that's already too late - the exploit happened on download, before the vendored copy got sent for review.
reply