<?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://oldhome.schmorp.de/marc/bournegol.html"/>
	<rdf:li rdf:resource="https://lobste.rs/s/gvtlpo/email_is_easy_email_address_quiz#c_vkssdf"/>
	<rdf:li rdf:resource="https://mcyoung.xyz/2023/03/29/rseq-checkout/"/>
	<rdf:li rdf:resource="https://arxiv.org/abs/2308.16862"/>
	<rdf:li rdf:resource="https://poweruser.blog/using-dtrace-with-sip-enabled-3826a352e64b"/>
	<rdf:li rdf:resource="https://emschwartz.me/understanding-the-bm25-full-text-search-algorithm/"/>
	<rdf:li rdf:resource="https://dhashe.com/how-to-build-highly-debuggable-c-binaries.html"/>
	<rdf:li rdf:resource="https://dougallj.wordpress.com/2022/08/20/faster-zlib-deflate-decompression-on-the-apple-m1-and-x86/"/>
	<rdf:li rdf:resource="https://drossbucket.com/2021/06/30/hacker-news-folk-wisdom-on-visual-programming/"/>
	<rdf:li rdf:resource="https://engineering.fb.com/2021/07/09/data-infrastructure/ribbon-filter/"/>
	<rdf:li rdf:resource="https://dotat.at/@/2022-07-15-histogram.html"/>
	<rdf:li rdf:resource="https://www.hammerspoon.org/"/>
	<rdf:li rdf:resource="https://www.dremio.com/apache-arrow-explained/"/>
	<rdf:li rdf:resource="https://eprint.iacr.org/2020/014"/>
	<rdf:li rdf:resource="https://www.hardill.me.uk/wordpress/2019/11/02/pi4-usb-c-gadget/"/>
	<rdf:li rdf:resource="https://arxiv.org/abs/1902.04023"/>
	<rdf:li rdf:resource="https://blog.scottlogic.com/2019/01/31/the-curious-case-of-disappeared-buses.html"/>
	<rdf:li rdf:resource="https://blog.benjojo.co.uk/post/eve-online-bgp-internet"/>
	<rdf:li rdf:resource="http://www.doxsey.net/blog/kubernetes--the-surprisingly-affordable-platform-for-personal-projects"/>
	<rdf:li rdf:resource="https://l0rd.github.io/containerspatterns/#1"/>
	<rdf:li rdf:resource="https://github.com/google/highwayhash"/>
	<rdf:li rdf:resource="http://nullprogram.com/blog/2017/10/06/"/>
	<rdf:li rdf:resource="http://www.itv.com/news/central/2017-09-18/undercover-operation-to-catch-drivers-too-close-to-cyclists-praised/"/>
	<rdf:li rdf:resource="https://01.org/hyperscan"/>
	<rdf:li rdf:resource="https://news.ycombinator.com/item?id=14691212"/>
	<rdf:li rdf:resource="https://utcc.utoronto.ca/~cks/space/blog/sysadmin/UnderstandingIODNSIssue"/>
	<rdf:li rdf:resource="http://up2v.nl/2017/05/29/what-went-wrong-in-british-airways-datacenter/"/>
	<rdf:li rdf:resource="https://mackeeper.com/blog/post/339-spammergate-the-fall-of-an-empire"/>
	<rdf:li rdf:resource="https://donatstudios.com/Falsehoods-Programmers-Believe-About-CSVs"/>
	<rdf:li rdf:resource="http://jeffe.cs.illinois.edu/teaching/algorithms/"/>
	<rdf:li rdf:resource="http://www.metzdowd.com/pipermail/cryptography/2016-September/030231.html"/>
	<rdf:li rdf:resource="https://janheine.wordpress.com/2016/06/14/suspension-losses-confirmed/"/>
	<rdf:li rdf:resource="http://danluu.com/google-sre-book/"/>
	<rdf:li rdf:resource="https://tools.ietf.org/html/rfc7754"/>
	<rdf:li rdf:resource="http://blog.cryptographyengineering.com/2015/12/on-juniper-backdoor.html"/>
	<rdf:li rdf:resource="https://github.com/01org/hyperscan"/>
	<rdf:li rdf:resource="http://arstechnica.com/tech-policy/2015/10/gene-patents-probably-dead-worldwide-following-australian-court-decision/"/>
	<rdf:li rdf:resource="http://fanf.livejournal.com/137283.html"/>
	<rdf:li rdf:resource="https://github.com/chrissimpkins/codeface"/>
	<rdf:li rdf:resource="http://blog.silentsignal.eu/2015/06/10/poisonous-md5-wolves-among-the-sheep/"/>
	<rdf:li rdf:resource="http://developerblog.redhat.com/2015/06/01/five-different-ways-handle-leap-seconds-ntp/"/>
	<rdf:li rdf:resource="http://arstechnica.com/apple/2015/01/why-dns-in-os-x-10-10-is-broken-and-what-you-can-do-to-fix-it/"/>
	<rdf:li rdf:resource="http://www.cs.utexas.edu/users/mckinley/papers/uncertainty-asplos-2014.pdf"/>
	<rdf:li rdf:resource="https://pmf.silvrback.com/fixing-tethering-on-android-kitkat"/>
	<rdf:li rdf:resource="https://wiki.gnome.org/Projects/OSTree"/>
	<rdf:li rdf:resource="http://arstechnica.com/business/2012/04/coolest-jobs-in-tech-literally-running-a-south-pole-data-center/"/>
	<rdf:li rdf:resource="https://wiki.recompile.se/wiki/Mandos"/>
	<rdf:li rdf:resource="https://mailinabox.email/"/>
	<rdf:li rdf:resource="http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html"/>
	<rdf:li rdf:resource="https://github.com/facebook/folly/blob/master/folly/docs/FBVector.md"/>
	<rdf:li rdf:resource="http://googleprojectzero.blogspot.co.uk/2014/08/the-poisoned-nul-byte-2014-edition.html"/>
	<rdf:li rdf:resource="https://network23.org/blackoutaustria/2014/07/01/to-whom-it-may-concern-english-version/"/>
	<rdf:li rdf:resource="http://csl.stanford.edu/~christos/publications/2014.pegasus.isca.pdf"/>
	<rdf:li rdf:resource="https://gist.github.com/lelandbatey/8677901"/>
	<rdf:li rdf:resource="https://code.facebook.com/posts/220956754772273/an-analysis-of-facebook-photo-caching/"/>
	<rdf:li rdf:resource="http://lekkertech.net/akamai.txt"/>
	<rdf:li rdf:resource="https://blogs.kent.ac.uk/unseenit/2013/10/18/stalled-scp-and-hanging-tcp-connections/"/>
	<rdf:li rdf:resource="https://www.simonsfoundation.org/quanta/20140130-perfecting-the-art-of-sensible-nonsense/"/>
	<rdf:li rdf:resource="http://www.thinkbroadband.com/news/6261-sky-parental-controls-break-jquery-website.html"/>
	<rdf:li rdf:resource="http://blog.backblaze.com/2014/01/21/what-hard-drive-should-i-buy/"/>
	<rdf:li rdf:resource="http://sigops.org/sosp/sosp13/papers/p33-david.pdf"/>
	<rdf:li rdf:resource="http://aphyr.com/posts/299-the-trouble-with-timestamps"/>
	<rdf:li rdf:resource="http://utcc.utoronto.ca/~cks/space/blog/web/SSLWebComplexity"/>
	<rdf:li rdf:resource="http://blog.docker.io/2013/08/containers-docker-how-secure-are-they/"/>
	<rdf:li rdf:resource="http://www.komar.org/faq/colorado-cataract-surgery-crystalens/ultra-violet-color-glow/"/>
	<rdf:li rdf:resource="http://www.joelonsoftware.com/items/2013/04/02.html"/>
	<rdf:li rdf:resource="https://github.com/armon/bloomd"/>
	<rdf:li rdf:resource="http://domainincite.com/12238-confusion-reigns-over-three-hijacked-cctlds"/>
	<rdf:li rdf:resource="http://opinionator.blogs.nytimes.com/2013/02/27/its-the-sugar-folks/?smid=tw-share"/>
	<rdf:li rdf:resource="http://translate.google.com/translate?sl=auto&amp;hl=en&amp;tl=en&amp;u=http://izvestia.ru/news/545688"/>
      </rdf:Seq>
    </items>
  </channel><item rdf:about="https://oldhome.schmorp.de/marc/bournegol.html">
    <title>Bournegol</title>
    <dc:date>2026-05-19T09:06:52+00:00</dc:date>
    <link>https://oldhome.schmorp.de/marc/bournegol.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[The original source code for the Bourne shell in early versions of UNIX is legendarily bizarre, as it was written in "Bournegol", the ALGOL-like dialect of C that Steve Bourne came up with, with a load of macros to make C look a bit like ALGOL 68.  This page has a good representative sample.  Thanks to Tony Finch for the reminder]]></description>
<dc:subject>via:fanf bournegol algol programming languages bizarre funny unix bin-sh macros</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:a88b5cc3a90c/</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:bournegol"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algol"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:languages"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bizarre"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:funny"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:unix"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bin-sh"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:macros"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://lobste.rs/s/gvtlpo/email_is_easy_email_address_quiz#c_vkssdf">
    <title>deep email lore</title>
    <dc:date>2025-08-25T16:20:35+00:00</dc:date>
    <link>https://lobste.rs/s/gvtlpo/email_is_easy_email_address_quiz#c_vkssdf</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Tony Finch: “i accidentally the whole history of email in the 1970s" -- this is great]]></description>
<dc:subject>email history 1970s via:fanf smtp ietf standards internet</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:219e04c983b2/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:email"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:history"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:1970s"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:fanf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:smtp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ietf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:standards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:internet"/>
</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://arxiv.org/abs/2308.16862">
    <title>UltraLogLog</title>
    <dc:date>2025-03-25T10:21:11+00:00</dc:date>
    <link>https://arxiv.org/abs/2308.16862</link>
    <dc:creator>jm</dc:creator><description><![CDATA[_UltraLogLog: A Practical and More Space-Efficient Alternative to HyperLogLog for Approximate Distinct Counting_:

<blockquote>Since its invention HyperLogLog has become the standard algorithm for approximate distinct counting. Due to its space efficiency and suitability for distributed systems, it is widely used and also implemented in numerous databases. This work presents UltraLogLog, which shares the same practical properties as HyperLogLog. It is commutative, idempotent, mergeable, and has a fast guaranteed constant-time insert operation. At the same time, it requires 28% less space to encode the same amount of distinct count information, which can be extracted using the maximum likelihood method. Alternatively, a simpler and faster estimator is proposed, which still achieves a space reduction of 24%, but at an estimation speed comparable to that of HyperLogLog. In a non-distributed setting where martingale estimation can be used, UltraLogLog is able to reduce space by 17%. Moreover, its smaller entropy and its 8-bit registers lead to better compaction when using standard compression algorithms. All this is verified by experimental results that are in perfect agreement with the theoretical analysis which also outlines potential for even more space-efficient data structures. A production-ready Java implementation of UltraLogLog has been released as part of the open-source Hash4j library. </blockquote>

(via Tony Finch)]]></description>
<dc:subject>via:fanf algorithms data-structures hyperloglog ultraloglog counting count-distinct distinct approximation counts java</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:a54e7c3c0b7d/</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:algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data-structures"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hyperloglog"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ultraloglog"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:counting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:count-distinct"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:distinct"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:approximation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:counts"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://poweruser.blog/using-dtrace-with-sip-enabled-3826a352e64b">
    <title>Using dtrace on MacOS with SIP enabled</title>
    <dc:date>2025-02-27T17:26:52+00:00</dc:date>
    <link>https://poweruser.blog/using-dtrace-with-sip-enabled-3826a352e64b</link>
    <dc:creator>jm</dc:creator><description><![CDATA["On all current MacOS versions (Catalina 10.15.x, Big Sur 11.x) System Integrity Protection (SIP) is enabled by default and prevents most uses of dtrace and other tools and scripts based on it (i.e. dtruss)."

Wow this is really complicated. Nice work, Apple (via Tony Finch)]]></description>
<dc:subject>macos mac debugging osx via:fanf dtrace tracing sip</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:e887bd86dfe8/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:macos"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mac"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:debugging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:osx"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:fanf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dtrace"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tracing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sip"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://emschwartz.me/understanding-the-bm25-full-text-search-algorithm/">
    <title>Understanding the BM25 full text search algorithm</title>
    <dc:date>2025-01-28T11:42:07+00:00</dc:date>
    <link>https://emschwartz.me/understanding-the-bm25-full-text-search-algorithm/</link>
    <dc:creator>jm</dc:creator><description><![CDATA["BM25, or Best Match 25, is a widely used algorithm for full text search. It is the default in Lucene/Elasticsearch and SQLite, among others."  At its heart, it's an interesting probabilistic ranking scheme, involving the Inverse Document Frequency of a term, term frequency in a single document, and the document length. (Via Tony Finch)]]></description>
<dc:subject>via:fanf lucene elasticsearch search text algorithms sqlite full-text bm25</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:d86bae9bc5f1/</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:lucene"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:elasticsearch"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:search"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:text"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sqlite"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:full-text"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bm25"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://dhashe.com/how-to-build-highly-debuggable-c-binaries.html">
    <title>How to build highly-debuggable C++ binaries</title>
    <dc:date>2024-12-17T14:43:43+00:00</dc:date>
    <link>https://dhashe.com/how-to-build-highly-debuggable-c-binaries.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[aka, how to have a modern C++ development environment (for when you still need to do such a thing) -- also, wow, C++ has changed a lot since the last time I was working with it. (Via Tony Finch)]]></description>
<dc:subject>via:fanf gdb c++ coding debugging builds</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:ab5c9fb90833/</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:gdb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:c++"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:debugging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:builds"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://dougallj.wordpress.com/2022/08/20/faster-zlib-deflate-decompression-on-the-apple-m1-and-x86/">
    <title>Faster zlib/DEFLATE decompression on the Apple M1 (and x86)</title>
    <dc:date>2024-09-13T12:08:48+00:00</dc:date>
    <link>https://dougallj.wordpress.com/2022/08/20/faster-zlib-deflate-decompression-on-the-apple-m1-and-x86/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Some decent low-level performance hacking on arm64/x86 (via Tony Finch)]]></description>
<dc:subject>via:fanf compression deflate optimization assembly c optimisation hacks</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:e410c595df19/</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:compression"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:deflate"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:assembly"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:c"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimisation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hacks"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://drossbucket.com/2021/06/30/hacker-news-folk-wisdom-on-visual-programming/">
    <title>Folk wisdom on visual programming</title>
    <dc:date>2024-08-21T15:05:20+00:00</dc:date>
    <link>https://drossbucket.com/2021/06/30/hacker-news-folk-wisdom-on-visual-programming/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[A (lengthy) summary of third party comments on visual programming environments and tools, from Hacker News (via Tony Finch's retro-links)]]></description>
<dc:subject>gui hn no-code programming tools coding visual-programming hacker-news via:fanf</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:fb154ee1f0dd/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gui"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hn"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:no-code"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tools"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:visual-programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hacker-news"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:fanf"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://engineering.fb.com/2021/07/09/data-infrastructure/ribbon-filter/">
    <title>Ribbon filter: Practically smaller than Bloom and Xor</title>
    <dc:date>2024-03-28T18:13:00+00:00</dc:date>
    <link>https://engineering.fb.com/2021/07/09/data-infrastructure/ribbon-filter/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>Building on some prior lines of research, the Ribbon filter combines a simplified, faster, and more flexible construction algorithm; a data layout optimized for filter queries; and near-continuous configurability to make a practical alternative to static (immutable) Bloom filters.

While well-engineered Bloom filters are extremely fast, they use roughly 50 percent more space (overhead) than the information-theoretic lower bound for filters on arbitrary keys. When Bloom filters cannot meet an application’s space efficiency targets, Ribbon filter variants dominate in space-versus-time trade-offs with near continuous configurability and space overhead as low as 1 percent or less. Ribbon filters have O(1) query times and save roughly 1/3 of memory compared with Bloom filters.

At Facebook’s scale, we expect Ribbon filters to save several percent of RAM resources, with a tiny increase in CPU usage for some major storage systems. However, we do not implement efficiency gains at all engineering costs, so it’s also important to have a user-friendly data structure. This issue stalled implementation of other Bloom alternatives offering some space savings. 

The Ribbon filter opens these new trade-offs without introducing notable discontinuities or hazards in the configuration space. In other words, there is some complexity to make Ribbon filters general and highly configurable, but these details can be hidden behind a relatively simple API. You have essentially free choice over any three of the four core performance dimensions — number of keys added to the set, memory usage, CPU efficiency, and accuracy — and the accuracy is automatically well optimized.
</blockquote>

(via Tony Finch)]]></description>
<dc:subject>via:fanf algorithms facebook programming ribbon-filters data-structures bloom-filters set-membership papers</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:9391321eb119/</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:algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:facebook"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ribbon-filters"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data-structures"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bloom-filters"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:set-membership"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:papers"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://dotat.at/@/2022-07-15-histogram.html">
    <title>hg64: a 64-bit histogram data structure</title>
    <dc:date>2022-07-26T11:19:24+00:00</dc:date>
    <link>https://dotat.at/@/2022-07-15-histogram.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Tony Finch has "written a proof-of-concept histogram data structure called hg64 [...] It can load 1 million data items in about 5ms (5ns per item), and uses a few KiB of memory."  In C, looks nifty!
]]></description>
<dc:subject>c c++ histograms storage data-structures via:fanf hg64</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:22d0c9f27fa1/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:c"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:c++"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:histograms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data-structures"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:fanf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hg64"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.hammerspoon.org/">
    <title>Hammerspoon</title>
    <dc:date>2020-12-03T11:43:32+00:00</dc:date>
    <link>https://www.hammerspoon.org/</link>
    <dc:creator>jm</dc:creator><description><![CDATA['a tool for powerful automation of OS X. At its core, Hammerspoon is just a bridge between the operating system and a Lua scripting engine. What gives Hammerspoon its power is a set of extensions that expose specific pieces of system functionality, to the user.

You can write Lua code that interacts with OS X APIs for applications, windows, mouse pointers, filesystem objects, audio devices, batteries, screens, low-level keyboard/mouse events, clipboards, location services, wifi, and more.'

(via Tony Finch)

]]></description>
<dc:subject>via:fanf automation osx mac lua scripting hammerspoon</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:2eb669dd1863/</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:automation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:osx"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mac"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:lua"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scripting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hammerspoon"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.dremio.com/apache-arrow-explained/">
    <title>Apache Arrow</title>
    <dc:date>2020-07-30T22:05:19+00:00</dc:date>
    <link>https://www.dremio.com/apache-arrow-explained/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>Arrow combines the benefits of columnar data structures with in-memory computing. It provides the performance benefits of these modern techniques while also providing the flexibility of complex data and dynamic schemas. And it does all of this in an open source and standardized way.</blockquote>

(via Tony Finch)]]></description>
<dc:subject>via:fanf arrow data formats compression columnar-storage storage libraries</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:fa06288fd165/</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:arrow"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:formats"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:compression"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:columnar-storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:libraries"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://eprint.iacr.org/2020/014">
    <title>SHA-1 is a Shambles - First Chosen-Prefix Collision on SHA-1 and Application to the PGP Web of Trust</title>
    <dc:date>2020-01-07T15:08:10+00:00</dc:date>
    <link>https://eprint.iacr.org/2020/014</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>
Abstract: The SHA-1 hash function was designed in 1995 and has been widely used during two decades. A theoretical collision attack was first proposed in 2004 [WYY05], but due to its high complexity it was only implemented in practice in 2017, using a large GPU cluster [SBK+17]. More recently, an almost practical chosen-prefix collision attack against SHA-1 has been proposed [LP19]. This more powerful attack allows to build colliding messages with two arbitrary prefixes, which is much more threatening for real protocols.

In this paper, we report the first practical implementation of this attack, and its impact on real-world security with a PGP/GnuPG impersonation attack. We managed to significantly reduce the complexity of collisions attack against SHA-1: on an Nvidia GTX 970, identical-prefix collisions can now be computed with a complexity of 261.2261.2 rather than 264.7264.7, and chosen-prefix collisions with a complexity of 263.4263.4 rather than 267.1267.1. When renting cheap GPUs, this translates to a cost of 11k US\$ for a collision, and 45k US\$ for a chosen-prefix collision, within the means of academic researchers. Our actual attack required two months of computations using 900 Nvidia GTX 1060 GPUs (we paid 75k US\$ because GPU prices were higher, and we wasted some time preparing the attack).

Therefore, the same attacks that have been practical on MD5 since 2009 are now practical on SHA-1. In particular, chosen-prefix collisions can break signature schemes and handshake security in secure channel protocols (TLS, SSH). We strongly advise to remove SHA-1 from those type of applications as soon as possible. We exemplify our cryptanalysis by creating a pair of PGP/GnuPG keys with different identities, but colliding SHA-1 certificates. A SHA-1 certification of the first key can therefore be transferred to the second key, leading to a forgery. This proves that SHA-1 signatures now offers virtually no security in practice. The legacy branch of GnuPG still uses SHA-1 by default for identity certifications, but after notifying the authors, the modern branch now rejects SHA-1 signatures (the issue is tracked as CVE-2019-14855).</blockquote>

(Via Tony Finch)]]></description>
<dc:subject>via:fanf security sha sha-1 crypto hashes hashing pgp gpg collisions</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:468127bda2ca/</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:security"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sha"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sha-1"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:crypto"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hashes"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hashing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pgp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gpg"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:collisions"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.hardill.me.uk/wordpress/2019/11/02/pi4-usb-c-gadget/">
    <title>using a Raspberry Pi 4 as a USB-C Gadget</title>
    <dc:date>2019-11-03T22:43:03+00:00</dc:date>
    <link>https://www.hardill.me.uk/wordpress/2019/11/02/pi4-usb-c-gadget/</link>
    <dc:creator>jm</dc:creator><description><![CDATA['This allows them to be powered and accessed via one of the micro USB sockets and it shows up as both a CD-Drive and a ethernet device.' (via Tony Finch)]]></description>
<dc:subject>via:fanf usb dev raspberry-pi hardware usb-c gadgets</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:9f7f777d743d/</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:usb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dev"/>
	<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:usb-c"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gadgets"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://arxiv.org/abs/1902.04023">
    <title>[1902.04023] Computing Extremely Accurate Quantiles Using t-Digests</title>
    <dc:date>2019-02-18T11:05:52+00:00</dc:date>
    <link>https://arxiv.org/abs/1902.04023</link>
    <dc:creator>jm</dc:creator><description><![CDATA['We present on-line algorithms for computing approximations of rank-based statistics that give high accuracy, particularly near the tails of a distribution, with very small sketches. Notably, the method allows a quantile q to be computed with an accuracy relative to max(q,1−q) rather than absolute accuracy as with most other methods. This new algorithm is robust with respect to skewed distributions or ordered datasets and allows separately computed summaries to be combined with no loss in accuracy.  An open-source Java implementation of this algorithm is available from the author. Independent implementations in Go and Python are also available.'

(via Tony Finch)]]></description>
<dc:subject>java go python open-source quantiles percentiles approximation statistics sketching algorithms via:fanf</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:6c84ec8a0947/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:go"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:python"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:open-source"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:quantiles"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:percentiles"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:approximation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:statistics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sketching"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:fanf"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://blog.scottlogic.com/2019/01/31/the-curious-case-of-disappeared-buses.html">
    <title>The curious case of disappearing buses</title>
    <dc:date>2019-02-13T10:50:12+00:00</dc:date>
    <link>https://blog.scottlogic.com/2019/01/31/the-curious-case-of-disappeared-buses.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Nice investigation into some dodgy pseudo-real-time bus location data in the Bristol real time passenger information system (via Tony Finch)

<blockquote>So what have we learned? One thing we are sure is that data of different qualities – genuinely real-time, pseudo real-time (Type 2 and Type 1), and non-real-time (scheduled) data – all present in the data stream.

Among these the most interesting are Type 2 pseudo real-time data. They appear to be the root cause of the phenomenon of disappearing buses.

Type 2 pseudo-real-time data are not totally bogus. One possible explanation of their existence can be this. The bus company has limited but not full tracking information on some of their buses. For example, it may know the location of a bus only when the bus leaves the bus terminal. Instead of not showing any data at all about the bus, the bus company uses interpolation to predict the locations of the bus, and reports these as if those are real-time data.</blockquote>

]]></description>
<dc:subject>via:fanf bristol buses public-transport rtpi estimation open-data</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:955f9d3a4d4b/</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:bristol"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:buses"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:public-transport"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rtpi"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:estimation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:open-data"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://blog.benjojo.co.uk/post/eve-online-bgp-internet">
    <title>using BGP to compute best paths across the London Underground</title>
    <dc:date>2019-02-07T09:31:08+00:00</dc:date>
    <link>https://blog.benjojo.co.uk/post/eve-online-bgp-internet</link>
    <dc:creator>jm</dc:creator><description><![CDATA[this is deeply silly, but also very impressive (via Tony Finch)]]></description>
<dc:subject>via:fanf bgp networking internet routing london-underground trains</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:c84d01a61942/</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:bgp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:routing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:london-underground"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:trains"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.doxsey.net/blog/kubernetes--the-surprisingly-affordable-platform-for-personal-projects">
    <title>Kubernetes: The Surprisingly Affordable Platform for Personal Projects</title>
    <dc:date>2018-10-03T10:57:19+00:00</dc:date>
    <link>http://www.doxsey.net/blog/kubernetes--the-surprisingly-affordable-platform-for-personal-projects</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>At the beginning of the year I spent several months deep diving on Kubernetes for a project at work. As an all-inclusive, batteries-included technology for infrastructure management, Kubernetes solves many of the problems you're bound to run into at scale. However popular wisdom would suggest that Kubernetes is an overly complex piece of technology only really suitable for very large clusters of machines; that it carries a large operational burden and that therefore using it for anything less than dozens of machines is overkill.

I think that's probably wrong. Kubernetes makes sense for small projects and you can have your own Kubernetes cluster today for as little as $5 a month.</blockquote>

(via Tony Finch)]]></description>
<dc:subject>via:fanf deployment howto kubernetes ops projects hacks clustering</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:fa2e19a6200f/</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:deployment"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:howto"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kubernetes"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:projects"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hacks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:clustering"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://l0rd.github.io/containerspatterns/#1">
    <title>Containers Patterns</title>
    <dc:date>2018-02-19T11:01:41+00:00</dc:date>
    <link>https://l0rd.github.io/containerspatterns/#1</link>
    <dc:creator>jm</dc:creator><description><![CDATA["There are a thousand ways to use containers" -- broken down into Development, Distribution and Runtime Patterns  (via Tony Finch)]]></description>
<dc:subject>docker containers design-patterns coding packaging deployment via:fanf</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:0e99583f73a7/</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:containers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design-patterns"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:packaging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:deployment"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:fanf"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/google/highwayhash">
    <title>google/highwayhash: Fast strong hash functions: SipHash/HighwayHash</title>
    <dc:date>2018-01-12T13:43:51+00:00</dc:date>
    <link>https://github.com/google/highwayhash</link>
    <dc:creator>jm</dc:creator><description><![CDATA[HighwayHash: 'We have devised a new way of mixing inputs with AVX2 multiply and permute instructions. The multiplications are 32x32 -> 64 bits and therefore infeasible to reverse. Permuting equalizes the distribution of the resulting bytes. The internal state occupies four 256-bit AVX2 registers. Due to limitations of the instruction set, the registers are partitioned into two 512-bit halves that remain independent until the reduce phase. The algorithm outputs 64 bit digests or up to 256 bits at no extra cost. In addition to high throughput, the algorithm is designed for low finalization cost. The result is more than twice as fast as SipTreeHash.

We also provide an SSE4.1 version (80% as fast for large inputs and 95% as fast for short inputs), an implementation for VSX on POWER and a portable version (10% as fast). A third-party ARM implementation is referenced below.

Statistical analyses and preliminary cryptanalysis are given in https://arxiv.org/abs/1612.06257.'

(via Tony Finch)]]></description>
<dc:subject>siphash highwayhash via:fanf hashing hashes algorithms mac google hash</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:c96748eca1a7/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:siphash"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:highwayhash"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:fanf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hashing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hashes"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mac"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hash"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://nullprogram.com/blog/2017/10/06/">
    <title>A Branchless UTF-8 Decoder</title>
    <dc:date>2017-10-09T10:27:09+00:00</dc:date>
    <link>http://nullprogram.com/blog/2017/10/06/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>This week I took a crack at writing a branchless UTF-8 decoder: a function that decodes a single UTF-8 code point from a byte stream without any if statements, loops, short-circuit operators, or other sorts of conditional jumps.  [...]  Why branchless? Because high performance CPUs are pipelined. That is, a single instruction is executed over a series of stages, and many instructions are executed in overlapping time intervals, each at a different stage.</blockquote>

Neat hack (via Tony Finch)]]></description>
<dc:subject>algorithms optimization unicode utf8 branchless coding c via:fanf</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:e6a102583433/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:unicode"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:utf8"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:branchless"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:c"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:fanf"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.itv.com/news/central/2017-09-18/undercover-operation-to-catch-drivers-too-close-to-cyclists-praised/">
    <title>Undercover operation 'Close Pass' reduced cyclist injuries by 20% in a year</title>
    <dc:date>2017-09-19T13:29:15+00:00</dc:date>
    <link>http://www.itv.com/news/central/2017-09-18/undercover-operation-to-catch-drivers-too-close-to-cyclists-praised/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>
An initiative to protect cyclists from dangerous overtaking has been praised, after reducing the amount of cyclists killed or seriously injured on the roads by 20% over the last year.
Operation 'Close Pass' was devised by West Midlands Police as a low cost way of preventing accidents caused by motorists who are driving too close for comfort.</blockquote>

(Via Tony Finch)]]></description>
<dc:subject>cycling via:fanf safety overtaking roads bikes</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:ef55426809be/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cycling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:fanf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:safety"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:overtaking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:roads"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bikes"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://01.org/hyperscan">
    <title>Hyperscan</title>
    <dc:date>2017-08-12T08:50:41+00:00</dc:date>
    <link>https://01.org/hyperscan</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>a high-performance multiple regex matching library. It follows the regular expression syntax of the commonly-used libpcre library, yet functions as a standalone library with its own API written in C. Hyperscan uses hybrid automata techniques to allow simultaneous matching of large numbers (up to tens of thousands) of regular expressions, as well as matching of regular expressions across streams of data.  Hyperscan is typically used in a DPI library stack.

Hyperscan began in 2008, and evolved from a commercial closed-source product 2009-2015. First developed at Sensory Networks Incorporated, and later acquired and released as open source software by Intel in October 2015. 

Hyperscan is under a 3-clause BSD license. We welcome outside contributors.</blockquote>

This is really impressive -- state of the art in parallel regexp matching has improved quite a lot since I was last looking at it.

(via Tony Finch)]]></description>
<dc:subject>via:fanf regexps regular-expressions text matching pattern-matching intel open-source bsd c dpi scanning sensory-networks</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:eb7f772d7923/</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:regexps"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:regular-expressions"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:text"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:matching"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pattern-matching"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:intel"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:open-source"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bsd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:c"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dpi"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scanning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sensory-networks"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://news.ycombinator.com/item?id=14691212">
    <title>terrible review for Solidity as a programming environment in HN</title>
    <dc:date>2017-07-24T13:39:27+00:00</dc:date>
    <link>https://news.ycombinator.com/item?id=14691212</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>"Solidity/EVM is by far the worst programming environment I have ever encountered. It would be impossible to write even toy programs correctly in this language, yet it is literally called "Solidity" and used to program a financial system that manages hundreds of millions of dollars."</blockquote>

Via Tony Finch

]]></description>
<dc:subject>blockchain ethereum programming coding via:fanf funny fail floating-point money json languages bugs reliability</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:ca02abcc222e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:blockchain"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ethereum"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:fanf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:funny"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fail"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:floating-point"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:money"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:json"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:languages"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bugs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reliability"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://utcc.utoronto.ca/~cks/space/blog/sysadmin/UnderstandingIODNSIssue">
    <title>Chris's Wiki :: blog/sysadmin/UnderstandingIODNSIssue</title>
    <dc:date>2017-07-13T20:06:17+00:00</dc:date>
    <link>https://utcc.utoronto.ca/~cks/space/blog/sysadmin/UnderstandingIODNSIssue</link>
    <dc:creator>jm</dc:creator><description><![CDATA[On the ns-a1.io security screwup for the .io CCTLD:

<blockquote>Using data from glue records instead of looking things up yourself is common but not mandatory, and there are various reasons why a resolver would not do so. Some recursive DNS servers will deliberately try to check glue record information as a security measure; for example, Unbound has the harden-referral-path option (via Tony Finch). Since the original article reported seeing real .io DNS queries being directed to Bryant's DNS server, we know that a decent number of clients were not using the root zone glue records. Probably a lot more clients were still using the glue records, through.</blockquote>

(via Tony Finch)]]></description>
<dc:subject>via:fanf dns security dot-io cctlds glue-records delegation</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:79776642bf4f/</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:dns"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:security"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dot-io"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cctlds"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:glue-records"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:delegation"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://up2v.nl/2017/05/29/what-went-wrong-in-british-airways-datacenter/">
    <title>WHAT WENT WRONG IN BRITISH AIRWAYS DATACENTER IN MAY 2017?</title>
    <dc:date>2017-05-31T13:42:11+00:00</dc:date>
    <link>http://up2v.nl/2017/05/29/what-went-wrong-in-british-airways-datacenter/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[A SPOF UPS. There was a similar AZ-wide outage in one of the Amazon DUB datacenters with a similar root cause, if I recall correctly -- supposedly redundant dual UPS systems were in fact interdependent, in that case, and power supply switchover wasn't clean enough to avoid affecting the servers.

<blockquote>Minutes later power was restored was resumed in what one source described as “uncontrolled fashion.” Instead of gradual restore, all power was restored at once resulting in a power surge.   BA CEO Cruz told BBC Radio this power surge  caused network hardware to fail. Also server hardware was damaged because of the power surge.

It seems as if the UPS was the single point of failure for power feed of the IT equipment in Boadicea House . The Times is reporting that the same UPS was powering both Heathrow based datacenters. Which could be a double single point of failure if true (I doubt it is)

The broken network  stopped the exchange of messages between different BA systems and application. Without messaging, there is no exchange of information between various applications. BA is using Progress Software’s Sonic [enterprise service bus].</blockquote>

(via Tony Finch)]]></description>
<dc:subject>postmortems ba airlines outages fail via:fanf datacenters ups power progress esb j2ee</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:4624716d7fe5/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:postmortems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ba"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:airlines"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:outages"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fail"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:fanf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:datacenters"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ups"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:power"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:progress"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:esb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:j2ee"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://mackeeper.com/blog/post/339-spammergate-the-fall-of-an-empire">
    <title>Spammergate: The Fall of an Empire</title>
    <dc:date>2017-03-06T14:20:20+00:00</dc:date>
    <link>https://mackeeper.com/blog/post/339-spammergate-the-fall-of-an-empire</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Featuring this interesting reactive-block evasion tactic:

<blockquote>In that screenshot, a RCM co-conspirator describes a technique in which the spammer seeks to open as many connections as possible between themselves and a Gmail server. This is done by purposefully configuring your own machine to send response packets extremely slowly, and in a fragmented manner, while constantly requesting more connections.
Then, when the Gmail server is almost ready to give up and drop all connections, the spammer suddenly sends as many emails as possible through the pile of connection tunnels. The receiving side is then overwhelmed with data and will quickly block the sender, but not before processing a large load of emails.</blockquote>

(via Tony Finch)

]]></description>
<dc:subject>via:fanf spam antispam gmail blocklists packets tcp networking</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:e5c526710904/</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:spam"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:antispam"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gmail"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:blocklists"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:packets"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tcp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://donatstudios.com/Falsehoods-Programmers-Believe-About-CSVs">
    <title>Falsehoods Programmers Believe About CSVs</title>
    <dc:date>2017-01-11T12:21:41+00:00</dc:date>
    <link>https://donatstudios.com/Falsehoods-Programmers-Believe-About-CSVs</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>Much of my professional work for the last 10+ years has revolved around handing, importing and exporting CSV files. CSV files are frustratingly misunderstood, abused, and most of all underspecified. While RFC4180 exists, it is far from definitive and goes largely ignored.

Partially as a companion piece to my recent post about how CSV is an encoding nightmare, and partially an expression of frustration, I've decided to make a list of falsehoods programmers believe about CSVs. I recommend my previous post for a more in-depth coverage on the pains of CSVs encodings and how the default tooling (Excel) will ruin your day.</blockquote>

(via Tony Finch)]]></description>
<dc:subject>via:fanf csv excel programming coding apis data encoding transfer falsehoods fail rfc4180</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:c8921999d6ab/</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:csv"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:excel"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:apis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:encoding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:transfer"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:falsehoods"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fail"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rfc4180"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://jeffe.cs.illinois.edu/teaching/algorithms/">
    <title>Jeff Erickson's Algorithms, Etc.</title>
    <dc:date>2016-11-05T21:35:06+00:00</dc:date>
    <link>http://jeffe.cs.illinois.edu/teaching/algorithms/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>This page contains lecture notes and other course materials for various algorithms classes I have taught at the University of Illinois, Urbana-Champaign. The notes are numbered in the order I cover the material in a typical undergraduate class, wtih notes on more advanced material (indicated by the symbol ♥) interspersed appropriately. [...] In addition to the algorithms notes I have been maintaining since 1999, this page also contains new notes on "Models of Computation", which cover a small subset of the material normally taught in undergraduate courses in formal languages and automata. I wrote these notes for a new junior-level course on "Algorithms and Models of Computation" that Lenny Pitt and I developed, which is now required for all undergraduate computer science and computer engineering majors at UIUC.</blockquote>

Via Tony Finch]]></description>
<dc:subject>via:fanf book cs algorithms jeff-erickson uiuc</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:7b0e68a81a8e/</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:book"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jeff-erickson"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:uiuc"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.metzdowd.com/pipermail/cryptography/2016-September/030231.html">
    <title>[Cryptography] Bridge hand record generator cracked</title>
    <dc:date>2016-09-13T13:32:19+00:00</dc:date>
    <link>http://www.metzdowd.com/pipermail/cryptography/2016-September/030231.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA['How to cheat at Bridge by breaking the tournament card-dealing random number generator', via Tony Finch]]></description>
<dc:subject>crypto security rngs prngs random bridge cards via:fanf</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:9f34e4e19524/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:crypto"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:security"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rngs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:prngs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:random"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bridge"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cards"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:fanf"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://janheine.wordpress.com/2016/06/14/suspension-losses-confirmed/">
    <title>Suspension Losses Confirmed</title>
    <dc:date>2016-06-21T14:58:57+00:00</dc:date>
    <link>https://janheine.wordpress.com/2016/06/14/suspension-losses-confirmed/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[high bike tire pressures are not faster, counterintuitively.  I never knew! (via Tony Finch)]]></description>
<dc:subject>cycling research bicycles via:fanf</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:7be8ca6da584/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cycling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:research"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bicycles"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:fanf"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://danluu.com/google-sre-book/">
    <title>Dan Luu reviews the Site Reliability Engineering book</title>
    <dc:date>2016-04-11T11:02:05+00:00</dc:date>
    <link>http://danluu.com/google-sre-book/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[voluminous! still looks great, looking forward to reading our copy (via Tony Finch)]]></description>
<dc:subject>books reading devops ops google sre dan-luu via:fanf</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:f27fece650a2/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:books"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reading"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:devops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sre"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dan-luu"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:fanf"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://tools.ietf.org/html/rfc7754">
    <title>RFC 7754 - Technical Considerations for Internet Service Blocking and Filtering</title>
    <dc:date>2016-03-16T12:13:00+00:00</dc:date>
    <link>https://tools.ietf.org/html/rfc7754</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>The Internet is structured to be an open communications medium.  This
   openness is one of the key underpinnings of Internet innovation, but
   it can also allow communications that may be viewed as undesirable by
   certain parties.  Thus, as the Internet has grown, so have mechanisms
   to limit the extent and impact of abusive or objectionable
   communications.  Recently, there has been an increasing emphasis on
   "blocking" and "filtering", the active prevention of such
   communications.  This document examines several technical approaches
   to Internet blocking and filtering in terms of their alignment with
   the overall Internet architecture.  When it is possible to do so, the
   approach to blocking and filtering that is most coherent with the
   Internet architecture is to inform endpoints about potentially
   undesirable services, so that the communicants can avoid engaging in
   abusive or objectionable communications.  We observe that certain
   filtering and blocking approaches can cause unintended consequences
   to third parties, and we discuss the limits of efficacy of various
   approaches.</blockquote>

(via Tony Finch)]]></description>
<dc:subject>via:fanf blocking censorship filtering internet rfcs rfc isps</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:3b43dcc1f35e/</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:blocking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:censorship"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:filtering"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rfcs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rfc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:isps"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blog.cryptographyengineering.com/2015/12/on-juniper-backdoor.html">
    <title>Excellent post from Matthew Green on the Juniper backdoor</title>
    <dc:date>2015-12-22T11:21:26+00:00</dc:date>
    <link>http://blog.cryptographyengineering.com/2015/12/on-juniper-backdoor.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>For the past several years, it appears that Juniper NetScreen devices have incorporated a potentially backdoored random number generator, based on the NSA's Dual_EC_DRBG algorithm. At some point in 2012, the NetScreen code was further subverted by some unknown party, so that the very same backdoor could be used to eavesdrop on NetScreen connections. While this alteration was not authorized by Juniper, it's important to note that the attacker made no major code changes to the encryption mechanism -- they only changed parameters. This means that the systems were potentially vulnerable to other parties, even beforehand. Worse, the nature of this vulnerability is particularly insidious and generally messed up.

[....] The end result was a period in which someone -- maybe a foreign government -- was able to decrypt Juniper traffic in the U.S. and around the world.  And all because Juniper had already paved the road.

One of the most serious concerns we raise during [anti-law-enforcement-backdoor] meetings is the possibility that encryption backdoors could be subverted. Specifically, that a back door intended for law enforcement could somehow become a backdoor for people who we don't trust to read our messages. Normally when we talk about this, we're concerned about failures in storage of things like escrow keys. What this Juniper vulnerability illustrates is that the danger is much broader and more serious than that.  The problem with cryptographic backdoors is not that they're the only way that an attacker can break intro our cryptographic systems. It's merely that they're one of the best. They take care of the hard work, the laying of plumbing and electrical wiring, so attackers can simply walk in and change the drapes.</blockquote>

(via Tony Finch)]]></description>
<dc:subject>via:fanf crypto backdoors politics juniper dual-ec-drbg netscreen vpn</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:934dcb1b02c0/</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:crypto"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:backdoors"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:politics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:juniper"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dual-ec-drbg"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:netscreen"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:vpn"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/01org/hyperscan">
    <title>Hyperscan</title>
    <dc:date>2015-10-21T14:33:51+00:00</dc:date>
    <link>https://github.com/01org/hyperscan</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>a high-performance multiple regex matching library. Hyperscan uses hybrid automata techniques to allow simultaneous matching of large numbers (up to tens of thousands) of regular expressions and for the matching of regular expressions across streams of data.</blockquote>

Via Tony Finch]]></description>
<dc:subject>via:fanf regexps regex dpi hyperscan dfa nfa hybrid-automata text-matching matching text strings streams</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:f41962a90f1b/</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:regexps"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:regex"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dpi"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hyperscan"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dfa"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nfa"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hybrid-automata"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:text-matching"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:matching"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:text"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:strings"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:streams"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://arstechnica.com/tech-policy/2015/10/gene-patents-probably-dead-worldwide-following-australian-court-decision/">
    <title>Gene patents probably dead worldwide following Australian court decision</title>
    <dc:date>2015-10-09T12:39:09+00:00</dc:date>
    <link>http://arstechnica.com/tech-policy/2015/10/gene-patents-probably-dead-worldwide-following-australian-court-decision/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>The court based its reasoning on the fact that, although an isolated gene such as BRCA1 was "a product of human action, it was the existence of the information stored in the relevant sequences that was an essential element of the invention as claimed." Since the information stored in the DNA as a sequence of nucleotides was a product of nature, it did not require human action to bring it into existence, and therefore could not be patented.</blockquote>

Via Tony Finch.]]></description>
<dc:subject>via:fanf australia genetics law ipr medicine ip patents</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:46c25adbed67/</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:australia"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:genetics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:law"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ipr"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:medicine"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ip"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:patents"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://fanf.livejournal.com/137283.html">
    <title>qp tries: smaller and faster than crit-bit tries</title>
    <dc:date>2015-10-06T13:04:46+00:00</dc:date>
    <link>http://fanf.livejournal.com/137283.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[interesting new data structure from Tony Finch. "Some simple benchmarks say qp tries have about 1/3 less memory overhead and are about 10% faster than crit-bit tries."]]></description>
<dc:subject>crit-bit popcount bits bitmaps tries data-structures via:fanf qp-tries crit-bit-tries hacks memory</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:3f98dd35e7f6/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:crit-bit"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:popcount"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bits"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bitmaps"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tries"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data-structures"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:fanf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:qp-tries"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:crit-bit-tries"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hacks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/chrissimpkins/codeface">
    <title>Codeface</title>
    <dc:date>2015-06-22T09:52:04+00:00</dc:date>
    <link>https://github.com/chrissimpkins/codeface</link>
    <dc:creator>jm</dc:creator><description><![CDATA[a good collection of coding fonts (via Tony Finch)]]></description>
<dc:subject>via:fanf fonts coding ui</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:797718ef12c4/</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:fonts"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ui"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blog.silentsignal.eu/2015/06/10/poisonous-md5-wolves-among-the-sheep/">
    <title>AV vendors still relying on MD5 to identify malware</title>
    <dc:date>2015-06-10T15:07:42+00:00</dc:date>
    <link>http://blog.silentsignal.eu/2015/06/10/poisonous-md5-wolves-among-the-sheep/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[oh dear. I can see how this happened -- in many cases they may not still have samples to derive new sums from :(]]></description>
<dc:subject>md5 hashing antivirus malware security via:fanf bugs</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:11ef4e54eeb8/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:md5"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hashing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:antivirus"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:malware"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:security"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:fanf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bugs"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://developerblog.redhat.com/2015/06/01/five-different-ways-handle-leap-seconds-ntp/">
    <title>Five different ways to handle leap seconds with NTP</title>
    <dc:date>2015-06-02T13:55:04+00:00</dc:date>
    <link>http://developerblog.redhat.com/2015/06/01/five-different-ways-handle-leap-seconds-ntp/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Without switching to chronyd, ntpd -x sounds not too suboptimal:

<blockquote>With ntpd, the kernel backward step is used by default. With ntpd versions before 4.2.6, or 4.2.6 and later patched for this bug, the -x option (added to /etc/sysconfig/ntpd) can be used to disable the kernel leap second correction and ignore the leap second as far as the local clock is concerned. The one-second error gained after the leap second will be measured and corrected later by slewing in normal operation using NTP servers which already corrected their local clocks.</blockquote>

It's all pretty messy though :(]]></description>
<dc:subject>ntpd ntp chronyd clocks time synchronization via:fanf linux leap-seconds</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:52c79bcfcdf0/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ntpd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ntp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:chronyd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:clocks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:time"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:synchronization"/>
	<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:leap-seconds"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://arstechnica.com/apple/2015/01/why-dns-in-os-x-10-10-is-broken-and-what-you-can-do-to-fix-it/">
    <title>Why DNS in OS X 10.10 is broken, and what you can do to fix it | Ars Technica</title>
    <dc:date>2015-01-13T23:54:42+00:00</dc:date>
    <link>http://arstechnica.com/apple/2015/01/why-dns-in-os-x-10-10-is-broken-and-what-you-can-do-to-fix-it/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[ffs Apple.  (Via Tony Finch)]]></description>
<dc:subject>via:fanf dns osx mac mdnsresponder discoveryd bugs</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:1674c7e6af03/</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:dns"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:osx"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mac"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mdnsresponder"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:discoveryd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bugs"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.cs.utexas.edu/users/mckinley/papers/uncertainty-asplos-2014.pdf">
    <title>'Uncertain&lt;T&gt;: A First-Order Type for Uncertain Data' [paper, PDF]</title>
    <dc:date>2014-12-28T23:20:32+00:00</dc:date>
    <link>http://www.cs.utexas.edu/users/mckinley/papers/uncertainty-asplos-2014.pdf</link>
    <dc:creator>jm</dc:creator><description><![CDATA['Emerging applications increasingly use estimates such as sensor
data (GPS), probabilistic models, machine learning, big
data, and human data. Unfortunately, representing this uncertain
data with discrete types (floats, integers, and booleans)
encourages developers to pretend it is not probabilistic, which
causes three types of uncertainty bugs. (1) Using estimates
as facts ignores random error in estimates. (2) Computation
compounds that error. (3) Boolean questions on probabilistic
data induce false positives and negatives.
This paper introduces Uncertain<T>, a new programming
language abstraction for uncertain data. We implement a
Bayesian network semantics for computation and conditionals
that improves program correctness. The runtime uses sampling
and hypothesis tests to evaluate computation and conditionals
lazily and efficiently. We illustrate with sensor and
machine learning applications that Uncertain<T> improves
expressiveness and accuracy.'

(via Tony Finch)]]></description>
<dc:subject>uncertainty estimation types strong-typing coding probability statistics machine-learning sampling via:fanf</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:4e691997eba0/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:uncertainty"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:estimation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:types"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:strong-typing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:probability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:statistics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:machine-learning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sampling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:fanf"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://pmf.silvrback.com/fixing-tethering-on-android-kitkat">
    <title>Fixing tethering on Android KitKat</title>
    <dc:date>2014-12-21T23:16:25+00:00</dc:date>
    <link>https://pmf.silvrback.com/fixing-tethering-on-android-kitkat</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>Google made a change in Android 4.4 which allows operators to know when users are using tethering and conveniently block tethered devices from accessing internet.  This can be fixed permanently using the following procedure. </blockquote>

Well this is stupid. (via Tony Finch)
]]></description>
<dc:subject>via:fanf tethering android mobile</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:82ceba235b40/</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:tethering"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:android"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mobile"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://wiki.gnome.org/Projects/OSTree">
    <title>OSTree</title>
    <dc:date>2014-12-09T22:36:38+00:00</dc:date>
    <link>https://wiki.gnome.org/Projects/OSTree</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>"git for operating system binaries".

OSTree is a tool for managing bootable, immutable, versioned filesystem trees. It is not a package system; nor is it a tool for managing full disk images. Instead, it sits between those levels, offering a blend of the advantages (and disadvantages) of both.

You can use any build system you like to place content into it on a build server, then export an OSTree repository via static HTTP. On each client system, "ostree admin upgrade" can incrementally replicate that content, creating a new root for the next reboot. This provides fully atomic upgrades. Any changes made to /etc are propagated forwards, and all local state in /var is shared.

A key goal of the project is to complement existing package systems like RPM and Debian packages, and help further their evolution. In particular for example, RPM-OSTree (linked below) has as a goal a hybrid tree/package model, where you replicate a base tree via OSTree, and then add packages on top.</blockquote>

]]></description>
<dc:subject>os gnome git linux immutable deployment packaging via:fanf</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:7fcc1fbae602/</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:gnome"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:git"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:immutable"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:deployment"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:packaging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:fanf"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://arstechnica.com/business/2012/04/coolest-jobs-in-tech-literally-running-a-south-pole-data-center/">
    <title>how to run a datacenter at the South Pole</title>
    <dc:date>2014-11-06T12:16:08+00:00</dc:date>
    <link>http://arstechnica.com/business/2012/04/coolest-jobs-in-tech-literally-running-a-south-pole-data-center/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[it's not easy, basically (via Tony Finch)]]></description>
<dc:subject>via:fanf antarctica datacenters icecube wipac south-pole cold ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:22361fb623b7/</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:antarctica"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:datacenters"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:icecube"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:wipac"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:south-pole"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cold"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://wiki.recompile.se/wiki/Mandos">
    <title>Mandos</title>
    <dc:date>2014-10-06T15:23:44+00:00</dc:date>
    <link>https://wiki.recompile.se/wiki/Mandos</link>
    <dc:creator>jm</dc:creator><description><![CDATA['a system for allowing servers with encrypted root file systems to reboot unattended and/or remotely.' (via Tony Finch)]]></description>
<dc:subject>via:fanf mandos encryption security server ops sysadmin linux</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:4723bcd4e08c/</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:mandos"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:encryption"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:security"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:server"/>
	<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:linux"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://mailinabox.email/">
    <title>Mail-in-a-Box</title>
    <dc:date>2014-09-08T09:04:50+00:00</dc:date>
    <link>https://mailinabox.email/</link>
    <dc:creator>jm</dc:creator><description><![CDATA['turns a fresh cloud computer into a working mail server.  You get contact synchronization, spam filtering, and so on. On your phone, you can use apps like K-9 Mail and CardDAV-Sync free beta to sync your email and contacts between your phone and your box.'

(via Tony Finch)]]></description>
<dc:subject>via:fanf mail diy hosting webmail ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:3ab3b1c8c5de/</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:mail"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:diy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hosting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:webmail"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html">
    <title>Revisiting How We Put Together Linux Systems</title>
    <dc:date>2014-09-01T22:26:39+00:00</dc:date>
    <link>http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Building a running OS out of layered btrfs filesystems.  This sounds awesome.

<blockquote>Instantiating a new system or OS container (which is exactly the same in this scheme) just consists of creating a new appropriately named root sub-volume. Completely naturally you can share one vendor OS copy in one specific version with a multitude of container instances.

Everything is double-buffered (or actually, n-fold-buffered), because usr, runtime, framework, app sub-volumes can exist in multiple versions. Of course, by default the execution logic should always pick the newest release of each sub-volume, but it is up to the user keep multiple versions around, and possibly execute older versions, if he desires to do so. In fact, like on ChromeOS this could even be handled automatically: if a system fails to boot with a newer snapshot, the boot loader can automatically revert back to an older version of the OS.</blockquote>

(via Tony Finch)]]></description>
<dc:subject>via:fanf linux docker btrfs filesystems unionfs copy-on-write os hacking unix</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:b9563993a8c5/</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:docker"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:btrfs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:filesystems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:unionfs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:copy-on-write"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:os"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hacking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:unix"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/facebook/folly/blob/master/folly/docs/FBVector.md">
    <title>Facebook's drop-in replacement for std::vector</title>
    <dc:date>2014-09-01T09:02:26+00:00</dc:date>
    <link>https://github.com/facebook/folly/blob/master/folly/docs/FBVector.md</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Fixes some low-hanging fruit, performance-wise.

'Simply replacing std::vector with folly::fbvector (after having included the folly/FBVector.h header file) will improve the performance of your C++ code using vectors with common coding patterns. The improvements are always non-negative, almost always measurable, frequently significant, sometimes dramatic, and occasionally spectacular.'

(via Tony Finch)]]></description>
<dc:subject>c++ facebook performance algorithms vectors via:fanf optimization</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:4903013d2867/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:c++"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:facebook"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:vectors"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:fanf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://googleprojectzero.blogspot.co.uk/2014/08/the-poisoned-nul-byte-2014-edition.html">
    <title>The poisoned NUL byte, 2014 edition</title>
    <dc:date>2014-08-26T22:42:52+00:00</dc:date>
    <link>http://googleprojectzero.blogspot.co.uk/2014/08/the-poisoned-nul-byte-2014-edition.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[A successful exploit of Fedora glibc via a single NUL overflow (via Tony Finch)]]></description>
<dc:subject>via:fanf buffer-overflows security nul byte exploits google project-zero</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:bfa7b40cbea2/</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:buffer-overflows"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:security"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nul"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:byte"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:exploits"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:project-zero"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://network23.org/blackoutaustria/2014/07/01/to-whom-it-may-concern-english-version/">
    <title>Tor exit node operator prosecuted in Austria</title>
    <dc:date>2014-07-03T09:27:04+00:00</dc:date>
    <link>https://network23.org/blackoutaustria/2014/07/01/to-whom-it-may-concern-english-version/</link>
    <dc:creator>jm</dc:creator><description><![CDATA['The operator of an exit node is guilty of complicity, because he enabled others to transmit content of an illegal nature through the service.'

Via Tony Finch.]]></description>
<dc:subject>austria tor security law liability internet tunnelling eu via:fanf</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:2f1ac37c3780/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:austria"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tor"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:security"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:law"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:liability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tunnelling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:eu"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:fanf"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://csl.stanford.edu/~christos/publications/2014.pegasus.isca.pdf">
    <title>Google's Pegasus</title>
    <dc:date>2014-06-18T15:48:28+00:00</dc:date>
    <link>http://csl.stanford.edu/~christos/publications/2014.pegasus.isca.pdf</link>
    <dc:creator>jm</dc:creator><description><![CDATA[a power-management subsystem for warehouse-scale computing farms.  "It adjusts the power-performance settings of servers so that the overall workload barely meets its latency constraints for user queries."]]></description>
<dc:subject>pegasus power-management power via:fanf google latency scaling</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:ddece9bbccdf/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pegasus"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:power-management"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:power"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:fanf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scaling"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://gist.github.com/lelandbatey/8677901">
    <title>Whiteboard Picture Cleaner</title>
    <dc:date>2014-06-18T13:58:55+00:00</dc:date>
    <link>https://gist.github.com/lelandbatey/8677901</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>
This [shell one-liner] will take a picture of a whiteboard and use parts of the ImageMagick library with sane defaults to clean it up tremendously.: convert "$1" -morphology Convolve DoG:15,100,0 -negate -normalize -blur 0x1 -channel RBG -level 60%,91%,0.1 "$2"
</blockquote>

Some kind soul has put up a quickie web UI here: http://api.o2b.ru/whiteboardcleaner]]></description>
<dc:subject>graphics tools whiteboard imagemagick text images cleanup gimp photoshop via:fanf</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:91d687763ace/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:graphics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tools"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:whiteboard"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:imagemagick"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:text"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:images"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cleanup"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gimp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:photoshop"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:fanf"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://code.facebook.com/posts/220956754772273/an-analysis-of-facebook-photo-caching/">
    <title>An analysis of Facebook photo caching</title>
    <dc:date>2014-05-07T12:53:52+00:00</dc:date>
    <link>https://code.facebook.com/posts/220956754772273/an-analysis-of-facebook-photo-caching/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[excellent analysis of caching behaviour at scale, from the FB engineering blog (via Tony Finch)]]></description>
<dc:subject>via:fanf caching facebook architecture photos images cache fifo lru scalability</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:3b5a7ad7f689/</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:caching"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:facebook"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:photos"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:images"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cache"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fifo"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:lru"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scalability"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://lekkertech.net/akamai.txt">
    <title>Akamai's &quot;Secure Heap&quot; patch wasn't good enough</title>
    <dc:date>2014-04-15T09:50:40+00:00</dc:date>
    <link>http://lekkertech.net/akamai.txt</link>
    <dc:creator>jm</dc:creator><description><![CDATA['Having the private keys inaccessible is a good defense in depth move.
For this patch to work you have to make sure all sensitive values are stored in
the secure area, not just check that the area looks inaccessible. You can't do
that by keeping the private key in the same process. A review by a security
engineer would have prevented a false sense of security. A version where the
private key and the calculations are in a separate process would be more
secure. If you decide to write that version, I'll gladly see if I can break
that too.'

Akamai's response: https://blogs.akamai.com/2014/04/heartbleed-update-v3.html -- to their credit, they recognise that they need to take further action.

(via Tony Finch)]]></description>
<dc:subject>via:fanf cryptography openssl heartbleed akamai security ssl tls</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:2e435fd4c303/</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:cryptography"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:openssl"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:heartbleed"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:akamai"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:security"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ssl"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tls"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://blogs.kent.ac.uk/unseenit/2013/10/18/stalled-scp-and-hanging-tcp-connections/">
    <title>Stalled SCP and Hanging TCP Connections</title>
    <dc:date>2014-04-15T09:47:38+00:00</dc:date>
    <link>https://blogs.kent.ac.uk/unseenit/2013/10/18/stalled-scp-and-hanging-tcp-connections/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[a Cisco fail.

<blockquote>It looks like there’s a firewall in the middle that’s doing additional TCP sequence randomisation which was a good thing, but has been fixed in all current operating systems. Unfortunately, it seems that firewall doesn’t understand TCP SACK, which when coupled with a small amount of packet loss and a stateful host firewall that blocks invalid packets results in TCP connections that stall randomly. A little digging revealed that firewall to be the Cisco Firewall Services Module on our Canterbury network border.</blockquote>

(via Tony Finch)]]></description>
<dc:subject>via:fanf cisco networking firewalls scp tcp hangs sack tcpdump</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:4774b16849b8/</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:cisco"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:firewalls"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tcp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hangs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sack"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tcpdump"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.simonsfoundation.org/quanta/20140130-perfecting-the-art-of-sensible-nonsense/">
    <title>A looming breakthrough in indistinguishability obfuscation</title>
    <dc:date>2014-02-05T16:40:10+00:00</dc:date>
    <link>https://www.simonsfoundation.org/quanta/20140130-perfecting-the-art-of-sensible-nonsense/</link>
    <dc:creator>jm</dc:creator><description><![CDATA['The team’s obfuscator works by transforming a computer program into what Sahai calls a “multilinear jigsaw puzzle.” Each piece of the program gets obfuscated by mixing in random elements that are carefully chosen so that if you run the garbled program in the intended way, the randomness cancels out and the pieces fit together to compute the correct output. But if you try to do anything else with the program, the randomness makes each individual puzzle piece look meaningless.  This obfuscation scheme is unbreakable, the team showed, provided that a certain newfangled problem about lattices is as hard to solve as the team thinks it is. Time will tell if this assumption is warranted, but the scheme has already resisted several attempts to crack it, and Sahai, Barak and Garg, together with Yael Tauman Kalai of Microsoft Research New England and Omer Paneth of Boston University, have proved that the most natural types of attacks on the system are guaranteed to fail. And the hard lattice problem, though new, is closely related to a family of hard problems that have stood up to testing and are used in practical encryption schemes.'

(via Tony Finch)]]></description>
<dc:subject>obfuscation cryptography via:fanf security hard-lattice-problem crypto science</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:fee9ea88b6c5/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:obfuscation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cryptography"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:fanf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:security"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hard-lattice-problem"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:crypto"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:science"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.thinkbroadband.com/news/6261-sky-parental-controls-break-jquery-website.html">
    <title>Sky parental controls break many JQuery-using websites</title>
    <dc:date>2014-01-27T13:53:50+00:00</dc:date>
    <link>http://www.thinkbroadband.com/news/6261-sky-parental-controls-break-jquery-website.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[An 11 hour outage caused by a false positive in Sky's anti-phishing filter; all sites using the code.jquery.com CDN for JQuery would have seen errors.

<blockquote>Sky still appears to be blocking code.jquery.com and all files served via the site, and more worryingly is that if you try to report the incorrect category, once signing in on the Sky website you an error page.  We suspect the site was blocked due to being linked to by a properly malicious website, i.e. code.jquery.com and some javascript files were being used on a dodgy website and every domain mentioned was subsequently added to a block list.</blockquote>

(via Tony Finch)

]]></description>
<dc:subject>via:fanf sky filtering internet uk anti-phishing phish jquery javascript http web fps false-positives</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:583339fa52bd/</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:sky"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:filtering"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:uk"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:anti-phishing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:phish"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jquery"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:javascript"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fps"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:false-positives"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blog.backblaze.com/2014/01/21/what-hard-drive-should-i-buy/">
    <title>Backblaze Blog » What Hard Drive Should I Buy?</title>
    <dc:date>2014-01-21T23:24:58+00:00</dc:date>
    <link>http://blog.backblaze.com/2014/01/21/what-hard-drive-should-i-buy/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>Because Backblaze has a history of openness, many readers expected more details in my previous posts. They asked what drive models work best and which last the longest. Given our experience with over 25,000 drives, they asked which ones are good enough that we would buy them again. In this post, I’ll answer those questions.</blockquote>

]]></description>
<dc:subject>backblaze backup hardware hdds storage disks ops via:fanf</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:33f2b7ef62aa/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:backblaze"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:backup"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hardware"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hdds"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:disks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:fanf"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://sigops.org/sosp/sosp13/papers/p33-david.pdf">
    <title>Everything You Always Wanted to Know About Synchronization but Were Afraid to Ask</title>
    <dc:date>2013-10-21T16:32:15+00:00</dc:date>
    <link>http://sigops.org/sosp/sosp13/papers/p33-david.pdf</link>
    <dc:creator>jm</dc:creator><description><![CDATA['the most exhaustive study of [multi-core] synchronization to date']]></description>
<dc:subject>synchronization scalability cpus hardware papers via:fanf multicore cas</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:f3c2f37df2b0/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:synchronization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scalability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cpus"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hardware"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:papers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:fanf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:multicore"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cas"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://aphyr.com/posts/299-the-trouble-with-timestamps">
    <title>The trouble with timestamps</title>
    <dc:date>2013-10-14T09:45:54+00:00</dc:date>
    <link>http://aphyr.com/posts/299-the-trouble-with-timestamps</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>Timestamps, as implemented in Riak, Cassandra, et al, are fundamentally unsafe ordering constructs. In order to guarantee consistency you, the user, must ensure locally monotonic and, to some extent, globally monotonic clocks. This is a hard problem, and NTP does not solve it for you. When wall clocks are not properly coupled to the operations in the system, causal constraints can be violated. To ensure safety properties hold all the time, rather than probabilistically, you need logical clocks.</blockquote>

]]></description>
<dc:subject>clocks time distributed databases distcomp ntp via:fanf aphyr vector-clocks last-write-wins lww cassandra riak</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:dcc3c0071909/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:clocks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:time"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:distributed"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:databases"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:distcomp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ntp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:fanf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aphyr"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:vector-clocks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:last-write-wins"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:lww"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:riak"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://utcc.utoronto.ca/~cks/space/blog/web/SSLWebComplexity">
    <title>Good SSL for your website is absurdly difficult in practice</title>
    <dc:date>2013-09-15T22:36:52+00:00</dc:date>
    <link>http://utcc.utoronto.ca/~cks/space/blog/web/SSLWebComplexity</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Yet again, security software fails on packaging and UI. via Tony Finch
]]></description>
<dc:subject>security ssl tls packaging via:fanf</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:46c3fc4c515e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:security"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ssl"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tls"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:packaging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:fanf"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blog.docker.io/2013/08/containers-docker-how-secure-are-they/">
    <title>Containers and Docker: How Secure Are They?</title>
    <dc:date>2013-08-21T22:29:36+00:00</dc:date>
    <link>http://blog.docker.io/2013/08/containers-docker-how-secure-are-they/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[pretty extensive article. (via Tony Finch)]]></description>
<dc:subject>via:fanf security containerization docker containers lxc linux ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:8247118ad5ff/</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:security"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:containerization"/>
	<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:lxc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.komar.org/faq/colorado-cataract-surgery-crystalens/ultra-violet-color-glow/">
    <title>seeing into the UV spectrum after Cataract Surgery with Crystalens</title>
    <dc:date>2013-06-09T21:45:05+00:00</dc:date>
    <link>http://www.komar.org/faq/colorado-cataract-surgery-crystalens/ultra-violet-color-glow/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>I've been very happy so far with the Crystalens implant for Cataract Surgery [...] one unexpected/interesting aspect is I see a violet glow that others do not - perhaps I'm more sensitive to the low end of the visible light spectrum.</blockquote>

(via Tony Finch)]]></description>
<dc:subject>via:fanf science perception augmentation uv light sight cool cataracts surgery lens eyes</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:89077a5e8de2/</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:science"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:perception"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:augmentation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:uv"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:light"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sight"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cool"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cataracts"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:surgery"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:lens"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:eyes"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.joelonsoftware.com/items/2013/04/02.html">
    <title>The Patent Protection Racket</title>
    <dc:date>2013-04-03T12:59:55+00:00</dc:date>
    <link>http://www.joelonsoftware.com/items/2013/04/02.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Joel On Software weighs in (via Tony Finch): <blockquote>The fastest growing industry in the US right now, even during this time of slow economic growth, is probably the patent troll protection racket industry.</blockquote>

]]></description>
<dc:subject>joel-on-software patents swpats shakedown extortion us-politics patent-trolls via:fanf</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:ebf874da2acf/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:joel-on-software"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:patents"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:swpats"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:shakedown"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:extortion"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:us-politics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:patent-trolls"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:fanf"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/armon/bloomd">
    <title>bloomd</title>
    <dc:date>2013-03-19T23:20:54+00:00</dc:date>
    <link>https://github.com/armon/bloomd</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>a high-performance C server which is used to expose bloom filters and operations over them to networked clients. It uses a simple ASCII protocol which is human readable, and similar to memcached.</blockquote>(via Tony Finch)

]]></description>
<dc:subject>via:fanf memcached bloomd open-source bloom-filters</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:058c62c7b990/</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:memcached"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bloomd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:open-source"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bloom-filters"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://domainincite.com/12238-confusion-reigns-over-three-hijacked-cctlds">
    <title>Confusion reigns over three “hijacked” ccTLDs</title>
    <dc:date>2013-03-12T21:43:34+00:00</dc:date>
    <link>http://domainincite.com/12238-confusion-reigns-over-three-hijacked-cctlds</link>
    <dc:creator>jm</dc:creator><description><![CDATA[This kind of silliness is only likely to increase as the number of TLDs increases (and they become more trivial). <blockquote>What seems to be happening here is that [two companies involved] have had some kind of dispute, and that as a result the registrants and the reputation of three countries’ ccTLDs have been harmed.  Very amateurish.</blockquote>

]]></description>
<dc:subject>tlds domains via:fanf amateur-hour dns cctlds registrars adamsnames</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:53a73c2d5c01/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tlds"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:domains"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:fanf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:amateur-hour"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dns"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cctlds"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:registrars"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:adamsnames"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://opinionator.blogs.nytimes.com/2013/02/27/its-the-sugar-folks/?smid=tw-share">
    <title>It’s the Sugar, Folks</title>
    <dc:date>2013-02-28T22:08:48+00:00</dc:date>
    <link>http://opinionator.blogs.nytimes.com/2013/02/27/its-the-sugar-folks/?smid=tw-share</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>A study published in the Feb. 27 issue of the journal PLoS One links increased consumption of sugar with increased rates of diabetes by examining the data on sugar availability and the rate of diabetes in 175 countries over the past decade. And after accounting for many other factors, the researchers found that increased sugar in a population’s food supply was linked to higher diabetes rates independent of rates of obesity. In other words, according to this study, obesity doesn’t cause diabetes: sugar does.

The study demonstrates this with the same level of confidence that linked cigarettes and lung cancer in the 1960s. As Rob Lustig, one of the study’s authors and a pediatric endocrinologist at the University of California, San Francisco, said to me, “You could not enact a real-world study that would be more conclusive than this one.”</blockquote>

]]></description>
<dc:subject>nytimes health food via:fanf sugar eating diabetes papers medicine</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:699d3f912d4d/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nytimes"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:health"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:food"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:fanf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sugar"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:eating"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:diabetes"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:papers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:medicine"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://translate.google.com/translate?sl=auto&amp;hl=en&amp;tl=en&amp;u=http://izvestia.ru/news/545688">
    <title>Trojan paralyses speed cameras in Moscow</title>
    <dc:date>2013-02-28T10:00:48+00:00</dc:date>
    <link>http://translate.google.com/translate?sl=auto&amp;hl=en&amp;tl=en&amp;u=http://izvestia.ru/news/545688</link>
    <dc:creator>jm</dc:creator><description><![CDATA[what a coincidence!  (via Tony Finch)]]></description>
<dc:subject>virus trojans malware via:fanf kaspersky</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:428ea63f321e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:virus"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:trojans"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:malware"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:fanf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kaspersky"/>
</rdf:Bag></taxo:topics>
</item>
</rdf:RDF>