1. Foren
  2. Kommentare
  3. Politik/Recht-Forum
  4. Alle Kommentare zum Artikel
  5. › Linux: Mit Ignoranz gegen…

Umdenken auch bei Kernel-Entwicklern erforderlich

Neue Foren im Freiraum! Raumfahrt und freie Software haben jetzt einen Platz, die Games tummeln sich jetzt alle in einem Forum.
  1. Thema

Neues Thema


  1. Umdenken auch bei Kernel-Entwicklern erforderlich

    Autor: irisquelle 20.03.18 - 04:55

    Ich halte eine aggressive Durchsetzung der GPL für kontraproduktiv. Letztlich wird der Ruf der ganzen Open-Source Entwicklercommunity beschädigt, wenn es sich Einzelne zur Lebensaufgabe machen, andere wegen Linzenzverstößen mit Prozessen zu überziehen. Hier allein auf die "Dummheit" der Hersteller und Vertriebsorganisationen hinzuweisen, reicht nicht aus. Es gibt ja konkrete kommerzielle Gründe, weshalb etwa die Hersteller von Geräten, die den Linux-Kernel einsetzen, ihre Erweiterungen nicht offenlegen können. Daher sollten sich die GPL-Verfechter darüber klar werden, dass man nicht beides haben kann: die massenhafte kommerzielle Verbreitung des Linux-Kernels lässt sich schwerlich damit vereinbaren, wenn jeder Hersteller gezwungen wird seine Geschäftsgeheimnisse zu offenbaren.

    Eher schon kann ich mir eine Partitionierung des Linux-Kernels in zwei unterschiedlich lizensierte Bereiche vorstellen. Zum einen einen echten "Kern", wo hardware-übergreifende Funktionen realisiert wird (also Scheduler, Memory Management, Netzwerkstack usw.), der weiterhin unter der GPL lizensiert ist. Und einen "Randbereich", wo Hersteller etwa Hardware-nahe Features wie Treiber umsetzen und vor der zwangsweisen Offenlegung ihres geistigen Eigentums geschützt sind. Eine weitere Alternative sind Karenzfristen, während derer die Hersteller ihren Code zurückhalten dürfen. Nach fünf Jahren dürfte es für den Hersteller eines Android-Geräts weniger schmerzhaft sein, wenn die programmierten Treiber zum Allgemeingut werden. Noch besser wäre es, wenn der Linux-Kernel perspektivisch die GPL aufgibt und zu einer liberaleren Lizenz wechselt. Übergangsweise ist auch eine Dual-Lizensierung denkbar, bei der Verwender des Linux-Kernels sich ggf. für eine alternative Lizenz entscheiden könnten. Das kann auch gegen Lizenzgebühren erfolgen, die dann per Verteilungsschlüssel an die Kernel-Programmierer ausgeschüttet werden.

  2. Re: Umdenken auch bei Kernel-Entwicklern erforderlich

    Autor: wilima 20.03.18 - 06:33

    Ich hoffe, du machst Witze! Eine Lizenz ist eine Lizenz ist eine Lizenz! Wenn ein Hersteller Geschäftsgeheimnisse hat, muss er eben ein eigenes Betriebssystem entwickeln oder könnte z. B. ein kommerzielles lizensieren.

    Die massenhafte Verbreitung des Linux-Kernels wurde überhaupt erst durch die GPL ermöglicht! Denn jeder Hersteller, der eine Erweiterung benötigt, muss diese öffentlich machen. Dadurch entwickelt sich der Kernel weiter und wird für mehr Leute interessant, die dann wieder eine Erweiterung benötigen und diese öffentlich machen müssen ...

    Alles andere ist kommerzielles Ausbeuten der Kernel-Entwickler, die genau deshalb zu ihrem Schutz unter der GPL entwickeln.

  3. Re: Umdenken auch bei Kernel-Entwicklern erforderlich

    Autor: irisquelle 20.03.18 - 08:27

    Ausgebeutet werden viele Kernel-Entwickler schon jetzt. Ich sehe jedenfalls nicht, dass die vielen Freizeit-Programmierer auch nur eine geringfügige wirtschaftliche Entschädigung für ihre Beiträge erhalten würden. Und andere Software ist beispielsweise BSD, MIT oder Apache-lizensiert und trotzdem erfolgreich. Meine These ist, dass Linux trotz, aber nicht wegen der GPL erfolgreich ist.

    Man sollte das Thema Lizensierung grundsätzlich ideologiefrei betrachten. Vor allem sollten die Protagonisten der Community regelmäßig überprüfen, inwiefern die GPL noch zweckmäßig ist. Es kann ja sein, dass die GPL in den Anfangsjahren von Linux die richtige Wahl war. Inzwischen wäre aber eine Dual-Lizensierung in vielen Fällen zeitgemäßer.

    Als Beispiel einmal ein fiktives Szenario: ein SaaS-Anbieter passt GPL-lizensierte Software für seine Zwecke an. Dann setzt er diese Software ohne Veröffentlichung des Quellcodes in seiner Cloud ein. Das ist zwar auch eine Lizenzverletzung, lässt sich aber praktisch nicht nachweisen.

    Demgegenüber müssen Hersteller von Hardware mit Linux-basierter Firmware oder Programmierer von installierter Software mit GPL-lizensierten Komponenten ihre Firmware/Software offen legen - allein weil der Nachweis einer Lizenzverletzung ungleich einfacher ist. Diese Unterscheidung ist nicht nur unfair - vor allem zeigt es, wie die GPL aus der Zeit gefallen ist. Der Gedanke der Offenlegung des Quelltextes ergibt im Zeitalter von Cloud-basierten Diensten immer weniger Sinn.

  4. Re: Umdenken auch bei Kernel-Entwicklern erforderlich

    Autor: a user 20.03.18 - 13:35

    irisquelle schrieb:
    --------------------------------------------------------------------------------
    > Ich halte eine aggressive Durchsetzung der GPL für kontraproduktiv.
    > Letztlich wird der Ruf der ganzen Open-Source Entwicklercommunity
    > beschädigt, wenn es sich Einzelne zur Lebensaufgabe machen, andere wegen
    > Linzenzverstößen mit Prozessen zu überziehen. Hier allein auf die
    > "Dummheit" der Hersteller und Vertriebsorganisationen hinzuweisen, reicht
    > nicht aus.

    Doch!
    > Es gibt ja konkrete kommerzielle Gründe, weshalb etwa die
    > Hersteller von Geräten, die den Linux-Kernel einsetzen, ihre Erweiterungen
    > nicht offenlegen können.
    Nein gibt es nicht. Ich abreite in einer Firma die sich genau damit schwer tut und es ist EINZIG UND ALLEINE UNSERER DUMMHEIT und FAULHEIT geschuldet. Denn es wurde nicht einmal einn erstnhafter Versuch unternommen dem Folge zu leisten.

    Es sieht nämlich so aus:
    A : "Was kostet uns das?"
    B: "Nix. Aber du musst da paar Kleinigkeiten erfüllen. Und zwar..."
    A: "Ah ne, dann lassen wir das. Zu aufwändig und wer weiß was da schief gehen kann."
    > Daher sollten sich die GPL-Verfechter darüber klar
    > werden, dass man nicht beides haben kann: die massenhafte kommerzielle
    > Verbreitung des Linux-Kernels lässt sich schwerlich damit vereinbaren, wenn
    > jeder Hersteller gezwungen wird seine Geschäftsgeheimnisse zu offenbaren.
    Darüber sind sich die GPL Verfechter im Klaren. Denn wenn du dich einmal mit der GPL beschäftigt hättest, dann wüstest du, dass sie das gar nicht zum Ziel hat. Das Ziel ist mithilfe guter Software über diese Lizenz Software frei für alle zu erzwingen.
    Was du mit unserem Zeug machst, musst du allen frei zugänglich machen. Das hat mit Nichten das Ziel diese Software weit zu verbreiten.

    Andersurm wird ein Schuh draus: man versucht die Verbreitung, weil es gute und freie Software ist dazu zu nutzen, damit immer mehr Software frei wird.

  5. Re: Umdenken auch bei Kernel-Entwicklern erforderlich

    Autor: Thaodan 20.03.18 - 21:16

    irisquelle schrieb:
    --------------------------------------------------------------------------------

    > Als Beispiel einmal ein fiktives Szenario: ein SaaS-Anbieter passt
    > GPL-lizensierte Software für seine Zwecke an. Dann setzt er diese Software
    > ohne Veröffentlichung des Quellcodes in seiner Cloud ein. Das ist zwar auch
    > eine Lizenzverletzung, lässt sich aber praktisch nicht nachweisen.
    Nein wäre es nicht, nur bei AGPL.

    Wahrung der Menschenrechte oder Freie fahrt am Wochenende.
    -- Georg Schramm

  6. Re: Umdenken auch bei Kernel-Entwicklern erforderlich

    Autor: Silberfan 29.03.18 - 09:42

    irisquelle schrieb:
    --------------------------------------------------------------------------------
    > Ich halte eine aggressive Durchsetzung der GPL für kontraproduktiv.
    > Letztlich wird der Ruf der ganzen Open-Source Entwicklercommunity
    > beschädigt, wenn es sich Einzelne zur Lebensaufgabe machen, andere wegen
    > Linzenzverstößen mit Prozessen zu überziehen. Hier allein auf die
    > "Dummheit" der Hersteller und Vertriebsorganisationen hinzuweisen, reicht
    > nicht aus. Es gibt ja konkrete kommerzielle Gründe, weshalb etwa die
    > Hersteller von Geräten, die den Linux-Kernel einsetzen, ihre Erweiterungen
    > nicht offenlegen können. Daher sollten sich die GPL-Verfechter darüber klar
    > werden, dass man nicht beides haben kann: die massenhafte kommerzielle
    > Verbreitung des Linux-Kernels lässt sich schwerlich damit vereinbaren, wenn
    > jeder Hersteller gezwungen wird seine Geschäftsgeheimnisse zu offenbaren.

    Die Schwierigkeit liegt im Risiko des Betreibers. Wenn er nun also kein Geld für Software Zahlen muss,dann ist es auch klar das er kein Geld verlangen kann und darf beim Kunden. Ebenso muss der Quellcode Offengelegt werden. Es reicht im allgemeinen aus die Ansprech-Adressen der Hardware korrekt aufzulisten und eine entsprechende Dokumentation dazu mitzugeben. die meisten Hersteller scheuen aber die Kosten die dabei entstehen. Wobei die Kostenpflichtige Closed Version im Vergleich zur Open Source teurer wäre. Man muss aber auch aus Firmensicht selbst entscheiden. Will man kosten in der Software Welt einsparen dann muss ich auch die Folgen die dadurch entstehen können mit in Betracht ziehen(Offenlegung des Quellcodes ,saubere Dokumentation ,etc.) . Oder ich betreibe Closed Source und kann so keine Umsatzzahlen oder geringere generieren und muss Möglicherweise auch den Support zur Software ( Treiber ,etc. ) dann auch noch Übernehmen.


    > Eher schon kann ich mir eine Partitionierung des Linux-Kernels in zwei
    > unterschiedlich lizensierte Bereiche vorstellen. Zum einen einen echten
    > "Kern", wo hardware-übergreifende Funktionen realisiert wird (also
    > Scheduler, Memory Management, Netzwerkstack usw.), der weiterhin unter der
    > GPL lizensiert ist. Und einen "Randbereich", wo Hersteller etwa
    > Hardware-nahe Features wie Treiber umsetzen und vor der zwangsweisen
    > Offenlegung ihres geistigen Eigentums geschützt sind. Eine weitere
    > Alternative sind Karenzfristen, während derer die Hersteller ihren Code
    > zurückhalten dürfen. Nach fünf Jahren dürfte es für den Hersteller eines
    > Android-Geräts weniger schmerzhaft sein, wenn die programmierten Treiber
    > zum Allgemeingut werden. Noch besser wäre es, wenn der Linux-Kernel
    > perspektivisch die GPL aufgibt und zu einer liberaleren Lizenz wechselt.
    > Übergangsweise ist auch eine Dual-Lizensierung denkbar, bei der Verwender
    > des Linux-Kernels sich ggf. für eine alternative Lizenz entscheiden
    > könnten. Das kann auch gegen Lizenzgebühren erfolgen, die dann per
    > Verteilungsschlüssel an die Kernel-Programmierer ausgeschüttet werden.

    Die Problematik gestaltet sich in 2 ebenen. Kostenpflichtig und kostenfrei. nimmt man kostenpflichtig will keiner was damit zu tun haben. Kostenfrei nutzt somit jeder. Es gibt zig andere Methoden und Möglichkeiten die Kosten der Softwareentwicklung wieder einzuspielen. Man muss nicht stur auf die eine oder andere Möglichkeit sein Geschäftsmodell setzten. Man kann auch z.B. durch Zusatz Modulen oder extras die es so gibt auch einen weiteren Zweig für Finanzielles einsetzten.
    Beispiel: jemand hat Grafikkarte X in Benutzung ,zockt aber nicht ,brauch als das geblubber für die Treiber im Gaming Bereich nicht. Ihm reichen Standard Treiber ,also zahlt er nix. Jemand anderes Zockt gerne und brauch den Kram. Also einmalig sich registrieren, 5¤ im Jahr für den Treiber Kram Bezahlen lassen, fertig. Wenn das z.B. 500.000 Leute das machen so könnte man mit dem Geld Locker 2 Programmierer ( evtl. mehr) finanzieren die Bugs oder Probleme beheben und diese dann Zeitnah auch fixen.
    Einfacher Dargestellt, für Standard zahlt man nix. Für Extras sollte man einen kleinen Betrag hinlegen. Das Denkbar Schlechtestes Beispiel im Kostenpflichtigen Bereich wäre Crossover von Cedega das schon 50-60¤ Pro Jahr Verlangt. Würden die z.B. auf 5¤ runter gehen , würden auch viel mehr Leute Ihre Software nutzten.

  7. Re: Umdenken auch bei Kernel-Entwicklern erforderlich

    Autor: Hello_World 03.04.18 - 17:32

    Es ist wenig sinnvoll, darüber zu diskutieren, ob der Kernel mit einer liberaleren Lizenz besser dran wäre, da es ohnehin nicht dazu kommen wird. Tausende Leute haben mittlerweile daran mitgearbeitet. Einige dürften sich schlicht weigern, ihren Code unter eine andere Lizenz zu stellen, andere sind unauffindbar oder tot.

    Zudem ist ohnehin zweifelhaft, ob es wirklich besser und technisch machbar wäre. Wäre der AMD-Grafiktreiber heute Open Source, wenn die GPL nicht wäre? Wie sieht es mit den Android-Features aus, die in den Mainline-Kernel gemerged wurden? Ich glaube nicht, dass der Kernel heute so weit wäre, wie er ist, wenn er unter einer liberaleren Lizenz gestanden hätte.
    Ganz zu schweigen davon, dass das auch ein stabiles Kernel-ABI nötig machen würde, was die Weiterentwicklung erschwert.

  8. Re: Umdenken auch bei Kernel-Entwicklern erforderlich

    Autor: metux 18.10.18 - 18:23

    > Ich halte eine aggressive Durchsetzung der GPL für kontraproduktiv.
    > Letztlich wird der Ruf der ganzen Open-Source Entwicklercommunity
    > beschädigt, wenn es sich Einzelne zur Lebensaufgabe machen, andere wegen
    > Linzenzverstößen mit Prozessen zu überziehen.

    Im Gegenteil: es ist wichtig, daß sich einige Leute intensiv darum kümmern und
    zumindest mit den großen Raubkopierern hart ins Gericht (im wörtlichen Sinne) gehen.
    Sie beschützen damit unsere Interessen.

    > Hier allein auf die "Dummheit" der Hersteller und Vertriebsorganisationen hinzuweisen,
    > reicht nicht aus.

    Oft ist es ja nichtmal Dummheit, sondern klarer Vorsatz. Betrug. Und das brauchen
    wir uns nicht bieten lassen - vorallem nicht von Schmarotzern, die sonst an jeder
    Ecke ihre Lizenzansprüche durchboxen.

    > Es gibt ja konkrete kommerzielle Gründe, weshalb etwa die Hersteller von Geräten,
    > die den Linux-Kernel einsetzen, ihre Erweiterungen nicht offenlegen können.

    Na und ? Deren Problem, nicht unseres. Dann sollen sie halt irgendwas kommerzielles
    nehmen - gibts doch 'nen Haufen Angebote, wo man einfach nur viele Münzen einwerfen
    muß. Wir sind doch nicht die kostenlosen Handlanger für irgendwelche Firmen, die nichtmal
    ein vernünftiges Lizenzmanagement auf die Reihe bekommen.

    > Daher sollten sich die GPL-Verfechter darüber klar werden, dass man nicht beides
    > haben kann: die massenhafte kommerzielle Verbreitung des Linux-Kernels lässt sich
    > schwerlich damit vereinbaren, wenn jeder Hersteller gezwungen wird seine
    > Geschäftsgeheimnisse zu offenbaren.

    Mir persönlich ist die *kommerzielle* Verbreitung mal komplett scheißegal.

    Und wer ein paar Interface-Specs, die nötig sind, um ein bissl Treiber zu schreiben,
    ernsthaft als großes "Geschäftsgeheimnis" betrachtet, der hat von professioneller
    Software-Entwicklung schonmal gar keine Ahnung - und genau das bekommen wir
    von dem kaputten proprietären Gerümpel immer wieder bestätigt. Ich erinnere mich
    zB. spontan an Freescale-Code (mx5->adreno), dessen Autor(en) ganz offentsichtlich
    nichtmal die essentiellen C-Grundlagen beherrschen - und sowas soll dann auch noch
    für mission-critical-Dinge wie zB. Medizinprodukte eingesetzt werden. Solche Leute
    gehören doch besser in unkritische Jobs, wie zB. Straße fegen, wo sie nicht so viel
    Schaden anrichten können.

    > Eher schon kann ich mir eine Partitionierung des Linux-Kernels in zwei
    > unterschiedlich lizensierte Bereiche vorstellen. Zum einen einen echten
    > "Kern", wo hardware-übergreifende Funktionen realisiert wird (also
    > Scheduler, Memory Management, Netzwerkstack usw.), der weiterhin unter der
    > GPL lizensiert ist.

    Aha, und wo genau soll da die Grenzlinie sein ? Wie genau soll das praktisch umgesetzt
    und durchgehalten werden ? Abgesehen davon: warum sollten wir uns überhaupt
    sowas antun ? Was haben wir davon ? (by the way: bei mir sind alle neuen Symbole
    stets GPL_ONLY, basta.)

    > Und einen "Randbereich", wo Hersteller etwa Hardware-nahe Features wie Treiber

    Dieser "Randbereich" ist schon da: Userland. Ja, da kann man auch allerhand tun.
    Und wir sehen ja schon seit Jahren, was dabei rauskommt: Schrott.

    > umsetzen und vor der zwangsweisen Offenlegung ihres geistigen Eigentums geschützt sind.

    Und wir Nutzer der Willkür des Herstellers (zB. "geplante Obsoleszenz" = Eingehungsbetrug,
    Digital Restriction Management, Backdoors, usw) ausgesetzt sind. Nein, solchen Müll will
    ich garnicht - und ich werde auch keinen Finger krumm manchen, sowas irgendwie für
    irgendwen einfacher zu machen. Im Gegenteil.

    > Eine weitere Alternative sind Karenzfristen, während derer die Hersteller ihren Code
    > zurückhalten dürfen.

    Ahja, wird ja noch komplizierter. Wer genau soll die nach welchen Kriterien genau
    definieren ? Wie irrsinnig komplex soll der ganze juristische Unterbau - mit allen
    Konsequenzen für die rechtliche Durchsetzung werden ?

    Die GPL hier ist völlig klar (das einzige Manko war die Tivoization-Bug - der wurde aber
    mit v3 behoben). Deal or no deal. Wem das nicht paßt, der soll einfach fern bleiben.
    Und wer den Vertrag eingeht und dann bricht, der soll auch ordentlich dafür haften.

    Bisher war die Rechtsdurchsetzung ja noch *sehr* milde. Hier und da mal ein Verkaufs-
    Verbot für ein paar Geräte ist noch harmlos. Nähme man die Lizenz wirklich ernst,
    müßten die verletzenden Firmen sofort *ALLE* Linux-basierten Geräte *ABSCHALTEN*.

    > Nach fünf Jahren dürfte es für den Hersteller eines
    > Android-Geräts weniger schmerzhaft sein, wenn die programmierten Treiber
    > zum Allgemeingut werden.

    Warum so lange warten - wenn die Geräte bis dahin eh schon kaputt sind ?
    Das ist doch eine Lachnummer !

    > Noch besser wäre es, wenn der Linux-Kernel perspektivisch die GPL aufgibt und zu
    > einer liberaleren Lizenz wechselt.

    Die Wahrscheinlichkeit nähert sich asymptotisch an Null an. Und zwar von unten.

    > Übergangsweise ist auch eine Dual-Lizensierung denkbar, bei der Verwender
    > des Linux-Kernels sich ggf. für eine alternative Lizenz entscheiden
    > könnten. Das kann auch gegen Lizenzgebühren erfolgen, die dann per
    > Verteilungsschlüssel an die Kernel-Programmierer ausgeschüttet werden.

    Aha, also einen Irrsinn a la GEMA (war ja mal eine Nazi-Erfindung) bauen ?
    Total absurd.

    --mtx

  9. Re: Umdenken auch bei Kernel-Entwicklern erforderlich

    Autor: metux 18.10.18 - 18:29

    > Man sollte das Thema Lizensierung grundsätzlich ideologiefrei betrachten.

    Hier zeigt sich genau faustische Problem - viele Techniker scheren sich überhaupt
    nicht um die gesellschaftlichen und politischen Konsequenzen ihre Werke.
    Genau das macht die GPL anders.

    > Inzwischen wäre aber eine Dual-Lizensierung in vielen Fällen zeitgemäßer.

    Entscheided wer ? Du etwa ?

    > Als Beispiel einmal ein fiktives Szenario: ein SaaS-Anbieter passt
    > GPL-lizensierte Software für seine Zwecke an. Dann setzt er diese Software
    > ohne Veröffentlichung des Quellcodes in seiner Cloud ein. Das ist zwar auch
    > eine Lizenzverletzung, lässt sich aber praktisch nicht nachweisen.

    Früher oder später bekommen wir das raus - und dann kann das schnell
    mal das Aus für den Anbieter sein. Zu Recht.

    > Demgegenüber müssen Hersteller von Hardware mit Linux-basierter Firmware
    > oder Programmierer von installierter Software mit GPL-lizensierten
    > Komponenten ihre Firmware/Software offen legen - allein weil der Nachweis
    > einer Lizenzverletzung ungleich einfacher ist.

    Tja, Pech. Manche Betrüger fallen halt schneller auf als andere.

    > Diese Unterscheidung ist nicht nur unfair -

    Viele Mörder bleiben unerkannt. Wie bitter unfair für jene, die gefaßt und
    verurteilt werden ... mir kommen die Tränen.

    > vor allem zeigt es, wie die GPL aus der Zeit gefallen ist.

    SaaS ist genau was die GPL eben *NICHT* will. Der User soll die Hoheit über seine
    Datenverarbeitung haben. Genau deshalb engagieren sich GNU, FSF, etc, stark
    gegen den ganzen SaaS-Wahnsinn.

    > Der Gedanke der Offenlegung des Quelltextes ergibt im Zeitalter von
    > Cloud-basierten Diensten immer weniger Sinn.

    Doch, jetzt umso mehr.


    --mtx

  10. Re: Umdenken auch bei Kernel-Entwicklern erforderlich

    Autor: metux 18.10.18 - 19:15

    > Die Schwierigkeit liegt im Risiko des Betreibers. Wenn er nun also kein
    > Geld für Software Zahlen muss,dann ist es auch klar das er kein Geld
    > verlangen kann und darf beim Kunden.

    Man darf sogar Geld verlangen (machen die kommerziellen Distro ja).
    Muß aber trotzdem den Sourcecode kostenlos zur Verfügung stellen.

    > Es reicht im allgemeinen aus die Ansprech-Adressen der Hardware
    > korrekt aufzulisten und eine entsprechende Dokumentation dazu mitzugeben.
    > die meisten Hersteller scheuen aber die Kosten die dabei entstehen.

    Die Kosten wären garnicht so hoch. Genau genommen fällt das bei halbwegs
    professioneller Entwicklung von selbst ab. Problem ist nur, daß die meisten
    Hardware-Hersteller (auch die sehr teuren, wie zB. in der Bahntechnik) alles
    andere als professionell sind und oft nichtmal selbst brauchbare Specs haben.

    Genau das erlebe ich regelmäßig bei meinen Kunden. Besonders bei Embedded.
    (ja, dort wo's wirklich auf Korrektheit, Robustheit und langfristige Wartung ankommt)

  1. Thema

Neues Thema


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Außendienst-Techniker*in / Regionale*r Betreuer*in
    VITRONIC Dr.-Ing. Stein Bildverarbeitungssysteme GmbH, Baden-Württemberg
  2. IT-Security-Architect (m/w/d)
    Rundfunk Berlin-Brandenburg (rbb), Berlin, Potsdam
  3. IT-Mitarbeiter (m/w/d)
    Bayerisches Landesamt für Gesundheit und Lebensmittelsicherheit, Oberschleißheim
  4. Softwareentwickler Backend Java Online-Games (m/w/d)
    BALLY WULFF Games & Entertainment GmbH, Berlin-Tempelhof

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 499,99€
  2. 1.771,60€ statt 4.699€ (mit 277,40€-Rabattgutschein)
  3. (u. a. Top Gun, Passengers, Spider-Man: Far From Home, Sonic the Hedgehog, Blader Runner 2049, Tanz...
  4. 84€ statt 99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Radeon RX 6650/6750 XT im Test: Von (fast) allem ein bisschen mehr
Radeon RX 6650/6750 XT im Test
Von (fast) allem ein bisschen mehr

Energie, Taktraten, Preis: Beim Radeon-RX-Refresh legt AMD die Messlatte durchweg höher, was für interessante Konstellationen sorgt.
Ein Test von Marc Sauter

  1. RDNA2-Grafikkarten Schnellere Radeon RX 6000 für Mai erwartet
  2. Temporales Upscaling Das kann AMDs FidelityFX Super Resolution 2.0
  3. Navi-Grafikkarten Radeon Super Resolution heute, FSR 2.0 bald

Alienware AW3423DW im Test: QD-OLED in 34 Zoll beeindruckt trotz Anlaufschwierigkeiten
Alienware AW3423DW im Test
QD-OLED in 34 Zoll beeindruckt trotz Anlaufschwierigkeiten

Dells Alienware AW3423DW zeigt, dass OLED-PC-Monitore in der Gegenwart angekommen sind. Wir sehen dem 21:9-Panel aber an, dass es sich um die erste Generation handelt.
Ein Test von Oliver Nickel

  1. AW3423DW Alienware-Monitor verwendet Samsungs QD-OLED
  2. Project Nyx Alienware zeigt Cloud-Gaming-Server fürs Eigenheim
  3. Aurora Gaming Desktop Alienware stellt Desktop-PC im neuen Design vor

Sid Meier's Pirates angespielt: Kaperfahrt in der Karibik
Sid Meier's Pirates angespielt
Kaperfahrt in der Karibik

Mit Pirates schuf Sid Meier vor 35 Jahren einen Klassiker. Wie spielt sich das frühe Open-World-Abenteuer heute?
Von Andreas Altenheimer