Containers are not usually associated with GUI applications, but there may be times when one might still want to run such a program inside a container, for example to isolate the application's dependencies. Installing a GUI application in a container means that not only the application, but also all its specific dependencies are encapsulated inside the container (respectively, the container image), and can therefore reliably be removed from the system in a single step.
The primary challenge is to let a container communicate with the host's display system, so that it can create GUI windows on the host. A GUI application will likely also need to share files with the host system, which in turn requires the appropriate user permissions.
In this example, I will use the pinta paint program, which requires the Mono runtime. I do not use any other programs that depend on Mono, and as I like to keep my system installation re
| a4b.amazonaws.com | |
| access-analyzer.amazonaws.com | |
| account.amazonaws.com | |
| acm-pca.amazonaws.com | |
| acm.amazonaws.com | |
| airflow-env.amazonaws.com | |
| airflow.amazonaws.com | |
| alexa-appkit.amazon.com | |
| alexa-connectedhome.amazon.com | |
| amazonmq.amazonaws.com |
| #!/usr/bin/env python3 | |
| # -*- coding: utf-8 -*- | |
| # https://toster.ru/q/72866 | |
| # How to | |
| # wget http://gist.github.com/... | |
| # chmod +x ya.py | |
| # ./ya.py download_url path/to/directory | |
| import os, sys, json |
Sometimes you want to commit a subfolder on an arbitrary branch (rather than gh-pages branch) as the root directory
to the gh-pages branch.
You will want to do so when, for example, the files to be published on GitHub Pages are generated by a build system.
This document shows the way to commit a build/gh-pages directory to the gh-pages branch by using Git plumbing commands.
In the following example, Windows PowerShell is used as a shell environment.
| // ==UserScript== | |
| // @name Zoom | |
| // @namespace Flash | |
| // @include * | |
| // @version 1 | |
| // @grant none | |
| // @run-at document-start | |
| // ==/UserScript== | |
| /* |
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
These are my notes basically. At first i created this gist just as a reminder for myself. But feel free to use this for your project as a starting point. If you have questions you can find me on twitter @thomasf https://twitter.com/thomasf This is how i used it on a Debian Wheezy testing (https://www.debian.org/releases/testing/)
Discuss, ask questions, etc. here https://news.ycombinator.com/item?id=7445545
L1 cache reference ......................... 0.5 ns
Branch mispredict ............................ 5 ns
L2 cache reference ........................... 7 ns
Mutex lock/unlock ........................... 25 ns
Main memory reference ...................... 100 ns
Compress 1K bytes with Zippy ............. 3,000 ns = 3 µs
Send 2K bytes over 1 Gbps network ....... 20,000 ns = 20 µs
SSD random read ........................ 150,000 ns = 150 µs
Read 1 MB sequentially from memory ..... 250,000 ns = 250 µs