Abo
  1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › Ada und Spark: Mehr…

Es ist keine Frage der Programmiersprache

  1. Thema
  1. 1
  2. 2
  3. 3

Neues Thema Ansicht wechseln


  1. Es ist keine Frage der Programmiersprache

    Autor: MrTridac 11.06.19 - 12:56

    Immer wieder lese ich diese Behauptung.
    Aber das ist quatsch. Ich kann auch mit der besten und sichersten Sprache scheiß Programme schreiben, die einen Fehler nach dem Anderen machen.

    Es ist immer einer Frage des Könnens.
    Ein guter Programmierer schreibt in jeder Sprache gute Programme, ein schlechter schreibt immer schlechte Programme egal in welcher Sprache.

    Sich auf die Fähigkeiten eines Compilers zu verlassen, Fehler zu finden bzw. zu behandeln, ist fahrlässig.
    Schon viel zu oft hab ich den Kommentar gehört: "Ich dachte da kümmert sich der Compiler drum", wenn ich einen tief verborgenen Fehler aufgestöbert habe.

  2. Re: Es ist keine Frage der Programmiersprache

    Autor: \pub\bash0r 11.06.19 - 13:09

    Einige Sprachen machen es dir sehr leicht, beschissenen Code zu schreiben (C), andere machen es dir deutlich schwerer (Rust).
    Wenn das Ziel von einem Entwickler ist, gute, sichere Software zu schreiben, ist es - unabhängig von seinem Können - in seinem Interesse, eine Sprache zu haben, die ihn dabei unterstützt.
    Man greift ja auch so gut wie nicht mehr zu Assembler, obwohl man damit natürlich ebenfalls jedes Problem lösen kann. Aber Abstraktion spart Zeit und damit Geld und macht es einfacher, überhaupt noch zu verstehen, was da an Code vor einem liegt, was wiederum Reviews vereinfacht und damit die Sicherheit erhöht.

    Oder anders gesagt: man BRAUCHT keine dieser Sprachen, um gute Software zu entwickeln, aber es HILFT. Und genau darum geht es doch bei Werkzeugen, oder?

  3. Re: Es ist keine Frage der Programmiersprache

    Autor: Enyaw 11.06.19 - 13:14

    ++ gut zusammengefasst

  4. Re: Es ist keine Frage der Programmiersprache

    Autor: Das Osterschnabeltier 11.06.19 - 13:14

    MrTridac schrieb:
    --------------------------------------------------------------------------------
    > Immer wieder lese ich diese Behauptung.
    > Aber das ist quatsch. Ich kann auch mit der besten und sichersten Sprache
    > scheiß Programme schreiben, die einen Fehler nach dem Anderen machen.
    >
    > Es ist immer einer Frage des Könnens.
    > Ein guter Programmierer schreibt in jeder Sprache gute Programme, ein
    > schlechter schreibt immer schlechte Programme egal in welcher Sprache.
    >
    > Sich auf die Fähigkeiten eines Compilers zu verlassen, Fehler zu finden
    > bzw. zu behandeln, ist fahrlässig.
    > Schon viel zu oft hab ich den Kommentar gehört: "Ich dachte da kümmert sich
    > der Compiler drum", wenn ich einen tief verborgenen Fehler aufgestöbert
    > habe.

    Und das alles stimmt vermutlich, geht aber leider am Thema vorbei.
    Ein schlechtes Programm ist nicht zwingend ein unsicheres Programm. Post/Preconditions, asserts, type checking, range checking, typenvalidierung etc. kann man alles auch zu Fuß Prüfen, nur leider wird ab einem Gewissen Grad an Zeremonie der Code einfach nicht mehr Lesbar. Der bloat versteckt dann die eigentliche Semantik.

    Man muss kein schlechter Programmierer sein um ein Detail zu übersehen. Denke den folgenden Fehler hat in der ein oder anderen Form schon jeder gemacht:
    this.coordX = x
    this.coordX = y
    this.coordZ = Z

    Natürlich gibt es auch Leute, die "keine Bugs" schreiben. Die muss ich im real life erst zwar finden, aber laut dem Internet gibt es sie ja überall.
    "Ich dachte da kümmert sich der Compiler drum" <- Aber ja , das ist ein Zeichen von inkompetenz :P
    Je nach Sprache hätte aber das Konstrukt um das es ging vielleicht nicht einmal kompiliert (Stichwort Rust).

    Fehler sind einfach menschlich. Aber je einfacher eine Programmiersprache es macht einen lesbaren Code mit schlanker Semantik zu haben desto unwahrscheinlicher werden auch Fehler übersehen.

  5. Re: Es ist keine Frage der Programmiersprache

    Autor: Quantium40 11.06.19 - 13:20

    \pub\bash0r schrieb:
    > Oder anders gesagt: man BRAUCHT keine dieser Sprachen, um gute Software zu
    > entwickeln, aber es HILFT. Und genau darum geht es doch bei Werkzeugen,
    > oder?

    Wenn man die genutzte Programmiersprache ständig wechselt, um der zweifelhaften Sicherheit hinterherzulaufen, die die neuen Sprachen bieten sollen, verfehlt man das eigentliche Ziel.
    Wenn man ein Problem beim Einschlagen von Nägeln hat, wechselt man doch auch nicht ständig den Hammer, nur weil der neue Hammer noch besseren Schutz für den Daumen bietet. Stattdessen lernt man besser, mit dem verdammten Hammer umzugehen.

  6. Re: Es ist keine Frage der Programmiersprache

    Autor: Xander 11.06.19 - 13:24

    Da ist schon was dran, aber auch der beste Programmierer macht Fehler oder muss schnell etwas programmieren und übersieht dabei etwas.

    Deswegen ist die Hilfe durch den Compiler oder einer guten IDE schon praktisch, ob eine "sichere" Sprache wie ADA jetzt so viel dazu beiträgt ist eine Frage, aber ich denke schon mal für jedes Einsatzgebiet ist ADA auch nicht geeignet ohne Mehraufwand.

  7. Re: Es ist keine Frage der Programmiersprache

    Autor: Quantium40 11.06.19 - 13:24

    Das Osterschnabeltier schrieb:
    > Denke den folgenden Fehler hat in der ein oder anderen Form schon jeder
    > gemacht:
    > this.coordX = x
    > this.coordX = y
    > this.coordZ = Z
    Wobei gerade diese Sorte Fehler in jeder noch so sicheren Sprache immer durchgeht.
    Sowas würde höchstens dem Optimzer des Compilers auffallen, weil er die erste Zuweisung zu this.coordX einsparen kann.

  8. Re: Es ist keine Frage der Programmiersprache

    Autor: bark 11.06.19 - 13:26

    Ohne know how kommst du trotzdem nicht weiter. Und das Ergebnis ist eher, dass sich ein grosser Teil der Entwickler auf die Hilfen verlässt und weiter schlechten code schreibt. Weil er sich denkt ahh das wird schon korrigiert.


    \pub\bash0r schrieb:
    --------------------------------------------------------------------------------
    > Einige Sprachen machen es dir sehr leicht, beschissenen Code zu schreiben
    > (C), andere machen es dir deutlich schwerer (Rust).
    > Wenn das Ziel von einem Entwickler ist, gute, sichere Software zu
    > schreiben, ist es - unabhängig von seinem Können - in seinem Interesse,
    > eine Sprache zu haben, die ihn dabei unterstützt.
    > Man greift ja auch so gut wie nicht mehr zu Assembler, obwohl man damit
    > natürlich ebenfalls jedes Problem lösen kann. Aber Abstraktion spart Zeit
    > und damit Geld und macht es einfacher, überhaupt noch zu verstehen, was da
    > an Code vor einem liegt, was wiederum Reviews vereinfacht und damit die
    > Sicherheit erhöht.
    >
    > Oder anders gesagt: man BRAUCHT keine dieser Sprachen, um gute Software zu
    > entwickeln, aber es HILFT. Und genau darum geht es doch bei Werkzeugen,
    > oder?

  9. Re: Es ist keine Frage der Programmiersprache

    Autor: \pub\bash0r 11.06.19 - 13:27

    Quantium40 schrieb:
    --------------------------------------------------------------------------------
    > \pub\bash0r schrieb:
    > > Oder anders gesagt: man BRAUCHT keine dieser Sprachen, um gute Software
    > zu
    > > entwickeln, aber es HILFT. Und genau darum geht es doch bei Werkzeugen,
    > > oder?
    >
    > Wenn man die genutzte Programmiersprache ständig wechselt, um der
    > zweifelhaften Sicherheit hinterherzulaufen, die die neuen Sprachen bieten
    > sollen, verfehlt man das eigentliche Ziel.
    > Wenn man ein Problem beim Einschlagen von Nägeln hat, wechselt man doch
    > auch nicht ständig den Hammer, nur weil der neue Hammer noch besseren
    > Schutz für den Daumen bietet. Stattdessen lernt man besser, mit dem
    > verdammten Hammer umzugehen.

    Hat ja auch niemand gesagt. Weder im Artikel noch in den Kommentaren. Auf der anderen Seite wäre es fahrlässig, eben NIE über den Tellerrand zu schauen. Siehe Assembler, COBOL, etc.

    Es kann auch durchaus hilfreich sein, neben der Hauptentwicklung kleinere Sachen in unterschiedlichen Sprachen zu implementieren, um ein Gefühl dafür zu bekommen. Selbst wenn man die Sprachen nicht in der Hauptentwicklung einsetzt, können Lektionen daraus trotzdem nützlich sein und in die andere Sprache übertragen werden. (Geht mir z.B. mit Go und Java so. Seit ich Go entwickle wird auch mein Java Code "einfacher".)

    Ebenso kann es sinnvoll sein, verschiedene Probleme mit verschiedenen Werkzeugen zu bearbeiten. Du musst eine SOAP Schnittstelle bedienen? Nimm Java oder .NET. Du musst hochperformante Berechnungen durchführen? C++ oder Fortran könnten eine gute Idee sein. Leichtgewichtige Backend-Entwicklung? Go. Hochverteilte System? Elixir. Und und und.
    MUSS man nicht machen. Aber zumindest zu wissen, dass es außer dem Hammer auch noch Schraubendreher, Zange, etc. gibt könnte einige Probleme vereinfachen ... nicht, dass man nicht auch mit einem Hammer eine Schraube in die Wand bekommen würde, aber ...

  10. Re: Es ist keine Frage der Programmiersprache

    Autor: MrTridac 11.06.19 - 13:31

    \pub\bash0r schrieb:
    --------------------------------------------------------------------------------
    > Man greift ja auch so gut wie nicht mehr zu Assembler, obwohl man damit
    > natürlich ebenfalls jedes Problem lösen kann.
    Assembler ist ein schlechtes Beispiel, weil der Grund kein bzw. wenig Asm zu programmieren ist nicht weil Asm unsicher ist, sondern umständlicher und unübersichtlicher, bzw. sehr schlecht portierbar.

    > Oder anders gesagt: man BRAUCHT keine dieser Sprachen, um gute Software zu
    > entwickeln, aber es HILFT.
    Problem ist, dass sich zu sehr auf diese "Hilfe" verlassen wird. Stichwort: Trügerische Sicherheit.
    Was letztenendes dazu führt, dass Tests vernachlässigt werden.

  11. Re: Es ist keine Frage der Programmiersprache

    Autor: \pub\bash0r 11.06.19 - 13:34

    bark schrieb:
    --------------------------------------------------------------------------------
    > Ohne know how kommst du trotzdem nicht weiter. Und das Ergebnis ist eher,
    > dass sich ein grosser Teil der Entwickler auf die Hilfen verlässt und
    > weiter schlechten code schreibt. Weil er sich denkt ahh das wird schon
    > korrigiert.

    Was hat das jetzt damit zu tun? Ist deine Konsequenz, dass die Sprache dir GAR NICHTS abnehmen darf (ergo Assembler) damit ja die Nulpen direkt aussortiert werden? Sich dann wochenlang an einfachsten Problemen aufhalten können dann die zurecht hoch bezahlten Profis die noch wissen wie die Maschine tickt.
    Mit so einer Einstellung wären wir noch in der IT Steinzeit.
    Gute und schlechte Entwickler gibt es so oder so. Egal wie viel oder wenig Hilfe sie vom Tooling bekommen. Dass ich Feuer auch mit trockenem Holz und Reibung erzeugen kann heißt nicht, dass ich nicht zum Kochen lieber einen Ofen mit Ceranfeld verwende. Oder einen Microwellenofen.

  12. Re: Es ist keine Frage der Programmiersprache

    Autor: carsti77 11.06.19 - 13:34

    Oh Gott. Was fuer ein Quatsch.

    Ich fahre seit vielen Jahrzehnten Auto. Fehlerfrei. Kein Unfall. Warum brauch ICH also einen Sicherheitsgurt, ABS, Anti-Einschlaf-Systeme, Alkoholkontrollen, Elch-Tests und Crash-Tests? Abschaffen!
    Leute die fehleranfaellig fahren, fahren mit dem sichersten Auto fehleranfaellig. Die sollen mal alle Oldtimer fahren!

    Ich bin sooooo gut beim Auto fahren, ich sollte mich eigentlich regelmaessig zusaufen um es fuer die anderen Verkehrsteilnehmer spannender zu machen <Zwinkersmiley>

    Leute wie du merken nicht mal was sie da sagen. Das Problem sind so Leute Meinungsmacher wie Fefe, die noch nichtmal eine Teilschuld bei der Programmiersprache (bzw. den fehlenden Zusicherungen die ein Compiler machen kann) sehen.

    Und dann verbloedet es sich nicht solche Sachen zu sagen: https://blog.fefe.de/?ts=a207d583

    Zitat: Und "die Leute schulen" hilft auch nicht.

    Also den Menschen kann man nur begrenzt verbessern? Aha! Das ist ja mal eine Erkenntnis. Wir Software immer noch von Menschen geschrieben, ja? D.h. wir muessen uns also damit abfinden, dass dann Fehler passieren koennen.
    Warum also nicht ALLES tun, damit die Programmiersprache/IDE/Compiler/Toolchain den Grossteil der Fehler schlicht ausschliessen oder wenigstens Hilfestellung geben, dass ein Problem vorliegen koennte.

    An einer Stelle hat Fefe recht: wenn man die Firmen die fehlerhafte Software schreiben in die Haftung nehmen wuerde fuer entstandene Schaeden, waere von Heute auf Morgen vieles besser. Ich bin davon ueberzeugt, es wuerde zu einem Boom fuer Rust, Ada und Spark fuehren. Keine Versicherung wuerde C/C++ Code versichern wollen. Das ist genau wie bei AKWs. Die will ja auch keiner versichern.

    Aber ja, Fefe ist da ja noch nie konsistent gewesen. Regt sich zu recht auf, dass BILD Rezo doxxt: https://blog.fefe.de/?ts=a213df1b hat aber vor Jahren auch schon selbst Leute gedoxxt. Zum Beispiel einen ehemaligen Telekom-Mitarbeiter der fehlerhaften Code geschrieben hat :)



    1 mal bearbeitet, zuletzt am 11.06.19 13:43 durch carsti77.

  13. Re: Es ist keine Frage der Programmiersprache

    Autor: EWCH 11.06.19 - 13:35

    Quantium40 schrieb:
    --------------------------------------------------------------------------------
    > Das Osterschnabeltier schrieb:
    > > Denke den folgenden Fehler hat in der ein oder anderen Form schon jeder
    > > gemacht:
    > > this.coordX = x
    > > this.coordX = y
    > > this.coordZ = Z
    > Wobei gerade diese Sorte Fehler in jeder noch so sicheren Sprache immer
    > durchgeht.
    > Sowas würde höchstens dem Optimzer des Compilers auffallen, weil er die
    > erste Zuweisung zu this.coordX einsparen kann.

    der gcc meldet 'set but not used' Fehler.

  14. Re: Es ist keine Frage der Programmiersprache

    Autor: \pub\bash0r 11.06.19 - 13:38

    MrTridac schrieb:
    --------------------------------------------------------------------------------
    > Problem ist, dass sich zu sehr auf diese "Hilfe" verlassen wird. Stichwort:
    > Trügerische Sicherheit.
    > Was letztenendes dazu führt, dass Tests vernachlässigt werden.

    Das löst du nicht durch schlechtere Sprachen. Ignorante und kurzsichtige Entwickler wirst du in jeder Sprache finden. Besagtes C nimmt dir bereits sehr wenig ab und verlangt viel vorausschauendes Denken, und doch findet sich haufenweise Code mit absurd dämlichen Leaks oder Overflows. Sowas kann in Eile, durch Unwissen oder vlt. auch beim Refactoring entstanden sein.
    Dass (beispielsweise) viele Java Entwickler einen Scheiß auf Speicheroptimierung geben ist schade, aber kein Problem der Sprache. Würde sich aber z.B. dadurch beheben lassen, indem diese Leute eben auch mal ANDERE Sprachen nutzen. Lass sie doch mal eine Weile mit Rust arbeiten oder mit C und Valgrind eine Weile herumhantieren, danach sehen die die Welt in Java auch anders.

  15. Re: Es ist keine Frage der Programmiersprache

    Autor: MrTridac 11.06.19 - 13:46

    Das Osterschnabeltier schrieb:
    --------------------------------------------------------------------------------
    > MrTridac schrieb:
    > ---------------------------------------------------------------------------
    > > Schon viel zu oft hab ich den Kommentar gehört: "Ich dachte da kümmert
    > sich
    > > der Compiler drum", wenn ich einen tief verborgenen Fehler aufgestöbert
    > > habe.
    >
    > "Ich dachte da kümmert sich der Compiler drum" <- Aber ja , das ist ein
    > Zeichen von inkompetenz :P

    Ganz genau. Das Problem ist, dass das immer Studenten waren, im letzten Semester, oder grad "fertig gemacht".
    Es sind schon die Universitäten die den Programmierern von morgen das Märchen von sicheren Programmiersprachen eintrichtern.

  16. Re: Es ist keine Frage der Programmiersprache

    Autor: carsti77 11.06.19 - 13:50

    Quantium40 schrieb:
    --------------------------------------------------------------------------------
    > Das Osterschnabeltier schrieb:
    > > Denke den folgenden Fehler hat in der ein oder anderen Form schon jeder
    > > gemacht:
    > > this.coordX = x
    > > this.coordX = y
    > > this.coordZ = Z
    > Wobei gerade diese Sorte Fehler in jeder noch so sicheren Sprache immer
    > durchgeht.
    > Sowas würde höchstens dem Optimzer des Compilers auffallen, weil er die
    > erste Zuweisung zu this.coordX einsparen kann.

    Gute IDEs und Compiler koennen das auch Heute schon nicht nur anzeigen sondern auch wenn man will das Kompilieren verhindern. Das funktioniert 1:1 wie Dead-Code detection und ist super nuetzlich. Klar passiert so ein Fehler nicht oft aber die meisten Menschen stolpern auch praktisch nie aber jeder der laeuft ist schon mal gestolpert.

  17. Re: Es ist keine Frage der Programmiersprache

    Autor: tsp 11.06.19 - 13:56

    > Und das alles stimmt vermutlich, geht aber leider am Thema vorbei.
    > Ein schlechtes Programm ist nicht zwingend ein unsicheres Programm.
    > Post/Preconditions, asserts, type checking, range checking,
    > typenvalidierung etc. kann man alles auch zu Fuß Prüfen, nur leider wird ab
    > einem Gewissen Grad an Zeremonie der Code einfach nicht mehr Lesbar. Der
    > bloat versteckt dann die eigentliche Semantik.

    Wobei das - weil das oft untergeht - auch nur bedingt eine Frage der verwendeten Programmiersprache ist. Dort wo man das will kann man ja z.B. auch mit Tools wie Frama-C auf C Code losgehen (Problematisch wird's leider bei Nutzung von z.B. function pointern) und entsprechend verifizieren ... wobei der Aufwand natürlich auch entsprechend steigt, wenn man damit entsprechende Ergebnisse erzielen will

  18. Re: Es ist keine Frage der Programmiersprache

    Autor: MrTridac 11.06.19 - 13:59

    carsti77 schrieb:
    --------------------------------------------------------------------------------
    > Oh Gott. Was fuer ein Quatsch.
    >
    > Ich fahre seit vielen Jahrzehnten Auto. Fehlerfrei. Kein Unfall. Warum
    > brauch ICH also einen Sicherheitsgurt, ABS, Anti-Einschlaf-Systeme,
    > Alkoholkontrollen, Elch-Tests und Crash-Tests? Abschaffen!

    Das ist ziemlich bescheuerter Vergleich.
    Programmieren ist Entwicklungsarbeit. Das ist nichts was man einfach lernt und dann nur ausführt. Beim Software entwickeln kreiert man etwas was es vorher nicht gab. Die Verkehrsregeln hat jemand für Dich kreiert, die führst Du nur aus.

    > Leute die fehleranfaellig fahren, fahren mit dem sichersten Auto
    > fehleranfaellig.

    Das bestätigt meinen Punkt, dass schlechte Programmierer auch mit einer "sicheren" Sprache schlechte Programme schreiben.

  19. Re: Es ist keine Frage der Programmiersprache

    Autor: schap23 11.06.19 - 14:08

    Ja, ja. Wie wir schon vor 30 Jahren gesagt haben: Richtige Programmierer schreiben in jeder Programmiersprache FORTRAN IV-Programme.

  20. Re: Es ist keine Frage der Programmiersprache

    Autor: MrTridac 11.06.19 - 14:13

    \pub\bash0r schrieb:
    --------------------------------------------------------------------------------
    > bark schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Ohne know how kommst du trotzdem nicht weiter. Und das Ergebnis ist
    > eher,
    > > dass sich ein grosser Teil der Entwickler auf die Hilfen verlässt und
    > > weiter schlechten code schreibt. Weil er sich denkt ahh das wird schon
    > > korrigiert.
    >
    > Mit so einer Einstellung wären wir noch in der IT Steinzeit.

    Das ist ein unsinniges "totschlag"-Argument.
    Niemand ist gegen Fortschritt und Weiterentwicklung. Das darf nur nicht dazu führen, dass Ingenieure nachlässig werden. Das ist aber meine Beobachtung.
    Immer öfter höre und lese ich dass man "heutzutage" ja dies und jenes "nicht mehr macht" weil sich ja Compiler und Runtime um alles kümmern.
    Mit dieser Vorstellung purzeln mehr und mehr Studenten aus der Uni.
    Ich will nur eins: Kompetenz.

  1. Thema
  1. 1
  2. 2
  3. 3

Neues Thema Ansicht wechseln


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

Stellenmarkt
  1. BWI GmbH, Bonn
  2. Chemische Fabrik Budenheim KG, Budenheim
  3. ID Logistics über IBS GmbH, Dortmund, Weilbach, Hammersbach
  4. Schwarz Dienstleistung KG, Neckarsulm

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 99€
  2. 99,90€ + Versand (Vergleichspreis 127,32€ + Versand)
  3. (u. a. AMD Upgrade-Bundle mit Sapphire Radeon RX 590 Nitro+ SE + AMD Ryzen 7 2700X + ASUS TUF B450...
  4. (u. a. Sandisk SSD Plus 1 TB für 88€, WD Elements 1,5-TB-HDD für 55€ und Seagate Expansion...


Haben wir etwas übersehen?

E-Mail an news@golem.de


IT-Freelancer: Paradiesische Zustände
IT-Freelancer
Paradiesische Zustände

IT-Freiberufler arbeiten zeitlich nicht mehr als ihre fest angestellten Kollegen, verdienen aber doppelt so viel wie sie. Das unternehmerische Risiko ist in der heutigen Zeit für gute IT-Freelancer gering, die Gefahr der Scheinselbstständigkeit aber hoch.
Von Peter Ilg

  1. IT-Jobs Der Amtsschimmel wiehert jetzt agil
  2. MINT Werden Frauen überfördert?
  3. Recruiting Wenn das eigene Wachstum zur Herausforderung wird

Vision 5 und Epos 2 im Hands on: Tolinos neue E-Book-Reader-Oberklasse ist gelungen
Vision 5 und Epos 2 im Hands on
Tolinos neue E-Book-Reader-Oberklasse ist gelungen

Die Tolino-Allianz bringt zwei neue E-Book-Reader der Oberklasse auf den Markt. Der Vision 5 hat ein 7 Zoll großes Display, beim besonders dünnen Epos 2 ist es ein 8-Zoll-Display. Es gibt typische Oberklasse-Ausstattung - und noch etwas mehr.
Ein Hands on von Ingo Pakalski

  1. Tolino Page 2 Günstiger E-Book-Reader erhält Displaybeleuchtung

IT-Sicherheit: Auch kleine Netze brauchen eine Firewall
IT-Sicherheit
Auch kleine Netze brauchen eine Firewall

Unternehmen mit kleinem Geldbeutel verzichten häufig auf eine Firewall. Das sollten sie aber nicht tun, wenn ihnen die Sicherheit ihres Netzwerks wichtig ist.
Von Götz Güttich

  1. Anzeige Wo Daten wirklich sicher liegen
  2. Erasure Coding Das Ende von Raid kommt durch Mathematik
  3. Endpoint Security IT-Sicherheit ist ein Cocktail mit vielen Zutaten

  1. Radikalisierung: Die meisten Menschen leben nicht in einer Blase
    Radikalisierung
    Die meisten Menschen leben nicht in einer Blase

    Dass fast jeder in gefährlichen Filterblasen oder Echokammern lebt, ist ein Mythos, sagt die Kommunikationswissenschaftlerin Merja Mahrt. Radikalisierung findet nicht nur im Internet statt, doch darauf wird meist geschaut.

  2. Mozilla: Firefox 70 zeigt Übersicht zu Tracking-Schutz
    Mozilla
    Firefox 70 zeigt Übersicht zu Tracking-Schutz

    Der Tracking-Schutz des Firefox blockiert sehr viele Elemente, die in der aktuellen Version 70 des Browsers für die Nutzer ausgewertet werden. Der Passwortmanager Lockwise ist nun Teil des Browsers und die Schloss-Symbole für HTTPS werden verändert.

  3. Softbank: Wework fällt von 47 auf 8 Milliarden US-Dollar
    Softbank
    Wework fällt von 47 auf 8 Milliarden US-Dollar

    In einer neuen Vereinbarung erlangt die japanische Softbank die Kontrolle über das Co-Working-Startup Wework. Es fällt dabei erheblich im Wert und entgeht dem drohenden Bankrott.


  1. 19:37

  2. 16:42

  3. 16:00

  4. 15:01

  5. 14:55

  6. 14:53

  7. 14:30

  8. 13:35