Activating Warp Speed for Hubzilla's Database

Fri, 25 Jan 2019 12:05:10 +0100 last edited: Sat, 26 Jan 2019 11:04:15 +0100

buckaroo@hub.netzgemeinde.eu

How to significantly gain speed and perfomance for Hubzilla by just some minor adjustments.
Note: The DB section is about MySQL/MariaDB. However, PostgresQL will be similar effected. The solultion is database agnostic.

View article

Preface

As my hub (hub.netzgemeinde.eu) grew I noticed sizable performance issues (including timeouts to hubzilla), originating from the database. The MariaDB in question was on a conventional SAS RAID, therefore the logical step was moving the database to a SSD host, making the old host a slave to the new db master. This significantly improved speed.

However, I noticed something odd: The slave (the former master) was experiencing rather high iowait time (up to 20%). Digging deeper into the issue I found that php's sessions were being stored in the database. And that is a very bad idea, it's one of the surest ways (apart from missing indexes and so) to bring the database to it's knees!

Let me tell you a story: There was this sports club which had an online shop for it's merchandise which also stored it's sessions in a database. Now against all odds the club won the cup, and guess what happened and who was on on-call duty that evening? I tried to mitigate this by adding 64 (yes, 64) cores to the database server, it just gobbled them up in microseconds so I told the customer that there was nothing we could do about this, just wait until the rush was over - and then make some optimizations, including removing the sessions from the database. (This had to be done by developers). After that (and a couple of other optimizations) the shop went fine. This was the worst offender I've seen, yet by far not the only one.

Back to Hubzilla

The slave

I've changed the replication to ignore the session table:

replicate-ignore-table = hub_netzgemeinde_eu.session

Usually this is something that makes every experienced DBA (including me) cringe - partial replication is one sure way to break your slave/backups, but in this case it's OK, since there is no point in having the session table replicated or backupped - If you have to perform disaster recovery like promoting the slave to master or restoring a backup, the sessions are the least of your concerns :-D

Let's have a look at the perfomance data - io wait:

Guess the time whan I disabled session's replication? ;-) This is rather compelling, isn't it?
This fixed the iowait issue on the slave's host. Now to the master.

The master

Now it's time to fix this issue once and for all: Take the session handling out of the database

There are basically two options: Use file based session handling or external session storage. Both have advantage and disadvantages:

File based session handling: Store your sessions in files residing /tmp. Some time ago this was considered to be a bad/slow solution (after all, a database is faster, eh?) However, tmp now usually has got tmpfs as a filesystem, which means /tmp is a RAM disk, which is much, much faster than a database. (If your tmp is not having a tmpfs, try the other option). There are two caveats, though: When the machine where your PHP interpreter (either fpm or mod_php) runs on has to reboot (either due to planned maintenance or powerloss) the sessions will be gone, the users will have to log in again That's an acceptable price to pay. The second one concerns scaling issue: If you run a high-performance setup (i.e. load balancer, more than one webserver) this can't be used since all application servers have to access the shared sessions.
External session storage: You run a small key/value in-memory database on another host. The usual ones are memcache or Redis (I myself haven't got mixed experiences with Redis as as session store, but your mileage may vary). All application servers (Apache with PHP) can access the storage, so this is the way to go if you have more than one application server. If you use Redis, the session can also be saved in regular intervals on the disk, therefore you won't lose the sessions if your session storage goes down (reboot, update, whatver), however you will lose some speed advantage. I myself would recommend memcache, it's blazingly fast and stores the session ony in memory, but feel free to toy with Redis.

Setting it up in Hubzilla

Unfortunately Hubzilla doesn't support changing the session handler out of the box. I've written a small patch (which I will submit for review) to enable ist (it's attached to this article):

cd <your instance>/Zotlabs/Web
(copy Session.patch here)
patch < Session.patch

After that you can switch the session handler, by default it's still database, so the patch won't do any harm. If you want to change the handler change .htconfig.php in Hubzilla's base directory:

App::$config["system"]['session_custom'] = true;
App::$config["system"]['session_save_handler'] = "files";
App::$config["system"]['session_save_path'] = "/tmp"

(Or whatever you prefer - memcached, redis,..)

After that all your former sessions will be unavailabe, i.e. users have to login again (including nomad's users), but after that things run rather smoothly.

About the performance gain

In my case it's hard to say, because the ssd is so fast - still the graph seems to indicate that even on a fast ssd (4 cores, 16 GB Ram, 10 GB Innodb buffer pool) there is a perfomance gain. I'd love to see if someone tries this on a slow machine - how much perfomance did you gain? I'd really be interested in feedback.

Conclusion

By changing Hubzilla's session handling one can gain a significant perfomance boost - the only disadvantage is that the sessions may be a little bit volatile (i.e. not reboot safe), but that's a small price to pay.

Edit 2019-01-26

I've expanded the patch making it possible to change session.gc_probability and session.gc_divisor (defaulting to 1 and 100 for custom session handlers):

App::$config["system"]['session_gc_probability'] = 1;
App::$config["system"]['session_gc_divisor'] = 100;

(Session2.patch)

english Hubzilla

Fri, 25 Jan 2019 14:12:11 +0100

i like the idea. a little volatility in session management really is a small price to pay. how often do webservers go down, and most everyone will have their browsers 'remember' login/pwd for a frequently used site like hubzilla.

why don't you !-add this to @Hubzilla Development so that others can give their input? i don't think everyone who might have something to say follows the framagit issues...

Boosting matrix/synapse by using workers

Fri, 13 Dec 2019 09:14:11 +0100 last edited: Fri, 13 Dec 2019 09:43:38 +0100

Mark Nowiasz

buckaroo@hub.netzgemeinde.eu

By using wokers, synapse becomes much more efficient on multi-core machines, although it consumes more memory

View article

I've been running a synapse homeserver for nearly a year and it works just fine, but there's one bottleneck: Python's single-threadedness. It only utilizes one core, the other are mostly idling (or used for the database). Recently I've learned that there's a solution for that (although currently considered to be experimental): Workers. By splitting synapse into a collection of processes which perform different tasks it's possbile to utilize all the cores of the CPU - even running the workers on different machines, loadbalancing the task, whatever. There are two catches, though:

The setup becomes more complex. This is rather normal when you make a setup more scalable
Since every worker is basically a synapse instance dedicated to a different task, the setup will consume more memory

There's a (incomplete) documentation about this: https://github.com/matrix-org/synapse/blob/master/docs/workers.md . However, there a few pitfalls to avoid, therefore I'll publish my configuration.

homeserver.yaml

As stated in documentation, there need to be some changes in the main homeserver.yaml. You need to add two listeners:

# The TCP replication port
  
  - port: 9092
    bind_addresses: ['::1', '127.0.0.1']
    type: replication
  
  # The HTTP replication port

  - port: 9093
    bind_addresses: ['::1', '127.0.0.1']
    type: http
    resources:
       - names: [replication]

And add some configuration items (if you want to have all workers running, that is)

# Workers

start_pushers: False
notify_appservices: False 
send_federation: False
enable_media_repo: False
update_user_directory: False
use_presence: False

Workers

I've put the worker's yamls in a subdirectory called workers:

homeserver.yaml

worker_app: synapse.app.homeserver
daemonize: true

appservice.yaml

worker_app: synapse.app.appservice

# The replication listener on the synapse to talk to.
worker_replication_host: 127.0.0.1
worker_replication_port: 9092
worker_replication_http_port: 9093

worker_daemonize: True
worker_pid_file: /home/matrix/synapse/appservice.pid
worker_log_config: /home/matrix/synapse/workers_log_config.yml

client_reader.yaml

worker_app: synapse.app.client_reader

# The replication listener on the synapse to talk to.
worker_replication_host: 127.0.0.1
worker_replication_port: 9092
worker_replication_http_port: 9093

worker_listeners:
    - type: http
      bind_addresses: ['::1', '127.0.0.1']
      port: 8086
      resources:
          - names:
            - client

worker_daemonize: True
worker_pid_file: /home/matrix/synapse/client_reader.pid
worker_log_config: /home/matrix/synapse/workers_log_config.yml

event_creator.yaml

worker_app: synapse.app.event_creator

# The replication listener on the synapse to talk to.
worker_replication_host: 127.0.0.1
worker_replication_port: 9092
worker_replication_http_port: 9093

worker_listeners:
    - type: http
      bind_addresses: ['::1', '127.0.0.1']
      port: 8089
      resources:
          - names:
            - client

worker_daemonize: True
worker_pid_file: /home/matrix/synapse/event_creator.pid
worker_log_config: /home/matrix/synapse/workers_log_config.yml

federation_reader.yaml

worker_app: synapse.app.federation_reader

# The replication listener on the synapse to talk to.
worker_replication_host: 127.0.0.1
worker_replication_port: 9092
worker_replication_http_port: 9093

worker_listeners:
    - type: http
      bind_addresses: ['::1', '127.0.0.1']
      port: 8084
      resources:
          - names:
            - federation

worker_daemonize: True
worker_pid_file: /home/matrix/synapse/federation_reader.pid
worker_log_config: /home/matrix/synapse/workers_log_config.yml

federation_reader.yaml

worker_app: synapse.app.federation_reader

# The replication listener on the synapse to talk to.
worker_replication_host: 127.0.0.1
worker_replication_port: 9092
worker_replication_http_port: 9093

worker_listeners:
    - type: http
      bind_addresses: ['::1', '127.0.0.1']
      port: 8084
      resources:
          - names:
            - federation

worker_daemonize: True
worker_pid_file: /home/matrix/synapse/federation_reader.pid
worker_log_config: /home/matrix/synapse/workers_log_config.yml

federation_sender.yaml

worker_app: synapse.app.federation_sender

# The replication listener on the synapse to talk to.
worker_replication_host: 127.0.0.1
worker_replication_port: 9092
worker_replication_http_port: 9093

worker_daemonize: True
worker_pid_file: /home/matrix/synapse/federation_sender.pid
worker_log_config: /home/matrix/synapse/workers_log_config.yml

frontend_proxy.yaml

worker_app: synapse.app.frontend_proxy

# The replication listener on the synapse to talk to.
worker_replication_host: 127.0.0.1
worker_replication_port: 9092
worker_replication_http_port: 9093
worker_main_http_uri: http://127.0.0.1:8008

worker_listeners:
    - type: http
      bind_addresses: ['::1', '127.0.0.1']
      port: 8088
      resources:
          - names:
            - client

worker_daemonize: True
worker_pid_file: /home/matrix/synapse/frontend_proxy.pid
worker_log_config: /home/matrix/synapse/workers_log_config.yml

frontend_proxy.yaml

worker_app: synapse.app.frontend_proxy

# The replication listener on the synapse to talk to.
worker_replication_host: 127.0.0.1
worker_replication_port: 9092
worker_replication_http_port: 9093
worker_main_http_uri: http://127.0.0.1:8008

worker_listeners:
    - type: http
      bind_addresses: ['::1', '127.0.0.1']
      port: 8088
      resources:
          - names:
            - client

worker_daemonize: True
worker_pid_file: /home/matrix/synapse/frontend_proxy.pid
worker_log_config: /home/matrix/synapse/workers_log_config.yml

media_repository.yaml

worker_app: synapse.app.media_repository

# The replication listener on the synapse to talk to.
worker_replication_host: 127.0.0.1
worker_replication_port: 9092
worker_replication_http_port: 9093

worker_listeners:
    - type: http
      bind_addresses: ['::1', '127.0.0.1']
      port: 8085
      resources:
         - names: [media]


worker_daemonize: True
worker_pid_file: /home/matrix/synapse/media_repository.pid
worker_log_config: /home/matrix/synapse/workers_log_config.yml

pusher.yaml

worker_app: synapse.app.pusher

# The replication listener on the synapse to talk to.
worker_replication_host: 127.0.0.1
worker_replication_port: 9092
worker_replication_http_port: 9093

worker_daemonize: True
worker_pid_file: /home/matrix/synapse/pusher.pid
worker_log_config: /home/matrix/synapse/workers_log_config.yml

synchrotron.yaml

worker_app: synapse.app.synchrotron

# The replication listener on the synapse to talk to.
worker_replication_host: 127.0.0.1
worker_replication_port: 9092
worker_replication_http_port: 9093

worker_listeners:
    - type: http
      bind_addresses: ['::1', '127.0.0.1']
      port: 8083
      resources:
          - names:
            - client

worker_daemonize: True
worker_pid_file: /home/matrix/synapse/synchrotron.pid
worker_log_config: /home/matrix/synapse/workers_log_config.yml

user_dir

worker_app: synapse.app.user_dir

# The replication listener on the synapse to talk to.
worker_replication_host: 127.0.0.1
worker_replication_port: 9092
worker_replication_http_port: 9093

worker_listeners:
    - type: http
      bind_addresses: ['::1', '127.0.0.1']
      port: 8087
      resources:
          - names:
            - client

worker_daemonize: True
worker_pid_file: /home/matrix/synapse/user_dir.pid
worker_log_config: /home/matrix/synapse/workers_log_config.yml

I'm using a shared log config for all the workers (workers_log_config.yaml) in the main directory, basically it's just a copy of the main logging config:

version: 1

formatters:
    precise:
        format: '%(asctime)s - %(name)s - %(lineno)d - %(levelname)s - %(request)s - %(message)s'

filters:
    context:
        (): synapse.util.logcontext.LoggingContextFilter
        request: ""

handlers:
    file:
        class: logging.handlers.RotatingFileHandler
        formatter: precise
        filename: /home/matrix/synapse/workers.log
        maxBytes: 104857600
        backupCount: 10
        filters: [context]
        encoding: utf8
    console:
        class: logging.StreamHandler
        formatter: precise
        filters: [context]

loggers:
    synapse:
        level: ERROR

    synapse.storage.SQL:
        # beware: increasing this to DEBUG will make synapse log sensitive
        # information such as access tokens.
        level: INFO

root:
    level: ERROR
    handlers: [file, console]

Reverse Proxy Settings

I'm using apache2 as a reverse proxy for synapse. Here are my ProxyPass/ProxyPassMatch configurations. I've put them in a single include file, so I can include them in both vhosts (443 and 884) - Include /etc/apache2/vhosts.d/proxystatements.include - , so both synapse ports will benefit from the workers. I've merged - when possible - some of the regexps in the documentation into single ones:

proxystatements.include

####### Workers #################################

#synapse.app.synchrotron
ProxyPassMatch ^/_matrix/client/(v1_alpha|r0)/sync$ http://127.0.0.1:8083 nocanon
ProxyPassMatch ^/_matrix/client/(api/v1|v2_alpha|r0)/events$ http://127.0.0.1:8083 nocanon
ProxyPassMatch ^/_matrix/client/(api/v1|r0)/initialSync$ http://127.0.0.1:8083 nocanon
ProxyPassMatch ^/_matrix/client/(api/v1|r0)/rooms/[^/]+/initialSync$ http://127.0.0.1:8083 nocanon

#synapse.app.federation_reader
ProxyPassMatch ^/_matrix/federation/v1/(event/|state/|state_ids/|backfill/|get_missing_events/|publicRooms|query/|make_join/|make_leave/|send_join/|send_leave/|invite/|query_auth/|event_auth/|exchange_third_party_invite/|send/) http://127.0.0.1:8084 nocanon
ProxyPassMatch ^/_matrix/key/v2/query http://127.0.0.1:8084 nocanon

#synapse.app.media_repository
ProxyPass /_matrix/media/ http://127.0.0.1:8085/_matrix/media/ nocanon

#synapse.app.client_reader
ProxyPassMatch ^/_matrix/client/(api/v1|r0|unstable)/(publicRooms|rooms/(.*/joined_members|.*/context/.*|.*/members|.*/state)|login|account/3pid|keys/(query|changes)|voip/turnServer|pushrules/.*|register|.*/messages)$  http://127.0.0.1:8086 nocanon
ProxyPassMatch ^/_matrix/client/versions$  http://127.0.0.1:8086 nocanon

#synapse.app.user_dir
ProxyPassMatch ^/_matrix/client/(api/v1|r0|unstable)/user_directory/search$ http://127.0.0.1:8087 nocanon

#synapse.app.frontend_proxy
ProxyPassMatch ^/_matrix/client/(api/v1|r0|unstable)/(keys/upload|presence/[^/]+/status) http://127.0.0.1:8088 nocanon

#synapse.app.event_creator
ProxyPassMatch ^^/_matrix/client/(api/v1|r0|unstable)/rooms/.*/send http://127.0.0.1:8089 nocanon
ProxyPassMatch ^^/_matrix/client/(api/v1|r0|unstable)/rooms/.*/(join|invite|leave|ban|unban|kick)$ http://127.0.0.1:8089 nocanon
ProxyPassMatch ^^/_matrix/client/(api/v1|r0|unstable)/(join|profile)/ http://127.0.0.1:8089 nocanon

#Everything eles to the main process
ProxyPass /_matrix http://127.0.0.1:8008/_matrix nocanon
ProxyPassReverse /_matrix http://127.0.0.1:8008/_matrix

Things to consider

As the documentation states, you have to start/restart/stop the whole setup now by using synctl -a ./workers (start|stop..) instead of synctl.

Jabber vs Matrix

Tue, 05 Feb 2019 11:03:02 +0100 last edited: Tue, 05 Feb 2019 11:12:50 +0100

Mark Nowiasz

buckaroo@hub.netzgemeinde.eu

I've planned setting up a public XMPP/Jabber service (in addition to my preexisting public matrix homeserver matrix.netzgemeinde.eu), well, I changed my mind rapidly and elected to delete this mess called "ejabberd". There are two reason, the first one concerns the software, the second one XMPP/Jabber itself.

Ejabberd

I chose to install ejabberd, which claims to be fast and efficient (I do believe it), written in Erlang. The installation went smooth, however the configuration was far from easy:

Ejabberd's Configuration

The supplied configuration file contained about 800 lines of yaml (most of it comments, of course), still it's quite complex - they acknowledge it:

Do not let this complexity scare you. Most of you will be fine with default config file (or light changes)

Which immediately brings me to the documention:

Documentation

https://docs.ejabberd.im/admin/configuration/

When you have such a complex configuration you have to have good documentation otherwise the administrator will be lost. This happened to me, because the documentation didn't clarifiy which options to use for what specific version! I was running 17.04, and - just a guess - the documention was for the most current version, so lots of items were not working on my setup. The worst offender was the database: I was running it on a server containing a PostgresQL. So I took the advice and used the "new" sql schema ( https://docs.ejabberd.im/admin/configuration/#database-and-ldap-configuration). So after a lot of cursing and trying which option did apply to my ejabberd's version (again - there's no hint in the documenation) I finally got it running - but was unable to create a user, because the "new" sql schema was not supported in my version!

So I dropped the databases, recreated it with the "old" schema and finally after lots of trial and error I was finally able to make it work.

Jabber

After finally having worked out most of ejabberd's quirks I was playing with some Jabber clients when I finally found out that Jabber/XMPP lacks one of the most essential messenger's features: The ability to use more than one client at once!

(Well, yes, Whatsapp also makes this impossible, but at least they tell you this. Also Telegram's encrypted chats - they warn you about this, too)

I launched three clients - the one build in in Plasma (Telepathy), Kopete and one on Android. And it was like a roulette - some messages got routed to Android, some to Kopete, you got the idea. This makes Jabber next to useless: My usual setup is running a client on Android and one on my desktop, both seemlessly. So when I leave the desktop (with a superior keyboard) I can continue the conversation using Android and vice versa. This is impossible using Jabber, I cannot access the old messages, and apparently there is a problem when using mobile: The frequent change of your IP address seems to cause problems in Jabber.

Extensibilty (XMPP)

I've learned that there is a workaround for my problem (multiple clients), its' an extension (hence the letter X), an XEP. You can extend the basic protocol by using extensions call XEP. There is some github repository for the necessary extension (XEP-0280), but why is such core feature for a messenger implemented as an extension? And even if, why it's not included in ejabberd's basic setup?

Anyway, this extensibility is in theory a good thing - in practise it causes lots of problems. For example, I've activated captcha for registrations. Unfortunately this resulted in not being able to register at all using a client - because the client in question didn't implement the needed XEP (the web registration didn't work at all, only a 404. Why? No idea). So using Jabber involves two problems: First you have to find a server (open for registration) that implements all the XEPs you need and then you have to find the client which understand all the XEPs - not only on Desktop, also on mobile. This is far too much hassle in my option.

Matrix

I've never encountered any of these problems running synapse/Matrix. You have to configure some things, but this is well-documented, so was the migration from sqlite to PostgresQL - wenn smoothly. Furthermore, it did work out of the box - multiple clients per session, voice/video chat, channels, offline messenges, you name it.

Conclusion

Instead of opening the server for the public I just going to delete this piece of.. well, you know. The documentation isn't accurate, it's written in a language I do not know (Erlang) so I cannot support it if there are problems - and last but not least Jabber lacks the elementary features of a messenger - multiple clients per session. So I see no point in running an XMPP server, I've set up a profile on another server just in case if someone wants to contact me via Jabber. Matrix remains my primary choice.

There's also a German blog article about this: https://www.kuketz-blog.de/messenger-matrix-das-xmpp-fuer-hobby-admins/

deutsch english

Meine Top 10 Chefkochrezepte

Fri, 14 Dec 2018 12:17:10 +0100 last edited: Fri, 14 Dec 2018 12:50:30 +0100

Mark Nowiasz

buckaroo@hub.netzgemeinde.eu

Ich habe über 200 Chefkoch.de-Rezepte ausprobiert, die meisten davon waren gut und eine Vielzahl davon koche ich immer wieder mal. Ich habe hier meine Top 10 Rezepte, die ich auf chefkoch.de gefunden habe, aufgelistet, wobei ich bewusst auf Nummerierungen verzichtet habe - die Rezepte lassen sich nicht vergleichen: Was ist besser? Ein Nachtisch, ein Braten, eine Beilage? Hier sind sie, alphabetisch geordnet:

Chocolate-Lava-Muffins: Unglaublich gut, teilweise flüssig, und dazu auch sehr einfach herzustellen.
Der beste Pizzateig: Der Titel klingt anmaßend, aber stimmt tatsächlich: Pizza mit dem Teig (zu der Sauce kann ich nichts sagen, ich mache eine andere) aus dem Ofen kommt einer Pizza beim Italiener schon sehr, sehr nahe. Hätte man einen Ofen der so heiß würde wie in der Pizzeria, wäre es genau so gut.
Djuvec-Reis: Schöne, vegetarische Beilage, schmeckt mir deutlich besser als die oft eher wässrige und laffe Version in Balkanrestaurants. Ich packe noch Erbsen da rein.
Hüftsteak in einer feinen Cognac-Sahne-Soße: Einer der besten Hüftsteaks nebst Sauce, die ich kenne - man braucht schon ein gutes Steakhaus um das zu schlagen, oftmals gibt es das in schlechterer Qualität.
Indisches Butter Chicken aus dem Ofen: Für diejenigen, die gerne indisch essen (ich z.B.). Das schmeckt zu meinen Erstaunen tatsächlich wie beim Inder, und ist recht einfach zu kochen.
Mascarpone-Himbeerquark: Ein sehr, sehr guter Nachtisch bei gleichzeitig geringem Arbeitsaufwand (etwa 10 Minuten). Muss eine Nacht im Kühlschrank, aber das Resultat schlägt alles, vermutlich auch kalorientechnisch, das ist es aber wert :-)
Omas beste Frikadellen: Maggi hin oder her, Margarine im Rezept (ich nutze natürlich Butterschmalz zum Braten) - das sind bislang die besten Frikadellen, die ich kenne. Oft genug gemacht für unterwegs, hat bislang jedem (sofern er Frikadellen mag) geschmeckt :-)
Pfeffersauce: Ich mag Pfeffersauce (siehe Hüftsteakrezept), und die besonders :-) Wer die einmal gemacht hat wird nie wieder Fertigsaucen verwenden
Überbackene Spitzpaprika mit Käsefüllung: Einer meiner Lieblingsgerichte im Vegetarischen: Schmeckt auch ausgewiesenen Fleischessern sehr gut, und eignet sich daher auch gut für „gemischte“ (vegetarisch/omnivor) Gesellschaften, wenn man kein Lust hat mehrere Gerichte zu kochen.
Wildschweinbraten: Das bislang beste Wildrezept, was ich bisher gegessen habe, egal ob privat oder im Restaurant. Nicht ganz billig durch das Wildfleisch, ist es aber wert. Und auch nicht sonderlich viel Arbeitsaufwand.

Wenn man die Bewertungen der Rezepte ansieht, sehen das andere wohl auch so :-) Einfach mal ausprobieren, sollte für jeden was dabei sein.

food

Elevation (Stephen King)

Thu, 08 Nov 2018 08:11:38 +0100

Mark Nowiasz

buckaroo@hub.netzgemeinde.eu

"Elevation" is the latest novella by Stephen King, taking place in King's favorite fictional town, Castle Rock

View article

Review

The Divine Cities (Robert Jackson Bennett)

Sat, 27 Oct 2018 14:43:06 +0200 last edited: Sat, 27 Oct 2018 15:49:48 +0200

Mark Nowiasz

buckaroo@hub.netzgemeinde.eu

The Divine Cities is a fascinating and unique trilogy of mystery/thrillers set in a urban fantasy world, Definitely worth reading!

View article

"The Divine Cities" is a trilogy (City of Stairs, City of Blades, City of Miracles) by Robert Jackson Bennett. It's a unique mix of mystery/thriller (with a dose of steampunk) in an urban fantasy setting. I'ts difficult to descibe the content, because in my opinion exporing the world is one part of the attraction - the reader learns in time more and more about the world, the history, the matter of the Divinities, and so on. Therefore it's not easy to write a review without any - minor - spoilers. I try to keep the spoilers as minor as possible :-)

(Minor spoilers below)

Click to open/close

The books are very, very good to read. The world Bennett describes is very colorful and rich (as one reviewer pointed out: Bennett is in love with the world he created), the characters are believable and complex (and sometimes a little eccentric, too), the mystery elements make it hard to stop reading :-)

On a side note: There seems to be perfect equality between the sexes - this isn't even discussed! Women are naturally part of every facet of the world (poltics, fighting forces) and that's that. No one raises even an eyebrow at a female general. This feels so normally that you ask yourself: Why the hell can't that kind of liberty be part of our world?

Definitely worth reading, thanks to Florian Freistetter of recommending this!

Image/photo

Review

Mon, 29 Oct 2018 11:30:19 +0100

Hanno (Cloudwatcher) Gardemann (Hz)

calvato@hub.netzgemeinde.eu

Danke für die Empfehlung! Muss mir leider die deutschsprachige Übersetzung kaufen weil mein Englisch für Belletristik zu mager ist. Technische Texte gehen, Literarur ist zu anstrengend.
Aber vielleicht hab ich ja Glück mit der Übersetzung.

Mon, 29 Oct 2018 15:25:26 +0100

Mark Nowiasz

buckaroo@hub.netzgemeinde.eu

Ich lese Bücher schon seit langem ausschließlich im englischen Original - analoges gilt für Serien und Filme, deshalb kann ich keine Aussagen über die Übersetzungen machen :-) Dank Amazon, DVD/BluRays und PayTV sowie Cinestar Original in Berlin ist das mittlerweile auch keine Akt mehr. Das hat allerdings oft seltsame Konsequenzen: Wenn die Leute über die übersetzte Serie reden, frage ich mich wovon die Leute eigentlich reden - „Königsmund”? Häh? Ah, „King's Landing“ - welcher Schwachkopf hat denn das übersetztß :-D

Preface

Back to Hubzilla

The slave

The master

Setting it up in Hubzilla

About the performance gain

Conclusion

Edit 2019-01-26

homeserver.yaml

Workers

homeserver.yaml

appservice.yaml

client_reader.yaml

event_creator.yaml

federation_reader.yaml

federation_reader.yaml

federation_sender.yaml

frontend_proxy.yaml

frontend_proxy.yaml

media_repository.yaml

pusher.yaml

synchrotron.yaml

user_dir

Reverse Proxy Settings

proxystatements.include

Things to consider

Ejabberd

Ejabberd's Configuration

Documentation

Jabber

Extensibilty (XMPP)

Matrix

Conclusion

Summary

Review