Notes
Atom FeedRemoving Token Authentication From Jupyter/iPython Notebooks
Jupyter (formerly iPython) notebooks by default require an authentication token to access. This is because the notebooks allow users to run arbitrary code so the token prevents access by non-authorized users. However, with a properly secured environment (running within a local network or not binding to a public network interface), there’s little need to set an authentication token. While the Jupyter documentation recommends using a password instead, it still doesn’t get around the fact that the default notebook configuration uses unencrypted http connections which allow any party to intercept or modify requests, making both tokens and passwords trivial to bypass. Therefore, to fully get rid of authentication on a Jupyter notebook:
- Make sure your notebook is not accessible to the wider internet.
- Run
jupyter notebook --generate-config - Uncomment the line
c.NotebookApp.token = ''and make sure the value is set to an empty string - Restart your notebook server
Debian and Ubuntu Releases
Debian Releases
| Version | Name | Release | End of Standard Support |
|---|---|---|---|
| 11 | Bullseye | TBA | TBA |
| 10 | Buster | 2019-07-06 | 2022 |
| 9 | Stretch | 2017-06-17 | 2020-07-18 |
| 8 | Jessie | 2015-04-25 | 2018-06-17 |
| 7 | Wheezy | 2013-05-04 | 2016-06-04 |
| 6 | Squeeze | 2011-02-06 | 2014-07-19 |
Ubuntu Releases
| Version | Name | Release | End of Standard Support |
|---|---|---|---|
| 20.10 | Groovy Gorilla | 2020-10-22 | 2021-07 |
| 20.04 | Focal Fossa | 2020-08-06 | 2025-04 |
| 18.04 | Bionic Beaver | 2018-04-26 | 2023-04 |
| 16.04 | Xenial Xerus | 2016-04-21 | 2021-04 |
| 14.04 | Trusty Tahr | 2014-04-17 | 2019-04 |
| 12-04 | Precise Pangolin | 2012-04-26 | 2017-04-28 |
| 10.04 | Lucid Lynx | 2010-04-29 | 2015-04-30 |
| 8.04 | Hardy Heron | 2008-04-24 | 2013-05-09 |
Setting Up FastAI Fastbook on a Fresh Ubuntu Instance
This is how to set up the fastai environment on a fresh Ubuntu instance, for those of us who have a computer with a good Nvidia graphics card and Ubuntu and don’t want to use a cloud-based platform.
- Install nvidia CUDA drivers. So far, the most dependable guide that I’ve found has been this askubuntu post.
- Verify that the CUDA drivers have been installed correctly following this guide.
- Download fastbook with
git clone [email protected]:fastai/fastbook.git && cd fastbook. - Install the latest version of python -
sudo apt update && sudo apt install python3.9 python3.9-venv python3-setuptools - Create a virtual environment:
python3.9 -m venv env - Activate the virtual environment:
source env/bin/activate - Install a build requisite:
pip install wheel - Install packages:
pip install -r requirements.txt - Launch the notebook with
jupyter notebook
Tip for Developer Tools Startups
I recently had a really annoying experience with a startup in the developer tools space. I’ve been looking for a better CI platform for a while now (I’ve used Codeship, CircleCI, Travis, and Jenkins) and I found a promising CI platform that relied significantly on open source repositories as plugins to run its build pipelines. Many of these repositories are owned under the company’s own Github organization. Onboarding a few repositories of mine during an initial trial period, I found that there was a major missing feature in one of these plugins which would block me as well as other users from using this CI system effectively. I even found an open Github issue from another user a year earlier that reported the same missing feature. I then went into the plugin, learned the architecture, wrote a patch, added tests and documentation, and submitted five pull requests to fix this missing feature.
I’ve been waiting for three weeks for the company to merge or at least comment on these pull requests. In the meantime, my two week trial period ended which means I can’t even test changes to my pull requests. I therefore have significant doubts whether I should be using this company’s products.
Here’s a tip for dev tools startups: your customers and yourself are likely Github users, and if your customers contribute free feedback or features to your company through Github, you had better be responsive.
PermalinkA Better Go Defer
Go has a defer statement built into the language which allows a function to be executed at the end of another function. This is pretty useful in particular for cleanup (e.g. closing a file handle) or for recovering from errors (because Go code usually contains a lot of if err != nil { return err } and scattering cleanup code everywhere can be visually distracting).
// Real working go code
// Prints out "Start\nmain\nClose
// https://repl.it/@varsnap/Go-Defer-Example
package main
import "fmt"
type Instrumenter struct {}
func (i *Instrumenter) Start() *Instrumenter {
fmt.Println("Start")
return i
}
func (i *Instrumenter) Close() {
fmt.Println("Close")
}
func main() {
i := Instrumenter{}
defer i.Start().Close()
fmt.Println("main")
}
The funny thing is, although Go has first-class support for functions, defer statements take a a function call as an argument, not just a function declaration or function name - i.e. defer run() and not defer Run. While this may be a minor annoyance while programming, it can be pretty unintuitive when combined with a factory pattern that might use defer with a double function call.
I humbly propose (with heavy doubt it’ll be implemented) that the defer syntax be changed so that defer accepts a function rather than a function call as an argument, thereby making defer accept a continuation that can be invoked at the end of a function call (this does cause some problems with variable mutations that may happen later on, which become even more complicated when exception handling is introduced, but hopefully it can be worked out). I also propose that defer be changed from a built-in statement into a function that can accept a continuation as a parameter.