My Galaxy Nexus was getting really slow over the last few weeks, meaning simple things like going to the homescreen took multiple seconds.
Turns out that the problem is the SD card filesystem / controller getting really slow once the SD card gets nearly filled up. You can verify this by running Androbench, a storage benchmark app. You should get a sequential write performance of a few MB/s (e.g. 8 MB/s), but when affected by the problem, you get about 0.x MB/s.
The fix is to delete files to make sure you have plenty of spare capacity, then run fstrim, neatly packaged in this app, followed by a reboot.
In case you haven’t rooted your phone for a while, the currently working way is using SuperSU, not Superuser.
I just released github.com/mstap/android-davsync, a FOSS tool with which you can (automatically or manually) upload photos to your WebDAV server.
On an up-to-date Debian testing system, lvremove fails sporadically when removing snapshots. The cause is not yet fully debugged, see Debian bug 549691. The symptom looks like this:
$ lvremove -f plana/snap_web Unable to deactivate open plana-domu--web-real (253:3) Failed to resume domu-web.
To work around this, use the following commands (works reliably, tested for a few days):
$ dmsetup remove /dev/mapper/plana-snap_web $ dmsetup remove /dev/mapper/plana-snap_web-cow $ lvremove -f plana/snap_web
Since they only remove the snapshot-mappings, this does not touch the data on the original LV at all.
One of the nice things about systemd is that you can change the Nice level and
IO scheduling class/priority in a very simple way. I have recently configured
bacula-fd on my server in such a way that it will not put a lot of
load on the machine:
cp /lib/systemd/system/bacula-fd.service /etc/systemd/system/bacula-fd.service
Then, open the file with an editor and change the following paragraph:
[Service] Type=forking PIDFile=/var/run/bacula/bacula-fd.9102.pid StandardOutput=syslog ExecStart=/usr/sbin/bacula-fd -u root -g root -c /etc/bacula/bacula-fd.conf
To look like this:
[Service] Nice=10 IOSchedulingClass=best-effort IOSchedulingPriority=7 Type=forking PIDFile=/var/run/bacula/bacula-fd.9102.pid StandardOutput=syslog ExecStart=/usr/sbin/bacula-fd -u root -g root -c /etc/bacula/bacula-fd.conf
And that’s it. See nice(1) and ionice(1) for the
possible values. Of course, these attributes are passed on to child processs:
USER PID PRI NI %CPU %MEM COMMAND root 3522 30 10 0.0 0.0 /usr/sbin/bacula-fd -u root -g root -c /etc/bacula/bacula-fd.conf root 23380 30 10 0.0 0.0 \_ /bin/sh /root/bin/xen-lvm-snapshot/foreach-domu.sh mount root 23607 30 10 0.0 0.0 \_ /bin/sh /root/bin/xen-lvm-snapshot/mount-snapshot.sh plana/domu-web root 23665 30 10 0.0 0.0 \_ /sbin/fsck.ext3 -y /dev/loop3
Hallo!
Wie jedes Jahr findet diesen November das Retro-Spiele-Event RGB2R des NoName e.V. statt. Der Plan: Jeder holt seine alten Spiele-Konsolen und -Computer jeglicher Art aus dem Schrank und verbringt in netter Gesellschaft viele Stunden Spaß mit den Spielen, die damals unsere Kindheit prägten.
Veranstaltungsort wird das Bürgerhaus Schlierbach in Heidelberg sein, siehe http://rgb2r.noname-ev.de/location/. Dort trefft ihr Gleichgesinnte, genießt eine Club-Mate und erkämpft euch den ersten Platz im $videospiel-Turnier!
Für einen Unkostenbeitrag von 15 € seid ihr das ganze lange Wochenende von 2012-11-01 (DO) bis 2012-11-04 (SO) dabei. Bitte meldet euch auf http://rgb2r.noname-ev.de/ an, damit wir planen können! Dort könnt ihr auch eure Frühstückswünsche äußern und ein T-Shirt vorbestellen.
Bis dann, der NoName e.V.
Because it is insanely hard to google this, here is how to disable auto-reload of PDF files within Evince (>= v3.4.0):
gsettings set org.gnome.Evince auto-reload false
Da die Entwicklung von sup (und dessen Nachfolger heliotrope/turnsole) absolut untragbar für ein OSS-Projekt ist, bin ich vor einer Weile auf den „Konkurrent“ notmuch umgestiegen. Da notmuch nur ein Mail-Index ohne Frontend ist, hat man die Wahl zwischen verschiedenen Frontends. Mit notmuch mitgeliefert wird das emacs-frontend, was mir aber nicht besonders gut gefällt.
Ehemalige Nutzer von sup werden sich in dem notmuch-Frontend alot schnell heimisch fühlen. alot kann noch nicht alles, was man von einem anständigen CLI-Mailer erwarten würde (z.B. GPG Encryption/Decryption oder Folding), aber ist für mich derzeit benutzbar genug. Der Entwickler pazz ist ziemlich responsiv was Patches angeht, daher prophezeie ich dem Projekt eine deutlich bessere Zukunft als sup.
Da notmuch mit Maildirs umgehen kann benutze ich offlineimap in Kombination mit einem eigenen IMAP-Server. Es ist abzusehen, dass ich nie wieder auf das Folder-Modell von IMAP zurückwechseln werde, weswegen ich nun folgende offlineimap-Zeile nutze:
folderfilter = lambda name: name == 'INBOX'Diese sorgt dafür, dass nur das INBOX-Folder synchronisiert wird, was einen offlineimap-Lauf (insbesondere mit dem
-q-Parameter) erheblich
beschleunigt.
Zusätzlich hilft es natürlich, die Datenmenge relativ klein zu halten, weswegen ich mein INBOX-Folder auf dem IMAP-Server regelmäßig aufräumen möchte. Dazu nutze ich das Script archivemail.sh von David Woodhouse.
Damit eingehende Mails ordentlich gefiltert werden und gekillte Threads auch gekillt bleiben benutze ich afew. Eine minimal Config dafür sieht so aus:
[global] [KillThreadsFilter]
Beim Abholen von Mails nutzt man dann:
offlineimap -q && notmuch new && afew -n -t
Als Anti-Spam-Lösung benutze ich DSPAM. Mein Filter für afew sieht folgendermaßen aus:
# coding=utf-8
# vim:ts=4:sw=4:expandtab
from __future__ import print_function, absolute_import, unicode_literals
from ..Filter import Filter, register_filter
@register_filter
class DSPAMFilter(Filter):
message = 'Tagging messages according to their DSPAM-header'
def __init__(self, spam_tag='is-spam'):
super(DSPAMFilter, self).__init__()
self.spam_tag = spam_tag
def handle_message(self, message):
if (message.get_header('X-DSPAM-Result') == 'Spam' and
float(message.get_header('X-DSPAM-Probability')) > 0.5):
self.add_tags(message, self.spam_tag)
(Man steckt den Filter in afew/afew/filters/DSPAMFilter.py und
fügt [DSPAMFilter] in der Config hinzu).
Ich setze dann für alle Threads den is-spam-Tag entsprechend und
trainiere DSPAM mit folgendem Script periodisch:
#!/bin/zsh # script to prepare the DSPAM training based on the current notmuch tags. # The timestamp used below is 2012-07-21, when I configured the 'S' keybinding # and afew filter to make use of the X-DSPAM headers again. rm -rf /tmp/spam /tmp/ham mkdir /tmp/spam /tmp/ham # Extract all SPAM emails notmuch search --output=files tag:is-spam 1342884032.. | \ tar cf - -P -T - --transform 's,.*/,,g' | \ tar xf - -C /tmp/spam # Extract all HAM emails notmuch search --output=files -tag:is-spam 1342884032.. | \ tar cf - -P -T - --transform 's,.*/,,g' | \ tar xf - -C /tmp/ham # Now run the training dspam_train michael --client /tmp/spam /tmp/ham
Gestern kriegte ich bescheid gesagt, dass ein Server, den ich mitbetreue, kaputt gegangen sei. Die Hardware wurde vom Hoster getauscht, allerdings wurden auch neue Platten eingebaut. Der Hoster bot an, zusätzlich die alte Platte anzuschließen, um die Daten zu kopieren. Warum er die Daten nicht einfach selbst kopierte, verstehe ich nicht ganz.
Im Rescue-System (ein grml) konnten wir dann die alte Platte (7 Jahre
Betriebsstunden, uff) und die neuen Platten sehen. Nach einem kurzen
dd waren die Daten dann kopiert, danach ging das Anpassen und
Debuggen los. Hier eine Checkliste, was man beachten sollte:
/etc/udev/rules.d/70-persistent-net.rules muss man
einen entsprechenden Eintrag für die neue Netzwerkkarte hinzufügen und
die alten entfernen, damit die neue Netzwerkkarte nicht als eth1
erkannt wird und plötzlich keine Konfiguration mehr hat.
Praktischerweise kann man den nötigen Inhalt direkt aus der
/etc/udev/rules.d/70-persistent-net.rules des
Rescue-systems kopieren./etc/mtab sollte, sofern sie existiert und noch
eine reguläre Datei ist, durch einen Symlink auf
/proc/mounts ersetzt werden.update-initramfs -k all -u
aktualisiert werden.grub-install --recheck
/dev/sda mit aktueller device map installiert werden./etc/fstab sollte angepasst werden.Alle diese Punkte hatten wir befolgt, aber nach einem Neustart kam der Server trotzdem nicht hoch. Eine serielle Schnittstelle, KVM, Remote-Hands o.ä. hatten wir nicht zur Verfügung.
Als nächstes habe ich dann netconsole probiert, um auf einem anderen Rechner die Bootmeldungen zu lesen. Das kriegt man unter Debian folgendermaßen hin:
echo 'forcedeth' >> /etc/initramfs-tools/modules echo 'netconsole [email protected]/eth0,[email protected]/00:0c:db:4e:e8:00' >> /etc/initramfs-tools/modules update-initramfs -k all -u
Wobei hier 111.222.333.444 die IP des Servers ist und 555.666.777.888 die IP
ist, an welche die Nachrichten geschickt werden. Wichtig ist hier noch, dass
die MAC-Adresse diejenige des Gateways ist, damit die Pakete ins Internet
gelangen. Die kann man mit ip -4 neighbor show herausfinden.
Des Rätsels Lösung war dann, dass im BIOS des Rechners die alte Festplatte
zuerst gelistet war, sodass er wieder ins alte System startete. Gelöst haben
wir das dann mit dd if=/dev/zero of=/dev/sdc bs=5M count=10, womit
man den MBR und die Partition Table (und Daten!) der alten Platte überschreibt,
sodass das BIOS diese beim Starten überspringt.
Soeben habe ich i3 v4.2 released. Die Release notes enthalten alle Neuerungen.
Soeben habe ich i3 v4.1.1 released. Die Release notes enthalten alle Neuerungen.