some tools for diagrams in software documentation
To limit a CPU to a certain C-state, you can pass the processor.max_cstate=X
option in the kernel
line of /boot/grub/grub.conf
.
Here we limit the system to only C-State 1:
kernel /vmlinuz-2.6.18-371.1.2.el5 ... processor.max_cstate=1
On some systems, the kernel can override the BIOS setting, and the parameter intel_idle.max_cstate=0
may be required to ensure sleep states are not entered:
#!/usr/bin/env bash | |
# names of latest versions of each package | |
export NGINX_VERSION=1.15.5 | |
export VERSION_NGINX=nginx-$NGINX_VERSION | |
export VERSION_LIBRESSL=libressl-2.8.1 | |
export VERSION_PCRE=pcre-8.42 | |
#export NPS_VERSION=1.9.32.10 | |
#export VERSION_PAGESPEED=v${NPS_VERSION}-beta | |
Password-store keeps your passwords (or any other sensitive information) saved in GnuPG encrypted files organized in ~/.password-store
. For more information about GPG, consult the GNU Privacy Handbook.
To get started, install pass
and generate a keypair.
$ brew install pass
$ gpg --gen-key
$ gpg --list-keys
jenkins-stats.py is used to generate statics for jenkins server, so far it display the plugin's usage in each job, see related stackoverflow question:how can I know whether the plugin is used by any jobs in jenkins
python-requests module is required
This post also appears on lisper.in.
Reader macros are perhaps not as famous as ordinary macros. While macros are a great way to create your own DSL, reader macros provide even greater flexibility by allowing you to create entirely new syntax on top of Lisp.
Paul Graham explains them very well in [On Lisp][] (Chapter 17, Read-Macros):
The three big moments in a Lisp expression's life are read-time, compile-time, and runtime. Functions are in control at runtime. Macros give us a chance to perform transformations on programs at compile-time. ...read-macros... do their work at read-time.
THIS GIST WAS MOVED TO TERMSTANDARD/COLORS
REPOSITORY.
PLEASE ASK YOUR QUESTIONS OR ADD ANY SUGGESTIONS AS A REPOSITORY ISSUES OR PULL REQUESTS INSTEAD!
A lot of these are outright stolen from Edward O'Campo-Gooding's list of questions. I really like his list.
I'm having some trouble paring this down to a manageable list of questions -- I realistically want to know all of these things before starting to work at a company, but it's a lot to ask all at once. My current game plan is to pick 6 before an interview and ask those.
I'd love comments and suggestions about any of these.
I've found questions like "do you have smart people? Can I learn a lot at your company?" to be basically totally useless -- everybody will say "yeah, definitely!" and it's hard to learn anything from them. So I'm trying to make all of these questions pretty concrete -- if a team doesn't have an issue tracker, they don't have an issue tracker.
I'm also mostly not asking about principles, but the way things are -- not "do you think code review is important?", but "Does all code get reviewed?".
# Add the following 'help' target to your Makefile | |
# And add help text after each target name starting with '\#\#' | |
help: ## Show this help. | |
@fgrep -h "##" $(MAKEFILE_LIST) | fgrep -v fgrep | sed -e 's/\\$$//' | sed -e 's/##//' | |
# Everything below is an example | |
target00: ## This message will show up when typing 'make help' | |
@echo does nothing |