Very interesting. Is any of this open source? I'd love to take a look!
I'm guessing it's not open source - as I couldn't find it on your Github account or your company's account. If that's the case, would you be able to create a quick gist with a copy/paste of any of the code you can share? If you have the time I'd appreciate it!
We pull Postgres from Nix using rules_nixpkgs for our Bazel tests. It works pretty well. I wrote some additional infrastructure that makes it easy to test against different versions of postgres (11, 12, 13 - all available from Nix) using simple Bazel command line options.
Thanks for the suggestion. I'll let the author of the post know. I think David was looking to update some documentation before doing any more distribution.
Just curious about how you technically do the export to MP4. Can you share any details? Do you play it back in real time and record it, or do you have a way of exporting it quicker than real time?? What technical approach do you use if you don't mind me asking? Thanks!
Quickly summarized we use puppeteer headfull with docker to do a recording of the video. So you’re right, it’s playing it back, not faster than real time. I might write more about the specifics in the future. It’s mostly open source code, you can start here: https://github.com/Ventricule/html2screen
Thanks for the reply. I was wondering if you were using the headfull chrome approach! I for one would definitely love to read some more specifics on this in the future when you have time! (And if there's anything you can open source please do!). I did a quick side project proof of concept of automating recording a webpage with video and other elements a few months ago. It's a shame there's not a way of just using headless chrome but my research let me to the headfull docker approach, so I'm happy to hear I landed on the same approach you did! Did you discover any novel tricks beyond what's been written about/open sourced already? What was the trickiest part for you?
No worries! Html2screen was a very good start, I modified it to support audio recording and got it to a pretty good state in a couple of days. After that the hard thing was just to run it automated on AWS. I used AWS Batch and Step Functions for that. When it’s a bit more stable I’ll definitely write about it and might open source it later. If you want to discuss more, feel free to email me at michiel@tella.tv
Hi Justin. I'd be very interested in seeing that custom element! If you're able to work to get that open sourced that would be amazing. (Interested as a user of both litelement and bazel)
We haven't had enough cycles to look at Podman in details (yet), but my understanding is that Podman and Docker serve similar purposes: they are high-level runtimes. (i'm obviating important nuances though and i'm not podman expert).
Sysbox, on the other hand, acts as a low-level runtime (same as runc), so we could potentially integrate with Podman too. In fact, we could _potentially_ integrate with anything that speaks OCI spec.
Having said that, we are not there yet, as for example sysbox wouldn't work with Podman in rootless mode right now; it should work in regular mode though, but we haven't tried it yet. If we accomplish this, it would allow podman to launch a larger set of applications too, same as we are doing for Docker.
Thanks; one thing I may have omitted mentioning is that Sysbox works with the fast overlayfs storage driver, meaning that when you do use it for Docker-in-Docker for example, both the outer Docker and the inner Docker are using overlayfs (as opposed to the slower vfs driver).
Sure, so one thing would be that CEL looks to be designed for writing expressions inside something else - like configuration files or other kinds of policies. So for example, its used within Firebase security policies, which are a superset of CEL. oso is a standalone policy engine that you add to your application as a library, and supports writing full policies made up of multiple rules and expressions.
Also, CEL is primarily based around protobufs as the core data objects, whereas we built oso to write policies directly over application objects in any language.
Otherwise, we definitely share a similar view on many parts of the language design.
