Development Tools on KnightLi Blog

Jimmy: Convert Exports from Evernote, Notion, Google Keep, and More into Markdown

Sat, 30 May 2026 11:55:56 +0800

Jimmy is a note conversion tool whose goal is to convert content from different note apps or document formats into Markdown. It is useful for people who want to move notes out of closed apps, import them into Obsidian or Joplin, or simply keep long-term archives as plain text.

The project documentation is very direct: export or back up the original note app’s data, run jimmy to convert it, then import the result into Joplin or Obsidian, or open it directly in a text editor such as VSCode.

What Jimmy Solves

Many note apps have their own export formats. When switching apps, the hardest part is often not the text itself, but images, attachments, tags, internal links, and structured metadata such as front matter.

Jimmy tries to turn those exports into a more universal Markdown directory:

Convert note bodies to Markdown.
Preserve images, resources, and attachments as much as possible.
Preserve tags, external links, and internal note links where possible.
Output Markdown + front matter.
Make the result importable into Joplin, Obsidian, and similar tools, or readable directly in a text editor.

The point of this kind of tool is to reduce migration cost. Once notes become Markdown, they are no longer tightly bound to one app. Backup, search, version control, and LLM processing all become much easier.

Many Supported Note Apps

Jimmy supports a wide range of sources, including Anki, Anytype, Bear, CherryTree, ColorNote, Day One, Diaro, Drafts, Dynalist, Evernote, Google Docs, Google Keep, Joplin, Notion, Obsidian, OneNote, QOwnNotes, RedNotebook, Reflect, Roam Research, Signal, Simplenote, Standard Notes, Synology Note Station, Telegram, Tiddlywiki, Turtl, UpNote, Wordpress, Zim, Zoho Notebook, and more.

Not every source has the same fidelity. In a real migration, you should still test with a small batch first and check images, attachments, tags, internal links, and date fields carefully.

It Can Also Convert Regular Documents

Besides exports from note apps, Jimmy can also handle common document formats. The docs mention converting a single file or recursively converting an entire folder, which makes it useful for turning messy document directories into Markdown.

Common supported formats include:

Type	Examples
Office documents	DOCX, ODT, RTF
Markup languages	Asciidoc, DocBook, Markdown, MediaWiki, reStructuredText
Web and ebooks	HTML, MHTML, EPUB
Data and structured files	CSV, OPML, Jupyter Notebook
Other	PDF, EML, Fountain, txt2tags

If you only want to batch-convert DOCX, PDF, or HTML into Markdown, Jimmy can also work as an offline batch-processing tool.

Two Ways to Use It

Jimmy provides both CLI and TUI interfaces.

Interface	Best For	Notes
CLI	Batch processing, scripts, full functionality	Suitable for converting folders, writing migration scripts, and specifying source formats
TUI	Interactive conversion	Suitable for manual operation; currently a beta subset of the full functionality

The official README gives these Linux examples:

# Convert with the interactive TUI
jimmy-linux tui

# Convert a single file supported by pandoc
jimmy-linux cli libre_office_document.odt

# Convert an entire folder
jimmy-linux cli path/to/folder

# Convert a Google Keep export
jimmy-linux cli takeout-20240401T160516Z-001.zip --format google_keep

These commands show that Jimmy is not only for one note app. It puts “note export packages” and “regular document folders” into the same conversion workflow.

Main Characteristics

Feature	Description
Offline execution	Conversion does not depend on cloud services, which is useful for private notes
Open source	The repository uses the GPL-3.0 license
Cross-platform	Official downloads are available for Linux, Windows, and macOS
Standalone binary	Users do not need to install Docker, Python, or Node.js
No AI used	Conversion does not call AI, making results more controllable and reducing privacy concerns
Markdown + front matter	Easy to import into note apps and later manage with Git

“Offline” and “no AI” are especially fitting for note migration. Notes often contain private information, work materials, and old attachments. Keeping conversion local makes the risk boundary clearer.

Who Should Use It

Jimmy is useful for:

Users migrating from Evernote, Notion, OneNote, Google Keep, and similar tools to Markdown.
People importing notes into Obsidian, Joplin, or another plain-text workflow.
People who want to preserve long-term materials in a format that will be easier to read in the future.
People preparing notes or documents as text that LLMs can process.
People who need to recursively convert folders of DOCX, PDF, HTML, ODT, and similar files.

It may not be for users who expect “one-click perfect migration”. Export formats vary greatly between note apps, and complex pages, databases, embeds, and internal links may still need manual review.

Pre-Migration Checklist

Before doing a real migration, it is better to follow this order:

Export a small sample from the original note app.
Convert the sample with Jimmy instead of converting everything immediately.
Check Markdown body text, images, attachments, tags, creation time, and internal links.
Confirm that the target app, such as Obsidian or Joplin, recognizes the directory structure and front matter correctly.
Convert the full export package.
Keep both the original export and converted result until you have verified everything.

This is a bit slower, but it avoids discovering missing attachments, broken links, or wrong tag structure only after the migration is done.

My Take

Jimmy is useful because it turns note migration from “relying on one app’s importer” into “convert to universal Markdown first”. It supports many sources, and its output is general enough to help free a personal knowledge base from closed formats.

If you only export one or two notes occasionally, you may not need it. But if you have years of notes, attachments, and document folders and want to move to Obsidian, Joplin, or a Git-managed Markdown workflow, Jimmy is worth trying. It is best used as a migration middle layer: first turn data into readable, backup-friendly, batch-processable text, then decide which note system should own it.

Project link: marph91/jimmy
Documentation: Jimmy - Note Conversion Tool

Ghostty Docs Quick Read: Installation, Configuration, and Daily Usage Notes

Fri, 15 May 2026 14:50:11 +0800

Ghostty is a new terminal emulator, but it is not simply “another faster terminal.” According to its official documentation, it tries to balance three goals at the same time: speed, features, and a native desktop experience. In other words, it wants GPU acceleration and solid rendering performance, while also feeling like a real local app on macOS and Linux instead of pushing every interaction into a custom-drawn interface.

If you currently use iTerm2, Kitty, Alacritty, WezTerm, or the system terminal, the most interesting part of Ghostty is not one isolated feature. It is the way it combines “works out of the box” with “deeply configurable.” The default configuration is already usable, but when you want to tune it further, the docs provide complete entry points for configuration files, themes, keybindings, fonts, Shell integration, and terminal control sequences.

Start with the Positioning

Ghostty’s core positioning can be summarized in three points:

It is a cross-platform terminal emulator, currently focused on macOS and Linux.
It uses platform-native UI: Swift, AppKit, and SwiftUI on macOS; Zig and GTK4 on Linux.
Its terminal core is libghostty, and the GUI applications are built around this shared core.

This design affects daily use. Tabs, splits, error prompts, window state restoration, system shortcuts, and similar features are not merely components that “look like a desktop app.” They try to follow the interaction conventions of each operating system. The default shortcuts on macOS and Linux also differ according to platform expectations.

Installation: Direct on macOS, Distribution-Dependent on Linux

The official prebuilt binaries mainly target macOS. The most common installation path is to download the .dmg, open it, and drag Ghostty into the Applications folder. Homebrew users can also use the community-maintained cask:

`1`	`brew install --cask ghostty`

Linux is more fragmented. The Ghostty docs separate package managers, community binaries, and source builds for different distributions. Arch, Alpine, Gentoo, NixOS, Snap, Solus, Void, and others all have their own paths. If a distribution has no official or trusted repository, the docs lean toward building from source rather than casually installing third-party binaries.

This matters especially on servers and workstations: a terminal emulator handles a large amount of input and output, clipboard data, links, SSH sessions, and local file paths. It is better to be conservative with the installation source, preferring the official macOS package, distribution repositories, or a build process whose source you can audit.

Configuration: Do Not Rush to Copy a Giant dotfiles Setup

Ghostty’s configuration philosophy is “usable with zero configuration.” The default font includes JetBrains Mono and Nerd Font support, so most users can work normally the first time they open it. The docs even suggest that if you must configure a non-subjective option to feel comfortable, it may be worth asking whether that behavior should become the default.

When you do need customization, Ghostty uses a text configuration file. The current configuration file name is config.ghostty, while older versions also support config. Common paths include:

$XDG_CONFIG_HOME/ghostty/config.ghostty
$XDG_CONFIG_HOME/ghostty/config
$HOME/.config/ghostty/config.ghostty
$HOME/.config/ghostty/config

On macOS, Ghostty also reads:

1
2

$HOME/Library/Application Support/com.mitchellh.ghostty/config.ghostty
$HOME/Library/Application Support/com.mitchellh.ghostty/config

The syntax is straightforward: key = value. For example:

font-family = JetBrains Mono
font-size = 14
theme = light:Rose Pine Dawn,dark:Rose Pine
keybind = ctrl+shift+t=new_tab

A practical suggestion: do not start by copying someone else’s full configuration. A steadier approach is to run it bare for a few days and change only three things at first: font family, font size, and theme. Once you actually feel friction around shortcuts, splits, windows, or Shell integration, add those settings one by one.

Documentation Lookup: Full Configuration Reference Is Available Locally

Ghostty has many configuration options, and the official docs collect them in the Option Reference. Besides the web page, you can query the reference locally after installation:

`1`	`ghostty +show-config --default --docs`

This command prints the default configuration and documentation to standard output, which is useful when piped into a pager:

`1`	`ghostty +show-config --default --docs \| less`

To list available fonts:

`1`	`ghostty +list-fonts`

To list built-in and available themes:

`1`	`ghostty +list-themes`

To view default keybindings:

`1`	`ghostty +list-keybinds --default`

These commands are more reliable than copying snippets from the web, because they come from the Ghostty version installed on your own machine.

Keybindings: Treat “Actions” as the Core Concept

Ghostty’s keybinding format is:

`1`	`keybind = trigger=action`

trigger is the key sequence, and action is the operation Ghostty performs. Creating a new tab, closing the current surface, reloading configuration, and jumping to a prompt are all actions. The model is clear: you are not “changing a menu item”; you are binding an input sequence to an action.

After changing configuration, you can reload it at runtime. The default shortcut is:

Linux: ctrl+shift+,
macOS: cmd+shift+,

Not every setting takes effect immediately. Some options only affect newly created terminals, while others require a full restart. If “the config is written but nothing changed,” check the documentation for that option before spending too much time suspecting syntax.

Themes and Fonts: Use Built-Ins First, Then Tune

Ghostty ships with many themes and supports switching themes according to the system light or dark mode:

`1`	`theme = light:Rose Pine Dawn,dark:Rose Pine`

Themes can also come from custom files. The docs are clear here: a theme file is essentially a Ghostty configuration file and can set many options, so do not casually use themes from untrusted sources.

For fonts, font-family can be repeated to specify fallback fonts. This is useful in multilingual environments: the primary font can handle English and symbols, while later fonts cover Chinese, Japanese, or other characters. When you encounter display details such as emoji, bold, italic, or ligatures, look up the corresponding options in the Option Reference.

Shell Integration: Especially Important for SSH Users

Ghostty supports automatic Shell integration injection for bash, elvish, fish, nushell, and zsh. When enabled, several interactions become more natural:

New terminals can open in the previous terminal’s working directory.
Complex prompts can redraw correctly after resize instead of reflowing badly.
You can jump between command outputs using prompt markers.
Cursor behavior at the prompt can better match editing habits.

If you do not want automatic injection, disable it in the configuration:

`1`	`shell-integration = none`

SSH deserves extra attention. Ghostty uses xterm-ghostty as TERM, but many remote hosts do not yet have the corresponding terminfo. The docs provide two Shell integration features, ssh-env and ssh-terminfo, which are disabled by default and can be enabled as needed:

`1`	`shell-integration-features = ssh-env,ssh-terminfo`

If you often connect to old servers, containers, bastion hosts, or tightly managed production environments, read the official Terminfo and Shell Integration docs before enabling these features. Terminal capability negotiation looks minor, but when it goes wrong, the symptoms can be strange colors, broken shortcuts, or garbled full-screen programs.

My Suggested Onboarding Order

If you only want to judge whether Ghostty fits you, try this sequence:

Install it and use it for a day without writing any configuration.
Adjust only font-family, font-size, and theme.
Use ghostty +list-keybinds --default to inspect default shortcuts instead of importing someone else’s shortcut table first.
If you use SSH often, check remote host terminfo compatibility early.
Finally, tune splits, windows, transparency, title bar, background image, and other visual or workflow preferences.

Ghostty’s docs are engineering-oriented. They are better read as a configuration reference manual than as a marketing page. For most users, the real evaluation criteria are simple: does the default experience already feel comfortable, and are your daily editor, Shell, SSH, tmux, or Zellij workflows stable? If those pieces work well, Ghostty deserves a place on your long-term terminal shortlist.

References

Awesome Codex Skills: A Community Catalog for Extending Codex CLI

Thu, 07 May 2026 20:19:15 +0800

ComposioHQ’s awesome-codex-skills is a community catalog for Codex CLI skills. Its value is not another pile of prompt templates, but a way to package repeatable workflows into installable, reusable, and maintainable Skills.

If you already use Codex as part of daily development, this kind of repository is immediately useful: rules, commands, reference materials, and operating steps that you used to explain again and again can be written down once, then reused whenever the matching Skill is invoked.

What This Repository Solves

Codex Skills can be understood as specialized work modes for Codex CLI. A normal prompt is good for one temporary instruction; a Skill is better for something you want to reuse over time.

For example, you may often need to:

generate commit messages in a fixed format;
look up a specific family of API documentation;
run project-specific test and deployment commands;
rewrite articles, translate docs, or organize notes according to team rules;
call external tools for repetitive development tasks.

Typing these instructions every time quickly becomes overhead. A Skill puts the rules into a standalone directory. The core is usually a SKILL.md file, sometimes accompanied by scripts, templates, reference documents, or assets. When Codex is triggered, it reads the instructions and follows the workflow described there.

How It Differs From a Prompt

A prompt is more like a one-off instruction: “do this task this way.” A Skill is closer to a small operating manual: “whenever this class of task appears, work in this way.”

Its main advantages are:

Reusable: common workflows no longer need copy-and-paste setup.
Reviewable: skill files are usually local Markdown files that can be opened, edited, and versioned.
Extensible: complex skills can include scripts, templates, and references, not just natural language instructions.

That is why catalogs like awesome-codex-skills are useful: they help you discover existing skills, then adapt them to your own workflow.

Installation and Use

The repository provides an installation script and also supports manual installation. A typical flow is:

1
2
3

git clone https://github.com/ComposioHQ/awesome-codex-skills.git
cd awesome-codex-skills
python install.py

If you only want to try a few skills, read the SKILL.md in each skill directory first. Check what it reads, what scripts it may run, what files it may edit, and whether the defaults fit your local environment.

After installation, Codex can match skills when the task calls for them, or you can name a skill explicitly. For long-term use, the most practical approach is often to install a community skill first, then rewrite the instructions around your own project conventions.

Which Skills Are Worth Watching

The most valuable skills are not necessarily the ones with the flashiest names. They are the ones that reliably remove repeated work.

I would first look at:

Development workflow skills: review, testing, commits, releases, dependency checks.
Documentation skills: rewriting, translation, summarization, structured organization.
Tool integration skills: connecting Codex to external services, APIs, and CLI tools.
Project convention skills: encoding team rules, directory structure, naming conventions, and deployment steps.

If a skill merely wraps a single sentence prompt, it has limited value. If it can connect research, judgment, execution, verification, and output into a stable workflow, it is worth keeping.

What to Watch Out For

Community skills are convenient, but they should not be treated as black boxes. This is especially true for Skills that include scripts. Before installing one, check:

what SKILL.md asks Codex to do;
whether it includes scripts that access the network, read or write files, or call external services;
whether the default paths, commands, and permissions fit your machine.

A Skill expands what Codex can do. Written well, it makes Codex feel more like a teammate who knows your project. Written carelessly, it can bring unsuitable rules into your workflow. The best pattern is not to install many skills, but to keep a small set, tune them carefully, and maintain them over time.

My Take

awesome-codex-skills is worth bookmarking, especially if you already use Codex CLI for real development, documentation, or automation work. It is not an official capability by itself; it is a community entry point for finding and adapting reusable workflows.

For heavy users, the point of Codex Skills is not simply helping AI remember more. It is helping AI make fewer detours on repeated tasks. Writing rules as Skills turns temporary instructions into reusable working infrastructure.

Warp Open Source: From Terminal to Agentic Development Environment

Thu, 07 May 2026 20:15:08 +0800

warpdotdev/warp is the open-source client repository for Warp. Warp now describes itself as an “agentic development environment, born out of the terminal”: it starts from the terminal, but brings AI coding agents, codebase indexing, task management, and development workflows into one environment.

This is not an ordinary open-source terminal emulator repository. It is closer to an answer to a larger question: as agents such as Claude Code, Codex, and Gemini CLI become common, should the terminal itself become a development environment for scheduling, observing, and managing agents?

Warp’s answer is yes.

Current State of the Repository

As of May 7, 2026, warpdotdev/warp is a public repository. GitHub shows roughly 56k stars and 4.1k forks. The README says the Warp client code is now open source and welcomes community contributions.

The main language is Rust. GitHub’s language breakdown shows Rust at over 98%, which matches Warp’s positioning: it is not a web wrapper, but a cross-platform native development tool.

Several README details matter:

Warp is an agentic development environment, born out of the terminal.
It can use its built-in coding agent and can also connect to external CLI agents such as Claude Code, Codex, and Gemini CLI.
OpenAI is the founding sponsor of the newly open-sourced Warp repository.
The agentic management workflows in the repository are powered by GPT models.
Warp UI framework crates use the MIT license, while the rest of the code uses AGPL v3.

This shows that Warp’s open source move is not merely publishing a terminal. It is operating the project as an experiment ground for agent workflows.

Warp Is More Than a Terminal

Traditional terminals mainly do three things:

start a shell;
run commands;
display output.

Warp’s earlier differentiation was making the terminal feel more modern: command blocks, completion, history, collaboration, UI-style interactions, and cross-platform polish. Now the focus has moved further toward organizing development around AI agents.

From the README, Warp no longer only emphasizes “a better terminal.” It emphasizes:

built-in coding agents;
external CLI agent support;
issue triage;
spec writing;
PR review;
contributor coordination;
observable agent sessions.

In other words, Warp wants to turn the terminal from “where you type commands” into “where you work with multiple agents.”

Oz and Open-Source Project Management

The README mentions Oz several times.

Warp’s contribution overview shows thousands of Oz agents working on issue triage, specs, implementation, and PR review. This is interesting because it extends AI agents from “helping one person write code” to “helping manage open-source collaboration.”

The hardest part of many open-source projects is not writing code, but maintenance:

too many issues, not enough classification;
bugs and feature requests mixed together;
new contributors unsure which tasks are approachable;
PR review pressure;
maintainers struggling to follow every community thread.

Warp’s idea is to let agents take on part of the project management and collaboration work first. The README also mentions Oz for OSS, a maintainer-facing program for bringing similar agentic open-source management workflows to other repositories.

This suggests that Warp’s ambition is not only the terminal product itself, but also a new model of open-source maintenance in the AI era.

Repository Structure and Tech Stack

From the repository structure, Warp is a large Rust project.

The root contains:

app/: main application code.
crates/: core Rust crates.
assets/: resource files.
command-signatures-v2/: command signature related content.
docker/, script/, resources/, specs/, and other engineering directories.
.claude/, .warp/, .agents/skills, and other agent-related configuration.

WARP.md gives more engineering detail. It describes Warp as a Rust-based terminal emulator using an in-house UI framework called WarpUI.

The major modules can be roughly understood as:

app/: terminal emulation, shell management, AI integration, Drive, authentication, settings, workspace, and sessions.
crates/warp_core/: core utilities and platform abstraction.
crates/editor/: text editing functionality.
crates/warpui/ and crates/warpui_core/: the in-house UI framework.
crates/ipc/: inter-process communication.
crates/graphql/: GraphQL client and schema.

WARP.md also mentions architectural features such as:

an Entity-Handle system;
a modular workspace structure;
macOS, Windows, Linux, and WASM targets;
AI integration, including Agent Mode, context awareness, and codebase indexing;
Warp Drive cloud sync.

This complexity is closer to a full IDE than a lightweight traditional terminal.

Local Build Commands

The README gives a concise local build flow:

1
2
3

./script/bootstrap
./script/run
./script/presubmit

Where:

./script/bootstrap performs platform-specific initialization.
./script/run builds and runs Warp.
./script/presubmit runs formatting, clippy, tests, and other pre-submit checks.

WARP.md also lists more detailed commands:

cargo run
cargo bundle --bin warp
cargo nextest run --no-fail-fast --workspace --exclude command-signatures-v2
cargo fmt
cargo clippy --workspace --all-targets --all-features --tests -- -D warnings

If you want to contribute to Warp, ./script/presubmit is effectively required.

Contribution Flow

Warp’s contribution flow is not simply “open a PR.”

The README describes a lightweight process from issue to PR:

Search existing issues first.
If there is no duplicate, file a bug or feature request.
Maintainers review the issue and may add readiness labels.
ready-to-spec means the design can be expanded into a spec.
ready-to-implement means the design is clear enough to start an implementation PR.
Contributors can pick up labeled issues.

This process fits a large open-source project. It separates ideas, design, and implementation, reducing the risk that contributors spend time building in the wrong direction.

It also fits AI agents well. An agent can organize issues, draft specs, add tests, and then move into implementation. Warp itself uses this pattern to demonstrate agentic project management.

License: MIT + AGPL v3

Warp uses a dual license structure.

The README says:

the Warp UI framework, namely the warpui_core and warpui crates, uses the MIT license;
the rest of the repository uses AGPL v3.

This matters. AGPL v3 has stronger open-source requirements for network services and distribution. If you are learning, researching, or contributing, it is usually straightforward. But if you want to use Warp code in a commercial product or closed-source derivative, you need to read the license carefully and consult legal advice if necessary.

In short, Warp is open source, but not “take it and close-source it freely” open source.

Why It Is Worth Watching

First, Warp brings the terminal, agents, and project management together.

Many AI coding tools are still CLI tools or editor plugins. Warp starts from the terminal entry point and tries to unify agent tasks, code execution, command output, PR workflows, and team collaboration.

Second, Warp’s open-source approach is a good place to observe agent workflows.

It does not only publish code. It also exposes contribution overviews, agent sessions, issue triage, and spec workflows. For anyone studying how AI can participate in open-source collaboration, the repository itself is a sample.

Third, Warp is a complex Rust desktop application.

If you want to study Rust GUI, terminal emulation, cross-platform apps, GraphQL clients, cloud sync, and AI integration, the repository has a lot to read. But it is not a small project, so new contributors should read the docs and issue process first.

Fourth, Warp supports both a built-in agent and a “bring your own CLI agent” approach.

This is realistic. Developers will not use only one agent. Claude Code, Codex, Gemini CLI, OpenCode, OpenClaw, and similar tools are likely to coexist. If Warp can become a workbench for them, it becomes more valuable than a single-purpose terminal.

Who Should Care

If you are a normal terminal user, Warp matters because the terminal may be changing from a command-line tool into an AI workbench.

If you are a heavy AI coding agent user, Warp is worth watching because it tries to manage multiple agents rather than act as another chat entry point.

If you maintain open-source projects, the Oz for OSS direction is worth attention. It explores agent-based issue triage, PR review, community collaboration, and contributor onboarding.

If you are a Rust developer, Warp is a real large-scale desktop application worth studying for UI organization, terminal internals, cloud sync, AI integration, and cross-platform code.

If you only want a terminal that can replace your current one immediately, it is better to download the stable release first, then decide whether to study the source. Building from source is more suitable for contributors and deep users.

Short Take

The point of Warp going open source is not merely “a modern terminal became open source.”

More precisely, Warp is trying to upgrade the terminal into an agentic development environment: the terminal connects the shell, codebase, command execution, agents, issues, PRs, and collaboration flow.

As AI coding agents keep growing, the entry point of the development environment may change. In the past, the IDE dominated the developer experience while the terminal ran commands. Now the terminal may become the center of agent collaboration. The Warp repository is exploring that possibility.

GitHub repository: https://github.com/warpdotdev/warp
Warp website: https://www.warp.dev
Warp documentation: https://docs.warp.dev
Warp build overview: https://build.warp.dev
WARP.md: https://github.com/warpdotdev/warp/blob/master/WARP.md
CONTRIBUTING.md: https://github.com/warpdotdev/warp/blob/master/CONTRIBUTING.md

GoAccess Latest Build-from-Source Notes: From Source Install to Real-Time HTML Reports

Wed, 29 Apr 2026 00:08:00 +0800

This is organized for 2026-04-29.
At this point, the latest stable version listed in the official README is 1.10.2.

1. Install build dependencies first

1
2
3

sudo apt-get update
sudo apt-get install -y build-essential wget tar \
  libncurses-dev libmaxminddb-dev libssl-dev zlib1g-dev

2. Download the latest source package

cd /usr/local/src
sudo wget https://tar.goaccess.io/goaccess-1.10.2.tar.gz
sudo tar -xzvf goaccess-1.10.2.tar.gz
cd goaccess-1.10.2

3. Configure build options

`1`	`sudo ./configure --enable-utf8 --enable-geoip=mmdb --with-zlib`

If you also want TLS support for real-time HTML reports:

`1`	`sudo ./configure --enable-utf8 --enable-geoip=mmdb --with-zlib --with-openssl`

4. Build and install

1
2

sudo make
sudo make install

5. Verify the version

1
2

goaccess --version
which goaccess

6. View reports directly in the terminal

For common Nginx or Apache combined logs:

`1`	`goaccess /var/log/nginx/access.log --log-format=COMBINED`

If the log path is Apache:

`1`	`goaccess /var/log/apache2/access.log --log-format=COMBINED`

7. Generate a static HTML report

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o /usr/share/nginx/html/goaccess-report.html

You can also write it to the current directory:

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o report.html

8. Generate a real-time HTML report

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o /usr/share/nginx/html/goaccess-report.html \
  --real-time-html

To change the port:

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o /usr/share/nginx/html/goaccess-report.html \
  --real-time-html \
  --port=7891

To bind only to localhost:

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o /usr/share/nginx/html/goaccess-report.html \
  --real-time-html \
  --addr=127.0.0.1

9. Follow logs continuously

`1`	`tail -f /var/log/nginx/access.log \| goaccess --log-format=COMBINED -`

From the beginning of the file and keep it live:

tail -f -n +0 /var/log/nginx/access.log | goaccess \
  --log-format=COMBINED \
  -o report.html \
  --real-time-html -

10. Look at only certain requests

For example, only requests containing firefox:

1
2

tail -f /var/log/nginx/access.log | grep -i --line-buffered 'firefox' | goaccess \
  --log-format=COMBINED -

For example, only 5xx and 3xx:

1
2
3

tail -f -n +0 /var/log/nginx/access.log | awk '$9~/3[0-9]{2}|5[0-9]{2}/' | goaccess \
  --log-format=COMBINED \
  -o out.html -

11. Analyze multiple logs together

`1`	`goaccess /var/log/nginx/access.log /var/log/nginx/access.log.1 --log-format=COMBINED`

Read compressed and uncompressed logs together:

`1`	`zcat --force /var/log/nginx/access.log* \| goaccess --log-format=COMBINED -`

12. Enable multithreading

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -o report.html \
  -j 4

Increase chunk size:

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -o report.html \
  -j 4 \
  --chunk-size=8192

13. Incremental processing

Persist an older log first:

`1`	`goaccess /var/log/nginx/access.log.1 --log-format=COMBINED --persist`

Then append the current log:

`1`	`goaccess /var/log/nginx/access.log --log-format=COMBINED --restore --persist`

Read only persisted data:

`1`	`goaccess --restore`

14. The set of commands I would run first

sudo apt-get update
sudo apt-get install -y build-essential wget tar \
  libncurses-dev libmaxminddb-dev libssl-dev zlib1g-dev

cd /usr/local/src
sudo wget https://tar.goaccess.io/goaccess-1.10.2.tar.gz
sudo tar -xzvf goaccess-1.10.2.tar.gz
cd goaccess-1.10.2
sudo ./configure --enable-utf8 --enable-geoip=mmdb --with-zlib --with-openssl
sudo make
sudo make install

goaccess --version

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o /usr/share/nginx/html/goaccess-report.html \
  --real-time-html

That is basically it.
If your goal is clear, getting the latest source build installed and making --log-format=COMBINED plus --real-time-html work first is usually enough. After that, most changes are just about log paths, output files, and ports.

Development Tools on KnightLi Blog

Jimmy: Convert Exports from Evernote, Notion, Google Keep, and More into Markdown

What Jimmy Solves

Many Supported Note Apps

It Can Also Convert Regular Documents

Two Ways to Use It

Main Characteristics

Who Should Use It

Pre-Migration Checklist

My Take

Ghostty Docs Quick Read: Installation, Configuration, and Daily Usage Notes

Start with the Positioning

Installation: Direct on macOS, Distribution-Dependent on Linux

Configuration: Do Not Rush to Copy a Giant dotfiles Setup

Documentation Lookup: Full Configuration Reference Is Available Locally

Keybindings: Treat “Actions” as the Core Concept

Themes and Fonts: Use Built-Ins First, Then Tune

Shell Integration: Especially Important for SSH Users

My Suggested Onboarding Order

References

Awesome Codex Skills: A Community Catalog for Extending Codex CLI

What This Repository Solves

How It Differs From a Prompt

Installation and Use

Which Skills Are Worth Watching

What to Watch Out For

My Take

Warp Open Source: From Terminal to Agentic Development Environment

Current State of the Repository

Warp Is More Than a Terminal

Oz and Open-Source Project Management

Repository Structure and Tech Stack

Local Build Commands

Contribution Flow

License: MIT + AGPL v3

Why It Is Worth Watching

Who Should Care

Short Take

Related Links

GoAccess Latest Build-from-Source Notes: From Source Install to Real-Time HTML Reports

1. Install build dependencies first

2. Download the latest source package

3. Configure build options

4. Build and install

5. Verify the version

6. View reports directly in the terminal

7. Generate a static HTML report

8. Generate a real-time HTML report

9. Follow logs continuously

10. Look at only certain requests

11. Analyze multiple logs together

12. Enable multithreading

13. Incremental processing

14. The set of commands I would run first