g4nd.xlarge by Ciro Santilli 37 Updated 2025-07-16
TODO meaning of "nd"? "n" presumably means Nvidia, but what is the "d"? Compare it g4ad.xlarge which has AMD GPUs. aws.amazon.com/ec2/instance-types/g4/ mentions:
G4 instances are available with a choice of NVIDIA GPUs (G4dn) or AMD GPUs (G4ad).
Price:
You SSH into a an OS like Ubuntu and do whatever you want from there. E.g. Amazon EC2.
The OS is usually virualized, and you get only a certain share of the CPU by default.
Platform as a service by Ciro Santilli 37 Updated 2025-07-16
Highly managed, you don't even see the Docker images, only some higher level JSON configuration file.
These setups are really convenient and cheap, and form a decent way to try out a new website with simple requirements.
Heroku by Ciro Santilli 37 Updated 2025-07-16
This feels good.
One problem though is that Heroku is very opinionated, a likely like other PaaSes. So if you are trying something that is slightly off the mos common use case, you might be fucked.
Another problem with Heroku is that it is extremely difficult to debug a build that is broken on Heroku but not locally. We needed a way to be able to drop into a shell in the middle of build in case of failure. Otherwise it is impossible.
Deployment:
git push heroku HEAD:master
View stdout logs:
heroku logs --tail
Drop and recreate database:
heroku pg:reset --confirm <app-name>
All tables are destroyed.
Restart app:
heroku restart
Arghh, why so hard... tested 2021:
LSF get version by Ciro Santilli 37 Updated 2025-07-16
Most/all commands have the -V option which prints the version, e.g.:
bsub -V
By default, LSF only sends you an email with the stdout and stderr included in it, and does not show or store anything locally.
One option to store things locally is to use:
bsub -oo stdout.log -eo stderr.log 'echo myout; echo myerr 1>&2'
as documented at:Or to use files with the job id in them:
bsub -oo %J.out -eo %J.err 'echo myout; echo myerr 1>&2'
By default bsub -oo:
  • also contains the LSF metadata in addition to the actual submitted process stdout
  • prevents the completion email from being sent
To get just the stdout to the file, use bsub -N -oo which:
  • stores only stdout on the file
  • re-enables the completion email
as mentioned at:
Another option is to run with the bsub -I option:
bsub -I 'echo a;sleep 1;echo b;sleep 1;echo c'
This immediately prints stdout and stderr to the terminal.
bsub on foreground by Ciro Santilli 37 Updated 2025-07-16
Run bsub on foreground, show stdout on host stdout live with an interactive with the bsub -I option:
bsub -I 'echo a;sleep 1;echo b;sleep 1;echo c'; echo done
Ctrl + C kills the job on remote as well as locally.

Pinned article: Introduction to the OurBigBook Project

Welcome to the OurBigBook Project! Our goal is to create the perfect publishing platform for STEM subjects, and get university-level students to write the best free STEM tutorials ever.
Everyone is welcome to create an account and play with the site: ourbigbook.com/go/register. We belive that students themselves can write amazing tutorials, but teachers are welcome too. You can write about anything you want, it doesn't have to be STEM or even educational. Silly test content is very welcome and you won't be penalized in any way. Just keep it legal!
We have two killer features:
  1. topics: topics group articles by different users with the same title, e.g. here is the topic for the "Fundamental Theorem of Calculus" ourbigbook.com/go/topic/fundamental-theorem-of-calculus
    Articles of different users are sorted by upvote within each article page. This feature is a bit like:
    • a Wikipedia where each user can have their own version of each article
    • a Q&A website like Stack Overflow, where multiple people can give their views on a given topic, and the best ones are sorted by upvote. Except you don't need to wait for someone to ask first, and any topic goes, no matter how narrow or broad
    This feature makes it possible for readers to find better explanations of any topic created by other writers. And it allows writers to create an explanation in a place that readers might actually find it.
    Figure 1.
    Screenshot of the "Derivative" topic page
    . View it live at: ourbigbook.com/go/topic/derivative
  2. local editing: you can store all your personal knowledge base content locally in a plaintext markup format that can be edited locally and published either:
    This way you can be sure that even if OurBigBook.com were to go down one day (which we have no plans to do as it is quite cheap to host!), your content will still be perfectly readable as a static site.
    Figure 2.
    You can publish local OurBigBook lightweight markup files to either https://OurBigBook.com or as a static website
    .
    Figure 3.
    Visual Studio Code extension installation
    .
    Figure 4.
    Visual Studio Code extension tree navigation
    .
    Figure 5.
    Web editor
    . You can also edit articles on the Web editor without installing anything locally.
    Video 3.
    Edit locally and publish demo
    . Source. This shows editing OurBigBook Markup and publishing it using the Visual Studio Code extension.
    Video 4.
    OurBigBook Visual Studio Code extension editing and navigation demo
    . Source.
  3. https://raw.githubusercontent.com/ourbigbook/ourbigbook-media/master/feature/x/hilbert-space-arrow.png
  4. Infinitely deep tables of contents:
    Figure 6.
    Dynamic article tree with infinitely deep table of contents
    .
    Descendant pages can also show up as toplevel e.g.: ourbigbook.com/cirosantilli/chordate-subclade
All our software is open source and hosted at: github.com/ourbigbook/ourbigbook
Further documentation can be found at: docs.ourbigbook.com
Feel free to reach our to us for any help or suggestions: docs.ourbigbook.com/#contact