Home on Sven Koschnicke

Inline Preview for Source File Links in Emacs

Wed, 13 May 2026 00:00:00 +0000

While working, I constantly take notes using org-mode. Because I often work with code, I extensively use the ability of org-mode to link directly into code files when I need to reference where something can be found. Something like [[file:~/src/foo/bar.el::42][the bit that parses the header]]. I can easily follow this link and have the file open in emacs, but in the note itself the link is just some underlined text. To remind myself what is behind the link I have to jump there, look, and jump back. That gets annoying.

What I really wanted was for org to show me the relevant lines right below the link, the way it already inlines images. Here is what the same link looks like before and after:

The hook org already gives us

Org 9.7 ships org-link-preview natively, but out of the box it only knows how to preview images. The good news is that the mechanism is generic: every link type can register a :preview function via org-link-set-parameters, and org will call it with an overlay it has already placed on top of the link. Whatever the function puts on that overlay is what the user sees.

That is the entire trick. The rest of this post is just filling in the preview function for file: and attachment: links so that, when the link points at a specific line, we render a syntax-highlighted snippet around it.

Resolving the link to a snippet

A file link in org can carry a search option after ::. It can be a line number (foo.el::42) or a piece of text (foo.el::defun my-thing) — org uses it when following the link to jump to the right spot, and we want to use it as the anchor for the preview.

The helpers below do four things: turn a text search into a line number, guess the source-block language from the file extension (so the snippet gets the right fontification when re-inserted), apply font-lock to the extracted text, and finally format the result with a 👉 marker on the target line so it’s obvious which line the link actually points at.

(defcustom my/org-link-preview-context-lines 5
 "Number of context lines to show before and after target line."
 :type 'integer
 :group 'org-link)

(defun my/org-link-find-line-by-text (file search-text)
 "Find line number in FILE that contains SEARCH-TEXT.
Returns line number or nil if not found."
 (when (and file (file-exists-p file) search-text)
 (with-temp-buffer
 (insert-file-contents file)
 (goto-char (point-min))
 (when (search-forward search-text nil t)
 (line-number-at-pos)))))

(defun my/org-link-get-language-from-extension (file)
 "Get org-babel language identifier from FILE extension."
 (let* ((mode (assoc-default file auto-mode-alist 'string-match))
 (mode-name (and mode (symbol-name mode))))
 (if mode-name
 (let ((lang (replace-regexp-in-string "-mode$" "" mode-name)))
 (cond
 ((assoc lang org-src-lang-modes) lang)
 ((string= lang "js") "javascript")
 (t lang)))
 (or (file-name-extension file) "text"))))

(defun my/org-link-apply-syntax-highlighting (content file)
 "Apply syntax highlighting to CONTENT based on FILE's major mode."
 (with-temp-buffer
 (insert content)
 (let ((mode (assoc-default file auto-mode-alist 'string-match)))
 (when (and mode (fboundp mode))
 (ignore-errors
 (funcall mode)
 (font-lock-ensure))))
 (buffer-string)))

(defun my/org-link-format-preview-content (content start-line target-line)
 "Format CONTENT as preview with optional TARGET-LINE highlighting."
 (with-temp-buffer
 (insert content)
 (goto-char (point-min))
 (let ((current-line start-line)
 (result ""))
 (while (not (eobp))
 (let* ((line-text (buffer-substring (point) (line-end-position)))
 (is-target (and target-line (= current-line target-line))))
 (setq result
 (concat result
 (if is-target
 (propertize (concat "👉 " line-text "\n") 'face 'hl-line)
 (concat " " line-text "\n"))))
 (setq current-line (1+ current-line))
 (forward-line 1)))
 result)))

(defun my/org-link-get-file-preview (file target-line)
 "Get preview text for FILE centered around TARGET-LINE.
Returns propertized string formatted as an org source block, or nil."
 (when (and file (file-exists-p file) target-line)
 (with-temp-buffer
 (insert-file-contents file)
 (let* ((language (my/org-link-get-language-from-extension file))
 (start-line (max 1 (- target-line my/org-link-preview-context-lines)))
 (end-line (+ target-line my/org-link-preview-context-lines)))
 (goto-char (point-min))
 (forward-line (1- start-line))
 (let* ((content-start (point))
 (content-end (progn (forward-line (- end-line start-line -1)) (point)))
 (content (buffer-substring content-start content-end))
 (highlighted (my/org-link-apply-syntax-highlighting content file))
 (formatted (my/org-link-format-preview-content
 highlighted start-line target-line))
 (line-info (format " :file %s :line %d"
 (file-name-nondirectory file) target-line)))
 (concat (propertize (format "#+begin_src %s%s\n" language line-info)
 'face 'org-block-begin-line)
 formatted
 (propertize "#+end_src" 'face 'org-block-end-line)))))))

There’s nothing clever in there — the only thing worth pointing at is that the snippet is wrapped in a fake #+begin_src / #+end_src pair with the filename and line baked into the header. That way the rendered overlay looks exactly like a normal org source block, getting nice syntax highlighting in the process.

Wiring it into org-link-preview

A :preview function receives (OV PATH LINK). The contract is: configure the overlay OV however you like and return non-nil to keep it, or return nil to have org throw the overlay away. We render the snippet via after-string so it appears below the link instead of replacing it — keeping the original link visible matters, because there might also be information in the link description.

The function only kicks in when the link has a search option. If there isn’t one, there’s nothing to anchor the preview to, so we fall through to org’s built-in image previewer. That way PNGs and friends still inline as before, and we register the same dispatcher for both file: and attachment: links so org-attach works too.

(defun my/org-link-preview-source-file (ov path link)
 "Preview a source-file link as a snippet over overlay OV.
Handles file links with a numeric (::42) or text (::needle) search
option. Returns non-nil on success, nil to let org fall back."
 (let ((search-option (org-element-property :search-option link)))
 (when search-option
 (let* ((file (expand-file-name path))
 (line (if (string-match "\\`\\([0-9]+\\)\\'" search-option)
 (string-to-number (match-string 1 search-option))
 (my/org-link-find-line-by-text file search-option)))
 (preview (my/org-link-get-file-preview file line)))
 (when preview
 (overlay-put ov 'after-string (concat "\n" preview "\n"))
 (overlay-put ov 'face 'default)
 t)))))

(defun my/org-link-preview-file-dispatch (ov path link)
 "Try source-file preview first, fall back to org's image previewer."
 (or (my/org-link-preview-source-file ov path link)
 (org-link-preview-file ov path link)))

(with-eval-after-load 'ol
 (org-link-set-parameters "file" :preview #'my/org-link-preview-file-dispatch)
 (org-link-set-parameters "attachment" :preview #'my/org-link-preview-file-dispatch))

One small papercut: links with descriptions

There’s one last annoyance. By default org-link-preview skips links that have a description — which is, of course, most of the links I actually want previewed, because I tend to write [[file:foo.el::42][the parser]] rather than dumping the raw path into the buffer. The fix is a one-line wrapper that passes the include-linked prefix argument so the link at point always gets previewed, plus a Spacemacs binding under SPC m l p. To clear a preview, C-u M-x org-link-preview still works as usual.

(defun my/org-link-preview-here ()
 "Preview the link at point, including links with descriptions."
 (interactive)
 (org-link-preview 1))

(with-eval-after-load 'org
 (spacemacs/set-leader-keys-for-major-mode 'org-mode "lp" 'my/org-link-preview-here))

Another step towards a better editor

There is room for improvement here. It doesn’t work if there are multiple matching texts or no position in the link at all. But I can now read my notes without context switching to the source file. It’s also satisfying to have used an extension point that was designed for this kind of thing instead of creating everything from scratch (which was what I had before). Just some small customization making the editor I spend most of my day in a bit more at home.

Overengineering a static website

Mon, 23 Feb 2026 00:00:00 +0000

The Boring Way

In the beginning, there was static HTML served by Apache. Then everyone wanted dynamic content, so we got CGI, then PHP, and suddenly every website was dynamic — even the ones that didn’t need to be. Today, static site generators have brought us full circle. Write some Markdown (or org-mode, because it’s better), let Hugo convert it to HTML, push to GitHub, done. I did exactly that with the first versions of this homepage. It works well. The Hugo conversion can even run in a GitHub workflow.

The Custom Server

But it’s also a little bit boring. I thought about how a generic webserver like Nginx could never be optimized to such an extend for serving my static website because it needs to be usable for other use-cases, too. I wanted to try if it would be faster to keep all the pages in memory the way they need to be sent to the client. So I wrote a custom webserver in Rust which gets all the content compiled into the binary on build time. Then I did some benchmarks. The Rust server was over 16 times faster than a standard Nginx server.

Test Environment:

Hugo site: ~6.4MB, 89 files
Benchmark tool: wrk (4 threads, 100 connections, 30 seconds)
Rust server: Port 3000 (optimized release build)
nginx: Port 8080 (Alpine, podman container, default config)

Results Summary

Test Case	Rust Req/s	nginx Req/s	Speedup	Rust Latency	nginx Latency
Homepage (HTML)	122,519	7,261	16.8x	754μs	16.95ms
CSS (fingerprinted)	129,547	8,791	14.7x	712μs	15.92ms
PNG Image (large)	28,155	10,494	2.7x	2.15ms	16.81ms

That was promising, so I added TLS support to the server. When comparing the deployed custom server with GitHub pages, Github pages still wins in overall response speed. That is because the most time of a web request is not spent waiting for the webserver but transferring the data from the server to the client, because the user is rarely sitting right next to the datacenter where the server is located.

To make the distance between server and client as short as possible, one uses a content delivery network (CDN). The static content is copied to multiple datacenters all over the world and served from the location nearest to the user. GitHub pages distributes the content through a CDN by default and that makes it faster than any single webserver in one location (except when the user happens to be near this single server).

But what a CDN can’t do is serve dynamic content. So I added a dynamic component to my homepage in the form of live statistics about requests to the server. It is nothing really useful, but it is something a CDN cannot do. You can see the statistics in action below each page. Click on “Show more” to see some diagrams. I made sure to only use data that cannot identify or track you. For now, the number of concurrent page requests (in a one second window) and the response time (that is, how long the server needs to respond to the request, not how long it takes response to reach the client) are measured. No IPs or other information are stored.

Going Full Unikernel

I could have stopped here. Deploy the Rust server to a virtual private server and be happy. But I didn’t want to stop. The server was already a single binary also containing the content it should serve. So why not skip the whole operating system and deploy the server as a unikernel directly to the hypervisor? The most difficult thing was actually finding a cloud provider that supported that and understanding the API for deployment. I chose Hetzner, because they are based in Europe, but it shows that unikernels are a not so often used technology.

Using the API successfully needed some experimentation, and the ops tool to build an unikernel image needs some polishing, but eventually it worked.

TLS certificates from Let’s Encrypt couldn’t be stored on disk anymore, so I had to use a storage bucket for that (Hetzner provides these with a S3 compatible API). Storing the certificates only in memory would have meant that every deploy needs a new certificate, and that way I might have run into rate limits from Let’s Encrypt.

But now everything works. This website is served from a custom server running directly on the hypervisor. No system updates I have to worry about (the provider cares about the hypervisor), I only have to update the server itself. And it is fast. I also spent some time reducing the amount of data transferred by optimizing the binary files (images, PDFs). The server supports brotli compression (in addition to the standard gzip compression).

It’s still slower than using a CDN if you are not near the datacenter, but everything is properly optimized now and it was a fun learning experience.

Recap

Is this kind of deployment actually better? Speed and reduced attack surface are the advantages. I can also add fun little gimmicks like the statistics, because I control the whole webserver, but there are also not so nice things:

deployment is slow. The binary needs to be built, then the image needs to be built from the binary, then the image needs to be started in the cloud. Takes about 5 to 10 minutes until the new version is online. That’s a long time for small content changes.
no easy debugging in production. I can’t SSH into the server or look at logs (there are no logs, currently). I’d need to create observability infrastructure like OpenTelemetry and some log consumer where the server could send data. Or I’d need to integrate that into the server, extending its attack surface again.
the allocated server resources are way too many for a simple static website. I’m paying about 3.50 euros for the server (2 vCPUs, 4 GB RAM) plus about 6 euros for object storage (that’s basically Hetzner’s base fee, I’m only using a few kilobytes for the certificates).
I can’t share the server resources to run other services like a Mastodon server or a Matrix server

Should static sites be served like this? No, using something like GitHub pages is easier and faster. Maybe I will go from unikernel deployment back to a virtual private server where the binary runs and change the server so that it can dynamically update the in-memory content. That would make better use of the resources and reduce the time it takes to update the content drastically. But in the end, it’s just some fun experiment.

Magic Wormhole

Wed, 07 May 2025 00:00:00 +0000

In a world where software gets more and more complex, and because of that also bloated, there are sometimes little gems which make your day a little bit better. They adhere to the initial goal of software and computers, helping people to get their tasks done. And when they just do their job and then get out of the way, it sometimes makes me smile.

One if these programs I just had the pleasure to use again is Magic Wormhole. A small command line utility which lets you transfer files between two computers.

XKCD “File transfer”

So I wanted to give my laptop SSH access to a server I already had access to from my desktop computer. Of course, login through password is deactivated on the server. So I had to add the public SSH key of my laptop to the authorized_keys file on the server.

I could have sent my public key to myself by email or even put it on an USB stick and get it onto the desktop computer like this and then copy it to the server (using the very handy ssh-copy-id program), but I remembered Magic Wormhole, which would let me transfer the key more easily to my desktop computer.

I had it already installed, but it should be easy to install on almost any system (don’t ask me about Windows, though). Trying to remember how to use it, I entered wormhole --help (actually I first tried wormhole -h, but that doesn’t work):

$ wormhole --help
Usage: wormhole [OPTIONS] COMMAND [ARGS]...

 Create a Magic Wormhole and communicate through it.

 Wormholes are created by speaking the same magic CODE in two different
 places at the same time. Wormholes are secure against anyone who doesn't
 use the same code.

Options:
 --appid APPID appid to use
 --relay-url URL rendezvous relay to use
 --transit-helper tcp:HOST:PORT transit relay to use
 --dump-timing FILE.json (debug) write timing data to file
 --version Show the version and exit.
 --help Show this message and exit.

Commands:
 help
 receive Receive a text message, file, or directory (from 'wormhole send')
 send Send a text message, file, or directory
 ssh Facilitate sending/receiving SSH public keys

Okay, so executing wormhole send .ssh/id_ed25519.pub should give me a code-word which I can use on the receiving machine by executing wormhole receive and get the file securely transferred.

But then the ssh command caught my attention, as it seemed to be exactly my use-case:

$ wormhole ssh --help
Usage: wormhole ssh [OPTIONS] COMMAND [ARGS]...

 Facilitate sending/receiving SSH public keys

Options:
 --help Show this message and exit.

Commands:
 accept Send your SSH public-key
 invite Add a public-key to a ~/.ssh/authorized_keys file

That was perfect. Just executing wormhole ssh invite on the server:

$ wormhole ssh invite
Now tell the other user to run:

wormhole ssh accept 1-embezzle-printer

And then running wormhole ssh accept 1-embezzle-printer on the laptop:

$ wormhole ssh accept 1-embezzle-printer
Sending public key type='ssh-ed25519' keyid='wayreth ssh key'
Really send public key 'wayreth ssh key' ? [y/N]: y
Key sent.

And on the server the program exits with:

Appended key type='ssh-ed25519' id='wayreth' to '/home/sven/.ssh/authorized_keys'

That’s it. Now I could access the server from my laptop. Easy, secure, straight forward.

Hello World

Thu, 02 Jan 2025 00:00:00 +0000

Shipping is a feature, and because I don’t have much time these days, I’ll start with a minimal viable product and get this homepage published as fast as possible. You’ll find my thoughts and insights here soon. Mostly about technology and software development. But I can’t say how often or when.

About

Mon, 01 Jan 0001 00:00:00 +0000

Hey, I’m Sven Koschnicke, a computer nerd with over 25 years of hands-on experience across the entire technology stack. From designing microchips and programming FPGAs to developing high-performance kernel modules, I bring deep technical expertise at every level.

My unique strength lies in true full-stack mastery - seamlessly bridging hardware, systems, and software. Whether it’s DevOps infrastructure, sophisticated backend services, or polished frontend applications, I’ve successfully delivered solutions across the spectrum.

I specialize in tackling complex technical challenges that require innovative thinking and optimization. With my broad knowledge I can successfully steer a team to create a robust and scalable software solution. I focus on creating high-performance, specialized systems that push boundaries and deliver exceptional value.

If you’re looking for someone who can not only understand your technical challenges from every angle but also architect and implement solutions that exceed expectations in both performance and quality, let’s connect.

You can download my full resume in English or in German.

Contact

You can reach me by email: s.koschnicke@gfxpro.com.

My postal address:

GFXpro, z. Hd. Sven Koschnicke
Tannenstraße 16
24229 Schwedeneck
Germany

Bank account:

bunq
IBAN: NL02 BUNQ 2057 0845 58
BIC: BUNQNL2A

Legal / Imprint (in german)

Anbieter und Verantwortlicher im Sinne des § 5 TMG und § 55 Absatz 2 RStV ist:

Sven Koschnicke (Einzelunternehmer)
Tannenstraße 16
24229 Schwedeneck
Germany
E-Mail: s.koschnicke@gfxpro.com
USt-IdNr.: DE235896138

Hinweis für Verbraucher:

Die Europäische Kommission stellt eine Plattform zur Online-Streitbeilegung (OS) bereit: https://ec.europa.eu/consumers/odr

Ich bin nicht bereit oder verpflichtet, an Streitbeilegungsverfahren vor einer Verbraucherschlichtungsstelle teilzunehmen.

Imprint

Mon, 01 Jan 0001 00:00:00 +0000

This website is operated by me, Sven Koschnicke, and I am responsible in terms of data protection rights (see my full address on the about page).

When using this website, no personal information about you is stored by me.

When your browser-software requests a part of this website, it sends some request information to the server providing the website. This request information includes:

your current IP-Address over which you are connected to the internet
name and version of your browser software and operating system
website, from which you reached the requested website if using a hyperlink (the so called referer-URL, it’s misspelling originated in the original proposal for the HTTP specification)
date and time of the request

The request information is required by the server to process your request of the website (Article 6.1(f) GDPR) and is discarded as soon as this request is fulfilled.

Your privacy is very important to me. For this reason, I do not use any third party services on my website, which would receive your request information. I also do not set any cookies which would allow to track you navigating my website. My website is only available over TLS, the standard for encrypted HTTP (called HTTPS), preventing other from seeing or changing the requested sites (only the hostname, sven.guru, for the request is not encrypted, which is a feature of the SNI extension to TLS and allows the server to serve more than one website over TLS).

When you contact me, I store the personal information which is provided along with your message to me. I keep this data as long as necessary for our conversation (Article 6.1(b) GDPR) and as required by law (which is six years for business correspondence in germany, Article 257(4) german commercial code, HGB). Conversations over e-mail are not encrypted by default and you should use PGP to encrypt e-mails. You can find my PGP-key at keybase.io.

When I work for you, I store your contact data in my invoice system, which is called Harvest and is operated by Iridesco, LLC d/b/a Harvest, a New York (USA) limited liability company. Harvest is fully GDPR compliant (see Harvest’s privacy policy). Invoices are stored ten years as required by german law (Article 257(4) german commercial code, HGB).

Additionally to normal bank transfer you can pay me using PayPal and Stripe. When using one of these third party services, the service receives your payment data. You can consult the PayPal privacy policy and the Stripe privacy policy for further details.

In any case, I follow industry standards of technical, physical and administrative security to safeguard your personal information.

If you want to access or change your personal data that I store, you may contact me. You have the right to disclosure, correction, deletion or constraint of your personal data, if permitted by law.

If you are unhappy about how I handle your personal data, you may complain to any data privacy authority. For example to the Independent Centre for Privacy Protection Schleswig-Holstein.

If you have any questions, feel free to contact me.

Privacy Policy

Mon, 01 Jan 0001 00:00:00 +0000

This website is operated by me, Sven Koschnicke, and I am the data controller (see my full address on the about page).

When using this website, no personal information about you is stored.

When your browser-software requests a part of this website, it sends some request information to the server providing the website. This request information includes:

your current IP-Address over which you are connected to the internet
name and version of your browser software and operating system
website, from which you reached the requested website if using a hyperlink (the so called referer-URL, its misspelling originated in the original proposal for the HTTP specification)
date and time of the request

The request information is required by the server to process your request of the website (Article 6.1(f) GDPR). It is not written to any log and is discarded as soon as the request is fulfilled.

The website does store a few small settings in your browser’s local storage (localStorage and sessionStorage), so that it remembers them from one page to the next: the progress of the adventure game, as soon as you click in it (your inventory, solved puzzles, the room you came from, and whether you switched the game off), the colour theme you picked (only until you close the tab), and whether the server metrics panel is expanded. None of this contains an identifier, and none of it is ever sent to the server or anyone else; it stays in your browser. Storing it is necessary for the features you use (Section 25(2) no. 2 TDDDG). You can delete it at any time by clearing this website’s data in your browser.

My website is only available over TLS, the standard for encrypted HTTP (called HTTPS), preventing others from seeing or changing the requested pages (only the hostname, sven.guru, for the request is not encrypted, which is a feature of the SNI extension to TLS and allows the server to serve more than one website over TLS).

When you contact me, I store the personal information which is provided along with your message to me. I keep this data as long as needed to handle your request (Article 6.1(b) GDPR) and as required by law (which is six years for business correspondence in Germany, Article 257(4) German commercial code, HGB). Conversations over e-mail are not encrypted by default and you should use PGP to encrypt e-mails. You can find my PGP-key at keybase.io.

When I work for you, I store your contact data in my invoice system, which is called Harvest and is operated by Iridesco, LLC d/b/a Harvest, a New York (USA) limited liability company. Harvest states that it is GDPR compliant (see Harvest’s privacy policy). Invoices are stored for ten years as required by German law (Article 6.1(c) GDPR, Article 257(4) German commercial code, HGB).

In addition to normal bank transfer, you can pay me using PayPal and Stripe. When using one of these third party services, the service receives your payment data. You can consult the PayPal privacy policy and the Stripe privacy policy for further details.

In any case, I follow industry standards of technical, physical and administrative security to safeguard your personal information.

If you want to access or change your personal data that I store, you may contact me. You have the right to disclosure, correction, deletion or constraint of your personal data, if permitted by law.

If you are unhappy about how I handle your personal data, you may complain to any data privacy authority. For example to the Independent Centre for Privacy Protection Schleswig-Holstein.

If you have any questions, feel free to contact me.

Website Monitor

Mon, 01 Jan 0001 00:00:00 +0000

If you found this page through your server logs: requests with the User-Agent sven.guru website monitor - https://sven.guru/monitoring come from a small, personal, non-commercial uptime monitor run by me, Sven Koschnicke. It checks whether a handful of websites I care about are up. It isn’t a search engine, an archive, an SEO tool or a crawler collecting training data.

How to opt out

Add this to your robots.txt:

User-agent: SvenGuruMonitor
Disallow: /

The monitor caches robots.txt for up to 24 hours, so it stops within about a day. After that it only re-reads your robots.txt once a day to see whether it has changed, and requests nothing else from your site.

What it requests

Only the one configured URL per site, usually the homepage, with GET. It doesn’t crawl or follow links, doesn’t load images, CSS or JavaScript, and doesn’t execute anything.
It follows up to 5 redirects, reads at most the first 64 KB of the response and gives up after 15 seconds.
It records only the status code, the response time and the outcome (ok, error, rate-limited). Page content isn’t stored. Detailed results are kept for 30 days, daily uptime totals after that.
The results only show up on a private dashboard on my home network. Nothing is published.

How often

While a site is healthy: once every 5 minutes (±10% jitter), so about 12 requests an hour, or 290 a day.
After a failed request: one retry after about 1 minute. While a site is down: retries after 1, 2 and 4 minutes, then every 5 minutes.

Rate limiting

A 429 Too Many Requests is never treated as an outage. The monitor just backs off.
Retry-After is honoured on any response, as seconds or as an HTTP date. If it asks for a longer wait than the normal schedule, the monitor waits that long (up to 1 hour per instruction). It never makes the monitor check more often.

robots.txt details

The monitor follows RFC 9309:

Product token: SvenGuruMonitor. The monitor obeys the group for that token if there is one, otherwise the * group.
robots.txt is fetched per origin and cached for up to 24 hours. Every redirect hop is checked against its own origin’s robots.txt before it’s requested.
If robots.txt disallows the URL, the monitor stops requesting the site entirely and only re-reads robots.txt once a day.
A missing robots.txt (404 or any other 4xx) means “allowed”, as the RFC says. If robots.txt can’t be fetched (server error, timeout) and the monitor has no earlier copy, it doesn’t request the site at all.

Contact

If the monitor misbehaves, or you can’t edit your robots.txt, write to me at s.koschnicke@gfxpro.com. I’ll then adjust the monitor for your site.