Recent comments on posts in the blog:

Look at 50unattended-upgrades

Did you look in the comment in /etc/apt/preferences.d/50unattended-upgrades? Yes, it is was so incomplete you did have to read the source to find out how to use it. And like you I did that. And then I wrote it up like you did here, and filed a bug whinging about it to the maintainer for good measure.

The maintainer turns out to be a very nice fellow. So now in jessie it's I think it's pretty good doco, although I'm probably not the best judge since I wrote it.

Comment by ras
Re: to LXC other Debian flavours ?

BTW, Can you expando on ? :

sudo MIRROR= lxc-create -n sid64 -t debian -- -r sid -a amd64

how could i install another Debian flavour (say Wheezy) ?

If you replace -r sid with -r wheezy in the above, you'll get a container running Debian stable instead of Debian unstable.

You can also change -a amd64 to -a i386 if you want a 32-bit container instead of a 64-bit one.

Comment by Francois Marier to LXC other Debian flavours ?

So useful to me, Thanks!

BTW, Can you expando on ? :

sudo MIRROR= lxc-create -n sid64 -t debian -- -r sid -a amd64

how could i install another Debian flavour (say Wheezy) ?

thanks again

Comment by jordi
Re: Privacy/SaaS/network freedom concerns?

Fabian: As far as I know, both the backend server and the client are both free software. The client doesn't use any binary blobs other than the optional OpenH264 (which is free software though patent-encumbered).

It also relies on STUN / TURN servers which may or may not be free software, I'm not sure. Probably best to ask the folks on #loop (

Comment by fmarier
Privacy/SaaS/network freedom concerns?

I don't suppose Firefox Hello will remain in Debian and other GNU/Linux distributions knowing it depends on third-party non-free network/SaaS services and possibly (I haven' t looked) introduces non-free code. Are there any plans to release this as a proper separate plugin/extension?

Videocasting/chromecasting is also problematic, but your post highlights a situation similar to what led to creation, in that context.

Comment by Fabian Rodriguez
Mosh? Mobile clients?

Why don't you just use mosh to connect to an IRC session running in screen? What's the benefit of znc and a local client?

Also, I've looked at znc particularly for multi-client support. The idea would be that I have a main irssi session, but during certain times I'd like to tune in to just e.g. #debconf-team from my smartphone. Unfortunately, bouncers usually do all-or-nothing to all clients (meaning I can either subscribe to all channels or none from the smartphone, which will drain the battery like crazy) and while I am led to believe that znc actually supports slave accounts and can be used for this, it's very complex to set up.

Finally, when you have multiple clients working, then privmsgs sent from one don't show up on the other.

All this makes me stay with mosh for now. If only mosh existed for Android…

Comment by madduck
Same here... and byte order mark issues!
I just investigated something similar involving a caching proxy that performed decompression. In my case the Content-Length header was, in many instances, off by three bytes. Further investigation--including identifying the bytes 0xEE 0xBB 0xBF--led me to discover that the Byte Order Mark (BOM) at the head of some of my text files was being stripped away by the proxy...BUT the Content-Length wasn't being downward adjusted by the proxy! So basically clients of the proxy ended up with some content (likely because of a keep-alive between the browser and the caching proxy) that included the first three bytes of the next response! (Usually this was "HTT" at the end of the file... probably part of the "HTTP/1.1 200 OK" response header on the next reply in the stream! This took quite a bit of time to investigate but was quite interesting!
Comment by Eric Kramer