Daniels Blog

There is no user interface in Google's browser Chrome yet to disable the disk cache, or control its size (version 14 appears to have something in the developer tools section).

But it can be done using command line options when starting the browser, and you can configure this globally for Ubuntu.

The following command line flags will use /dev/null ("the sink") as cache dir, and additionally limits it to 1 byte:

--disk-cache-dir=/dev/null --disk-cache-size=1

(I have tried just --disk-cache-size=0 or 1, but it did not appear to work as expected)

On Ubuntu/Debian, you can just add these flags to the CHROMIUM_FLAGS variable in /etc/chromium-browser/default and it will be used every time when starting Chromium.

The motivation to do this comes from me using a local (intercepting) HTTP proxy with its cache on a RAM disk. Therefore I do not want Chromium to store quite the same retrieved files on disk again.
Additionally, this is a SSD, which is not that happy about being written to in general.
Therefore /tmp is a tmpfs mount already, and the same should be the case for temporary browser files.

The following snippet will get you the OpenVZ container, when you're in a container. I have added this to my zsh prompt, but this might be useful in other places, too.

Code:

The following zsh snippet allows you to re-install any missing startup/init.d links.

This can be useful/required when e.g. installing an upstart based distribution (like Ubuntu Lucid) has removed some of those, and you want them back after downgrading to Hardy or switching to Debian testing (like I just did).
(apt-get install --reinstall won't bring back those links; you would have to purge (apt-get purge) and reinstall the package instead, removing any other configuration of the package though)

It basically looks for any init scripts that are not present in /etc/rc?.d/S* and then looks at the packages' postinstallation script for an update-rc.d command.

It will not install anything, but only output them (and allows you to pipe it into "sh" for execution).

Worked fine on my "messed up" system, but has rather odd results on my Maverick desktop.

Code:

(in case you need to extract the init script altogether, the following might help for starters:
dpkg-deb --extract /var/cache/apt/archives/$PACKAGE.deb /tmp/foo.)

Link: https://github.com/blueyed/oh-my-zsh/blob/master/plugins/apt/apt.plugin.zsh

I've finally started to manage the setup of my dotfiles (configuration files) for shell, editor etc.
It is based on the popular dotfiles repository of ryanb and my fork can be found at github:blueyed/dotfiles.

While I'm still in the process of setting this up, I've just added the apt-* helpers I wrote some years ago:

They provide neat things like asrc -g hardy hello to get the version of the "hello" package from hardy (via "apt-get source" and the version number grepped from "apt-cache madison" - so you need to have it in your apt sources list, of course).
Also, ashow -g testing hello will show the package from Debian testing.

Apart from that these are mostly aliases, like "aup" for "sudo apt-get update" and some of them support shell completion (of package names) for e.g. "ainst" ("sudo apt-get install"). Shell completion works in both zsh and bash (at least).

You can get the file (to be sourced in a shell) from:
https://github.com/blueyed/oh-my-zsh/blob/master/plugins/apt/apt.plugin.zsh.

Feedback is very welcome and I am sure some of this is in packages like debian-goodies already (actually, there's nothing like that in _that_ package, but..).

Does it make sense to add (parts of) it to some package for easy installation across Debian/Ubuntu?

When nginx is being used as backend server, it will talk plain "http" to the frontend server only (for performance reasons and to simplify setup).

But web applications often need to know, if the traffic between the browser and server is encrypted (https), e.g. when checking if a particular part of the site is being accessed securely.

Since only the frontend proxy (the one between nginx and the browser) knows about this, this information has to be forwarded to the backend.

Full story »

When doing web development you'll often have domains/hostnames like hahler.local (instead of hahler.de).

Having a separate hostname for a lot of projects will result in some inconvenience though: you have to setup those.
Until recently, I was adding them to /etc/hosts (or the counterpart on Windows), like so:

127.0.0.1 hahler.local whissip.local


This however does not allow wildcards (like *.hahler.local), and having something like 127.0.0.1 *.local would be much easier to maintain (no adding to this file for a new setup/project).

dnsmasq to the rescue!

dnsmasq is a lightweight DNS forwarder and I was using it already to cache DNS queries locally, for faster browsing etc. Since it answers my DNS lookups already, it should be able to make *.local work for me.

I've created a simple file /etc/dnsmasq.d/my-local with just a single line:

Code:

And after restarting dnsmasq, *.local gets resolved to 127.0.0.1.

Instead of "local" you can (and should probably) use another domain, like "dev" instead, because using "local" conflicts with Avahi/mdns, but this can get solved as follows:
Avahi/mdns defaults to ".local" as its TLD and therefore you have to adjust the "hosts" line in /etc/nsswitch.conf and put "dns" (which is dnsmasq in this case) before mdns4_minimal (which is avahi in this case), or remove the NOTFOUND=return, so that "dns" would get used even when mdns4_minimal returns NOTFOUND (which it apparently does for requests in its domain (typically ".local") it does not know anything about):

Code:

I've created the following macros to easily launch various SVN commands in TortoiseSVN at work.

To use them yourself, just create the displayed files (VCS/*.bsh) in your personal "macros" directory (~/.jedit/macros).

Code:

You can now execute those macros either by calling them from the "Macros" menu, assign a shortcut to them or (my preferred way) via Ctrl-Enter, typing parts of them and then TAB-completing it (e.g. Ctrl-Enter, "log_", TAB, Enter).

They do not have "svn" in the name, since they might get extended to use the appropriate VCS GUI command in the future, for example by testing if there's a .svn control directory or using commands like "bzr st" or "git status" to check if it's a Bazaar/Git/... file.

(For debugging, you can use Macros.message( view, exec ); to display the "exec" value in a message)