xenophonf

Texture2D<float4> t0 : register(t0);

SamplerState s0_s : register(s0);

cbuffer cb0 : register(b0)
{
  float4 cb0[1];
}

xenophonf

#!/bin/sh

#### Run as user `ubuntu` from the Ubuntu Desktop installer's live environment.

passwd ubuntu
sudo apt install --yes openssh-server
ip addr

xenophonf

(add-to-list 'tramp-methods
 '("sudosu"
   (tramp-login-program "sudo")
   (tramp-login-args
    (("su")
     ("-")
     ("%u")))
   (tramp-remote-shell "/bin/sh")
   (tramp-remote-shell-login
    ("-l"))

xenophonf

Name:           postsrsd
Version:        1.4
Release:        3%{?dist}
Summary:       A sender-envelope rewriter to comply with SPF forwarding for postfix

License:       GPLv2+
URL:           https://github.com/roehling/postsrsd
Source0:       https://github.com/roehling/%{name}/archive/%{version}.tar.gz

BuildRequires: cmake

xenophonf

#!/usr/bin/env bash

set -x

FQDN=$1
DISK=$2
IFACE=$3

HOSTNAME=$(echo ${FQDN} | sed -e 's/\..*//')

xenophonf

<?xml version="1.0" encoding="UTF-8"?>
<AttributeFilterPolicyGroup xmlns="urn:mace:shibboleth:2.0:afp" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" id="ShibbolethFilterPolicy" xsi:schemaLocation="urn:mace:shibboleth:2.0:afp http://shibboleth.net/schema/idp/shibboleth-afp.xsd">
  <!-- release uid, cn, and upn to everyone -->
  <AttributeFilterPolicy id="_1">
    <PolicyRequirementRule xsi:type="ANY"/>
    <AttributeRule attributeID="uid">
      <PermitValueRule xsi:type="ANY"/>
    </AttributeRule>
    <AttributeRule attributeID="cn">
      <PermitValueRule xsi:type="ANY"/>

xenophonf

Recipe for running strange binaries in AWS Lambda

In general, the command ldd and the environment variable LD_LINKER_PATH is your best friend when running new, untested binaries in Lambda. My process (which I want to get around to automating one day, maybe using Packer), goes like this:

1. Run an EC2 instance with the official AWS Lambda AMI.
2. Get binary you want to run in AWS Lambda running on the instance (either by installing from a package manager or compiling). 
3. Run ldd -v ./the-binary. Note all of the shared libraries it requires. You’ll need to remember these.
4. Copy the binary to your local machine. Upload the binary with your AWS Lambda function code that runs the ldd command inside the handler function using the process execution library from your language of choice. In node, this works just fine: console.log(require('child_process').execSync('ldd -v ./the-binary'))
5. Note any shared libraries that are missing in the function output. Copy those over from the EC2 instance to a direct

xenophonf

#!/bin/sh

## kind of any ugly hack
read checkout repo upstream<<EOF
`grep '^'$1 ./forks`
EOF

## clone the repository
rm -rf $checkout
git clone $repo

xenophonf

Dual-boot Mac OS X (FileVault2) and Ubuntu (OpenZFS/LUKS)

This procedure results in a computer that runs both Mac OS X and Ubuntu in a dual-boot configuration, each operating system using full (whole) disk encryption, and with the Ubuntu root file system stored on a ZFS pool encrypted using LUKS. The specific hardware and software versions used to document this procedure are:

• MacBookPro8,2

xenophonf

Live Environment Preparation

I disabled any hardware RAID features, preferring instead to rely on ZFS. The eServer's ServeRAID controller wouldn't let me export its attached hard disk drives without creating a new single-drive RAID-0 array for each one.

FreeBSD's boot loader can access USB mass storage devices only if supported by the computer's BIOS. To test this I connected a USB flash drive to the server prior to powering it up, and then I booted the FreeBSD 9.0-RELEASE installation CD. From the boot menu I exited to the loader prompt (menu option 2) and issued the lsdev command to review the BIOS device list. In my case both servers listed only their floppy disk, CD, and hard disk drives, meaning that I couldn't boot them via USB nor could I access encryption keys stored on a USB mass storage device. (This is why I chose to boot from CD instead of USB.)

To continue with the installation, I entered the "boot" command to start FreeBSD and chose the option to use the live CD (log in as user `root