Nachbarnebenan

Es ist schön, daß du dein Wissen in Wikipedia einbringen willst, aber halte dich doch bitte an die Fakten.

T-Home-Entertain über andere Anbieter als T-Online?

Bzgl. des Reverts [1]: Ist es tatsächlich so, dass über T-Home Entertain-Anschlüsse die PPPoE-Verbindung über alternative T-DSL-ZISP-Internetzugangsanbieter (also mit Fremdanbieter-Zugangsdaten für die herkömmliche T-DSL-Konzentrationsnetz-Infrastruktur der DTAG) möglich ist? Hast du das selbst getestet? (also Zugangsdaten z.B. von justdsl, meome/freenet, etc) Gruß -- Fruli 14:49, 28. Apr. 2008 (CEST)

Ja, das geht. Der AC nutzt den gleichen Radius wie bei allen Anschlüssen. Nur die Multicast-Route fehlt dann (nicht getestet, sollte aber, vielleicht bis auf die ÖR). Es geht sogar mit nicht-Entertain Tarifen von T-Com. Getestet mit 1&1 und Call&Surf Basic. Abgerechnet wird wohl nach Minutenpreis, in einem Monat weiß ich es genau. Das VLAN-Tagging bleibt auf 7. Die feste IP bietet T-Com für VDSL nicht für Privatkunden (und zu Privatkundenpreisen) an, an einigen Anschlüssen ist die Zwangstrennung aktiv (früher bei uns mit 25/5), an manchen ist sie es nicht (jetzt bei uns mit 50/10). Bei neuen wird sie jetzt wohl ganz eingestellt, auch bei 25/5. Man hat zwar keine feste IP, kann sie aber solange behalten, wie man will. Man sollte natürlich den Cron für Neueinwahl 4 Uhr morgens löschen... ;-)

Ich muss mich revidieren. Seit 1. Juni geht es nicht mehr, nicht nur bei mir. Ich habe vier Bestätigungen aus Leipzig und Berlin, einmal normal, zweimal 25/5 und hier 50/10. Es ist keine Einwahl mit anderen Zugangskennungen mehr möglich, also alles nicht T-Com/T-Home/T-Online/oderwieauchimmer. Die Zwangstrennung scheint auch nicht mehr einheitlich zu sein. Hier wurde am 2.Juni 0 Uhr nach 202 Stunden getrennt, ist aber seitdem wieder 68 Stunden stabil. Ein Bekannter hier in Leipzig mit 25/5 hat seit dem 1. Juni wieder die alte 24 Stunden-Regelung, ein anderer mit 16k+ seitdem eine stabile Verbindung. Keine Ahnung, was da abgeht, aber es sieht nach Chaos aus... :(

Also, nach rumtelefonieren und langen Gesprächen mit ein paar Leuten bin ich auf folgendes gekommen: Anschlüsse, die vor dem 1. Oktober 2006 geschaltet wurden ("early adopters") waren bis zum 31. Mai 2008 in einer Art "Übergangszone". Im System wird das vermerkt und der Anschluss mit einem "roten Vorhängeschloss" gekennzeichnet ist. Die normalen Mitarbeiter an der Hotline und im T-Punkt wissen dann, dass sie da nicht randürfen. Neben anderen Schaltungsregeln können auch softwareseitig Dinge eingestellt werden, die sonst nicht gehen (keine Zwangstrennung, Zwangstrennung mit fester IP, Zwangstrennung nach != 24h usw.). Auch andere DSLAM-Profile sind möglich, z.B. 55/15 *neid* oder 25/10. Dazu gehörte auch ZISP; also Einwahl mit Zugangsdaten einiger anderer (nicht aller) Anbieter. Das wird jetzt jedoch Stück für Stück abgebaut, da VDSL2 jetzt im Regelbetrieb ist. Es ist jedoch ein Beweis dafür, dass es geht und nur nicht gehen soll. Vermutlich wird es irgendwann — gegen Aufschlag — als "brandneue Entwicklung" vermarktet.-- nachbarnebenan 13:21, 22. Jul. 2008 (CEST)

Kann der Artikel T-Home Entertain nicht ein wenig allgemeinverständlicher formuliert werden? Er wird immer mehr verkompliziert. Bei der Hälfte der technischen Beschreibungen musste ich erst unter den Links nachsehen, was sie bedeuten. Es ist eine Technologie für die Allgemeinheit, der Artikel DSL ist ja auch gut verständlich geschrieben.

Bilder

Hi, ich fühle mich (weil ich den Zoo Leipzig auf meiner Beobachtungsliste hab) dazu gezwungen zwei Hinweise abzulassen: Beim Zoo Leipzig hast du es mit Bildern ziemlich übertrieben (z.B. drei Amurtiger in ähnlicher Ansicht etc.), zu sehr Bilderbuch. Mach lieber ne hübsche Galerie auf Commons ;). Des Weiteren bitte nicht ein neues Bild als neue Version eines anderen hochladen (wie hier), so hat sich das der Erfinder nicht gedacht..und ich find das ne Unsitte ;)--D.W. 23:19, 20. Jun. 2008 (CEST)

Die Idee ist, für jede der großen Anlagen wenigstens ein vernünftiges Bild einzufügen. Für die Kiwara-Savanne wollte ich auch für jede der darauf vergesellschafteten Arten ein Bild, einfach weil diese Kombination weltweit einzigartig ist. Ok, bei den Amurtigern war es wirklich eins zuviel und zu ähnlich, ich habs rausgenommen. Das Bild vom Elefantentempel hatte ich ersetzt, weil es ohne Elefanten für Außenstehende keinen Sinn ergibt. Nachbarnebenan 00:48, 21. Jun. 2008 (CEST)

Einige der von Dir hochgeladenen Bilder haben ein digitales Wasserzeichen. Bitte mache einen OTRS-Eintrag dazu, sonst müssen sie wieder gelöscht werden. Beim nächsten Mal dann bitte nicht ganz so schnell copy&paste ;-)

???? --nachbarnebenan 17:13, 23. Aug. 2008 (CEST)

Danke für die neuen Bilder :-) --Onegin ^Fragen? 18:29, 20. Okt. 2008 (CEST)

Inkscape

Hi. Also, erstmal muss ich dir Recht geben: Zwar kann man alle Rastergrafiken tracen, aber ob man auch das gewünschte Ergebnis erhält, ist fraglich. Trotzdem konnte der Text so[2] nicht stehen bleiben, sorry. Wenn dir ne bessere Formulierung einfällt, kannst du sie gerne einfügen, nur frage ich mich ob das überhaupt nötig ist. Also nicht böse sein, das ich das Rückgängig (den Linkfix hab ich natürlich gelassen!) gemacht habe. mfg --ucc 09:48, 21. Jun. 2008 (CEST)

Ja, es war auch mehr oder weniger eine Verlegensheitslösung - ich wollte es nicht unnötig aufblähen, aber halt klarstellen, das man keine Wunder erwarten soll. Vielleicht fällt mir noch etwas besseres ein. Andererseits kann man ja auch im potrace-Artikel nachsehen. Nachbarnebenan 15:40, 21. Jun. 2008 (CEST)

Wikipedia-Tag Dresden

Artikelarbeit zum Wikipedia-Tag in der SLUB 2007

Hallo Nachbarnebenan,
ich möchte dich auf diesem Wege recht herzlich zum vierten Wikipedia-Tag nach Dresden einladen. Der Tag besteht aus einem Seminarteil, bei welchem älteren Bürgern erste Schritte zum Lesen von Wikipedia beigebracht werden. Am Abend treffen wir uns in der Dresdner Neustadt zu einem gemütlichen Austausch. Solltest du Lust haben, zu unterstützen oder einfach nur mit Wikipedianern aus dem Raum Dresden und Gästen zu plaudern, schreib dich bitte in die Seminarliste und/oder die Treffensliste ein und beobachte die Seite.

Weitere Ideen und Vorschläge erwünscht, Fragenbeantwortung gern, liebe Grüße dir, Conny 20:23, 18. Nov. 2008 (CET).

Bilder im Zoo Leipzig

Ist schon komisch, sobald eine Sonderfolge Elefant, Tiger & Co. gesendet wurde, tauchen ein paar Tage später Bilder auf, die "zufälligerweise" Standbildern verblüffend ähnlich sind. Bitte unterlass sowas in Zukunft. Danke. (Der vorstehende, nicht signierte Beitrag – siehe dazu Hilfe:Signatur – stammt von 151.1.143.116 (Diskussion • Beiträge) 11:37, 1. Jan. 2009 (CET))

Hallo IP, kein grund, gleich die ganze DS zu löschen!

@Nachbar: Ich hab sie dir mal wiederhergestellt :-) --Onegin ^Fragen? 14:49, 1. Jan. 2009 (CET)

PS: Liebe IP, du warst schon mehrmals gesperrt wegen den Unterstellungen, und das ein Bild mit 3.888×2.297 Pixeln kein Screenshot einer PAL-Sendung sein kann, sollte dir vielleicht auffallen. --Onegin ^Fragen? 15:06, 1. Jan. 2009 (CET)

Um die Diskussionen (hoffentlich) zu beenden, habe ich das Originalbild hochgeladen.nachbarnebenan 11:48, 4. Jan. 2009 (CET)

Hallo! Es gab keine DS, ich hab die IP wieder sperren lassen (Benutzer_Diskussion:LKD#IP_151.1.143.116) --Onegin ^Fragen? 14:11, 4. Jan. 2009 (CET)

OpenOffice.org

Danke, sieht schon gleich viel besser aus! Und dass das hässliche Vista-Dessign weg ist, macht mir den Bildschirmausdruck direkt sympatisch, auch wenn ich mit Linux nix am Hut hab. ;-) Gruß -- Qhx 23:38, 20. Jun. 2009 (CEST)

Panorama Pinguinanlage

Hallo nachbarnebenan...

Ich habe dieses Bild per EBV stark verbessert (ist ein Top-Bild im JPG-Format). Ist es möglich bzw. kompatibel zu deiner Lizenz, das Bild in die de:WP hochzuladen? Wenn ja, unter welcher Lizenz? MfG - Appaloosa 23:45, 30. Dez. 2009 (CET)

Das Bild kann frei verändert werden. Nachbanebenan

Pulseaudio

Frage mich nur warum der Eintrag rueckgaengig gemacht wird. Pulseaudio hat standardmaessig keine Multiuserfaehigkeit mehr. Dies ist ein Kritikpunkt und bereitet in der Praxis auch so einige Probleme. Es sollte durchaus erwaehnt werden bei den Eigenschaften. Alle anderen Unix basierten Betriebssysteme haben dieses Problem (sofern sie Pulseaudio nicht verwenden) nicht 92.225.103.203 11:26, 6. Mär. 2010 (CET)

Genau dafür gibt es ja das Modul pa_user_perm. Unabhängig davon kann man es auch einfach wie bei X machen: PULSE_SERVER und PULSE_COOKIE (wenn man es eingeschaltet hat) setzen und fertig. Da ist es dann egal, auch im Netz. Bei vielen Distributionen läuft der PA Daemon sowieso suid root und die Zugriffbeschränkungen sind abgeschaltet. Ob das sinnvoll ist, sei dahingestellt. --nachbarnebenan 12:33, 6. Mär. 2010 (CET)

Es wurden keine mit Ihrer Suchanfrage - pa_user_perm - übereinstimmenden Dokumente gefunden.

Vorschläge:

   * Vergewissern Sie sich, dass alle Wörter richtig geschrieben sind.
   * Probieren Sie andere Suchbegriffe.
   * Probieren Sie allgemeinere Suchbegriffe.

kann interessiert zusaetzlich leider nicht, da verschiedene Distributionen die Konfigurationen weissgottwo angelegt haben ist eine konsistente Konfiguration von Pulseaudio praktisch nicht mehr moeglich. Wenn Sie Informationen zu einer praktischen Loesung fuer so ein Problem haben lasse ich mich gerne ueberzeugen. Wenn User X derzeit auf Audio zugreift kann der Administrator vom System nicht mehr auf das Sounddevice zugreifen (dies funktioniert derzeit eindeutig mit anderen Systemen). Cookies verwenden ist keine Loesung sofern die andere Audioapplikation abgekoppelt von X laeuft soweit ich mitbekommen habe. Loesungsansaetze welche ich derzeit erhalten habe waren theoretischer Natur und in der Praxis leider auch nicht anwendbar. 92.225.98.70 12:55, 6. Mär. 2010 (CET)

Bei mir ist das unter /usr/lib64/pulse-0.9/modules/module-perm-user.so zu finden (0.9.21). Ich weiß nicht, ab welcher Version es dabei ist, durchaus wahrscheinlich, dass das recht neu ist. Die schon lange unterstützten Cookies sind zwar X nachgebildet und laufen "huckepack" beim Root-Window mit, funktionieren aber auch ohne. Ich benutze mplayer (nicht gmplayer, also ohne X) für Internetradio, den ich in meiner .profile starte. Der läuft immer, egal ob X oder nicht. Normalerweise muss man die Cookies auch nicht selbst setzen, wenn man z.B. das X11-Forwarding von ssh benutzt. Manuell geht es aber so: Mit xprop -root|grep PULSE bekommt man die Variablen PULSE_SERVER, PULSE_COOKIE und PULSE_ID angezeigt und trägt sie z.B. in die .profile auf einer anderen Maschine ein (die Werte sind stabil und im Gegensatz zu XAuth braucht man keine Cookie-Datei). Alle PA-Clients nutzen dann auch den angegebenen Server. Das funktioniert natürlich auch lokal mit anderen Benutzern. Und auch mit Windows-Clients im Netz, z.B. mit VLC bei Codecs, die es noch nicht für Linux gibt. Das Sounddevice selbst wird vom Daemon gesperrt, genau wie die Grafikkarte vom X-Server gesperrt wird. Man kann natürlich in /etc/asoundrc DMix aktivieren aber wozu? Damit verschenkt man wieder alle Vorteile von Pulseaudio, z.B. das man ein laufendes Programm, auch auf einem anderen Rechner, nicht beenden oder überhaupt darauf zugreifen muss, sondern einfach im Mixer den Stream stummschaltet. Am Anfang ist das gewöhnungsbedürftig, das gebe ich zu.-- nachbarnebenan 13:17, 6. Mär. 2010 (CET)

Kleine Ergänzung: Ich habe gerade mal mit sudo mplayer -ao alsa getestet und es geht, beide MPlayer sind zu hören. Das ALSA-PulseAudio-Plugin ist nicht installiert (dann würde ich auch den Stream sehen), also aktiviert Suse DMix automatisch, denn ich habe die Standardkonfiguration von ALSA und PulseAudio nie geändert. Frage mich allerdings, warum ein Programm als root überhaupt Audio bräuchte.-- nachbarnebenan 13:27, 6. Mär. 2010 (CET)

Das ist nicht das Multiuser das ich meine, man trage eine Soundapplikation im Initbereich ein oder führe "su -" aus um die lokalen Einstellungen loszuwerden und es funktioniert dann nicht mehr - man bekommt permission denied. Man kann sich genauso von einem Fremdrechner mittels SSH (root oder anderer User) einloggen und es wird nicht funktionieren. Workaround wäre sich von einem Remote Host (z.b als Root) einzuloggen und den User auf den aktuellen Pulseaudio User abzuändern. Dies ist alles noch keine ernstzunehmende Lösung derzeit. Das Problem das ich sehe ist die X Anbindung, die ist bei einigen Szenarien fehl am Platz. Bei reinen Desktop Anwendungen OK, aber bei weiteren Anwendungen eben nicht mehr. Ein weiterer wörkaround wäre Pulseaudio über DMIX zu schalten - was aber wieder mit einer Rekonfiguration verbunden ist - und dies ist leider distributionsübergreifend durch die schlampige Konfiguration praktisch nicht möglich. Gehen wir davon aus das es einen User gibt welcher einen Daemon installieren möchte welcher automatisiert Warnsignale an den Rechner abgibt - unabhängig vom jeweiligen User. Dies hat mit OSS und Alsa noch funktioniert (und funktioniert mit Apple Coreaudio ebenfalls). Mit Pulseaudio jedoch nicht mehr. Pulseaudio ist in dem Bereich ein massiver Schritt nach hinten. Multiuser unabhängig von X wird praktisch nicht mehr unterstützt.

Ok, vielleicht stehe ich einfach auf dem Schlauch (es ist immerhin Wochenende). Also schrittweise: 1. In einer X-Session funktioniert PulseAudio, d.h. Programme können sich mit dem Server verbinden, ihre Streams werden im Mixer angezeigt und man hört was. 2. Aber wenn die, in dieser Session, von xprop ausgegebenen Variablen gesetzt sind und ein Prozess, egal ob lokal oder nicht, der eine andere Uid hat, sich mit diesen Werten mit dem Server verbinden will, geht das nicht? Das wäre dann ein Bug und sollte unbedingt gemeldet werden. Genau das ist nämlich etwas, was auf jeden Fall funktionieren muss, denn es ist eines der Designkriterien von PulseAudio. Wenn man sudo, keine Ahnung wie es bei su ist, benutzt, muss man env_keep setzen oder, wie ich es zugegebenermaßen tue, einfach auf allen Maschinen die Variablen in /etc/profile und /etc/bashrc eintragen. Sicherheit ist damit natürlich hin, aber es ist halt bequem…-- nachbarnebenan 14:34, 6. Mär. 2010 (CET)

Also etwa sowas wie "50 5 * * * nobody /usr/bin/ogg123 /usr/local/share/music/InnerUniverse.ogg" in der Crontab? Das funktioniert bei mir einwandfrei.-- nachbarnebenan 14:50, 6. Mär. 2010 (CET)

da letzteres wohl eher nur kurz abspielt, aber dann gleich die Audiokarte wieder freilässt. Starten Sie bevor der X-Server gestartet wurde ein Programm das konstant Audio abspielt, dieses Programm wird dann alle Pulseaudio User im X blockieren, eventuell macht der Corking Mechanismus etwas. "muss man env_keep setzen" dies ist bereits ein Design Bug da besonders Multiuser der eine vom anderen nichts wissen muss, z.b root hat im generellen eine übergeordnete Rolle auf einem System aber auf einmal wird ihm nicht mehr erlaubt das Audiodevice zu verwenden. Ich als jemand der sein System selber verwalten möchte will diese Exklusivität nicht, maximal als Zusatzoption. Da dies mit vorherigen Systemen funktioniert hat ist es als Regression einzuordnen welche jedoch von den Entwicklern als Designbug aller existierenden Systeme einordnen (dies ist für mich in der Tat eher ein Eingeständnis das diese Entwickler weltfremd in ihrer eigenen Welt leben)

Wieso kurz abspielen? Inner Universe ist 4:55 lang. Das reicht, aufzustehen und sich anzumelden, inklusive KDE-Anmeldesound. Voraussetzung dafür ist natürlich, dass der PulseAudio-Server vorher läuft, woran es auf vielen Systemen hapert. Ich starte ihn über /etc/init.d/alsasound, so ist er immer verfügbar. Ich befürchte, das Hauptproblem das viele mit PulseAudio haben, liegt daran, dass sie in einem zu frühen Stadium umgestiegen sind, als es nur wenige Programme native unterstützten. Eine Menge Workarounds und Tricks waren nötig oder es hat schlicht gar nicht funktioniert und das hat sich festgesetzt. Das Design von PulseAudio ist einfach aber ziemlich gut durchdacht, aber es funktioniert eben nur dann, wenn es auch benutzt wird. Ich selbst habe lange gewartet und bin erst mit 0.9.5 umgestiegen, als ich wusste, dass mplayer, xine, gstreamer, vlc und SDL und damit alle KDE4-Programme (Amarok&Kaffeine) sowie die Spiele native Unterstützung für PulseAudio hatten. Darum hatte ich auch nie irgendwelche Probleme. Der obige crontag Eintrag funktioniert auch nur, weil ogg123 eine aktuelle libao nutzt und in /etc/libao.conf default_driver=pulse drinsteht. Wer aber auf Programme angewiesen ist, die kein PulseAudio oder wenigstens Esd unterstützen und für die es keine Patches gibt (wie für Wine), sollte sich gut überlegen, ob sich die dann notwendige Bastelei überhaupt lohnt. Und das Authentifizierungssystem von PulseAudio ist absichtlich dem von X nachempfunden, denn auch root kann nicht einfch auf einen fremden X-Server zugreifen, auch nicht lokal, ohne das passende Cookie. Im Gegensatz zu X lässt sich das aber ausschalten, so dass der Server alle Verbindungen akzeptiert. Ein guter Weg bei Problemen ist es, die gesamte bestehende PulseAudio-Konfiguration sowohl in /etc/pulse als auch in /home/*/.pulse und besonders /root/.pulse zu archivieren und komplett neu mit den Defaultwerten aus dem Paket anzufangen. Das gilt auch für die ASLA-Konfiguration, falls dort noch irgendwelche PulseAudio-Einträge drin sind. Die meisten Probleme lösen sich damit von selbst. (Bei mir war es z.B. ein alter disable-shm=yes Eintrag, der immer wieder zu Abstürzen geführt hat.)-- nachbarnebenan 15:40, 6. Mär. 2010 (CET)

Ist Ihr PA als Server konfiguriert? Die Serverkonfiguration ist depreciated lt. PA Entwicklern. Wie schon erwaehnt ein einfaches Beispiel man loggt sich mit SSH auf einen Fremdrechner ein mit 2 verschiedenen Usern und versucht etwas abzuspielen mit PA wird dies nicht funktionieren mit ALSA und OSS jedoch schon ebenso auf Apple. Dies soll auf der Wikipedia Seite ebenfalls vermerkt werden. Pulseaudio macht Zwangsmuting wenn man User wechselt (was unter anderem ebenfalls ein Feature -- aber kein Zwang bei Apple ist). Und wie bekommt man PA nun auf allen Systemen die es im Feld gibt auf eine Serverkonfiguration? (Praktisch nicht mehr moeglich aufgrund der unterschiedlich verteilten Konfiguration). Schlussendlich ist Audio nun noch mehr kaputt als vorher.

PulseAudio läuft immer als Server. Unter [3] wird empfohlen, dass man den Daemon nicht als root starten soll und das stimmt auch (manche Distributionen machen das trotzdem). Grund dafür ist einfach, dass PulseAudio in erster Linie für Desktop-Benutzer entwickelt wurde, und im System-Modus massive Sicherheitsprobleme mit sich bringt (man kann binäre Module nachladen). Der einzige Vorteil daraus, wäre die zentrale Verfügbarkeit des Servers für alle Nutzer, ohne das jemand lokal eingeloggt ist. Aber das kann man auch einfacher haben: Mit su - nn -c /usr/bin/pulseaudio in der /etc/init.d/alsasound und den Variablen zentral gesetzt hat man genau den gleichen Effekt ohne die Nachteile. Ubuntu verfolgt diesen Ansatz und ich benutze das hier auch auf Suse. Es ist egal, wieviele Streams wievieler Nutzer abgespielt werden, egal ob lokal oder nicht. Auf jeder Konsole und in zwei X-Sessions oder per ssh können sich verschiedene Nutzer einloggen und den Server verwenden. Solange ein Server läuft, erreichbar ist und man das Cookie hat, kein Problem. Und genau daran hakt es fast immer: Vielen ist nicht klar, wenn man sich auf einer Konsole oder per ssh einloggt, dass dann der Daemon eben nicht läuft, wenn er nicht systemweit konfiguriert ist. Und wenn man ihn manuell oder in .profile startet oder er automatisch durch eine X-Session gestartet wurde, dann haben spätere Prozesse anderer Benutzer ein Problem, denn das Cookie aus ~/.pulse-cookie stimmt meist nicht überein. Genauso bei zwei X-Sessions (verschiedener Benutzer). Es gibt kein "Zwangsmuting", sondern der zweitgestartete Daemon suspendiert den ersten via Dbus komplett. Wenn man darüber nachdenkt, ist es auch logisch: Ein X-Client des zweiten Nutzers kann auch nicht auf dem X-Server des ersten angezeigt werden und umgekehrt, es sei denn man setzt DISPLAY und sorgt für die XAuth-Authentifizierung. Und das kann man auch bei PulseAudio machen. Es ist nicht viel Mühe, die Variablen einmal zentral zu setzen und den Server automatisch starten zu lassen, danach läuft es einfach. Man muss die Cookie-Datei auch nicht herumkopieren, sie braucht nur bei dem Nutzer zu sein, unter dem der Daemon gestartet wird. Alle anderen bekommen das Cookie per Variable. Am Anfang muss man etwas darüber nachdenken, wie man es konfiguriert, ich habe auch einige Stunden gebraucht, bis alles lief. Insbesondere im Zusammenspiel mit dem X-Tunnel von ssh und zwei Systemen, auf denen beiden der Daemon läuft, kann man Überraschungen erleben. Beispiel: Auf dem Zielsystem läuft kein X, aber der PulseAudio-Server. Auf dem lokalen System ebenfalls und man loggt sich unter KDE per ssh auf dem anderen ein und startet mplayer. Wenn man gar nichts manuell gesetzt hat, hat man den Sound lokal. Hat man lokal kein PulseAudio - hört man gar nichts. Grund ist einfach, in den Eigenschaften des root-Window die ssh mittunnelt, sind die Umgebungsvariablen für PulseAudio mit enthalten. Bekommt mplayer eine DISPLAY-Variable zu fassen, wird dort zuerst gesucht, wenn die Variablen nicht manuell in der Umgebung gesetzt sind. Hat man nun lokal keinen Server oder ist er nicht zugänglich (falsches Cookie), gibt es keinen Ton. Darum ist auch meine Empfehlung, wenn man irgendetwas ernsthafteres machen will, den Daemon auf einem Computer (vorzugsweise dem mit einer Soundkarte ;-) zentral zu starten und die Variablen zu verteilen. Damit umgeht man sämtliche Schwierigkeiten und Probleme. Danach muss man nur darauf achten, dass alle Programme PulseAudio-fähig sind und es auch benutzen. Für OpenAL, libao und SDL kann man das gleich zentral einstellen und muss nicht jedes Programm einzeln konfigurieren.-- nachbarnebenan 18:31, 6. Mär. 2010 (CET)

Das ist alles klar soweit, aber genau dann sind wir dort wo man schreiben kann das Pulseaudio ein Designproblem hat. Multiuser darf nicht sein das ein User den anderen fragen muss nach einer Adresse (Cookie) fuer den Server. Entweder es funktioniert fuer alle einigermaszen einfach (so wie es vorher war) oder es ist einfach nicht richtig implementiert. Weder bei Alsa noch bei OSS noch bei CoreAudio (Apple) war dies der Fall. Pulseaudio hat ein paar Vorteile, jedoch ist genau dies ein gewaltiger Nachteil fuer einige Applikationen. Man kann zudem nicht ausgehen das alle Applikationen auf Pulseaudio abgestimmt werden lediglich das man funktionierendes Audio bekommt. Multiuser ist defakto nach wievor nicht mehr existent mit Pulseaudio. Wenn Sie dem nicht zustimmen wie wuerden Sie das geforderte Feature auf allen existierenden Systemen realisieren? (Ein einzelnes Workstationsystem zu konfigurieren ist kein Problem, jedoch gibt es mehr als nur ein System im Feld). Das die Entwickler etwas inkompetent sind ist bekannt, alleine die Vergleiche das es unter OSX genau gleich funktioniert wie bei Pulseaudio, oder das Alsa auch keine verschiedenen User ohne Rekonfiguration des Audiosystems zulaesst sind falsch.

Mit den aktuellen Versionen und dem pa_user_perm Modul muss man sich darum nicht mehr kümmern, via DBus funktioniert das automatisch, auch über verschiedene Nutzer hinweg (wenn der Nutzer, unter dem der Server läuft, dies nicht explizit abgeschalten hat) und Clients können den Server jetzt auch selbst starten, wenn noch keiner läuft (bisher hat das standardmäßig nur das Alsa-Plugin gemacht). Und im Netz können Clients einen Server mittels Broadcast ebenfalls automatisch finden (das ist aber, sinnvollerweise, standardmäßig abgeschaltet). Das ich noch die manuelle Konfiguration benutze, hat einerseits mit Faulheit zu tun sie zu löschen (funktioniert ja schließlich), andererseits damit, dass das eben auch schon mit wesentlich älteren Versionen funktioniert und meine Systeme sind nicht alle auf dem gleichen Stand. Und für Windows gibt es bisher nur die manuelle Möglichkeit, einen Server im Netz zu nutzen, daher ist es gut zu wissen, wie das geht. Dennoch werden seit 0.9.20 die meisten wohl kaum noch in die Situation kommen, PulseAudio manuell konfigurieren zu müssen. Es ist auch in Arbeit, dass ssh neben X auch PulseAudio separat tunneln kann, auch reverse, so dass auch dieses Manko bald entfällt. Die Entwickler habe nicht unbedingt seltsame Ansichten, sie wollen nur das Design nicht unnötig aufblähen. Aber für echte Multiuser-Fähigkeit wäre das nötig, daher wird die Standardkonfiguration eben nach dem Motto gesetzt: Einer oder keiner. Denn man darf nicht vergessen, das bei PulseAudio die Ausgabe auch die Eingabe sein kann, somit kann ein böswilliger Prozess eben nicht nur auf die Soundkarte ausgeben, sondern z.B. auch beide Seiten eines VoIP-Gespräches einfach aufnehmen, im Moment gibt es keine feinstufige Rechteverwaltung wie für Dateien. Darum sieht die Vorgabe halt sehr konservativ aus, ich kann das nachvollziehen. Was Anwendungen betrifft, unterstützt praktisch alles heutzutage PulseAudio entweder nativ oder die verwendeten Bibliotheken unterstützen es, evtl. über den Esd-Adapter. Wine ist das einzige, für das man noch einen Patch benötigt, aber mit OpenAL hat sich das dann auch erledigt. Der Grund dafür, das viele Projekte nach anfänglichem Zögern recht schnell mitgemacht haben, ist einfach: ALSA gibt es nur für Linux, OSS hauptsächlich für BSD und ein bischen Linux, CoreAudio nur für MacOSX und Windows hat wieder was eigenes. PulseAudio läuft überall gleich (Client oder Server), man hat also nur einmal Arbeit und die Netzwerkfähigkeit bekommt man gratis dazugeschenkt. Natürlich hat PulseAudio seine Grenzen, für Hardcore-Musiker oder Soundspezialisten gibt es bessere Lösungen wie z.B. Jack, das aber auch manuelle Konfiguration erfordert. Andererseits ist PulseAudio die einzige Möglichkeit, über einen netzwerkfähigen Verstärker via RTP Sound zu haben. Mit ALSA usw. hat man da Pech. Und mit der zunehmenden Verbreitung solcher Geräte (bzw. Lautsprecher mit eingebautem WLAN-Modul) hat man dann automatisch den Vorteil, das sie unterstützt werden, ohne dass man sich darum kümmern müssen. Das gilt auch für USB-Lautsprecher und Bluetooth-Headsets, besonders wenn mehrere gleichzeitig in Betrieb sind (z.B. Headset und standalone Mikro). PulseAudio ist die einzige Möglichkeit, ohne ein Programm (eventuell noch auf einem anderen Computer) beenden oder umkonfigurieren zu müssen, auf ein anderes Ein- oder Ausgabegerät zu verschieben.-- nachbarnebenan 19:58, 6. Mär. 2010 (CET)

Sie scheinen viel mit Pulseaudio zu tun zu haben, die Sicherheitsaspekte welche Sie hier nennen sind meiner Ansicht nach irrelevant. Bei Alsa hatte man ebenfalls die Moeglichkeit ein Device exklusiv zu oeffnen (sprich wenn ein VOIP Call kommt konnte man das Device vollstaendig belegen - Pulseaudio zeigt ja wie es geht da es auch auf das Alsa Backend aufbaut). Diese Argumente hoerte ich bis jetzt auch mehrfach und stufe diese als Humbug ein. Das Pulseaudio zoegerlich eingesetzt wurde kann man auch der Stabilitaet von Pulseaudio verdanken (unter anderem Memory Corruptions bei aelteren Versionen). Netzwerkfaehigkeit benoetige ich sowie die meisten meiner Kunden nicht, es waere gut wenn das lokale Setup konsistent und rueckwaertskompatibel waere. Zu "pa_user_perm" fehlt derzeit jedliche Dokumentation, noch ist es auf einem Ubuntu 9.10 System anscheinend vorhanden. Nichts fuer ungut aber der Wikipedia Artikel sollte auch beschreiben was fuer ein Chaos Pulseaudio eigentlich ist und nicht nur das Blaue vom Himmel erwaehnen.

Es stimmt, ich habe eine Menge mit PulseAudio zu tun und auch einen (kleinen) Patch beigetragen. Und die Sicherprobleme sind relevant. Wohl nicht auf einem Einzelsystem, aber im Netz, denn der Server kann eben von allen Hosts gleichermaßen verwendet werden, wenn der Netzzugriff gestattet wird, das kann schnell zum Problem werden. Was das Locking angeht, gibt es mehrere Möglichkeiten: Der Daemon kann das Device mit flock sperren oder nicht, das kann man einstellen. Eine dritte Option ist, nach wählbarer Zeit (meist 5s) das Lock aufzugeben. Warum also überhaupt diese Option? Um möglichst effizient zu sein und die Audiodaten nicht umkopieren zu müssen, wird der Speicherbereich fest mit mmap abgebildet, das geht (außer als root) nur im gesperrten Zustand und z.B. bei ALSA auch nicht mit darunterliegenden Plugins wie Dmix etc., da diese selbst das Lock halten. Dieser Speicher wird dann in alle Prozesse gespiegelt, die gegen libpulsecore linken. Deshalb z.B. auch die (nicht völlig unberechtigten) Bauchschmerzen der Wine-Entwickler gegenüber dem nativen Treiber, denn Wine verwendet ein eigenes mmap-Konzept. Das Mapping wird im übrigens auch von ALSA unterstützt, aber immer nur für einen Prozess zur gleichen Zeit. PulseAudio kann das mit mehreren Prozessen gleichzeitig, und die müssen nichtmal die Samplingrate der Soundkarte verwenden. Damit dürfte auch klar werden, worin das Sicherheitsproblem besteht, wenn man Multiuser möchte: Es werden Speicherbereiche, die Prozessen verschiedener Nutzer gehören beschreibbar aufeinander abgebildet. Verzichtet man auf mmap, braucht der Server nicht nur mehr Speicher und Rechenzeit, sondern es entsteht durch das dann nötige Umkopieren auch eine deutliche Verzögerung (Lag). Das ist übrigens auch der Grund, warum es in der Anfangszeit zu solchen Problemen kam, das Mapping ist nicht trivial und PulseAudio hat sich sehr schnell entwickelt und mehrere verschiedene mmap-Konzepte nacheinander durchlaufen. Auch die API war anfangs nicht stabil (und ist es offiziell immer noch nicht), daher haben andere Projekte natürlich abgewartet. Die Kompatibilität ist inzwischen sehr gut, solange man eine aktuelle libpulse einsetzt, können sowohl ältere Clients als auch ein älterer Server ab etwa 0.9.5 problemlos verwendet werden. Was leider wirklich stimmt, ist die mangelhafte Dokumentation. Vieles ist nur im Quelltext dokumentiert und es existiert auch kein aktuelles Benutzerhandbuch, selbst die Webseite ist in Teilen veraltet. Es gibt auch keinen Guide für Distributoren und Paketbauer, weshalb sich jeder mehr oder weniger sein eigenes Süppchen kocht und die Standardkonfiguration ein klein wenig anders ausliefert. Glücklicherweise ist es nicht immer so schlimm wie bei Ubuntu, das mal lustig PulseAudio ohne das Dbus-Modul ausgeliefert hat. Trotzdem kann man sagen, dass die aktuellen Versionen normalerweise mit vernünftigen Konfigurationen und auch nicht zu restriktiv für lokales Arbeiten kommen sollten. Wenn es konkrete Probleme gibt, sollte man sich vielleicht auch mal die Mühe machen, ein wenig zu stochern, woran es denn liegt. Von der Behebung haben schließlich alle was. Und ja, PulseAudio ist im ersten Moment, der schlechten Dokumentation geschuldet, etwas unübersichtlich und chaotisch, aber sobald es funktioniert, möchte man es nicht mehr missen (besonders mit Netzwerksound nicht).-- nachbarnebenan 21:28, 6. Mär. 2010 (CET)

Ich hatte selber einmal bei einem ISP gearbeitet und kann durchaus sagen das die Sicherheitsprobleme irrelevant sind. Besonders da die Server keine Audioeinheit hatten, und Pulseaudio hat uebrigens ohnehin nichts auf einem normalen Server zu suchen. Zudem wuerde da auch das Mikrophon fehlen. Es geht lediglich um Manipulation von Daten welche durchgeschliffen werden. Wer mit dem Argument VOIP kommt darf Pulseaudio gerne reparieren da es diese Probleme mit ALSA/OSS nicht gibt (hierbei gibt es ebenfalls ein RW/MMAP Interface). Nichts desto trotz wenn man sich remote auf einen Rechner einloggt 1x als root oder anderer User welcher durch /etc/passwd in der Audio Gruppe steckt und 1x als normaler Anwender dann hat idR eher nur der Anwender Zugriff auf das Audiodevice und root oder der andere virtuelle User eher nicht - so sieht die Praxis derzeit aus und deshalb trifft der Vermerk das Pulseaudio keine Multiuser Faehigkeit mehr hat durchaus zu. Ich kann mich hier als root auf eine alten aelteren Ubuntu Rechner einloggen - Audio verwenden, anschliessend als user und ebenfalls Audio verwenden. Dies funktioniert ebenfalls mit FreeBSD und OSX jedoch nicht mehr mit Pulseaudio. Fakt ist das die Pulseaudioentwickler diese Moeglichkeit praktisch gesperrt haben ohne das es die User explizit gefordert haben. Zudem hatte das seit dem Begin von Audio auf Linux anscheinend auch noch niemanden gestoert ausser Pulseaudio Entwickler selber. Ich werde den Eintrag auf Wikipedia spaeter aus diesem Grund wiederherstellen da er lediglich die Realitaet wiederspiegelt. Wenn ein anderer User die Cookies von einem weiteren anderen User kennen muss oder auf einmal stark in die Konfiguration eingreifen muss (welche nicht einmal Distributionsunabhaengig gleich gemacht werden kann) dann ist dies praktisch nicht funktionabel implementiert. 92.229.51.56 13:47, 7. Mär. 2010 (CET)

Ich befürchte leider, wir reden/schreiben aneinander vorbei. Der PulseAudio-Daemon ist der Server. Diese Konzeption wurde gezielt von X abgeschaut, da sie sich über Jahrzehnte bewährt hat. Der direkte Zugriff auf das Hardwaredevice ist nicht nur obsolet sondern auch nicht portabel, was ebenfalls ein wichtiger Aspekt von PulseAudio ist und mit ein Grund, warum standardmäßig ein hartes Lock gesetzt wird. Der lokale Zugriff auf den Server wird über Dbus problemlos automatisch geregelt und ist auch userübergreifend möglich, wenn man eine aktuelle Version einsetzt und das in der Konfiguration (bzw. in der paprefs GUI) nicht gesperrt hat. Es ist vermutlich das Konzept, das für viele ungewohnt ist. Bisher war die Soundkarte (nicht nur unter Linux) einfach nur ein "dummes" Device wie ein tty, auf das man nach Belieben schreiben und von dem man lesen kann, wann und wie man will. Das hat früher ausgereicht, aber sobald mehrere Programme gleichzeitig laufen und komplexeres Soundrouting benötigt wird, braucht man mehr. Jack war der richtige Schritt, ist aber zu stark Linux- bzw. Unix-spezifisch und erfordert erhebliche Anpassungen an den Programmen. Mehr oder weniger als Kompromiss entstand PulseAudio. Die physische Soundkarte verschwindet hinter dem Server, über den eben nicht mehr Allgewalt besteht und dessen definierter Schnittstelle man sich unterordnen muss. Es ist ein Abstraktionsschritt, genau wie die tty hinter der darüber aufgebauten Netzwerkverbindung verschwindet (und zu Recht z.B. vom pppoed gesperrt wird). Letztlich liegt ein großes Problem darin, dass die Distributoren PulseAudio natürlich anbieten und einbinden müssen, da sie ihren Nutzern die Vorteile nicht vorenthalten möchten, andererseits aufgrund der schnellen Weiterentwicklung und der anfangs nicht sehr stabilen Versionen unausgereifte und schlecht konfigurierte oder unvollständige Pakete ausgeliefert worden. Auf vielen Systemen schlummern noch immer Reste dieser Konfigurationen und machen nun bei der heute automatischen Konfiguration Probleme. Diese sollten daher zuerst beseitigt werden. Andererseits, wenn man keine Verwendung für PulseAudio hat oder z.B. ein Programm es nicht unterstützt, und man es daher nicht benutzen möchte — es zwingt einen niemand dazu. pactl exit beendet den Server.-- nachbarnebenan 15:07, 7. Mär. 2010 (CET)

Auf einer Seite gebe ich Ihnen vollkommen Recht, auf der anderen Seite gibt es einfach andere Anwendungsszenarien welche durch Pulseaudio ploetzlich nicht mehr moeglich sind. Bewaehrt hat sich im Linuxbereich ohnehin nicht wirklich viel, vieles ist verbesserungsfaehig. Und es ist nicht zumutbar einem Pulseaudio Anwender(und das sind auch Entwickler) zu sagen das er eine Pulseaudio Bibliothek schreiben soll um sein Szenario abzudecken. Alleine diese Diskussion zeigt das Pulseaudio sehr viele Defizite aufweist. Ich stimme zu das alles irgendwie moeglich ist, aber ich kann genauso Pulseaudio durch meinen eigenen Audiostack ersetzen wenn Pulseaudio meinen Anforderungen nicht entspricht - alles ist relativ zu sehen. Fakt ist das Pulseaudio die Moeglichkeiten von ALSA und OSS behindert waehrend es andere Moeglichkeiten hinzufuegt. Vorprogrammiert ist dadurch aerger mit all jenen welche die urspruengliche Moeglichkeiten ausnutzen und ausgenutzt haben. Pulseaudio haette einen sauberen Start hinlegen sollen und nicht versuchen mit Gewalt die Welt an sich reissen sollen, das kann nur schief gehen.92.229.51.56 16:38, 7. Mär. 2010 (CET)

Wie schon geschrieben, ist PulseAudio ein möglichst einfacher Kompromiss, eine simple und pragmatische Lösung, entstanden aus dem, was man aus den Konzepten von X, Jack und Arts (oder besser: dessen Fehlern) gelernt hat. Es ist nicht perfekt und noch sehr viel Arbeit ist nötig (besonders bei der automatischen Priorisierung verschiedener Geräte und der fehlenden Midi-Unterstützung). Zielgruppe ist der "Otto Normal"-Durchschnittsanwender ohne große Ansprüche: Videos ansehen, Internetradio, Musik hören, Podcasts und Spiele, alles mit PulseAudio-fähigen Anwendungen unter Gnome oder KDE, die sich um den Start des Servers kümmern und dessen Konfiguration übernehmen. Das ist alles, mehr sollte man (ohne Bastelei) also auch nicht erwarten. Für dieses Design ist es auch zulässig, an anderer Stelle Abstriche zu machen. Es ist nicht die einzige Audio-Lösung und das wird auch so bleiben. Denn wer z.B. ernsthaft mit Sound oder Musik arbeitet, wird sowieso wenig dafür übrig haben und zumeist Jack verwenden, das wiederum genau dafür entwickelt wurde. Und zu Recht gibt es auch Programme (z.B. Ardour und Rosegarden), die nur Jack unterstützen. Und es ist ja auch nicht so, dass ALSA, OSS oder CoreAudio über Nacht verschwinden. PulseAudio selbst wird irgendwann auch wieder verschwinden und nur als API weiterbestehen (die ja wiederum von Esd übernommen wurde), vielleicht wird man ja dann Audio über den X-Server mitverwalten oder wie auch immer. Einige integrierte Geräte und Handhelds verwenden die API schon heute als native Soundschnittstelle ohne den PulseAudio-Server dahinter.-- nachbarnebenan 21:25, 7. Mär. 2010 (CET)

komischerweise sind die meisten "Otto Normalanwender" mit dem vorigen System auch zurechtgekommen, das Flash Probleme bereitet hat kam ja daher das die Flashentwickler nicht genug Ahnung von dem ganzen hatten. Nichts desto trotz sind wir mit Pulseaudio echte Multiuserfähigkeit los. 92.225.23.96 21:34, 9. Mär. 2010 (CET)

Es gibt leider noch Probleme mit deiner Datei

Hallo Nachbarnebenan,

Bei der nachstehenden von dir hochgeladenen Datei gibt es Probleme, die du leider noch nicht behoben hast:

• Datei:Screenshot UFRaw.png

Konkret besteht noch folgendes Problem:

Das von dir fotografierte Bild hat natürlich Schöpfungshöhe, so trage bitte die Lizenz ein, unter der du das Bild veröffentlichen möchtest.

Du hast jetzt zwei Wochen Zeit, um die fehlenden Informationen nachzutragen. Wenn dann die Probleme weiterhin bestehen, muss die Datei leider gelöscht werden. Solltest du noch Fragen haben, würde ich dich gern unterstützen. ~Lukas Diskussion Bewertung 19:31, 12. Mär. 2010 (CET)

Schöpfungshöhe bezieht sich auf den Screenshot, das Herbstbild selbst ist natürlich PD. Aber wie trägt man das als Lizenz ein, d.h. SH für den Screenshot, PD für das Bild?-- nachbarnebenan 19:49, 12. Mär. 2010 (CET)

Ich habe die Angaben jetzt entsprechend angepasst, mit dem Bild gibt es jetzt keine Probleme mehr. ~Lukas Diskussion Bewertung 15:48, 13. Mär. 2010 (CET)

Datei:Baustelle Gondwanaland im Zoo Leipzig.png

Moin, die musste ich gerade leider löschen, da die Datei defekt war. Es gab wohl einen Fehler bei der Erstellung des Thumbnails. Kannst du vllt. mal schauen, ob die Datei bei dir auf dem PC bereits defekt ist? Sonst wieder hochladen und mal in der Bilderwerkstatt melden, ob die da was machen können. Grüße, XenonX3 - (☎:±) 22:13, 17. Jul. 2010 (CEST)

Ich hab ein neues Panorama fotografiert und gerade hochgeladen. Diesmal als jpeg, vielleicht geht das besser.-- nachbarnebenan 15:02, 19. Jul. 2010 (CEST)

Nö, geht auch nicht, da steckt wohl 'nen Zoowurm drin ... --Ole62 19:25, 19. Jul. 2010 (CEST)

Was ist denn da nur los? Das PNG konnte ich bei 23 problemlos hochladen, ist aber für die WP zu groß. Ich frag' mal die Bilderwerkstatt, vielleicht ist bei mir irgendeine Lib im Eimer.-- nachbarnebenan 20:03, 19. Jul. 2010 (CEST)

Reduziere doch einfach die Größe auf normale ~5 MB. Das sollte für sehr gute jpg-Qualität vollkommen reichen und geht auf jeden Fall durch. Überschwere Dateien bringen keinen Mehrwert und belasten die Systeme nur unnütz. --Ole62 20:53, 19. Jul. 2010 (CEST)

Datei:Zoo Leipzig Gajendra Jan2011.png

Moin! Könntest du deine Fotos als JPG hochladen? PNGs werden nur angezeigt, wenn sie weniger als 12.500.000 Pixel haben, das hier hat 13.700.000. Bei Fotos ist JPG zudem das Format, das weniger Speicherplatz benötigt. Gruß, NNW 19:02, 12. Jan. 2011 (CET)

In meinem Hinterkopf war noch irgendwas von 14Mio Limit, ich habe extra drauf geachtet. Egal, ich habe sie (kleiner) nochmal neu hochgeladen. Sorry für die Umstände. (Könnte man das nicht auf der Hochladen-Seite mit als Warnung anzeigen?)-- nachbarnebenan 20:13, 12. Jan. 2011 (CET)

Einladung zum Stammtisch in der Nähe von Bautzen

Treffen von Wikipedianern zum Wikipedia-Tag 2006 - dieses Mal in der Natur

Lieber Wikipedianer aus Sachsen,
ich möchte dich gern auf ein gemütliches Treffen von Wikipedianern in meine Gartensparte einladen. Wir wollen zusammenkommen, einander mal in echt sehen und den Abend gemeinsam mit Grillen, Lagerfeuern und Quatschen verbringen. Der Termin ist auf das Wochenende um den 11. Juni gelegt, es kann noch abgestimmt werden, welcher Wochentag dir gut passt. Ähnlich den Treffen bei Cornelius lebt die Veranstaltung von den Mitbringseln aller Gäste. Dafür gibt es beim Stammtisch Bautzen eine Organisationsseite, wo du bei Bedarf einen Zeltplatz reservieren und eintragen kannst, was du beisteuern magst. Für weitere Fragen kannst du mich gern kontaktieren. Ich freue mich auf dich, bis dahin, Conny 21:40, 11. Mai 2011 (CEST).

Einladung zum 100. Dresdner Wikipedia-Stammtisch

Hallo Nachbarnebenan!

Am Sonnabend, 30. Mai 2015 findet der 100. Wikipedia-Stammtisch Dresden statt. Du bist dazu ganz herzlich eingeladen. Falls du Interesse hast teilzunehmen melde dich bitte auf der Stammtischseite. Dort findest du auch weitere Informationen.

Diese Nachricht wurde im Auftrag von Der Checkerboy von Luke081515Bot 18:17, 21. Mai 2015 (CEST) versendet. Du erhälst diese Nachricht weil du in der Kategorie:Benutzer:aus Sachsen oder einer Unterkategorie zu finden bist.

Einladung zur WikiCon 2017, der Wiki-Gemeinschaftskonferenz: 8.–10. September

300 Wikipedia-Autorinnen und Autoren · mehr als 80 Vorträge, Kurse und Diskussionsrunden · Ort zum Austausch, Lernen und Weiterentwickeln · Wissen weitergegeben · Exkursionen · Cocktails

„WikiCon – Wissen fängt mit an.“

vom 8. bis 10. September 2017 in Leipzig

Der Veranstaltungsort: Leipziger KUBUS

Hallo Nachbarnebenan, wir möchten dich recht herzlich zur WikiCon 2017 nach Leipzig einladen und freuen uns sehr, wenn du den Weg zu uns findest.

Was möchte die WikiCon erreichen?

Die WikiCon ist die jährliche Konferenz der Aktiven der deutschsprachigen Wikipedia sowie ihrer Schwesterprojekte und aller, die sich für Freies Wissen interessieren. In offener Atmosphäre werden wir gemeinsam neue Ideen entwickeln, diese vertiefen sowie Konflikte behandeln. Weitere Infos findest du auf der Projektseite.

Was erwartet dich?

Es wird ein vielfältiges und interessantes Programm geben. Für jedes Interesse und jeden Geschmack wird etwas dabei sein: Neben Vorträgen und Workshops rund um das Thema Wikipedia und ihre Schwesterprojekte erwarten dich Beiträge von externen Referentinnen und Referenten aus Kultur und Politik sowie dem Denkmalschutz. Weiterhin gibt es Ausstellungen zu Projekten des Freien Wissens innerhalb und außerhalb der Wikipedia, Exkursionen, Wiki Loves Cocktails … und noch vieles mehr.

Anmeldung

Melde dich an! – Bei anfallenden Fahrt- und Übernachtungskosten kann dich Wikimedia Deutschland unterstützen. Die Frist für Hotelbuchungen über Wikimedia endet am 20. August.

Viele Grüße, das WikiCon-Orga-Team: DCB, Don-kun, Stepro, Ubahnverleih

---

 Info: Bitte antworte nicht hier, sondern schreibe uns auf der Projektseite oder sende eine E-Mail.

--MediaWiki message delivery (Diskussion) 11:49, 11. Aug. 2017 (CEST)

Problem mit Deiner Datei (07.04.2023)

Hallo Nachbarnebenan,

bei der folgenden von dir hochgeladenen Datei gibt es noch ein Problem:

1. Datei:UFRaw 0.18 GIMP-Plugin Screenshot.png - Problem: Lizenz, Hinweis

• Lizenz: Eine Lizenz ist die Erlaubnis, eine Datei unter bestimmten Bedingungen zu nutzen. In der deutschsprachigen Wikipedia werden nur solche Dateien akzeptiert, die unter einer freien Lizenz stehen, die hier gelistet sind. Unser Online-Assistent unter https://wmts.dabpunkt.eu/freigabe3/ hilft Dir, eine passende Lizenz auszuwählen und den Text für Dich anzupassen. Wenn du der Urheber der Datei oder der Inhaber der Nutzungsrechte bist, kannst Du ihn benutzen, um den Text anschließend in die Dateibeschreibungsseite einzufügen.
• Hinweis durch den DÜP-Bearbeiter: erreicht Schöpfungshöhe --Didym (Diskussion) 17:55, 25. Mär. 2023 (CET)

Durch Klicken auf „Bearbeiten“ oben auf der Dateibeschreibungsseite kannst du die fehlenden Angaben nachtragen. Wenn das Problem nicht innerhalb von 14 Tagen behoben wird, muss die Datei leider gelöscht werden.

Fragen beantwortet dir möglicherweise die Bilder-FAQ. Du kannst aber auch gern hier in diesem Abschnitt antworten, damit dir individuell geholfen wird.

Vielen Dank für deine Unterstützung, Xqbot (Diskussion) 00:53, 7. Apr. 2023 (CEST)