[13:57] Noen tips til verktøy som "cp" og "mv" med fremgangsindikator? [13:59] rsync --progress [14:00] kanskje også --human [14:42] --human? [14:43] -P er foresten en fin kombo av --progress --partial [14:44] --human-readable funker, --human feiler på lucid [14:45] ja, jeg mnete --human-readable [14:46] rsync kan ikke flytte et helt tre dog, men den kan fjerne filene etter den har kopiert de. Den tomme katalogstrukturen som er igjen kan fjernes med rmdir + globstar eller find. [15:32] rsync er alltid verrdt å sjekke når man skal kopiere noe, selvom den er temmelig mye treigere i noen få situasjoner. [15:43] i hvilke tilfeller er det tregere? :) [16:14] hvis du prøver å kopiere en fil i RAM, for eksempel. :) [16:17] rsync er veldig lat. Den legger massevis av arbeid i å finne ut hva den ikke behøver å gjøre. Det er nesten alltid veldig fint, men i noen få tilfeller, så tar det arbeidet mer tid enn å bare gjøre alt. Det er sjelden. ;) [16:18] I det vanlige tilfellet er jo rsync like rask eller raskere. [16:18] Den stat()er bare filene i hver ende og ser på hvilken som er nyest. [16:19] Du kan tvinge checksummingen med -c. Og det er vel i nesten alle tilfeller raskere, som du sier. [16:19] Jeg kommer ikke helt på når det skulle være treigere. [16:19] det er ikke sant. Den identifiserer for eksempel tom data. Hvis lagringen er rask nok og du kjenner dataen nok, så kan cp være raskere enn rsync i mange tilfeller. [16:20] Tom data? [16:20] Om du har voldsomt sløve CPUer, kanskje. [16:20] på lavprisekspressen, men det er litt dårlig ping :p på vei fra Arendal til Oso [16:20] Men både rsync og cp må lese hele kildefilen for å kopiere den. [16:20] men jeg sa altså dette mest for å understreke at rsync alltid bør tas med i betraktning med mindre du vet akkurat hvorfor den ikke er aktuell. [16:21] rsync leser den, checksummer (med en flott sliding windows-algoritme) og skriver potensielt hele mottakerfilen, og potensiel kun én byte. [16:21] jo-erlend: Jada, jeg bare lurte på om du hadde noen konkrete eksempler. [16:21] Jeg gjør nesten alltid kopiering med rsync når jeg gjør den for hånd. [16:22] prøv å ta en stor videofil, put den på tmpfs og kopier den med rsync og cp. [16:22] vedder ti megabytes på at cp vinner. [16:22] Kan prøve. [16:23] rsync er ca. like rask (bittelitt raskere, men det er nok målefeil) uten -c [16:23] Hvilket er normaltilfellet. [16:24] Og ca. halv hastighet med -c [16:24] Dette til og fra en SSD og /tmp på Debian, som er en tmpfs. [16:24] hva har halv hastighet? [16:24] rsync -c [16:24] nei. Jeg mente altså til og fra tmpfs. [16:25] Det har jo ikke så mye å se, med -c er det CPUen som taker. [16:25] Med cp fra tmpfs til tmpfs taker nok kontekstsvitsjing, så det blir litt akademisk. [16:26] Men konklusjonen er: Om du har sløvere CPUer enn lagringssystem, vil cp på enkeltfiler være raskere. [16:26] Så kult lagringssystem kan du såklart ha. Det er jo ikke helt uvanlig med RAM-disker med batterybackup for tiden. [16:27] (Eller hybrid-greier.) [16:27] nei, jeg vet. Jeg har hatt lyst til å skaffe meg et par sånne. [16:27] trenger ikke batteri engang. [16:28] Du er ikke glad i dataene? [16:29] hater data. [16:29] joda, men det er endel tilfeller hvor du leser ekstremt mye mer enn du skriver, men hvor dataen er så stor at du ikke kan holde den i primærminne. [16:36] kan for eksempel se for seg femti tusen halvsynkroniserte couchdatabaser. [21:02] noen her som vet om god programvare til å sy sammen bilder til "slideshow", helst med selvbestemt pause osv [21:02] det optimale hadde vært om jeg kunne klikke fram pausen i sanntid mens musikken går [23:21] RoyK: Høres ut som om du beskriver en presentasjon