Schlagwort: Computer

Soft- & Harware-Kommentare

Veröffentlicht am
von
Old but not bus­ted … – Die­ser Inhalt wur­de vor mehr als 13 Jah­ren publi­ziert. Die Kor­rekt­heit und Ver­füg­bar­keit von Links kön­nen lei­der nicht gewähr­leis­tet werden.

Gera­de hat­te ich das Pro­blem, dass mei­ne aktu­ell instal­lier­te Ver­si­on von ffmpeg nicht so woll­te wie ich und mir eine Video­da­tei­kon­ver­tie­rung mit einer Feh­ler­mel­dung quittierte.

Nach einer klei­nen Recher­che stell­te sich her­aus, dass das Pro­blem bekannt und bereits in einer aktu­el­le­ren Ver­si­on beho­ben ist. Da ich aber nun nicht so schnell eine aktu­el­le­re Ver­si­on instal­lie­ren konn­te und obi­ges Pro­blem auch nur bei einer Datei auf­trat, fand ich fol­gen­de Mög­lich­keit bei ubuntuforums.org zur (tem­po­rä­ren) Benut­zung einer sta­ti­schen (bereits kom­pi­lier­ten) Ver­si­on von ffmpeg.

wget http://ffmpeg.gusari.org/static/32bit/ffmpeg.static.32bit.2014-02-23.tar.gz
tar xzvf ffmpeg.static.32bit.2014-02-23.tar.gz
./ffmpeg -i input [output options] output

Erläu­te­rung:
Mit dem ers­ten Befehl wird die gepack­te 32bit-Vari­an­te von ffmpeg vom 23.02.2014 her­un­ter gelan­den.
Der zwei­te ent­packt die Datei, wobei die bei­den Datei­en ffmpeg und ffprobe ent­ste­hen.
Und als drit­tes wird die gera­de ent­pack­te Datei ffmpeg benutzt, um eine (bei­spiel­haf­te) Kon­ver­tie­rung durchzuführen.

… und schwup­di­wup war mein Pro­blem (jeden­falls tem­po­rär) beho­ben … – Dan­ke an FakeOutdoorsman!

Veröffentlicht am
von
Old but not bus­ted … – Die­ser Inhalt wur­de vor mehr als 14 Jah­ren publi­ziert. Die Kor­rekt­heit und Ver­füg­bar­keit von Links kön­nen lei­der nicht gewähr­leis­tet werden.

Seit ein paar Wochen habe ich den own­Cloud-Cli­ent unter Ubun­tu instal­liert. Die­ser lief auch recht gut & brauch­bar – bis auf ein paar klei­ne ‘Macken’. So zum Bei­spiel auch das Pro­blem­chen, wel­ches bei Don­ner­D­rum­mel kurz erklärt ist. Dies war beson­ders nach dem Auf­wa­chen des Rech­ners regel­mä­ßig zu beobachten.

Vor ein paar Tagen erhielt ich dann bei Neu­start des Cli­ents die Mel­dung, dass die Ver­si­on 1.0.3 ver­füg­bar ist. Aller­dings habe ich mich dann gewun­dert, dass ich die­se bei der Soft­ware­ak­tua­li­sie­rung nicht ange­bo­ten bekom­me. Heu­te habe ich dann noch­mal ver­sucht, dem Pro­blem auf den Grund zu gehen und bin über Don­ner­D­rum­mels Bei­trag gestol­pert. Dann habe ich mir noch­mal die Anlei­tung zur Instal­la­ti­on des Cli­ents ange­schaut und fest­ge­stellt, dass ich ein ande­res Repo instal­liert hat­te, als es da ange­ge­ben ist – ich hatte 

"isv:ownCloud:communiy"

in der URL, wel­ches jetzt 

"isv:ownCloud:ownCloud2012"

ist. Offen­sicht­lich hat sich da etwas ‘offi­zi­ell’ geän­dert, was ich bis dato nicht mit­be­kom­men hatte.

Lan­ge Rede, kur­zer Sinn – How­To zum Update des ownCloud-Clients:

  1. "owncloud-client" – Ver­si­on 1.0.2 – voll­stän­dig deinstal­lie­ren (ein Update hat nicht funktioniert).
  2. Das Repo (aus der Anlei­tung; s.o.) kon­trol­lie­ren und korrigieren.
  3. "owncloud-client" – jetzt in Ver­si­on 1.0.3–1 – (neu) installieren.

Voi­la – das ers­te Auf­wa­chen hat den Feh­ler im Cli­ent nicht mehr produziert… 🙂
Schön ist auch, dass der csync-Pro­zess (der im Hin­ter­grund für die Syn­chro­nisia­ti­on zustän­dig ist, nicht mehr mei­ne .xsession-errors-Datei ‘voll­müllt’. Dafür gibt es (jetzt?) im Cli­ent sel­ber einen Knopf, der die Logs anzeigt. (Blöd nur, dass das Fens­ter mit dem Log nicht schließ­bar ist und gera­de nur mit "xkill" been­det wer­den konn­te… *egal*)

Abschlie­ßend bleibt zu sagen, dass obi­ge ‘Anlei­tung’ ohne jeg­li­ches Gewehr mei­ner­seits ver­öf­fent­licht ist und dass ich mich gene­rell sehr über das own­Cloud-Pro­jekt und die alles in allem sehr gut funk­tio­nie­ren­de Soft­ware freue! 🙂

Veröffentlicht am
von
Old but not bus­ted … – Die­ser Inhalt wur­de vor mehr als 14 Jah­ren publi­ziert. Die Kor­rekt­heit und Ver­füg­bar­keit von Links kön­nen lei­der nicht gewähr­leis­tet werden.

…gehö­ren mir!

Letz­te Woche bin ich über unhosted.org – „Per­so­nal data free­dom; A move­ment to sepa­ra­te web apps from user data“ – gestol­pert. Und die haben die Web-App „Lib­re Docs“ auf Basis von Ether­pad Lite geschaf­fen, die das von Lib­re Docs zur Ver­fü­gung gestell­te Ether­pad nutzt, die erzeug­ten Daten bzw. Doku­men­te jedoch in der Cloud ablegt/speichert. Und der Ober­knal­ler dar­an ist, dass die­se Cloud-Schnitt­stel­le mit­tels der Java­script-Cli­ent-Biblio­thek remoteStorage.js, die die Rea­li­sie­rung einer W3C-Spe­zi­fi­ka­ti­on ist, umge­setzt wur­de und somit auch mei­ne eigen Cloud benutzt wer­den kann.

Wie jetzt, mei­ne eige­ne Cloud…!? – Na die, die ich mit own­Cloud auf mei­nem Web­space betrei­be und in der ich schon meine(n) Kalen­der (Cal­DAV), mein Adress­buch (Card­DAV) und ein paar Datei­en (Web­DAV) mit­tels Desk­top (Thun­der­bird & Ubun­tu) und Smart­phone (Android) ver­wal­te und synchronisiere.

Also ich kanns nur emp­feh­len und bedan­ke mich jetzt schon mal bei allen Betei­lig­ten der oben genann­ten Projekte! 🙂

Veröffentlicht am
von
Old but not bus­ted … – Die­ser Inhalt wur­de vor mehr als 14 Jah­ren publi­ziert. Die Kor­rekt­heit und Ver­füg­bar­keit von Links kön­nen lei­der nicht gewähr­leis­tet werden.

Ich ver­ste­he es nicht… – Sys­tem-Update (Ubun­tu Pre­cise; ohne frem­de PPAs) auf Thun­der­bird 12.0.1 und danach funk­tio­niert die manu­ell instal­lier­te Light­ning-Exten­si­on (1.3) nicht mehr.

Nach etwas Suchens bin ich dann zu einer Lösung gekom­men: Instal­la­ti­on der Ver­si­on 1.4.
Aller­dings ist die­se Ver­si­on nur (direkt) über addons.mozilla.org und nicht über die Haupt­sei­te des „Mozil­la Calen­dar“ Pro­jekts erhält­lich. Auf der Pro­jekt­sei­te wird als aktu­el­le Ver­si­ons­num­mer die 1.3 ange­ge­ben… *naja*

Trotz alle­dem: Es funk­tio­niert wie­der alles und die Cal­DAV-Unter­stüt­zung, wel­che IMHO (auch) durch das Team von Inver­se inc. unterstützt/voran getrie­ben wird, ist großartig! 🙂

Veröffentlicht am
von
Old but not bus­ted … – Die­ser Inhalt wur­de vor mehr als 14 Jah­ren publi­ziert. Die Kor­rekt­heit und Ver­füg­bar­keit von Links kön­nen lei­der nicht gewähr­leis­tet werden.

Seit ein paar Tagen habe ich in mei­nem /var/log/syslog ein paar häss­li­che Mel­dun­gen, die das gan­ze sys­log ‚voll­mül­len‘.

Hier mal ein Beispiel:

Apr 24 08:55:10 axolotl kernel: [36283.935663] Valid eCryptfs headers not found in file header region or xattr region, inode 1717173
Apr 24 08:55:10 axolotl kernel: [36283.935674] Either the lower file is not in a valid eCryptfs format, or the key could not be retrieved. Plaintext passthrough mode is not enabled; returning -EIO

Auf der Suche nach Ursa­che & Lösung bin ich über

Das Pro­blem der Mel­dun­gen (sie­he Rapha­els Erklä­run­gen) ist wohl, dass es in mei­nem (mit eCryptfs ver­schlüs­sel­tem) home Datei­en gibt, die eine Grö­ße von 0 Bytes haben. Wie die da hin gekom­men sind kann ich nicht mehr reka­pi­tu­lie­ren, da ich mir auch nicht mehr ganz sicher bin, seit wann die Mel­dun­gen im sys­log ste­hen (und ich eben­falls wenig Lust habe, die alten sys­log-Datei­en zu durchsuchen…).

Am Ende habe ich nun Fol­gen­des dur­ge­führt, um das eCryptfs wie­der kon­sis­ten zu machen & somit auch die Mel­dun­gen los zu werden.

  1. sudo find /home/.ecryptfs/$username/.Private/ -xdev -size 0c ($username = mein Login-Name)
  2. Der ers­te Befehl sucht alle Datei­en mit der 0‑By­te-Grö­ße und gibt die­se aus. – Bei mir waren es zehn die­ser Dateien.
  3. Danach habe ich alle aus­ge­ge­be­nen Datei­en per Hand noch­mal kon­trol­liert – ls -lha $datei.
  4. Abschlie­ßend (nach­dem ich fest­ge­stellt hat­te, dass alle Datei­en wirk­lich mir gehö­ren & wirk­lich 0 Bytes groß waren) habe ich dann alle zehn Datei­en ein­zeln gelöscht: sudo rm "$datei".

Das Gan­ze habe ich immer mit root-Rech­ten (sudo) gemacht, da es ohne die­se stän­dig zu Feh­ler­mel­dun­gen bzgl. der Rech­te kam – was aber auch an der Benut­zung von trash-cli lie­gen kann!

Zusam­men­fas­send kann ich sagen, dass

  • seit dem die Mel­dun­gen im sys­log nicht mehr vor­han­den sind *cla­ro!*;
  • ich seit dem kei­ne Pro­ble­me fest­stel­len konnte,
  • der Bug offen­sicht­lich (für bestimm­te Anwen­dun­gen) bereits gefi­xed ist (nichts des­to trotz kann ein Sys­tem­crash nat. dazu füh­ren, dass die­se Datei­en wie­der exis­tie­ren und dann mosert eCryptfs ja zurecht…) und
  • ich der Mei­nung bin, dass man die Datei­en rela­tiv gefahr­los löschen kann – 0 Byte gro­ße Datei­en haben kei­nen (pri­va­ten) Inhalt und soll­te es sich um Spe­zi­al­da­tei­en von bestimmtn Anwen­dun­gen han­deln, wer­den die beim Neu­start der Anwen­dung wahrsch. wie­der neu erstellt.

In die­sem Sin­ne & ohne die Über­nah­me irgend wel­cher Geweh­re,
der sokai