A common and reliable pattern in service unit files is thus:
NoNewPrivileges=yes
PrivateTmp=yes
PrivateDevices=yes
DevicePolicy=closed
ProtectSystem=strict
A running example of the code from:
This gist creates a working example from blog post, and a alternate example using simple worker pool.
TLDR: if you want simple and controlled concurrency use a worker pool.
#!/bin/sh | |
PREREQ="dropbear" | |
prereqs() { | |
echo "$PREREQ" | |
} | |
case "$1" in | |
prereqs) |
FROM --platform=${BUILDPLATFORM:-linux/amd64} golang:1.16 as builder | |
ARG TARGETPLATFORM | |
ARG BUILDPLATFORM | |
ARG TARGETOS | |
ARG TARGETARCH | |
WORKDIR /app/ | |
ADD . . | |
RUN CGO_ENABLED=0 GOOS=${TARGETOS} GOARCH=${TARGETARCH} go build -ldflags="-w -s" -o yourapplication main.go |
service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval
(in minutes)service.beta.kubernetes.io/aws-load-balancer-access-log-enabled
(true|false)service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name
service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix
service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags
(comma-separated list of key=value)service.beta.kubernetes.io/aws-load-balancer-backend-protocol
(http|https|ssl|tcp)service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled
(true|false)Hi. My name is Sadayuki "Sada" Furuhashi. I am the author of the MessagePack serialization format as well as its implementation in C/C++/Ruby.
Recently, MessagePack made it to the front page of Hacker News with this blog entry by Olaf, the creator of the Facebook game ZeroPilot. In the comment thread, there were several criticisms for the blog post as well as MessagePack itself, and I thought this was a good opportunity for me to address the questions and share my thoughts.
To the best of my understanding, roughly speaking, the criticisms fell into the following two categories.
RDBMS-based job queues have been criticized recently for being unable to handle heavy loads. And they deserve it, to some extent, because the queries used to safely lock a job have been pretty hairy. SELECT FOR UPDATE followed by an UPDATE works fine at first, but then you add more workers, and each is trying to SELECT FOR UPDATE the same row (and maybe throwing NOWAIT in there, then catching the errors and retrying), and things slow down.
On top of that, they have to actually update the row to mark it as locked, so the rest of your workers are sitting there waiting while one of them propagates its lock to disk (and the disks of however many servers you're replicating to). QueueClassic got some mileage out of the novel idea of randomly picking a row near the front of the queue to lock, but I can't still seem to get more than an an extra few hundred jobs per second out of it under heavy load.
So, many developers have started going straight t
-- Create a group | |
CREATE ROLE readaccess; | |
-- Grant access to existing tables | |
GRANT USAGE ON SCHEMA public TO readaccess; | |
GRANT SELECT ON ALL TABLES IN SCHEMA public TO readaccess; | |
-- Grant access to future tables | |
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO readaccess; |
package main | |
import ( | |
"bufio" | |
"crypto/aes" | |
"crypto/cipher" | |
"crypto/rand" | |
"fmt" | |
"io" | |
"io/ioutil" |
#!/usr/bin/perl | |
# | |
# @file | |
# Converter tool, from Apache Common Log file to CSV. | |
# | |
# All code is released under the GNU General Public License. | |
# See COPYRIGHT.txt and LICENSE.txt. | |
# | |