bash

Apropos

Ik heb net een van mijn partities geformatteerd naar een ander bestandssysteem. Zoals we allemaal weten, wijzigt de UUID bij het formatteren. Een aanpassing van /etc/fstab was dus nodig.

Ik was even het commando vergeten waarmee je UUIDs kan oplijsten. Ik zat al in bash dus ik dacht, RTFM: Read The Fantastic Man Pages. Ik typte apropos uuid en ik kreeg het volgende:

amedee@fangorn:~$ apropos uuid
Data::UUID (3pm)     - OSSP uuid Backward Compatibility Perl Binding
dbus-uuidgen (1)     - Utility to generate UUIDs
findfs (8)           - Find a filesystem by label or UUID
OSSP::uuid (3pm)     - OSSP uuid Perl Binding
UUID (3pm)           - Perl extension for using UUID interfaces as defined in e2fsprogs.
uuidd (8)            - UUID generation daemon
uuidgen (1)          - command-line utility to create a new UUID value

Sorry gasten, maar dat helpt mij niet. Nu was ik verplicht om die geheugenvreter bijgenaamd Firefox op te starten. Ik gebruikte deze query: http://www.google.com/search?q=how+to+find+uuid+of+a+partition. Het eerste resultaat kwam van de Ubuntu Forums en gaf me direct het antwoord dat ik wilde weten: blkid.

amedee@fangorn:~$ blkid
/dev/sda1: UUID="cbca999c-ac35-400b-981e-f6521bdce034" TYPE="ext2" 
/dev/sda2: UUID="af28U3-nqkc-r7yc-ImXS-Xrgc-jvuk-cBQWiP" TYPE="LVM2_member" 
/dev/mapper/lvmvolume-root: UUID="f3eedbc4-fbb0-4ba8-ac36-38d94b2d3aad" TYPE="ext4" 
/dev/mapper/lvmvolume-home: UUID="3ca8d92c-c04a-433a-825d-57edc77f014f" TYPE="ext4" 
/dev/mapper/lvmvolume-swap: UUID="0b92ab6a-7dfe-40b6-b227-833c9f136204" TYPE="swap" 
/dev/mapper/lvmvolume-vm: LABEL="vm" UUID="4779f948-0621-43df-a17d-741d0b44a1a4" TYPE="xfs" 
/dev/sdg1: SEC_TYPE="msdos" LABEL="EXT2FSD" UUID="E891-8431" TYPE="vfat" 
/dev/sdg2: LABEL="external" UUID="d195e97b-7f5d-41f6-9f55-7761ec569f8a" SEC_TYPE="ext2" TYPE="ext3" 
/dev/sdh1: UUID="B804-0E83" TYPE="vfat" 
/dev/sda3: UUID="00352C6E44CEFA42" TYPE="ntfs"

Waarom [krachtterm weggelaten] toont apropos uuid dat [adjectief verwijderd] blkid commando niet??? Het is echt wel relevant hoor! Als bewijs:

amedee@fangorn:~$ man blkid | grep uuid
       blkid -L label | -U uuid
       -U  uuid
              Look up one device that uses the uuid. For more details see the -L option.

Blijkbaar zoekt apropos alleen maar in de synopsis van commando's, en uiteraard staat "uuid" niet in de synopsis van blkid:

amedee@fangorn:~$ whatis blkid
blkid (8)            - command-line utility to locate/print block device attributes

WEROEM??? Aaaaaaaaaargggg!!!

Sorry, ik moest even stoom afblazen. De stoomdruk is nu terug onder het kritische niveau gezakt.

Foto's in batch verkleinen met imagemagick

Gisteren stelde Monica Monté een beetje een rare vraag op Twitter: "Bestaat er een manier om een hoop foto's (+100) in een batch te verkleinen (7mb >1mb) Via Photoshop, Lightroom, Bridge,...?"

Ik vind het een rare vraag omdat bestandsgrootte een ééndimensionaal gegeven is, terwijl foto's eigenlijk 3 dimensies hebben: lengte, breedte en kleurdiepte. Of 2 dimensies, als je alleen van lengte en breedte spreekt, en het aantal kleuren gelijk blijft in je omzetting. Bovendien, bij JPEG-compressie (daar bleek het achteraf inderdaad om te gaan) is het bij een foto waarvan je alleen de lengte en breedte weet, quasi onmogelijk om te voorspellen wat de bestandsgrootte gaat zijn, zonder het jpeg-compressiealgoritme uit te voeren. 2 verschillende foto's maar met exact dezelfde lengte en breedte zullen meestal een verschillende grootte hebben. Soit, Monica moet bij gelegenheid maar eens uitleggen wat ze bedoelde.

Er waren direct een aantal mensen die deze sympathieke fotoredactrice ter hulp snelden met hun advies voor zware softwarepakketten zoals Lightroom (@Jannemans, @mbargo, @bartclaeys, @Schuppe), iPhoto (@boskabout), Photoshop (@broodkast, @kodel, @eyeballkid), Picasa (@raf__) en Irfanview (@vdbvdb). @robindheer zat ook met dezelfde vraag: hoe verklein je foto's in batch?

Maar mensen, waarom allemaal zo moeilijk doen? Zoals ik gisteren al schreef op Twitter: het in batch verkleinen van afbeeldingen is iets waarvoor imagemagick ideaal geschikt is.
Ubuntu beschrijft het als volgt:

amedee@fangorn:~$ apt-cache show imagemagick
Package: imagemagick
Priority: optional
Section: graphics
Installed-Size: 348
Maintainer: Ubuntu Core developers <ubuntu-devel-discuss@lists.ubuntu.com>
Original-Maintainer: ImageMagick Packaging Team <pkg-gmagick-im-team@lists.alioth.debian.org>
Architecture: amd64
Version: 7:6.5.1.0-1.1ubuntu3
Depends: libbz2-1.0, libc6 (>= 2.3.4), libfreetype6 (>= 2.2.1), libgomp1 (>= 4.2.1),
 libice6 (>= 1:1.0.0), libjpeg62, liblcms1 (>= 1.15-1), libltdl7 (>= 2.2.6a), libmagickcore2,
 libmagickwand2, libsm6, libtiff4, libx11-6, libxext6, libxt6, zlib1g (>= 1:1.1.4)
Suggests: transfig, imagemagick-doc
Filename: pool/main/i/imagemagick/imagemagick_6.5.1.0-1.1ubuntu3_amd64.deb
Size: 95720
MD5sum: 87d33361ab2486f49c8ea077d8933eff
SHA1: b1a0da0347944a35984d40f7f85e94a52d576ae8
SHA256: 431d515a1b033b167f2517382e944ccdc60388bb326dd43adfc1f15a552a8a49
Description: image manipulation programs
 ImageMagick is a software suite to create, edit, and compose bitmap images.
 It can read, convert and write images in a variety of formats (over 100)
 including DPX, EXR, GIF, JPEG, JPEG-2000, PDF, PhotoCD, PNG, Postscript,
 SVG, and TIFF. Use ImageMagick to translate, flip, mirror, rotate, scale,
 shear and transform images, adjust image colors, apply various special
 effects, or draw text, lines, polygons, ellipses and Bézier curves.
 All manipulations can be achieved through shell commands as well as through
 an X11 graphical interface (display).
Homepage: http://www.imagemagick.org/
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Origin: Ubuntu
Task: kubuntu-desktop, kubuntu-netbook, edubuntu-desktop-gnome, edubuntu-desktop-kde,
 xubuntu-desktop
Don't panic, imagemagick bestaat ook voor al jullie Windows en Apple pointyclickers, zie http://www.imagemagick.org/script/binary-releases.php voor de downloadpagina.

Het omzetten van een groot aantal afbeeldingen is poepsimpel. Je geeft gewoon een van de volgende commando's in de directory waarin de te verkleinen afbeeldingen staan:

mogrify -resize 40% *.jpg
mogrify -resize 800x600 *.jpg
mogrify -resize 800 *.jpg
mogrify -resize 800x600! *.jpg
Dit geeft volgende resultaten:
  1. Verklein alle afbeeldingen naar 40% van hun oorspronkelijke afmeting.
  2. Verklein alle afbeeldingen zodat die binnen 800x600 pixels passen, met behoud van de aspect ratio.
  3. Verklein alle afbeeldingen zodat de breedte 800 pixels is.
  4. Verklein alle afbeeldingen zodat de afmeting exact 800x600 pixels is, waarbij de aspect ratio verloren mag gaan.
mogrify past de afbeeldingen in-place aan, dus de originelen worden overschreven. De om te zetten afbeeldingen zet je dus best op voorhand in een aparte directory, ofwel gebruik je convert ipv mogrify zodat je een nieuwe bestandsnaam kan (moet) meegeven.

Snelheidstest

Ik ben ervan overtuigd dat imagemagick véél efficiënter is dan al die GUI-programma's (met uitzondering misschien van lichtgewicht Irfanview). Daarom daag ik alle Windowsers en Appelaars uit voor een snelheidstest.

Ik heb 100 jpg-afbeeldingen gemaakt, allemaal bestaande uit willekeurige ruis. Je kan hier een kleiner voorbeeld (100x100) downloaden, of je kan ze ook zelf aanmaken met mijn bash scriptje img-create:

#!/bin/bash
for (( COUNTER=1; COUNTER<=100; COUNTER++ )) do
	convert -size 3000x3000 xc: +noise Random noise-"$COUNTER".jpg
	ls -hl noise-"$COUNTER".jpg
done
exit 
Het aanmaken van de afbeeldingen duurde 11'3":
amedee@fangorn:/tmp$ time ./img-create 
-rw-r--r-- 1 amedee amedee 7,6M 2009-11-22 15:57 noise-1.jpg
-rw-r--r-- 1 amedee amedee 7,6M 2009-11-22 15:57 noise-2.jpg
-rw-r--r-- 1 amedee amedee 7,6M 2009-11-22 15:57 noise-3.jpg
...
-rw-r--r-- 1 amedee amedee 7,6M 2009-11-22 16:08 noise-98.jpg
-rw-r--r-- 1 amedee amedee 7,6M 2009-11-22 16:08 noise-99.jpg
-rw-r--r-- 1 amedee amedee 7,6M 2009-11-22 16:08 noise-100.jpg
 
real	11m3.026s
user	10m44.710s
sys	0m13.570s
Met het bash scriptje img-resize zet ik ze om naar een kleiner bestand:
#!/bin/bash
for filename in `ls noise*.jpg`; do
	convert $filename -resize 50% small-"$filename"
	ls -hl *"$filename"
done
exit 
De omzetting duurde slechts 2'46":
amedee@fangorn:/tmp$ time ./img-resize
-rw-r--r-- 1 amedee amedee 7,6M 2009-11-22 16:08 noise-100.jpg
-rw-r--r-- 1 amedee amedee 1,5M 2009-11-22 17:28 small-noise-100.jpg
-rw-r--r-- 1 amedee amedee 7,6M 2009-11-22 15:58 noise-10.jpg
-rw-r--r-- 1 amedee amedee 1,5M 2009-11-22 17:28 small-noise-10.jpg
-rw-r--r-- 1 amedee amedee 7,6M 2009-11-22 15:58 noise-11.jpg
-rw-r--r-- 1 amedee amedee 1,5M 2009-11-22 17:28 small-noise-11.jpg
...
-rw-r--r-- 1 amedee amedee 7,6M 2009-11-22 16:08 noise-98.jpg
-rw-r--r-- 1 amedee amedee 1,5M 2009-11-22 17:30 small-noise-98.jpg
-rw-r--r-- 1 amedee amedee 7,6M 2009-11-22 16:08 noise-99.jpg
-rw-r--r-- 1 amedee amedee 1,5M 2009-11-22 17:31 small-noise-99.jpg
-rw-r--r-- 1 amedee amedee 7,6M 2009-11-22 15:58 noise-9.jpg
-rw-r--r-- 1 amedee amedee 1,5M 2009-11-22 17:31 small-noise-9.jpg
 
real	2m46.400s
user	3m37.430s
sys	0m10.530s
Wie doet het beter? Zet jouw resultaten in de reacties. Ik vraag me trouwens af hoe je op een betrouwbare manier de snelheid van Lightroom of Photoshop kunt meten, zonder gebruik te maken van een cronometer.

Linux liposuctie: Crunchbang in minder dan 1 gigabyte op de Acer Aspire One

Deze blogpost is een bewerking van http://po-ru.com/diary/linux-liposuction-or-xubuntu-in-under-a-gig-on-th.... Daar wordt er (X)Ubuntu Intrepid (8.10) gebruikt, terwijl mijn versie gericht is op Jaunty (9.04) en Karmic (9.10), meer bepaald de Crunchbang-variant met OpenBox desktop.

In een vorige blogpost heb ik 180 MiB vrijgemaakt door overbodige software en overbodige locales te verwijderen.

Ik heb di en du gebruikt om te achterhalen waar het meeste schijfruimte wordt verbruikt:

$ di -hm /
Filesystem         Mount               Megs     Used    Avail %Used fs Type
/dev/sda1          /                 6099.6   1887.6   4212.0  31%  ext4
$ sudo du -cms /* 2>/dev/null | column -tc 2 | grep -v "^0 " | sort -nr | head -n 11
2649  total
1396  /usr
900   /home
192   /var
124   /lib
16    /boot
8     /sbin
8     /etc
6     /bin
1     /tmp
1     /srv
Het meeste plaats wordt ingenomen door /usr: 1396 MiB. Dit kan verkleind worden, met een combinatie van squashfs en unionfs.

squashfs laat je een filesystem comprimeren, maar het is read-only. unionfs laat je toe om er een schrijfbaar filesystem bovenop te leggen, zodat je gegevens kan wijzigen. Uiteraard, hoe meer data je wijzigt, hoe meer schijfruimte er gebruikt wordt, maar het is altijd mogelijk om opnieuw te comprimeren en de schijfruimte te herwinnen.

Eerst moet squashfs geinstalleerd worden. unionfs zit al standaard in de kernel bij Jaunty en Karmic, en moet dus niet meer geïnstalleerd worden.

$ sudo aptitude install squashfs-tools
Dan moet er een plaats voorzien worden voor het gecomprimeerde filesystem en de overlay:
$ sudo mkdir -p /.filesystems/usr/overlay
Comprimeer het filesystem:
$ sudo mksquashfs /usr /.filesystems/usr/usr.sqfs
Voeg deze regels toe aan /etc/modules:
unionfs
squashfs
loop
en deze regels aan /etc/fstab:
/.filesystems/usr/usr.sqfs /usr squashfs ro,loop,nodev  
unionfs /usr unionfs nodev,noatime,dirs=/.filesystems/usr/overlay=rw:/usr=ro  
Sluit alle programma's af, ga naar runlevel 1 (of reboot en ga in de rescue mode) en zet de oude /usr-directory opzij:
$ sudo init 1
$ mv /usr /usr.old
$ mkdir /usr
$ mount -a
$ init 3
Werkt alles OK, ook na een reboot, dan mag /usr.old verwijderd worden.

Het schijfgebruik is nu:

$ di -hm /
Filesystem         Mount               Megs     Used    Avail %Used fs Type
/dev/sda1          /                 6099.6    954.9   4834.9  21%  ext4
Er is dus 932,7 MiB vrijgekomen. Dat komt overeen met het verschil in grootte tussen /usr en  :
$ sudo du -ms /usr /.filesystems/usr
1396    /usr
464     /.filesystems/usr

Opmerking: bij mij deed readahead een beetje lastig tijdens het booten. Dit probleem staat ook beschreven in deze forumtopic. Aangezien readahead alleen maar zinvol is bij een harde schijf maar niet bij een SSD, heb ik readahead ineens verwijderd:

$ sudo aptitude purge readahead

Kleine full-disk backup met dd

Eerst de USB-stick opvullen met een file vol nullen:

time dd if=/dev/zero of=/media/USB_2G/delete bs=1M
dd: schrijven van 'delete': Geen ruimte meer over op apparaat
1890+0 records in
1889+0 records uit
1981267968 bytes (2,0 GB) gekopieerd, 1121,06 s, 1,8 MB/s
 
real    18m41.067s
user    0m0.020s
sys     0m8.357s

Dan deze file weer wissen:

rm /media/USB_2G/delete

USB-stick unmounten:

umount /dev/sde1

Stick dumpen met dd en gzip:

time dd if=/dev/sde | gzip -c9 > USB_2G_ext2.gz
3941375+0 records in
3941375+0 records uit
2017984000 bytes (2,0 GB) gekopieerd, 198,682 s, 10,2 MB/s
 
real    3m18.687s
user    0m37.058s
sys     0m32.902s

De grootte van de backup valt echt héél goed mee! Wink Nose

ls -hl USB_2G_ext2.gz
-rw-r--r-- 1 amedee users 2,7M feb  7 15:40 USB_2G_ext2.gz

Achteraf de backup weer restoren:

time gunzip -c USB_2G_ext2.gz | dd of=/dev/sde
3941375+0 records in
3941375+0 records uit
2017984000 bytes (2,0 GB) gekopieerd, 461,316 s, 4,4 MB/s
 
real    7m41.322s
user    0m16.009s
sys     0m25.070s

Inhoud syndiceren