Crazy long interview, but interesting, as DHH has some weight in software engineering.
NVIDIA developer workshop: “s1: Simple test-time scaling” paper
At the NVIDIA developer workshop days I attended last week, the following paper was highly recommended:
“s1: Simple test-time scaling” by Niklas Muennighoff, Zitong Yang, Weijia Shi, Xiang Lisa Li, Li Fei-Fei, Hannaneh Hajishirzi, Luke Zettlemoyer, Percy Liang, Emmanuel Candès, Tatsunori Hashimoto
(PDF)
Github project: https://github.com/simplescaling/s1
Not directly related, but an interesting application of the NVIDIA RAPIDS Accelerator that was also presented: https://aws.amazon.com/blogs/industries/accelerating-fraud-detection-in-financial-services-with-rapids-accelerator-for-apache-spark-on-aws/
GitLab 10.5 and later: Solution for error “Validation failed for domain” with Let’s Encrypt
GitLab 10.5 introduced built-in support for Let’s Encrypt.
Unfortunately, if you follow the official GitLab instructions how to enable Let’s Encrypt support, you may encounter the following error when rebuilding GitLab:
Running handlers:
There was an error running gitlab-ctl reconfigure:letsencrypt_certificate[yourhost.yourdomain.com] (letsencrypt::http_authorization line 3) had an error: RuntimeError: acme_certificate[staging] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/letsencrypt/resources/certificate.rb line 20) had an error: RuntimeError: [yourhost.yourdomain.com] Validation failed for domain yourhost.yourdomain.com
Running handlers complete
Chef Client failed. 11 resources updated in 11 secondsWarnings:
Let’s Encrypt is enabled, but external_url is using http
The last line is rather misleading, as the domain validation can apparently also fail if one sets external_url = “https://yourhost.yourdomain.com”
As a workaround, add the following two additional lines to /etc/gitlab/gitlab.rb (hat tip to Kai Mindermann and Thomas Jost for the hints):
nginx['redirect_http_to_https_port'] = 80 nginx['redirect_http_to_https'] = true
So, all in all, you need to set in /etc/gitlab/gitlab.rb:
external_url 'https://yourhost.yourdomain.com'
and add the following lines (adjust the notification e-mail address):
letsencrypt['enable'] = true letsencrypt['contact_emails'] = ['gitlab-notifications@yourdomain.com'] # optional nginx['redirect_http_to_https_port'] = 80 nginx['redirect_http_to_https'] = true
Make sure that your firewall doesn’t block access to ports 22 (SSH), 80 (HTTP), 443 (HTTPS).
After that, reconfigure GitLab (in a shell):
# gitlab-ctl reconfigure
That’s it! You can now register/login at https://yourhost.yourdomain.com.
Updated Homebrew formula for t-prot 3.3
Just a note that I updated the t-prot.rb Homebrew formula for t-prot 3.3 (it’s really trivial, just a version bump). See my original post for the updated formula.
Guaranteeing memory safety in Rust | Air Mozilla
Nicholas Matsakis of Mozilla on how Rust guarantees type soundness, memory safety, and data-race freedom while still offering control similar to C/C++:
(via Guaranteeing memory safety in Rust | Air Mozilla.)
Rust, with its funny name, reminds more of a mutt than an academic programming language. It’s that pragmatism however, that has a lot of potential to help solving well-known “real world” reliability problems in software engineering. It would definitely make a worthwhile addition to other programming languages taught in CS classes.
Mozilla has already started building Servo, a web browser engine based on Rust. While still far from usable (Disclaimer: I’ve just compiled and quickly tested the current master branch sources on Mac OS X Mavericks), it’s the right strategic move and I wonder when other browser projects, like Chromium, will start shifting to safer programming languages too.
Modern web browsers are very complex and accordingly vulnerable pieces of software and yet, with the rise of the browser as an app platform, we depend more and more on their reliability, safety and security.
Ironically, my Chrome browser irrecoverably froze while I was drafting this blog post. Although chrome doesn’t rust, some Rust would actually be a good thing for Chrome, in the long term.
macvim – Vim for the Mac
When using Mac OS X, I used to use the CLI vim by the excellent Homebrew package manager.
Now I’ve just stumbled over macvim, which is kind of a “deluxe vim” for Mac OS X, including adjusted key bindings for the Mac and a GUI menu, supporting Cocoa file dialogs, among others.
It’s highly recommended if you want to have the best of both the CLI and GUI editor worlds.
Some helpful Git resources
A friend recently told the following joke:
“The idea that git can be used offline is an illusion – you still need connectivity for googling which arguments to pass to what command.”
That’s an exaggeration, of course, but as always, there’s a grain of truth in it. So here we go:
- Probably the visually and didactically nicest Git reference I’ve seen so far: Git Reference at gitref.org
- Got 2 minutes for a quick introduction? Check Git for dummies!
- And of course, there’s the official Git Book with some more details.
