Activating Warp Speed for Hubzilla's Database

Fri, 25 Jan 2019 12:05:10 +0100 zuletzt bearbeitet: 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.

Artikel ansehen

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 zuletzt bearbeitet: 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

Artikel ansehen

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 zuletzt bearbeitet: Tue, 05 Feb 2019 11:12:50 +0100

Mark Nowiasz

buckaroo@hub.netzgemeinde.eu

Ursprünglich wollte ich - zustätzlich zu dem öffentlichen Matrixserver matrix.netzgemeinde.eu - einen öffentlichen Jabberserver anbieten, jedoch habe ich sehr schnell meine Meinung geändert und werde den entsprechenden Jabberserver ASAP löschen. Das hat zwei Gründen: Der Server selbst (ejabberd) und das Protokoll selbst.

Ejabberd

Ich hatte mich für ejbabberd entschieden, ein Jabberserver geschrieben in Erlang, welcher schnell und effizient sein soll (das glaube ich sogar, wenn ich andere Erlang-Projekte ansehe). Die Installation als solche war unproblematisch, aber die Konfiguration, mein Gott die Konfiguration!

Die Konfiguration

Die mitgelieferte Konfiguration umfasst etwa 800 Zeilen YAML (viele Zeilen davon sind Kommentare). Die Doku erkennt das Problem und versucht den Administrator zu beruhigen:

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

Soweit so gut, nun zur Dokumentation:

Die Dokumentation

Die Dokumentation befindet sich unter https://docs.ejabberd.im/admin/configuration.
Wenn man eine so komplexe Konfiguration hat, ist eine gute Dokumentation das A und O, ansonsten ist man relativ aufgeschmissen und rennt ständig in Probleme. Genau das ist mir passiert, denn das Grundübel der Dokumentation: Es ist vollkommen unklar auf welche Version des ejabberd sie sich bezieht! Ich hatte 17.04 am laufen, divere Konfigurationsoptionen, die in der Doku beschrieben sind, funktionieren nicht - anscheinend bezieht sich die Dokumentation auf die allerneuste Version von ejabberd, ohne das irgendwo zu erwähnen! Besonders unangenehm war das bei der Datenbank: Ich befolgte den Rat das „neue“ SQL-Schema zu benutzen ( https://docs.ejabberd.im/admin/configuration/#database-and-ldap-configuration). Nach viel Fluchen und Herumprobieren (welche der Konfigurationsoptionen denn nun gehen und für meine Version zuöässig sind) gelang es mir endlich den Dienst zu starten - ich konnte bloß keine User anlegen. Es stellte sich heraus, dass das „neue“ SQL-Schema nicht von meiner Version unterstützt wurde!

Also die Datenbank gelöscht, neu aufgesetzt, „altes“ Schema eingespielt und endlich - nach viel Herumprobieren - funktionierte das Teil endlich!

Jabber

Nachdem ich endlich die meisten Probleme gelöst hatte habe ich mit einigen Jabber clients herumspielt und zu meinem extremen Erstaunen stellte sich heraus, das Jabber/XMPP eines der grundsätzlichensten Features eines Messengers nicht unterstützt: Die Fähigkeit mit mehr als einem Client an einer Sitzung teilzunehmen. Dieses Feature ist so grundlegend, dass es erst gar nicht glauben konnte. (Zugegeben, Whatsapp kann das auch nicht, aber wenigstens sagt Whatsapp das. Ditto Telegrams verschlüsselte Nachrichten. Auch hier eine Warnung).

Ich hatte drei Clients laufen - einen der in KDE/Plasma eingebaut ist (Telepathy), Kopete und einen unter Android. Und das war ein reines Glückspiel: Manche Nachrichten kamen in Android an, manche in Kopete, etc. Das macht Jabber für mich fast unbenutzbar: Normalerweise läuft bei mir ein Client unter Android und einen auf dem Desktop. Wenn ich den Desktop verlasse kann ich Unterhaltungen unter Android weiterführen und umgekehrt. Das ist unmöglich uunter Jabber - ich kann nicht auf alte Nachrichten zugreifen, und das scheint auch noch unter mobil ein Problem zu sein: Da sich dort regelmäßig die IP ändert gibt es wohl Probleme mit Jabber.

Erweiterbarkeit (XMPP]

Ich habe herausgefunden dass es für das Problem „mehrere Clients“ ein Workaround gibt - eine Erweiterung des Protokolls (XEP). Es gibt ein Github repository für die notwendige Erweiterung (XEP-0280), aber warum ist ein solches Kernfeature als Erweiterung des Protokolls implementiert? Und selbst wenn, warum ist es nicht Teil von ejabberds Standardsetup?

Die Erweiterbarkeit des Protokolls ist theoretisch eine gute Sache - praktisch jedoch erzeugt das massive Probleme. Als Beispiel: Ich hatte captcha für die Registrierungen aktiviert. Das führte leider dazu dass Registrierungen nicht möglich waren - der Client hatte das entsprechende XEP nicht implementiert (Die Webregistrierung funktionierte sowieso nicht. Gab nur einen 404. Warum? Keine Ahnung). Das führt dazu dass es ein zweiseitiges Problem bei der Nutzung von Jabber gibt: Zuerst muss man einen (öffentlichen) Server finden, der die benötigten XEPs implementiert, und dann noch einen Client der diese auch alle versteht - nicht nur auf dem Desktop, sondern auch unter Mobile. Das ist viel zu viel Aufwand/Ärger die man sich damit einfängt.

Matrix

Die Probleme unter Jabber hatte ich nie bei Matrix/synapse gehabt. Zugegeben, man muss einige Dinge konfigurieren, die Dokumentation ist aber gut und richtig, die Migration von sqlite zu PostgreSQL war gut beschrieben und lief problemlos. Es lief einfach so - mehrere Clients pro Sitzung, Voice/Videochat, Kanäle, Offline Nachrichten, egal was.

Ergo

Statt den Jabberserver für die Öffentlichkeit werde ich diesen Haufen .. (man kann sich denken) löschen. Die Doku ist nicht korrekt, der Server ist einer Programmiersprache geschrieben die ich nicht beherrsche, was dazu führt dass ich bei Problemen nichts machen kann und zu guter Letzt fehlen Jabber elementare Eigenschaften eines Messengers - z.B. mehrere Clients pro Sitzung, deshalb sehe ich keinen Sinn darinen ein XMPP-Server zu betreiben. Ich habe auf einem anderen Server ein Profil angelegt falls jemand mich per Jabber kontaktieren möchte, jedoch bleibt Matrix die bevorzugte Kommunikationsform.

Es gibt einen deutschsprachigen Blogartikel zu dem selben Thema: 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 zuletzt bearbeitet: 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“ (gibt es zum Zeitpunkt dieser Rezension noch nicht auf deutsch) ist die neuste Novelle von Stephen King die in Castle Rock spielt

Artikel ansehen

Review

The Divine Cities (Robert Jackson Bennett)

Sat, 27 Oct 2018 14:43:06 +0200 zuletzt bearbeitet: Sat, 27 Oct 2018 15:49:48 +0200

Mark Nowiasz

buckaroo@hub.netzgemeinde.eu

„The Divine Cities“ spielt in einer Urban-Fantasy-Welt, in der Götter real sind. Die Bücher sind eine sehr interessante und erfrischende Mischung aus Fantasy/Steampunk/Mystery/Spionagethriller, sehr gut zu lesen und spannend.

Artikel ansehen

„The Divine Cities“ (City of Stairs, City of Blades, City of Miracles) ist eine Trilogie von Robert Jackson Bennett, das Genre ist relativ schwierig zu beschreiben: Mystery/Spionagethriller in einem Urban Fantasy-Setting gewürzt mit Steampunk. Ebenso schwierig ist zu schreiben worum es geht, weil meiner Meinung ein Teil des Reizes die Erkundung dieser Welt ist - nach und nach erfährt der Leser über die Geschichte der Welt, was warum passiert ist, usw. Demzufolge besteht die Gefahr zu spoilern, ich werde versuchen die Spoiler möglichst gering zu halten.
(Kleiner Spoiler)

Klicke zum Öffnen/Schließen

Die Bücher sind sehr, sehr gut zu lesen. Die Welt wird von Bennett sehr liebvoll farbig beschrieben, die Charaktere sind glaubwürdig und keinesfalls eindimensional (wenn auch teilweise eigenwillig) und die Mystery-Elemente machen es schwer mit dem Lesen aufzuhören :-)

Ein interessantes Detail: In der Welt scheint es natürliche Gleichberechtigung zwischen Mann und Frau zu geben - dies wird nie thematisiert, Frauen sind dort ganz selbstverständlich in jeglichen Bereichen (Politik, Militär,.) aktiv und nirgendwo unterrepräsentiert. Das wirkt so natürlich und normal dass man sich direkt fragt, warum das nicht auch in unserer Welt so ist?

Definitiv lesenswert, noch mal danke an Florian Freistetter für die Empfehlung!

Bild/Foto

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

Die Konfiguration

Die Dokumentation

Jabber

Erweiterbarkeit (XMPP]

Matrix

Ergo

Inhalt

Meinung