- Compile the program in gcc with debug symbols enabled (
-g
) - Do NOT strip the binary
- To generate assembly code using gcc use the -S option:
gcc -S hello.c
rpm -Uvh http://www.city-fan.org/ftp/contrib/yum-repo/city-fan.org-release-2-1.rhel7.noarch.rpm | |
rpm -Uvh https://dl.fedoraproject.org/pub/epel/7/x86_64/Packages/e/epel-release-7-11.noarch.rpm | |
yum -y --enablerepo=city-fan.org update curl |
The following are examples of the four types rate limiters discussed in the accompanying blog post. In the examples below I've used pseudocode-like Ruby, so if you're unfamiliar with Ruby you should be able to easily translate this approach to other languages. Complete examples in Ruby are also provided later in this gist.
In most cases you'll want all these examples to be classes, but I've used simple functions here to keep the code samples brief.
This uses a basic token bucket algorithm and relies on the fact that Redis scripts execute atomically. No other operations can run between fetching the count and writing the new count.
#!/usr/bin/env python3 | |
# coding=utf-8 | |
import json | |
from ansible.executor.task_queue_manager import TaskQueueManager | |
from ansible.inventory import Inventory | |
from ansible.inventory.group import Group | |
from ansible.inventory.host import Host | |
from ansible.parsing.dataloader import DataLoader | |
from ansible.playbook.play import Play |
- What do Etcd, Consul, and Zookeeper do?
- Service Registration:
- Host, port number, and sometimes authentication credentials, protocols, versions numbers, and/or environment details.
- Service Discovery:
- Ability for client application to query the central registry to learn of service location.
- Consistent and durable general-purpose K/V store across distributed system.
- Some solutions support this better than others.
- Based on Paxos or some derivative (i.e. Raft) algorithm to quickly converge to a consistent state.
- Service Registration:
- Centralized locking can be based on this K/V store.
/* | |
Parallel processing with ordered output in Go | |
(you can use this pattern by importing https://github.com/MarianoGappa/parseq) | |
This example implementation is useful when the following 3 conditions are true: | |
1) the rate of input is higher than the rate of output on the system (i.e. it queues up) | |
2) the processing of input can be parallelised, and overall throughput increases by doing so | |
3) the order of output of the system needs to respect order of input | |
- if 1 is false, KISS! |
(Inspired by https://medium.com/@icanhazedit/clean-up-unused-github-rpositories-c2549294ee45#.3hwv4nxv5)
-
Open in a new tab all to-be-deleted github repositores (Use the mouse’s middle click or Ctrl + Click) https://github.com/username?tab=repositories
-
Use one tab https://chrome.google.com/webstore/detail/onetab/chphlpgkkbolifaimnlloiipkdnihall to shorten them to a list.
-
Save that list to some path
-
The list should be in the form of “ur_username\repo_name” per line. Use regex search (Sublime text could help). Search for ' |.*' and replace by empty.
[Unit] | |
Description=supervisord - Supervisor process control system for UNIX | |
Documentation=http://supervisord.org | |
After=network.target | |
[Service] | |
Type=forking | |
ExecStart=/bin/supervisord -c /etc/supervisord/supervisord.conf | |
ExecReload=/bin/supervisorctl reload | |
ExecStop=/bin/supervisorctl shutdown |
The standard way of understanding the HTTP protocol is via the request reply pattern. Each HTTP transaction consists of a finitely bounded HTTP request and a finitely bounded HTTP response.
However it's also possible for both parts of an HTTP 1.1 transaction to stream their possibly infinitely bounded data. The advantages is that the sender can send data that is beyond the sender's memory limit, and the receiver can act on