Sammelthread: Linux Tipps, Tricks, Kniffe

[kim88]

Denn nehmen wir mal an, Du würdest ein open-Source-Programm verkaufen. Beim ersten Käufer/Lizenznehmer könntest Du noch Kohle abknöpfen. Beim zweiten wirds schon schwieriger. Der der ein Programm unter Open-Source-Lizenz erworben hat, hat das recht dies weiterzugeben (ohne das ihm das eingeschränkt werden kann).
(wenn er das nicht dürfte, wäre es auch keine Open-Source-Lizenz im OSI-Sinne mehr)

Jein. Du kannst theoretisch - wie so oft in der IT - mit der Unwissenheit der Menschen Geld verdienen. Du veröffentlichst nur Quellcode am besten schlecht dokumentiert und keine vollständigen Build Anleitungen und verkaufst die Binaries.
Wenn du den Namen / Logo der App markenrechtlich schützen lässt, dürfte die Weitergabe dieser Binaries auch nicht so einfach sein.
Ich weiss nicht ob xChat damals einen Markenschutz hatte, aber in etwa so haben sie damals die Windows Binaries verkauft ^^

Falsch. Die Lizenz kostet gar nichts. Was Du bei Redhat kaufst ist keine Lizenz, sondern eine Subskription. Das bedeutet im Wesentlichen, das Du Support für Deine Instanz kriegst und fertig gepackte Binaries.
Mit dem Source-Code kannst Du weiterhin machen was Du willst. Und der ist auch frei verfügbar, weshalb es ja ja auch RH-Klone gibt. Mit der Lizenz hat die Subskription nix zu tun. Daher sollte man das auch nicht vermischen.

Stimmt ist eine Subscription und keine Lizenz. In der Praxis spielt es keine grosse Rolle. Wenn jemand Red Hat nutzen will bezahlt er ob das nun eine Lizenz oder Subscription ist macht in der wirtschaftlichen Kalkulation für ein Projekt keinen grossen Unterschied ^^

 

[iWaver]

Hallo zusammen!
Ich frage mich gerade, ob es möglich ist, auf einem reinen ALSA System in OBS den Systemsound mit aufzuzeichnen.
Mit

sudo modprobe snd-aloop

und dann in OBS

hw:2,1,0

bei einem custom Audio Capture Device (ALSA) funktioniert es jedenfalls nicht.
Hat hier jemand schon Erfahrungen damit?

 

[andy_m4]

Jein. Du kannst theoretisch - wie so oft in der IT - mit der Unwissenheit der Menschen Geld verdienen.

Das hat aber nix mit Open-Source oder Lizenzen zu tun.
Das hat nicht mal was mit IT zu tun. Homöopathie & Esoterikkram verkauft sich ja auch gut.

Du veröffentlichst nur Quellcode am besten schlecht dokumentiert und keine vollständigen Build Anleitungen und verkaufst die Binaries.

Die Frage ist halt, warum Du dann überhaupt noch Open-Source und nicht gleich ganz Closed-Source-Software machst. :-)
Open-Source macht man ja als Hersteller gerade, weil man möchte das sich die Leute dran beteiligen. Wenn man denen dann solche Steine in den Weg legt, wird sich auch niemand beteiligen.

Abgesehen davon stellt Open Source aber auch einige Anforderungen an die Quellen (wenngleich auch nicht explizit). Es reicht also nicht aus, wenn das irgendwie theoretisch kompilierbar ist. Sonst könntest Du ja einfach Deinen Quelltext durch nen Source-Code-Obfuscator jagen und dann behaupten, das sei Open-Source. :-)

Wenn du den Namen / Logo der App markenrechtlich schützen lässt, dürfte die Weitergabe dieser Binaries auch nicht so einfach sein.

Dann ist aber das Gesamtwerk keine Open-Source mehr. Open Source bedeutet halt, das alle Bestandteile "frei" (also die Rechte die Du angeräumt kriegst, damit das anerkannt Open Source ist) verwendbar sind. Wenn das nicht der Fall ist, hast Du halt ein gemischtes Werk. Mit Non-Open-Source-Anteilen.
Nur würde ja niemand von einem Open-Source-Programm sprechen, bloß weil da teilweise Open-Source-Sachen verbaut sind.

Wie gesagt. Man muss da schon differenzieren. Ich sag ja auch nicht, das man mit Open-Source kein Geld verdienen kann. Ich sag ja nur, das man durch den Verkauf von Open-Source-lizenzierter Software kein Geld verdienen kann (also kann man theoretisch natürlich schon; aber ich hab ja begründet, warum das in der Praxis dann doch immer wieder auf kostenlos hinausläuft).
Vielleicht hab ich Dich ja falsch verstanden. Dann korrigiere mich. Daran glaube ich aber nicht so recht, sonst würdest Du ja nicht mit Argumenten kommen a-la "Man kann ja Open Source an Unwissende verkaufen".

Stimmt ist eine Subscription und keine Lizenz.

Na immerhin siehst Du es ein. :-)

In der Praxis spielt es keine grosse Rolle. Wenn jemand Red Hat nutzen will bezahlt er ob das nun eine Lizenz oder Subscription ist macht

Ja. Ich kann auch zu Debian gehen und denen ne DVD-Box ihrer Distribution abkaufen oder einfach so ne Spende da lassen. Daraus dann aber abzuleiten, das Debian keine kostenlose Distribution ist würde ich dann als mutige Argumentation bewerten. :-)

 

[kim88]

Dann ist aber das Gesamtwerk keine Open-Source mehr. Open Source bedeutet halt, das alle Bestandteile "frei" (also die Rechte die Du angeräumt kriegst, damit das anerkannt Open Source ist) verwendbar sind.

Das ist für mich dann eben der Unterschied zwischen freier Software und OpenSource.

Selbst Firefox bezeichne ich ala OpenSource. Es ist nicht frei. Du knnst zwar den Quellcode nehmen und daraus deinen eigenen Browser basteln - aber Firefox Logo und Name sind geschützt die musst du auswechseln.

 

[Linuxfreakgraz]

Ich glaube die Diskussion wird kein Ergebnis bringen. Keiner kann den anderen von seiner Meinung überzeugen.

 

[KitKat::new()]

Tipps

Benutzt keine Lockscreens, da es nicht das Fail-Safe-Prinzip nutzt:
Linux Lock Screens Are Fundamentally Flawed - YouTube

 

[sedot]

Falls sich wer das Video nicht anschauen will:
https://news.ycombinator.com/item?id=25843874

tl;dr: Kids haben den Mint/Gnome Lockscreen bzw. die damit zusammenhängenden Prozesse zum Absturz gebracht, Session konnte ohne Login-Passwort hergestellt werden. Kann auch andere Plattformen (wie macOS) betreffen. Jut, kommt vor, ist doof, sollte mal behoben werden, wegen Security.

 

[foo_1337]

Kann auch andere Plattformen (wie macOS) betreffen

This mistake of the X11 architecture can never, ever be fixed. X11 is too old, too ossified, and has too many quagmire-trapped stakeholders to ever make any meaningful changes to it again. That's why people keep trying to replace X11 -- and failing, because it's too entrenched.

Naja, das ist ein X Problem. Sowas gab es in den 2000ern auch schonmal mit xlockmore. Das wurde daraufhin von Debian entfernt.
macOS (und auch der direkte Vorgänger OpenSTEP) nutzt jedoch kein X11, daher ist dieses Design Flaw hier nicht existent. Da gabs dafür andere Klopper https://twitter.com/patrickwardle/status/935608904377077761

 

[sedot]

macOS (und auch der direkte Vorgänger OpenSTEP) nutzt jedoch kein X11 (...)

Kinder können und haben schon so ziemlich alle Systeme zum Absturz gebracht. Genauso wie Katzen auf der Tastatur. Wie ich schrieb ist es ein Problem, aber kein Linux spezifisches. In diesen Sammler gehört so eine Meldung aus meiner Sicht nicht, falls wer Linux spezifische Sicherheitsprobleme oder x11 vs Wayland diskutieren will, gern, aber nicht hier.

 

[KitKat::new()]

Also laut Brodie ist es wegen der Architektur seitens Linux sehr wohl ein Linux-spezifisches Problem (und auch nicht x11 vs wayland vs ..., da das das Problem nur verschiebt).

Daher: Hohe Sicherheitsanforderungen -> kein Lockscreen

 

[foo_1337]

Nein, es ist kein "Linux spezifisches" Problem. Linux ist ein Kernel und der hat damit ohnehin nix am hut. Weder für ein GUI, noch für ein TTY.
Um die Problematik zu verstehen, muss man wissen, wie X11 funktioniert bzw. wie die Lockscreens, wie xlock, implementiert sind:
Der X Server ist simplifiziert ein Daemon, der auf einem Unix Socket und ggf. einem TCP Port lauscht. So genannte X clients, wie z.B. xterm oder auch ein Browser wie Firefox, connecten via Socket (oder TCP) zum Xserver, authentifizieren via xauth cookie und das Bild wird auf dem Xserver Framebuffer gezeichnet.
Das Problem ist nun, dass weder der X Server noch das X11 Protokoll einen Mechanismus für einen Screenlock implementiert haben. 1984 hat daran vermutlich noch keiner Gedacht
Nun wollen jedoch die User einen Lockscreen haben. Also was hat man gemacht? Man hat einen X client geschrieben (xlock) der eben fullscreen läuft und das ganze darstellt. Ich könnte mich jetzt einfach via SSH einloggen oder lokal auf einem TTY einloggen und den xlock Prozess einfach killen. Dann wäre der Bildschirm entsperrt. Dafür brauche ich allerdings auch die Privilegien des Users, dem der xlock gehört oder eben root. Durch bugs in xlock selbst kann ich aber halt auch einen Crash Provozieren.
Durch kdm & Co ist das ganze etwas erwachsener geworden: Der Lock Prozess wird automatisch respawned, wenn er crashed. Aber auch das ist eben nur ein Hack.

Wird Wayland die Situation verbessern? Im Falle von Plasma (KDE) wird der Screen-Locker-Daemon von ksmserver nach kwin verschoben, so dass der Compositor mehr Kontrolle darüber hat. Screen Locking ist ein dedizierter Modus, der vom Compositor unterstützt wird. Ob ein Kontextmenü geöffnet ist oder nicht, spielt keine Rolle mehr, der Bildschirm kann gesperrt werden. Außerdem kontrolliert der Compositor die Eingabeereignisse. Wenn er das Wissen hat, dass der Bildschirm gesperrt ist, kann er sicherstellen, dass keine Eingabe an den falschen Client geht. Zu guter Letzt kontrolliert der Compositor das Erstellen von Screenshots und kann so verhindern, dass Clients die Ausgabe des gesperrten Bildschirms abgreifen können.

 

[KitKat::new()]

Weder für ein GUI, noch für ein TTY.

Aber für das, auf was diese aufbauen.

Was passiert, wenn der Compositor seine Kontrolle verliert?
Das Problem ist ja, dass man im Fehler-Zustand nicht automatisch in einer sichere Situation zurückfällt.

 

[foo_1337]

Aber für das, auf was diese aufbauen.

Ja, aber mit Screenlocking hat der Kernel dennoch nichts am hut. Auch nicht für die Authentifizierung. Dafür gibt es dann beispielsweise PAM. Die Zuständigkeit fällt hier in den Prozess, der den Framebuffer unter Kontrolle hat.

Was passiert, wenn der Compositor seine Kontrolle verliert?
Das Problem ist ja, dass man im Fehler-Zustand nicht automatisch in einer sichere Situation zurückfällt.

Der Compositor (und damit auch der screenlock) ist im Wayland Fall direkt im Window Server implementiert. Wenn dieser nun crashed, ist das komplette GUI weg. Ist zwar auch eine unschöne Situation, aber immer noch besser als wenn nur der Lock Prozess weg ist und ich das GUI zur vollen Verfügung habe..

 

[andy_m4]

Das ist für mich dann eben der Unterschied zwischen freier Software und OpenSource.

Kann man natürlich so sehen. Allerdings wird allgemein dazwischen nicht unterschieden. Open-Source ist nur ein anderer Name für Freie Software (einen Begriff den Richard Stallman initiiert hat).

Selbst Firefox bezeichne ich ala OpenSource. Es ist nicht frei. Du knnst zwar den Quellcode nehmen und daraus deinen eigenen Browser basteln - aber Firefox Logo und Name sind geschützt die musst du auswechseln.

Das musst Du aber auch nur, wenn Du den Code änderst. Der Grund dahinter ist das wenn jemand den Firefox modifiziert (sozusagen einen Fork daraus erstellst) das es dann natürlich nicht mehr der originale Firefox ist. Sprich: Du kannst die Software gerne modifizieren und dann republizieren, aber dann gib ihm wenigstens einen neuen Namen/Logo.

Übrigens: Nach dieser Definition wäre selbst der Linux Kernel keine freie Software. Auch die Bezeichnung Linux ist markenrechtlich geschützt und unterliegt entsprechenden Einschränkungen.
Ähnliches gilt übrigens auch für GNU. Und Du kannst gerne versuchen mit den GNU-Leuten auszudiskutieren, ob ihre Software jetzt freie Software ist oder nicht. :-)

Ergänzung (28. Januar 2021)

Ich glaube die Diskussion wird kein Ergebnis bringen. Keiner kann den anderen von seiner Meinung überzeugen.

Bei einer Diskussion gehts nicht zwangsläufig darum den anderen von der eigenen Meinung zu überzeugen. Ich glaube sogar eher, Diskussionen funktionieren weniger gut wenn man das als eine Art Wettkampf sieht, wo es lediglich darum geht das die eigene Meinung gewinnt und die andere verliert.
Viel wichtiger finde ich aber ein Perspektivwechsel zu haben und Aspekte zu beleuchten, die mir bisher vielleicht nicht bewusst waren. Das kann dann immer noch damit enden das ich bei meiner Meinung bleibe, trotzdem würde ich die Diskussion dann als fruchtbar empfinden.

 

[nullPtr]

Ich würde namens- und markenrechtliche Geschichten generell aus der Definition von freier Software rauslassen. Da stimme ich @andy_m4 zu. Damit würden BSD-Lizenzen, die es verbieten mit dem Namen des originalen Autors zu werben, rausfallen.

Übrigens sagt auch die GPL:

7. Additional Terms.​

[...] for material you add to a covered work, you may [...] supplement the terms of this License with terms:
[...]
d) Limiting the use for publicity purposes of names of licensors or authors of the material; or
e) Declining to grant rights under trademark law for use of some trade names, trademarks, or service marks

(GPL v3)

 

[Natriumchlorid]

Hat schon jemand PipeWire aktiv in Verwendung? Habe das letztens installiert, was nun PulseAudio und JACK ersetzt. Mein Grund für den aktiven Wechsel ist, weil PulseEffects nun PipeWire als Backend zwingend benötigt. Es liefert auch einen Kompatibilitätslayer für PA und JACK mit, was den Umstieg sehr angenehm macht. Außerdem ist es von Grund auf, auf niedrige Latenzen ausgelegt, was mich bei PA immer etwas gestört hat.

Dennoch hab ich noch kleinere Probleme:
Es läuft an sich echt gut. Allerdings hab ich, wenn ich PulseEffects (mein Equalizer) im Hintergrund laufen habe, krasse Distortion, Crackling und eine unsaubere Überschneidung, wenn zum Beispiel das Lied in Spotify gewechselt wird.

Ich hab dann mit meiner

/etc/pipewire/pipewire.conf

gespielt, da einige User im Arch Linux Forum das selbe Problem berichtet haben.
Ich hab die Werte auf

default.clock.quantum = 256
default.clock.min-quantum = 256
default.clock.max-quantum = 768

gesetzt.

Dadurch verschwindet zwar die unschöne Distortion, allerdings bekomme ich dann keinen Sound mehr, wenn ich Spiele in Wine starte.

Wenn ich die Werte wieder hoch setze, erscheint wieder die Distortion beim Musikwechsel, aber der Sound in den Spielen verschwindet nicht mehr.

Auch wenn ich in VirtualBox eine VM starte, verschwindet der Ton für ca. 5 Sekunden, aber erscheint dann wieder. Da ist es nicht so kritisch.

Hat sich eventuell schon jemand näher damit beschäftigt und kann mir einen Tipp geben, was noch zu verbessern wäre?

 

[Natriumchlorid]

Als kleinen Nachtrag zu mir selbst, falls jemand in das gleiche Problem reinrennt:

Ich habe die für mich passenden Settings gefunden. In der

/etc/pipewire/pipewire.conf

habe ich die Werte folgendermaßen festgelegt:

    default.clock.quantum =             512
    default.clock.min-quantum =         512
    default.clock.max-quantum =         768

Zusätzlich hab ich noch das Package Realtime-Privileges installiert und meinen User in die Gruppe realtime hinzugefügt. Der Sound ist jetzt einwandfrei, ohne Verzögerung, ohne Distortion und mit geringerer Latenz als mit PulseAudio. Wobei der letzte Punkt nur gefühlt eintritt, da ich die Latenz selbst nicht nachgemessen habe.
At least ist PulseEffects mit PipeWire als Backend wieder benutzbar, which is nice.

Ich bin mir auch nicht sicher, in wie weit die Konfigurationen in der pipewire.conf bzgl. Distortion noch eine Rolle spielen. Denn sobald man das Realtime-Package installiert und den User in die Gruppe hinzugefügt hat, waren die Probleme wie aufgelöst. Ich hab deshalb auch nicht weiter in der Konfig hantiert.

 

[lokon]

Denn sobald man das Realtime-Package installiert und den User in die Gruppe hinzugefügt hat, waren die Probleme wie aufgelöst.

Es ist schon etwas komisch dass es Artefakte gibt - angesichts der potentiellen Rechenleistung des Systems - wenn Realtime-Scheduling hilft, dann wären die Effekte der "normalen" Scheduling Einstellungen, (früher zB "Kernel-Ticks"/tickless Kernel seit 3.10), usw (vgl. arch wiki: "Pro Audio"), Power-Management - und die CPU Auslastung durch die Effekte interessant.

Die "Artefakte" sind doch vergleichbar mit Jitter bzw. unregelmäßigen Frame-Times bei Spielen.

Aktuell ist auf der Consumer-Hardware doch aktuell alles Software-Mixing - und bei ~5Sekunden Latenz (?)

pacmd list-sink-inputs

->"current latency:"
ist vielleicht der "Audio-Pfad" zu lang/kompliziert - wenn die Quelle, Effekte und Ausgabe zB intern andere Sampleraten (44,1 - 48 - 96) bzw. Bitraten (16,24,32) haben und ständig hin-und hergerechnet wird.

 

[H1ldegunst]

Hat jemand eine Webcam im Einsatz, die ohne große Umstände funktioniert?
Nur für Videotelefonate, kein professionelles Streamen.

 

[foo_1337]

Die Aukey PC-LM1E zB. Die ist aber recht weitwinklig. Aktuell bei Amazon für 10€ weniger zu haben.