docent-net/conferences 9

Repository where I keep my conferences / events related resources

docent-net/dotfiles 4

bash, zsh, git, tmux, personal toolbox

docent-net/CheatSheetsKeyBindings 1

Keybindings, cheat-sheets

docent-net/DNSHarvester 1

This tool will harvest valid DNS subdomains from a given domain.

docent-net/DockerWorkshops 1

This project contains materials for Docker Workshops we will host on 26th July 2014

docent-net/ansible-examples 0

Starter examples of ansible playbooks & environments

docent-net/ansible-gitlab 0

Ansible role for Gitlab insallation on Centos 7

docent-net/ansible-jenkins 0

Ansible playbook: Jenkins

docent-net/ansible-piwik 0

Ansible role: Piwik

push eventdocent-net/charts

Maciej Lasyk

commit sha e94c3ed28871607662cbb190904950efa3579719

feat(longhorn-UI): Add loadBalancer service type Signed-off-by: Maciej Lasyk <>

view details

push time in 8 days

PR opened longhorn/charts

feat(longhorn-UI): Allow specyfing loadBalancer IP/SourceRanges

This change allows users to specify loadBalancerIP/SourceRanges while using loadBalancer service type in Longhorn-UI service.

+10 -0

0 comment

1 changed file

pr created time in 8 days

create barnchdocent-net/charts

branch : lb-service-ui

created branch time in 8 days

fork docent-net/charts

Helm Charts

fork in 8 days


started time in 12 days

issue commentopenzfs/zfs

Latest version support for all Linux distros (via shell script)

"curl -sSLf | sudo sh" is a terrible way of installing anything. This is an antipattern we should all avoid. It teaches people to install directly from the internet. It's just wrong.

There is a reason for using distro packages, releases and some other popular models of delivering software. It is a security and compliance.

Also - I just don't imagine maintenance burden of such scripts. Idempotency would be a hassle, plus this would be one huge stack of imperative blocks.


comment created time in 2 months

issue openedwolfSSL/wolfssh

Question about CPU footprint

Hi, posting this question as an issue here, as it might be a good reference for others.

We're using classic openssh server in our infrastructure. However, we're having issues with high CPU demands when even low number of concurrent users are connected (5-10). That's because sshd is single - threaded and encryption takes a lot of CPU.

The only way for scaling this is (we think) scaling vertically by adding more CPUs and using CPU pinning. But this is really cumbersome as we're in k8s in some public cloud.

So, we're looking for another sshd implementation that might be better performing or maybe could be configured in a more performant way. And here we are analyzing wolfssh.

We found this article about memory footprint of wolfssl - and that looks very promising! However not word about CPU utilization there. According to this, TLS 1.3 will be probably more performant and less CPU intensive.

Could you please elaborate a little about how WolfSSH/WolfSSL compares to openssh in terms of cpu utilization? And how does scalability look like? As far as I understand from documentation, WolfSSL is multi-threaded (, with optional SINGLE_THREADED switch. However, not sure if this multithreading helps a lot from a performance perspective, as there is only one mutex (used for the session cache)?

Thank you

created time in 2 months

create barnchdocent-net/

branch : main

created branch time in 2 months

created repositorydocent-net/

GH project for my microscale modelling blog

created time in 2 months