In the new year, I plan on archiving the repositories below. Because I plan on only archiving the repositories, any project that depends on any of these projects will continue to work. However, I will no longer be accepting issues or pull requests and will never tag a new release.
The reality of each of the projects listed below is that I've almost completely ignored issues and pull requests for
| Accept4 SYS_ACCEPT | |
| Accept4 SYS_ACCEPT4 | |
| Accept SYS_ACCEPT | |
| Access SYS_FACCESSAT | |
| Acct SYS_ACCT | |
| AddKey SYS_ADD_KEY | |
| Adjtimex SYS_ADJTIMEX | |
| AttachLsf SYS_SETSOCKOPT | |
| Bind SYS_BIND | |
| BindToDevice SYS_SETSOCKOPT |
| // Package main is a sample macOS-app-bundling program to demonstrate how to | |
| // automate the process described in this tutorial: | |
| // | |
| // https://medium.com/@mattholt/packaging-a-go-application-for-macos-f7084b00f6b5 | |
| // | |
| // Bundling the .app is the first thing it does, and creating the DMG is the | |
| // second. Making the DMG is optional, and is only done if you provide | |
| // the template DMG file, which you have to create beforehand. | |
| // | |
| // Example use: |
When running a compose project, services are accessible both through their full name (including the project-name prefix, for example, myproject_web_1), and through their service name (as specified in the compose-file), for example web. The short name is a network-scoped alias, which means that any container connected to the same network can access the container through this name.
By default, docker-compose creates a network for each compose project (projectname_default) so that all services in the compose project can communicate. Because that network is created for each project individually, two compose project don't share the same network, and their services are isolated from other compose projects.
It's possible, however, to make compose projects (or individual services in a compose project) share the same network.
| # Generate a new pgp key: (better to use gpg2 instead of gpg in all below commands) | |
| gpg --gen-key | |
| # maybe you need some random work in your OS to generate a key. so run this command: `find ./* /home/username -type d | xargs grep some_random_string > /dev/null` | |
| # check current keys: | |
| gpg --list-secret-keys --keyid-format LONG | |
| # See your gpg public key: | |
| gpg --armor --export YOUR_KEY_ID | |
| # YOUR_KEY_ID is the hash in front of `sec` in previous command. (for example sec 4096R/234FAA343232333 => key id is: 234FAA343232333) |
| # Description: Boxstarter Script | |
| # Author: Jess Frazelle <[email protected]> | |
| # Last Updated: 2017-09-11 | |
| # | |
| # Install boxstarter: | |
| # . { iwr -useb http://boxstarter.org/bootstrapper.ps1 } | iex; get-boxstarter -Force | |
| # | |
| # You might need to set: Set-ExecutionPolicy RemoteSigned | |
| # | |
| # Run this boxstarter by calling the following from an **elevated** command-prompt: |
Just run this from your Mac terminal and it'll drop you in a container with full permissions on the Docker VM. This also works for Docker for Windows for getting in Moby Linux VM (doesn't work for Windows Containers).
docker run -it --rm --privileged --pid=host justincormack/nsenter1
more info: https://github.com/justincormack/nsenter1
I have been an aggressive Kubernetes evangelist over the last few years. It has been the hammer with which I have approached almost all my deployments, and the one tool I have mentioned (shoved down clients throats) in almost all my foremost communications with clients, and it was my go to choice when I was mocking my first startup (saharacluster.com).
A few weeks ago Docker 1.13 was released and I was tasked with replicating a client's Kubernetes deployment on Swarm, more specifically testing running compose on Swarm.
And it was a dream!
All our apps were already dockerised and all I had to do was make a few modificatons to an existing compose file that I had used for testing before prior said deployment on Kubernetes.
And, with the ease with which I was able to expose our endpoints, manage volumes, handle networking, deploy and tear down the setup. I in all honesty see no reason to not use Swarm. No mission-critical feature, or incredibly convenient really nice to have feature in Kubernetes that I'm go
| BITS 32 | |
| org 0x05000000 | |
| db 0x7F, "ELF" | |
| dd 1 | |
| dd 0 | |
| dd $$ | |
| dw 2 | |
| dw 3 | |
| dd 0x0500001B |
