misc/firestuff
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Image switch to webp, crush remaining png. Drop > 50% of image bytes.

Browse Source
This commit is contained in:
Ian Gulliver
2019-04-24 03:30:01 +00:00
parent 411188f0cb
commit 2e097d8919
20 changed files with 16 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
2006-03-16-spanning-tree-protocol-introduction.html
View File

@@ -7,7 +7,7 @@
<p>STP is, simply, an ethernet-level protocol for disabling redundant links until they’re needed to avoid loops (which effectively kill ethernet networks). It works by electing a root “bridge” (meaning switch in this case). Every other bridge checks to see if it has more than one link to the root; if it does, it puts every link but one in blocking state. This lets you build neat redundant networks:</p> <p>STP is, simply, an ethernet-level protocol for disabling redundant links until they’re needed to avoid loops (which effectively kill ethernet networks). It works by electing a root “bridge” (meaning switch in this case). Every other bridge checks to see if it has more than one link to the root; if it does, it puts every link but one in blocking state. This lets you build neat redundant networks:</p>
<p><img src="data:image/png;base64,<!--# include file="images/stp.png.base64" -->" alt=""></p> <p><img src="data:image/webp;base64,<!--# include file="images/stp.webp.base64" -->" alt=""></p>
<p>(<strong>A</strong>, <strong>B</strong> and <strong>C</strong> are switches; <strong>1</strong> and <strong>2</strong> are servers)</p> <p>(<strong>A</strong>, <strong>B</strong> and <strong>C</strong> are switches; <strong>1</strong> and <strong>2</strong> are servers)</p>

2
2006-12-05-fixing-your-home-soho-network.html
View File

@@ -23,7 +23,7 @@
<ol> <ol>
<li>Diagram your network. Knowing what you have and how it’s all connected together is a critical first step toward fixing any of it. A complete diagram looks like:<br> <li>Diagram your network. Knowing what you have and how it’s all connected together is a critical first step toward fixing any of it. A complete diagram looks like:<br>
<img src="data:image/png;base64,<!--# include file="images/sample-network.png.base64" -->" alt=""><br> <img src="data:image/webp;base64,<!--# include file="images/sample-network.webp.base64" -->" alt=""><br>
(the diagram above was made with <a href="http://dia-installer.sourceforge.net/">dia</a>, a free diagramming software)</li> (the diagram above was made with <a href="http://dia-installer.sourceforge.net/">dia</a>, a free diagramming software)</li>
<li>Count up devices doing Network Address Translation (NAT; sometimes referred to as PNAT). These are usually marketed as routers or firewalls. It’s common (and completely acceptable) to have <strong>one</strong> such device, directly connected to the Internet and “in front” of all other devices. There should never be more than one; doing multiple translations will cause nothing but problems. The one such is device is also the most likely failure point; this is the place to spend real money. However, avoid anything labeled “firewall” unless you really know that you need some feature that it offers. NAT alone is enough to keep out any attacks that connect in from the Internet.</li> <li>Count up devices doing Network Address Translation (NAT; sometimes referred to as PNAT). These are usually marketed as routers or firewalls. It’s common (and completely acceptable) to have <strong>one</strong> such device, directly connected to the Internet and “in front” of all other devices. There should never be more than one; doing multiple translations will cause nothing but problems. The one such is device is also the most likely failure point; this is the place to spend real money. However, avoid anything labeled “firewall” unless you really know that you need some feature that it offers. NAT alone is enough to keep out any attacks that connect in from the Internet.</li>
<li>Repeating myself form the previous step: look <strong>hard</strong> at your diagram. Do you see any routers that could be replaced with switches? Do you see any wireless routers that could be replaced with wireless access points?</li> <li>Repeating myself form the previous step: look <strong>hard</strong> at your diagram. Do you see any routers that could be replaced with switches? Do you see any wireless routers that could be replaced with wireless access points?</li>

2
2010-03-26-fun-with-map-visualizations.html
View File

@@ -11,7 +11,7 @@
<p>Today, I got to build a visualization that <a href="http://www.google.com/appserve/fiberrfi">went public</a>:</p> <p>Today, I got to build a visualization that <a href="http://www.google.com/appserve/fiberrfi">went public</a>:</p>
<p><img src="data:image/png;base64,<!--# include file="images/fiberrfi-map.png.base64" -->" alt=""></p> <p><img src="data:image/webp;base64,<!--# include file="images/fiberrfi-map.webp.base64" -->" alt=""></p>
<p>We had lots of data from the fiber-to-the-home request-for-information site, and needed a way to visualize it. This is a <a href="http://code.google.com/apis/visualization/documentation/gallery/geomap.html">geo map</a> that uses markers. Unfortunately, the API limits you to 400 points, which wasn't enough, so I (at nmlorg's suggestion) screenshotted the map with 400 points at a time and stitched the results; hacky, but functional. We couldn't have used the direct rendering anyway, as it does one AJAX call to Google Maps to look up each point (we were passing in ZIP codes), so it takes ~10 minutes to render.</p> <p>We had lots of data from the fiber-to-the-home request-for-information site, and needed a way to visualize it. This is a <a href="http://code.google.com/apis/visualization/documentation/gallery/geomap.html">geo map</a> that uses markers. Unfortunately, the API limits you to 400 points, which wasn't enough, so I (at nmlorg's suggestion) screenshotted the map with 400 points at a time and stitched the results; hacky, but functional. We couldn't have used the direct rendering anyway, as it does one AJAX call to Google Maps to look up each point (we were passing in ZIP codes), so it takes ~10 minutes to render.</p>

2
2011-08-08-database-best-practices-for-future-scalability.html
View File

@@ -9,7 +9,7 @@
<li><p>Use InnoDB. You’re eventually likely to want transactions, foreign keys, row-level locking or relative crash safety. You can Google and find lots of InnoDB vs. MyISAM comparisons, but if you don’t want to dig too deeply, “just use InnoDB” is a safe place to start.</p></li> <li><p>Use InnoDB. You’re eventually likely to want transactions, foreign keys, row-level locking or relative crash safety. You can Google and find lots of InnoDB vs. MyISAM comparisons, but if you don’t want to dig too deeply, “just use InnoDB” is a safe place to start.</p></li>
<li><p>Don’t store data that you don’t intend to use relationally. Using MySQL as a key/value store or to store encoded data (XML, <a href="http://code.google.com/p/protobuf/">protocol buffers</a>, etc.) in BLOB/TEXT may work, but dedicated key/value stores are likely to be more efficient.</p></li> <li><p>Don’t store data that you don’t intend to use relationally. Using MySQL as a key/value store or to store encoded data (XML, <a href="http://code.google.com/p/protobuf/">protocol buffers</a>, etc.) in BLOB/TEXT may work, but dedicated key/value stores are likely to be more efficient.</p></li>
<li><p>Try to design your schema with as few hierarchies as possible. For example, take the following table layout, with arrows representing many-to-one relationships:Perhaps A=”Users”, B=”DVDs Owned”, C=”Logins”, D=”Times Watched”, while E=”Administrators” and F=”Changes”. These are two hierarchies, since A and E have no links to each other. Minimizing the number of hierarchies (keeping it to just one is awesome!) makes it easier to shard later. Schemas with cross-links (say F also links to A, or a table records transfers between two different users, linking to A twice) are very difficult to shard.<br> <li><p>Try to design your schema with as few hierarchies as possible. For example, take the following table layout, with arrows representing many-to-one relationships:Perhaps A=”Users”, B=”DVDs Owned”, C=”Logins”, D=”Times Watched”, while E=”Administrators” and F=”Changes”. These are two hierarchies, since A and E have no links to each other. Minimizing the number of hierarchies (keeping it to just one is awesome!) makes it easier to shard later. Schemas with cross-links (say F also links to A, or a table records transfers between two different users, linking to A twice) are very difficult to shard.<br>
<img src="data:image/png;base64,<!--# include file="images/db-hierarchy.png.base64" -->" alt="" style="background: white;"></p></li> <img src="data:image/webp;base64,<!--# include file="images/db-hierarchy.webp.base64" -->" alt="" style="background: white;"></p></li>
<li><p>Use BIGINT UNSIGNED NOT NULL (64-bit required numeric) primary keys on every table. AUTO_INCREMENT is fine, at least to start. You can skip this for many-to-many link tables; just put both link columns in the primary key. Having single-column, numeric primary keys makes it easier to do things like drift checking and traversing between tables.</p></li> <li><p>Use BIGINT UNSIGNED NOT NULL (64-bit required numeric) primary keys on every table. AUTO_INCREMENT is fine, at least to start. You can skip this for many-to-many link tables; just put both link columns in the primary key. Having single-column, numeric primary keys makes it easier to do things like drift checking and traversing between tables.</p></li>
<li><p>Use BIGINT instead of INT for all keys. The cost in space (4 vs. 8 bytes) and compute time is so small that you’ll never notice it, but the cost of a schema change later to increase the field size, or an accidental wraparound, can be enormous. As you expand shards, your key space becomes sparse and grows rapidly, so wide keys are critical.</p></li> <li><p>Use BIGINT instead of INT for all keys. The cost in space (4 vs. 8 bytes) and compute time is so small that you’ll never notice it, but the cost of a schema change later to increase the field size, or an accidental wraparound, can be enormous. As you expand shards, your key space becomes sparse and grows rapidly, so wide keys are critical.</p></li>
<li><p>Split off your data access code into an <a href="http://en.wikipedia.org/wiki/Object-relational_mapping">ORM layer</a>, even if it’s very simple to begin with. This will be where your read/write split, shard lookups and change tracking will live later.</p></li> <li><p>Split off your data access code into an <a href="http://en.wikipedia.org/wiki/Object-relational_mapping">ORM layer</a>, even if it’s very simple to begin with. This will be where your read/write split, shard lookups and change tracking will live later.</p></li>

1
images/db-hierarchy.png.base64
View File

File diff suppressed because one or more lines are too long

1
images/db-hierarchy.webp.base64 Normal file
View File

@@ -0,0 +1 @@
UklGRhYJAABXRUJQVlA4TAoJAAAv4EAuENfnsG3bQDKd3v4z36X4XwFB27YNxd2PoG3bhuLuN5C2Te5f8v5Pkdu2DXxKupg+IyXV1KeaampTl2rqUv2qTepTTW1qU5/61Kc+talNNXWLSW2qqUvtGlbyqS7AnRX9yEv4FwRqAkgVIyKCigFIdAMgAIKabgBAGIuYOwmYOzXddAc6QNgAQA3Y1Ow5MM49UBOce7pZKwGo6Z3nfQwAzM7cgd5R5p5lPf+Dc88LXHxk7pkdMvfMHTHvqQE490QAxNwBYXPu6cZGQEeNTTc1AN0w9xgCYO4ICKBmRwEg9weAAIA1atsWt3HeJzuKqgYUQ1XLTVW7ttXUobpKotgKKDHKINkjmEbLGHbqNgzuMjNDmBMthWmZmZkZwlS1/v56BPP5m5lCck5E/yeATlfb1qBpUEATy3KhpaVgREgwscp8aGz3RMTSWgjtJa9QQg5g+tXXadkB2AMiCdnRsftjpuXh15fGMVggci4WvsI0fuc69G4Wh+LEdYeZ5q9cgPHiKMPVh5nmyfuQrwhjAuYfZhw+DntMFM246BvGYXI+JgqjGHsZl4tRJ4pRWMW43A63MKzYz8cGeEXhxlN8fIx8YeAixudjGCyKIrzGx5fIE8fsU3WcmIqpJ3QEaerIEwCeNDc34gHcpCssq2L7atKMI9MnfW1mEljHVuNBE9M1G++z9zCny7y8gk7GWCde1ZGU+nEPtjLGtuEe07L/XKiff0A/WFZFtgOpd5qVf+BF1v1FXGpS3seiLpWuBXjfnKzGLqa+A2t0I7U+nJw29WiKI5OnnzQjGoos26cgi3OyG0NEUYLn9MaGb/hYi9GiqECCj6dQLAw3tnCRnI2AKOow/zgX18EnjDpM/pKHBApIlIoTq3jYC1tEGFSKhR9otxVSvTCoUcKK/VodT8ThJ3FGnTh7xXOvabq9E/CRQKt746K7E5oubQeqSKTRIRI0t9eQUFuKoLmzngTb4i0pSvc3A371y/6//l1RmuUTYiTa0Hhvun/Mc3ozHNtMQq8vRZ9YUIKlZLxMeqj4nZBCpJ/KBCcAL5EX3V1VIdFFquwAykg3I1V2ALBFiBRHNwAFo5oE1uaxoXuzXrR6rFD1EhE1pgA8wmoul6BaSjpZJUHdEu5GFSkGKqJqkpCyQS+irhQeUo3kqvyijYRdLakVkW5GHSoWWY1qVc7wiouqe6nU6QcNVfFQajeAIgklYWH50N1J+ulB7xxAak1DtqFYqeuDvCZB+SCNkIAa3VAGwRqQHRhM6fpzw0RtAyGNFZIHUjX5kU96qbhhDRDJBaG0KEhEpHiAQVHxeCBVE5HPrxeKG9YAEVGUslpthaNFNB5I1aSnihvWAGkZcsLqF4sHUjXpabQM9ibSNjoYGB4TiAdSNelp1AV7kDT3W+BsFYYH1hrS06gL9iBx2JwPW40YlApYA6SnURfsQeIyWgaMVASguGENkJ5GXcgNEq8+CS65xyluWAOkp3IBHDLxG8iFvb6HKW5YA6SnsgMOmXgOF0Ma3aMUN6wB0lPZAYdMfCteCSXhnqO4YQ2Q2Ftq/WmPGYABY/xpNoR5IKrrg7wmfgLjvOkXwDrMm2ZVTVQ0ii8XGkvFTVkLVHoGp/5DX/T6/eC0PVXN2fLnQWuLJyIUeSDQcfPS9O+9d2m6911xHqTK7NQXQPPCxmwo5cDspYkMNyXSXnt1HPlBgUSdmP0s03j/BmBcNqqAjlVbHkt7z2Ppb1nRDmlcFipwwV6m9XudyI+IYxTmf8e0fxxSKLMJiCeSTOPjGyDVZdSIc19n2h++FB5hRC14h/G4FMMzitiwl3GYQH4skzIkGI/vxS1RUVTjasble7BnNBbXMR6TnZiYiRXfcMGuQ7UoRmMzH+wiRDIpxeNcsC0YkkErOhif61EpCi8SnMxGayYOfMDHayjKaDYnCXh1Lw9f/j8ZUusGul941Qs94enbZp575Zb9BgmY9Ap3h26G6tRnegDLqtgY6/phOa7h7jb8dd8PyS82TIq/aYQY+wnn8PYcZn7Duj+C643Rz5jJ2114lKkefOh5Q/TjUmzkrQMfqWXMh7qeqC47yVscx4xW55O8nYMjPYhlVWyMsYNP/Q07OZuHD9W6Dhgjxj7FLM7uxxa1t/5yedIYfY/zOXsJs37o9u+bsIMZoX99chuu5YxdizlP7D/59i24tcv4qJ/1Om/fL4bqHUeZITpz1p1vMd7YsUcvu/iSu15mmfKQbZFlnYdsn0JuMyeTERaEjOmcrIVPFNW4gY/P0IcyLcSbfDyHkgyoDz7moxN1oghL8Y+5WIvyjAbjYT7WYmQmw7GUi9dgi4mCKnDpYQ5eiUstGdWi/TAP301GYyYhCY9x8E07KkmYkXx0vqdVcmscXsq8ELcd1+7w1SiljMcBa3/SKPlYO4oUcVDQAVy6IqHh+runAx7KYsiGS1/RKPnsQuTKmVGVhPgV12k6GSiJkkgjI63QuqCWstqSB0y+9DoNOycDBSHKZnOpBRo7/QoJNlY33pvmn539vOlX+oOU7Zg3Hxo7fDHKcjTQoGkbCT00WMJY4ritsUHDJpkMqDxcAmxRnoy27LEAQAWZVdljgWrQrIywQL2EzGpD7xS1poUCfVTyyMT+SaXKxPhwRg5giZgXPzBRdmA4mdZqCT6isKvFtDRIGE1EFCOzGrDCQ6Y2aEM5mdqgHW7F1MgOuBQys2EHXFEys1EXHGEys4oLDpnMrOKGPUimthx9gmRqPbAGyFQq9aMGp/9b9CoZnO6ImpjRq3dAc/t4Y+eTMHvDY5o+3AkMN3K1Eh5OMq0fuwCVxi2Wj4cZh8/BIhu2GixO8sDugtewDcfDjMuXMNCwleA5Pr5EnmErwmun4kD3c2av/NLkALj4DRPDGDv27k2YdcTUMHayE9tNDnsCN5mdb9Fudv6JuNk5hvPNzuf4u9nZh9tNzskleMzUHHvrRsw9aV7Up7zLTM25C1Z/zUxL1k+DMwiP8fEBHIatEvfxsQXlhq1Vin/Mw+F21Bo2GoKF32l3+GYUknGPFmD67v3aHH9qMeytBo7CxQA6ZmsZBwqCZOxriiVoW+hTyPi3aqrQaWwB

1
images/fiberrfi-map.png.base64
View File

File diff suppressed because one or more lines are too long

1
images/fiberrfi-map.webp.base64 Normal file
View File

File diff suppressed because one or more lines are too long

2
images/hp-switch-return-label.webp.base64
View File

File diff suppressed because one or more lines are too long

1
images/sample-network.png.base64
View File

File diff suppressed because one or more lines are too long

1
images/sample-network.webp.base64 Normal file
View File

File diff suppressed because one or more lines are too long

2
images/server-carrier.webp.base64
View File

File diff suppressed because one or more lines are too long

1
images/stp.png.base64
View File

File diff suppressed because one or more lines are too long

1
images/stp.webp.base64 Normal file
View File

@@ -0,0 +1 @@
UklGRkoJAABXRUJQVlA4TD0JAAAvw8BDAPXYurXtmOxqHcfWoQ9tmz/AtnFk286hbdu2nbR72dV2B11d31vv9/TzxraThdFfbC3EZo+uMWIsBVfs7b1j1h4SIEkybWuOz9nzbNu2bdu2bdv2e9+2bdu2bZshBwDAQpKSyU6wDNZuzyrf6P3fWq3dmZ3/O9vm2bZt2+o/JLeNJEmMdu9LnSYjM2s+cBKAcySp4odNeetfZbefzUjd2dR7RWOriMaGoSua/fOFdvFLdH4mZ+JmKHhjY/2AR7W++hJtFV0oyCo7HDOq5q9pquRld1b90Zhx3fqKmuLNYlFUs7iS2sWirHYaOun3bGburljU9f8f9MsLMQv1gnqXsPsW7mr5Cc0/EI9ZK81+55Vm9jR7RS+eQ2oTh7iMxK3ZTSdzFz4sOPyv+Elr6f8lwGiQ1auxiXkBAAzFXtNKc7uaa9UhxzyVfBgqPJOTt+Jxdsf5jJSdTRzjjcUu0cnVMcMyd7VOWtvWWqnHUVHzYdy+uErtjX3tNPKCfS9o5J/2/VMjzexrppEr7LvCDdzwwA1vccMXuWFsdUOP44Ze0wk9vyvmXoo+VHYOTHO7muu7JgQAOq4JcatNt2q2RmpPs1ecsFbthD0DJ+zduGEPzQl7mS7YU3bC3r4TzrFwwbkuLjjnSPVzvxpZRTTwXpGWurNd/BJUrxoAygo4139nO9AZ3+57WTLe+Aff69yf7IcnAQfh8eJNPPRpsbysrTzqT1AbrCs5mc3NFxHLTYVmUuVHd7VrXjElf9KBLyL1xyUDMCD3T7ZJBj+vE1IREpwlQv3ccqqe7wItSx0KswJ1QLTZa/43EJvCo55bPi1XnK745vqYPUxDTH4s2JI5OXnMIlAK4FCDnlWjS2ar/T9N1/cJRj9O1v9l9prkNSJKT1QdLjtEccZiHwEA47AP5Jq19t/zQKLy8Ow1yRGOY8Hi9HS5UYG2JTcAuUCB7cl1Yk089Lk1cLBh930Rj2TCkU87OzSL0zsqKAYNmJK5BZQA7APlS7VmeBlQR2pi0oHPXseyiW+1NPPQp4BDiZg2HwHzUSeEurGR6AywSEGm9HEpEQsDMzMX2/wIJGNBoRYpyABqyo7dK9wo7BsgD0hvqKIzvr1XVPlvYDT2lUybedcCm/jWSLcOuQ3YgNzUpk2b9cnNwLrkVpmO0RwAFs/NFq5nVJUDDBiTfX6qMdgXQC7QXlBVFGoAsFOG6khNADO1/hJueuYqkIb5wo4gBQsAMzKXRcpCc8AUfV+FOxiPAxaijoRZgDoGHILHilSMLwPjj32UbWDuD/BYPygnTF8orwQgMAj3W+rV5P1fZVuJ2gfsQqxqE147EmuAlam9EtWVnBD/dNd8UyNMABMxt8sZj70PPPKdwI8dqzEALJ6bJVoV3jU+c0+gzb1qgX+K1t7ATsQagRYpyATS5caEKvfnw8BjfaE8gX1aY5EZYJGCDMEWpI4ChxHRbSLVn8AzAvvltcLKgNrSE4L75VTMD/wY0QzMFaCFQPF6EpNy5y3l2po8IJURXZULFPhY4Pzxmnx6EUhQGe4UwXylaa0Q5F1gfXKzSeMpcR6/dFZOAbUIvHSofvcq0SWz1v6buvv7hCMfp+38MVdl8johFUlKIyBIb6ji38Do7EujCYDE9ZQ5qpMbik2LXU+ZhbkAXG42ERO5rjXpwJf1giozBGYjrmtt5VE3Vc+3e8U4HI8CFqCOGU2IvxO6vvjU7du41Z+gNlRffDKHmy8ilkOCM2lyo7vatayUUtDRDWvV50htPQAucEcNAOqxE/1YiQTS/3fESsJqdAA+/3+KBEJS4clIxSciCpAQDQiICvyPDnyPEvyOFnyOGvyNHnyNIvyMJnyMKvyLLnyLMvyKNnyKOvyJPnyJQvyIRnyISuxHJ9ajFNvRiuWoxW70YjWKsRnNWIxq7EU31qIcW9GOpajHTvRjJQqykQqvs6dh36ssDvAKDvAKLsAZiAoeo9BGUr/LVDPTemIAP9FeJpiqqk9TAninSr5X2fcNp4ypETzBWHnU9fHvtZVzBdeptARG1fE1TRW+RnWbzIFxdWilptBGkmAvgyjqN5RUGURZlRoq/Q1rFVqDqOvaJ9XzZKfAQnV6Ujth9y3cVU5lYKkqVRPaSAJrhWJa/WbPb6300iHwkmChauVamyxhuecNRW+10j+g5BssfKFlH9IbjhiT3YXBIOs7ylcxDpoIa8dr6BsHmqbpV73cCAryWuAhPdYWWkdLvkLKV+lf0HQpTbSWnpfXxACgqZA2Q7eSo6MXPCr/Jkpykp49myywRIFNiu8DA3eH1tM6RZYUH5FgqR6slW3N2oMBcs7qgVd9L0DYAXT9INzX6cBEE47DDAhQCmDkdW4h4t7ubjRhTLKXQXjVazK/BNStNHuJyxD+xF7WFNgoyCTE9Z6yDuBkTxFEqNAqAmQdwp7zGEGqfwJqyyAZvg+iqrRIDhS91rwfCtL9nRBQSAJzgsbVREtZ9oXe46swX5gT1N58CJT8hN6NjiAjrXcD18jQKTp1KixA4Svk3TbL0dXD8B62FHhDhpQAHp2c07rRV70vxGd9nglMMOU41BADOzmzzp+EZfgt6lv+592rSRpbMwS1j7u5HxIytlZFI8VPFH+GwN1JrtJTlSDHaOOx5zirq8VrW3APATToNgWCwdE6eMjtnmrhDxKt5J0AmTuJSd8v5Okrer0eHHazZ5lcWy4LIYeDo6x1y37L89nHMED2YZxgrgy8L+iLBtvlzRDUoI604Q7JX5RgprIO4rKDeiXRUhotSQhSPW81B+aqFYLH1qqs3Rgg96KeaCPNJvOS9H/AB+xnQeT2OAkmKnMbLjukvGuGRHtpOJeXpLu7IeBGub1mxiYCkH8LJTnKwMz3kjwKFFBASM9vIrSOAhTcR/cY5nokGXCfFzhfyNzLQNOVFKDgCUr2EIGhuCgLlnPgG5lz4KDJYgZwe4oXD0x9L8k/sngITN9jl7kW0XgOA3gyxV8YpyNi9HIjePGyObY8Bp56ECeq6Z/JXBPCu1JDuOA1Iagnifo95JOzNmdTB4TZxoPdKmmN1J7fWgmSjWBtGbSLI1u0mPd/wFdB16qdsGfghL0bN+yhOWEv0wV7yk7Y23fCORYuONfFBeccqX3u1/u/VVX9VtHP/RJVZ0F0bl0FAA==

2
images/wifi-router.webp.base64
View File

File diff suppressed because one or more lines are too long

2
include/icon-cow.png.base64
View File

File diff suppressed because one or more lines are too long

2
markdown/2006-03-16-spanning-tree-protocol-introduction.md
View File

@@ -7,7 +7,7 @@ I’ve been considering increased network redundancy for awhile. After trying a
STP is, simply, an ethernet-level protocol for disabling redundant links until they’re needed to avoid loops (which effectively kill ethernet networks). It works by electing a root “bridge” (meaning switch in this case). Every other bridge checks to see if it has more than one link to the root; if it does, it puts every link but one in blocking state. This lets you build neat redundant networks: STP is, simply, an ethernet-level protocol for disabling redundant links until they’re needed to avoid loops (which effectively kill ethernet networks). It works by electing a root “bridge” (meaning switch in this case). Every other bridge checks to see if it has more than one link to the root; if it does, it puts every link but one in blocking state. This lets you build neat redundant networks:
<img src="data:image/png;base64,<!--# include file="images/stp.png.base64" -->" alt=""> <img src="data:image/webp;base64,<!--# include file="images/stp.webp.base64" -->" alt="">
(__A__, __B__ and __C__ are switches; __1__ and __2__ are servers) (__A__, __B__ and __C__ are switches; __1__ and __2__ are servers)

2
markdown/2006-12-05-fixing-your-home-soho-network.md
View File

@@ -18,7 +18,7 @@ You get what you pay for
### Sorting out the devices ### Sorting out the devices
1. Diagram your network. Knowing what you have and how it’s all connected together is a critical first step toward fixing any of it. A complete diagram looks like:<br> 1. Diagram your network. Knowing what you have and how it’s all connected together is a critical first step toward fixing any of it. A complete diagram looks like:<br>
<img src="data:image/png;base64,<!--# include file="images/sample-network.png.base64" -->" alt=""><br> <img src="data:image/webp;base64,<!--# include file="images/sample-network.webp.base64" -->" alt=""><br>
(the diagram above was made with [dia](http://dia-installer.sourceforge.net/), a free diagramming software) (the diagram above was made with [dia](http://dia-installer.sourceforge.net/), a free diagramming software)
1. Count up devices doing Network Address Translation (NAT; sometimes referred to as PNAT). These are usually marketed as routers or firewalls. It’s common (and completely acceptable) to have __one__ such device, directly connected to the Internet and “in front” of all other devices. There should never be more than one; doing multiple translations will cause nothing but problems. The one such is device is also the most likely failure point; this is the place to spend real money. However, avoid anything labeled “firewall” unless you really know that you need some feature that it offers. NAT alone is enough to keep out any attacks that connect in from the Internet. 1. Count up devices doing Network Address Translation (NAT; sometimes referred to as PNAT). These are usually marketed as routers or firewalls. It’s common (and completely acceptable) to have __one__ such device, directly connected to the Internet and “in front” of all other devices. There should never be more than one; doing multiple translations will cause nothing but problems. The one such is device is also the most likely failure point; this is the place to spend real money. However, avoid anything labeled “firewall” unless you really know that you need some feature that it offers. NAT alone is enough to keep out any attacks that connect in from the Internet.
1. Repeating myself form the previous step: look __hard__ at your diagram. Do you see any routers that could be replaced with switches? Do you see any wireless routers that could be replaced with wireless access points? 1. Repeating myself form the previous step: look __hard__ at your diagram. Do you see any routers that could be replaced with switches? Do you see any wireless routers that could be replaced with wireless access points?

2
markdown/2010-03-26-fun-with-map-visualizations.md
View File

@@ -11,7 +11,7 @@ The most elegant solution seems to be a [force-directed graph](http://en.wikiped
Today, I got to build a visualization that [went public](http://www.google.com/appserve/fiberrfi): Today, I got to build a visualization that [went public](http://www.google.com/appserve/fiberrfi):
<img src="data:image/png;base64,<!--# include file="images/fiberrfi-map.png.base64" -->" alt=""> <img src="data:image/webp;base64,<!--# include file="images/fiberrfi-map.webp.base64" -->" alt="">
We had lots of data from the fiber-to-the-home request-for-information site, and needed a way to visualize it. This is a [geo map](http://code.google.com/apis/visualization/documentation/gallery/geomap.html) that uses markers. Unfortunately, the API limits you to 400 points, which wasn't enough, so I (at nmlorg's suggestion) screenshotted the map with 400 points at a time and stitched the results; hacky, but functional. We couldn't have used the direct rendering anyway, as it does one AJAX call to Google Maps to look up each point (we were passing in ZIP codes), so it takes ~10 minutes to render. We had lots of data from the fiber-to-the-home request-for-information site, and needed a way to visualize it. This is a [geo map](http://code.google.com/apis/visualization/documentation/gallery/geomap.html) that uses markers. Unfortunately, the API limits you to 400 points, which wasn't enough, so I (at nmlorg's suggestion) screenshotted the map with 400 points at a time and stitched the results; hacky, but functional. We couldn't have used the direct rendering anyway, as it does one AJAX call to Google Maps to look up each point (we were passing in ZIP codes), so it takes ~10 minutes to render.

2
markdown/2011-08-08-database-best-practices-for-future-scalability.md
View File

@@ -10,7 +10,7 @@ There’s a perpetual debate about how much effort to put into scalability when
1. Don’t store data that you don’t intend to use relationally. Using MySQL as a key/value store or to store encoded data (XML, [protocol buffers](http://code.google.com/p/protobuf/), etc.) in BLOB/TEXT may work, but dedicated key/value stores are likely to be more efficient. 1. Don’t store data that you don’t intend to use relationally. Using MySQL as a key/value store or to store encoded data (XML, [protocol buffers](http://code.google.com/p/protobuf/), etc.) in BLOB/TEXT may work, but dedicated key/value stores are likely to be more efficient.
1. Try to design your schema with as few hierarchies as possible. For example, take the following table layout, with arrows representing many-to-one relationships:Perhaps A=”Users”, B=”DVDs Owned”, C=”Logins”, D=”Times Watched”, while E=”Administrators” and F=”Changes”. These are two hierarchies, since A and E have no links to each other. Minimizing the number of hierarchies (keeping it to just one is awesome!) makes it easier to shard later. Schemas with cross-links (say F also links to A, or a table records transfers between two different users, linking to A twice) are very difficult to shard.<br> 1. Try to design your schema with as few hierarchies as possible. For example, take the following table layout, with arrows representing many-to-one relationships:Perhaps A=”Users”, B=”DVDs Owned”, C=”Logins”, D=”Times Watched”, while E=”Administrators” and F=”Changes”. These are two hierarchies, since A and E have no links to each other. Minimizing the number of hierarchies (keeping it to just one is awesome!) makes it easier to shard later. Schemas with cross-links (say F also links to A, or a table records transfers between two different users, linking to A twice) are very difficult to shard.<br>
<img src="data:image/png;base64,<!--# include file="images/db-hierarchy.png.base64" -->" alt="" style="background: white;"> <img src="data:image/webp;base64,<!--# include file="images/db-hierarchy.webp.base64" -->" alt="" style="background: white;">
1. Use BIGINT UNSIGNED NOT NULL (64-bit required numeric) primary keys on every table. AUTO\_INCREMENT is fine, at least to start. You can skip this for many-to-many link tables; just put both link columns in the primary key. Having single-column, numeric primary keys makes it easier to do things like drift checking and traversing between tables. 1. Use BIGINT UNSIGNED NOT NULL (64-bit required numeric) primary keys on every table. AUTO\_INCREMENT is fine, at least to start. You can skip this for many-to-many link tables; just put both link columns in the primary key. Having single-column, numeric primary keys makes it easier to do things like drift checking and traversing between tables.