Zum Labeldrucker ql-710w (und einigen anderen) gibt Brother ein Kommandozeilentool,
mit dem man Custom pagesizes, also eigene Label-Formate erstellen und einbinden kann.
Das händisch zu versuchen, endet leicht in rot blinkender Drucker-LED.

brpapertoollpr_ql710w -P ql-710w -n 62x35Label -w 62 -h 35

ist die Syntax, um ein neues Format 62x35Label mit Breite 62mm, Höhe 35mm
zu erstellen.

Das Tool geht aber ungefragt davon aus, dass  
in /etc/cups/ppd die Datei ql-710w.ppd existiert und gibt sonst nur
lakonisch ein File not Found zurück.

mit

strace -ff  -e stat64  -e open brpapertoollpr_ql710w -P ql-710w -n 62x35Label -w 62 -h 35

kann man sich das vor Augen führen.

Hier gab es halt nur eine anders benamte .ppd, deshalb einiges Herumsuchen und -kopieren.

andere hier nennenswerte Orte:

/usr/share/cups/model
/opt/brother/PTouch/ql710w/inf

Was eben leider nicht geht, obwohl man es erwartet (und andere
Betriebssysteme auch Druckertreiber haben, die das unterstützen):
Das das Ding von seinem Endlospapier einfach druckt, bis es fertig ist, und
dann abschneidet.

Diese Erfahrung mache ich nicht allein, Tante Guggel findet reichlich ähnliche Fragen. 
Hilfreich waren mir Brother PCLinux-Forum Suse-Forum (mit Hinweisen auf einen besseren Foomatic-Treiber), natürlich das Arch-Drucker-Wiki 


Diese Einrichtung hat mich fast 3 m Etiketten gekostet.

Davon ab ist das ein für seine Zwecke nettes Druckerchen mit ordentlichem Druckbild. Ich bin im Zweifel, ob es grosse Unterschiede zwischen dem Druckwerk des QL-700 und günstigeren Modellen wie dem QL-570 gibt, lt. Datenblatt hat der QL-7XX zwar bis zu 300x600 px Auflösung, aber die Treiberdialoge kennen nur 300px und auch ein anhakbarer Schönschreibmodus hat keine sichtlichen Unterschiede gemacht. Zur Ersteinrichtung des Wlan musste ich auf einem anderen Betriebssystem einmal die Software installieren und eine USB-Verbindung herstellen, ganz ohne Mac oder Win geht es nur, wenn man an seinem AccessPoint die 1-Klick-Anmeldung mit WPS unterstützt.

Arch Linux entschlacken

Sunday, June 2. 2013

Ok, auch Linux verfettet mit der Zeit.
Mal eben ein df -h und mit Schrecken sehe ich, dass die root partition bei über 90% Benutzung angelangt ist.
Mein erster Verdacht (dass ein Backup statt in's gemountete remote-Laufwerk lokal reingerutscht ist, bestätigt sich nicht, stattdessen zeigt mir Konqueror im Viewmode 'File Size View' von /var nur /var/cache/pacman/pkg, alle anderen Verzeichnisse kleben als Pünktchen am Rand.

pacman hebt sich hier vorige versionen aller packages auf, um dem Nutzer so schmerzloses Downgrade von Paketen zu ermöglichen. Sowas habe ich bislang noch nicht machen müssen.

Google schickt mich zum pacman-Artikel im Arch-wiki und dort finde ich den Hinweis auf das Putzprogramm paccache. paccache -h zeigt die Optionen, ich putze alle alten Versionen und behalte nur die jeweils letzte von jedem mit
paccache -r -k1
die fettesten Brocken, KDE-Hintergrundbilder, vertreibe ich ganz mit
paccache -r -k0 kdeartwork-wallpapers
paccache -r -k0 kde-wallpapers


Ergebnis: 12 GB frei gemacht, Benutzung liegt wieder bei 42%. Dauer (mit Googlen): 15 min.

 

Mäusespeck

Saturday, April 6. 2013

 Den Trackball von LogiTech gibt es offenbar nur noch als kabelloses Device (und zu einem Preis, der jeden Kontakt zu den Herstellungskosten verloren hat). Musste trotzdem sein, und: AEG - auspacken, einschalten, gehtnich.
dmesg meinte dazu:

usb 6-1: new full-speed USB device number 5 using uhci_hcd
usb 6-1: device not accepting address 5, error -71
hub 6-0:1.0: unable to enumerate USB device on port 1
und kernel.log präzisierte:
device descriptor read/64, error -71
Auf den einschlägigen Seiten, die mir Google fand, stand nichts Weiterführendes. Was es dann brachte: den kleinen USB-Stecker in einen anderen USB-Port einzustöpseln.
kernel.log meint:
usb 6-2: new full-speed USB device number 10 using uhci_hcd
logitech-djreceiver 0003:046D:C52B.0006: hiddev0,hidraw3: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:1d.2-2/input2
input: Logitech Unifying Device. Wireless PID:1028 as /devices/pci0000:00/0000:00:1d.2/usb6/6-2/6-2:1.2/0003:046D:C52B.0006/input/input12
logitech-djdevice 0003:046D:C52B.0007: input,hidraw4: USB HID v1.11 Mouse [Logitech Unifying Device. Wireless PID:1028] on usb-0000:00:1d.2-2:1
 
Jetzt maust sie.
 

owncloud 5.0

Saturday, March 16. 2013

(owncloud ist in reger Entwicklung und manches Problem, dass ich mit 5.0 sah, hat sich im Laufe der versionen schon erledigt. 
updates am Ende des Artikel.)

Heise berichtet von der eben erschienenen Version 5.0 von ownCloud und deutet auf laestig klingende upgrade-Methoden. Aber ich hab' es doch im repository... hier reicht ein apt-get update && ap-get upgrade und dann erscheint, nach Aufruf der Wolke, ein kurzer Hinweis auf das Upgrade, pling, pling,plong, pling, erfolgreich, weitergeleitet - fertig.
Erstmal login als Administrator, es sind eine Reihe neue Applications dazugekommen und ich aktiviere tasks - Antivir: hat zwar die Anmerkung "recommended", schmeisst mir aber gleich eine Fehlermeldung.
Auf den ersten Blick kommt mir die neue Oberfläche etwas dunkler vor, platzsparender und bedienbarer.
Raus und zweites Login als user, ich bekomme erst einmal minutenlang einen Verlaufsbalken mit dem Titel: "Dateisystem-Cache wird aktualisiert ..." Und dann: "Alles leer - lade etwas hoch!" :-( - da ist schon mal was verlorengegangen. Hoffentlich nur der Link...

Kurz mal durch die anderen Optionen:
Kontakte kennt auf einmal Gruppen! Schon mal ein Schritt in die richtige Richtung.
Aufgaben kennt keine hierarchischen Beziehungen zwischen tasks, also kein "Kapitel 1" .. "Kapitel n" als subTasks zu "Buch". Eine Task hat Title, Kategorie, Ort, Fälligkeit, Fertigstellung scheint Boolean zu sein. Nach Priorität kann man sortieren, aber wo man die setzt, sehe ich erst mal nicht.

Ein Blick in's forum.owncloud.org/ bestätigt, dass andere die Probleme (Dateien, Task/Priority) auch haben.
Es findet sich auch ein Hinweis auf ein Google import app.

Nach etwas stöbern und probieren sieht es für mich, was die fehlenden Inhalte in meinem ownCloud storage angeht, so aus: 
- unbegreiflicherweise sind alle Ordner, die zum Zeitpunkt des upgrade existierten, unsichtbar. Und zwar permanent und aktiv unsichtbar. Ich kann sie aus dem jwlg Verzeichnis verschieben, in der ownCloud-Oberfläche einen neuen, gleichnamigen anlegen, alles wunderbar. Ein Click auf Dateien und die Ordner sind unsichtbar. Dass sie existieren und zugänglich sind, kann man mit etwas Url-Gymnastik leicht feststellen. Aber sie werden eben nicht angezeigt.

Ok, neue Ordnernamen, gefällt nicht wirklich aber ein gangbarer workaround. Aber die Logik dahinter entgeht mir.

Es tut mir leid, das so sagen zu müssen, aber owncloud 5.0 funktioniert derzeit nur im Prinzip. Konkret erlebe ich dagegen einen Sack von Unzuverlässigkeiten, Funktionsausfällen, Überraschungen dass ich es derzeit allenfalls als Ergänzung zu den Google-Diensten nutzen kann, aber nicht als deren replacement.

Update:
Mit einiger Mühe hatte ich 5.0 dann letztlich doch in grundsätzlich funktionierendem status, 5.03 brachte dagegen einen markanten Sprung nach vorn, die erste Version, wo "Bilder" für mich nicht völlig kaputt aussieht....

Update
5.04 ist eben installiert und macht einen weiter verbesserten Eindruck. Allerdings ist auch nur ein rudimentäres subset der Features hier wirklich in Gebrauch, letztlich nur webdav / files. Kontakte sind bei google eben doch noch weit flexibler mit dem tagging zu Gruppen und der sync zu Thunderbirds Adressbuch. Und bislang habe ich noch keinen praktikablen weg gefunden, Kontaktbilder von Google nach owncloud zu ziehen. Nur schade, dass viele der drittseitigen Apps mit 5.x gar nicht laufen.   

Update
5.05 nennt sich selbst in der config.php 5.0.6, aber das war wohl auch bei der Vorversion schon so. Die "Geister" in Musik und Dateien gab es immer noch, daraufhin habe ich mit apt-get purge owncloud und brutaler Gewalt gegenüber der config.php und den Tabellen der mysql-db eine komplette De- und anschliessende Neuinstallation erzwungen. Seither funktionieren Bilder und Musik deutlich besser.

Update 15.5.2013
owncloud hat ganz offenbar eine interne Versionierung, die der veröffentlichten vorauseilt. Außen drauf steht 5.0.6 und so heisst auch das debian package (5.0.6-0) - aber die config.php nennt sich schon 5.0.8'  Das Upgrade selbst geht mit apt-get locker, anschliessend akualisiert sich OC mit dem ersten Aufruf der Seite im Bowser. Kein Problem dabei.
Ich benutze von den Modulen ja faktisch nur Dateien. weil mir für Kalender, Kontakte und Tasks die Synchronisierung mit den entsprechenden Google-Diensten fehlt, Musik geht nicht im Hintergrund weiter. Bilder funktioniert seit 5.0.5 besser als zuvor, ist aber immer noch etwas verwirrend. Der beklagt langsame Upload ist wohl wirklich schneller geworden, wie das release note aufführt, ich habe wie im Testszenario mp3's hochgeladen, über https://, allerdings im intranet. 446 MB in 90 sec. Upload über externe Verbindung steht noch zu testen aus.

Update 17.8. 2013
Owncloud ist bei mir nun schon mehr als einen Monat auch für Kontakte und Kalender an die Stelle von Google getreten und abgesehn von der mühsamen Migration der Kontakte und nur eingeschränkter Unterstützung der Gruppierung von Kontakten im neuen Thunderbird-Addon ist alles wunderbar. Immer mal kommt eine neue Version, derzeit 5.0.10 aber die anfangs teils holprige Update-Prozedur geht inzwischen locker durch.

 

Porteus vom usb

Saturday, December 29. 2012

Schnell ist es ja. Wenn auch nur beim Booten.
In kaum einer Minute vom Einschalten bis in den KDE-Desktop (Trinity ~KDE 3.5), und das auf einer alten acer Travelmate 4060-Büchse ohne HD von einem 0815-usb. Und dabei sind mindestens 5, vllt aber sogar 15 sec. warten auf ein Timeout noch inklusive - das ist aber deutlich was schneller als der vorige Anlauf mit Mint.
Wenn man es erst mal zum Starten gebracht hat, und auch danach gilt: holp'rige Wegstrecke.

Porteus ist Kindeskind von Slackware, graue Eminenz der Distributionen. Meine erste Linux-Installation war ein Slackware, stilecht auf einem 386SX so circa 1997. Linux zu installieren war damals eine ziemlich frustrierende Angelegenheit, um es vorsichtig auszudrücken. 

Porteus sagt von sich, eine Distribution zu sein, die darauf optimiert ist, von Medien wie einem USB-Stick sehr schnell zu booten. Wie bringe ich Porteus bootfähig auf einen Stick? Da ist die Doku ganz klar: 

  • .iso herunterladen, auf cd brennen
  • Rechner von der CD-Rom nach Porteus booten
  • usb-Stick einstecken
  • Porteus Installer machen lassen

Fein, dass mit dem neu booten übertrage ich einer vbox - vm aber davon ab folge ich der Anleitung wortwörtlich. Ergebnis: geht nicht.
Den Reminder angeklickt und Bootloader installieren ausgewählt, das Ding (ziemlich lange) machen lassen, bis es mir Erfolg meldet und dann den Laptop vom stick booten - und er benimmt sich, als sei überhaupt kein boot loader vorhanden. not a bootable disk.

Aus seiner Vorgeschichte misstraue ich dem stick etwas und formatiere ihn (vfat) neu. Wiederhole die vorigen Schritte, hat nichts geholfen.
Kurz gegoogelt und die Sache zu Fuss unternommen. 
Ja, hagelt es eine Ladung roter Fehler, md5 hash fail. Google drauf, finde http://forum.porteus.org/viewtopic.php?f=41&t=1378
K
urzversion: am 10.7.2012 bestätigt der Guru dieser Distri, dass er da in der Datei md5sums.txt irgendwie die falschen Pfade erwischt hat. 
Mein Download war am 28.12, satte 5,5 Monate später, und der bestätigte Bug ist unverändert drin. 

Der empfohlene workaround war ohnehin, die roten Fehler schlicht zu ignorieren unde weiter zu machen. Was ich auch tat, nur um nun beim nächsten Bootversuch Fehler analog dieser Beschreibung zu bekommen:

 

SYSLINUX 4.04 CHS 2011-04-18 Copyright (C) 1994-2011 H. Peter Anvin et al
ERROR: No configuration file found
No DEFAULT or UI configuration directive found!
(bei mir war es SYSLINUX 4.05)
 
Der Poster meldet am Ende des Threads, er sei nun darauf gekommen, dass Syslinux auf seinem Rechner fat-32 nicht erkennt, mit fat-16 ging es. Fat-16 war mir nun wirklich zuviel an Erniedrigung aber ich beschloss, seinen Tip doch aufzugreifen und meinen Stick mal wieder neu zu formatieren, zur Abwechslung mit ext3. Anschliessend /boot und /porteus vom .iso auf den Stick kopieren, den Bootloader mit 
/boot/lin_start_here.sh
installieren, Test-Boot und Bingo!, auf einmal kommt die Kiste hoch. Sauschnell, siehe oben.
 
Ländereinstellung (deutsches Tastatur-Layout) sind nicht von einer Sitzung zur nächsten persistent.
Trinity hält sie aber wenigstens während der laufenden Session bei, während unter LXDE das US-Layout schon nach wenigen Mouseclicks wieder zurückkehrt. Porteus-Settings nimmt sich desbezüglich einige Zeit, ändert letztlich aber gar nichts am Ablauf.
 
Nur Google aus dem Network-Package zu installieren geht schief. Es kommt (kurz)= eine MsgBox mit einem Hinweis auf Misserfolg beim Anlegen des Profile und dann segfaults Chrome. Mit dem mc im Dateisystem herumspazierend fallen mir dann diverse zerbrochene Symlinks unter / auf libs unter /usr/lib/seamonkey auf. So sensibilisiert entdecke ich im Network-Package dann die Seamonkey shared libs, die aktiviert und auf einmal geht Google Chrome auch. 
Unter LXDE schafft es Google-Chrome mehrfach nicht, die Settings mit dem Google-Account zu synchronisieren, das ding lädt und lädt und lädt... Zurück auf Trinity/KDE klappt es aber.
 
Also im ersten Eindruck: mehr als nur ein paar ungeschliffene Ecken sind schon dabei...
 

 

 

(Page 1 of 8, totaling 36 entries) » next page