Beiträge von Berichtigung

Ich wurde gerade von jemanden, der hier wegen eines Moderators nicht schreiben mag, darauf aufmerksam gemacht, dass du eh schon Kodi einsetzt.
Das kann DLNA.

Damit dürfte es noch einfacher sein.
Guck mal dort.
(Ich kenne dieses Kodi nicht)

Das ist mal ne komplett andere Richtung.

Weil es ein lokales Netz ist, sollte dir da paprefs helfen.
Das will erst installiert sein - braucht nun wirklich nicht jede(r).

zypper in paprefs

Damit kannst du prima Netzwerkstreaming einrichten.
Und jeder (Linux)User kann alles hören/senden.

Wenn du es damit nicht hinkriegst, gib Bescheid und mir ein wenig Zeit; dann kriegst ein Scriptchen, das das erledigt.
Dazu müsstest du alle beteiligten Versionen nennen. (Da hat sich von Version zu Version einiges geändert.)

***SOIFZZZZZ****

Es ist KEIN Defekt.
Weder einer Distribution, noch eines Browsers, noch eines Webservers.

Es ist das Zusammenspiel von Browserplugins und vom Webserver gelieferten Werbemüll.

Ich hatte schon geschrieben, dass ich mir das nach Gusto anzeigen lassen kann, oder halt auch nicht.

Ich habe es deshalb NICHT nocheinmal probiert.

Es hat sich nichts geändert.
Und es wird sich nichts ändern.

Die Erklärung gab ich dir in deinem ersten Post.
Dem ist nichts hinzuzufügen.

Außer vielleicht, dass du es nicht akzeptieren willst.
Du kannst posten wie du willst, mails senden wie du willst.
Mehr als "Es ist die Installation DEINER Plugins in DEINEN Browsern"
und "Wir haben nichts geändert." wirst du nicht erhalten.

PUNKT!

Lies mal lieber die AGBs des Providers.
Vielleicht wird dir dann klar, was die alles einbauen (dürfen),
und warum dann die Seite oft nicht angezeigt wird.

Also ich würde ja fast meinen wollen, dass so harte Tasten tatsächlich was mit Hardware zu tun haben könnten.
Und wenn so ein komisches Ding losrennt, dann tut es doch irgendwie mit der Hardware rummachen, oder täusche ich mich da?

Da könnte es doch glatt der Fall sein, dass man dieser Stelle auch eingreifen könnte.
Man müsste das halt mal versuchen.

Aber, es geht ja teilweise.
Da kann sowas natürlich niemals gar nie nicht sein.

Zitat

8. Bitte nur einen Link auf eine gute Diskussion alter Hasen zum Für-und-Wider von sudo bzw. Admin und Nutzer getrennt bezüglich OpenSuse.

Diese erbitterte Debatte ist schnell erklärt:

Ein su meint SubstituteUser(kontext). Jeder Prozess, der in einem Unix/Linux System läuft hat bestimmte Eigenschaften, Sicherheitsattribute und somit ein genau definiertes "ENVIRONMENT". Zu diesem Envrionment gehören einige Variablen, die die Prozessauführung steuern.
Wenn du dich anmeldest, wird ein Vaterprozess für dich mit deinen Rechten und deiner Umgebung gestartet. Alles, was du nun in dieser Sitzung (sei sie graphisch oder auf der reinen Konsole) erbt seine Attribute von diesem "Vaterprozess". Willst du nun innerhalb deines Userprozesses mit mehr Rechten arbeiten, kannst du mit su fritz den damit gestarteten Prozess mit den Rechten (und in der Ausführungsumgebung) vom User fritz laufen lassen, so du dessen Spasswort kennst. Gibst du keinen User bei su an, so wird das per default zu su root
Damit bist du dann -falls du das Spasswort kennst- der/die totale Vernichter/in.

Um am System Änderungen vornehmen zu können, muss man root sein. Manche Jobs -obwohl sie nicht so graviernde Änderungen machen- erfordern ebenfalls root- Rechte.
Damit nun der echte root nicht Hinz&Kunz alle Rechte geben muss, sie aber ermächtigen kann solche Jobs trotzdem aufzurufen, gibt es sudo.
sudo heißt SubstituteUserAndDO Ich gebe also dem aktuellen User die Root-Rechte nur für genau einen möglichst genau definierten Befehl. Den darf er dann ausführen, aber halt auch nur genau den.
Die Zuordnung von Usern zu solchen Befehlen steht in der Datei sudoers Du kannst das leicht in YaST machen. (Auch wenn man das i.d.R. anfangs erst mal nicht zufriedenstellend hinkriegt.)

Die Verwirrung rührt daher, dass die Distris hier verschiedene Wege gehen. Bei *buntu macht man alles mit sudo, da sie von Haus aus als Root-Spasswort das Spasswort des ersten erzeugten Users akzeptieren (und sogar ein Spasswort für Root gar nicht ohne Weiteres ermöglichen).
Die reine (openSUSE) Lehre verpönt solche Sicherheitsdefizite.
(Ob das wirklich ein Defizit ist, kann man trefflich debattieren...)

Jedenfalls haben sich die Distris diesbezüglich auseinanderentwickelt.
Unter openSUSE tut er Befehl sudo etwas anderes, als er unter Ubuntu tut.
Der Hauptunterschied liegt im Environment des damit gestarteten Prozesses. Bei Ubuntu wird das Environment wirklich komplett ersetzt, bei openSUSE NICHT.
Zwar funktioniert das meistens doch.
Abzuraten ist davon allemal.

Eine ganz einfache Lösung ist dieser Merksatz:
Wo auch immer du auf ein "sudo" stösst, ersetze es durch ein "su -c"!!!

Das -c meint -command. Alles, was danach folgt ist das auszuführende Kommando samt seinen Optionen und Argumenten.
Das ist das exakte Pendant zum sudo der *buntus.

Zitat

9. Welches Tutorial sollte ich für den Einstieg noch lesen?

Guck mal das da an. Wir bieten sowohl im IRC im Forumschannel ##os-forum auf Freenode Support, wie auch sehr effektiven Suppot via Mumble (braucht ein Micro). Und wir haben "Lerngruppen" mit denen wir gemeinsam in einer Konsolensitzung hacken. Man sieht dann zu, was der andere tippt. Lernen am lebenden Objekt.

Zitat von Jana

Hallo liebe Community-Mitglieder,
ich bin dann mal die Neue und begrüße euch herzlich. Ich beabsichtige, OpenSuse mit KDE zu installieren, bei der Vorbereitung dessen sind einige Fragen aufgetaucht.

1. Ich habe schon mal etwas im Forum gestöbert, daraufhin frage ich mal die alten Hasen, was momentan für diejenigen angeraten wird, die OpenSuse auch als einigermaßen bugfreies Produktivsystem nutzen möchten. Leap42.1 oder 13.2? Letzteres wird ja m. E. bis März 2016 supported.

Das ist richtig.
Es fehlt aber noch der nicht ganz unwichtige Hinweis, dass die Evergreen die Version 13.1 ist/sein wird.
"Evergreen" heißt bei openSUSE die Version mit LongTermSuport.
Von daher also auch eine Überlegung wert.
LEAP selbst läuft auf den allermeisten Maschinen hervorragend und stabil.
Ärger gibt es unter Linux öfter mit brandneuen Maschinen.
Es gibt in Linux einfach nicht so viele Tester und nigelnagelneue Hardware braucht oft eine geraume Zeit, bis sie anständig unterstützt wird. Die Hersteller lassen Linux noch immer links liegen, weshalb die Community viel Arbeit mit neuer Hardware hat, was nun mal dauert.
Hast du keine brandneue Hardware, solltest du LEAP probieren.
Gute Chancen, dass das einfach gut läuft.

Zitat

2. Aus Sicherheitsgründen sollte man vermutlich einen aktuellen Firefox benutzen. Genügen dafür die nach der Installation vorhandenen Standardrepos oder sollte ich das Repo Index of /repositories/mozilla/openSUSE_13.2 einbinden?

Du kriegst die neuen FF Versionen auch ohne dieses Repo. Manchmal dauert es halt ein wenig länger.
Wenn du mit openSUSE anfängst, rate ich von solchen Repos immer ab.
Die Standardrepos und Packman. Sonst nichts. Dann ist dein Installation sicher UND du geniesst die Sicherheit, die openSUSE schon bietet.
Neuere Versionen haben Bugs und können neue Probleme schaffen.
Tu dir das nur an, wenn du dich wirklich wehren kannst.
Da braucht man den großen Linuxrettungsschwimmerschein mit goldnem Seepferdchen.
Nimm auch Abstand von allen Home Repos.
Da braucht man noch mehr Wissen und viel Gottvertrauen.

Zitat

3. Nicht meckern: Flash-Player aus welchem Repo empfohlen? (Ja, nur mal notfalls, Chrome oder pepperflash (?) probiere ich auch.)

Flashplayer für Linux ist schon lange tot. Nimm einfach das "frehsplayerplugin". Das tut, ist rein Linux (soweit bei flash überhaupt möglich) und vergiss den ganzen Rest.

Zitat

4. Mit dem Mozilla- und dem Packman-Repo kommt es vmtl. zu Paketdoppelungen. Nun habe ich in nachfolgenden Tutorials 2 Methoden der Priorisierung gefunden:
Über den Umgang mit openSUSE Repos
SDB:Vendor change update - openSUSE
Welche Methode ist ratsamer und warum? Priorisierung per YAST -> SW-Repos -> Prio auf 20 oder Vendorwechsel?

Wie oben schon geschrieben: Erst mit Standard üben.
Du brauchst das nicht.
Ein "Vendorchange" -was keine sonderlich gute Namensgebung ist, als historische Altlast aber weiter so benannt wird- ist schlicht der Umstand, dass ein Programm umgestellt wird auf ein anderes Repo. Das kann Ärger geben, wenn man nicht genau weiß, was man tut.

Die Prios sind schlicht Zahlen. Und wie im richtigen Leben hat höhere Priorität, was eine niedrigere Nummer hat. Eben meine 1. Priorität ist am wichtigsten.
Es kommt dabei nicht auf die absoluten Zahlen an (die sind beliebig), sondern nur auf die Differenzen.
Findet sich ein Programm mit Version 1.1 in Repo A und dasselbe (also auch Version 1.1) so wird als Quelle das Repo bevorzugt, das die höhrere Prio (also niedrigere Nummer) hat.
Deshalb sollte man Packman höher priorisieren.
In Packman liegen viele Multimedia Dinge, die aus lizenzrechtlichen Gründen nicht in die Standardrepos dürfen.
openSUSE nimmt das sehr, sehr genau.
Du kannst aber alle Programme von Packman problemlos verwenden. Sie sind zum privaten Gebrauch immer erlaubt.
Du findest nichts illegales bei openSUSE oder Packman.

Zitat

5. Ist die Reihenfolge einer Softwareinstallation mit Anbieterwechsel per Terminal so korrekt? Erst Vendorwechsel und dann Softwareinstallationen oder umgekehrt oder egal?

Code

zypper ar -f <repo> <repo_alias>
zypper ref
zypper dup --from <repo_alias>
zypper in <software_pakete>

6. Wenn ich die Multimediacodecs für 13.2 so eingebunden habe
openSUSE Forums
sollte ich diese noch ergänzen entsprechend
13. Multimedia Codecs - Install Support For MP3, DVD, WMA, WMV, MOV etc.

Alles anzeigen

Wie schon gesagt: Packman hinzufügen, höher Priorisieren. Und dann einen dup --from packman (falls der Name/Alias auch "packman" ist)

Bei zypper ist ein in die Abkürzung für install. Analog dazu ist up ein update und dup ein "Distribution upgrade. Diese Benennung ist openSUSE spezifisch. Andere Distris verstehen unter upgrade etwas anderes, als es openSUSE tut.
Ein ar ist ein --add-repo Es fügt also schlicht ein weiteres Repo hinzu.
Und ein ref ist ein refresh Damit möglichst wenig Daten übertragen werden müssen, gibt es Prüfsummen und Zeitstempel für alle Repos. Ein refresh guckt also kurz, ob deine Installation noch auf dem neuesten Stand ist, und wenn nicht, lädt es die hinzugekommenen Informationen nach. Das sind alles nur minimierte Beschreibungen, um die Datenlast gering zu halten.
Ein ref wird aber automatisch gemacht (falls du nicht dran rumgefummelt hast), sobald du ein Programm installieren oder updaten willst.
Ein Update tut, was man denkt: Es installiert Updates, wenn es welche gibt.
Ein install tut auch, was man denkt: Es installiert ein Programm. Dabei wird -nach Prios geordnet- die höchste Version gesucht und installiert.

Damit gehört der Install- Befehl also nicht in die Liste. Nur deshalb, weil die vorhergehenden sich ja mit der Umstellung der Versionen befassen, der Install aber ein noch nicht installiertes Programm installiert, was ja eh nach den Prios und Versionsnummer ausgewählt wird.

Du musst also nur EINMAL ein dup --from machen, wenn du ein neues Repo hinzugefügt hast UND willst/weißt, dass du bereits installierte Programme auf das neu hinzugefügte Repo umstellen willst.

Zitat

7. Wie erfolgt eine korrekte Systemaktualisierung nach Anbieterwechsel oder Priorisierung von Repos, zypper up oder zypper dup oder zypper dup --from <alle repo_aliases>?

Durch ein schlichtes zypper up, da du ja jetzt deine Repos sauber priorisiert hast, auch nicht mehr an der Repoliste rumspielst, ist alles schon erledigt.

Es ist wirklich so einfach.

Ich nehme an, dass der Krach local erschauern soll, nicht auf Host2.
(Das wäre ja ganz schön übel für die pysikalisch anwesenden User bei Host2. Da würde die bestimmt jemand mit einer Dauerschleife der McDonalds Werbung beglücken, die Armen.)

Es gibt prinzipiell zwei Möglichkeiten Krach von einem anderen Rechner zu hören.
Entweder den Krach schlicht als Dateien übertragen, oder eben als Stream.

Ich kenne keinen Player, der Dateien von remote abspielt, aber das lässt sich leicht mit sshfs einbinden.

# als root sshfs installieren
su -c "zypper in sshfs"


# als user das entfernte Krachdirectory einbinden.


# wir brauchen ein leeres Verzeichnis irgendwo:
cd  # springt in das Home des aktiven Users.
mkdir krach   # ein Verzeichnis erzeugen, das wir als Mountpoint verwenden.
sshfs user@host2:krach/im/home  $HOME/krach # das remote Verzeichnis nach $HOME/krach mounten
#   user@host2:/absoluter/Pfad/zu/Krach 
#   ohne den / nach host2: wäre es das dortige Homeverzeichnis von user




# Player nach gusto
aplay ~/krach/monsterkrach.wav
mplayer ~/krach/lauter.mp3


# hat man genug auf die Ohren gekriegt,
# den Mount lösen.
fusermount -u krach

Willst du wirklich den Krach auf dem host2 ertönen lassen, sollte es genügen, dort alle Krachmacher zu installieren und halt einfach aufzurufen.
Jeder Player (aplay, paplay, mplayer ..., ....., ....., ) spielt ja seinen Krach eh lokal ab. Sie "öffnen" die dortige Soundkarte und spulen den Krach halt dorthin.

Für alle Mischformen ist es nicht so einfach. Dann müssen auf host2 natürlich auch die entsprechenden Soundprogramme laufen (und Soundhardware verfügbar sein).
Das wiederum lässt sich dann mit mehreren Methoden erreichen. Keine davon ist sonderlich einfach.
Da wären dann einige Fragen vorher zu klären.
Das läuft letztlich darauf hinaus irgendeinen Streamingdienst zu etablieren.
Das kann man alleine mit PulseAudio machen (ja, das kann über das Netz streamen), oder man nimmt gleich einen spezialisierten Streamserver.

Na denn.

Da du ja über genügend Wissen verfügst, dass du sogar bei einem install Fehler ignorieren kannst,
wird der Hinweis genügen:

man public

Bitte verwende nicht Pastebin. Dieser Service ist etwas verrufen, nicht immer verfügbar und findet deshalb wenig Gegenliebe.
Es gibt tonnenweise solche Pasteserver. Selbst openSUSE hat einen unter SUSE Paste
(Der lehnt Posts mit mehr als drei URL's idiotischerweise als potentiellen Spam ab. Entweder das HTTP durch PTTH ersetzen oder löschen. )

Man kann auch die Ausgaben von irgendEinBefehl ganz einfach mit

irgendEinBefehl --samt seinen -Optionen und Argumenten  | curl -F 'sprunge=<-' http://sprunge.us

posten. Obige Zeile gibt dann einfach einen URL aus.
Und es gibt auch Scripte, die das tun.
Eines davon ist

zypper in susepaste
# direktes Pasten
irgenEinBefehl | susepaste
# eine Textdatei pasten
susepaste eineTextDatei
# infos zu susepaste
man susepaste

Nach den installierten Versionen von libzypui* sollte das Ding eigentlich laufen.
In exakt derselben Installation mit dergleichen Versionen läuft es bei mir ohne jedwedes Mucken.

Womit dein Effekt wohl doch eher an anderer Stelle zu suchen ist.
Ich argwöhne, dass deine ehemalige Repoliste dir da Streiche gespielt hat.

Deshalb bitte erst einmal die ausführliche Liste posten.

zypper lr -d | sed 's/http/ptth/' | susepaste


# oder 
zypper lr -d | sed 's/http/ptth/'  | curl -F 'sprunge=<-' http://sprunge.us