I wanted to see how small a deployable web service container could be.
package main
Unencrypted IOPs | Encrypted IOPs | Metric Name | Description | |
---|---|---|---|---|
111264 | 112404 | read iops | 90/10 700 threads r/w test | |
32454 | 33063 | read iops | 90/10 1 thread r/w test | |
110489 | 69653 | write iops | 10/90 700 threads r/w test | |
8843 | 9057 | write iops | 10/90 1 thread r/w test |
# Crunk | |
/give @p diamond_sword{display:{Name:"[{\"text\":\"Crunk\"}]",Lore:["{\"text\":\"Magic sword, second version.\"}"]},Enchantments:[{id:"bane_of_arthropods",lvl:5},{id:"fire_aspect",lvl:2147483647},{id:knockback,lvl:2},{id:looting,lvl:100},{id:sharpness,lvl:2147483647},{id:"silk_touch",lvl:1},{id:smite,lvl:2147483647},{id:sweeping,lvl:2147483647}],Unbreakable:1,Damage:0} 1 | |
# Helmut | |
/give @p chainmail_helmet{display:{Name:"[{\"text\":\"Helmut\"}]"},Enchantments:[{id:"aqua_affinity",lvl:1},{id:"blast_protection",lvl:4},{id:"fire_protection",lvl:4},{id:knockback,lvl:2},{id:"projectile_protection",lvl:2147483647},{id:protection,lvl:2147483647},{id:respiration,lvl:3},{id:thorns,lvl:2147483647}],Unbreakable:1,Damage:0,HideFlags:63} 1 | |
# Nova Sling | |
/give @p bow{display:{Name:"[{\"text\":\"Nova Sling\"}]",Lore:["{\"text\":\"A magic bow.\"}"]},Enchantments:[{id:flame,lvl:1},{id:infinity,lvl:1},{id:power,lvl:1073741823},{id:punch,lvl:2}],Unbreakable:1} 1 | |
# Diamond Gear | |
/give @p diamond_helmet{Enchantments:[{id:"a |
package main | |
import ( | |
"fmt" | |
"reflect" | |
) | |
type A struct { | |
a uint8 | |
b uint16 |
package main | |
import ( | |
"crypto/sha1" | |
"encoding/hex" | |
"log" | |
"os" | |
) | |
// Animal describes features common to all animals. |
After upgrading to 3.9.3.7537, (roughly November 14, 2017) I noticed not only a memory usage increase as expected, but a continual increase in memory used of 20% total used per month on my UAP-AC-LR. This is a clear indication of a memory leak. The upgrade did not declare any new in-memory databases or the like which could account for the usage over time.
I noticed the same problem on my SW-8-POE 60W switch. The apparent leak is about half the rate of the AP during the same time. It's less significant but still a probable indicator that there's a leak. My guess is that there's a daemon common to both platforms that is leaking memory and is less busy on the switch.
/etc/jail.conf
- add example config, using globals to DRY jail definitions
- jails need mount.procfs;
for minecraft
1. ZFS templating of a template jail
- link to FreeBSD docs on installing a jailzfs send | zfs recv
example#!/usr/bin/env ruby | |
require 'world' | |
World.instance.save! |
I hereby claim:
To claim this, I am signing this object:
ipe:dev mhix$ vagrant destroy -f && rm -fr .vagrant && vagrant up | |
==> chef-server: Forcing shutdown of VM... | |
==> chef-server: Destroying VM and associated drives... | |
Looking in /Users/mhix/Downloads and /Users/mhix/scratch/chef-server-at-scale/chef-server/omnibus/pkg for installable chef-server-core package. | |
1) /Users/mhix/Downloads/chef-server-core_12.7.0-1_amd64.deb | |
2) /Users/mhix/Downloads/chef-server-core_12.8.0+20160711131028-1_amd64.deb | |
3) /Users/mhix/Downloads/chef-server-core_12.8.0-1_amd64.deb | |
Select an image, or set the INSTALLER variable and run again: [1 - 3]: ^CExiting due to interrupt. | |
ipe:dev mhix$ vagrant destroy -f && rm -fr .vagrant && vagrant up | |
==> chef-server: VM not created. Moving on... |