March 31, 2023

A guide to simple and stupid usage of computers for writers (anyone who writes really)

This guide is published under a CC BY-NC-SA 4.0 license.

Author: RP.

Table of Contents

  1. Who should not use this guide
  2. Who may find this guide useful
  3. Introduction
  4. How to read this guide?
  5. The command-line interface a.k.a cli
  6. Use Vim or pick the text editor of your choice1
  7. Write in plain text with Markdown
  8. Spell check a file
  9. View your files with the programme less”
  10. Produce your document layout with Pandoc
  11. Merge multiple pdf files
  12. Track versions of your work with git
  13. Collaborate with others using git (to be published)
  14. Back up your work
  15. Final note
  16. About the author

Who should not use this guide

You might not want to use this guide if you:

  • prefer to do things using a mouse (or a trackpad) rather than using shortcuts
  • think that, in computing, you can get things your way as long as you pay (money) for software
  • value convenience over agency

Who might find this guide useful

You might find this guide useful if you:

  • would like to keep your fingers on the keyboard (rather than fidgeting with the mouse)
  • are okay spending a bit of time understanding how you can do things if it means you can do things quickly afterwards
  • are curious about the terminal, a.k.a the shell.


The glut of features in word processors have made writing and collaborating with others unnecessarily complicated, slow, or cumbersome. Some feel they no longer work to write, but, work to manage the software and its features - so they can get work done.

All-in-one tools (like word processors) average at everything but get nothing done well.

Do one thing, do it well.

This guide offers writers to learn how to use programmes that do one single things well: edit plain text (no messing around with layout), track versions of your work, produce the layout your document et cetera - so one can focus on writing.

This is inspired by the Unix philosophy (emphasis mine):

This is the Unix philosophy: Write programs that do one thing and do it well. Write programs that work together. Write programs to handle text streams, because that is a universal interface. –Doug Mcllroy2

In other words, instead of having one programme (a word processor) which attempt to do everything, we will take the approach of having programmes that do one things well, and work together.


Most programmes in this guide are copyleft licensed (e.g. GPL licensed); others are at Free Software (e.g. MIT licensed).

You already have all the programmes we will use.

All programmes or utilities we suggest in this guide are already installed on your computer (even on a Mac), for example Vim, grep, find, less - or available in the repository of the GNU/Linux distribution you use (i.e. Pandoc or Git).

You should not have to switch programme anytime soon.

Also, all programmes discussed have passed the test of time”, at least to some extend (compared to the pace at which programmes pop up and die in the digital space.) No programme presented in this guide are novelties (most novelties vanish). For example: the utility find was published in 1971; grep in 1973; less in 1985; Vim in 1991; Git in 2005; Pandoc in 2006; Markdown was written in 2004. The most recent, Back In Time, was published in 2008 (which is based on rsync released in 1996). So based on the Lindy effect3, the idea that future life expectancy of a non-perishable item is equal to time passed since its inception (for example, a technology that has existed for 20 years is expected to survive for another 20), we can expect these programmes to be around’ for another 15 to 50 years. My point is that you should not have to switch programme anytime soon.

Feedback welcome at yctct at yctct dot com.

How to read this guide?

If you came to this guide because you want to learn how to collaborate with others using git, jump to the first git section.

You might not want to learn git (yet); still you are interested in applying the Unix philosophy. In that case you want to make yourself familiar with the command line (if you are not), read the section on Vim (or pick the text editor of your liking (not a word processor)), and then read the sections on Markdown and Pandoc, at minima. Using a text editor, Markdown and Pandoc can replace usage of a word processor4.

If your main motivation is to control your computer from the keyboard exclusively (i.e. to free yourself from using the mouse), the whole guide is about that. However, you might not be interested in all programmes discussed. Feel free to skip parts; each section can be read independently.

The command-line interface a.k.a. cli

You should be familiar with the command-line interface (a.k.a the terminal) before you go through this guide.

If cd, cd .., cd /, ls, mv, mkdir, rm look familiar to you, you are good to go. Otherwise you might want read where I put a few ideas to get the basics to get started with the command-line interface.

Use Vim

Why Vim?

The point is to quit using word processors. It starts with picking a text editor, a programme that does work one thing well: edit plain text (as opposted to rich text processed by word processors). Writing in plain text means that you don’t have to worry about formatting: the layout, the font, the table of contents, et cetera. Just write.

I suggest Vim but you are free to pick the text editor of your liking (not a word processor!).

If you have never used Vim you will be surprised at first. Vim doesn’t not work like the lay text editor. You will find that you no longer need to use the mouse. You will only interact with the keyboard. Typing, editing, is very fast. I also find that keeping my hands on the keyboard, rather than to constantly have to reach out for the mouse, helps me focus.

It takes a bit of effort at first, but, most people who try Vim do not switch back to a regular text editor.

Keep reading if you decide to pick Vim as your text editor. (You can skip to the next section, on Markdown, if you decide not* to use Vim.)*

To learn how to use Vim: start using it now.

Three things to make getting started easier though:

Vim Tutor

Complete the VIM Tutor. VIM Tutor is already installed on your computer, like Vim. To start Vim Tutor open the terminal and run

$ vimtutor

You should see this:


=    W e l c o m e   t o   t h e   V I M   T u t o r    -    Version 1.7      =

     Vim is a very powerful editor that has many commands, too many to
     explain in a tutor such as this.  This tutor is designed to describe
     enough of the commands that you will be able to easily use Vim as
     an all-purpose editor.

     The approximate time required to complete the tutor is 25-30 minutes,
     depending upon how much time is spent with experimentation.

     The commands in the lessons will modify the text.  Make a copy of this
     file to practice on (if you started "vimtutor" this is already a copy).

     It is important to remember that this tutor is set up to teach by
     use.  That means that you need to execute the commands to learn them
     properly.  If you only read the text, you will forget the commands!

     Now, make sure that your Caps-Lock key is NOT depressed and press
     the   j   key enough times to move the cursor so that lesson 1.1
     completely fills the screen.
                        Lesson 1.1:  MOVING THE CURSOR

   ** To move the cursor, press the h,j,k,l keys as indicated. **
             k              Hint:  The h key is at the left and moves left.
       < h       l >               The l key is at the right and moves right.
             j                     The j key looks like a down arrow.

Make Vim your default text editor

Use Vim.


When you need to figure how to do something: run :h to display the help files. For example, if you want to find out how to substitute some text run :h substitute.


To quit Vim run :q

Brian Moolenaar’s blog post

Learn to think of how to think Vim rather than learning shortcuts and commands by heart without understanding why things are this way. Vim is like a language that has a grammar. Once you get how the grammar works, you can make you own sentences.

To get an idea of how to think about using Vim, read written by Vim’s creator Bram Moolenaar.

I’d suggest using no plugins at first (I still don’t).

In the following sections, a few tips to get started tough.

Show word count in Vim

You can show the number of words in Vim by writing a file, a paragraph, etc. to the programme wc.

To display word count of a file, write it to the programme wc:

:w !wc  -w

In Vim, ! calls an external programme.

-w is an option that prompt wc to only show word count.

Run $ man wc in a terminal to see other options.

Change Vim color scheme

You can change Vim color scheme to your liking.

To display the name of the color scheme currently loaded run:


The name of the color scheme should be displayed at the bottom of your screen.

To display all color schemes run:

:colo [spacebar] [Crtl+D]

To flick through color schemes run:

:colo [spacebar] [tab]

To load a color scheme run:

:colo [name] [return]

For example :colo evening [return].

What’s next?

If you write in plain text, you will need another tool to format your text, e.g. create title, make a work bold, etc. That is what Markdown is for. Keep reading.

Write in plain text with Markdown

What is Markdown?

Markdown is a markup language for creating formatted text using a plain-text editor5.

Why use Markdown?

I am assuming the reader has been using word processors (e.g. Word, LibreOffice) so far.

Word processors are what some call WYSIWYG (What You See Is What You Get), meaning that the activity of writing text, that is actually typing your text, and the activity of formatting text, that is editing your text in the form of a letter, a C.V. or whatever you want your text to look like, are done in one single programme. What you see is what you get…

Another way to produce a document is first to write, in the text editor of your choice, then, to format the text using another programme. That is where Markdown comes into use. You can write using Markdown’s syntax in plain text, then, use Pandoc to convert your Markdown document into a pdf or else. That is it. No more word processor.

The authors of the markup language write that Markdown allows you to write using an easy-to-read, easy-to-write plain text format”6, and add that, readability is emphasized above all else. A Markdown-formatted document should be publishable as-is, as plain text”.

Markdown syntax

# That is a H1 title 

## That is a H2 title 

### That is a H3 title

Also a H1 title

A a H2 title

*Use asterisks to italicize text.*

Use asterisks to italicize text.

_Underscores also work to italicize text._

Underscores also work to italicize text.

**Use two asterisks to in bold.**

Use two asterisks to write in bold.

~~User tildes to strikethrough text.~~

User tildes to strikethrough text.

You can comment out text by framming it between <code><!--</code> 
and <code>--></code>, like this: <!-- N.B. commented text will not 
appear once you convert out from Markdown!-->.

You can comment out text by framing it between <!– and –>, like this: .

This sentence terminates in the footnote^[here.] 

This sentence terminates in the footnote7

You can also use numbers to write footnotes^[2].
[2]: second footnote

You can also use numbers to write footnotes8.

Numbered list:

1. first bullet point
1. second bullet point (notice: it is still number 1)
1. third bullet  point
    * indent bullet point
  1. first bullet point
  2. second bullet point (notice: it is still number 1)
  3. third bullet point
    • indent bullet point

Unnumbered list:

* one 
* two 
* three 
  • one
  • two
  • three

You can also use hyphens:

- one 
- two 
- three
  • one

  • two

  • three

    ``` Use at least three backtick marks for code blocks on multiple lines. ```

Use at least three backtick marks
for code blocks
on multiple lines.

Use one tab or four spaces for single-line code block.

    Use one tab or four spaces for single-line code block.

Use `backtick marks` to indicate `code` within a paragraph.

Use backtick marks to indicate code within a paragraph.

> a quote 
> > a nested quote
> a second paragraph within a quote

a quote

a nested quote

a second paragraph within a quote

[An hyperlink with a title - hoover on it]( "yctct")

A hyperlink with a title - hover on it

[An hyperlink with no title](

A hyperlink with no title

To embed an image with a title:

![Alt text](/path/to/img.jpg "Title")

Without a title:

![Alt text](/path/to/img.jpg)

Produce a horizontal rule tag by placing three or more hyphens, asterisks, or underscores on a line with nothing else:

* * *
- - -

You can find more information on the webpage the developers of Markdown, John Gruber and Aaron Swartz, published in 2004 when they released:

Spell check a file

For example, to spell check the file named letter run

$ aspell check letter

the first misspelt word should be highlighted and an interactive menu should pop up where you can select suggested corrections, choose to ignore that word, add word to dictionary et cetera.

For more information, including how to add other dictionaries, run $ man aspell to display the manual in your terminal.

View your files with the programme less”

Why less?

You don’t have to open files or documents to display them. You can use the programme called less”.
Less is a pager. A pager is a program that displays text files9.

To view a file run:

$ less file

To quit less press q.

To navigate the file viewed use keys:

  • j to scroll down
  • k to scroll up
  • f or space bar to scroll down one window size
  • b to scroll up one window size

The idea of using keys rather than the arrow-key pad (to the bottom right of your keyboard) is that it is faster since your right-hand fingers are already positioned on keys j and k. Once one gets use to scroll up and down with j and k it becomes inconvenient to use the arrow keys.

To return to the top of the page press g.

To jump to the bottom of the page press GG.

Searching for keywords

You can search for keywords by typing /some_keyword. Once the keyword is highlighted, press return (enter). Now you can move to the next occurrence by pressing the key n (small cap), and the previous occurrence by pressing the key N (large cap).

If you already scrolled down and think that the keyword you are looking for is towards the top of the page, use the inverse” of /, that is: ?. For example ?some_keyword to search backwards.

Switch to a text editor to edit a file

If you want to edit the file you are previewing press v.

Display multiple files with less

You can preview multiple files running:

$ less file1 file2 file3

To navigate between files press:

  • :n to examine the next file
  • :p to examine the previous file

Use less to display the output of other commands

You can use less to display the output of other commands instead of having the output of a command printing in the shell (i.e., the terminal).

For example, to list all pdf files of a directory and pipe the output of ls to less run:

$ ls .*pdf | less

That way you can navigate the (supposedly long) list using the keys j and k or search for keywords using /.

| pipes the output of the command preceding | as input to the next.

* acts as wild card (a substitute) for one or many characters (“a string”, esoterically speaking). In that example above, that is all files ending in .pdf.

More about less

Less is was written by Mark Nudelman in 1983-85, released in 1984 and currently maintained by him10.

Less is released under GNU General Public License (GPL).

To learn more about less, run $ man less to view less’s manual (in less).

Produce your document layout with Pandoc

What’s Pandoc?

Pandoc is tool to convert from one markup language to another using the command-line.

Using Pandoc

To convert from Markdown to pdf run:

$ pandoc -o file.pdf

-o stands for output”.

To add a table of contents to the output, append the command by --toc:

$ pandoc -o file.pdf --toc

To learn more about pandoc run:

$ man pandoc

Pandoc’s Markdown

Pandoc has an extended and slightly revised version of Markdown. To see Pandoc’s Markdown, in the shell (i.e. the terminal) run:

$ man pandoc

once the man page shows search for MARKDOWN by typing:


to go directly to the Markdown section of Pandoc’s man page.

Merge multiple pdf files


You can use Ghostscript to merge multiple pdf into one pdf.

To merge multiple pdf files into one single pdf file run:

$ gs 
-q \ 
-sPAPERSIZE=letter \ 
-dBATCH \ 
-sDEVICE=pdfwrite \ 
-sOutputFile=merged.pdf \
file1.pdf \

You can run $ man gs to understand what each option does.

If you don’t know whether Ghostscript is installed on your operating system, on GNU/Linux, you can check by running in your terminal:

$ dpkg -s ghostscript

If Ghostscript is installed you should see a line printing:

Status: install ok installed

You can also run:

$ dpkg -s ghostscript | grep installed

grep will print the line that matches keyword installed’.

dpkg is a package manager; the option -s (or –status) prints the status of a programme, e.g. you can check whether a program is installed.

If you need to install Ghostscript run:

$ sudo apt install ghostscript

Ghostscript was released in 1988 in by L. Peter Deutsch and licensed under GNU Affero General Public License (GNU AGPL).

Track versions of your work with git

What is git?

Git a version control system, a programme to help you keep track of different versions of your work, revisions your make or changes. With git, you can also save all past changes, so in case you mess up, you can also reverse to a prior version.

Why would you want to use git as a writer?

As a sole writer:

  • stop duplicating files to keep track of modifications e.g. file_version_1.txt, file_version_yesterday.txt, etc.
  • do not hesitate to delete text; everything you commit (I will define later) can be retrieved. Delete with confidence, recover if needed.
  • edit, reorganise and more text without altering the main” copy

As writers collaborating:

  • no more duplicates e.g., doc_alice_edits.txt, doc_bob_edits.txt, doc_john_edits.txt
  • no more waiting for other to send you the latest version or whatever
  • use git to check for conflicts” (differences) when two or more persons have worked on same file
  • each writer can use their own text editor, their own system to write. Git is agnostic.

There are many more reasons. This is just to give the reader an idea of why a writer might want to use git.

Getting started using git: create a git repository, make changes to a file and merge your changes into master

In this example we will learn how to use git to keep track of revisions of a text file: file.txt. We will:

  • create a git repository in a directory
  • initiate tracking for a file
  • create a branch
  • edit a file without altering the original” copy
  • commit (save) that change
  • merge the change with the original” file
  • delete the branch to leave the repository clean

You should be familiar with using the command-line interface (i.e. the terminal, the shell). You can find more information on learning to the use the command line there:

If you need to install git on Trisquel GNU/Linux run:

$ sudo apt install git

Start by creating a directory (a folder) named book where we will create and keep track of a file:

$ mkdir book

Move into the directory book:

$ cd book

Create a file:

$ touch file.txt

Initiate a git repository in this directory:

$ git init

The shell (a.k.a the terminal) should print:

Initialized empty Git repository in /home/user/book/.git/

We can check the status of our repository:

$ git status

The shell should print:

On branch master

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)

nothing added to commit but untracked files present (use "git add" to track)

Git tells us that it can see file.txt but does not track it (yet).

As suggested by git in the message above, to start tracking file.txt we run:

$ git add file.txt

We can run git status to check that file.txt is tracked by git. The shell should print:

On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
    new file:   file.txt

file.txt is now tracked but not recorded to the repository yet. To record a file to the repository we need to commit (save, in a way) that file. To commit file.txt we run:

$ git commit -m "Add file"

-m stands for message”; a message appended to the commit. You can run $ man git-commit to learn more about commits.

The shell unexpectedly prints:

*** Please tell me who you are.


  git config --global ""
  git config --global "Your Name"

to set your account's default identity.
Omit --global to set the identity only in this repository.

fatal: unable to auto-detect email address (got 'yourusername@computer.(none)')

Our commit did not go through. The repository does not know who we are. When we will collaborate with others on the same repository, and commit changes, git will need to know who commits come from.

We follow the above instruction to set the identity of our account, we run:

$ git config --global ""
$ git config --global "Alice A"

N.B. #1: do not forget to substitute the placeholders for your email address and name.

N.B. #2: This email address and name will show up in the commits for others to see.

Now that we created a repository, added file.txt and set our identity, we can commit file.txt to the repository (try Crtl+P to retrieve commands you’ve previously typed in the shell):

$ git commit -m "Add file"

The shell should print:

[master (root-commit) 954ea14] Add file
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 file.txt

We run git status to check where we are at. The shell should print:

On branch master
nothing to commit, working tree clean


We can also run git log to print our commit to the shell:

commit 954ea14e97ff2f2f690583bdb728d3fdab584376 (HEAD -> master)
Author: Alice A <>
Date:   Sun Mar 26 12:32:31 2023 +0100

    Add file

That is the commit we just made. You can see that our change was committed to the branch master.

Now we want to start working on file.txt. In this example, we will add a title. That is not much but the process will be the same for any future work you will want to keep track of.

The first thing we want to do before make any modification to our file is to create a branch (a sort of copy) of the directory where the repository lives. We do not need to create copy of file.txt e.g. file_version1.txt!

We create a branch named add-title:

$ git branch add-title

(You can run $ man git-branch to learn more about branching.)

We can check that the branch was created by running:

$ git branch

The shell should print:

* master

We can see that the branch add-title was created.

We can also see that we are still on the branch master. The * indicates which branch we are on.

We want to add a title to file.txt so let’s switch to the branch add-title where we will be able to make changes to file.txt without altering file.txt on the branch master.

To switch to the branch add-title we run:

$ git switch add-title

We can check that we switched to the branch add-title by running:

$ git branch

The shell should print:

* add-title

The * indicates that we are on the branch add-title.

Now we can start editing file.txt.

We can add a title to file.txt (using the programme echo) and check that the title was added (using the programme cat):

$ echo "# This is a title" > file.txt
$ cat file.txt 
# This is a title

Good. cat prints the content of file.txt to the shell.

Now we run git status to check where we are at.

The shell should print:

On branch add-title
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    modified:   file.txt

no changes added to commit (use "git add" and/or "git commit -a")

We are happy with the title we added to file.txt so we commit the modification.

First: we stage (that is, add) the file to the staging area by running:

$ git add file.txt

N.B.: you will make use of the staging area in the future. For now it makes no different. Just an extra step we have to take.

We can run git status to check that file.txt was staged. The shell should print:

On branch add-title
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
    modified:   file.txt

Now we commit:

$ git commit -m "Add title"

The shell should print:

[add-title bc4803f] Add title
 1 file changed, 1 insertion(+)

We can run git log to prints our commits to the shell:

commit bc4803f1330c1febeaee3283ee858be079bd3665 (HEAD -> add-title)
Author: Alice A <>
Date:   Sun Mar 26 12:58:18 2023 +0100

    Add title

commit 954ea14e97ff2f2f690583bdb728d3fdab584376 (master)
Author: Alice A <>
Date:   Sun Mar 26 12:32:31 2023 +0100

    Add file

Those are the two commits we made so far: first adding file.txt to the repository, and then adding a title to file.txt. We can see that the first commit was made on the branch master and the second (the one at the top) to the branch add-title.

We can also run git status to check that the branch is clean”, that file.txt was committed:

On branch add-title
nothing to commit, working tree clean

If we are happy with the modification we have just made i.e. adding a title, we can merge the changes into to branch master and delete the branch add-title.

First we switch back to the branch master:

$ git switch master

N.B.: we need to commit all changes to switch branch.

The shell should print:

Switched to branch 'master'

To see that changes made on the branch add-title did not affect the branch master we can print the content of file.txt:

$ cat file.txt

The shell should print nothing. (file.txt has no title on the branch master.)

We can check that the branch add-title was not merged yet:

$ git branch --no-merged

The shell should print branches that are not merged, in our case the branch add-title:


To merge changes made on the branch add-title into the branch master we run:

$ git merge add-title 

(You can run $ man git-merge to learn more about merges.)

The shell should print:

Updating 954ea14..bc4803f
 file.txt | 1 +
 1 file changed, 1 insertion(+)

We can check that changes of the branch add-title were merged onto the branch master:

$ git branch --merged

The shell should print branches that are merged (and indicates which branch we are on):

* master

We can also check that file.txt was modified, again using the programme cat:

$ cat file.txt 
# This is a title

Now we can delete the branch add-title since its changes were merged into the branch master, we run:

$ git branch -d add-title 

The shell should print:

Deleted branch add-title (was bc4803f).

We can run git status to check the status of our repository. The shell should print:

On branch master
nothing to commit, working tree clean

We are done learning the very basics of git. We:

  • created a repository in a directory with file.txt
  • set the identity of our git account
  • created a branch
  • made a change to file.txt
  • committed that changes to the newly created branch
  • merged the changes into the branch master
  • deleted the branch where we worked to keep the repository clean

I hope you can now use git to track versioning of your work. If not, you can run $ man git to learn more or drop me a line via email. I would be happy to help further by writing another blog post for example. Let me know.

Other git commands you might find useful

$ git diff

shows changes between commits in the shell.

$ git add . 

stages all files. Also useful when you stage one single file so you don’t have to type the name of the file.

$ git ci --amend --no-edit

adds changes to the last commit. In other words, it is useful if you already committed and forgot to add something to a file (do not do if you already pushed, for those who use git to collaborate). You can commit a change without adding a new commit.

$ git ci --amend 

same as above, but prompts you to also update the message of the commit.

$ git ci -am "Commit message"

stages (add) and commit at once. No need to run git add .

$ git branch -v

lists the last commit on each branch.

$ git grep keyword

to look for a keyword in the repository.

You might also want git to ignore .pdf files so they don’t show up when you run git status. To do so you can tell the .gitignore file to ignore files with extension .pdf. In the directory run:

$ echo "*.pdf" > .gitignore

to check that *.pdf was written to the hidden file .gitignore you can run:

$ cat .gitignore

which should print:


One more thing if you are unfamiliar with hidden files: to list hidden files run $ ls -a.

About git

Git is published under the copyleft license GNU General Public License (GPL). It was started by Linus Torvalds, released in 2005 and is currently maintained by Junio C Hamano et al..

Back up your work

Backing up?

Back up (save) your work locally, that is on an external drive, with the programme named Back In Time” (BiT).

You can install BiT on a GNU/Linux distribution by running:

$ sudo apt install backintime-qt

Your first back up

To create your first back, do:

  • Open Back in Time
  • A prompt should pop up asking you if you want to restore, click No
  • A window titled Settings should pop up
  • To select the drive where you want to back up, click on the folder icon in Where to save snapshots > Computer > / > media > user > (make sure the drive is mounted)
  • To select /home/ folder to backup, in Settings go to the tab titled Include > Add folder > select the folder
  • /home/ should be listed in Include files and folders
  • Click OK
  • A window titled Back in Time should pop up
  • Click the Take a snapshot button to take the first snapshot.

To back up your /home/ directory from the command line run:

$ backintime backup

Restore from an existing back up

To restore from an existing backup, on a newly installed operating system for example, run:

  • Open Back in Time (root)
  • A prompt should pop up asking you if you want to restore, click Yes
  • A prompt should pop up asking you for user password
  • A window titled Restore Settings (as superuser) should pop up
  • Navigate to the snapshot you want to restore and select it
  • The path to the snapshot should show up in green at the bottom
  • Click Restore
  • A window titled Back in Time (as superuser) should pop up
  • Select the folder you want to restore
  • A window titled Question (as superuser) should pop up
  • Click Yes

Final note

This guide is meant to evolve.

Free free to email feedback and comments to yctct at yctct dot com.

About the author

As far as I can remember: I had my first encounter with the internet in the early 2000s; with Instant Messaging and peer-to-peer networks. Back then, I owned a computer running with Windows, for a couple of years or so, then nothing until I purchased a Macbook in 2010. I got my first smartphone in 2015, the year I started to work in the software industry.

In 2019 I stopped working for the development of proprietary software.

In 2020 I switched back to using a dumb phone.

In 2021 I traded my Macbook for a second-hand laptop running the operating system Trisquel GNU/Linux.

I now do research, mostly drawing from philosophical works, to try to figure out concepts, or a framework, to critique digital technologies; to critique’ meaning to sieve through to improve how we use technologies (not to blame or reject). I plan to publish a book.

  1. rather than a word processor↩︎

  2. Raymond, Eric S. (2004). Basics of the Unix Philosophy”. The Art of Unix Programming. Addison-Wesley Professional (published 2003-09-23). ISBN 0-13-142901-9↩︎

  3. Goldman, Mandelbrot, Taleb↩︎

  4. and if you need to compare files, you can use the programme diff, e.g. in your terminal run $ diff file1 file2.↩︎

  5. From Wikiless↩︎

  6. John Gruber’s website↩︎

  7. here.↩︎

  8. 2↩︎


  10. Less’s website↩︎

learn personal computing command-line interface (cli) vim markdown git backintime pandoc text processing office applications wiki shell literacy

No affiliate links, no analytics, no tracking, no cookies. © 2016-2023 Content is licensed under CC BY-NC-SA 4.0 .