| DH_USERNAME= | |
| DH_PASSWORD= | |
| DOCKER_HUB_COOKIE="" |
This is a living document. Everything in this document is made in good faith of being accurate, but like I just said; we don't yet know everything about what's going on.
Update: I've disabled comments as of 2025-01-26 to avoid everyone having notifications for something a year on if someone wants to suggest a correction. Folks are free to email to suggest corrections still, of course.
tl;dr: Wayland is not "the future", it is merely an incompatible alternative to the established standard with a different set of priorities and goals.
Wayland breaks everything! It is binary incompatible, provides no clear transition path with 1:1 replacements for everything in X11, and is even philosophically incompatible with X11. Hence, if you are interested in existing applications to "just work" without the need for adjustments, then you may be better off avoiding Wayland.
Wayland solves no issues I have but breaks almost everything I need. Even the most basic, most simple things (like xkill) - in this case with no obvious replacement. And usually it stays broken, because the Wayland folks mostly seem to care about Automotive, Gnome, maybe KDE - and alienating e
| version: '2' | |
| services: | |
| myapp: | |
| build: . | |
| container_name: "myapp" | |
| image: debian/latest | |
| environment: | |
| - NODE_ENV=development | |
| - FOO=bar | |
| volumes: |
The new generic distributed content manifest format (schema version 2) [see distribution/distribution#62] is approaching final approval, and while some discussion has happened in-line, it seems reasonable to break out the various pieces that would be required to implement a multi-arch Docker image solution on top of the flexible manifest format being proposed.
As a starting point it is useful to discuss what the intended use case is for multi-architecture images in the Docker platform. The following requirements summarize the expected capabilities of the engine + registry + storage/retrieval format that is implemented.
name:tag manifest will need to contain the proper information for access/retrieval of multiple architectures
docker pull ubuntu:15.04 should have the capability on a POWER system to pull the POWER-specific image layers which comprise an Ubuntu 15.04 imagename:tag manifests will have information for
| def pretty_time_delta(seconds): | |
| sign_string = '-' if seconds < 0 else '' | |
| seconds = abs(int(seconds)) | |
| days, seconds = divmod(seconds, 86400) | |
| hours, seconds = divmod(seconds, 3600) | |
| minutes, seconds = divmod(seconds, 60) | |
| if days > 0: | |
| return '%s%dd%dh%dm%ds' % (sign_string, days, hours, minutes, seconds) | |
| elif hours > 0: | |
| return '%s%dh%dm%ds' % (sign_string, hours, minutes, seconds) |
| var request = require('request'); | |
| var unzip = require('unzip'); | |
| var csv2 = require('csv2'); | |
| request.get('http://s3.amazonaws.com/alexa-static/top-1m.csv.zip') | |
| .pipe(unzip.Parse()) | |
| .on('entry', function (entry) { | |
| entry.pipe(csv2()).on('data', console.log); | |
| }) | |
| ; |
| /* | |
| * I add this to html files generated with pandoc. | |
| */ | |
| html { | |
| font-size: 100%; | |
| overflow-y: scroll; | |
| -webkit-text-size-adjust: 100%; | |
| -ms-text-size-adjust: 100%; | |
| } |
| killall ssh-agent; eval `ssh-agent` |
