Posts mit dem Label openSUSE werden angezeigt. Alle Posts anzeigen
Posts mit dem Label openSUSE werden angezeigt. Alle Posts anzeigen

Mittwoch, 9. August 2017

Yahoo authentication failed in KMail 5.5.2 on openSUSE leap 42.3. The solution....

Zuerst ist es mir gar nicht aufgefallen, aber mein Yahoo IMAP Mailkonto wurde über KMail 5.5.2 in openSUSE leap 42.3 - im Gegensatz zu openSUSE leap 42.2 nicht mehr synchronisiert.
Es kam zwar eine Fehlermeldung, das scheinbar die Zugangsdaten nicht richtig sind, diese kam aber auch alle heiligen Zeiten mal in der Vorgängerversion. Diese hab ich zumeist ignoriert, denn nach einem Neustart war alles wieder o.k. Da über dieses Konto selten Emails laufen, bestand auch kein dringender Handlungsbedarf.

Doch nun scheint es als wäre ich mit KMail völlig von Yahoo ausgesperrt. Android-Mail (auf meinem Smartphone) hat mit Yahoo Mail keinerlei Probleme. Ebenso funktioniert der Einstieg über die Webseite völlig reibungslos.
Auch Änderungen an der Authentifizierung in KMail (Port, SSL/TLS, PLAIN, Klartext,...) brachten keinen Erfolg.

Zu erwähnen ist auch, dass GMX und GMAIL weiterhin ohne Probleme funktionieren.


Lösung:
Die Lösung fand ich als ich mich über den Browser in mein Yahoo Mail einloggte. Hier kam wie gewohnt gleich einmal die Sicherheitsmeldung "externe Zugriffe" zu unterbinden. Gemeint sind hier Android-Mail und dergleichen.

Unter dem Menüpunkt "Account-Info / Account-Sicherheit" fand ich den Eintrag "App-Passwort-Generator". Hier wählt man aus einer Reihe von Apps das Richtige aus, beziehungsweise erstellt einen neuen Eintrag. Mithilfe des erstellten Passwortes, welches anschließend in KMail unter "Benutzernamen / Passwort" eingetragen wird (anstelle des üblichen Passwortes), ist bereits der erste Schritt getan. Nun muss nur noch in KMail bei "Authentifizierung" NTLM ausgewählt werden.
(was NTLM ist findet man hier )











... und schon ist der Yahoo-Account wieder bereit!



Diese "Zwei-Schritt-Authentifizierung" ist von Yahoo zwar nett, aber etwas im Verborgenen.

Roman.

Donnerstag, 27. Juli 2017

openSUSE leap: Upgrade from 42.2 to 42.3

Gestern erschien die neueste Version von openSUSE leap - 42.3.

Die Vernunft sagt einem, dass man besser immer etwas zuwartet mit dem Upgrade. Erste Bugs sind dann eventuell bereits beseitigt.

Doch wie heißt es so schön - "Der Geist ist willig nur der Körper ist schwach!"

So machte ich mich bereits ein paar Stunden nach der Veröffentlichung ans Werk um das Upgrade durchzuführen.

Ich wählte dabei das gleiche Vorgehen wie beim Upgrade von 42.1 auf 42.2 .
(For upgrading 42.2 to 42.3 I used the same procedure like 42.1 to 42.2 )

Alles lief reibungslos. Nach einem Download von mehr als 4100 Paketen und einem Reboot startete openSUSE leap 42.3. Alle Systemeinstellungen wurden übernommen. Sogar das von mir nachträglich konfigurierte Wlan (rtl8723be - dazu gab es einen Blogeintrag) war sofort wieder startklar.
(After download of more than 4100 packages and one reboot the system works well. All system-settings are remained intact.)

Roman.



Update 28.07.2017:

Aufgrund eines Kommentares beim Blogeintrag 42.1 auf 42.2 möchte ich nochmals darauf hinweisen, dass es sehr wichtig ist alle die dort beschriebenen Schritte auch in deren Reihenfolge auszuführen. Auch ist beim Bearbeiten der Repos nur der "2" von 42.2 auf einen"3" (42.3) zu ändern - sonst bleibt der Link des Repos unverändert.

Dann sollte es reibungslos klappen und nach einen Reboot in der Systeminfo folgendes Bild erscheinen:



Das System läuft nach einem Tag immer noch ohne Probleme. Optisch - bis auf etwas buntere Plasma-Icons - kein Unterschied. Doch merkt man vor allem bei akonadi (Mail, Kalender,..) eine Performance-Steigerung!

Roman.



Montag, 27. Februar 2017

How to fix the rtl8723be (Realtek-Wifi) problem on openSUSE leap 42.2

Da mein altes Notebook mir bereits seit 8 Jahren dient, ist es natürlich in die Jahre gekommen. CPU und GPU sind für ein Linuxsystem mit KDE-Oberfläche noch mehr als ausreichend, aber an der Peripherie merkt man doch deutlich das Alter. So gibt es einige Gebrauchsspuren. Der Rand des Displays hat einen Sprung im Plastik. Der Akku - dieser wurde bereits einmal ausgetauscht - hält keine Stunde mehr. Der Lüfter ist nervig laut geworden - ein Ersatz würde ca. € 45,- kosten. Nicht viel Geld, aber in ein so altes Gerät noch investieren?

Also musste ein neues Notebook her. Da ich aber meinen Desktop PC als Haupt-PC nutze aber mein Notebook nur für Office-Anwendungen und Vorträge, hatte ich diesbezüglich keine großen Ansprüche. Deshalb entschied ich mich für ein kostengünstiges Einsteiger-Notebook von HP. AMD A6 Prozessor, 4 GB RAM, 1 TB HDD, DVD Laufwerk, 15,6 Zoll Display mit 1920x1080 Auflösung, sollten für meinen Gebrauch reichen. Mit einem Gewicht von 2,4 Kilogramm ist es dazu noch knapp mehr als einen Kilogramm leichter als mein altes Notebook. Weiters entschied ich mich absichtlich für ein Gerät ohne vorinstalliertem Windows.
Eine Internet-Recherche ergab, dass es mit der AMD  A-Reihe keine Probleme seitens Linux gibt, und deshalb war es rasch bestellt. Auch fand ich HP - hier vor allem im Druckerbereich - den Linuxusern immer sehr entgegenkommend (Bereitstellung von Treibern).

Am Gerät selbst gibt es nichts zu meckern. Alles so wie bestellt.

Konfiguration:

OpenSUSE leap 42.2 wurde mittels bootfähigen USB-Stick ohne Probleme installiert.

Doch bei der Konfiguration der Wlan-Verbindung wollte es nicht so recht klappen. Über YasT / Hardware fand ich heraus, dass es sich um einen rtl8723be Wifi Chipsatz handelt. "hwinfo" und "lspci" brachten auch keine anderen Ergebnisse. In den Standardrepos gab es keine extra Firmware dafür. Eine Internetrecherche ergab, dass dieser Chipsatz von Realtek jedoch seit Kernel 4.2.x unterstützt wird - also auch bei openSUSE leap 42.2.

Also holte ich mir über das openSUSE Softwareportal (rtl8723be in Suche eingeben) ein Repo mit der neuesten Firmware.
Doch auch das brachte keinen Erfolg.
Das Wlan funktionierte - aber nur mit einer Reichweite von ca. einem Meter Abstand vom Router. Danach brach die Verbindung ab.

Eine weitere Internetrecherche brachte die Lösung: Das Problem lag am Setup der "Antenne" der Wlan-Karte. Mit Hilfe dieser Anleitung konnte ich mein Problem lösen.

Man geht wie folgt vor:

Konsole/Terminal öffnen und "root-Rechte" erlangen (mittels su und Passwort für root).

Danach folgende Befehle eingeben:

 modprobe -rv rtl8723be   (Enter)

modprobe -v rtl8723be ant_sel=1  (Enter)  

Damit das Setup auch nach einen Neustart bestehen bleibt, gibt man folgenden Befehl ein:

echo "options rtl8723be ant_sel=1 fwlps=0" | tee /etc/modprobe.d/rtl8723be.conf

Danach nur noch:

modprobe -r rtl8723be

modprobe rtl8723be


Fertig! Nun sollte das Wlan anstandslos funktionieren.

Sollte es nicht funktionieren kann man noch alternativ  ant_sel=2 oder ant_sel=0 ausprobieren. In der von mir im Internet gefundenen Anleitung war zum Beispiel ant_sel=2 der Schlüssel zum Erfolg. Bei mir war es ant_sel=1.
Dieses Antennen-Setup scheint daraus zu resultieren, da Wlan und Bluetooth ein und dieselbe Schnittstelle bzw. Adapter sind und der Treiber an der Einstellung scheitert.

Mein Wlan funktioniert nun einwandfrei. Die Reichweite ist ausgezeichnet.

Auf der Webseite von HP fand ich dazu leider keine Lösungsansätze.

Roman


Donnerstag, 15. Dezember 2016

Screenfetch - a nice bash tool on openSUSE leap 42.2

Screenfetch ist ein nettes kleines Tool zur Darstellung eines Systemüberblickes im Terminal (bash). Screenshots davon habe ich schon öfters mal bei Twitter und Co. gesehen, wurde aber jetzt erst bei intux.de zufällig fündig.

Bei openSUSE leap 42.2 liegt es bereits in den Standardrepositorien auf und ist daher lediglich über YasT / Software installieren oder mittels zypper install screenfetch  (in der Konsole mit root-Rechten) zu installieren.



Danach öffnet man die Konsole und gibt den Befehl screenfetch ein.



Je nach Farbeinstellung (Profil) der Konsole ist das Erscheinungsbild unterschiedlich.



Fällt eindeutig unter "klein aber oho"!

Danke an intux.de!

Roman.


Montag, 28. November 2016

Snapshot management with Snapper claims a lot of space in the root partition on openSUSE leap 42.2

Das System Recovery Tool "Snapper" ist bereits seit openSUSE 12.1 Teil der Distribution. Es werden damit automatisch sogenannte Snapshots - also Wiederherstellungspunkte - erstellt.

Ausführliche Erklärung zu Snapper

Es war mir bis jetzt noch nie in diesem Maße aufgefallen, doch ließ mich die Größe meiner root-Partition nach dem Upgrade auf openSUSE leap 42.2 zweifeln. Von der automatisch angelegten Größe von 40 GB für /root  waren nur noch knapp 7 GB frei. Normalerweise hat meine root-Partition ein Volumen von 10 bis max. 15 GB.

Das Übel wurde rasch gefunden. Es waren die Snapshots. Denn es waren auch noch alle Snapshots von openSUSE 42.1 vorhanden.

Diese konnten über Anwendungsmenü / Yast / Snapper / gelöscht werden. Nur die letzten 3 Snapshots von der langen Liste ("vorher&nachher" und einmal mit "important=yes" markiert) behielt ich. Standardmäßig behält sich openSUSE leap 42.2 die 10 letzten Snapshots.

Nach dieser Aktion waren wieder mehr als 27 GB auf meiner root-Partition frei.

Roman.


Moving of /var/cache to a separate subvolume - openSUSE leap 42.2

Wenn man auf openSUSE 42.2, so wie ich hier beschrieben habe, das Upgarde durchführt, wird seitens openSUSE empfohlen /var/cache in ein eigenes Subvolumen zu verschieben.Bei einer kompletten Neuinsatllation ist dies nicht nötig!

Wie dies durchzuführen ist, kann man hier unter Punkt 3 Move /var/cache to a separate subvolume auf der openSUSE Webseite nachlesen. Es ist ganz einfach. Man öffnet die Konsole (Terminal) - erlangt root-Rechte - und führt Punkt für Punkt aus. Man gibt die jeweiligen Befehle per Copy and Paste ein und bestätigt mit Enter. Ich z.B. hatte keine Datei mit /var/cache.old.

Ist man bei dem Absatz "....entry to /etc/fstab for the new /var/cache subvolume......" angekommen, so hilft vielleicht die folgende kurze Beschreibung:

Über das Anwendermenü / System / File Manager - Super User mode / wird der Dateimanager Dolphin mit root-Rechten geöffnet. Über Basisordner / etc / gelangt man in den etc Ordner, in welchen sich die Datei fstab befindet. Diese wird mit Doppelklick geöffnet.

Hier habe ich die Zeile

UUID=821........cc..........e-ea......acc......bfd..  /var/tmp btrfs subvol=@/var/tmp  @ @

einfach kopiert und am Ende der Auflistung wieder eingefügt. Anschließend werden in der neuen Zeile die Wörter "tmp" durch das Wort "cache" ersetzt und fstab gespeichert. Dolphin wird anschließend geschlossen und in der Konsole der letzte Befehl von der openSUSE Webseite ausgeführt. Nach einem Neustart ist /var/cache in ein eigenes Subvolumen verschoben worden. Dies soll deshalb wichtig sein, da durch Snapshots des Tools Snapper das Datenvolumen in /var/cache rasant ansteigen kann.

Roman.

Sonntag, 20. November 2016

openSUSE leap: Upgrade from 42.1 to 42.2

Nach rund einem Jahr war es wieder so weit und eine neue Version von openSUSE leap ist erschienen.Die 42.2´er Version wurde veröffentlicht.

Also Zeit das Upgrade durchzuführen.

Das Upgrade der 13'er Versionen habe ich  hier in meinem Blog ausführlich beschrieben. Dies ist bis heute auch die meistbesuchte Seite in meinem Blog.

Das Upgrade von 13.2 auf leap 42.1 führte ich nicht so durch, da sich openSUSE leap bereits im Grundaufbau komplett von den bisherigen Versionen unterschieden hat. Ich wählte eine Neuinstallation.

Nun aber, da dies nur ein Upgrade von "leap zu leap" war, wählte ich wieder die Methode mit "zypper". Allerdings in leicht geänderter Form.

Upgrade:

Einfach aus Interesse wählte ich eine Mischform aus "Yast" und "zypper". Es erspart eine Tipparbeit in der Konsole und ist dadurch für "Laien" nicht so abschreckend.

Los gehts!

Zuerst wichtige Daten sichern, oder das gesamte Betriebssystem! (z.B. mit Clonezilla)

Über das Anwendermenü und Yast gehts zu den Repositorien (root-Rechte erforderlich!):


Hier löschen wir alle eingebundenen Repositorien außer diese:


Non-Oss, Oss, Update und Update Non-Oss bleiben erhalten!!

Danach verlassen wir Yast und öffnen die Konsole. Erlangen root-Rechte (Administratorrechte) mit dem Befehl "su" und der anschließenden Passworteingabe (diese sieht man beim Tippen nicht!!).

Es folgt der Befehl "zypper ref" (mit Enter bestätigen)

Hier werden die (noch verbliebenen Repos) aktualisiert.



Danach der Befehl "zypper up" (mit Enter bestätigen)

Hiermit wird das System auf den neuesten Stand gebracht. Die Aktualisierung muss mit einem "j" für "ja" bestätigt werden.

Ist dies geschehen, so verlassen wir die Konsole wieder und gehen zurück zu den Repositoren mittels Yast.



Nun klicken wir jedes einzelne Repo an und öffnen es mittels den "Bearbeiten" - Button. Das Fenster "Server und Verzeichnis" erscheint. Nun ersetzen wir einfach 42.1 durch 42.2 sowohl in der oberen, als auch in der unteren Zeile.
Wie gesagt, diese Änderung führen wir bei allen vier Repositorien durch. Dabei ließt sich das System stets beim neuen Server ein. Beim letzten Repo muss die Lizenzvereinbarung mittels "Weiter" bestätigt werden.

Nun wieder raus aus Yast und rein in die Konsole. Wieder root-Rechte mittel "su" und Passwort.erlangen.

Es folgen die Befehle:

  •  "zypper clean --a" (mit Enter bestätigen) (hierbei werden die Repos bereinigt)
  •  "zypper ref" (mit Enter bestätigen) (hier werden die Repos neu eingelesen)


                                                             
Nun folgt der Upgrade-Befehl "zypper dup" (mit Enter bestätigen)

Nach zwei bis drei Bestätigungen mit "j" für "Ja" und durchgelesenen Lizenzen (diese können mit "q" übersprungen werden) beginnt der Download der neuen Pakete.



...und es läuft und läuft.....

Ist der Download beendet so wird gleich in der Konsole der Befehl "reboot" eingegeben. Das System startet neu, und wenn alles glatt gelaufen ist, ist das Upgrade ist vollbracht.


In der Systeminformation sollte nun 42.2 zu sehen sein mit der KDE 5.8.2 Version.


Nun kann man wieder über Yast / Repositorien gewünschte zusätzliche Repos (für Multimedia etc,..) einbinden (zumeist über Hinzufügen / Community-Repos).

Ich hoffe das Alles gelingt!

Roman.

Samstag, 1. Oktober 2016

Creating private shared folder on openSUSE Leap 42.1 with KDE (Plasma 5)

Unlängst unterhielt ich mich mit Didi von Didis Blogazo (über unseren XMPP Klient) über Ordnerfeigaben auf ein und demselben PC. Also nicht im Heimnetzwerk oder ähnliches.
Didi erstellte dazu einen Blogeintrag: Gemeinsamer Ordner mit Samba...

Ich hatte es jedoch in der Zwischenzeit bereits selbst gelöst. Möchte jedoch, inspiriert durch Didis Eintrag, auch meinen Weg darstellen.

Aufgabe:

Es sind auf einen PC mehrere Nutzer. Alle haben einen eigenen Zugang. Z. B. jedes Familienmitglied hat einen eigenen Account auf einen gemeinsamen PC.
Nun sollen sich zwei Nutzer einen Ordner teilen dürfen, die anderen Nutzer sollen darauf aber keinen Zugriff haben.

In meinem folgenden Beispiel sollen "roman" und "familie" Zugriff auf einen gemeinsamen Ordner haben, "max" soll dieser Zugriff jedoch verwährt bleiben.

Da alle neuen Nutzer automatisch der Gruppe "user" angehören, würde bei der Möglichkeit von Didi aber auch "max" Zugriff auf den Ordner haben.

Deshalb muss man eine zuvor eine neue Gruppe erstellen!
Über YaST gelangt man zur Gruppenverwaltung.



Nach dem öffnen der Gruppenverwaltung sieht man die angemeldeten Nutzer mit der Gruppenanghörigkeit.


Über den Reiter Gruppe und "Hinzufügen" legt man eine neue Gruppe an. Wählt einen Namen aus (man kann frei wählen - hier in meinem Fall "Datenaustausch") und fügt die gewünschten Gruppenmitglieder hinzu.


Nach "OK" sieht man bereits die neue Gruppe und deren Mitglieder.


YaST wird geschlossen und der Dateimanager Dolphin geöffnet. Nun wird ein neuer Ordner (der neue gemeinsame Ordner) erstellt. Hier z. B. "Sammelordner". Danach wird Dolphin wieder geschlossen und im "Super-User-Mode" (also mit root-Rechten) geöffnet.



Über "Orte - Basisordner - home - roman" gelangt man zum angelegten Sammelordner und öffnet ihn mit Rechtsklick und "Eigenschaften".


 Unter "Berechtigung" gibt man der Gruppe auch die Möglichkeit für "Anzeigen & Ändern des Inhalts möglich", ebenso ändert man bei "Eigentümer" die Gruppe auf die neu angelegte Gruppe (in meinem Fall auf "Datenaustausch").


 Bei der Einstellmöglichkeit "Erweiterte Berechtigung" fügt man eine "Benannte Gruppe", in  diesem Fall "Datenaustausch" hinzu. Diese und der Eintrag "Maske" sollte mit drei grünen Häkchen versehen sein. Ebenso der Eigentümer und die Eigentümer-Gruppe. "Sonstige" erhält keine Häkchen.



Nun wird Dolphin geschlossen und als "normaler User" wieder geöffnet, sowie eine Testdatei angelegt.


Dolphin wird geschlossen und eine neue Sitzung über "Menü (Anwendungsstarter) - Sitzung - Neue Sitzung" gestartet (Wechsel des Benutzers). In meinem Fall starte ich den Benutzer "familie".

Hier wird Dolphin normal gestartet. Über "Orte - Basisordner - home - roman" wird der Sammelodner angezeigt. Dieser wird per Drag & Drop in "Orte" integriert.



Der "Sammelordner" kann geöffnet, die Daten darin verwendet und gegebenenfalls auch gelöscht werden. Möchte man jedoch z.B. eine Textdatei öffnen, bearbeiten und wieder speichern klappt dies nicht. Die Rechtevergabe verbietet dies. Man muss zuvor die Datei herauskopieren - bearbeiten - und anschl. wieder in den Sammelordner speichern.



"roman" und "familie" können sich nun einfach Daten wie z.B. Fotos oder Videos teilen.

Nun wird wieder eine neue Sitzung gestartet - der Benutzer "max". Auch bei "max" wird Dolphin normal gestartet und versucht über "Orte - Basisordner - home - roman" den Sammelordner in "Orte" einzufügen. Hier fällt sofort auf, dass der Sammelordner nun mit einem Schlosssymbol versehen ist. Es ist möglich ihn in "Orte" zu integrieren (dabei verschwindet das Schlosssymbol), aber möchte man ihn öffnen wird der Zugriff verweigert.


"max" ist nicht Gruppenmitglied der Gruppe "Datenaustausch" und kann deshalb auf den Sammelordner nicht zugreifen.

Die Aufgabe wurde erfolgreich gelöst.

Roman.

PS: Danke an Didi, der sich meines Problems rasch angenommen hat.


Donnerstag, 28. Juli 2016

Which OCR tool works well on openSUSE Leap 42.1? - Here is a brief overview.

OCR  (optical character recognition) ist eine automatisierte Texterkennung. Texte in gescannten Bildern können erfasst werden und anschließend in eine Textdatei umgewandelt werden, wodurch diese bearbeitbar sind. Dies braucht man selten, aber doch.
Welches dieser Programme unter Linux, speziell bei openSUSE, effizient arbeitet, zeigt der folgende kurze Überblick:

Ausgangspunkt ist eine Textdatei in deutscher Sprache aus Wikipedia, die auf meinem HP Deskjet 2050-J510 series mit 300 dpi (grayscale) ausgedruckt wurde und anschließend mit 300 dpi (Graustufen) wieder mit dem HP Deskjet eingescannt wurde. Es wurden bewusst unterschiedliche Schriftgrößen verwendet und auch das eine oder andere Wort in englischer Sprache. Der Treiber des HP "All-in-one" kommt von hplip.


Testtext:



XSane:

Um einen Scanner unter Linux zu betreiben führt der Weg an XSane kaum vorbei. Auch dieses Tool kann mit Texterkennung umgehen. XSane benötigt dazu aber die Pakete "gocr" und "gocr-gui" aus den Standard-Repos.



"Text" wählen und die anschließend gescannte Datei als.txt Datei speichern. Das Ergebnis ist jedoch mehr als fraglich. Kaum ein Wort wurde richtig erkannt.





gimageReader

gimageReader ist eine grafische Oberfläche (GUI) von tesseract . Es ist in den Standard-Repos nicht enthalten, und muss über die Paketsuche eingebunden werden (als instabiles Paket). Es ist jedoch voll funktionstüchtig. Natürlich muss dazu auch tesseract installiert sein.




Auch hier wird der Text mit 300 dpi gescannt. Anschließend mit "Text erkennen" überprüft.


Ich habe das Ergebnis in ein LibreOffice Writer Dokument kopiert, verbessert und anschließend als .pdf gespeichert. Das Ergebnis ist hier bereits viel besser. Die rotmarkierten Stellen sind Fehler der Texterkennung. Typische Fehler sind Namen, Satzzeichen,...





Tesseract

Tesseract ist ein Tool rein für die Kommandozeile. Es liegt in den Standard-Repos vor und funktioniert einwandfrei. Das Ergebnis ist ident mit dem von gimageReader (natürlich, denn gimageReader arbeit ja mit tesseract).
Nun ist aber die Hürde mit der Konsole zu arbeiten für manche zu groß. Noch dazu ist im Jahre 2016 eine GUI für ein Programm kein Luxus mehr.



Online Dienst: Free Online OCR

Ein Beispiel für einen Web Dienst zu diesem Thema ist Free Online OCR . Hier habe ich den Testtext gesannt und in eine .pdf Datei umgewandelt. Diese wird hochgeladen und nach nicht mal einer Minute hat man die fertige Textdatei. Wahlweise .txt oder .docx. Ich habe wieder das Ergebnis (.txt) in ein LibreOffice Writer Dokument kopiert, verbessert und als .pdf gespeichert. Das Ergebnis ist das Beste meiner kleinen Testreihe. Die Fehler sind wieder rot gekennzeichnet.



Proprietäre und Open Source Software:

Natürlich gibt es noch einige proprietäre Software-Tools, auf diese möchte ich aber nicht weiter eingehen. Mein Interesse liegt doch eher bei Open Source.

Bei den Open Source Tools sollte Transkribus nicht unerwähnt bleiben. Dieses Tool befasst sich vor allem mit handgeschriebenen Texten (dazu fällt mich gleich die automatisierte Briefsortierung bei der Post ein). Dieses habe ich jedoch nicht getestet. 


Fazit:

Trotz einiger Möglichkeiten, installierbare Open Source OCR Tools zu nutzen, fällt mein Ergebnis doch eindeutig aus. Der Onlinedienst "Free Online OCR" hat die beste Erkennung und somit das beste Ergebnis.

Roman.

Dienstag, 3. Mai 2016

Plasma 5 includes a new kind to run applications

Das neu inkludierte - für KDE völlig untypische - Startermenü des Plasma 5 Desktops sollte nicht unerwähnt bleiben.

Mittels Rechtsklick auf das KDE Startersymbol öffnet sich der Menüentrag "Alternativen...". Dieser wird anschließend geöffnet.





Mit der "Anwendungsübersicht" bekommt man ein Startermenü in dem eine ganze Menge "Gnome-Look" steckt.
Nach dem (Links)-Klick auf das KDE-Startersymbol erscheint nun für KDE-Nutzer ein doch ungewohntes Bild.


Jedoch, diesem Launcher fehlt es an nichts. Er präsentiert sich sehr übersichtlich, reagiert flott und hat seit dem ersten Tag noch nicht einmal eine Fehlfunktion gezeigt.

Mal etwas Anderes, wenn nicht sogar Innovatives.

Roman.

Mittwoch, 20. Januar 2016

Amazon Video Streaming with Linux (openSUSE)? With Google Chrome now it works well out of the box!

Nachdem in meiner Umgebung in den letzten Jahren das große Schließen sämtlicher Video- und DVD-Theken sehr rasch vorangeschritten ist, blieb auch mir nichts anderes übrig, als mich für Streaming-Dienste zu interessieren.

Darunter natürlich auch das Angebot von Amazon Video, welches sich aber unter Linux nicht streamen ließ (fehlendes Silverlight Plug-in). In diversen Foren fand ich Anleitungen wie es mittels "Pipelight" und sonst noch einigen "gewurschtl" (österreichischer Dialekt) zu schaffen sei. Das war mir aber irgendwie zu doof.

Ich probierte es dennoch (ohne Pipelight) aus. Es funktionierte natürlich nicht. Ich schrieb an Amazon, argumentierte meine Probleme, und bekam auch prompt mein Geld zurück. Das sollte nicht unerwähnt bleiben.

Auf der Amazon Homepage, unter Hilfe, findet man auch die Rubrik " Streamingprobleme mit dem PC ".
Unter Linux jedoch wenig hilfreich.

Doch vor ein paar Tagen, stolperte ich über einen Eintrag in einem Forum, dass es nun auch unter Linux mit dem Google Chrome (nicht Chromium) Browser möglich ist das Amazon Video Angebot zu nutzen.

Nun  gleich vorweg, ich bin auch kein Fan von proprietärer Software und cloused Source, aber einen Blog auf Googles Blogger zu betreiben und dann über den Chrome-Browser herzuziehen wäre doch mehr als scheinheilig. Deshalb wollte ich es ausprobieren.

Installation:

Es ist nicht ganz einfach den Google Chrome Browser zu installieren. Ein kleiner Zwischenschritt ist nötig.

Am besten zuerst einen Ordner auf /home anlegen. (zum Beispiel "Google Chrome"). 

Auf die Google Chrome Webseite gehen und die Linux-Datei, bei mir die 64-bit rpm. (Fedora/openSUSE) , downloaden und in den erstellen Ordner legen.

Dann ein Terminal (Konsole) öffnen und folgenden Befehl eingeben:

wget https://dl.google.com/linux/linux_signing_key.pub

...mit Enter bestätigen und anschließend diesen Befehl eingeben:

sudo rpm --import linux_signing_key.pub

...wieder mit Enter bestätigen.

Nun wird das root-Passwort abverlangt.

Warum man dies tun muss, steht hier auf der Google Website.

Dies legt einen Signaturschlüssel im /home Verzeichnis ab. Diese Signatur in den zuvor angelegten Ordner verschieben. Nun befinden sich in diesem Ordner die rpm.-Datei und die Signatur.

Diesen Ordner öffnen und mittels Rechts-Klick (ins Leere) den Menüeintrag "Terminal hier öffnen" aufrufen.


Nachdem sich das Terminal geöffnet hat, den Befehl "ls" eingeben. "ls" listet den Inhalt des Ordners auf. Dort steht nun: google-chrome-stable..... und linux signing.....

Die, wahrscheinlich farblich hervorgehobene, Datei google-chrome-stable..... noch im Terminal mit der Maus kopieren.

Nun unter openSUSE den Befehl      zypper in      eintippen und die Datei einfügen.

Sieht so aus : name@linux xxxx:~> zypper in google-chrome-stable..........rpm

Mit Enter bestätigen und los gehts.

(Unter Fedora ist es " yum install")

Läuft alles glatt, findet man anschließend den Browser im Start-Menü. Auch das Google-Repo wurde eingebunden.



Der geöffnete Browser:

Wie gesagt, es funktioniert "out of the box". Einloggen bei Amazon, Titel auswählen und ansehen. Der Player kann verleinert oder in Vollbildmodus eingestellt werden. Ton, Bild O.K., keine Abstürze. Einzig die Zeitspanne seines Bildschrimschoners sollte man nicht vergessen in die Höhe zu setzen.

Ich habe den Browser in den Einstellungen so ziemlich alles untersagt (Werbeverfolgung,...) was ich gefunden habe. Ob es nützt?

Nun ja, cloused Source, aber zur Zeit wohl der einzige (einfache) Weg, um dieses Angebot nützen zu können.

Roman.


Montag, 14. Dezember 2015

QupZilla Webbrowser dosen't play HTML5 Videos (Youtube) on openSUSE leap 42.1 - but I have fixed it!



Ich habe bereits in einigen früheren Posts über openSUSE Leap 42.1 mich darüber gewundert, dass der Webbrowser QupZilla (Version 1.8.7 mit WebKIt-Version 583.1) nun scheinbar keine Unterstützung mehr findet um HTML5 Videos (zumeist von Youtube) abzuspielen.

Somit blieb mir nur die Möglichkeit Youtube-Videos mit anderen Browsern, wie Firefox oder Chromium (diese hatten keinerlei Probleme mit HTML5), oder mit dem Tool SMTube von SMPlayer, welches ich übrigens sehr empfehlen kann, abzuspielen.


Ich wollte aber den Grund für diese Fehlfunktion wissen, da QupZilla unter openSUSE 13.2 kein Problem mit HTML5 hatte. Nach längerer Suche und ein bisschen Experimentieren hatte ich das Problem gefunden.


Gstreamer-Pakete:

Durch die Einbindung des Packman-Repos erhält man eine Vielzahl alternativer Gstreamer-Pakete und dadrurch die notwendige Unterstützung (vor allem) für den Multimediabereich. Hier handelt es sich per default um die Pakete "gstreamer-0_10-xxxxxxxx".


(Die Grafik zeigt nicht alle gstreamer-0_10'er Pakete! ; These arn't all packages of gstreamer-0_10-xxx!)
Diese Pakete reichen jedoch nicht für eine HTML5 Unterstützung aus!


Anscheinend benötigt QupZilla nun aber auch (warum auch immer) andere gstreamer Pakete. (die ohne Nummer). Ich habe diese Pakete zusätzlich installiert. (I have added these packages)


Da ich kein Informatiker bin, verstehe ich nicht ganz die Hintergründe. Doch scheint die Lösung ein Mix aus den "gstreamer-plugins-xxx" und den "vaapi"-Paketen zu sein.

gstreamer-plugin-vaapi

libstvaapi-wayland-1_4-1   (inklusive aller Abhängigkeiten)


Das Hinzufügen dieser Pakete brachte den gewünschten Erfolg. Ob es nun die Wayland-Plugins sind oder die gstreamer, VA-API, oder die Komination aller...? I don't know why, but now it works well!


Beim Starten von QupZilla aus der Konsole zeigt sich folgendes:



Dies deutet für mich darauf hin, dass die VA-API Pakete benötigt wurden. Auf VA-API ArchWiki konnte ich lesen, dass libav normalerweise die VA-API findet. "libav" wird benötigt zur Videdodarstellung, also war ich wohl am richtigen Weg. Für VA-API gibt es auch bei ubuntuusers einen Eintrag.


Das Ergenbis:

HTML5 Test:


Verpixelter Screenshot von Youtube:



Viel Spass mit QupZilla!

Roman.