1. Foren
  2. Kommentare
  3. Security-Forum
  4. Alle Kommentare zum Artikel
  5. › Log4Shell: BSI vergibt höchste…

OSS vs. CSS

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. OSS vs. CSS

    Autor: Methylasem 12.12.21 - 18:17

    Das ist jetzt wieder einer der Vorfälle, auf die die "Commercials" dann gerne argumentativ zurückgreifen, wenn sie ihren Anspruch begründen wollen, daß nur sie wirklich "professionelle" Software anbieten.

    Deswegen finde ich es immer äußerst problematisch, von "Hobby" Projekten zu sprechen, sobald Software nicht im Rahmen eines direkten Auftrags mit exklusiver Nutzung entsteht.

    Sowohl jene "Commercials" als auch generell Jene, die von "Hobby-Projekten" sprechen, unterschlagen dann unwissentlich, ungewollt oder bewusst, dass OpenSource eben nicht synonym für "kostenlos" oder "Hobby" steht, sondern ein spezieller und in der Industrie längst etablierter Softwareentwicklungsprozess ist, der bewusst und notwendigerweise fundamental anders als klassische Auftragsentwicklung (die auch OSS sein kann) strukturiert ist.
    In diesem Vorfall relevante wesentliche Kennzeichen sind die Dezentralisierung und die Zusammenarbeit der Prozessbeteiligten.

    Vorfälle wie dieser treten dann nicht deshalb auf, weil der Entwickler schlechte Arbeit geleistet hätte, oder weil das OSS Prozessdesign fehlerhaft wäre, sondern weil bestimmte Prozessbeteiligte nicht ihren Beitrag leisten oder versäumen, ihrer eigenen Verantwortung nachzukommen.

    Das sind auch solche Nutzer, die sich weder finanziell noch über Mitarbeit an der Entwicklung beteiligen, aber als Netto-Nutzer auftreten. Die vielleicht sogar OSS Produkte in ihrer Domäne monetarisieren und dann im schlimmsten Fall nicht einmal von den so erzielten Gewinnen einen "Fairshare" in die Entwicklung zurückgekoppelt.

    Solcher Missbrauch war einer der von IBM angeführten Gründe, bei CentOS den Stecker zu ziehen. Daß auf dieses Argument von den IBM Kritikern deutlich weniger eingegangen wurde, als auf andere Aspekte dieses eigenen "Falls", schien mir darauf hinzuweisen, daß da einige der Kritiker des CentOS-Kurswechsels recht tief im Glashaus saßen.

    Eine wichtige Lehre (aber keinewegs neue Erkenntnis) aus diesem Vorfall muss sein: der Einsatz von OpenSource-Software ist nicht unprofessionell, sondern erfordert Eigenverantwortung der Anwender, und damit eine entprechende Mindestausstattung an professioneller Kompetenz, um dieser gerecht werden zu können.

    M.a.w.: nicht OSS ist unprofessionell, sondern im Zweifelsfall ihr Nutzer.

    Die Verantwortung kann nur gemeinsam vom Entwickler und dem Nutzer getragen werden.
    Hier liegt gerade einer der signifikanten Vorteile von OSS gegenüber CSS (Closed Source Software): der Nutzer *kann* diese Verantwortung auch wahrnehmen, während man bei CSS auf das Verantwortungsbewusstsein des Anbieters vertrauen muss. Und bei entsprechend kritischen Projekten hilft einem im Schadensfall das Ruhekissen der mitgekauften rechtliche Haftung dann manchmal auch nicht weiter.



    1 mal bearbeitet, zuletzt am 12.12.21 18:18 durch Methylasem.

  2. Re: OSS vs. CSS

    Autor: Slartie 12.12.21 - 22:06

    Welche tolle closed source Logging-Library sollte ich denn dann kaufen? Also ich kenne nicht eine einzige.

    Dafür kenne ich gleich mehrere closed source Programme, die Log4j benutzen. Die sind jetzt alle erst mal genau so gef**** wie die Open-Source-Software, da gibt es genau null Unterschied.

  3. Re: OSS vs. CSS

    Autor: demon driver 12.12.21 - 22:42

    Methylasem schrieb:
    --------------------------------------------------------------------------------
    > Das ist jetzt wieder einer der Vorfälle, auf die die "Commercials" dann
    > gerne argumentativ zurückgreifen, wenn sie ihren Anspruch begründen wollen,
    > daß nur sie wirklich "professionelle" Software anbieten [...]

    Ja, aber der entscheidende Unterschied ist hier doch, dass irgendeine Closed-Source-Bibliothek, die irgendeine Firma von ihren professionellen Entwicklern hätte entwickeln lassen, auch keine geringere Wahrscheinlichkeit hätte, dass man irgendwann mal so einen Fehler findet. Bei der massenhaft verbreiteten Open-Source-Bibliothek fällt's aber auf – und ist dann auch extrem schnell gefixt, trotz unbezahlten Entwicklern.

    Vor allem aber ist die Frage doch längst ausdiskutiert. Kein Mensch käme in dem Bereich auf die Idee, für eine solche Java-Library ernsthaft nach Closed Source zu suchen. Open Source ist da längst die Regel, nicht die Ausnahme.

  4. Re: OSS vs. CSS

    Autor: Methylasem 13.12.21 - 10:30

    Slartie schrieb:
    --------------------------------------------------------------------------------
    > Welche tolle closed source Logging-Library sollte ich denn dann kaufen?
    > Also ich kenne nicht eine einzige.
    >
    Exakt: das ist ja auch gut so, und zeigt ja auch, wie attraktiv die Lösung ist. Es wäre aber eben auch interessant, in welchem Masse von diesen Nutzern entsprechende Rückkoppelung in das Projekt erfolgt. Mir fehlt leider die Einsicht, in welchem Umfange das erfolgt, es würde mich aber sehr interessieren. Ich vermute aber, daß das nicht immer fair abläuft.

  5. Re: OSS vs. CSS

    Autor: Methylasem 13.12.21 - 10:36

    demon driver schrieb:
    --------------------------------------------------------------------------------
    > Methylasem schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Das ist jetzt wieder einer der Vorfälle, auf die die "Commercials" dann
    > > gerne argumentativ zurückgreifen, wenn sie ihren Anspruch begründen
    > wollen,
    > > daß nur sie wirklich "professionelle" Software anbieten [...]
    >
    > Ja, aber der entscheidende Unterschied ist hier doch, dass irgendeine
    > Closed-Source-Bibliothek, die irgendeine Firma von ihren professionellen
    > Entwicklern hätte entwickeln lassen, auch keine geringere
    > Wahrscheinlichkeit hätte, dass man irgendwann mal so einen Fehler findet.
    > Bei der massenhaft verbreiteten Open-Source-Bibliothek fällt's aber auf
    > – und ist dann auch extrem schnell gefixt, trotz unbezahlten
    > Entwicklern.
    >
    Das ist auch meine Erfahrung, zumal Bugbounty-Programme kommerzieller Anbieter ja den prinzipiellen Nachteil gegenüber OSS zu kompensieren versuchen. Ich habe aber auch selbst erlebt, daß in CSS Produkten dann Fixes nicht mehr in ältere Releases backported werden, sondern als Lösungsvorschlag auf ein Update/Upgrade verwiesen wird, was ich bei OSS bisher noch nicht erlebt habe.

    > Vor allem aber ist die Frage doch längst ausdiskutiert. Kein Mensch käme in
    > dem Bereich auf die Idee, für eine solche Java-Library ernsthaft nach
    > Closed Source zu suchen. Open Source ist da längst die Regel, nicht die
    > Ausnahme.

    Das wäre gut. Aber der unstete Verlauf z.B. des LIMUX Projektes zeigt auch, daß es da keine abschliessende Etablierung geben wird, solange sich die Strategie der kommerziellen Player nicht ändert (was sie ja tut, was widerum nicht so gut ist, wie es klingt). Ich kenne namhafte nationale Organisationen wissenschaftlicher Einrichtungen, in denen OSS Lösungen grosso modo immer noch als "Bastellösung" (O-Ton) klassifiziert werden und regelmäßig hinter die bekannten Standartansätze zurücktreten müssen, selbst wenn man gleichzeitig von den gleichen Anbietern mit den unglaublichsten Lizenzbedingungen geknebelt wird. Wenn man dann nachfragt, fällt sehr wahrscheinlich der "Hobbyprogrammierer". Daher meine Bedenken bzgl. der Verwendung dieses Begriffes, mit dem man aus diesen Gründen vorsichtig sein muss.

    Das Problem aus meiner Sicht ist, daß eine kompetente Abwägung von OSS vs. CSS eine Sachkenntnis voraussetzt, die man auf Entscheiderebene i.a. nicht mehr voraussetzen kann. Der Verfall der Bedeutung der CIO-Rolle in Organsiationsstrukturen spielt dabei sicher eine wesentliche Rolle.

  6. Re: OSS vs. CSS

    Autor: demon driver 13.12.21 - 13:36

    Methylasem schrieb:
    --------------------------------------------------------------------------------
    > demon driver schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Methylasem schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > -----
    > > > Das ist jetzt wieder einer der Vorfälle, auf die die "Commercials"
    > dann
    > > > gerne argumentativ zurückgreifen, wenn sie ihren Anspruch begründen
    > > wollen,
    > > > daß nur sie wirklich "professionelle" Software anbieten [...]
    > >
    > > Ja, aber der entscheidende Unterschied ist hier doch, dass irgendeine
    > > Closed-Source-Bibliothek, die irgendeine Firma von ihren professionellen
    > > Entwicklern hätte entwickeln lassen, auch keine geringere
    > > Wahrscheinlichkeit hätte, dass man irgendwann mal so einen Fehler
    > findet.
    > > Bei der massenhaft verbreiteten Open-Source-Bibliothek fällt's aber auf
    > > – und ist dann auch extrem schnell gefixt, trotz unbezahlten
    > > Entwicklern.
    > >
    > Das ist auch meine Erfahrung, zumal Bugbounty-Programme kommerzieller
    > Anbieter ja den prinzipiellen Nachteil gegenüber OSS zu kompensieren
    > versuchen. Ich habe aber auch selbst erlebt, daß in CSS Produkten dann
    > Fixes nicht mehr in ältere Releases backported werden, sondern als
    > Lösungsvorschlag auf ein Update/Upgrade verwiesen wird, was ich bei OSS
    > bisher noch nicht erlebt habe.
    >
    > > Vor allem aber ist die Frage doch längst ausdiskutiert. Kein Mensch käme in
    > > dem Bereich auf die Idee, für eine solche Java-Library ernsthaft nach
    > > Closed Source zu suchen. Open Source ist da längst die Regel, nicht die
    > > Ausnahme.
    >
    > Das wäre gut. Aber der unstete Verlauf z.B. des LIMUX Projektes

    In dem Riesen-Segment, in dem mit Java und JVM Unternehmenssoftware entwickelt wird, da wird im Normalfall alles mit Open Source abgedeckt, was sich damit abdecken lässt, da ist die Diskussion wirklich schon seit vielen Jahren beendet.

    Dass das in anderen Bereichen, vor allem auch außerhalb der reinen Softwareentwicklung, noch anders ist, das streite ich gar nicht ab.

    > zeigt auch,
    > daß es da keine abschliessende Etablierung geben wird, solange sich die
    > Strategie der kommerziellen Player nicht ändert (was sie ja tut, was
    > widerum nicht so gut ist, wie es klingt). Ich kenne namhafte nationale
    > Organisationen wissenschaftlicher Einrichtungen, in denen OSS Lösungen
    > grosso modo immer noch als "Bastellösung" (O-Ton) klassifiziert werden und
    > regelmäßig hinter die bekannten Standartansätze zurücktreten müssen, selbst
    > wenn man gleichzeitig von den gleichen Anbietern mit den unglaublichsten
    > Lizenzbedingungen geknebelt wird. Wenn man dann nachfragt, fällt sehr
    > wahrscheinlich der "Hobbyprogrammierer". Daher meine Bedenken bzgl. der
    > Verwendung dieses Begriffes, mit dem man aus diesen Gründen vorsichtig sein
    > muss.

    Völlig richtig.

    > Das Problem aus meiner Sicht ist, daß eine kompetente Abwägung von OSS vs.
    > CSS eine Sachkenntnis voraussetzt, die man auf Entscheiderebene i.a. nicht
    > mehr voraussetzen kann. Der Verfall der Bedeutung der CIO-Rolle in
    > Organsiationsstrukturen spielt dabei sicher eine wesentliche Rolle.

    Da bin ich nicht sicher. Ich meine nicht, dass der Zustand gut ist, aber habe auch nicht den Eindruck, dass er irgendwann schon mal besser war ;-)

    Die Gesamttendenz geht ja zum Glück doch immer mehr in Richtung Akzeptanz und Einsatz von Open Source, inzwischen sogar im öffentlichen Bereich (siehe Schleswig-Holstein), wo die Skepsis und der Grundsatz "was nichts kostet, kann auch nichts taugen" traditionell nach meinem Eindruck besonders hartnäckig waren.

  7. Re: OSS vs. CSS

    Autor: Methylasem 13.12.21 - 22:46

    Methylasem schrieb:
    --------------------------------------------------------------------------------
    > Das ist jetzt wieder einer der Vorfälle, auf die die "Commercials" dann
    > gerne argumentativ zurückgreifen, wenn sie ihren Anspruch begründen wollen,
    > daß nur sie wirklich "professionelle" Software anbieten.
    >
    > Deswegen finde ich es immer äußerst problematisch, von "Hobby" Projekten zu
    > sprechen, sobald Software nicht im Rahmen eines direkten Auftrags mit
    > exklusiver Nutzung entsteht.
    >
    > Sowohl jene "Commercials" als auch generell Jene, die von "Hobby-Projekten"
    > sprechen, unterschlagen dann unwissentlich, ungewollt oder bewusst, dass
    > OpenSource eben nicht synonym für "kostenlos" oder "Hobby" steht, sondern
    > ein spezieller und in der Industrie längst etablierter
    > Softwareentwicklungsprozess ist, der bewusst und notwendigerweise
    > fundamental anders als klassische Auftragsentwicklung (die auch OSS sein
    > kann) strukturiert ist.
    > In diesem Vorfall relevante wesentliche Kennzeichen sind die
    > Dezentralisierung und die Zusammenarbeit der Prozessbeteiligten.
    >
    > Vorfälle wie dieser treten dann nicht deshalb auf, weil der Entwickler
    > schlechte Arbeit geleistet hätte, oder weil das OSS Prozessdesign
    > fehlerhaft wäre, sondern weil bestimmte Prozessbeteiligte nicht ihren
    > Beitrag leisten oder versäumen, ihrer eigenen Verantwortung nachzukommen.
    >
    > Das sind auch solche Nutzer, die sich weder finanziell noch über Mitarbeit
    > an der Entwicklung beteiligen, aber als Netto-Nutzer auftreten. Die
    > vielleicht sogar OSS Produkte in ihrer Domäne monetarisieren und dann im
    > schlimmsten Fall nicht einmal von den so erzielten Gewinnen einen
    > "Fairshare" in die Entwicklung zurückgekoppelt.
    >
    > Solcher Missbrauch war einer der von IBM angeführten Gründe, bei CentOS den
    > Stecker zu ziehen. Daß auf dieses Argument von den IBM Kritikern deutlich
    > weniger eingegangen wurde, als auf andere Aspekte dieses eigenen "Falls",
    > schien mir darauf hinzuweisen, daß da einige der Kritiker des
    > CentOS-Kurswechsels recht tief im Glashaus saßen.
    >
    > Eine wichtige Lehre (aber keinewegs neue Erkenntnis) aus diesem Vorfall
    > muss sein: der Einsatz von OpenSource-Software ist nicht unprofessionell,
    > sondern erfordert Eigenverantwortung der Anwender, und damit eine
    > entprechende Mindestausstattung an professioneller Kompetenz, um dieser
    > gerecht werden zu können.
    >
    > M.a.w.: nicht OSS ist unprofessionell, sondern im Zweifelsfall ihr Nutzer.
    >
    > Die Verantwortung kann nur gemeinsam vom Entwickler und dem Nutzer getragen
    > werden.
    > Hier liegt gerade einer der signifikanten Vorteile von OSS gegenüber CSS
    > (Closed Source Software): der Nutzer *kann* diese Verantwortung auch
    > wahrnehmen, während man bei CSS auf das Verantwortungsbewusstsein des
    > Anbieters vertrauen muss. Und bei entsprechend kritischen Projekten hilft
    > einem im Schadensfall das Ruhekissen der mitgekauften rechtliche Haftung
    > dann manchmal auch nicht weiter.

    Um das Bild durch einen interessanten Aspekt zu vervollständigen: ein internationaler Anbierter von Enterprise Security Lösungen (worldwide corporate endpoint security top "ganz vorne" 2020) hat heute seine Kunden unterrichtet, daß ihr Enterpriseprodukt ebenfalls betroffen ist.
    Die Schwachstelle ist also auch dort entweder nicht erkannt worden, oder eine entsprecehnde Untersuchung gar nicht erfolgt. Wenn man grundsätzlich gleiche Softwareentwicklungstandarts für die open- und closed-source Komponente des betroffenen Gesamtprodukts annimmt, ergeben sich entsprechende Schlussfolgerungen für den Vergleich von OSS- und CSS-Sicherheit.

  8. Re: OSS vs. CSS

    Autor: Methylasem 13.12.21 - 23:00

    demon driver schrieb:
    --------------------------------------------------------------------------------
    > Methylasem schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > demon driver schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > -----
    > > > Methylasem schrieb:
    > > >
    > >
    > ---------------------------------------------------------------------------
    >
    > >
    > > > -----
    > > > > Das ist jetzt wieder einer der Vorfälle, auf die die "Commercials"
    > > dann
    > > > > gerne argumentativ zurückgreifen, wenn sie ihren Anspruch begründen
    > > > wollen,
    > > > > daß nur sie wirklich "professionelle" Software anbieten [...]
    > > >
    > > > Ja, aber der entscheidende Unterschied ist hier doch, dass irgendeine
    > > > Closed-Source-Bibliothek, die irgendeine Firma von ihren
    > professionellen
    > > > Entwicklern hätte entwickeln lassen, auch keine geringere
    > > > Wahrscheinlichkeit hätte, dass man irgendwann mal so einen Fehler
    > > findet.
    > > > Bei der massenhaft verbreiteten Open-Source-Bibliothek fällt's aber
    > auf
    > > > – und ist dann auch extrem schnell gefixt, trotz unbezahlten
    > > > Entwicklern.
    > > >
    > > Das ist auch meine Erfahrung, zumal Bugbounty-Programme kommerzieller
    > > Anbieter ja den prinzipiellen Nachteil gegenüber OSS zu kompensieren
    > > versuchen. Ich habe aber auch selbst erlebt, daß in CSS Produkten dann
    > > Fixes nicht mehr in ältere Releases backported werden, sondern als
    > > Lösungsvorschlag auf ein Update/Upgrade verwiesen wird, was ich bei OSS
    > > bisher noch nicht erlebt habe.
    > >
    > > > Vor allem aber ist die Frage doch längst ausdiskutiert. Kein Mensch
    > käme in
    > > > dem Bereich auf die Idee, für eine solche Java-Library ernsthaft nach
    > > > Closed Source zu suchen. Open Source ist da längst die Regel, nicht
    > die
    > > > Ausnahme.
    > >
    > > Das wäre gut. Aber der unstete Verlauf z.B. des LIMUX Projektes
    >
    > In dem Riesen-Segment, in dem mit Java und JVM Unternehmenssoftware
    > entwickelt wird, da wird im Normalfall alles mit Open Source abgedeckt, was
    > sich damit abdecken lässt, da ist die Diskussion wirklich schon seit vielen
    > Jahren beendet.
    >
    > Dass das in anderen Bereichen, vor allem auch außerhalb der reinen
    > Softwareentwicklung, noch anders ist, das streite ich gar nicht ab.
    >
    > > zeigt auch,
    > > daß es da keine abschliessende Etablierung geben wird, solange sich die
    > > Strategie der kommerziellen Player nicht ändert (was sie ja tut, was
    > > widerum nicht so gut ist, wie es klingt). Ich kenne namhafte nationale
    > > Organisationen wissenschaftlicher Einrichtungen, in denen OSS Lösungen
    > > grosso modo immer noch als "Bastellösung" (O-Ton) klassifiziert werden
    > und
    > > regelmäßig hinter die bekannten Standartansätze zurücktreten müssen,
    > selbst
    > > wenn man gleichzeitig von den gleichen Anbietern mit den unglaublichsten
    > > Lizenzbedingungen geknebelt wird. Wenn man dann nachfragt, fällt sehr
    > > wahrscheinlich der "Hobbyprogrammierer". Daher meine Bedenken bzgl. der
    > > Verwendung dieses Begriffes, mit dem man aus diesen Gründen vorsichtig
    > sein
    > > muss.
    >
    > Völlig richtig.
    >
    > > Das Problem aus meiner Sicht ist, daß eine kompetente Abwägung von OSS
    > vs.
    > > CSS eine Sachkenntnis voraussetzt, die man auf Entscheiderebene i.a.
    > nicht
    > > mehr voraussetzen kann. Der Verfall der Bedeutung der CIO-Rolle in
    > > Organsiationsstrukturen spielt dabei sicher eine wesentliche Rolle.
    >
    > Da bin ich nicht sicher. Ich meine nicht, dass der Zustand gut ist, aber
    > habe auch nicht den Eindruck, dass er irgendwann schon mal besser war ;-)
    >
    Meine Erfahrungen beziehen sich ebenfalls auf den ÖD, und in dem mir zugänglichen Umfeld wird die IT-Leitung nur in Ausnahmefällen von Fachläuten besetzt. Fachfremde "IT-Verantwortliche" haben nicht immer die Fachkenntnis, solche Fragen so weit zu verstehen, daß sie sich eine autonome Entscheidung zutrauen können, und wählen dann im Zweifelsfall die Lösung, für die im Branchenjargon noch nie jemand gefeuert worden ist ;-)
    Eine dedizierte "C-level" IT Stelle war vor 10 Jahren in meinem Umfeld noch deutlich selbstverständlicher.
    > Die Gesamttendenz geht ja zum Glück doch immer mehr in Richtung Akzeptanz
    > und Einsatz von Open Source, inzwischen sogar im öffentlichen Bereich
    > (siehe Schleswig-Holstein), wo die Skepsis und der Grundsatz "was nichts
    > kostet, kann auch nichts taugen" traditionell nach meinem Eindruck
    > besonders hartnäckig waren.

  9. Re: OSS vs. CSS

    Autor: demon driver 14.12.21 - 11:17

    Methylasem schrieb:
    --------------------------------------------------------------------------------
    > demon driver schrieb:
    > ---------------------------------------------------------------------------
    > > Methylasem schrieb:
    > > ---------------------------------------------------------------------------

    > > > Das Problem aus meiner Sicht ist, daß eine kompetente Abwägung von OSS vs.
    > > > CSS eine Sachkenntnis voraussetzt, die man auf Entscheiderebene i.a. nicht
    > > > mehr voraussetzen kann. Der Verfall der Bedeutung der CIO-Rolle in
    > > > Organsiationsstrukturen spielt dabei sicher eine wesentliche Rolle.
    > >
    > > Da bin ich nicht sicher. Ich meine nicht, dass der Zustand gut ist, aber
    > > habe auch nicht den Eindruck, dass er irgendwann schon mal besser war ;-)
    > >
    > Meine Erfahrungen beziehen sich ebenfalls auf den ÖD, und in dem mir
    > zugänglichen Umfeld wird die IT-Leitung nur in Ausnahmefällen von
    > Fachläuten besetzt. Fachfremde "IT-Verantwortliche" haben nicht immer die
    > Fachkenntnis, solche Fragen so weit zu verstehen, daß sie sich eine
    > autonome Entscheidung zutrauen können, und wählen dann im Zweifelsfall die
    > Lösung, für die im Branchenjargon noch nie jemand gefeuert worden ist ;-)
    > Eine dedizierte "C-level" IT Stelle war vor 10 Jahren in meinem Umfeld noch
    > deutlich selbstverständlicher.

    Ok, mag sein... Zumal, soweit ich Einblick dort habe, die Tendenz der letzten ein, zwei Jahrzehnte im öffentlichen Dienst zwar nicht durchweg eine Verschlechterung war, aber doch eine immer weitergehende "Verbetriebswirtschaftlichung", die vor allem auch zu Einsparungen beim Personal führten. Mal ganz abgesehen davon, dass ein "CIO" für TVöD-Geld auch erst mal gefunden werden muss.

  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. Softwareentwickler Java (m/w/d)
    Atruvia AG, Karlsruhe, München, Münster
  2. Verwaltungsprofessur (W2) für das Lehrgebiet Informatik
    HAWK - Fachhochschule Hildesheim/Holzminden/Göttingen Leitweg-ID: 030-0000000087-83, Göttingen
  3. IT-Berater / Fachlicher Lead Digitalstrategie (w/m/d)
    Dataport, verschiedene Standorte
  4. (Senior) MLOps Engineer (Cloud) (m/f/d)
    Lidl Digital, Berlin, Neckarsulm

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. 499,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Ferngesteuertes Auto ausprobiert: Wenn 4G für das Autofahren nicht ausreicht
Ferngesteuertes Auto ausprobiert
Wenn 4G für das Autofahren nicht ausreicht

Der Carsharing-Anbieter Elmo zeigt uns seine Lösung für ferngesteuertes Fahren in Städten und stößt dabei an die Grenzen der deutschen Mobilfunknetze.
Ein Bericht von Martin Wolf

  1. Elektromobilität Rock Tech Lithium baut Lithiumhydroxid-Fabrik in Guben
  2. Akkutechnik Our Next Energy baut Akku für 1.000 km-BMW-Prototyp
  3. EU-Verkehrsminister Lkw-Ladepunkte an allen wichtigen Straßen bis 2030

Technics EAH-A800 im Praxistest: Tolle faltbare Alternative zu Sonys Oberklasse-Kopfhörer
Technics EAH-A800 im Praxistest
Tolle faltbare Alternative zu Sonys Oberklasse-Kopfhörer

Technics' neuer ANC-Kopfhörer EAH-A800 ist eine der besten Alternativen zu Sonys Oberklasse-Kopfhörer WH-1000XM5. Im Bereich Akkulaufzeit liefert er sogar Spitzenleistung.
Ein Test von Ingo Pakalski


    30 Jahre Fate of Atlantis: Indiana Jones in seinem besten Abenteuer
    30 Jahre Fate of Atlantis
    Indiana Jones in seinem besten Abenteuer

    Mehrere Handlungspfade und Prügeleien: Golem.de hat das vor 30 Jahren veröffentlichte Indiana Jones and the Fate of Atlantis neu ausprobiert.
    Von Andreas Altenheimer

    1. Indiana Jones wird 40 Jahre alt Als Harrison Ford zum ersten Mal die Peitsche schwang

    1. Code-Genossenschaften: Mitbestimmung und Einheitsgehalt statt Frust im Hamsterrad
      Code-Genossenschaften
      Mitbestimmung und Einheitsgehalt statt Frust im Hamsterrad

      Programmieren ohne Chef, das klingt für Angestellte wie ein Traum. Kleine Unternehmen wagen eine hierarchiefreie Graswurzelrevolution.

    2. TADF Technologie: Samsung kauft Cynora in Bruchsal und entlässt alle
      TADF Technologie
      Samsung kauft Cynora in Bruchsal und entlässt alle

      Der Cynora-Chef wollte das deutsche Start-up zum Einhorn entwickeln. Nun wurden die Patente und die TADF-Technologie von Samsung für 300 Millionen Dollar gekauft und das Unternehmen zerschlagen.

    3. Elektroauto: Hyundai Ioniq 6 bekommt ein stromlininienförmiges Design
      Elektroauto
      Hyundai Ioniq 6 bekommt ein stromlininienförmiges Design

      Hyundai hat das Design des Ioniq 6 gezeigt. Mit einer aerodynamischen Karosserie und einem Innenraum mit Wohlfühlambiente soll das Elektroauto Kunden von Tesla abwerben.


    1. 12:00

    2. 11:56

    3. 11:49

    4. 11:36

    5. 11:30

    6. 11:20

    7. 11:00

    8. 10:46