1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › Interview mit Systemd-Entwicklern…

.... und welcher sinn steckt jetzt hinter dem artikel ?????

  1. Thema

Neues Thema Ansicht wechseln


  1. .... und welcher sinn steckt jetzt hinter dem artikel ?????

    Autor: fesfrank 12.05.14 - 14:37

    wer sich mit linux auseinander setzt weiss was systemd ist, ein windows user kann damit nichts anfangen

  2. Re: .... und welcher sinn steckt jetzt hinter dem artikel ?????

    Autor: bstea 12.05.14 - 14:41

    Vermutlich um weiter für Zündstoff/Klicks zu sorgen. Ein netter Beitrag von Rob Landley,

    http://www.landley.net/notes.html#23-04-2014

    --
    Erst wenn der letzte Baum gefällt, der letzte Fluss gestaut und der letzte Fisch gefangen ist, werdet ihr feststellen, dass man Biber nicht essen kann!

  3. Re: .... und welcher sinn steckt jetzt hinter dem artikel ?????

    Autor: DerInderInDerInderin 12.05.14 - 14:45

    fesfrank schrieb:
    --------------------------------------------------------------------------------
    > wer sich mit linux auseinander setzt weiss was systemd ist, ein windows
    > user kann damit nichts anfangen


    Welcehr Sinn steckt hinter deinem Kommentar?

  4. Re: .... und welcher sinn steckt jetzt hinter dem artikel ?????

    Autor: YoungManKlaus 12.05.14 - 15:01

    bstea schrieb:
    --------------------------------------------------------------------------------
    > Vermutlich um weiter für Zündstoff/Klicks zu sorgen. Ein netter Beitrag von
    > Rob Landley,
    >
    > www.landley.net#23-04-2014
    Uuuhm, er sagt also "systemd ist böse weil keiner ne alternative implementierung schreibt?" hab ich das so ungefähr richtig zusammengefasst? Das ist so ungefähr die schwachsinnigste Begründung die ich jemals gehört habe, ganz besonders wenn er weiter oben sagt:
    > "When udev happened I wrote mdev"
    ... na, was hält dich heute auf das gleiche zu tun? Ein durchwegs schwachsinniger Artikel.

  5. Re: .... und welcher sinn steckt jetzt hinter dem artikel ?????

    Autor: Schattenwerk 12.05.14 - 15:06

    Persönlich habe ich nichts gegen systemd, nutze es selbst und es funktioniert wirklich gut - das muss man systemd lassen.

    Was mich jedoch tatsächlich stört ist die Tatsache, dass viel Software darauf angepasst wird/werden muss. Beispiel ist z.B. gnome trotz diverser Patches, etc. ohne systemd zwar läuft jedoch nicht voll und teilweise auch nicht rund.

    Und genau dies stößt mir bei systemd wirklich bitter auf. Ich hätte kein Problem zu sagen: "Wer systemd nicht haben will, soll es nicht nutzen, fertig". Jedoch ist dies leider im Detail ja nicht so einfach

  6. Re: .... und welcher sinn steckt jetzt hinter dem artikel ?????

    Autor: fesfrank 12.05.14 - 15:25

    DerInderInDerInderin schrieb:
    --------------------------------------------------------------------------------
    > fesfrank schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > wer sich mit linux auseinander setzt weiss was systemd ist, ein windows
    > > user kann damit nichts anfangen
    >
    > Welcehr Sinn steckt hinter deinem Kommentar?

    ist kein kommentar, sondern eine festellung

  7. Re: .... und welcher sinn steckt jetzt hinter dem artikel ?????

    Autor: oleid 12.05.14 - 16:13

    > Was mich jedoch tatsächlich stört ist die Tatsache, dass viel Software
    > darauf angepasst wird/werden muss. Beispiel ist z.B. gnome trotz diverser
    > Patches, etc. ohne systemd zwar läuft jedoch nicht voll und teilweise auch
    > nicht rund.

    Es muss keine Software angepasst werden, es sei denn sie möchte Dinge wie den "Software-Watchdog" von systemd unterstützen. Was GNOME angeht: ein Teil nutzt mangels Alternative logind. Davon gibt es auch eine Variante, die nicht in systemd integriert ist. Consolekit, die Alternative zu logind, wird aber schon länger nicht mehr gewartet. Dennoch unterstützt GNOME auch noch den Betrieb mit Consolekit. Logind ist also keine obligatorische Abhängigkeit.

  8. Re: .... und welcher sinn steckt jetzt hinter dem artikel ?????

    Autor: baltasaronmeth 12.05.14 - 16:13

    Tatsächlich hat systemd eine Reihe alternativer Initsysteme provoziert, die allesamt leichtgewichtiger und weniger verpatcht sind als sysvinit.

  9. Re: .... und welcher sinn steckt jetzt hinter dem artikel ?????

    Autor: baltasaronmeth 12.05.14 - 16:15

    ... und das Verschwinden von consolekit tut mir alles andere als leid. Logind funktioniert wenigstens, ohne dass ich mir einen Wolf konfigurieren muss.

  10. Re: .... und welcher sinn steckt jetzt hinter dem artikel ?????

    Autor: oleid 12.05.14 - 16:17

    Interessant. Hast du dazu ein paar Links?

  11. Re: .... und welcher sinn steckt jetzt hinter dem artikel ?????

    Autor: Onsdag 12.05.14 - 21:18

    Jupp, insbesondere der Link auf http://ewontfix.com/14/ ... schade, daß eine so wichtige Entscheidung am Ende auf diese Weise gefallen ist.

  12. Re: .... und welcher sinn steckt jetzt hinter dem artikel ?????

    Autor: oleid 12.05.14 - 22:03

    Onsdag schrieb:
    --------------------------------------------------------------------------------
    > Jupp, insbesondere der Link auf ewontfix.com ... schade, daß eine so
    > wichtige Entscheidung am Ende auf diese Weise gefallen ist.

    Der Blogeintrag von Rob Lendley ist ja eine Sammlung von Halbwahrheiten... da weiß man gar nicht, wo man anfangen soll... Meingott!

    Der Blogeintrag auf ewontfix wird auch ständig in den Ring geworfen, aber häufiges Nennen macht ihn wirklich nicht besser:

    1. Systemd als PID1.

    Es wird ja selbst der Grund genannt, warum systemd als PID1 laufen muss:
    "Among the reasons systemd wants/needs to run as PID 1 is getting parenthood of badly-behaved daemons that orphan themselves, preventing their immediate parent from knowing their PID to signal or wait on them."

    Das Absturtzrisiko ist natürlich vorhanden, klar. Aber ich frage mich, warum man nicht einfach den Kernel PID1 neustarten lässt, wenn der Prozess wirklich abstürtzen sollte.

    2. Attack surface:
    Es wird kritisiert, dass ein weiterer Prozess als root läuft - ein Prozess der IO hat. Das ist natürlich ein Problem, aber ich sehe keine Möglichkeit das zu verhindern. Immerhin wird ein einfaches, gut getestetes Protokoll verwendet,

    3. Reboot to Upgrade

    Das ist einfach nur falsch! Systemd kann sehr wohl im laufenden Betrieb aktuallisiert werden:

    systemctl daemon-reexec

    startet systemd neu. Aus der manpage:

    Reexecute the systemd manager. This will serialize the manager
    state, reexecute the process and deserialize the state again. This
    command is of little use except for debugging and package upgrades.
    Sometimes, it might be helpful as a heavy-weight daemon-reload.
    While the daemon is being reexecuted, all sockets systemd listening
    on behalf of user configuration will stay accessible.

    Darauf wird sogar später eingegangen, aber ein künstliches Ressourcen-Szenario konstruiert, unter dem das Neustarten von PID1 verhindert werden könnte. Dann schreibt der Autor:

    "Using musl libc with static linking or even dynamic linking with no additional libraries eliminates these failure cases, but systemd is intended to be used with glibc."

    Natürlich wird glibc verwendet, weil es Distributionsstandard ist. Aber wer sollte eine Distribution daran hindern systemds PID1 statisch gegen musl zu linken, wenn man das möchte?

    "In addition, systemd might fail to restore its serialized state due to resource allocation failures, or if the old and new versions have diverged sufficiently that the old state is not usable by the new version."

    Ich bin mir recht sicher, dass das Serialisierungsformat kompatibel gehalten wird.

    Dann weiter:

    "Its popularity is purely the result of an aggressive, dictatorial marketing strategy including elements such as:

    * Engulfing other "essential" system components like udev and making them difficult or impossible to use without systemd (but see eudev).
    "
    Das ist erstunken und erlogen. Debian baut sein udev-Paket aus den udev-Quellen, die im systemd-Baum entwickelt werden. Diese haben keinerlei Laufzeitabhängigkeit von systemd.

    " * Setting up for API lock-in (having the DBus interfaces provided by systemd become a necessary API that user-level programs depend on).
    "
    Eine stabile API ist doch wunderbar! Das macht die Komponenten austauschbar. Und was außer DBus soll man denn als IPC-Nachrichtendienst verwenden? Sowas ist bei Microkerneln ohnehin Standard und auch Linux wird dank kdbus sowas bald integriert haben.

    "
    * Dictating policy rather than being scoped such that the user, administrator, or systems integrator (distribution) has to provide glue. This eliminates bikesheds and thereby fast-tracks adoption at the expense of flexibility and diversity.
    "
    Das wird sogar als Feature angesehen, als Nutzer sehe ich da auch Vorteile, so dass man sich bei einer neuen Distribution sofort zurechtfindet.


    "So how should init be done right?
    The Unix way: with simple self-contained programs that do one thing and do it well."

    Das ist der Standard-Spruch, den man ständig hört.... Böse Zungen sagen, dass systemd genau der Unix-Weg ist: ein Tool, dass alles liefert, was man zum Starten von Diensten braucht.

    "The systemd way: Take advantage of special properties of pid 1 to the maximum extent possible. This leads to ever-expanding scope creep and exacerbates all of the problems described above (and probably many more yet to be discovered)."

    Wie gesagt: Wenn der Kernel eine abgestürtzte PID1 neustartet sehe ich kein Problem.

    "The right way: Do away with everything special about pid 1 by making pid 1 do nothing but start the real init script and then just reap zombies:"

    Und damit verliert man alle Vorteile von PID1.

    Zum PID1 vollstopfen auch eine Aussage von Herrn Poettering:
    "stuffing everything into PID1" is hardly what we do. We have 80+ separate binaries around. The bits of kdbus that will be in PID 1 are mostly how we set up things (a few ioctls) and the handling of the activation events (which are currently already there but awkwardly complex since dbus-daemon and systemd need to stay in close touch to handle this, asynchronously). The more complex bits, like the remarshalling to dbus1 (i.e. the compat for old libdbus1 clients) is outside of PID 1 in a socket activated service. This too, is written in the text above. Ultimately this all makes things a lot simpler. In fact, the D-Bus code in PID 1 after the transition will be substantially shorter than before. So if you are afraid that we "stuff everything into PID1" then you should actually be happy."

    https://plus.google.com/+LennartPoetteringTheOneAndOnly/posts/8RmiAQsW9qf

  13. Re: .... und welcher sinn steckt jetzt hinter dem artikel ?????

    Autor: Anonymer Nutzer 13.05.14 - 02:52

    fesfrank schrieb:
    --------------------------------------------------------------------------------
    > wer sich mit linux auseinander setzt weiss was systemd ist, ein windows
    > user kann damit nichts anfangen

    Und Leute die Windows und Linux parallel nutzen gibt es natürlich nicht? Und sich mit Linux auseinandersetzen ist außer bei diesem einen Artikel für dich aber ansonsten sinnvoll?
    In dem Interview wurden Fragen gestellt. Frag dich mal warum die auch beantwortet wurden.

  14. Re: Es muss keine Software angepasst werden ...

    Autor: Brotbüchse aus Blech 13.05.14 - 09:49

    Sorry, aber das ist Blödsinn.

    Ein Beispiel:
    https://www.redhat.com/archives/libvir-list/2014-February/msg01360.html

  15. Re: .... und welcher sinn steckt jetzt hinter dem artikel ?????

    Autor: bstea 13.05.14 - 22:57

    Man könnte es zusammenfassen: Du hast keine Ahnung. Der Init Prozess ist der erste Prozess wovon alle erben, den kann man nicht neustarten, wie auch. Kann man bei systemd auch nicht(würde aber voraussetzen man liest sich den verlinkten Text mal durch und durchdenkt diesen was geschrieben bzw. nicht beschrieben ist).
    Glibc ist Müll, war es schon immer weshalb im Embedded Bereich keiner den Schrott einsetzt, Landley kommt von Busybox Richtung, hätte man wissen können, wenn man mal seine Seite liest, hast du bestimmt auch nicht getan. Glücklicherweise gibts Alternativen zur bloatigen C Bibliothek.
    Das Serialisierungsformat wurde als Designziel als nicht stabil gekennzeichnet, weil keiner so benutzen sollte. Systemd soll das übernehmen, wie auch die History deren Format auch keinen interessieren muss.
    Debian baute sein Paket wie andere auch auf eine gammlige Systemd Version auf, wo die Teile einzeln noch brauchbar waren. Das ist lange her und nun auch nicht mehr notwendig.
    Dbus ist für eines bekannt zu häufig sinnlos eingesetzt zu werden, hatte auch nicht das Gefühl das es außerhalb von Linux zufriedenstellend lief.
    Unix Way - simpel, modular, halbwegs portabel. Nichts davon trifft auf Systemd zu.
    Und das Lennox, gerne die Sachen beschönigt ist bekannt. Immer sind andere Schuld. Systemd mag einzelne Binaries anbieten, dass es locker um Faktor 10 größer, komplexer und mehr anbietet, als es mal machen sollte, zeigt die planlose Entwicklung. Jetzt heißt es schon, es war alles geplant.

    --
    Erst wenn der letzte Baum gefällt, der letzte Fluss gestaut und der letzte Fisch gefangen ist, werdet ihr feststellen, dass man Biber nicht essen kann!

  16. Schwacher Artikel

    Autor: Hello_World 14.05.14 - 00:59

    Landley schreibt in dem Artikel eine Menge Unfug. Beispielsweise behauptet er, dass Linux ein OS sei, in dem jede Komponente ausgetauscht werden könne, und als Beispiel nennt er ausgerechnet gcc, weil er die ISO-C-Standards implementiert. Aber das ist Unfug, denn die Entwicklung des Linux-Kernels war immer auf gcc geeicht und man machte umfangreichen Gebrauch von unportablen gcc-Erweiterungen. Mittlerweile kann man den Kernel wohl auch mit anderen Compilern (Intel und LLVM) bauen, aber nicht, weil es einen ISO-Standard gibt, sondern weil diese Compiler mittlerweile viele der ehemals gcc-spezifischen Features nachgebaut haben.
    Weiter geht es mit der Argumentation, dass der Linux-Kernel modular sei, und man deswegen die Wahl zwischen verschiedenen Treibern für die gleiche Hardware habe, beispielsweise dem proprietären nvidia-Treiber und „noveau“ (sic). Nur leider ist das Unfug: Wenn man verschiedene Grafikchips (nvidia, AMD, Intel) unterstützen will, braucht man verschiedene Treiber, daher führt kein Weg darum herum, irgendeine Form von Schnittstelle zu bieten, auf die diese Treiber aufsetzen können. Und wenn diese Schnittstelle dann einmal da ist, kann man natürlich auch mehrere Treiber für die gleiche Hardware schreiben. Sinn macht das aber nicht, und deswegen gibt es auch in der Regel nur einen Treiber. Dass es für Grafikchips verschiedene gibt, liegt nicht daran, dass das so toll wäre, sondern daran, dass einer davon proprietär ist. Und wenn es doch einmal mehrere Open-Source-Treiber gibt, wird in der Regel nach kurzer Zeit einer davon beerdigt, so geschehen beispielsweise im Falle des radeonhd-Treibers. Zudem sind die Schnittstellen für Kernelmodule auch stabil, sie ändern sich also alle paar Kernel-Releases. Fazit: Kernelmodule haben exakt gar nichts damit zu tun, dass irgendjemand ein Kernelmodul durch ein anderes mit gleicher Funktionalität austauschen will (denn dann gäbe es stabile Schnittstellen), sondern nur mit Ressourcenersparnis und Erleichterungen für die Anwender.
    Dann ist da ein Haufen sinnloses Blabla über die Konfigurierbarkeit von Komponenten. Im Linux-Kernel kann man a.out-Unterstützung einkompilieren, bei Busybox kann man buchstäblich alles weglassen und erhält ein Binary, das gar nichts tut. Dass beides heutzutage vollkommen unnütz ist, ficht ihn natürlich nicht an, und genauso ignoriert er vollkommen, dass auch systemd ein configure-Script hat, das prinzipiell das gleiche tut wie das von ihm gepriesene „make menuconfig“ des Linux-Kernels. logind, networkd, timedated, hostnamed, binfmt usw. können allesamt abgeschaltet werden. Und natürlich gibt es Sachen in systemd, die man nicht abschalten kann, aber davon gibt es im Linux-Kernel noch viel mehr, ebenso im X-Server, der ja auch als Beispiel angeführt wird. Das ist übrigens auch eine Perle der Blödheit: XFree86 ist ein klassisches Beispiel für eine hochgradig monolithische Architektur, bei der so ziemlich gar nichts auf einfache Weise austauschbar ist. Dass der Fork X.org Xfree86 ersetzen konnte, lag nicht an irgendwelchen Architekturentscheidungen, sondern daran, dass es am Anfang eben genau der gleiche Code ist, das haben Forks nun einmal so an sich. Und dass der Fork möglich war, ist einzig und allein der Lizenz geschuldet, und natürlich erlaubt das auch die Systemd-Lizenz.
    Weiter geht es mit der Behauptung, dass es keine Schnittstelle gäbe, die reimplementiert werden könnte. Das ist schlicht und einfach eine Lüge, es gibt einen ganzen Haufen dokumentierter Schnittstellen, die, anders als die Linux-Kernel-Schnittstellen, stabil gehalten werden, siehe http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise/ . Dann kommen solche unglaublich dummen Behauptungen wie diese: „ (Reason Linux hasn't cloned it [launchd] yet: xml config files.)“ – was natürlich kompletter Bullshit ist, weil systemd viel mehr und andere Funktionalität umfasst als launchd (und zwar weil diese Funktionalität auch benötigt wird, weswegen ja auch alle relevanten Distris umgestiegen sind). Natürlich darf auch der übliche Bullshit über „having systemd shoved down our throats“ nicht fehlen – als hätten die systemd-Entwickler dazu überhaupt die Möglichkeit! Der ultimative Bullshit ist aber der Vorschlag am Ende, ausgerechnet von Android – einem System, bei dem es nie vorgesehen war, irgendwas frei ersetzen zu können, und das in einem komplett geschlossenen Prozess von einer einzelnen Firma entwickelt wird – einen neuen Linux-Userspace ableiten zu wollen.

    Kurz: dieser Blog-Eintrag ist so ziemlich das dümmste, was ich in den letzten Wochen gelesen habe. Unlogisch, fehlinformiert und trollig, insofern passt er hervorragend zu Deinen Postings.

  17. Re: .... und welcher sinn steckt jetzt hinter dem artikel ?????

    Autor: Hello_World 14.05.14 - 03:04

    bstea schrieb:
    --------------------------------------------------------------------------------
    > Man könnte es zusammenfassen: Du hast keine Ahnung. Der Init Prozess ist
    > der erste Prozess wovon alle erben, den kann man nicht neustarten, wie
    > auch.
    Nein, DU hat keine Ahnung. Offensichtlich fehlen Dir elementarste Unix-Grundlagen. Oder um's konkret zu machen: Du hast execve nicht verstanden.
    https://en.wikipedia.org/wiki/Exec_%28operating_system%29

    > Kann man bei systemd auch nicht(würde aber voraussetzen man liest
    > sich den verlinkten Text mal durch und durchdenkt diesen was geschrieben
    > bzw. nicht beschrieben ist).
    Doch, das kann systemd, und das konnte sogar schon sysvinit.

    > Glibc ist Müll, war es schon immer weshalb im Embedded Bereich keiner den
    > Schrott einsetzt,
    Ja, genau, und weil es so ein Schrott ist, wird es überall anders eben doch eingesetzt und hat auch die Linux-libc5 verdrängt. Ach, und natürlich auch im embedded-Bereich, siehe libhybris und eglibc.

    > Landley kommt von Busybox Richtung, hätte man wissen
    > können, wenn man mal seine Seite liest, hast du bestimmt auch nicht getan.
    > Glücklicherweise gibts Alternativen zur bloatigen C Bibliothek.
    > Das Serialisierungsformat wurde als Designziel als nicht stabil
    > gekennzeichnet, weil keiner so benutzen sollte. Systemd soll das
    > übernehmen, wie auch die History deren Format auch keinen interessieren
    > muss.
    Welche Rolle spielt es, woran Landley bisher gearbeitet hat? Welche Rolle spielt das Serialisierungsformat, und was soll der Satz, in dem Du dieses Wort verwendest, überhaupt bedeuten? Die Syntax dieses Satzes ist nicht nur falsch, sie ist so kaputt, dass man die Bedeutung nicht einmal mehr erahnen kann. Und von welcher History redest Du, und was soll systemd (sic) übernehmen und von wem‽ Was Du hier schreibst ist nicht nur nicht richtig, es ist noch nicht einmal falsch, sondern einfach nur konfus.

    > Dbus ist für eines bekannt zu häufig sinnlos eingesetzt zu werden,
    Elementarer logischer Fehler: Du schließt aus einer allgemeinen Aussage (die übrigens falsch ist) auf einen konkreten Fall. Oder anders gesagt: Wenn Du der Meinung bist, dass systemd D-Bus sinnlos einsetze, dann begründe das doch bitte konkret, und nicht mit unnachvollziehbaren allgemeinen Behauptungen.

    > hatte
    > auch nicht das Gefühl das es außerhalb von Linux zufriedenstellend lief.
    Ach ja „Das Gefühl“. Was _genau_ lief da nicht zufriedenstellend? dbus-daemon ist portabel und läuft unter anderen Systemen einwandfrei. Von Bedeutung ist das freilich nicht, denn systemd läuft ja ohnehin nur unter Linux (und jetzt wirst Du natürlich wieder behaupten, dass das ja ganz furchtbar wäre, obwohl Dir schon x Leute erklärt haben, warum ein portables init Unsinn ist – erspar's uns doch bitte wenigstens dieses eine Mal, OK?)

    > Unix Way - simpel, modular, halbwegs portabel. Nichts davon trifft auf
    > Systemd zu.
    > Und das Lennox, gerne die Sachen beschönigt ist bekannt. Immer sind andere
    > Schuld. Systemd mag einzelne Binaries anbieten, dass es locker um Faktor 10
    > größer, komplexer und mehr anbietet, als es mal machen sollte, zeigt die
    > planlose Entwicklung. Jetzt heißt es schon, es war alles geplant.
    Wie ich andernorts bereits erwähnt habe, sind weite Teile der Funktionalität von systemd optional, darunter logind, vconsole-setup, shutdownd, hostnamed, localed, binfmt, timedated, networkd und noch mehr. Also wenn es Dir nicht passt, dann benutz es eben nicht. Natürlich liefern die meisten Distributionen den ganzen Kram trotzdem mit, weil man die entsprechende Funktionalität ansonsten eben selbst entwickeln und warten müsste, und da die meisten dieser Komponenten nicht übermäßig spannend sind, widmet man sich lieber interessanteren Sachen, als systemd aus Prinzip zu bekämpfen.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. InnoGames GmbH, Hamburg
  2. SDL, Leipzig / München
  3. Statistisches Bundesamt, Wiesbaden
  4. DIgSILENT GmbH, Gomaringen

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. (u. a. MSI Optix G24C für 155,00€, Asus VP278H für 125,00€, LG 27UD59-W für 209,00€ und HP...
  2. 1439,90€ (Vergleichspreis: 1530,95€)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Sicherheitslücken: Microsoft-Parkhäuser ungeschützt im Internet
Sicherheitslücken
Microsoft-Parkhäuser ungeschützt im Internet

Eigentlich sollte die Parkhaussteuerung nicht aus dem Internet erreichbar sein. Doch auf die Parkhäuser am Microsoft-Hauptsitz in Redmond konnten wir problemlos zugreifen. Nicht das einzige Sicherheitsproblem auf dem Parkhaus-Server.
Von Moritz Tremmel

  1. Datenleck Microsoft-Datenbank mit 250 Millionen Support-Fällen im Netz
  2. Office 365 Microsoft testet Werbebanner in Wordpad für Windows 10
  3. Application Inspector Microsoft legt Werkzeug zur Code-Analyse offen

Support-Ende von Windows 7: Für wen Linux eine Alternative zu Windows 10 ist
Support-Ende von Windows 7
Für wen Linux eine Alternative zu Windows 10 ist

Windows 7 erreicht sein Lebensende (End of Life) und wird von Microsoft künftig nicht mehr mit Updates versorgt. Lohnt sich ein Umstieg auf Linux statt auf Windows 10? Wir finden: in den meisten Fällen schon.
Von Martin Loschwitz

  1. Lutris EA verbannt offenbar Linux-Gamer aus Battlefield 5
  2. Linux-Rechner System 76 will eigene Laptops bauen
  3. Grafiktreiber Nvidia will weiter einheitliches Speicher-API für Linux

30 Jahre Champions of Krynn: Rückkehr ins Reich der Drachen und Drakonier
30 Jahre Champions of Krynn
Rückkehr ins Reich der Drachen und Drakonier

Champions of Krynn ist das dritte AD&D-Rollenspiel von SSI, es zählt zu den Highlights der Gold-Box-Serie. Passend zum 30. Geburtstag hat sich unser Autor den Klassiker noch einmal angeschaut - und nicht nur mit Drachen, sondern auch mit dem alten Kopierschutz gekämpft.
Ein Erfahrungsbericht von Benedikt Plass-Fleßenkämper

  1. Dungeons & Dragons Dark Alliance schickt Dunkelelf Drizzt nach Icewind Dale

  1. Wasserverbrauch: Musk verteidigt Gigafactory als umweltfreundlich
    Wasserverbrauch
    Musk verteidigt Gigafactory als umweltfreundlich

    Nach Kritik aus der Bevölkerung hat sich Tesla-Chef Elon Musk persönlich in die Debatte um die geplante Gigafactory für Elektroautos in Brandenburg eingeschaltet. Auch die Landesregierung sieht die Gerüchteküche brodeln.

  2. United States Space Force: Sternenflotten-artiges Logo verärgert Star-Trek-Fans
    United States Space Force
    Sternenflotten-artiges Logo verärgert Star-Trek-Fans

    Präsident Donald Trump hat das Logo der Space Force präsentiert, einer neuen Teilstreitkraft der Vereinigten Staaten. Weil das Logo der Militärsparte stark an das der Sternenflotte von Star Trek erinnert, gibt es Kritik.

  3. ROG Strix XG17AHPE: Asus zeigt USB-Monitor mit 17 Zoll und 240 Hz
    ROG Strix XG17AHPE
    Asus zeigt USB-Monitor mit 17 Zoll und 240 Hz

    Portables Display für unterwegs: Der ROG Strix XG17AHPE ist ein 17-Zöller mit 1080p-Auflösung und 240 Hz. Laut Asus eignet sich der Bildschirm für Gaming am Notebook, selbst ein Akku ist integriert.


  1. 13:15

  2. 12:50

  3. 11:43

  4. 19:34

  5. 16:40

  6. 16:03

  7. 15:37

  8. 15:12