Add shell tips section with review of nohup and nice

Author: mbjones

_quarto.yml

@@ -2,45 +2,25 @@ project:
   type: book
 
 book:
-  title: "Scalable and Computationally Reproducible Approaches to Arctic Research"
-  doi: 10.18739/A2NK3670P
-  author: "Matthew B. Jones, S. Jeanette Clark, Jim Regetz, Rushiraj Nenuji, Nicole Greco, Angie Garcia, and Justin Kadi"
-  date: "April 7, 2025"
-  issued: 2025
+  title: "Quick review: remote computing"
+  author: "Matthew B. Jones"
+  date: "May 7, 2026"
+  issued: 2026
   reader-mode: false
   sidebar:
     title: "Course Materials"
     style: "floating"
     search: false
     tools:
       - icon: house-door-fill
-        href: https://arcticdata.io
-      - icon: twitter
-        href: https://twitter.com/arcticdatactr
+        href: https://nceas.ucsb.edu
       - icon: github
         href: https://github.com/NCEAS/scalable-computing-course
-
   chapters:
     - index.qmd
-    - sections/adc-intro.qmd
     - sections/remote-computing.qmd
     - sections/python-intro.qmd
     - sections/parallel-programming.qmd
-    - sections/data-structures-netcdf.qmd
-    - sections/parallel-with-dask.qmd
-    - sections/group-project-1.qmd
-    - sections/data-ethics.qmd
-    - sections/geopandas.qmd
-    - sections/parquet-arrow.qmd
-    - sections/group-project-2.qmd
-    - sections/software-design-1.qmd
-    - sections/adc-data-publishing.qmd
-    - sections/zarr.qmd
-    - sections/docker-containers.qmd
-    - sections/software-design-2.qmd
-    - sections/cloud-scale-data.qmd
-    - sections/reproducibility-containers.qmd
-    - sections/docker-hpc-cloud.qmd
 
 bibliography: references.bib
 

index.qmd

@@ -1,20 +1,10 @@
+![](images/nceas-banner.png)
+
 # Preface {.unnumbered}
 
 ## About {-}
 
-This 5-day in-person workshop will provide researchers with an introduction to advanced topics in computationally reproducible research in python, including software and techniques for working with very large datasets. This includes working in cloud computing environments, docker containers, and parallel processing using tools like parsl and dask. The workshop will also cover concrete methods for documenting and uploading data to the Arctic Data Center, advanced approaches to tracking data provenance, responsible research and data management practices including data sovereignty and the CARE principles, and ethical concerns with data-intensive modeling and analysis.
-
-
-![](images/arctic-data-center.png)
-
-<br>
-
-### Schedule {-}
-
-:::{.column-page}
-![](images/schedule.png)
-:::
-
+This one hour overview will provide researchers with a quick introduction to working in remote server computing environments, and some basics of parallel processing in the shell.
 
 ### Code of Conduct {-}
 

sections/remote-computing.qmd

@@ -457,6 +457,36 @@ echo "DONE!"
 ```
 :::
 
+## Shell tips and tricks
+
+When you're working 
+
+### Being nice {{< fa heart >}} 
+
+When working on a shared server, it's important to be considerate of other users who may also be using the server's resources. Here are some tips for being a good citizen when working on a shared server:
+
+- Check the server's resource usage before running a computationally intensive task. You can use commands like `htop` or `glances`to see how much CPU and memory is being used by other processes on the server
+- Use `nice` to run your processes with a lower priority, which can help prevent your processes from hogging resources and slowing down the server for other users. For example, you can run a command with `nice` like this: `nice -n 10 my_command`, where `-n 10` sets the priority level to 10 (the default is 0, and higher numbers indicate lower priority)
+
+### Don't hangup {{< fa phone >}} 
+
+When working on a remote server, it's important to be aware that your connection may be interrupted for various reasons (e.g. network issues, server maintenance, etc.), or maybe you just exit your terminal. When you do, the processes you were running will also be terminated. Here are some tips for being persistent when working on a remote server.
+
+- If you're running a long-running process, consider using `nohup` to run it in the background, which allows you to disconnect from the server without interrupting the process. For example: 
+- `nohup my_command &`
+
+What that does is to run the program `my_command` in the background (the `&` operator indicates to put it in the background) and to ignore the hangup signal (the `nohup` command), which allows the process to continue running even if your connection to the server is interrupted. The output of the command will be saved to a file called `nohup.out` in the current directory. 
+
+Alternatively, you can redirect the output to a specific file like this:
+- `nohup my_command > output.log 2>&1 &`
+
+That redirects the standard output (stdout) to `output.log` and the standard error (stderr) to the same file (`2>&1` means "redirect stderr to the same location as stdout"). This way, you can keep track of both the normal output and any error messages generated by `my_command` in a single log file. You might instead choose to redirect stdout and stderr to separate files for easier debugging, like this:
+- `nohup my_command > output.log 2> error.log &`
+
+### Persistent sessions with tmux {{< fa laptop >}} 
+
+`tmux` Tutorial: https://hamvocke.com/blog/a-quick-and-easy-guide-to-tmux/
+
 
 ## {{< fa cloud >}} What is cloud computing anyways?