HN user
For what it's worth, if you don't have the chip that powers this card, there's also the PicoGUS which is a multi-function, software-defined ISA card that includes the ability to emulate the Gravis Ultrasound among other sound cards: https://picogus.com/
I've found that for CPU inference the PyTorch-based (non-quantized) version of Pocket TTS actually performs (both speed and quality-wise) better than the ONNX version, even after fiddling with all of the knobs that ONNX provides.
You'd be amazed what exists on the market these days. For example, the pre-terminated InvisiLight fiber cabling is 0.6mm in diameter and has a 2.5mm bend radius. I've personally installed this cabling while making many 90 degree (and sharper in some cases) bends without any issues. That makes it easy to hide and trivial to fit right through doorways and other tight spaces too.
What "heavy handed tracing" was turned on by default?
If you haven't already seen it, I highly recommend watching the "War Stories" video on the making of Prince of Persia: https://www.youtube.com/watch?v=sw0VfmXKq54
On a related note, I also highly recommend the "War Stories" video for the making of Crash Bandicoot: https://www.youtube.com/watch?v=izxXGuVL21o
Do you have a link to results confirming this? Kroko does not seem to be on the Open ASR Leaderboard. Parakeet has an average WER of 6.32 across several common datasets.
Why the choice of Kroko over something like parakeet-tdt-0.6b-v3, which is also faster than realtime on CPU?
After having to deal with VM hosts that do GeoIP blocking, which unintentionally blocks Let's Encrypt and others from properly verifying domains via http-01/tls-alpn-01, I settled on a DIY solution that uses CNAME redirects and a custom, minimal DNS server for handling the redirected dns-01 challenges. It's essentially a greatly simplified version of the acme-dns project tailored to my project's needs (and written in node.js instead of Go).
Unfortunately with dns-persist-01 including account information in the DNS record itself, that's a bit of a show stopper for me. If/when account information changes, that means DNS records need changing and getting clients to update their DNS records (for any reason) has long been a pain.
On Linux, this is why I always turn to using abstract sockets when I only need local locking. Only one process can bind and the kernel cleans up automatically on process exit.
You could do the same thing with TCP/UDP, but abstract sockets give you more flexibility in naming with 108 characters vs. being forced to use a 16-bit integer. Also it means you aren't using up a port that could otherwise be used for actual network communication.
Abstract sockets also make for a nice process existence monitoring mechanism since any processes connected to the bound socket are guaranteed to be immediately notified when the process dies.
Also be aware that kernel support for shebangs depends on CONFIG_BINFMT_SCRIPT=y being in the kernel config.
It's only an alternative if you have a backing swap device. zram does not have this requirement, so (aside from using no compression) it's basically the only solution for some scenarios (e.g. using entire disk(s) for ZFS).
tl;dr: Use surge protectors when you care about your electronics and/or your health.
This seems a bit strange to me considering the default behavior is to only show a suggested command if possible and do nothing else. That means they explicitly opted into the autocorrect feature and didn't bother to read the manual first and just guessed at how it's supposed to be used.
Even the original documentation for the feature back when it was introduced in 2008 (v1.6.1-rc1) is pretty clear what the supported values are and how they are interpreted.
It didn't work for me either, but apparently one of the issues is that it assumes window.speechSynthesis is available which may be disabled via about:config > media.webspeech.synth.enabled.
In my opinion it's primarily for less noisy logs.
I think it goes without saying that you would still want to be using keys instead of passwords for the actual authentication. Port knocking should always be an additional layer, not a replacement layer.
For what it's worth if you have control over both client and server and don't want to limit access using a strict IP whitelist, an alternative solution that will keep your logs quieter and add additional protection is to use good old fashioned port knocking. knockd on Linux helps with automating this on the server side. Client side you can use anything (although knockd does include a dedicated client) to send your sequence of packets before actually connecting.
Generally speaking (I've not tested this kind of setup with the cosmopolitan libc) what I've done in the past with C is use something like libmicrohttpd along with some web assets linked into the executable (`xxd -i` can help you with the assets). That gives you a single (small) binary where you can use HTML/CSS/JS for the main GUI and logic.
You can then integrate additional libraries as you please, such as sqlite3 to give yourself fast, local database access over an endpoint on the embedded HTTP/S/2 (or websocket) server.
Even with node.js, it's possible to be faster and/or use less memory than better-sqlite3. For example, here is an opinionated sqlite addon I wrote that shows just that (while executing queries asynchronously): https://github.com/mscdex/esqlite
I recognize that, but surely there could be overlap in some areas or problems unique to streamers who don't stream for a living.
For example, I could see streamers who stream for a potential social benefit may feel the need to chase trends, play the more popular games, and other similar things in order to increase/maintain viewership for more socializing opportunities. However they may also have a unique set of problems that streamers who do it for money do not have.
Every time I see articles talking about this subject, it's always completely focused on Twitch streamers that stream for a living. I would be more interested in hearing the contrast with streamers who stream for fun/not for a living. Which problems are the same between the two groups and which are unique?
From their pricing FAQ[1]:
19. Why do Picovoice engines require an internet connection?
While data is processed offline, locally on-device, Picovoice engines call home servers to stay active and report the consumption for billing purposes only.
Potential buffering issues aside, as others have pointed out the node.js example is performing asynchronous writes, unlike the other languages' examples (as far as I know).
To do a proper synchronous write, you'd do something like:
node -e 'const { writeSync } = require("fs"); while (1) writeSync(1, "1");' | pv > /dev/null
I wouldn't judge all VRML-enabled software the same, as they were not all terrible. For example, back in the mid-to-late 90s (and for several years in the 00's) there was a free (client) product called OnLive! Traveler (later DigitalSpace Traveler) that utilized VRML 1.0 with a few additional, custom VRML node types.
It was multi-user, it had a wide variety of customizable avatars that could express emotion and featured lip synching to the user's mic audio, it had 3D spatial user and environmental audio, and it all worked really well over dialup (even with 28.8kbps) even on first generation Pentium PCs. Movement was done with "FPS"-style keys (cursors, ALT for strafing, etc.). MTV would host regular live events in-world and there were a number of other large companies that were involved as well.
I was a bit surprised to find out that Unikraft does not yet support multiple cores/CPUs (at least on kvm and x86): https://github.com/unikraft/unikraft/pull/244
That doesn't answer the why though. It just makes it seem suspicious. How hard could it have been to use the latest versions of the non-Postgres software? Even as a "this is kind of interesting" experiment it seems like you'd have to go out of your way to install such old versions.
I wonder why such an old version of Redis was used in these benchmarks? Redis 3.0.7 was released back in January 2016. The current stable version as of this writing is 6.2.5.
EDIT: Additionally the version of memcached used in the benchmarks was from July of 2012 -- even older!
For those working with HTML/CSS in email clients here are a couple of sites that can help determine compatibility:
Quick hack for Ublock Origin users to get everything lined up again (add this to your filters): github.com#$#body{ max-width: 1280px !important; margin-right: auto !important; margin-left: auto !important; }