Mostly cat /dev/urandom
txiki.js is a small and powerful JavaScript runtime. It’s built on the shoulders of giants: it uses QuickJS as its JavaScript engine, libuv as the platform layer, wasm3 as the WebAssembly engine and curl as the HTTP client.
Today I’m happy to release txiki.js 22.11, which contains a bunch of improvements that have happened during the last few months. Let’s look at some of those!
Read moreFor some time now I’ve been running KDE Neon on my desktop Linux machine, and I’m loving it. I love getting the Latest and Greatest KDE features, on top of a boring and familiar distro like Ubuntu LTS.
I’ve been following PipeWire from a distance for a while, and it seemed to be ready for prime time so, after getting some choppy audio from by Bluetooth headphones I thought I’d give it a try.
It’s actually fairly easy, and while I was at it I decided to use a PPA which will allow us to use a more recent PipeWire version.
Without further ado:
sudo add-apt-repository ppa:pipewire-debian/pipewire-upstream
sudo apt full-upgrade
sudo apt install pipewire-pulse libspa-0.2-bluetooth
systemctl --user --now disable pulseaudio.{socket,service}
systemctl --user mask pulseaudio
systemctl --user --now enable pipewire{,-pulse}.{socket,service}
pactl info | grep '^Server Name'
That’s it really. The last command will show something like Server Name: PulseAudio (on PipeWire 0.3.49) confirming you are running PipeWire as your PulseAudio server!
So far, upon switching to PipeWire my audio is no longer choppy and the volume meter is correct (it used to display 100% while clearly not being at 100%), so count me in as a happy PipeWire user.
pycares is a Python module which provides an interface to c-ares. c-ares is a C library that performs DNS requests and name resolutions asynchronously.
Finally, after a long time, I managed to make a new pycares release. Introducing pycares 4.0.0. This is an important one (note the major number change!) here are the most important features from this release:
I’m looking for help maintaining this module further, if you are interested, please comment here.
While working on this release I had some thoughts and reflections, if you are interested in those come with me in a trip down memory lane.
Read moreFinally back blogging… it’s been a while. Today I bring you a new pycares release: 3.1.0
pycares is a Python module which provides an interface to c-ares. c-ares is a C library that performs DNS requests and name resolutions asynchronously.
This release was relatively small, but I’m really happy about the automation work that I managed to do before the release, which should help with making the next releases faster and better.
Thanks to the automation work this release includes binary wheels for Python 3.5-3.8 on Windows, macOS and GNU/Linux.
How is this done? Well, pycares is now using 3 different CIs:
Thanks to these 3 free services, I couldn’t have done it without them! ❤️ Also huge thanks to Joe Rickerby for creating cibuildwheel it really made this a whole lot easier.
2 years have passed since the last Skookum JS release, so here we are, with a new release, and (maybe) a new plan.
But first, for those who don’t remember: what is Skookum JS (sjs)?
Skookum JS (or sjs for short) is a simple JavaScript runtime built on top of the Duktape JavaScript engine, with a simple POSIX-y API.
I guess the first question is “what’s with the version number?”. Fair point. I decided to switch to calendar versioning and give it a try, so since we are in June 2018, it’s time for a 18.6.0.
The focus of this release was to add more features and make it more CommonJS-alike, as I mentioned on my previous sjs post, but as time passed I realized I was wrong.
When I designed sjs I got heavily inspired by the runtime I knew the most: Python. This means having a small binary and “native addons” as shared libraries, in addition to a sizeable standard library. That’s all great, but it brings significant trouble because all those need to be in some path which the runtime will query, take (potentially) long time to load, and having multiple versions installed side by side is not easy. By contrast, Node takes the single binary approach: all the native modules needed for the standard library are part of the single binary, and so is the standard library itself. So I decided to do the same.
With this release, sjs is a single binary with all previous native modules embedded, as well as the standard library. I’d like to point out how I went about embedding the standard library, because that was a fun discovery: incbin. Incbin uses assembly to embed binaries into an executable, so that’s how I chose to embed all the JavaScript in the standard library onto the binary? Ugly? Maybe. Does it work? You bet!
sjs remains a toy project I like to hack on every now and then, and it’s now clear to me that my original design was flawed in many levels, so with this release I’m fixing one of those mistakes. Hopefully there will be more to come!
You can check the release notes here, check the code on GitHub, and check the documentation here.
Every so often I see the following question:
How can I stream a webcam to a Jitsi Meet room?
Wait, isn’t this just like “joining” a room? Not quite. One may want to have some dedicated contraption streaming a webcam to a room. Think of a homemade security camera system or something alike.
This probably gets asked for other WebRTC conferencing services too. The way I see it, there are 2 ways to go about it:
I know what you’re thinking: “Saúl, running an entire browser is overkill!”. Maybe. It will consume more RAM, yeah, but I argue the dominating factor here is video capture and encoding, not JavaScript execution, the DOM and other shenanigans.
Also, when all you have is a hammer, everything looks like a nail.
With the advent of headless mode in both Chrome and Firefox, this option looks more enticing than ever, so let’s roll our sleves and give it a shot.
I’m going to use Google’s puppeteer library, which runs Chrome headless to join a Jitsi Meet room. Being a headless client, we can cut down some of Jitsi Meet’s features in order to reduce the required resources:
I could probably add some more, but those should be enough to make a difference. The astute amongst you may think “but Saúl, disabling simulcast means every streamer will send an HD stream, I can’t cope with so many!”. Great point! Here we are going to rely on adaptivity, so no need to worry, if the client can only receive a single HD stream, the rest will be suspended, but you can switch between them just fine!
Here is the code (I also got to play with async / await for the first time, which is pretty cool):
https://gist.github.com/saghul/179feba3df9f12ddf316decd0181b03e
My original intent here was to use some inexpensive (and not very powerful) device such as the Raspberry Pi, but alas puppeteer doesn’t yet support ARM devices 🙁
Happy streaming!
I’ve had an (now) old Mac Mini 2,1 for about 10 years now and it has served me well. It used to be my desktop machine, then media center, then small home server.
At some point I realized I had moved all services except the printing service, so I thought it was about time I decommissioned it, but it deserved one last shot, so here we are 🙂
Today I finally found some time to put together a new pyuv release! Oh, but what is pyuv? I’m glad you asked!
pyuv is a Python module which provides an interface to libuv. libuv is a high performance asynchronous networking and platform abstraction library.
This a big one. Here are some of the highlights:
See the full changelog here.
I just realized the last release was over a year ago. Time flies! At any rate, here it is now. Enjoy!