Jeg står overfor at skulle melde min flytning til CPR registeret, og det falder som et par andre ting, under den nye lov af d. 1 december 2012, om tvungen digital selvbetjening - så derfor fik jeg en udfordring,da hverken min kone eller jeg har tillid nok til NemID, til at have en OCES del (signatur delen) af NemID.

Jeg kan konstatere at mange jeg ellers ved har stor teknisk kompetance, slet ikke forstår hvorfor jeg ikke har OCES delen aktiveret på mit NemID - og i sidste instans en argumentation om at jeg da så bare må få det hardware token de nu (endelig) er kommet med.

read more

If you are compositing pixels with 16 bits per component, you often need this computation:

uint16_t a, b, r;

r = (a * b + 0x7fff) / 65535;

There is a well-known way to do this quickly without a division:

uint32_t t;

t = a * b + 0x8000;

r = (t + (t >> 16)) >> 16;

Since we are compositing pixels we want to do this with SSE2 instructions, but because the code above uses 32 bit arithmetic, we can only do four operations at a time, even though SSE registers have room for eight 16 bit values. Here is a direct translation into SSE2:

a = punpcklwd (a, 0);
b = punpcklwd (b, 0);
a = pmulld (a, b);
a = paddd (a, 0x8000);
b = psrld (a, 16);
a = paddd (a, b);
a = psrld (a, 16);
a = packusdw (a, 0);

But there is another way that better matches SSE2:

uint16_t lo, hi, t, r;

hi = (a * b) >> 16;
lo = (a * b) & 0xffff;

t = lo >> 15;
hi += t;
t = hi ^ 0x7fff;

if ((int16_t)lo > (int16_t)t)
    lo = 0xffff;
else
    lo = 0x0000;

r = hi - lo;

This version is better because it avoids the unpacking to 32 bits. Here is the translation into SSE2:

t = pmulhuw (a, b);
a = pmullw (a, b);
b = psrlw (a, 15);
t = paddw (t, b);
b = pxor (t, 0x7fff);
a = pcmpgtw (a, b);
a = psubw (t, a);

This is not only shorter, it also makes use of the full width of the SSE registers, computing eight results at a time.

Unfortunately SSE2 doesn’t have 8-bit variants of pmulhuw, pmullw, and psrlw, so we can’t use this trick for the more common case where pixels have 8 bits per component.

Exercise: Why does the second version work?

A new version 1.1.8 of Sysprof is out.

This is a release candidate for 1.2.0 and contains mainly bug fixes.

Pixels with 8 bits per channel are normally sRGB encoded because that allocates more bits to darker colors where human vision is the most sensitive. (Actually, it’s really more of a historical accident, but sRGB nevertheless remains useful for this reason). The relationship between sRGB and linear RGB is that you get an sRGB pixel by raising each component of a linear pixel to the power of $1/2.2$.

A lot of graphics software does alpha blending directly on these sRGB pixels using alpha values that are linearly coded (ie., an alpha value of 0 means no coverage, 0.5 means half coverage, and 1 means full coverage). Because alpha blending is best done with premultiplied pixels, such systems store pixels in this format:

[ alpha,  alpha * red_s,  alpha * green_s,  alpha * blue_s ]

where alpha is linearly coded, and (red_s, green_s, blue_s) are sRGB coded. As long as you are happy with blending in sRGB, this works well. Also, if you simply discard the alpha channel of such pixels and display them directly on a monitor, it will look as if the pixels were alpha blended (in the sRGB space) on top of a black background, which is the desired result.

But what if you want to blend in linear RGB? If you use the format above, some expensive conversions will be required. To convert to premultiplied linear, you have to first divide by alpha, then raise each color to 2.2, then multiply by alpha. To convert back, you must divide by alpha, raise to $1/2.2$, then multiply with alpha.

The conversions can be avoided if you store the pixels linearly, ie., keeping the premultiplication, but coding red, green, and blue linearly instead of as sRGB. This makes blending fast, but the downside is that you need deeper pixels. With only 8 bits per pixel, the linear coding loses too much precision in darker tones. Another problems is that to display these pixels, you will either have to convert them to sRGB, or if the video card can scan them out directly, you have to make sure that the gamma ramp is set to compensate for the fact that the monitor expects sRGB pixels.

Can we get the best of both worlds? Yes. The format to use is this:

[ alpha,  alpha_s * red_s,  alpha_s * green_s,  alpha_s * blue_s ]

That is, the alpha channel is stored linearly, and the color channels are stored in sRGB, premultiplied with the alpha value raised to 1/2.2. Ie., the red component is now

(red * alpha)^(1/2.2),

where before it was

alpha * red^(1/2.2).

It is sufficient to use 8 bits per channel with this format because of the sRGB encoding. Discarding the alpha channel and displaying the pixels on a monitor will produce pixels that are alpha blended (in linear space) against black, as desired.

You can convert to linear RGB simply by raising the R, G, and B components to 2.2, and back by raising to $1/2.2$. Or, if you feel like cheating, use an exponent of 2 so that the conversions become a multiplication and a square root respectively.

This is also the pixel format to use with texture samplers that implement the sRGB OpenGL extensions (textures and framebuffers). These extensions say precisely that the R, G, and B components are raised to 2.2 before texture filtering, and raised to 1/2.2 after the final raster operation.

The ">">Porter/Duff Over operator, also known as the “Normal” blend mode in Photoshop, computes the amount of light that is reflected when a pixel partially covers another:

The fraction of bg that is covered is denoted alpha. This operator is the correct one to use when the foreground image is an opaque mask that partially covers the background:

A photon that hits this image will be reflected back to your eyes by either the foreground or the background, but not both. For each foreground pixel, the alpha value tells us the probability of each:

$a \cdot \text{fg} + (1 - a) \cdot \text{bg}$

This is the definition of the Porter/Duff Over operator for non-premultiplied pixels.

But if alpha is interpreted as translucency, then the Over operator is not the correct one to use. The Over operator will act as if each pixel is partially covering the background:

Which is not how translucency works. A translucent material reflects some light and lets other light through. The light that is let through is reflected by the background and interacts with the foreground again.

Let’s look at this in more detail. Please follow along in the diagram to the right. First with probability $a$, the photon is reflected back towards the viewer:

$a \cdot \text{fg}$

With probability $(1 - a)$, it passes through the foreground, hits the background, and is reflected back out. The photon now hits the backside of the foreground pixel. With probability $(1 - a)$, the foreground pixel lets the photon back out to the viewer. The result so far:

$ \begin{align*} &a\cdot \text{fg} \\ +&(1 - a) \cdot \text{bg} \cdot (1 - a) \end{align*} $

But we are not done yet, because with probability $a$ the foreground pixel reflects the photon once again back towards the background pixel. There it will be reflected, hit the backside of the foreground pixel again, which lets it through to our eyes with probability $(1 - a)$. We get another term where the final $(1 - a)$ is replaced with $a \cdot \text{fg} \cdot \text {bg} \cdot (1 - a)$:

$ \begin{align*} &a\cdot \text{fg} \\ +&(1 - a) \cdot \text{bg} \cdot (1 - a)\\ +&(1 - a) \cdot \text{bg} \cdot a \cdot \text{fg} \cdot \text{bg} \cdot (1 - a) \end{align*} $

And so on. In each round, we gain another term which is identical to the previous one, except that it has an additional $a \cdot \text{fg} \cdot \text{bg}$ factor:

$ \begin{align*} &a\cdot \text{fg} \\ +&(1 - a) \cdot \text{bg} \cdot (1 - a)\\ +&(1 - a) \cdot \text{bg} \cdot a \cdot \text{fg} \cdot \text{bg} \cdot (1 - a)\\ +&(1 - a) \cdot \text{bg} \cdot a \cdot \text{fg} \cdot \text{bg} \cdot a \cdot \text{fg} \cdot \text{bg} \cdot (1 - a) \\ +&\cdots \end{align*} $

or more compactly:

$\displaystyle a \cdot \text{fg} + (1 - a)^2 \cdot \text{bg} \cdot \sum_{i=0}^\infty (a \cdot \text{fg} \cdot \text{bg})^i $

Because we are dealing with pixels, both $a$, $\text{fg}$, and $\text{bg}$ are less than 1, so the sum is a geometric series:

$\displaystyle \sum_{i=0}^\infty x^i = \frac{1}{1 - x} $

Putting them together, we get:

$\displaystyle a \cdot \text{fg} + \frac{(1 - a)^2 \cdot bg}{1 - a \cdot \text{fg} \cdot \text{bg}} $

I have sidestepped the issue of premultiplication by assuming that background alpha is 1. The calculations with premultipled colors are similar, and for the color components, the result is simply:

$\displaystyle r = \text{fg} + \frac{(1 - a_\text{fg})^2 \cdot \text{bg}}{1 - \text{fg}\cdot\text{bg}} $

The issue of destination alpha is more complicated. With the Over operator, both foreground and background are opaque masks, so the light that survives both has the same color as the input light. With translucency, the transmitted light has a different color, which means the resulting alpha value must in principle be different for each color component. But that’s not possible for ARGB pixels. A similar argument to the above shows that the resulting alpha value would be:

$\displaystyle r = 1 - \frac{(1 - a)\cdot (1 - b)}{1 - \text{fg} \cdot \text{bg}} $

where $b$ is the background alpha. The problem is the dependency on $\text{fg}$ and $\text{bg}$. If we simply assume for the purposes of the alpha computation that $\text{fg}$ and $\text{bg}$ are equal to $a$ and $b$, we get this:

$\displaystyle r = 1 - \frac{(1 - a)\cdot (1 - b)}{1 - a \cdot b} $

which is equal to

$\displaystyle a + \frac{(1 - a)^2 \cdot b}{1 - a \cdot b} $

Ie., exactly the same computation as the one for the color channels. So we can define the Translucency Operator as this:

$\displaystyle r = \text{fg} + \frac{(1 - a)^2 \cdot \text{bg}}{1 - \text{fg} \cdot \text{bg}} $

for all four channels.

Here is an example of what the operator looks like. The image below is what you will get if you use the Over operator to implement a selection rectangle. Mouse over to see what it would look like if you used the Translucency operator.

Both were computed in linear RGB. Typical implementations will often compute the Over operator in sRGB, so that’s what see if you actually select some icons in Nautilus. If you want to compare all three, open these in tabs:

Over, in sRGB

Translucency, in linear RGB

Over, in linear RGB

And for good measure, even though it makes zero sense to do this,

Translucency, in sRGB

A new stable releasenew stable release of Sysprof is now available. Download version 1.2.0.

In computer science and sometimes mathematics, big-O notation is used to talk about how quickly a function grows while disregarding multiplicative and additive constants. When classifying algorithms, big-O notation is useful because it lets us abstract away the differences between real computers as just multiplicative and additive constants.

Big-O is not a difficult concept at all, but it seems to be common even for people who should know better to misunderstand some aspects of it. The following is a list of misconceptions that I have seen in the wild.

But first a definition: We write

$f(n) = O(g(n))$

when $f(n) \le M g(n)$ for sufficiently large $n$, for some positive constant $M$.

Misconception 1: “The Equals Sign Means Equality”

The equals sign in

$f(n) = O(g(n))$

is a widespread travestry. If you take it at face value, you can deduce that since $5 n$ and $3 n$ are both equal to $O(n)$, then $3 n$ must be equal to $5 n$ and so $3 = 5$.

The expression $f(n) = O(g(n))$ doesn’t type check. The left-hand-side is a function, the right-hand-side is a … what, exactly? There is no help to be found in the definition. It just says “we write” without concerning itself with the fact that what “we write” is total nonsense.

The way to interpret the right-hand side is as a set of functions:

$ O(f) = \{ g \mid g(n) \le M f(n) \text{ for some \(M > 0\) for large \(n\)}\}. $

With this definition, the world makes sense again: If $f(n) = 3 n$ and $g(n) = 5 n$, then $f \in O(n)$ and $g \in O(n)$, but there is no equality involved so we can’t make bogus deductions like $3=5$. We can however make the correct observation that $O(n) \subseteq O(n \log n)\subseteq O(n^2) \subseteq O(n^3)$, something that would be difficult to express with the equals sign.

Misconception 2: “Informally, Big-O Means ‘Approximately Equal’"

If an algorithm takes $5 n^2$ seconds to complete, that algorithm is $O(n^2)$ because for the constant $M=7$ and sufficiently large $n$, $5 n^2 \le 7 n^2$. But an algorithm that runs in constant time, say 3 seconds, is also $O(n^2)$ because for sufficiently large $n$, $3 \le n^2$.

So informally, big-O means approximately less than or equal, not approximately equal.

If someone says “Topological Sort, like other sorting algorithms, is $O(n \log n)$", then that is technically correct, but severely misleading, because Toplogical Sort is also $O(n)$ which is a subset of $O(n \log n)$. Chances are whoever said it meant something false.

If someone says “In the worst case, any comparison based sorting algorithm must make $O(n \log n)$ comparisons” that is not a correct statement. Translated into English it becomes:

“In the worst case, any comparison based sorting algorithm must make fewer than or equal to $M n \log (n)$ comparisons”

which is not true: You can easily come up with a comparison based sorting algorithm that makes more comparisons in the worst case.

To be precise about these things we have other types of notation at our disposal. Informally:

$O()$:	Less than or equal, disregarding constants
$\Omega()$:	Greater than or equal, disregarding constants
$o()$:	Stricly less than, disregarding constants
$\Theta()$:	Equal to, disregarding constants

and some more. The correct statement about lower bounds is this: “In the worst case, any comparison based sorting algorithm must make $\Omega(n \log n)$ comparisons. In English that becomes:

“In the worst case, any comparison based sorting algorithm must make at least $M n \log (n)$ comparisons”

which is true. And a correct, non-misleading statement about Topological Sort is that it is $\Theta(n)$, because it has a lower bound of $\Omega(n)$ and an upper bound of $O(n)$.

Misconception 3: “Big-O is a Statement About Time”

Big-O is used for making statements about functions. The functions can measure time or space or cache misses or rabbits on an island or anything or nothing. Big-O notation doesn’t care.

In fact, when used for algorithms, big-O is almost never about time. It is about primitive operations.

When someone says that the time complexity of MergeSort is $O(n \log n)$, they usually mean that the number of comparisons that MergeSort makes is $O(n \log n)$. That in itself doesn’t tell us what the time complexity of any particular MergeSort might be because that would depend how much time it takes to make a comparison. In other words, the $O(n \log n)$ refers to comparisons as the primitive operation.

The important point here is that when big-O is applied to algorithms, there is always an underlying model of computation. The claim that the time complexity of MergeSort is $O(n \log n)$, is implicitly referencing an model of computation where a comparison takes constant time and everything else is free.

Which is fine as far as it goes. It lets us compare MergeSort to other comparison based sorts, such as QuickSort or ShellSort or BubbleSort, and in many real situations, comparing two sort keys really does take constant time.

However, it doesn’t allow us to compare MergeSort to RadixSort because RadixSort is not comparison based. It simply doesn’t ever make a comparison between two keys, so its time complexity in the comparison model is 0. The statement that RadixSort is $O(n)$ implicitly references a model in which the keys can be lexicographically picked apart in constant time. Which is also fine, because in many real situations, you actually can do that.

To compare RadixSort to MergeSort, we must first define a shared model of computation. If we are sorting strings that are $k$ bytes long, we might take “read a byte” as a primitive operation that takes constant time with everything else being free.

In this model, MergeSort makes $O(n \log n)$ string comparisons each of which makes $O(k)$ byte comparisons, so the time complexity is $O(k\cdot n \log n)$. One common implementation of RadixSort will make $k$ passes over the $n$ strings with each pass reading one byte, and so has time complexity $O(n k)$.

Misconception 4: Big-O Is About Worst Case

Big-O is often used to make statements about functions that measure the worst case behavior of an algorithm, but big-O notation doesn’t imply anything of the sort.

If someone is talking about the randomized QuickSort and says that it is $O(n \log n)$, they presumably mean that its expected running time is $O(n \log n)$. If they say that QuickSort is $O(n^2)$ they are probably talking about its worst case complexity. Both statements can be considered true depending on what type of running time the functions involved are measuring.

In the Porter/Duff compositing algebra, images are equipped with an alpha channel that determines on a per-pixel basis whether the image is there or not. When the alpha channel is 1, the image is fully there, when it is 0, the image isn’t there at all, and when it is in between, the image is partially there. In other words, the alpha channel describes the shape of the image, it does not describe opacity. The way to think of images with an alpha channel is as irregularly shaped pieces of cardboard, not as colored glass. Consider these two images:

When we combine them, each pixel of the result can be divided into four regions:

One region where only the source is present, one where only the destination is present, one where both are present, and one where neither is present.

By deciding on what happens in each of the four regions, various effects can be generated. For example, if the destination-only region is treated as blank, the source-only region is filled with the source color, and the ‘both’ region is filled with the destination color like this:

The effect is as if the destination image is trimmed to match the source image, and then held up in front of it:

The Porter/Duff operator that does this is called “Dest Atop”.

There are twelve of these operators, each one characterized by its behavior in the three regions: source, destination and both. The ‘neither’ region is always blank. The source and destination regions can either be blank or filled with the source or destination colors respectively.

The formula for the operators is a linear combination of the contents of the four regions, where the weights are the areas of each region:

$A_\text{src} \cdot [s] + A_\text{dest} \cdot [d] + A_\text{both} \cdot [b]$

Where $[s]$ is either 0 or the color of the source pixel, $[d]$ either 0 or the color of the destination pixel, and $[b]$ is either 0, the color of the source pixel, or the color of the destination pixel. With the alpha channel being interpreted as coverage, the areas are given by these formulas:

$A_\text{src} = \alpha_\text{s} \cdot (1 - \alpha_\text{d})$
$A_\text{dst} = \alpha_\text{d} \cdot (1 - \alpha_\text{s})$
$A_\text{both} = \alpha_\text{s} \cdot \alpha_\text{d}$

The alpha channel of the result is computed in a similar way:

$A_\text{src} \cdot [\text{as}] + A_\text{dest} \cdot [\text{ad}] + A_\text{both} \cdot [\text{ab}]$

where $[\text{as}]$ and $[\text{ad}]$ are either 0 or 1 depending on whether the source and destination regions are present, and where $[\text{ab}]$ is 0 when the ‘both’ region is blank, and 1 otherwise.

Here is a table of all the Porter/Duff operators:

And here is how they look:

Despite being referred to as alpha blending and despite alpha often being used to model opacity, in concept Porter/Duff is not a way to blend the source and destination shapes. It is way to overlay, combine and trim them as if they were pieces of cardboard. The only places where source and destination pixels are actually blended is where the antialiased edges meet.

Blending
Photoshop and the Gimp have a concept of layers which are images stacked on top of each other. In Porter/Duff, stacking images on top of each other is done with the “Over” operator, which is also what Photoshop/Gimp use by default to composite layers:

Conceptually, two pieces of cardboard are held up with one in front of the other. Neither shape is trimmed, and in places where both are present, only the top layer is visible.

A layer in these programs also has an associated Blend Mode which can be used to modify what happens in places where both are visible. For example, the ‘Color Dodge’ blend mode computes a mix of source and destination according to this formula:

$ \begin{equation*} B(s,d)= \begin{cases} 0 & \text{if \(d=0\),} \\ 1 & \text{if \(d \ge (1 - s)\),} \\ d / (1 - s) & \text{otherwise} \end{cases} \end{equation*} $

The result is this:

Unlike with the regular Over operator, in this case there is a substantial chunk of the output where the result is actually a mix of the source and destination.

Layers in Photoshop and Gimp are not tailored to each other (except for layer masks, which we will ignore here), so the compositing of the layer stack is done with the source-only and destination-only region set to source and destination respectively. However, there is nothing in principle stopping us from setting the source-only and destination-only regions to blank, but keeping the blend mode in the ‘both’ region, so that tailoring could be supported alongside blending. For example, we could set the ‘source’ region to blank, the ‘destination’ region to the destination color, and the ‘both’ region to ColorDodge:

Here are the four combinations that involve a ColorDodge blend mode:

In this model the original twelve Porter/Duff operators can be viewed as the results of three simple blend modes:

In this generalization of Porter/Duff the blend mode is chosen from a large set of formulas, and each formula gives rise to four new compositing operators characterized by whether the source and destination are blank or contain the corresponding pixel color.

Here is a table of the operators that are generated by various blend modes:

The general formula is still an area weighted average:

$A_\text{src} \cdot [s] + A_\text{dest} \cdot [d] + A_\text{both}\cdot B(s, d)$

where [s] and [d] are the source and destination colors respectively or 0, but where $B(s, d)$ is no longer restricted to one of $0$, $s$, and $d$, but can instead be chosen from a large set of formulas.

The output of the alpha channel is the same as before:

$A_\text{src} \cdot [\text{as}] + A_\text{dest} \cdot [\text{ad}] + A_\text{both} \cdot [\text{ab}]$

except that [ab] is now determined by the blend mode. For the Zero blend mode there is no coverage in the both region, so [ab] is 0; for most others, there is full coverage, so [ab] is 1.

I anledning af 100 års-jubilæet for Herning som købstad har BON’A PARTE deltaget i et projekt med en række andre virksomheder og institutioner. Et projekt der skulle resultere i verdens højeste modeshow.

En australsk kunstnergruppe har benyttet en af vores haller til at lære en masse studerende fra TEKO Designskole at bygge 4 meter høje dukker, der fredag den 3. maj skulle gå catwalk i Herning. De studerende har bygget 10 dukker der repræsenterer 10 tekstilvirksomheder fra Herning-regionen, som udover BON’A PARTE også tæller virksomheder som JBS, Egetæpper, KABOOKI m.fl.

Se regionalt indslag fra begivenheden her:

http://www.tvmidtvest.dk/nettv/?id=24517

table <spamd-white> persist
table <nospamd> persist file "/etc/mail/nospamd"
pass in on egress proto tcp from any to any port smtp \
        rdr-to 127.0.0.1 port spamd
pass in on egress proto tcp from <nospamd> to any port smtp
pass in log on egress proto tcp from <spamd-white> to any port smtp
pass out log on egress proto tcp to any port smtp

table <spamd-white> persist
table <nospamd> persist file "/etc/mail/nospamd"
no rdr inet proto tcp from <spamd-white> to any \
       port smtp
rdr pass inet proto tcp from any to any \
       port smtp -> 127.0.0.1 port spamd

$ sudo /usr/libexec/spamd

$ sudo /usr/local/libexec/spamd

"My admin told me not to talk to strangers"

1. sender's IP address
2. the From: address
3. the To: address
4. time of first delivery attempt matching 1) through 3)
5. time delivery of retry will be allowed
6. time to live for the current entry

"if we have one or more addresses that we are quite sure will never receive valid email, we can safely assume that any mail sent to those addresses is spam"

Jan 16 19:55:50 skapet spamd[27153]: 82.174.96.131: connected (3/2), lists: uatraps
Jan 16 19:59:33 skapet spamd[27153]: (BLACK) 82.174.96.131: <bryonRoe@boxerdelasgargolas.com> -> <schurkoxektk@ehtrib.org>
Jan 16 20:01:17 skapet spamd[27153]: 82.174.96.131: From: "bryon Roe" <bryonRoe@boxerdelasgargolas.com>
Jan 16 20:01:17 skapet spamd[27153]: 82.174.96.131: To: schurkoxektk@ehtrib.org
Jan 16 20:01:17 skapet spamd[27153]: 82.174.96.131: Subject: vresdiam
Jan 16 20:02:33 skapet spamd[27153]: 82.174.96.131: disconnected after 403 seconds. lists: uatraps

$ sudo spamdb

$ sudo spamdb -a 192.168.110.12

$ sudo spamdb -d 192.168.110.12

$ sudo spamdb -T -a wkitp98zpu.fsf@datadok.no

Jul 13 14:36:50 delilah spamd[29851]: 212.154.213.228: Subject: Considered UNSOLICITED BULK EMAIL, apparently from you
Jul 13 14:36:50 delilah spamd[29851]: 212.154.213.228: From: "Content-filter at srv77.kit.kz" <postmaster@srv77.kit.kz>
Jul 13 14:36:50 delilah spamd[29851]: 212.154.213.228: To: <skulkedq58@datadok.no>

1. Spammers, one or more groups, are generating numerous fake and nondeliverable addresses in our domains.
2. adding those generated addresses to our local list of spamtraps is mainly a matter of extracting them from our logs
3. if we could make the spammers include those addresses in their To: addresses, too, it gets even easier to stop incoming spam and shift the spammers to the one-byte-at-a-time tarpit. Putting the trap addresses on a web page we link to from the affected domains' home pages will attract the address slurping robots sooner or later.

$ sudo spamdb | grep GREY

GREY|96.225.75.144|Wireless_Broadband_Router|<aguhjwilgxj@bn.camcom.it>|<bsdly@bsdly.net>|1198745212|1198774012|1198774012|1|0
GREY|206.65.163.8|outbound4.bluetie.com|<>|<leonard159@datadok.no>|1198752854|1198781654|1198781654|3|0
GREY|217.26.49.144|mxin005.mail.hostpoint.ch|<>|<earle@datadok.no>|1198753791|1198782591|1198782591|2|0

$ sudo spamdb | grep "<>" | awk -F\| '{print $5}' |  tr -d '<>' | sort | uniq

earle@datadok.no
leonard159@datadok.no

# spamdb | grep GREY | awk -F\| '{print $4}' | grep mydomain.tld |  tr -d '<>' | sort | uniq 

"earlier this month the address capitalgain02@gmail.com 

 started appearing frequently enough that it caught my 

 attention in my greylist dumps and log files.

 The earliest contact as far as I can see was at 

 Nov 10 14:30:57, trying to spam wkzp0jq0n6.fsf@datadok.no 

 from 193.252.22.241 (apparently a France Telecom customer). 

 The last attempt seems to have been ten days later, at 

 Nov 20 15:20:31, from the Swedish machine 217.10.96.36.

 My logs show me that during that period 6531 attempts 

 had been made to deliver mail from capitalgain02@gmail.com 

 via bsdly.net, from 35 different IP addresses, to 131 different 

 recipients in our domains. Those recipients included three 

 deliverable addresses, mine or aliases I receive mail for. 

 None of those attempts actually succeeded, of course."

Vi er i FULD gang med at udvikle en Magento-løsning til at erstatte den nuværende webshop, som kommer til at blive en af skandinaviens største Magento-baserede webshops, når vi har migreret alle lande.

Vi søger derfor en person til en kort projektansættelse på 3 måneder. Vi kan ikke love, at det vil blive til en fuldtidsansættelse bagefter, men i det mindste kan du blive en del af et helt vildt spændende projekt.

Du skal virkelig kende Magento som din egen baglomme; du behøver ikke være programmør, men du skal kunne forstå det tekniske.

Kontakt Claus på chy@bonaparte.dk

Tidsfrist er NU, og du vil kunne starte I MORGEN!

$ cd /usr/ports/misc screen

$ls -l

total 20
drwxr-xr-x  2 root  wheel   512 Mar 31 16:46 CVS
-rw-r--r--  1 root  wheel  1047 Mar 28 17:34 Makefile
-rw-r--r--  1 root  wheel   283 Apr  5  2007 distinfo
drwxr-xr-x  3 root  wheel   512 Jun 26  2012 patches
drwxr-xr-x  3 root  wheel   512 Mar 11  2012 pkg

.include <bsd.port.mk>

$ sudo make install 

$ pkg_info | grep screen
screen-4.0.3p3      multi-screen window manager

PKG_PATH=ftp://ftp.eu.openbsd.org/pub/OpenBSD/snapshots/packages/`uname -m`/

PKG_PATH=ftp://ftp.eu.openbsd.org/pub/OpenBSD/`uname -r`/packages/`uname -m`/

$ sudo pkg_add screen

$ sudo pkg_add -vui

$ make search key=mykeyword

This week the founder of the GNU project and the Free Software Foundation, Richard Stallman (RMS) gave two presentations at the Technical University of Denmark. The events were organized by KLID.

On Wednesday the topic was Copyright vs. Community. Discussing the history of copyright, how it is being extended and (mis)used, and how Richard Stallman proposes to reform copyright.

On Thursday night the topic was A Free Digital Society. Covering a wide range of topics including privacy, censorship, electronic voting, software freedom, DRM and streaming services, software patents, services as a software substitution and also the EU Unitary Patent.

Here is Stallman auctioning off a plush GNU at the end of the talk. My apologies for the poor photo.

As always it was a very interesting and entertaining experience. Video recordings were made and should be up on the KLID website before too long. If you can’t wait, you can download other audio and video recordings of Stallman’s speeches here: http://audio-video.gnu.org/

Stallman also gave away stickers and sold various other items for the support of the FSF.

On using Acme as a day-to-day text editor

Setting up acme

• Grab Plan 9 from User Space and ./INSTALL it somewhere. This gives you the basis environment, but it does require some help to get running.
• Grab Plan 9 setup which is my small tools as shell scripts to manipulate files
• I have some changes to $HOME/.profile:
  

  export BROWSER='chromium'
  PLAN9=/home/jlouis/P/plan9
  PATH=$PATH:$PLAN9/bin
  
  # Plumb files instead of starting new editor.
  EDITOR=E
  unset FCEDIT VISUAL
  
  # Get rid of backspace characters in Unix man output.
  PAGER=nobs
  
  # Default font for Plan 9 programs.
  font=$PLAN9/font/lucsans/euro.8.font
  
  # Equivalent variables for rc(1).
  home=$HOME
  prompt="$H=;          "
  user=$USER
  
  export \
          BROWSER\
          ⋯
  
          PLAN9\
          ⋯
          font\
          home\
          prompt\
          user
  

• Acme is started once through the acme-start.rc script. This also starts the plumber service.
• $HOME/lib/plumbing is linked so I get some additional plumbing rules in addition to the default rules primarily quick access to github stuff

On mouse usage

Working with acme

• Urls to important web pages. 3-click them and chromium takes you there
• Github issues
• Git branch names enclosed in brackets: [jl/fix-eqc-test/37]
• Notes of importance, thougths.
• Complex commands with notes on their usage so they can be copied in and used quickly

• One with documentation and scratch pads.
• One which contain the main code I am working on right now.
• One with shells, erlang shells and code mixed.
• A narrow strip containing directory output to quickly get at a specific file. This strip also holds windows with error output.

Working with Erlang in acme

• A shell is used to run rebar compile. I add [rebar compile] to the tag and then click at the right of [ to select it. A 2-click now recompiles. Other typical things in the tag could be make or make test and so on.
• The gg command is a shorthand for git grep -n. Need a specific thing? I gg it and then the filename comes up with a line number. 3-clicking it is understood by the plumber to open that file on that line.
• I tend to avoid using tools which can follow code paths. Mainly because if you need a tool, then chances are that the code itself is quite convoluted and nasty
• I have a window which runs an erlang console for the project I am working on. I often dynamically load code into the erlang node and test it out. It is rare that I reboot the node unless I am doing something startup-specific coding.
• Documentation: Edit , <erl -man lists in a dummy window for the purpose
• I often search for code. :/^keyfind will search for keyfind, but at the start of the line. I keep such a line around in the tag for searches.
• The Edit , d command clears a window by selecting all contents and then deleting it.
• I often utilize the shell commands: <date +%Y-%m-%d inserts the current date into the buffer for instance. Selecting text and sending it through |sort will sort export lists and atom tables.
• Each project is written to a dump file with Dump acme.projectname. This way, you can easily get back with Load acme.projectname which restores your current window layout and more.
• I use the shell a lot when I write code. In practice I see the UNIX system as the IDE and then I use acme to access that IDE. It works wonders.

The Education Kit

Why not use <insert your favorite technology here>?

So - what's the scope?

Working outside the box

Where to go from here?

Apr 14 15:19:22 skapet spamd[1733]: (GREY) 201.215.127.126: <switchbackiwh0@google.com> -> <aramforbess@bsdly.net>
Apr 14 15:19:22 skapet spamd[31358]: Trapping 201.215.127.126 for tuple 201.215.127.126 pc-126-127-215-201.cm.vtr.net <switchbackiwh0@google.com> <aramforbess@bsdly.net>
Apr 14 15:19:22 skapet spamd[31358]: sync_trap 201.215.127.126

Apr 14 15:28:01 skapet spamd[30256]: 201.215.127.126: connected (3/3), lists: spamd-greytrap
Apr 14 15:30:15 skapet spamd[30256]: 201.215.127.126: disconnected after 134 seconds. lists: spamd-greytrap

Setting Up OpenBSD's spamd(8) With Secondary MXes In Play in Four Easy Steps

1. Make sure your MXes (both primary and secondary) are able to receive mail for your domains
2. Set set up content filtering for all MXes, since some spambots actually speak SMTP
3. Set up spamd in front of all MXes
4. Set up synchronization between your spamds

peter@primary $ sudo grep smtp /etc/pf.conf

pass in log quick on egress proto tcp from <nospamd> to port smtp
pass in log quick on egress proto tcp from <spamd-white> to port smtp
pass in log on egress proto tcp to port smtp rdr-to 127.0.0.1 port spamd queue spamd
pass out log on egress proto tcp to port smtp

table <spamd-white> persist
table <nospamd> persist file "/etc/mail/nospamd"

$ sudo grep smtp /etc/pf.conf

pass in log on egress proto tcp to port smtp rdr-to 127.0.0.1 port spamd
pass log proto tcp from <moby> to port smtp
pass log proto tcp from <spamd-white> to port smtp
pass log proto tcp from $lan to port smtp

table <spamd-white> persist counters
table <moby> file "/etc/mail/nospamd"

peter@primary-gw $ grep spamd /etc/rc.conf.local
spamd_flags="-v -G 2:8:864 -w 1 -y bge0 -Y secondary.com -Y secondary-gw.secondary.com "

$ sudo grep spamd /etc/rc.conf.local
spamd_flags="-v -G 2:8:864 -w 1 -y xl0 -Y primary-gw.primary.com -Y primary.com"

# spamd
!!spamd
daemon.err;daemon.warn;daemon.info;daemon.debug         /var/log/spamd

spamdb -T -a noreply@mydomain.nx

Der er i øjeblikket mange der taler om et botnet der på nuværende tidspunkt skulle være i gang med at brute force sig adgang til WordPress sites overalt. Der skulle efter sigende være tale om et angreb fra op til 90.000 forskellige kilder.

Om et sådan angreb er i gang eller ej skal jeg ikke kunne sige, men det har tilsyneladende fået rigtig mange WordPressbrugere til at genoverveje deres nuværende sikkerhedsniveau, så noget positivt er der da kommet ud af det lige meget hvad.

Jeg ser mange der diskuterer problemet og mulige løsninger, hvilket igen er positivt, men der er mange der ikke har helt styr på hvad der er godt og skidt, og evt. hvorfor, så jeg vil her prøve at give mit bud på nogle overvejelser man bør gøre sig inden man hovedløst kaster sig ud i installation af tilfældige sikkerhedsplugins.

En række supportere på det officielle WordPress support forum har sammen lavet en side på WordPress codex med tips og tricks til at sikre sig mod angrebet, så hvis du vil have den korte version på engelsk kan den findes her. Jeg vil gå lidt mere i dybden og forsøge at forklare det hele på dansk.

Hvad sker der egentlig?

For god ordens skyld vil jeg lige starte med at forklare det egentlige problem, så vi allesammen snakker om de samme ting, og for at give en idé om de overvejelser man bør gøre sig.

Botnets? What?

Det omtalte angreb stammer fra et stort botnet. Et botnet er et antal computere der, for det meste uden at ejeren ved det, bliver brugt af tredjepart til andre formål end hvad ejeren af computeren havde til hensigt.

I dette tilfælde handler det efter sigende om at bagmændende bag botnettet prøver at tiltvinge sig kontrol over flere computere, for på den måde at udvide deres botnet. De gør det ved at “brute force” sig administratoradgang til maskiner der kører websites bygget på WordPressplatformen. Hvis det lykkedes dem at få adgang til et WordPress-site gør de så dette site til en del af deres botnet, og på den måde vil angrebet vokse hver gang det lykkedes dem at overtage et WordPress-site.

Hvad så med det “brute forcing”?

Brute forcing handler om at tiltvinge sig adgang ved “brute force”, altså rå magt. Det foregår ved de simpelthen prøver at logge ind som adminbrugeren, ved at prøve mere eller mere tilfældige passwords, i teorien kan man jo gætte alle passwords hvis man har uendelige forsøg og god tålmodighed. Da der er tale om et automatisk angreb er det ikke noget der koster bagmændende noget tid, og de har derfor rigeligt med tålmodighed.

Men hvad kan jeg gøre ved det?

For det første skal du tage dine normale forholdsregler. Sørg ALTID for at holde WordPress fuldt opdateret. Det samme gælder alle installerede plugins og temaer. Dette er ikke specielt for det nuværende angreb, men alt software er usikkert på den ene eller anden måde. Folkene bag WordPress arbejder hårdt for at lukke alle sikkerhedshuller der bliver fundet så hurtigt så muligt, så sørg for altid at være opdateret. Sørg desuden for at slå alle plugins fra du ikke bruger. Som nævnt er intet software 100% sikkert, så en tommelfingerregel er at jo mindre software du har jo bedre.

Mht. det nuværende angreb er der selvfølgelig nogle ekstra ting du kan gøre.

Tag backup af alt!

En backup sikrer dig selvfølgelig ikke imod angreb udefra. Men hvis du skulle være uheldig enten at blive offer for angrebet, eller at få ødelagt dit site i et forsøg på at sikre det er det altså noget rarere at have end up-to-date backup, end at skulle starte helt forfra. Sørg altså for at tage backup af både selvesitet (via. FTP) og databasen (f.eks. via phpmyadmin), gerne lige nu, inden du forsøger at øge din sikkerhed.

Selve backupprocessen er afhængig af hvor du har dit website liggende, så der kan jeg ikke være så behjælpelig, men der findes som sædvanlig en række forslag på WordPress Codex.

Skift navnet på din adminbruger

Det igangværende angreb udnytter tilsyneladende at WordPress i gamle dage automatisk oprettede en administratorbruger med brugernavnet. Fra version 3.0 og frem har det været muligt selv at bestemme dette brugernavn, men det er ikke alle der har ændret det. En ændring af dette brugernavn vil gøre det sværere at brute force sig adgang til dit site, da angriberne så både skal finde brugernavn og password, i stedet for kun password.

Hvis du har en administratorbruger med brugernavnet admin kan det ændres forholdsvist enkelt med et plugin, eller ved et par manuelle skridt:

1. Login som din administratorbruger
2. I adminpanelet gå til “Brugere” -> “Tilføj ny”
3. Opret en ny bruger, sæt brugerens rolle til administrator (med et ordentlig password!)
4. Log ud.
5. Log ind med din nyoprettede administratorbruger.
6. I adminpanelet gå til “Brugere” -> “Alle brugere”.
7. Hold musen hen over admin-brugeren, og tryk på det “slet”-link der kommer frem.

Hvis du oplever at du ikke kan slette admin-brugeren så dobbeltcheck lige at du har logget ind med din nyoprettede bruger, og ikke stadig er logget ind som adminbrugere (ja, vi kan alle lave trykfejl ).

Brug ordentlige passwords

Dette er vel nok det vigtigste punkt på listen, og desværre nok også det mest besværlige at gøre ordentligt. Sørg altid for at bruge ordentlige passwords der ikke er lige til at gætte. Som sagt foregår det nuværende angreb som et brute force angreb, hvor de prøver sig at gætte sig til dit password, dette vil normalt foregå på en af to måder.

Enten kan man prøve fra en ende af, med “a” som password, derefter “b”, når alle muligheder er opbrugt prøver man så med to bogstaver, “aa”. Dette kan selvsagt tage lang tid, men hvis dit password f.eks. er “asdf” tager det altså ikke lang tid.

En anden metode er at tage udgangspunkt i en ordbog. I stedet for at prøve alle kombinationer af tal og bogstaver nøjes man med ord fra en prædefineret liste af ord. Disse liste vil ofte også indeholde ofte brugte afarter af ord, hvor f.eks bogstaver er udskiftet med tal. Dette betyder at hverken “password” eller “p4ssw0rd” er særlig gode passwords.

Der er skrevet rigtig, rigtig, rigtig, meget om hvordan man gør sine passwords sikre. WordPress Codex nævner også nogle gode forholdsregler man kan forholde sig til. Der henvises desuden til nogle services der kan hjælpe med at generere og huske gode passwords. De væsentligste ting må være:

• Lad være med at bruge personlige oplysninger, såsom dit navn, din fødselsdag eller lignende offentlige oplysninger.
• Lad være med at bruge ord fra ordbogen.
• Længere passwords er generelt bedre passwords.
• Brug en blanding af store og små bogstaver, tal og tegn

Men husk altid på de ovenstående metoder der bruges til at gætte passwords. 5up3rM4nRul3z43v3r (superman rules forever) er altså ikke nødvendigvis et godt password, da det stadig er en sammensætning af ord der garanteret vil stå i enhver password breaking ordbog.
Gode passwords vil oftest (altid?) være svære at huske. En metode til at gøre det lettere er at bruge en passwordmanager, et program eller en service til at huske dine passwords for dig. Jeg bruger selv LastPass som gør at jeg har et meget stærkt password som jeg skal huske. Dette masterpassword giver så adgang til alle mine passwords til diverse websites. Det betyder at jeg kan bruge services til at generere tilfældige passwords (eller, ihvertfald tilfældige nok), uden selv at skulle huske alle disse passwords, eller nedskrive dem på papirer som jeg kan smide væk.

Bloker adgang til din loginside

Da det igangværende angreb forsøger at få adgang administratorinterfacet på WordPress sites via den normale loginmetode, er en mulighed for øget beskyttelse at begrænse adgangen til adminpanelet. De to mest brugte metoder til dette er:

• Password-beskyt adminpanelet
• Bloker adgang til filen på IP-niveau

Fælles for de to metoder er at de kan fungere på et af to niveauer. Det kan enten gøres via. WordPress selv, eller det kan gøres direkte på serverniveau. Om man bruger den ene eller anden metode kan umiddelbart virke ligegyldigt, men jeg vil gerne lige understrege hvorfor det gør en forskel.

WordPress er skrevet i PHP, som bl.a. bruges til at skabe dynamiske hjemmesider. Jeg har andetsteds skrevet lidt om forskellen på statiske og dynamiske hjemmsider (læs afsnittene om statiske og dynamiske hjemmesider, resten af artiklen er ikke relevant for dette emne). Men det betyder at hver gang sikkerheden bliver håndteret i WordPress skal serveren have hele WordPress i gang med at arbejde for først at finde ud af om en bruger skal have adgang til en ressource. Samme sikkerhed kan ofte klares på serverniveau, hvilket betyder meget mindre arbejde for serveren, da en evt. angriber vil blive forment adgang allerede inden WordPress bliver sat i gang.

Password-beskyt adminpanelet

Passwordbeskyttelse kan som nævnt foregå både på server- og på WordPressniveau. Passwordbeskyttelse på WordPressniveau foregår via. WordPress eget loginsystem, det er en beskyttelse vi snakkede om tidligere med ændring af adminbrugernavn, og brug af gode passwords.

Passwordbeskyttelsen kan dog også flyttes ned på serverniveau med HTTP authentication. Dette vil resultere i at når du tilgår din WordPress loginside vil du først møde en popup hvor du skal skrive brugernavn og password, og derefter vil du møde den normale WordPress loginside. Dette er selvfølgelig en afvejning af sikkerhed vs. convenience da det kan virke lidt irriterende at skulle logge ind to gange. Hvis du vælger denne metode skal du selvfølgelig huske ikke at bruge samme brugernavn/passwordkombination til begge lag af beskyttelse. WordPress Codex har selvfølgelig også instruktioner til hvordan du opsætter HTTP authentication, både på Apache og Nginx servere.

Bloker adgangen på IP-niveau

En anden metode er at blokere adgangen til WordPress-loginformen ud fra forespørgerens IP-adresse. Hvis du ved at du har en fast IP-adresse og at du vil have den samme adresse lige så længe som du har din WordPressside kan du selvfølgelig lave en opsætning der kun giver den ene IP-adresse adgang til din loginside, men det er de færreste forundt (og nu er ikke tidspunktet til en IPv6-diskussion).

Et alternativ, som vil være mere relevant for de fleste, er kun at tillade en IP-adresse X antal loginforsøg, før denne blokeres. Dette kan gøres på WordPressniveau vha. et plugin som WordFence (tak til Kasper Bergholt for anbefaling af pluginet, der tilsyneladende også kan mange andre lækre ting), men igen har vi problemet med at hele WordPresspakken skal startes op, før der kan tages stilling til om en bruger skal have adgang eller ej. Dette er dog noget mere besværligt, og nok ikke noget alle og enhver bare bør kaste sig ud i, men en guide til opsætning af af rate-limiting på Apache kan findes her. Hvis man vil opsætte rate limiting i .htaccess, kræver det dog at man kører Apache med mod_security 2.7.3 eller senere.

Et problem med denne tilgang til det igangværende angreb er at angrebet som forklaret udføres af et botnet der arbejder fra mere end 90.000 forskellige IP-adresser (med mulighed for udvidelse, hvis de får succes). Det betyder at de potentielt kan fortsætte angrebet fra en ny IP, hvis en af adresserne bliver spærret. Dog må der altid være en form for ressource cost tilknyttet hvis angrebet skal flyttes til en ny afsender, da der skal holdes styr på hvor langt hver angriber er nået i ordbogen. Så jo flere lag af sikkerhed du kan opsætte, jo sværere bliver det for angriberen.

Opsummering

Så for at opsummere hvad jeg mener du bør gøre for at højne din WordPress-sikkerhed generelt, og imod det måske igangværende angreb er:

1. Hold WordPress opdateret, inkl.
   • WordPress core
   • Alle installerede plugins
   • Alle installerede temaer
2. Tag backup. Om ikke andet for at gøre det lettere at komme tilbage på benene hvis uheldet skulle være ude.
3. Lad være med at have en adminbruger med navnet admin.
4. Brug ordentlige passwords. Brug evt. en passwordmanager.
5. Passwordbeskyt din loginside.
6. Bloker adgangen for IP-adresser der prøver at gætte dit password.

Hvis i har andre gode råd til beskyttelse af WordPress hører jeg selvfølgelig også gerne om det i kommentarfeltet nedenfor, så vi kan få spredt ordet om ordentlig sikkerhed (At lade være med at bruge WordPress godtages ikke som et godt råd, så hvis det er din mission, så spar dig selv besværet og lad være med at skrive det her).

Jeg har længe fundet QR koder interessante, og var relativt hurtigt til at tage dem til mig, da de først kom frem. Til gengæld er jeg aldrig rigtig blevet overbevist om forretningspotentialet i dem.

Webbureauer og QR-konsulenter har længe kontaktet mig for at overtale mig om deres værdi, og selvom jeg aldrig rigtig bliver vist tal, der kunne vise den værdi, kunne jeg da godt blive overbevist alligevel af de rigtige argumenter.

Men dem er jeg bare endnu ikke blevet mødt med endnu – og jeg er ikke overbevist om, at ressourcerne der skal lægges i at få succes med dem, er  det værd.

Så hermed en udfordring:

• Hvordan kan QR koder binde offline og online sammen – på en kreativ, innovativ måde der VIRKER?
• Hvordan kan man markedsføre sin QR kode aktivitet uden at bruge store dele af marketingsbudgettet for det?
• Hvordan får man en målgruppe 35-55 år til at anvende det effektivt?
• Og på tværs af mange lande?

Jeg gider ikke store præsentationer og komplekse sammenhænge. Hvis ideen og konceptet ikke er simpelt nok, er det heller ikke godt nok

As an Operations consultant, I always see people focus on redundancy on all levels... Except for documentation.

For some reason everyone says, there should be documentation, but never ends up being usable documentation. Either it's too much, too little or something else :)

read more

Regular expressions are a wonderful tool, but as many other powerful tools they tend to be misused. If I had a penny for everytime I recommended against using regular expressions for parsing HTML fragments …. yeah you know what I mean.

This time made me think a bit about my own use of regular expressions. Do I ever fall in the trap of misusing regular expressions myself? Looking at my current code base I couldn’t find any glaring misuses, if I could only get a list of all the regular expressions in my current project.

Regular expressions to the rescue? No, that would probably be quite an horrible adventure. Luckily I have tools to parse Perl: PPI to the rescue:

A few hundred regular expressions. Most of them just matching simple substrings (in some cases case insensitive) or just short hand for testing a handful of equalities in one go. The only zero-width assertions we are using are the word boundary and quantifiers are mostly used on simple character classes like \d, \s, [0-9a-f] and a few “anything but this one or two characters” ([^>]).

Lessons learned: 1) PPI is cool. 2) I really do use regular expressions as I preach.

Nu har jeg efterhånden ikke haft en 30-dages udfordring siden Januar. Det holder jo ikke hvis jeg nogensinde skal kunne nå at gennemføre min. 3 stk i løbet af året. Desuden har jeg nu i ca. 3 måneder arbejdet med forskellige systemer og metoder, til at holde overblik over mine projekter og til at nå mere, så jeg burde have lært noget brugbart efterhånden, og det mener jeg da også at jeg har.
Jeg har flere gange læst om den fantastiske sammenhæng mellem motion og produktivitet. Jeg har ingen konkrete beviser på sammenhængen, men jeg mener selv at jeg har set en sammenhæng i form af øget produktivitet på dage hvor jeg har dyrket en eller anden form for motion.
Min 30-dages udfordring for April bliver derfor at starte hver dag med at dyrke en eller anden form for motion. Omfanget vil svinge meget fra dag til dag, alt efter hvad jeg lige har af tid fra morgenstunden. Nogen dage vil jeg starte stort enten med en WOD eller en løbetur, mens andre dage (især arbejds- og tømmermandsdage) vil være noget mindre prangende, disse kunne f.eks. bestå af 10 armbøjninger eller lignende. Planen er selvfølgelig at dette skal hjælpe mig til at blive mere produktiv, men det skal også hjælpe med at holde mig til ilden i forbindelse med min træning, og ændre mit mindset mht. både produktivitet og træning. Dette er et emne jeg vil komme mere ind på i senere indlæg, hvor jeg også vil komme lidt ind på hvad der kom ud af udfordringen med de 750 ord fra min Januarudfordring.

I've been setting up automated (with puppet) graphing of a lot of servers, incl. graphs for applications like varnish, mysql, memcache etc. (using diamond graphite collector).

I created a graph over varnish hitrates and shared it with the developer of the site running behind that varnish-farm (at that time it was 67% and slowly decreasing).

Here's what happened then :)

Åhhh, glæderne ved at have domænet hacking.dk:

Hej Peter .. jeg fandt din mail på nettet … kan du muligvis hjælpe mig? .. jeg er en ung pige der tror min fyr er utro … jeg vil gerne hacke hans facebook!!!

Hvis jeg er i et rigtig bittert humør, så kunne jeg række ud efter straffelovens §263 og slå hende i hovedet med strafferammen. Det er nok overkill, selvom jeg ville fortjene en straf medvirkened. Men nu er jeg rent faktisk ikke specielt bitter idag (om det så er fordi det er forår eller fordi mailen faktisk er forholdsvis velformlueret og velskrevet?)

Jeg kender selvfølgelig en ung dame der med jævne mellemrum “hacker” hendes fars facebook. Men mon ikke at afsenderes kæreste dog har lidt bedre styr på basal IT-sikkerhed end den stakkels far.

So. following up on my previous post about implementing a libravatar server, this will be an announcement of a quick Qt5 based client library for libravatar – so that everyone can put avatars everywhere!

Get it while it is hot on
git.kde.org

There isn’t much screenshots to show off, given it is effectively just converting a string with an email into a URL for a image.

And thanks to Martin Sandsmark for coming up with such a great name. Now I expect him to show off what it can be used for. Another thanks goes to Andreas Hartmetz for going thru the code & api.

The local hacker space here in Aalborg (HAL9k) has moved from Rapsgade 1 to a permanent location at Sofiendalsvej 80. For a number of weeks we he been moving boxes of all our stuff, painting walls and other tasks related to the move. One of the things that I was involved in was the electricity installation and the computer network.

We have been so lucky to inherit a large number of metal and plastic cable trays including a number of Ethernet jacks and power outlets reducing the budget for establishing a new infrastructure at the new place.

After a lot of work, 50 m metal, 20 m plastic cable tray and 1,2 km Ethernet cable later we now have 74 ethernet jacks connected to our distribution frame with our two 48 port gigabit Dell switches connected to an OpenBSD firewall in VMware on our Dell R710 server, routing IPv4 and IPv6 (through a SIXXS tunnel). Thank you to Notaplan for the switches and the server.

The wireless network is handled by a 802.11a/b/g access point. The access point and the directional antennas are actually meant for outdoor usage, so we mounted it on an IKEA table leg to give it a touch of the rustic outdoor life on a large pole…
If you are curious about the details of the network setup check out the hal9k wiki here.

Besides the network installation we have also installed a new distribution board and a lot of power outlets. We have a dedicated power meter for the server room besides the three other power meters (which according to our plan will be monitored by our LIAB) and relays for the groups used in the workshops making integration with the physical access control system and emergency buttons easily done.

OMG, hvor er user-agents strenge meningsløse:

“Mozilla/5.0 (iPhone; CPU iPhone OS 6_1_2 like Mac OS X) AppleWebKit
/536.26 (KHTML, like Gecko) Mobile/10B146 [FBAN/FBIOS;FBAV/5.6;FBBV/144493;FBDV/iPhone5,2;FBMD/iPhone;FBSN/iPhone OS;FBSV/6.1.2;FBSS/2; FBCR/TDC;FBID/phone;FBLC/da_DK;FBOP/0]“

So, since recently bugs.debian.org has started using libravatar avatars. Not yet the federated service, but that’s supposedly in the works. But for that, one of course need to run each own service. Which I wanted to do. In a simple way.

So I did it.

_avatars._tcp.pusling.com. 43200 IN SRV 10 10 80 static.pusling.com.

and in my root dir for that one I have source/ and avatar/

$ ls
avatar source

In source, I have default.png which I’m serving and a series of avatars for various email addresses

$ ls source/
debian@pusling.com default.png

and then I have a simple script to generate the right file names:

#! /bin/sh

(cd avatar;
ls | while read file ; do [ -L $file ] && rm $file ; done
)
for i in source/*@* ; do ln -s ../$i avatar/$(echo -n $(basename $i) | sha256sum | sed ‘s/-//’) ; done
for i in source/*@* ; do ln -s ../$i avatar/$(echo -n $(basename $i) | md5sum | sed ‘s/-//’) ; done

and the last piece of magic to get everything to work:

$ cat avatar/.htaccess
ErrorDocument 404 “/source/default.png”
ForceType image/png

<Files “index.html”>
ForceType text/html
</Files>

and a set of index.html files created with ‘touch’.

So there you go. A simple libravatar service, ignoring some pieces of the spec, but it should be good enough for most people. I might save my rants about the libravatar spec for another day. But it involves implementing a complete redirecting service and scaling of images.

When will debian.org and kde.org start providing avatar services?

Da jeg dagligt har kontakt med mine indiske kollegaer, lægger jeg ofte specielt mærke til når nyheder fra Indien suser forbi i min daglige nyhedsstrøm. For eksemple artiklen på pol.dk “Bus styrter ned fra bro i Indien: 32 er dræbt“. Artiklen indeholder følgende beskrivelse af den indiske trafiksikkerhed:

I 2011 blev omkring 110.000 personer dræbt i den tætte indiske trafik – det er flere end 300 om dagen. Dårlige veje, høje hastigheder og ringe køreevner er blandt årsagerne til de mange ulykker.

300 dræbte om dagen lyder godt nok slemt, ikke?

Fra en anden artikel kan jeg finde de tilsvarende tal for Danmark. I 2012 døde der 180 danskere i trafikken (rekord-få dræbte) og for kun 10 år siden var tallet omkring 500 dræbte om året.

I Indien bor der lige omkring 1,2 milliarder mod cirka 5.5 millioner i Danmark. Der er altså cirka 200 gange så mange indere som der er danskere. Hvis vi tager det ti år gamle antal for trafikdræbte i Danmark og ganger med 200, så får vi sjovt nok præcis det antal dræbte som artiklen forfærdes over der er i den indiske trafik.

Den indiske trafik er slem og en trafikdræbt er absolut en for mange. Men man skal passe på med at blive alt for forfærdet bare ved at sammenligne danske og indiske tale en-til-en.

Tivoli laver stadig ikke en kalender til Fredagsrock som er til at importere i diverse digitale kalendere.

Så jeg har gjort det for dem.
Kalenderen for Fredagsrock 2013 kan ses nedenfor. Selvfølgelig helt uofficielt, med forbehold for trykfejl, ændringer og uden ansvar.

Direkte links til: ical .ics, html og xml

http://www.fredagsrock.dk/ er selvfølgelig stadig den officielle side for Fredagsrock (og her kan også findes info om de forskellige kunstnere).
Fredagsrock har også en Facebook side.

Foto af: Tomasz Sienicki