<?xml version="1.0" encoding="UTF-8"?>
 <rdf:RDF xmlns="http://purl.org/rss/1.0/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:cc="http://web.resource.org/cc/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://pinboard.in">
    <title>Pinboard (jm)</title>
    <link>https://pinboard.in/u:jm/public/</link>
    <description>recent bookmarks from jm</description>
    <items>
      <rdf:Seq>	<rdf:li rdf:resource="https://github.com/isene/glass"/>
	<rdf:li rdf:resource="https://www.hmpcabral.com/2026/04/26/the-fastest-linux-timestamps/"/>
	<rdf:li rdf:resource="https://chrisdown.name/2026/03/24/zswap-vs-zram-when-to-use-what.html"/>
	<rdf:li rdf:resource="https://patrickmccanna.net/a-better-way-to-limit-claude-code-and-other-coding-agents-access-to-secrets/"/>
	<rdf:li rdf:resource="https://wiki.archlinux.org/title/Solid_state_drive#External_SSD_with_TRIM_support"/>
	<rdf:li rdf:resource="https://dfir.ch/posts/linux_capabilities/"/>
	<rdf:li rdf:resource="https://tanelpoder.com/posts/xcapture-v3-alpha-ebpf-performance-analysis-with-duckdb/"/>
	<rdf:li rdf:resource="https://github.com/Orange-OpenSource/hurl"/>
	<rdf:li rdf:resource="https://www.elastic.co/observability-labs/blog/debugging-aks-packet-loss"/>
	<rdf:li rdf:resource="https://www.asayers.com/jetrelay/"/>
	<rdf:li rdf:resource="https://mcyoung.xyz/2023/03/29/rseq-checkout/"/>
	<rdf:li rdf:resource="https://github.com/just-containers/s6-overlay#quickstart"/>
	<rdf:li rdf:resource="https://boyter.org/posts/my-list-of-useful-command-line-tools/"/>
	<rdf:li rdf:resource="https://linux.doompdf.dev/"/>
	<rdf:li rdf:resource="https://isd-project.github.io/isd/"/>
	<rdf:li rdf:resource="https://tracker.debian.org/news/1584883/accepted-util-linux-2402-11-source-into-unstable/"/>
	<rdf:li rdf:resource="https://transactional.blog/how-to-learn/disk-io"/>
	<rdf:li rdf:resource="https://nnethercote.github.io/2022/07/27/twenty-years-of-valgrind.html"/>
	<rdf:li rdf:resource="https://www.olivetin.app/"/>
	<rdf:li rdf:resource="https://arstechnica.com/security/2024/05/ssh-backdoor-has-infected-400000-linux-servers-over-15-years-and-keeps-on-spreading/?utm_brand=arstechnica&amp;utm_social-type=owned"/>
	<rdf:li rdf:resource="https://www.pgrs.net/2024/03/21/duckdb-as-the-new-jq/"/>
	<rdf:li rdf:resource="https://max.levch.in/post/724289457144070144/shamir-secret-sharing-its-3am-paul-the-head-of"/>
	<rdf:li rdf:resource="https://aws.amazon.com/s3/features/mountpoint/"/>
	<rdf:li rdf:resource="https://chrisdown.name/2018/01/02/in-defence-of-swap.html"/>
	<rdf:li rdf:resource="https://news.ycombinator.com/item?id=34612277&amp;s=03"/>
	<rdf:li rdf:resource="https://github.com/robweber/omni-epd/blob/main/README.md"/>
	<rdf:li rdf:resource="https://ghettobastler.com/2022/12/04/vtech_storio_3s/"/>
	<rdf:li rdf:resource="https://mihai-albert.com/2022/02/13/out-of-memory-oom-in-kubernetes-part-2-the-oom-killer-and-application-runtime-implications/"/>
	<rdf:li rdf:resource="https://raspberrypi.stackexchange.com/questions/169/how-can-i-extend-the-life-of-my-sd-card"/>
	<rdf:li rdf:resource="https://www.linuxserver.io/blog/taking-the-zimaboard-for-a-spin"/>
	<rdf:li rdf:resource="https://mazzo.li/posts/fast-pipes.html"/>
	<rdf:li rdf:resource="https://blog.cloudflare.com/missing-manuals-io_uring-worker-pool/"/>
	<rdf:li rdf:resource="https://ubuntu.com/blog/safely-backup-google-photos"/>
	<rdf:li rdf:resource="https://danluu.com/cgroup-throttling/"/>
	<rdf:li rdf:resource="https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1624320"/>
	<rdf:li rdf:resource="https://github.com/Orange-OpenSource/bmc-cache"/>
	<rdf:li rdf:resource="https://www.ifixit.com/News/51614/framework-laptop-teardown-10-10-but-is-it-perfect"/>
	<rdf:li rdf:resource="https://github.com/Granulate/gprofiler"/>
	<rdf:li rdf:resource="https://www.reddit.com/r/aws/comments/o7oxnl/strange_performance_decline_aws_clocksource_change/"/>
	<rdf:li rdf:resource="https://www.hannahtech.co/post/turn-your-old-cracked-android-phone-into-a-backup-server-urbackup-linux-deploy-tutorial-part-i"/>
	<rdf:li rdf:resource="https://talawah.io/blog/extreme-http-performance-tuning-one-point-two-million/"/>
	<rdf:li rdf:resource="http://0pointer.net/blog/file-descriptor-limits.html"/>
	<rdf:li rdf:resource="https://mjg59.dreamwidth.org/56345.html"/>
	<rdf:li rdf:resource="https://www.scylladb.com/2020/05/05/how-io_uring-and-ebpf-will-revolutionize-programming-in-linux/"/>
	<rdf:li rdf:resource="https://github.com/Feh/nocache"/>
	<rdf:li rdf:resource="https://www.jeffgeerling.com/blog/2020/raspberry-pi-usb-boot-uasp-trim-and-performance"/>
	<rdf:li rdf:resource="https://ulsoy.org/blog/experiencing-wsl-as-a-linux-veteran-part-1/"/>
	<rdf:li rdf:resource="https://www.flamingspork.com/projects/libeatmydata/"/>
	<rdf:li rdf:resource="https://www.gnome.org/news/2019/09/gnome-foundation-facing-lawsuit-from-rothschild-patent-imaging/"/>
	<rdf:li rdf:resource="https://www.scylladb.com/2019/09/25/isolating-workloads-with-systemd-slices/"/>
	<rdf:li rdf:resource="https://www.bunniestudios.com/blog/?p=5590"/>
	<rdf:li rdf:resource="https://www.itsco.de/"/>
	<rdf:li rdf:resource="https://console.cloud.google.com/cloudshell/editor?pli=1&amp;supportedpurview=project&amp;shellonly=true"/>
	<rdf:li rdf:resource="https://www.joyfulbikeshedding.com/blog/2019-03-14-what-causes-ruby-memory-bloat.html"/>
	<rdf:li rdf:resource="http://batey.info/docker-jvm-k8s.html"/>
	<rdf:li rdf:resource="http://canonical.org/~kragen/sw/dev3/wifiscan.py"/>
	<rdf:li rdf:resource="https://haydenjames.io/nginx-tuning-tips-tls-ssl-https-ttfb-latency/"/>
	<rdf:li rdf:resource="https://blog.newrelic.com/2013/04/29/debugging-stuck-ruby-processes-what-to-do-before-you-kill-9/"/>
	<rdf:li rdf:resource="https://usesthis.com/interviews/leonard.lin/"/>
	<rdf:li rdf:resource="https://hackernoon.com/another-reason-why-your-docker-containers-may-be-slow-d37207dec27f"/>
	<rdf:li rdf:resource="https://www.stackrox.com/post/2017/08/hardening-docker-containers-and-hosts-against-vulnerabilities-a-security-toolkit/"/>
	<rdf:li rdf:resource="https://www.nearform.com/blog/securing-docker-containers-on-aws/"/>
	<rdf:li rdf:resource="http://www.brendangregg.com/blog/2018-01-17/measure-working-set-size.html"/>
	<rdf:li rdf:resource="https://news.ycombinator.com/item?id=16046636"/>
	<rdf:li rdf:resource="https://help.backblaze.com/hc/en-us/articles/115001518354-How-to-configure-Backblaze-B2-with-Duplicity-on-Linux"/>
	<rdf:li rdf:resource="http://habilis.net/cronic/"/>
	<rdf:li rdf:resource="http://poormansprofiler.org/"/>
	<rdf:li rdf:resource="https://compiletoi.net/share-scripts-that-have-dependencies-with-nix/"/>
	<rdf:li rdf:resource="http://www.brendangregg.com/blog/2017-08-08/linux-load-averages.html"/>
	<rdf:li rdf:resource="https://github.com/awslabs/aws-ec2rescue-linux"/>
      </rdf:Seq>
    </items>
  </channel><item rdf:about="https://github.com/isene/glass">
    <title>isene/glass</title>
    <dc:date>2026-05-05T11:37:30+00:00</dc:date>
    <link>https://github.com/isene/glass</link>
    <dc:creator>jm</dc:creator><description><![CDATA[I love the purism of this -- "pure assembly terminal emulator. x86_64 Linux, no libc, X11 wire protocol".

<blockquote>Terminal emulator written in x86_64 Linux assembly. No libc, no runtime, pure syscalls. Speaks X11 wire protocol directly via Unix socket. Single static binary, ~155KB.  No toolkit, no rendering library, no external font engine. The TTF rasterizer (glyph) is embedded in-binary via %include. Just your keystrokes, the X11 server, and the kernel. Part of the CHasm (CHange to ASM) suite: bare (shell), show (file viewer), glass (terminal emulator).</blockquote>

]]></description>
<dc:subject>asm x86_64 assembly terminal hacks unix linux glass chasm optimization x11</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:3a109b6e8b07/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:asm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:x86_64"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:assembly"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:terminal"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hacks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:unix"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:glass"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:chasm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:x11"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.hmpcabral.com/2026/04/26/the-fastest-linux-timestamps/">
    <title>The fastest Linux timestamps</title>
    <dc:date>2026-04-27T11:42:47+00:00</dc:date>
    <link>https://www.hmpcabral.com/2026/04/26/the-fastest-linux-timestamps/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[lol -- "TL;DR: We can speed up timestamps on x86 Linux by 30% and maintain the same precision as the standard system clock by implementing our own timers without relying on vDSO. Almost nobody should do this"

This is good info, I had to implement fast timestamps a few years back in Java and this would have been useful.]]></description>
<dc:subject>time optimization performance linux libc speed clocks</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:cd189cceb922/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:time"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:libc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:speed"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:clocks"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://chrisdown.name/2026/03/24/zswap-vs-zram-when-to-use-what.html">
    <title>Debunking zswap and zram myths</title>
    <dc:date>2026-03-25T10:00:18+00:00</dc:date>
    <link>https://chrisdown.name/2026/03/24/zswap-vs-zram-when-to-use-what.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[This is pretty compelling.  I like this example:

<blockquote>We have some concrete numbers to show this in practice. On Instagram, which runs on Django and is largely memory bound, we ran a test where we moved from their existing setup (with swap entirely disabled) to a setup with disk swap and zswap tiering. Django workers accumulate significant cold heap state over their lifetime, like forked processes with duplicated memory, growing request caches, Python object overhead, you get the idea. The results were twofold:

- We achieved roughly 5:1 compression. That's a huge benefit for such a memory bound workload, and also enables us to consider further stacking workloads.
- Enabling zswap reduced disk writes by up to 25% compared to having no swap at all(!).

As you can imagine, as a result of this test, Instagram has been using zswap for many years now.</blockquote>

]]></description>
<dc:subject>kernel compression memory linux ops performance swap zswap zram</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:fc55a5e5ba65/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kernel"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:compression"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:swap"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:zswap"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:zram"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://patrickmccanna.net/a-better-way-to-limit-claude-code-and-other-coding-agents-access-to-secrets/">
    <title>A better way to limit Claude Code (and other coding agents!) access to Secrets</title>
    <dc:date>2026-01-15T09:55:40+00:00</dc:date>
    <link>https://patrickmccanna.net/a-better-way-to-limit-claude-code-and-other-coding-agents-access-to-secrets/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Bubblewrap, a Linux CLI tool which uses namespaces to sandbox a specific command (and its subprocesses):

<blockquote>
Bubblewrap lets you run untrusted or semi-trusted code without risking your host system. We’re not trying to build a reproducible deployment artifact. We’re creating a jail where coding agents can work on your project while being unable to touch  ~/.aws, your browser profiles, your ~/Photos library or anything else sensitive.
</blockquote>

Very nice, I hadn't heard of this tool before.  The rest of the blog post details how to use it to isolate Claude Code specifically.]]></description>
<dc:subject>claude llms sandboxing linux cli namespaces security infosec trust unix</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:40eee427987f/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:claude"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:llms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sandboxing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cli"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:namespaces"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:security"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:infosec"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:trust"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:unix"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://wiki.archlinux.org/title/Solid_state_drive#External_SSD_with_TRIM_support">
    <title>Solid state drive - ArchWiki</title>
    <dc:date>2026-01-05T11:02:18+00:00</dc:date>
    <link>https://wiki.archlinux.org/title/Solid_state_drive#External_SSD_with_TRIM_support</link>
    <dc:creator>jm</dc:creator><description><![CDATA[the Arch Linux wiki page about SSD tuning and enabling TRIM -- extremely detailed and useful!]]></description>
<dc:subject>trim ssd hardware arch-linux linux</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:1e116fb63487/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:trim"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ssd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hardware"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:arch-linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://dfir.ch/posts/linux_capabilities/">
    <title>Linux Capabilities instead of setuid</title>
    <dc:date>2025-10-19T15:15:17+00:00</dc:date>
    <link>https://dfir.ch/posts/linux_capabilities/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[This seems like a pretty poor idea for Linux to have implemented:

<blockquote>The command setcap sets file capabilities on an executable. The cap_setuid capability allows a process to make arbitrary manipulations of user IDs (UIDs), including setting the UID to a value that would otherwise be restricted (i.e. UID 0, the root user). setcap takes a set of parameters, where

- e: Effective means the capability is activated;
- p: Permitted means the capability can be used/is allowed.

Putting this together, we’re adding the cap_setuid capabilities to the Python binary:

# setcap cap_setuid+ep /usr/bin/python3.12
</blockquote>

And hey presto, "/usr/bin/python3 -c 'import os;os.setuid(0);os.system("/bin/bash")'" now works.  Ouch]]></description>
<dc:subject>linux permissions setuid capabilities setcap infosec security root</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:0992880ad4dd/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:permissions"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:setuid"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:capabilities"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:setcap"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:infosec"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:security"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:root"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://tanelpoder.com/posts/xcapture-v3-alpha-ebpf-performance-analysis-with-duckdb/">
    <title>xcapture and xtop</title>
    <dc:date>2025-09-16T13:59:07+00:00</dc:date>
    <link>https://tanelpoder.com/posts/xcapture-v3-alpha-ebpf-performance-analysis-with-duckdb/</link>
    <dc:creator>jm</dc:creator><description><![CDATA["0x.Tools: X-Ray vision for Linux systems".  Linux Performance Analysis with Modern eBPF and DuckDB; dig into the captured DuckDB files using "xtop":

"xtop is like the Linux top tool, but extended with x-ray vision and ability to view your performance data from any chosen angle [..]. This enables dimensional performance analysis on Linux and tools like top for wall-clock time and much more. You can use it for system level overview and drill down into indivual threads’ activity and even into kernel events like lock waits or memory stalls."]]></description>
<dc:subject>os debugging sysadmin ops monitoring xtop xcapture ebpf linux duckdb syscalls</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:b730ad37aa33/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:os"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:debugging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sysadmin"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:xtop"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:xcapture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ebpf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:duckdb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:syscalls"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/Orange-OpenSource/hurl">
    <title>Orange-OpenSource/hurl</title>
    <dc:date>2025-06-20T09:42:49+00:00</dc:date>
    <link>https://github.com/Orange-OpenSource/hurl</link>
    <dc:creator>jm</dc:creator><description><![CDATA["Hurl; run and test HTTP requests with plain text".  This is pretty nice; a really simple plain-text file format to describe making a HTTP request or set of requests, and performing assertions on their results.  The only thing I can spot missing is builtin support for OAuth]]></description>
<dc:subject>cli rust tools unix testing linux json curl http tests</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:d9655d2dcc54/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cli"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rust"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tools"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:unix"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:json"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:curl"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tests"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.elastic.co/observability-labs/blog/debugging-aks-packet-loss">
    <title>Debugging Azure Networking for Elastic Cloud Serverless</title>
    <dc:date>2025-06-10T08:46:06+00:00</dc:date>
    <link>https://www.elastic.co/observability-labs/blog/debugging-aks-packet-loss</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Good writeup of fixing a Linux packet loss issue in Azure, using low-level access to the VMs running k8s nodes.

<blockquote>
Elastic's Site Reliability Engineering team (SRE) observed unstable throughput and packet loss in Elastic Cloud Serverless running on Azure Kubernetes Service (AKS). After investigation, we identified the primary contributing factors to be RX ring buffer overflows and kernel input queue saturation on SR-IOV interfaces. To address this, we increased RX buffer sizes and adjusted the netdev backlog, which significantly improved network stability.
</blockquote>]]></description>
<dc:subject>sr-iov linux networking bugs azure debugging ops sre drivers</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:aac45eb89c4b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sr-iov"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bugs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:azure"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:debugging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sre"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:drivers"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.asayers.com/jetrelay/">
    <title>Jetrelay</title>
    <dc:date>2025-05-20T09:18:20+00:00</dc:date>
    <link>https://www.asayers.com/jetrelay/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[This is a great little hack: "jetrelay, a pub/sub server compatible with Bluesky’s “jetstream” data feed. Using a few pertinent Linux kernel features, it avoids doing almost any work itself. As a result, it’s highly efficient: it can saturate a 10 Gbps network connection with just 8 CPU cores."

Specifically, these are the tricks in question:

- Trick #1: Bypassing userspace with sendfile();
- Trick #2: Handling many clients in parallel with io_uring;
- Trick #3: Discarding old data with FALLOC_FL_PUNCH_HOLE -- this is a nice way to avoid having to rotate between multiple files, nifty.

]]></description>
<dc:subject>sendfile io_uring linux kernel hacks tools jetrelay jetstream firehose bluesky pub-sub</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:b17e2ee136e7/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sendfile"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:io_uring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kernel"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hacks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tools"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jetrelay"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jetstream"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:firehose"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bluesky"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pub-sub"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://mcyoung.xyz/2023/03/29/rseq-checkout/">
    <title>Atomicless Concurrency</title>
    <dc:date>2025-05-19T09:03:07+00:00</dc:date>
    <link>https://mcyoung.xyz/2023/03/29/rseq-checkout/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[CPU-local (not just thread-local) concurrency in Linux using rseq(2) [via Tony Finch]]]></description>
<dc:subject>via:fanf linux concurrency multiprocessing rseq cpu-local</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:d8ecd0840341/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:fanf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:concurrency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:multiprocessing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rseq"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cpu-local"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/just-containers/s6-overlay#quickstart">
    <title>just-containers/s6-overlay</title>
    <dc:date>2025-04-09T10:50:22+00:00</dc:date>
    <link>https://github.com/just-containers/s6-overlay#quickstart</link>
    <dc:creator>jm</dc:creator><description><![CDATA[s6-overlay -- a Docker process management system, current state of the art used by Paperless and the Linux-server.io teams, with the following goals:

- Be usable on top of any Docker base image (Ubuntu, CentOS, Fedora, Alpine, Busybox);
- Make it easy to create new images, that will operate like any other images;
- Provide users with a turnkey s6 installation that will give them a stable pid 1, a fast and orderly init sequence and shutdown sequence, and the power of process supervision and automatically rotated logs.
]]></description>
<dc:subject>docker containerization containers init scripts process-management linux docker-images</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:282108a9eb35/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:docker"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:containerization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:containers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:init"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scripts"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:process-management"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:docker-images"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://boyter.org/posts/my-list-of-useful-command-line-tools/">
    <title>My list of useful command line tools</title>
    <dc:date>2025-03-25T09:43:29+00:00</dc:date>
    <link>https://boyter.org/posts/my-list-of-useful-command-line-tools/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Here's a bunch of fantastic recent CLI tools I hadn't seen before; loads are by one guy, https://github.com/sharkdp , who seems very productive :)]]></description>
<dc:subject>terminal bash shell tools cli linux unix sharkdp</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:2d9f2a12f5af/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:terminal"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bash"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:shell"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tools"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cli"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:unix"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sharkdp"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://linux.doompdf.dev/">
    <title>LinuxPDF</title>
    <dc:date>2025-02-13T12:09:37+00:00</dc:date>
    <link>https://linux.doompdf.dev/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[It's Linux, running inside a PDF file.

"The humble PDF file format supports JavaScript – with a limited standard library, mind you. By leveraging this, [vk6] managed to compile a RISC-V emulator (TinyEMU) into JavaScript using an old version of Emscripten targeting asm.js instead of WebAssembly. The emulator, embedded within the PDF, interfaces with virtual input through a keyboard and text box."

(via Fuzzix)]]></description>
<dc:subject>via:fuzzix linux pdf hacks emulation javascript emscripten tinyemu</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:22e742036221/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:fuzzix"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pdf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hacks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:emulation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:javascript"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:emscripten"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tinyemu"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://isd-project.github.io/isd/">
    <title>isd</title>
    <dc:date>2025-01-20T10:08:03+00:00</dc:date>
    <link>https://isd-project.github.io/isd/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[a curses UI for systemd, via Nelson]]></description>
<dc:subject>systemd ubuntu sysadmin linux ops curses ui tui</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:764405cefdef/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:systemd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ubuntu"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sysadmin"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:curses"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ui"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tui"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://tracker.debian.org/news/1584883/accepted-util-linux-2402-11-source-into-unstable/">
    <title>write(1) no longer part of util-linux</title>
    <dc:date>2024-11-18T09:39:22+00:00</dc:date>
    <link>https://tracker.debian.org/news/1584883/accepted-util-linux-2402-11-source-into-unstable/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[util-linux (2.40.2-11) unstable; urgency=medium

  * The mesg(1) and write(1) programs are no longer provided.
    It is believed chatting between users is nowadays done using more
    secure facilities.

 -- Chris Hofstaedtler <zeha@debian.org>  Wed, 13 Nov 2024 12:58:06 +0100

Sic transit gloria mundi.

(via Doug on ITC Slack)]]></description>
<dc:subject>via:itc write mesg unix linux bsd util-linux cli debian</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:136cfd2e5846/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:itc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:write"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mesg"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:unix"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bsd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:util-linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cli"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:debian"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://transactional.blog/how-to-learn/disk-io">
    <title>How to Learn: Userland Disk I/O</title>
    <dc:date>2024-11-08T13:21:19+00:00</dc:date>
    <link>https://transactional.blog/how-to-learn/disk-io</link>
    <dc:creator>jm</dc:creator><description><![CDATA[This is an interesting hodge-podge of key bits of information about disk I/O, file integrity and durability, buffering or unbuffered writes, async I/O, and which filesystems to use for high-I/O database operation on Linux, MacOS and Windows.  One thing that was new to me: "You can periodically scrape /proc/diskstats to self-report on disk metrics".]]></description>
<dc:subject>databases filesystems linux macos fsync durability coding</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:95771a126b07/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:databases"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:filesystems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:macos"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fsync"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:durability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://nnethercote.github.io/2022/07/27/twenty-years-of-valgrind.html">
    <title>Twenty years of Valgrind</title>
    <dc:date>2024-08-29T08:59:33+00:00</dc:date>
    <link>https://nnethercote.github.io/2022/07/27/twenty-years-of-valgrind.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[It's been an amazing tool (or set of tools) over all those years! And thank goodness Purify never chose to enforce their patents, as I'm sure that would have killed the project in its infancy]]></description>
<dc:subject>valgrind programming memory purify history linux coding static-analysis</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:57501c97c1d0/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:valgrind"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:purify"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:history"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:static-analysis"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.olivetin.app/">
    <title>OliveTin</title>
    <dc:date>2024-07-15T18:37:17+00:00</dc:date>
    <link>https://www.olivetin.app/</link>
    <dc:creator>jm</dc:creator><description><![CDATA["Give safe and simple access to predefined shell commands from a web interface."

This is great; my home server has a small set of hacky CGI scripts to run things like df(1), nice to have a nicer UI for this purpose
]]></description>
<dc:subject>ui cli shell self-hosted home unix linux web</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:7f6eef7c7bdb/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ui"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cli"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:shell"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:self-hosted"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:home"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:unix"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:web"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://arstechnica.com/security/2024/05/ssh-backdoor-has-infected-400000-linux-servers-over-15-years-and-keeps-on-spreading/?utm_brand=arstechnica&amp;utm_social-type=owned">
    <title>Linux maintainers were infected for 2 years by SSH-dwelling backdoor with huge reach | Ars Technica</title>
    <dc:date>2024-05-16T09:57:19+00:00</dc:date>
    <link>https://arstechnica.com/security/2024/05/ssh-backdoor-has-infected-400000-linux-servers-over-15-years-and-keeps-on-spreading/?utm_brand=arstechnica&amp;utm_social-type=owned</link>
    <dc:creator>jm</dc:creator><description><![CDATA[yikes.

<blockquote>Infrastructure used to maintain and distribute the Linux operating system kernel was infected for two years, starting in 2009, by sophisticated malware that managed to get a hold of one of the developers’ most closely guarded resources: the /etc/shadow files that stored encrypted password data for more than 550 system users, researchers said Tuesday.
</blockquote>

]]></description>
<dc:subject>passwords kernel linux security hacks malware kernel.org</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:32259902527f/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:passwords"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kernel"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:security"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hacks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:malware"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kernel.org"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.pgrs.net/2024/03/21/duckdb-as-the-new-jq/">
    <title>DuckDB as the New jq - Paul Gross’s Blog</title>
    <dc:date>2024-03-22T09:59:27+00:00</dc:date>
    <link>https://www.pgrs.net/2024/03/21/duckdb-as-the-new-jq/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[tl;dr: this works:

<pre>
% duckdb -c \
  "select license->>'key' as license, count(*) as count \
  from 'repos.json' \
  group by 1 \
  order by count desc"
</pre>

This is very cool.  I need to start looking into using `duckdb` as a go-to CLI tool.]]></description>
<dc:subject>duckdb cli linux unix json csv data sql querying</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:cd7c4f54c76b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:duckdb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cli"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:unix"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:json"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:csv"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:querying"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://max.levch.in/post/724289457144070144/shamir-secret-sharing-its-3am-paul-the-head-of">
    <title>Max Levchin's Shamir Secret Sharing story</title>
    <dc:date>2023-08-11T13:05:13+00:00</dc:date>
    <link>https://max.levch.in/post/724289457144070144/shamir-secret-sharing-its-3am-paul-the-head-of</link>
    <dc:creator>jm</dc:creator><description><![CDATA[this is amazing. "This is the story of a catastrophic software bug I briefly introduced into the PayPal codebase that almost cost us the company (or so it seemed, in the moment.)"

tl;dr: UNIX libc API standardisation failure bites again -- the getpass() API had differing behaviour between Linux and Solaris, where SysV compatibility caused passwords to be truncated after 8 bytes. horrific]]></description>
<dc:subject>via:hn paypal security getpass libc system-v unix linux solaris bugs war-stories</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:4145894e44be/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:hn"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:paypal"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:security"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:getpass"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:libc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:system-v"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:unix"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:solaris"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bugs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:war-stories"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://aws.amazon.com/s3/features/mountpoint/">
    <title>Mountpoint for S3</title>
    <dc:date>2023-08-09T15:58:39+00:00</dc:date>
    <link>https://aws.amazon.com/s3/features/mountpoint/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[An officially-supported Linux filesystem client for Amazon S3, now GA]]></description>
<dc:subject>s3 clients oss linux aws filesystems unix</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:2f96c68c04ef/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:s3"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:clients"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:oss"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:filesystems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:unix"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://chrisdown.name/2018/01/02/in-defence-of-swap.html">
    <title>In defence of swap</title>
    <dc:date>2023-05-11T09:56:01+00:00</dc:date>
    <link>https://chrisdown.name/2018/01/02/in-defence-of-swap.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Common misconceptions about swap memory on Linux systems:

<blockquote>Swap is a useful tool to allow equality of reclamation of memory pages, but its purpose is frequently misunderstood, leading to its negative perception across the industry. If you use swap in the spirit intended, though – as a method of increasing equality of reclamation – you'll find that it's a useful tool instead of a hindrance.

Disabling swap does not prevent disk I/O from becoming a problem under memory contention, it simply shifts the disk I/O thrashing from anonymous pages to file pages. Not only may this be less efficient, as we have a smaller pool of pages to select from for reclaim, but it may also contribute to getting into this high contention state in the first place.
</blockquote>

(via valen)]]></description>
<dc:subject>linux memory performance swap vm oom</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:d9ca8717e766/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:swap"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:vm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:oom"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://news.ycombinator.com/item?id=34612277&amp;s=03">
    <title>Raspberry Pi alternatives</title>
    <dc:date>2023-02-02T10:58:47+00:00</dc:date>
    <link>https://news.ycombinator.com/item?id=34612277&amp;s=03</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Interesting thread on the current state of low-cost/low-power server hardware; I didn't realise thin client boxes were so viable for this use case, these days.  (I've just replaced my current home server with an ODROID HC4, and I'm absolutely delighted with it, though...)]]></description>
<dc:subject>servers home gadgets hardware linux raspberry-pi</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:7ed216cab297/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:servers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:home"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gadgets"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hardware"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:raspberry-pi"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/robweber/omni-epd/blob/main/README.md">
    <title>omni-epd</title>
    <dc:date>2023-01-24T10:26:42+00:00</dc:date>
    <link>https://github.com/robweber/omni-epd/blob/main/README.md</link>
    <dc:creator>jm</dc:creator><description><![CDATA[A Python module to abstract usage of several different types of EPD (electronic paper displays), including Inky and Waveshare hardware.]]></description>
<dc:subject>epd inky waveshare e-paper displays hardware python linux</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:45a19221e52f/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:epd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:inky"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:waveshare"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:e-paper"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:displays"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hardware"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:python"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://ghettobastler.com/2022/12/04/vtech_storio_3s/">
    <title>Getting a root shell on a VTech Storio 3S tablet</title>
    <dc:date>2022-12-20T16:39:45+00:00</dc:date>
    <link>https://ghettobastler.com/2022/12/04/vtech_storio_3s/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Quite a complicated process -- extracting the eMMC chip is way beyond my abilities! -- but using FCCID.io is a neat trick]]></description>
<dc:subject>hardware hacking reverse-engineering vtech gadgets linux embedded-systems</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:856a8461c261/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hardware"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hacking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reverse-engineering"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:vtech"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gadgets"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:embedded-systems"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://mihai-albert.com/2022/02/13/out-of-memory-oom-in-kubernetes-part-2-the-oom-killer-and-application-runtime-implications/">
    <title>Out-of-memory (OOM) in Kubernetes</title>
    <dc:date>2022-09-30T17:07:11+00:00</dc:date>
    <link>https://mihai-albert.com/2022/02/13/out-of-memory-oom-in-kubernetes-part-2-the-oom-killer-and-application-runtime-implications/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Extremely detailed writeup of how k8s handle's out of memory conditions, how the Linux OOM killer interacts with cgroups, and application runtime implications]]></description>
<dc:subject>linux memory oom-killer ooms k8s kubernetes cgroups errors</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:7c73f0256951/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:oom-killer"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ooms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:k8s"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kubernetes"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cgroups"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:errors"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://raspberrypi.stackexchange.com/questions/169/how-can-i-extend-the-life-of-my-sd-card">
    <title>durability - How can I extend the life of my SD card? - Raspberry Pi Stack Exchange</title>
    <dc:date>2022-08-14T21:03:08+00:00</dc:date>
    <link>https://raspberrypi.stackexchange.com/questions/169/how-can-i-extend-the-life-of-my-sd-card</link>
    <dc:creator>jm</dc:creator><description><![CDATA[A few good suggestions here. Absolutely to nobody's surprise, it turns out systemd quietly sets up swapping to /var/swap, so that's a good one to turn off if your RPIs are not RAM-bound]]></description>
<dc:subject>sd-cards lifetime raspberry-pi hardware linux systemd</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:ed2b5bf825d6/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sd-cards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:lifetime"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:raspberry-pi"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hardware"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:systemd"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.linuxserver.io/blog/taking-the-zimaboard-for-a-spin">
    <title>Taking The ZimaBoard For A Spin | LinuxServer.io</title>
    <dc:date>2022-07-27T21:52:32+00:00</dc:date>
    <link>https://www.linuxserver.io/blog/taking-the-zimaboard-for-a-spin</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Good review for the ZimaBoard, a pretty hefty looking SBC microserver platform with a real x86_64 CPU]]></description>
<dc:subject>zimaboard hardware linux docker reviews sbc</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:9b73869aefa7/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:zimaboard"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hardware"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:docker"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reviews"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sbc"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://mazzo.li/posts/fast-pipes.html">
    <title>How fast are Linux pipes anyway?</title>
    <dc:date>2022-06-04T16:33:40+00:00</dc:date>
    <link>https://mazzo.li/posts/fast-pipes.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Very enjoyable Linux hyper-optimization through splice and huge pages]]></description>
<dc:subject>kernel linux performance pipes vmsplice splice optimization syscalls unix</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:8390af0dda94/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kernel"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pipes"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:vmsplice"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:splice"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:syscalls"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:unix"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://blog.cloudflare.com/missing-manuals-io_uring-worker-pool/">
    <title>Missing Manuals - io_uring worker pool</title>
    <dc:date>2022-02-09T11:53:13+00:00</dc:date>
    <link>https://blog.cloudflare.com/missing-manuals-io_uring-worker-pool/</link>
    <dc:creator>jm</dc:creator><description><![CDATA['Calling io_uring just an asynchronous I/O API doesn’t do it justice, though. Underneath the API calls, io_uring is a full-blown runtime for processing I/O requests. One that spawns threads, sets up work queues, and dispatches requests for processing. All this happens “in the background” so that the user space process doesn’t have to, but can, block while waiting for its I/O requests to complete.

A runtime that spawns threads and manages the worker pool for the developer makes life easier, but using it in a project begs the questions:

1. How many threads will be created for my workload by default?

2. How can I monitor and control the thread pool size? [.....]

3. What is an unbounded worker?

4. How does it differ from a bounded worker?

Things seem a bit under-documented as is, hence this blog post. Hopefully, it will provide the clarity needed to put io_uring to work in your project when the time comes.']]></description>
<dc:subject>linux io_uring apis runtime kernel system-calls coding performance</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:14f82c98f81e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:io_uring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:apis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:runtime"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kernel"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:system-calls"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://ubuntu.com/blog/safely-backup-google-photos">
    <title>Safely Backup Google Photos</title>
    <dc:date>2022-01-20T17:24:02+00:00</dc:date>
    <link>https://ubuntu.com/blog/safely-backup-google-photos</link>
    <dc:creator>jm</dc:creator><description><![CDATA[pretty simple tools on Ubuntu, from the looks of it]]></description>
<dc:subject>backup linux photos archival ubuntu</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:dfff38803f5c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:backup"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:photos"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:archival"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ubuntu"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://danluu.com/cgroup-throttling/">
    <title>The CFS quota container throttling problem</title>
    <dc:date>2021-12-19T22:01:40+00:00</dc:date>
    <link>https://danluu.com/cgroup-throttling/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Well, this is quite a messy one:

<blockquote>Almost all services at Twitter run on Linux with the CFS scheduler, using CFS bandwidth control quota for isolation, with default parameters. The intention is to allow different services to be colocated on the same boxes without having one service's runaway CPU usage impact other services and to prevent services on empty boxes from taking all of the CPU on the box, resulting in unpredictable performance, which service owners found difficult to reason about before we enabled quotas. The quota mechanism limits the amortized CPU usage of each container, but it doesn't limit how many cores the job can use at any given moment. Instead, if a job "wants to" use more than that many cores over a quota timeslice, it will use more cores than its quota for a short period of time and then get throttled, i.e., basically get put to sleep, in order to keep its amortized core usage below the quota, which is disastrous for tail latency1.

Since the vast majority of services at Twitter use thread pools that are much larger than their mesos core reservation, when jobs have heavy load, they end up requesting and then using more cores than their reservation and then throttling. This causes services that are provisioned based on load test numbers or observed latency under load to over provision CPU to avoid violating their SLOs. They either have to ask for more CPUs per shard than they actually need or they have to increase the number of shards they use.</blockquote>

Note that Kubernetes uses CFS to implement CPU quotas by default, too.

In the twitter thread about this post, a commenter noted: "'By shrinking the CFS period, the worst case time between quota exhaustion causing throttling and the process group being able to run again is reduced proportionately'. Our P99s at previous gig reduced in line after I petitioned cloud provider to adjust setting." --- this at least seems like a relatively easy setting to tune.

]]></description>
<dc:subject>cgroups kubernetes linux k8s cfs scheduling containers quotas</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:c6f83c36887b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cgroups"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kubernetes"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:k8s"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cfs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scheduling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:containers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:quotas"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1624320">
    <title>Bug #1624320 “systemd-resolved appends 127.0.0.53 to resolv.conf...” : Bugs : systemd package : Ubuntu</title>
    <dc:date>2021-12-10T11:00:21+00:00</dc:date>
    <link>https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1624320</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Wow; recent Ubuntu versions force name resolution to operate via the systemd-resolved DNS resolver, which has some pretty major bugs and omissions:

<blockquote>This bug just compromised every ubuntu machine on my network. It falsely says that DNSSEC is not supported by the nameserver and resorts to non-DNSSEC resolution. So every machine on my network just accepted bogus DNS replies from a MITM. Thanks.</blockquote>

Is there anything systemd can't break :(]]></description>
<dc:subject>systemd fail dns dnssec mitm security resolvers ubuntu bugs linux</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:56f29ab67900/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:systemd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fail"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dns"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dnssec"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mitm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:security"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:resolvers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ubuntu"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bugs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/Orange-OpenSource/bmc-cache">
    <title>Orange-OpenSource/bmc-cache</title>
    <dc:date>2021-09-20T09:14:30+00:00</dc:date>
    <link>https://github.com/Orange-OpenSource/bmc-cache</link>
    <dc:creator>jm</dc:creator><description><![CDATA[In-kernel memcache based on eBPF (via Brendan Gregg):

<blockquote>BMC (BPF Memory Cache) is an in-kernel cache for memcached. It enables runtime, crash-safe extension of the Linux kernel to process specific memcached requests before the execution of the standard network stack. BMC does not require modification of neither the Linux kernel nor the memcached application. Running memcached with BMC improves throughput by up to 18x compared to the vanilla memcached application.</blockquote>

]]></description>
<dc:subject>memcached bpf ebpf linux performance kernel via:brendangregg</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:f4d6b7e18bd8/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memcached"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bpf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ebpf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kernel"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:brendangregg"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.ifixit.com/News/51614/framework-laptop-teardown-10-10-but-is-it-perfect">
    <title>Framework Laptop Teardown: 10/10, But is it Perfect?</title>
    <dc:date>2021-08-30T09:24:19+00:00</dc:date>
    <link>https://www.ifixit.com/News/51614/framework-laptop-teardown-10-10-but-is-it-perfect</link>
    <dc:creator>jm</dc:creator><description><![CDATA[10 out of 10 for repairability -- and it looks like a great laptop! nice one]]></description>
<dc:subject>framework hardware laptops linux ifixit repairability repair</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:2a7412132b8a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:framework"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hardware"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:laptops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ifixit"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:repairability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:repair"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/Granulate/gprofiler">
    <title>gProfiler</title>
    <dc:date>2021-06-28T09:31:58+00:00</dc:date>
    <link>https://github.com/Granulate/gprofiler</link>
    <dc:creator>jm</dc:creator><description><![CDATA['a system-wide profiler, combining multiple sampling profilers to produce unified visualization of what your CPU is spending time on.' -- claims to have little impact on performance of running code, supports Linux, java and Ruby]]></description>
<dc:subject>gprofiler profiling performance testing measurement coding ruby java linux perf via:reddit</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:6772a8b88a40/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gprofiler"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:profiling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:measurement"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ruby"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:perf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:reddit"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.reddit.com/r/aws/comments/o7oxnl/strange_performance_decline_aws_clocksource_change/">
    <title>Interesting AWS performance tip</title>
    <dc:date>2021-06-27T20:41:55+00:00</dc:date>
    <link>https://www.reddit.com/r/aws/comments/o7oxnl/strange_performance_decline_aws_clocksource_change/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>we determined that calls to time.Now() or time.Since(time.Time) in Golang were taking about 200 times longer on new servers than they were on old servers. We found similar impacts in Python, which lead us to the clocksource.

It turns out that in our Grub boot parameters for AL2, we had added clocksource=hpet about two years ago, but all of our servers launched prior to 6/17 had a clocksource of kvm-clock, apparently ignoring the Grub config. Servers launched after 6/17 (with the same AMI, Grub config, everything) were honoring the specified clocksource, which caused our performance issue.</blockquote>

]]></description>
<dc:subject>ec2 aws clocksource linux kvm</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:68b3230eeae8/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:clocksource"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kvm"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.hannahtech.co/post/turn-your-old-cracked-android-phone-into-a-backup-server-urbackup-linux-deploy-tutorial-part-i">
    <title>Turn Your Old, Cracked Android Phone Into a Backup Server</title>
    <dc:date>2021-06-21T16:34:16+00:00</dc:date>
    <link>https://www.hannahtech.co/post/turn-your-old-cracked-android-phone-into-a-backup-server-urbackup-linux-deploy-tutorial-part-i</link>
    <dc:creator>jm</dc:creator><description><![CDATA[It's gratifying to see that an apk called 'Linux Deploy' will run a chrooted Debian install on a rooted Android phone -- that's a great way to reuse and recycle old, nearly-dead hardware]]></description>
<dc:subject>backup android servers linux ops home</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:3813f67ce138/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:backup"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:android"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:servers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:home"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://talawah.io/blog/extreme-http-performance-tuning-one-point-two-million/">
    <title>Extreme HTTP Performance Tuning: 1.2M API req/s on a 4 vCPU EC2 Instance | talawah.io</title>
    <dc:date>2021-05-21T08:54:01+00:00</dc:date>
    <link>https://talawah.io/blog/extreme-http-performance-tuning-one-point-two-million/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[This is very cool. Updating the old "C10K" problem space to C1.2M -- the current state of Linux userspace networking -- using libreactor and a whole load of up-to-date tweaks.

Interesting to note that this scale is feasible to run in Docker (using --network=host, of course).
]]></description>
<dc:subject>http servers c10k linux performance scalability ops tuning libreactor networking tcp</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:022774113a4b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:servers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:c10k"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scalability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:libreactor"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tcp"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://0pointer.net/blog/file-descriptor-limits.html">
    <title>File Descriptor Limits</title>
    <dc:date>2021-05-20T08:55:30+00:00</dc:date>
    <link>http://0pointer.net/blog/file-descriptor-limits.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[tl;dr: 'Don't use select() anymore in 2021.'  Select(2) on Linux has a limit of 1024 fds

]]></description>
<dc:subject>linux programming select system-calls coding libc fds</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:f54a8ef695f2/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:select"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:system-calls"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:libc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fds"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://mjg59.dreamwidth.org/56345.html">
    <title>mjg59 | Exploring my doorbell</title>
    <dc:date>2021-05-06T09:39:37+00:00</dc:date>
    <link>https://mjg59.dreamwidth.org/56345.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Nice walkthrough of rooting and extending a bit of IOT hardware]]></description>
<dc:subject>linux exploits security iot gadgets embedded u-boot</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:96df7c2f1d43/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:exploits"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:security"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:iot"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gadgets"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:embedded"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:u-boot"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.scylladb.com/2020/05/05/how-io_uring-and-ebpf-will-revolutionize-programming-in-linux/">
    <title>How io_uring and eBPF Will Revolutionize Programming in Linux</title>
    <dc:date>2020-11-26T21:52:12+00:00</dc:date>
    <link>https://www.scylladb.com/2020/05/05/how-io_uring-and-ebpf-will-revolutionize-programming-in-linux/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Nice writeup of how io_uring works, and how it improves performance]]></description>
<dc:subject>io_uring linux coding libc io performance</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:dfb34efedfee/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:io_uring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:libc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:io"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/Feh/nocache">
    <title>Feh/nocache</title>
    <dc:date>2020-09-23T10:43:42+00:00</dc:date>
    <link>https://github.com/Feh/nocache</link>
    <dc:creator>jm</dc:creator><description><![CDATA[minimize filesystem caching effects:

<blockquote>
The nocache tool tries to minimize the effect an application has on the Linux file system cache. This is done by intercepting the open and close system calls and calling posix_fadvise() with the POSIX_FADV_DONTNEED parameter. Because the library remembers which pages (ie., 4K-blocks of the file) were already in file system cache when the file was opened, these will not be marked as "don't need", because other applications might need that, although they are not actively used (think: hot standby).</blockquote>

]]></description>
<dc:subject>cache linux memory performance filesystems backup k8s unix fadvise</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:bd12d7ea46ac/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cache"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:filesystems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:backup"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:k8s"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:unix"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fadvise"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.jeffgeerling.com/blog/2020/raspberry-pi-usb-boot-uasp-trim-and-performance">
    <title>Raspberry Pi USB Boot - UASP, TRIM, and performance</title>
    <dc:date>2020-09-21T10:38:32+00:00</dc:date>
    <link>https://www.jeffgeerling.com/blog/2020/raspberry-pi-usb-boot-uasp-trim-and-performance</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>In the past few weeks, I reviewed USB drive performance on the Raspberry Pi 4, and the importance of UASP support for USB drive performance.
Both posts generated great discussion, and there were three things I wanted to cover in this follow-up, namely: Which drives support UASP; Real-world performance benchmarks; TRIM support.</blockquote>

]]></description>
<dc:subject>raspberry-pi optimization linux trim ssd filesystems usb</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:36695789d680/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:raspberry-pi"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:trim"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ssd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:filesystems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:usb"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://ulsoy.org/blog/experiencing-wsl-as-a-linux-veteran-part-1/">
    <title>Experiencing WSL as a Linux Veteran</title>
    <dc:date>2020-01-20T10:22:54+00:00</dc:date>
    <link>https://ulsoy.org/blog/experiencing-wsl-as-a-linux-veteran-part-1/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Sounds like they've done a great job at integration]]></description>
<dc:subject>linux windows wsl desktop unix cli</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:993f5487a928/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:windows"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:wsl"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:desktop"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:unix"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cli"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.flamingspork.com/projects/libeatmydata/">
    <title>libeatmydata</title>
    <dc:date>2019-10-10T15:55:49+00:00</dc:date>
    <link>https://www.flamingspork.com/projects/libeatmydata/</link>
    <dc:creator>jm</dc:creator><description><![CDATA['a small LD_PRELOAD library designed to (transparently) disable fsync (and friends, like open(O_SYNC)). This has two side-effects: making software that writes data safely to disk a lot quicker and making this software no longer crash safe.'

Good for tests....]]></description>
<dc:subject>fsync linux performance mysql testing</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:a876035ccbb5/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fsync"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:testing"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.gnome.org/news/2019/09/gnome-foundation-facing-lawsuit-from-rothschild-patent-imaging/">
    <title>GNOME Foundation facing lawsuit from Rothschild Patent Imaging</title>
    <dc:date>2019-09-26T10:42:50+00:00</dc:date>
    <link>https://www.gnome.org/news/2019/09/gnome-foundation-facing-lawsuit-from-rothschild-patent-imaging/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Software patents are a cancer.

'The GNOME Foundation has been made aware of a lawsuit from Rothschild Patent Imaging, LLC over patent 9,936,086. Rothschild allege that Shotwell, a free and open source personal photo manager infringes this patent.  Neil McGovern, Executive Director for the GNOME Foundation says “We have retained legal counsel and intend to vigorously defend against this baseless suit.”']]></description>
<dc:subject>software-patents swpats shotwell gnome linux open-source patents</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:d58268eb8178/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:software-patents"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:swpats"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:shotwell"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gnome"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:open-source"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:patents"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.scylladb.com/2019/09/25/isolating-workloads-with-systemd-slices/">
    <title>Isolating workloads with Systemd slices</title>
    <dc:date>2019-09-26T10:41:48+00:00</dc:date>
    <link>https://www.scylladb.com/2019/09/25/isolating-workloads-with-systemd-slices/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Systemd supports docker-like cgroups isolation, it seems, and ScyllaDB can take advantage of that]]></description>
<dc:subject>systemd cgroups process-isolation linux containerisation scylladb ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:e0ea78ae0b3f/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:systemd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cgroups"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:process-isolation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:containerisation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scylladb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.bunniestudios.com/blog/?p=5590">
    <title>Open Source Could Be a Casualty of the Trade War</title>
    <dc:date>2019-06-24T10:08:50+00:00</dc:date>
    <link>https://www.bunniestudios.com/blog/?p=5590</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>ideologically, a core tenant of open source is non-discriminatory empowerment. When I was introduced to open source in the 90’s, the chief “bad guy” was Microsoft – people wanted to defend against “embrace, extend, extinguish” corporate practices, and by homesteading on the technological frontier with GNU/Linux we were ensuring that our livelihoods, independence, and security would never be beholden to a hostile corporate power.

Now, the world has changed. Our open source code may end up being labeled as enabling a “foreign adversary”. I never suspected that I could end up on the “wrong side” of politics by being a staunch advocate of open source, but here I am. My open source mission is to empower people to be technologically independent; to know that technology is not magic, so that nobody will ever be a slave to technology. This is true even if that means resisting my own government. The erosion of freedom starts with restricting access to “foreign adversaries”, and ends with the government arbitrarily picking politically convenient winners and losers to participate in the open source ecosystem.

Freedom means freedom, and I will stand to defend it.

Now that the US is carpet-bombing Huawei’s supply chain, I fear there is no turning back. The language already written into EO13873 sets the stage to threaten open source as a whole by drawing geopolitical and national security borders over otherwise non-discriminatory development efforts. While I still hold hope that the trade war could de-escalate, the proliferation and stockpiling of powerful anti-trade weapons like EO13873 is worrisome. Now is the time to raise awareness of the threat this poses to the open source world, so that we can prepare and come together to protect the freedoms we cherish the most.

I hope, in all earnestness, that open source shall not be a casualty of this trade war.</blockquote>

]]></description>
<dc:subject>open-source business china economics huawei us-politics trade-war oss gnu linux</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:56e3429e0c97/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:open-source"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:business"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:china"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:economics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:huawei"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:us-politics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:trade-war"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:oss"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gnu"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.itsco.de/">
    <title>ITSCO</title>
    <dc:date>2019-04-08T11:22:46+00:00</dc:date>
    <link>https://www.itsco.de/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[super-cheap ancient Thinkpads etc., ideal for low cost linux laptop usage]]></description>
<dc:subject>cheap thinkpads laptops linux via:markdennehy hardware</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:02562736650f/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cheap"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:thinkpads"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:laptops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:markdennehy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hardware"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://console.cloud.google.com/cloudshell/editor?pli=1&amp;supportedpurview=project&amp;shellonly=true">
    <title>Cloud Shell - Google Cloud Platform</title>
    <dc:date>2019-03-25T21:42:53+00:00</dc:date>
    <link>https://console.cloud.google.com/cloudshell/editor?pli=1&amp;supportedpurview=project&amp;shellonly=true</link>
    <dc:creator>jm</dc:creator><description><![CDATA[I had no idea about this -- every google user has instant in-browser shell access to a Linux VM with 1.7GB of RAM]]></description>
<dc:subject>shell servers linux google gcp cloudshell</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:b1154a01a4bd/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:shell"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:servers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gcp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cloudshell"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.joyfulbikeshedding.com/blog/2019-03-14-what-causes-ruby-memory-bloat.html">
    <title>What causes Ruby memory bloat? – Joyful Bikeshedding</title>
    <dc:date>2019-03-25T11:53:22+00:00</dc:date>
    <link>https://www.joyfulbikeshedding.com/blog/2019-03-14-what-causes-ruby-memory-bloat.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>Another likely suspect is the memory allocator. After all, Nate Berkopec and Heroku remarked that fiddling with the memory allocator (either replacing it altogether with jemalloc, or setting the magical environment variable MALLOC_ARENA_MAX=2) drastically lowers [Ruby] memory usage.</blockquote>

]]></description>
<dc:subject>ruby memory rails linux malloc bloat jemalloc ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:2ea0371f30eb/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ruby"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rails"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:malloc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bloat"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jemalloc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://batey.info/docker-jvm-k8s.html">
    <title>The JVM in Docker 2018</title>
    <dc:date>2018-11-19T11:57:33+00:00</dc:date>
    <link>http://batey.info/docker-jvm-k8s.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>
Later JDK versions have made it far easier to run a JVM application in a Linux container. The memory support means that if you relied on JVM ergonomics before than you can do the same inside a container where as previously you had to override all memory related settings. The CPU support for containers needs to be carefully evaluated for your application and environment. If you’ve previously set low cpu_shares in environments like Kubernetes to increase utilisation while relying on using up unused cycles then you might get a shock.</blockquote>

]]></description>
<dc:subject>jvm docker kubernetes linux containers ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:521b7b5a67e4/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:docker"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kubernetes"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:containers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://canonical.org/~kragen/sw/dev3/wifiscan.py">
    <title>wifiscan.py</title>
    <dc:date>2018-11-07T21:46:52+00:00</dc:date>
    <link>http://canonical.org/~kragen/sw/dev3/wifiscan.py</link>
    <dc:creator>jm</dc:creator><description><![CDATA[A neat kragen hack:

<blockquote>Report wireless signal strength using audio synthesis.

This quick kludge is useful for figuring out where the dead spots in
your wireless network coverage are.  They’re where the pitch goes high
and maybe you start getting clicks from audio buffer underruns.

Example audio output can be found at
<http://canonical.org/~kragen/sw/wifiscan.ogg>.

This is based on a brilliant hack by Seth Schoen, in which he
generated a tone controlled by the signal strength indication from his
wireless card in order to get a sort of 21st-century software
Theremin.  This adds some envelope modulation so that it’s useful as a
network diagnostic tool rather than a musical instrument.

It depends on PulseAudio and the interface to the usual set of Linux
commands: pacat, ping, and iwconfig.  (I should really just read
/proc/net/wireless instead of depending on iwconfig.)</blockquote>

]]></description>
<dc:subject>kragen wifi scanning audio sound signal linux</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:449997ee022e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kragen"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:wifi"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scanning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:audio"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sound"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:signal"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://haydenjames.io/nginx-tuning-tips-tls-ssl-https-ttfb-latency/">
    <title>Nginx tuning tips: TLS/SSL HTTPS – Improved TTFB/latency</title>
    <dc:date>2018-07-05T09:45:02+00:00</dc:date>
    <link>https://haydenjames.io/nginx-tuning-tips-tls-ssl-https-ttfb-latency/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Must do these soon on jmason.org / taint.org et al.]]></description>
<dc:subject>nginx http https http2 ops tls security linux</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:2be4d6918037/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nginx"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:https"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tls"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:security"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://blog.newrelic.com/2013/04/29/debugging-stuck-ruby-processes-what-to-do-before-you-kill-9/">
    <title>Debugging Stuck Ruby Processes — What to do Before You Kill -9</title>
    <dc:date>2018-04-23T10:30:12+00:00</dc:date>
    <link>https://blog.newrelic.com/2013/04/29/debugging-stuck-ruby-processes-what-to-do-before-you-kill-9/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[good tips on using gdb to gather backtraces (via Louise)]]></description>
<dc:subject>debugging gdb ruby linux unix threads ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:053ee778bddc/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:debugging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gdb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ruby"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:unix"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:threads"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://usesthis.com/interviews/leonard.lin/">
    <title>Uses This / Leonard Lin</title>
    <dc:date>2018-04-11T09:28:18+00:00</dc:date>
    <link>https://usesthis.com/interviews/leonard.lin/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[lhl describes the stuff he uses, day to day.  Lots of travel gear, drones, Linux and a surprising lack of Macs]]></description>
<dc:subject>travel shopping hardware gear uses-this lhl drones vr linux vive chromebook tips</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:6cf31f1fb3da/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:travel"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:shopping"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hardware"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gear"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:uses-this"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:lhl"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:drones"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:vr"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:vive"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:chromebook"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tips"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://hackernoon.com/another-reason-why-your-docker-containers-may-be-slow-d37207dec27f">
    <title>Another reason why your Docker containers may be slow</title>
    <dc:date>2018-04-06T11:33:20+00:00</dc:date>
    <link>https://hackernoon.com/another-reason-why-your-docker-containers-may-be-slow-d37207dec27f</link>
    <dc:creator>jm</dc:creator><description><![CDATA[TL;DR: fadvise() is a bottleneck on Linux machines running many containers]]></description>
<dc:subject>linux fadvise filesystems performance docker containers ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:9015116d6c92/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fadvise"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:filesystems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:docker"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:containers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.stackrox.com/post/2017/08/hardening-docker-containers-and-hosts-against-vulnerabilities-a-security-toolkit/">
    <title>Hardening Docker containers and hosts against vulnerabilities: a security toolkit | StackRox: Security built in</title>
    <dc:date>2018-01-18T17:02:02+00:00</dc:date>
    <link>https://www.stackrox.com/post/2017/08/hardening-docker-containers-and-hosts-against-vulnerabilities-a-security-toolkit/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Another docker security checklist]]></description>
<dc:subject>docker security containers linux hardening</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:8066373d01a3/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:docker"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:security"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:containers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hardening"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.nearform.com/blog/securing-docker-containers-on-aws/">
    <title>Securing Docker Containers on AWS | nearForm</title>
    <dc:date>2018-01-18T17:00:33+00:00</dc:date>
    <link>https://www.nearform.com/blog/securing-docker-containers-on-aws/</link>
    <dc:creator>jm</dc:creator><description><![CDATA['On most projects at nearForm we are deploying our solutions within Docker containers. There are tasks that are repeated on each project to secure and harden off those deployments and we built this packer template to produce a quick and easy way for you to spin up an AWS AMI that passes the Docker-Bench-Security script. The Docker-Bench-Security repo is a work product of the above mentioned consolidation efforts by the Docker team.']]></description>
<dc:subject>docker aws security nearform containers linux packer</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:81c78e3e1ed8/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:docker"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:security"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nearform"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:containers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:packer"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.brendangregg.com/blog/2018-01-17/measure-working-set-size.html">
    <title>How To Measure the Working Set Size on Linux</title>
    <dc:date>2018-01-17T23:18:14+00:00</dc:date>
    <link>http://www.brendangregg.com/blog/2018-01-17/measure-working-set-size.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[A nifty metric:

<blockquote>The Working Set Size (WSS) is how much memory an application needs to keep working. Your app may have populated 100 Gbytes of main memory, but only uses 50 Mbytes each second to do its job. That's the working set size. It is used for capacity planning and scalability analysis.

You may never have seen WSS measured by any tool (I haven't either). OSes usually show you virtual memory and resident memory, shown as the "VIRT" and "RES" columns in top. Resident memory is real memory: main memory that has been allocated and page mapped. But we don't know how much of that is in heavy use, which is what WSS tells us.

In this post I'll introduce some new things I've developed for WSS estimation: two Linux tools, and WSS profile charts. The tools use either the referenced or the idle page flags to measure a page-based WSS, and were developed out of necessity for another performance problem.</blockquote>

(via Amy Tobey)
]]></description>
<dc:subject>via:amytobey memory linux rss wss proc ps processes metrics working-set-size ram</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:1d204b1c11e4/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:amytobey"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rss"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:wss"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:proc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ps"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:processes"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:working-set-size"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ram"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://news.ycombinator.com/item?id=16046636">
    <title>The mysterious case of the Linux Page Table Isolation patches | Hacker News</title>
    <dc:date>2018-01-03T12:55:01+00:00</dc:date>
    <link>https://news.ycombinator.com/item?id=16046636</link>
    <dc:creator>jm</dc:creator><description><![CDATA[good HN comments on the horrible security bug du jour -- Intel CPUs potentially allowing privileged data leaks cross-VM and cross-process]]></description>
<dc:subject>lpt linux vm intel cpus security</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:97ed5d019c23/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:lpt"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:vm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:intel"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cpus"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:security"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://help.backblaze.com/hc/en-us/articles/115001518354-How-to-configure-Backblaze-B2-with-Duplicity-on-Linux">
    <title>How to configure Backblaze B2 with Duplicity on Linux</title>
    <dc:date>2017-11-27T12:26:23+00:00</dc:date>
    <link>https://help.backblaze.com/hc/en-us/articles/115001518354-How-to-configure-Backblaze-B2-with-Duplicity-on-Linux</link>
    <dc:creator>jm</dc:creator><description><![CDATA[sorry S3, Backblaze is cheaper nowadays!]]></description>
<dc:subject>duplicity backups linux ops security b2 s3 storage home</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:a0aa65c8ad8f/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:duplicity"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:backups"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:security"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:b2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:s3"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:home"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://habilis.net/cronic/">
    <title>Cronic</title>
    <dc:date>2017-10-23T09:56:13+00:00</dc:date>
    <link>http://habilis.net/cronic/</link>
    <dc:creator>jm</dc:creator><description><![CDATA['A cure for Cron's chronic email problem']]></description>
<dc:subject>cron linux unix ops sysadmin mail</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:b567431d6767/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cron"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:unix"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sysadmin"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mail"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://poormansprofiler.org/">
    <title>poor man's profiler</title>
    <dc:date>2017-10-06T16:23:56+00:00</dc:date>
    <link>http://poormansprofiler.org/</link>
    <dc:creator>jm</dc:creator><description><![CDATA['Sampling tools like oprofile or dtrace's profile provider don't really provide methods to see what [multithreaded] programs are blocking on - only where they spend CPU time. Though there exist advanced techniques (such as systemtap and dtrace call level probes), it is overkill to build upon that. Poor man doesn't have time. Poor man needs food.'

Basically periodically grabbing stack traces from running processes using gdb.]]></description>
<dc:subject>gdb profiling linux unix mark-callaghan stack-traces performance</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:72be8ec1c19f/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gdb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:profiling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:unix"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mark-callaghan"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:stack-traces"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://compiletoi.net/share-scripts-that-have-dependencies-with-nix/">
    <title>Share scripts that have dependencies with Nix</title>
    <dc:date>2017-10-02T14:07:17+00:00</dc:date>
    <link>https://compiletoi.net/share-scripts-that-have-dependencies-with-nix/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Nice approach to one-liner packaging invocations using nix-shell]]></description>
<dc:subject>nix packaging unix linux ops shebang #!</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:42dd43c1d0e4/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nix"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:packaging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:unix"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:shebang"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:#!"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.brendangregg.com/blog/2017-08-08/linux-load-averages.html">
    <title>Linux Load Averages: Solving the Mystery</title>
    <dc:date>2017-08-21T13:17:17+00:00</dc:date>
    <link>http://www.brendangregg.com/blog/2017-08-08/linux-load-averages.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Nice bit of OS archaeology by Brendan Gregg.

<blockquote>In 1993, a Linux engineer found a nonintuitive case with load averages, and with a three-line patch changed them forever from "CPU load averages" to what one might call "system load averages." His change included tasks in the uninterruptible state, so that load averages reflected demand for disk resources and not just CPUs. These system load averages count the number of threads working and waiting to work, and are summarized as a triplet of exponentially-damped moving sum averages that use 1, 5, and 15 minutes as constants in an equation. This triplet of numbers lets you see if load is increasing or decreasing, and their greatest value may be for relative comparisons with themselves.</blockquote>

]]></description>
<dc:subject>load monitoring linux unix performance ops brendan-gregg history cpu</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:00a0f4ee73d7/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:load"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:unix"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:brendan-gregg"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:history"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cpu"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/awslabs/aws-ec2rescue-linux">
    <title>awslabs/aws-ec2rescue-linux</title>
    <dc:date>2017-07-21T09:54:23+00:00</dc:date>
    <link>https://github.com/awslabs/aws-ec2rescue-linux</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>Amazon Web Services Elastic Compute Cloud (EC2) Rescue for Linux is a python-based tool that allows for the automatic diagnosis of common problems found on EC2 Linux instances.</blockquote>

Most of the modules appear to be log-greppers looking for common kernel issues.

]]></description>
<dc:subject>ec2 aws kernel linux ec2rl ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:1e8923ebc45e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kernel"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2rl"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
</rdf:RDF>