Surgut

One of the WSGI servers that is commonly using with nginx is uwsgi . One way to configure and deploy simple and complex WSGI middlewares and apps is by using Paste deploy tooling. However, until now uwsgi was only able to load a default app under the suffix "main". There is no such limitation in the Paste deploy code itself, as functions there accept a name argument. What was missing is an option in uwsgi to pass, optionally, alternative non-default name of the app to load. A patch adding this option has now been merged upstream and should be available in the next uwsgi release. What I was hoping that one will be able to do something like this: $ uwsgi --ini-paste /etc/nova/api-paste.ini --paste-name osapi_compute But alas that didn't work. I wish all OpenStack Software service were deployable as normal wsgi stand-alone apps without any addition glue code. Keystone is kind of like this with /usr/share/httpd/cgi-bin/keystone/main entry point for deploying keys

Today at work, I announced something James Hunt, Ikey Doherty and myself have been working on. We integrated Clear Containers  technology with Docker* Engine  to create Clear Containers for Docker* Engine . After following installation instructions , one can pull and run existing Docker* containers in the secure Clear Containers environment. This means that instead of namespaces, a fast virtual machine is started using the kvmtool hypervisor. This VM is running an optimised minimal Linux* kernel and the optimised Clear Linux* for Intel ®  Architecture Project user-space, with the only goal to execute the Docker* workload and then shut down. The net effect is almost indistinguishable from typical Docker* container usage: $ docker run -ti ubuntu:vivid root@d88a60502ed7:/# systemd-detect-virt kvm Apart from, as you see, it's running inside a kvm VM, and thus protected by  Intel® Virtualization Technology. This is available on Clear Linux* as well as multiple other operating

Given a string, get a truncated string of length up to 12. The task is ambiguous, as it doesn't say anything about whether or not 12 should include terminating null character or not. None the less, let's see how one would achieve this in various languages. Let's start with python3 import sys print(sys.argv[1][:12]) Simple enough, in essence given first argument, print it up to length 12. As an added this also deals with unicode correctly that is if passed arg is 車賈滑豈更串句龜龜契金喇車賈滑豈更串句龜龜契金喇, it will correctly print 車賈滑豈更串句龜龜契金喇. (note these are just random Unicode strings to me, no idea what they stand for). In C things are slightly more verbose, but in essence, I am going to use strncpy function: #include <stdio.h> #include <string.h> void main(int argc, char *argv[]) { char res[12]; strncpy(res,argv[1],12); printf("%s\n",res); } This treats things as byte-array instead of unicode, thus for unicode test it will end up printing just 車賈滑

$ sudo find /etc -type f | wc -l 2794 Stateless When was the last time you looked at /etc and thought - "I honestly know what every single file in here is". Or for example had a thought "Each file in here is configuration changes that I made". Or for example do you have confidence that your system will continue to function correctly if any of those files and directories are removed? Traditionally most *NIX utilities are simple enough utilities, that do not require any configuration files what's so ever. However most have command line arguments, and environment variables to manipulate their behavior. Some of the more complex utilities have configuration files under /etc, sometimes with "layer" configuration from user's home directory (~/). Most of them are generally widely accepted. However, these do not segregate upstream / distribution / site administrator / local administrator / user configuration changes. Most update mechanisms cre

Current Setup I am a Linux Distribution Engineer and work on arbitrary open source projects. Mostly I'm patching/packaging existing things, and sometimes start fresh projects. My "IDE", or rather I shall say "toolbox" is rather sparse: GNOME Terminal Google Chrome GNU Emacs GCC toolcahin with GDB Python3 - iPython, iPdb, pyflakes git, GNU bazaar There are a few things that annoy me, and should be done better these days. Documentation I lookup documentation mostly with Google Chrome. This includes the texinfo renderings of the docs. There are a few reasons for that. First of all my developer machine is not polluted with all the dev packages under the sun, instead I compile practically everything in a chroot. And most of the time chroots have much newer versions of everything (from gcc & automake, to boost and whatever other dependencies are in use). However I would like to have easy generic lookup builtin for common things that I lookup in

Ubuntu Vivid Vervet 15.04 is on its final approach to release at the end of next month. Here is a highlight of one of the features that I have helped to land. ubuntu-drivers-common is a framework to detect hardware-dependent components on user's machine and offer to install additional packages to enable better support for such hardware. Typical examples are drivers for the graphics cards. This cycle I have added CPU family detection plugin, which helps to detect cpu family and install appropriate microcode update. E.g. if one is running Intel CPU, intel-microcode package is installed. Check out: $ ubuntu-drivers devices $ ubuntu-drivers list $ ubuntu-drivers autoinstall

I'm happy to announce that Python 3 ports of launchpadlib & ubuntu-dev-tools (library) are available for consumption. These are 1.10.3 & 0.155 respectfully. This means that everyone should start porting their reports, tools, and scriptage to python3. ubuntu-dev-tools has the library portion ported to python3, as I did not dare to switch individual scripts to python3 without thorough interactive testing. Please help out porting those and/or file bug reports against the python3 port. Feel free to subscribe me to the bug reports on launchpad. For the time being, I believe some things will not be easy to port to python3 because of the elephant in the room - bzrlib. For some things like lp-shell, it should be easy to move away from bzrlib, as non-vcs things are used there. For other things the current suggestion is to probably fork to bzr binary or a python2 process. I ponder if a minimal usable python3-bzrlib wrapper around python2 bzrlib is possible to satisfy the nee