aboutsummaryrefslogtreecommitdiff
path: root/README.adoc
diff options
context:
space:
mode:
authorPřemysl Eric Janouch <p@janouch.name>2021-08-06 16:12:15 +0200
committerPřemysl Eric Janouch <p@janouch.name>2021-08-06 16:43:59 +0200
commit50057d5149dda340b3b47aca4096f4a6ec66b9ee (patch)
tree79323d20b17c2c8e32942a1ac9b84d9da3041c6d /README.adoc
parent1f64710e795b0c5434d15813d4f1f568467ca087 (diff)
downloadxK-50057d5149dda340b3b47aca4096f4a6ec66b9ee.tar.gz
xK-50057d5149dda340b3b47aca4096f4a6ec66b9ee.tar.xz
xK-50057d5149dda340b3b47aca4096f4a6ec66b9ee.zip
Come up with sillier names for the binaries
I'm not entirely sure, but it looks like some people might not like jokes about the Holocaust. On a more serious note, the project has become more serious over the 7 or so years of its existence.
Diffstat (limited to 'README.adoc')
-rw-r--r--README.adoc78
1 files changed, 39 insertions, 39 deletions
diff --git a/README.adoc b/README.adoc
index f4200e5..ef721aa 100644
--- a/README.adoc
+++ b/README.adoc
@@ -2,25 +2,25 @@ uirc3
=====
:compact-option:
-The [line-through]#unethical# edgy IRC trinity. This project consists of an
-IRC client, daemon, and bot. It's all you're ever going to need for chatting,
-as long as you can make do with minimalist software.
+The unreasonable IRC trinity. This project consists of an IRC client, daemon,
+and bot. It's all you're ever going to need for chatting, as long as you can
+make do with minimalist software.
All of them have these potentially interesting properties:
- IPv6 support
- TLS support, including client certificates
- - lean on dependencies (with the exception of 'degesch')
+ - lean on dependencies (with the exception of 'xC')
- compact and arguably easy to hack on
- very permissive license
-degesch
--------
+xC
+--
The IRC client. It is largely defined by being built on top of GNU Readline
that has been hacked to death. Its interface should feel somewhat familiar for
weechat or irssi users.
-image::degesch.png[align="center"]
+image::xC.png[align="center"]
This is the largest application within the project. It has most of the stuff
you'd expect of an IRC client, such as being able to set up multiple servers,
@@ -28,8 +28,8 @@ a powerful configuration system, integrated help, text formatting, CTCP queries,
automatic splitting of overlong messages, autocomplete, logging to file,
auto-away, command aliases and basic support for Lua scripting.
-kike
-----
+xD
+--
The IRC daemon. It is designed to be used as a regular user application rather
than a system-wide daemon. If all you want is a decent, minimal IRCd for
testing purposes or a small network of respectful users (or bots), this one will
@@ -48,7 +48,7 @@ Not supported:
- server linking (which also means no services); I consider existing protocols
for this purpose ugly and tricky to implement correctly; I've also found no
use for this feature yet
- - online changes to configuration; the configuration system from degesch could
+ - online changes to configuration; the configuration system from xC could
be used to implement this feature if needed
- limits of almost any kind, just connections and mode `+l`
@@ -56,8 +56,8 @@ This program has been
https://git.janouch.name/p/haven/src/branch/master/hid[ported to Go],
and development continues over there.
-ZyklonB
--------
+xB
+--
The IRC bot. It builds upon the concept of my other VitaminA IRC bot. The main
characteristic of these two bots is that they run plugins as coprocesses, which
allows for enhanced reliability and programming language freedom.
@@ -78,8 +78,8 @@ Building
--------
Build dependencies: CMake, pkg-config, asciidoctor, awk, liberty (included) +
Runtime dependencies: openssl +
-Additionally for degesch: curses, libffi, lua >= 5.3 (optional),
- readline >= 6.0 or libedit >= 2013-07-12
+Additionally for xC: curses, libffi, lua >= 5.3 (optional),
+ readline >= 6.0 or libedit >= 2013-07-12
Avoid libedit if you can, in general it works but at the moment history is
acting up and I have no clue about fixing it.
@@ -102,49 +102,49 @@ Or you can try telling CMake to make a package for you. For Debian it is:
Usage
-----
-'degesch' has in-program configuration. Just run it and read the instructions.
-Consult its link:degesch.adoc[man page] for details about the interface.
+'xC' has in-program configuration. Just run it and read the instructions.
+Consult its link:xC.adoc[man page] for details about the interface.
For the rest you might want to generate a configuration file:
- $ zyklonb --write-default-config
- $ kike --write-default-config
+ $ xB --write-default-config
+ $ xD --write-default-config
After making any necessary edits to the file (there are comments to aid you in
doing that), simply run the appropriate program with no arguments:
- $ zyklonb
- $ kike
+ $ xB
+ $ xD
-'ZyklonB' stays running in the foreground, therefore I recommend launching it
-inside a Screen or tmux session.
+'xB' stays running in the foreground, therefore I recommend launching it inside
+a Screen or tmux session.
-'kike', on the other hand, immediately forks into the background. Use the PID
+'xD', on the other hand, immediately forks into the background. Use the PID
file or something like `killall` if you want to terminate it. You can run it
as a `forking` type systemd user service.
Client Certificates
-------------------
-'degesch' will use the SASL EXTERNAL method to authenticate using the TLS
-client certificate specified by the respective server's `tls_cert` option
-if you add `sasl` to the `capabilities` option and the server supports this.
+'xC' will use the SASL EXTERNAL method to authenticate using the TLS client
+certificate specified by the respective server's `tls_cert` option if you add
+`sasl` to the `capabilities` option and the server supports this.
-'kike' uses SHA-1 fingerprints of TLS client certificates to authenticate users.
+'xD' uses SHA-1 fingerprints of TLS client certificates to authenticate users.
To get the fingerprint from a certificate file in the required form, use:
$ openssl x509 -in public.pem -outform DER | sha1sum
-Custom Key Bindings in degesch
-------------------------------
-The default and preferred frontend used in 'degesch' is GNU Readline. This
-means that you can change your bindings by editing '~/.inputrc'. For example:
+Custom Key Bindings in xC
+-------------------------
+The default and preferred frontend used in 'xC' is GNU Readline. This means
+that you can change your bindings by editing '~/.inputrc'. For example:
....
# Preload with system-wide settings
$include /etc/inputrc
# Make M-left and M-right reorder buffers
-$if degesch
+$if xC
"\e\e[C": move-buffer-right
"\e\e[D": move-buffer-left
$endif
@@ -154,12 +154,12 @@ Consult the source code and the GNU Readline manual for a list of available
functions. Also refer to the latter for the exact syntax of this file.
Beware that you can easily break the program if you're not careful.
-How do I make degesch look like the screenshot?
------------------------------------------------
-First of all, you must build it with Lua support. With the defaults, degesch
-doesn't look too fancy because I don't want to depend on Lua or 256-colour
-terminals. In addition to that, I appear to be one of the few people who use
-black on white terminals.
+How do I make xC look like the screenshot?
+------------------------------------------
+First of all, you must build it with Lua support. With the defaults, xC doesn't
+look too fancy because I don't want to depend on Lua or 256-colour terminals.
+In addition to that, I appear to be one of the few people who use black on white
+terminals.
/set behaviour.date_change_line = "%a %e %b %Y"
/set behaviour.plugin_autoload += "fancy-prompt.lua"
@@ -195,5 +195,5 @@ License
This software is released under the terms of the 0BSD license, the text of which
is included within the package along with the list of authors.
-Note that 'degesch' becomes GPL-licensed when you link it against GNU Readline
+Note that 'xC' becomes GPL-licensed when you link it against GNU Readline,
but that is not a concern of this source package. The licenses are compatible.