~rbdr/gemlog

97b7f12d299065ff3f369dc5e6e5fd72a97fe116 — Ruben Beltran del Rio 2 months ago c34f2e2
blog-sync-up-1707084701480
9 files changed, 192 insertions(+), 21 deletions(-)

A archive/1707084701399/how-i-publish-my-website-using-page-and-sourcehut.gmi
A archive/1707084701399/metadata.json
A posts/0/how-i-publish-my-website-using-page-and-sourcehut.gmi
M posts/0/metadata.json
M posts/1/metadata.json
R posts/{0/setting-up-net-on-se30.gmi => 1/setting-up-net-on-se30.gmi}
M posts/2/metadata.json
R posts/{1/scripts-for-git-admin.gmi => 2/scripts-for-git-admin.gmi}
D posts/2/window-management-and-huge-windows.gmi
A archive/1707084701399/how-i-publish-my-website-using-page-and-sourcehut.gmi => archive/1707084701399/how-i-publish-my-website-using-page-and-sourcehut.gmi +91 -0
@@ 0,0 1,91 @@
# How I publish my website using page and sourcehut

I have a very simple website available in gemini[1] and https[2]: It's gemini-first so it consists of gemtext and some assorted static files so I built a tool called page[3] to help me generate the static version of the site. In this post I describe how I use that tool and sourcehut to publish my site.

=> gemini://gemini.unlimited.pizza [1] Gemini version of my website
=> https://www.unlimited.pizza [2] HTTPS version of my website
=> /page.gmi [3] page

You can read more about page in the link above, but in short:

* it reads a _layout.html at the root of the directory.
* it takes every .gmi file, and converts it to html using the layout file above.
* it copies over static files and creates two "upload-ready" directories with html and gemini content.

This is easy enough to run locally, but I have the build set up in sourcehut so I can update it on push. Breaking down my .build.yml, it goes something like this:

Step 1. Specify an image. I've been using arch for a while so I went with archlinux, but the rest doesn't change that much.

```
image: archlinux
```

Step 2. Install dependencies. page needs rust and make, and I use rsync to copy files to my VPS so I only need those three.

```
packages:
  - make
  - rust
  - rsync
```

Step 3. Select which sources to clone. I'm building page from source and I'm using my website so I specify those two.

```
sources:
  - https://git.sr.ht/~rbdr/page
  - git@git.sr.ht:~rbdr/www.unlimited.pizza
```

Step 4. My secrets. I need a set of credentials to clone the sources, and another to connect to my VPS. Sourcehut has great documentation[4] on this, but it basically corresponds to keyfiles I can use to connect.

=> https://man.sr.ht/builds.sr.ht/#secrets [4] sourcehut build documentation.

```
secrets:
  - 01234567-89ab-cdef-0123-456789abcdef
  - fedcba98-7654-3210-fedc-ba9876543210
```

Step 5. Do the actual work. I've separated my task in four steps. First we build page, then we generate the static files, then we rsync the html, and finally we rsync the gemini content. One thing of note is that I exclude the .build.yml because page will upload everything in the directory, including hidden files.

```
tasks:
  - build_page: |
      cd page
      make -e profile=release
  - generate_page: |
      cd www.unlimited.pizza
      ../page/target/release/page
  - sync_html: |
      rsync -r --exclude '.build.yml' www.unlimited.pizza_html/ deploy@www.unlimited.pizza:/srv/http/www
  - sync_gemini: |
      rsync -r --exclude '.build.yml' www.unlimited.pizza_gemini/ deploy@gemini.unlimited.pizza:/srv/gemini/content
```

And that's it! The build system in sourcehut is very straightforward, so using this for other website builders shouldn't be a big change. And maybe, if you're also publishing with gemini you will find page useful. In upcoming posts I'll write about how I use stargazer to host the gemini capsule (+ some cgi scripts), and how I use nginx to host the https version. Anyway! here's the complete .build.yml:

```
image: archlinux
packages:
  - make
  - rust
  - rsync
sources:
  - https://git.sr.ht/~rbdr/page
  - git@git.sr.ht:~rbdr/www.unlimited.pizza
secrets:
  - 01234567-89ab-cdef-0123-456789abcdef
  - fedcba98-7654-3210-fedc-ba9876543210
tasks:
  - build_page: |
      cd page
      make -e profile=release
  - generate_page: |
      cd www.unlimited.pizza
      ../page/target/release/page
  - sync_html: |
      rsync -r --exclude '.build.yml' www.unlimited.pizza_html/ deploy@www.unlimited.pizza:/srv/http/www
  - sync_gemini: |
      rsync -r --exclude '.build.yml' www.unlimited.pizza_gemini/ deploy@gemini.unlimited.pizza:/srv/gemini/content
```

A archive/1707084701399/metadata.json => archive/1707084701399/metadata.json +4 -0
@@ 0,0 1,4 @@
{
  "id": "1707084701399",
  "createdOn": 1707084701399
}
\ No newline at end of file

A posts/0/how-i-publish-my-website-using-page-and-sourcehut.gmi => posts/0/how-i-publish-my-website-using-page-and-sourcehut.gmi +91 -0
@@ 0,0 1,91 @@
# How I publish my website using page and sourcehut

I have a very simple website available in gemini[1] and https[2]: It's gemini-first so it consists of gemtext and some assorted static files so I built a tool called page[3] to help me generate the static version of the site. In this post I describe how I use that tool and sourcehut to publish my site.

=> gemini://gemini.unlimited.pizza [1] Gemini version of my website
=> https://www.unlimited.pizza [2] HTTPS version of my website
=> /page.gmi [3] page

You can read more about page in the link above, but in short:

* it reads a _layout.html at the root of the directory.
* it takes every .gmi file, and converts it to html using the layout file above.
* it copies over static files and creates two "upload-ready" directories with html and gemini content.

This is easy enough to run locally, but I have the build set up in sourcehut so I can update it on push. Breaking down my .build.yml, it goes something like this:

Step 1. Specify an image. I've been using arch for a while so I went with archlinux, but the rest doesn't change that much.

```
image: archlinux
```

Step 2. Install dependencies. page needs rust and make, and I use rsync to copy files to my VPS so I only need those three.

```
packages:
  - make
  - rust
  - rsync
```

Step 3. Select which sources to clone. I'm building page from source and I'm using my website so I specify those two.

```
sources:
  - https://git.sr.ht/~rbdr/page
  - git@git.sr.ht:~rbdr/www.unlimited.pizza
```

Step 4. My secrets. I need a set of credentials to clone the sources, and another to connect to my VPS. Sourcehut has great documentation[4] on this, but it basically corresponds to keyfiles I can use to connect.

=> https://man.sr.ht/builds.sr.ht/#secrets [4] sourcehut build documentation.

```
secrets:
  - 01234567-89ab-cdef-0123-456789abcdef
  - fedcba98-7654-3210-fedc-ba9876543210
```

Step 5. Do the actual work. I've separated my task in four steps. First we build page, then we generate the static files, then we rsync the html, and finally we rsync the gemini content. One thing of note is that I exclude the .build.yml because page will upload everything in the directory, including hidden files.

```
tasks:
  - build_page: |
      cd page
      make -e profile=release
  - generate_page: |
      cd www.unlimited.pizza
      ../page/target/release/page
  - sync_html: |
      rsync -r --exclude '.build.yml' www.unlimited.pizza_html/ deploy@www.unlimited.pizza:/srv/http/www
  - sync_gemini: |
      rsync -r --exclude '.build.yml' www.unlimited.pizza_gemini/ deploy@gemini.unlimited.pizza:/srv/gemini/content
```

And that's it! The build system in sourcehut is very straightforward, so using this for other website builders shouldn't be a big change. And maybe, if you're also publishing with gemini you will find page useful. In upcoming posts I'll write about how I use stargazer to host the gemini capsule (+ some cgi scripts), and how I use nginx to host the https version. Anyway! here's the complete .build.yml:

```
image: archlinux
packages:
  - make
  - rust
  - rsync
sources:
  - https://git.sr.ht/~rbdr/page
  - git@git.sr.ht:~rbdr/www.unlimited.pizza
secrets:
  - 01234567-89ab-cdef-0123-456789abcdef
  - fedcba98-7654-3210-fedc-ba9876543210
tasks:
  - build_page: |
      cd page
      make -e profile=release
  - generate_page: |
      cd www.unlimited.pizza
      ../page/target/release/page
  - sync_html: |
      rsync -r --exclude '.build.yml' www.unlimited.pizza_html/ deploy@www.unlimited.pizza:/srv/http/www
  - sync_gemini: |
      rsync -r --exclude '.build.yml' www.unlimited.pizza_gemini/ deploy@gemini.unlimited.pizza:/srv/gemini/content
```

M posts/0/metadata.json => posts/0/metadata.json +2 -2
@@ 1,4 1,4 @@
{
  "id": "1706113636109",
  "createdOn": 1706113636109
  "id": "1707084701399",
  "createdOn": 1707084701399
}
\ No newline at end of file

M posts/1/metadata.json => posts/1/metadata.json +2 -2
@@ 1,4 1,4 @@
{
  "id": "1705848860112",
  "createdOn": 1705848860112
  "id": "1706113636109",
  "createdOn": 1706113636109
}
\ No newline at end of file

R posts/0/setting-up-net-on-se30.gmi => posts/1/setting-up-net-on-se30.gmi +0 -0
M posts/2/metadata.json => posts/2/metadata.json +2 -2
@@ 1,4 1,4 @@
{
  "id": "1705616805329",
  "createdOn": 1705616805329
  "id": "1705848860112",
  "createdOn": 1705848860112
}
\ No newline at end of file

R posts/1/scripts-for-git-admin.gmi => posts/2/scripts-for-git-admin.gmi +0 -0
D posts/2/window-management-and-huge-windows.gmi => posts/2/window-management-and-huge-windows.gmi +0 -15
@@ 1,15 0,0 @@
# Window management doesn't work because all my windows are huge.

I have two computers at home with very different screens: one has a resolution of 1512 x 982, and the other one has a resolution of 512 x 342. On both screens I multi-task and get to use similar apps: text editors, file managers, image editors, web browsers, etc. And yet my large spacious laptop often feels more constrained than the tiny screen on the older mac.

I'm not saying the windowing experience was better in 1989, because it wasn't. But it wasn't all worse either. One of the things I find most irritating is how large screens are nowadays [1]. For example:

Omnigraffle, a diagramming app can't be resized to less than 57% of the screen width. Transmit, an FTP app needs 58%. Xcode, the official Apple IDE has decided it requires at least 63% of my screen width to operate. Setapp can't let me install apps without taking 72% of my screen width, and Davinci Resolve is generous to give me back a meager 4% of my screen width back.

All of these apps could go way smaller and still provide a great experience, there's plenty of examples: Max 8, Finder (Without sidebars), Blender. Many of the apps I believe they could change that limit and nothing else and it would work great. Some other apps have decided that design = padding and macspread all over the screen. It's just rude to not let me use all that screen space.

Meanwhile on the older mac, I find that most apps tend to be friendlier with screen real-estate. Of course without virtual spaces and smaller resolutions you had to!

Large windows make window management worse, please make your windows smaller.

=> http://www.unlimited.pizza/min_sizes.html [1] A collection of minimum window widths