An analysis of Censys Public Scan 20180807 (only port 22) to estimate the number of servers {potentially} vulnerable to the recent Libssh bug.
| import os, sys | |
| from imgurpython import ImgurClient | |
| client_id = os.environ['IMGUR_ID'] | |
| client_secret = os.environ['IMGUR_SECRET'] | |
| if not client_id and client_secret: | |
| print 'Export IMGUR_ID and IMGUR_SECRET before running' | |
| sys.exit() |
| Install i3-gaps on Ubuntu 16 | |
| apt-get install libxcb1-dev libxcb-keysyms1-dev libpango1.0-dev libxcb-util0-dev libxcb-icccm4-dev libyajl-dev libstartup-notification0-dev libxcb-randr0-dev libev-dev libxcb-cursor-dev libxcb-xinerama0-dev libxcb-xkb-dev libxkbcommon-dev libxkbcommon-x11-dev autoconf xutils-dev dh-autoreconf | |
| git clone --recursive https://github.com/Airblader/xcb-util-xrm.git | |
| cd xcb-util-xrm/ | |
| ./autogen.sh | |
| make | |
| sudo make install |
This gist had a far larger impact than I imagined it would, and apparently people are still finding it, so a quick update:
- TC39 is currently moving forward with a slightly different version of TLA, referred to as 'variant B', in which a module with TLA doesn't block sibling execution. This vastly reduces the danger of parallelizable work happening in serial and thereby delaying startup, which was the concern that motivated me to write this gist
- In the wild, we're seeing
(async main(){...}())as a substitute for TLA. This completely eliminates the blocking problem (yay!) but it's less powerful, and harder to statically analyse (boo). In other words the lack of TLA is causing real problems - Therefore, a version of TLA that solves the original issue is a valuable addition to the language, and I'm in full support of the current proposal, which you can read here.
I'll leave the rest of this document unedited, for archaeological
It's now here, in The Programmer's Compendium. The content is the same as before, but being part of the compendium means that it's actively maintained.
Once in a while, you may need to cleanup resources (containers, volumes, images, networks) ...
// see: https://github.com/chadoe/docker-cleanup-volumes
$ docker volume rm $(docker volume ls -qf dangling=true)
$ docker volume ls -qf dangling=true | xargs -r docker volume rm
Picking the right architecture = Picking the right battles + Managing trade-offs
- Clarify and agree on the scope of the system
- User cases (description of sequences of events that, taken together, lead to a system doing something useful)
- Who is going to use it?
- How are they going to use it?
| const I = x => x | |
| const K = x => y => x | |
| const A = f => x => f (x) | |
| const T = x => f => f (x) | |
| const W = f => x => f (x) (x) | |
| const C = f => y => x => f (x) (y) | |
| const B = f => g => x => f (g (x)) | |
| const S = f => g => x => f (x) (g (x)) | |
| const S_ = f => g => x => f (g (x)) (x) | |
| const S2 = f => g => h => x => f (g (x)) (h (x)) |
All of the below properties or methods, when requested/called in JavaScript, will trigger the browser to synchronously calculate the style and layout*. This is also called reflow or layout thrashing, and is common performance bottleneck.
Generally, all APIs that synchronously provide layout metrics will trigger forced reflow / layout. Read on for additional cases and details.
elem.offsetLeft,elem.offsetTop,elem.offsetWidth,elem.offsetHeight,elem.offsetParent
This is the follow up to a post I wrote recently called From Require.js to Webpack - Party 1 (the why) which was published in my personal blog.
In that post I talked about 3 main reasons for moving from require.js to webpack:
- Common JS support
- NPM support
- a healthy loader/plugin ecosystem.
Here I'll instead talk about some of the technical challenges that we faced during the migration. Despite the clear benefits in developer experience (DX) the setup was fairly difficult and I'd like to cover some of the challanges we faced to make the transition a bit easier.