A common and reliable pattern in service unit files is thus:
NoNewPrivileges=yes
PrivateTmp=yes
PrivateDevices=yes
DevicePolicy=closed
ProtectSystem=strict
AWSTemplateFormatVersion: '2010-09-09' | |
Description: Extreme Performance Tuning Benchmark Environment | |
Parameters: | |
AmiId: | |
Type: AWS::SSM::Parameter::Value<AWS::EC2::Image::Id> | |
Default: '/aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2' |
#!/usr/bin/env bash | |
set -Eeuo pipefail | |
trap cleanup SIGINT SIGTERM ERR EXIT | |
script_dir=$(cd "$(dirname "${BASH_SOURCE[0]}")" &>/dev/null && pwd -P) | |
usage() { | |
cat <<EOF | |
Usage: $(basename "${BASH_SOURCE[0]}") [-h] [-v] [-f] -p param_value arg1 [arg2...] |
This document was originally written several years ago. At the time I was working as an execution core verification engineer at Arm. The following points are coloured heavily by working in and around the execution cores of various processors. Apply a pinch of salt; points contain varying degrees of opinion.
It is still my opinion that RISC-V could be much better designed; though I will also say that if I was building a 32 or 64-bit CPU today I'd likely implement the architecture to benefit from the existing tooling.
Mostly based upon the RISC-V ISA spec v2.0. Some updates have been made for v2.2
The RISC-V ISA has pursued minimalism to a fault. There is a large emphasis on minimizing instruction count, normalizing encoding, etc. This pursuit of minimalism has resulted in false orthogonalities (such as reusing the same instruction for branches, calls and returns) and a requirement for superfluous instructions which impacts code density both in terms of size and
const fetch = require('node-fetch'), | |
FormData = require('form-data'); | |
// your gitea domain without trailing slash | |
const GITEA_DOMAIN = 'https://subdomain.domain.xyz'; | |
// you can find this variables when you visit your gitea installation | |
// open dev-tools and look in the Cookies section | |
const i_like_gitea = 'YOUR_I_LIKE_GITEA_STRING'; | |
const gitea_awesome = 'YOUR_GITEA_AWESOME_STRING'; |
#!/bin/bash -x | |
# make_arm64_rpi_kernel_debs.sh | |
# Builds arm64 debian packages from the CURRENT rpi firmware repository kernel which is installed by: | |
# sudo rpi-update | |
# This runs on an arm64 host with arm64 compilation tools... | |
# or with some sort of cross-compilation setup. | |
# Debs are put in $workdir/build | |
# | |
# This will NOT work in Raspbian unless you have an arm64 compilation | |
# environment setup. Appears to work on |
#!/bin/bash | |
### | |
### my-script — does one thing well | |
### | |
### Usage: | |
### my-script <input> <output> | |
### | |
### Options: | |
### <input> Input file to read. | |
### <output> Output file to write. Use '-' for stdout. |
SPC | |
SPC: find file | |
, switch buffer | |
. browse files | |
: MX | |
; EX | |
< switch buffer | |
` eval | |
u universal arg | |
x pop up scratch |
I just got this working so I figured I'd share what I found, since there's hardly any information about this anywhere online except an RFC, the GPG mailing list and one tutorial from the GnuPG blog.
You can use automatic key discovery with WKD (Web key directory) to make it easy for users to import your key, in GPG since version 2.1.12. Since this feature is fairly new, it isn't yet available in the current LTS release of Ubuntu (16.04; xenial), however it is available in Debian stable (stretch).
I couldn't add a DNS CERT or DANE / OPENPGPKEY record through my email service (which also hosts my nameservers). I tried making the PKA record - a foo._pka.example.com
TXT record but GPG doesn't seem to recognize it and fails; I'm still investigating why.
So the last option for self-hosted auto-discovery was WKD.
First thing I had to do was add an email address to my key. My primary UID is just my name so the key represents my identity rather