Abo
  1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › Go - schnelle…

mit der [...] Sicherheit [...] von C und C++ verbinden soll

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. mit der [...] Sicherheit [...] von C und C++ verbinden soll

    Autor: Kaliumhexacyanoferrat 11.11.09 - 10:36

    C? Sicherheit? Hab' ich was verpasst?

  2. Re: mit der [...] Sicherheit [...] von C und C++ verbinden soll

    Autor: autore 11.11.09 - 10:39

    Kaliumhexacyanoferrat schrieb:
    --------------------------------------------------------------------------------
    > C? Sicherheit? Hab' ich was verpasst?

    Wahrscheinlich ist die "type safety" der statisch typisierten Sprachen im Gegensatz zu den dynamisch typisierten gemeint.

  3. Re: mit der [...] Sicherheit [...] von C und C++ verbinden soll

    Autor: darkfate 11.11.09 - 10:39

    Anscheinend hast du das wirklich.

    Linux/Unix ist in C geschrieben und bilden den größten Teil der Enterpriseserver.
    So ziemlich alle Bereiche wo Sicherheit sehr kritisch ist da wird auf C/C++ gesetzt.

    Was dir wahrscheinlich einfällt sind unfähige Programmierneulinge.

  4. Re: mit der [...] Sicherheit [...] von C und C++ verbinden soll

    Autor: Ja Wa 11.11.09 - 10:46

    darkfate schrieb:

    > So ziemlich alle Bereiche wo Sicherheit sehr kritisch ist da wird auf C/C++
    > gesetzt.

    Äh... und auf Java.

  5. Re: mit der [...] Sicherheit [...] von C und C++ verbinden soll

    Autor: darkfate 11.11.09 - 10:51

    Mir ist kein Enterprise Kernel bekannt der in Java geschrieben wurde.



    1 mal bearbeitet, zuletzt am 11.11.09 10:51 durch darkfate.

  6. Re: mit der [...] Sicherheit [...] von C und C++ verbinden soll

    Autor: Ja Wa 11.11.09 - 10:56

    darkfate schrieb:
    --------------------------------------------------------------------------------
    > Mir ist kein Enterprise Kernel bekannt der in Java geschrieben wurde.

    Du hast auch nicht "Kernel", sondern "Server" beschrieben und darunter habe ich "Application Server" verstanden. Dass Java irgendwo aufsetzen muss, ist klar. ;) Das ist dann meist C, richtig.

  7. Re: mit der [...] Sicherheit [...] von C und C++ verbinden soll

    Autor: Kaliumhexacyanoferrat 11.11.09 - 11:00

    darkfate schrieb:
    --------------------------------------------------------------------------------
    > Anscheinend hast du das wirklich.
    >
    > So ziemlich alle Bereiche wo Sicherheit sehr kritisch ist da wird auf C/C++ gesetzt.

    Ich habe auf die schnelle keine verlässlichen Studien gefunden ... aber vielleicht machts ja auch die Menge der Zahlen:

    - Verglichen mit C++ benötigt ein Java-Programm für die gleiche Funktionalität ~25% weniger LOC
    - C++ hat etwa drei mal mehr Bugs / Hour
    - C++-Code enthält i.d.R. ~35% mehr Defects als Java-Code
    - Das Debuggen von C++ dauert verglichen mit Java etwa 3x länger

    Java hier nur als Beispiel für eine typsichere Sprache mit VM. Bei solch einem Design fallen bereits im Voraus viele mögliche Fehlerquellen weg (Buffer Overflows etc.).

    Sicherlich, C/C++ ist hinsichtlich systemnaher Programmierung (Kernel, Treiber, ...) das non-plus-ultra, aber auf höherer Ebene (z.B. Service-Oriented-Programming) findet sich genug Java-Code in Sicherheitsrelevanten Bereichen.

  8. Und was ist mit COBOL? (KT)

    Autor: MartinP 11.11.09 - 11:02

    *Augenzwinker*

  9. Re: mit der [...] Sicherheit [...] von C und C++ verbinden soll

    Autor: darkfate 11.11.09 - 11:11

    > - Verglichen mit C++ benötigt ein Java-Programm für die gleiche
    > Funktionalität ~25% weniger LOC

    Dafür kannst du mit C/C++ Sachen machen die mit Java womöglich nie realisiert werden können. Sowas wie direkte USB Ansteuerung ist PITA bei Java.

    > - C++ hat etwa drei mal mehr Bugs / Hour
    Kommt immer auf den Programmierer an. Nur weil manche sich nicht hinsetzen und den Code gut durchplanen und anschließend auf DoS,Overflows, falsche Ereignisse und nummerische Instabilitäten prüfen ist das kein Problem der Sprache sondern des voreiligen Programmierers.

    > - C++-Code enthält i.d.R. ~35% mehr Defects als Java-Code
    Häää?

    > - Das Debuggen von C++ dauert verglichen mit Java etwa 3x länger
    Kann ich ebenfalls nicht bestätigen.

    > Java hier nur als Beispiel für eine typsichere Sprache mit VM. Bei solch
    > einem Design fallen bereits im Voraus viele mögliche Fehlerquellen weg
    > (Buffer Overflows etc.)
    Eben nicht. Auch JAVA hat Buffer Overlows. Nur eben in der VM.

    > aber auf höherer Ebene (z.B.
    > Service-Oriented-Programming) findet sich genug Java-Code in
    > Sicherheitsrelevanten Bereichen.

    Java in sicherheitsrelevanten Bereichen? -> Amen!
    Liegt aber wahrscheinlich an den FHs und UNIs. Da ist Java mittlerweile die erste Programmiersprache.

  10. Re: Und was ist mit COBOL? (KT)

    Autor: darkfate 11.11.09 - 11:12

    Schwarzeneggers Checks wurden noch in Kobol berechnet :)

  11. Javas VM

    Autor: Greindoch 11.11.09 - 11:53

    darkfate schrieb:

    > Auch JAVA hat Buffer Overlows. Nur eben in der VM.

    In welcher Sprache ist die VM programmiert?

  12. Quatsch mit Soße!

    Autor: kirsche40 11.11.09 - 13:34

    > - Verglichen mit C++ benötigt ein Java-Programm für die gleiche
    > Funktionalität ~25% weniger LOC
    So pauschal ist das völliger Quatsch. Da müssen nämlich alle Zeilen Code mitgezählt werden, die im Framework von z.B. Java mitarbeiten. Und die sind definitiv mehr als die in einem gleichen C-Programm. Was Du meinst sind die LOC des Entwicklers, der selber Code schreiben muß. Das läuft dann also auf Zeitersparnis hinaus - nicht aber auf die Fehleranfälligkeit des Systems insgesamt. Mehr LOC bedeuten immer auch mehr mögliche Fehler. Da wird grundsätzlich das KISS-Prinzip verletzt. Siehe Suns Java-Bugtracker! Der quillt auch nach Jahren der Nutzung des Frameworks noch mit Fehlermeldungen über.

    > - C++ hat etwa drei mal mehr Bugs / Hour
    ??? Seltsam. Der Linux-Kernel läuft z.B. extrem stabil. Hab ich was verpaßt? Dagegen kacken bei mir regelmäßig irgendwelche Java-Programme mit einer NPE ab. :)

    > - C++-Code enthält i.d.R. ~35% mehr Defects als Java-Code
    Huh. 99,9% aller Java-Coder erfinden Zahlen zu defects in anderen Sprachen - oder wie soll ich das jetzt mit Deinem Eingangsstatement "Ich habe auf die schnelle keine verlässlichen Studien gefunden" verstehen?

    > - Das Debuggen von C++ dauert verglichen mit Java etwa 3x länger
    ??? Also wer da einen Unterschied merkt, der hat wohl einen systematischen Fehler im Layer 8.

    > Java hier nur als Beispiel für eine typsichere Sprache mit VM. Bei solch
    > einem Design fallen bereits im Voraus viele mögliche Fehlerquellen weg
    > (Buffer Overflows etc.).
    Dafür hat man trotz Abschaffung von Pointern und Einführung von Referenzen immer wieder die schönen NPEs. :)

    > Sicherlich, C/C++ ist hinsichtlich systemnaher Programmierung (Kernel,
    > Treiber, ...) das non-plus-ultra, aber auf höherer Ebene (z.B.
    > Service-Oriented-Programming) findet sich genug Java-Code in
    > Sicherheitsrelevanten Bereichen.
    >
    Sorry, das ist nun wirklich BWLer-Bullshit-Bingo. Bemühe einfach mal Secunia und den Sun-Java-Bugtracker, dann weißt Du, wie es mit der Sicherheit in Java aussieht! Bloß weil Millionen Fliegen Scheiße gut finden möchte ich noch lange kein Java in einer kritischen Umgebung an der Backe haben. AspectJ ist da übrigens mein Favorit in Sachen "aufgebohrter Sicherheit". Java, genauer J2EE, mag für simple Bussiness-Anwendungen Sinn machen. Aber sobald es was größeres wird stößt Java an seine Grenzen - wie jede andere Programmiersprache auch. Den Stein der Weisen hat eben immer noch niemand gefunden.

  13. Re: Quatsch mit Soße!

    Autor: Karamalx 11.11.09 - 15:19

    kirsche40 schrieb:

    > Java, genauer J2EE, mag für simple Bussiness-Anwendungen Sinn
    > machen. Aber sobald es was größeres wird stößt Java an seine Grenzen

    Komisch. Dabei wurde J2EE doch genau dafür entwickelt.

  14. Re: mit der [...] Sicherheit [...] von C und C++ verbinden soll

    Autor: thorben 11.11.09 - 16:08

    darkfate schrieb:
    --------------------------------------------------------------------------------
    >
    > Java in sicherheitsrelevanten Bereichen? -> Amen!
    > Liegt aber wahrscheinlich an den FHs und UNIs. Da ist Java mittlerweile die
    > erste Programmiersprache.


    nein, es gibt noch ein paar professoren, die das ganze bullshit finden und einen erstmal C/C*+ beibringen, damit man dann programmieren kann und weiß was java eigentlich tut.
    leider werden die blos immer weniger ;)

  15. Re: Und was ist mit COBOL? (KT)

    Autor: Eris Discordia 11.11.09 - 16:20

    COBOL is ne Geldruckmaschine. Nach dem Studium ne Firma suchen die Legacysysteme in COBOL betreut. Dann heiszt es: B**ches und Fuffies im Club!

  16. Re: mit der [...] Sicherheit [...] von C und C++ verbinden soll

    Autor: DrAgOnTuX 11.11.09 - 16:49

    sofern man nicht in einer *nix umgebung arbeitet, dann doch lieber c#/f# als java.
    der entwickler hat dabei mehr zeit sich um die lösung des problems zu kümmern. ein gutes framework welches einem viele möglichkeiten bietet, sowie eine sprache welche einem viel arbeit (weniger code -> weniger fehler) abnimmt.

    so zumindest meine beruflichen erfahrungen in den letzten 5 jahren mit java,c#(,f#)

  17. Re: Quatsch mit Soße!

    Autor: darkfate 11.11.09 - 17:06

    Finde ich auch komisch dass sie trotz Bemühungen in dieser Hinsicht so kräftig versagen konnten. Vor allem bei Geschäftskundensoftware würde mich stören dass mein Quellcode jedem der einen Texteditor bedienen kann zugänglich ist. Java hat diesbezüglich ein ganz beschissenes Konzept mit ihren Class/Package mist.

  18. Re: mit der [...] Sicherheit [...] von C und C++ verbinden soll

    Autor: darkfate 11.11.09 - 17:08

    Wieso dann nicht gleich vernünftig Programmieren lernen?
    Bei mir haben sich über die Jahre genügend Bibliotheken für jeden Mist angesammelt so dass ich getrost auf den Systemspezifischen Quatsch verzichten kann.

  19. Re: mit der [...] Sicherheit [...] von C und C++ verbinden soll

    Autor: DrAgOnTuX 11.11.09 - 17:20

    geht mir nicht anderst, keines meiner projekte kommt ohne eine "utility" klasse aus wo ich die nötigsten funktionen ablege welche ich übers ganze projekt verteilt brauche und vom framework selber nicht zur verfügung gestellt wird.
    wenn ich aber mit dingen wie LINQ oder PLINQ und tasks anstatt threads arbeite, geht mir in zeitunkritischen projekten c/c++ am a**** vorbei, weil ich da einfach zu viel zeit vertrödel um endlich mal abstrakt zu sein und mich um das eigentliche problem (businesslogik/ui/mvc) kümmern zu können.

  20. Re: mit der [...] Sicherheit [...] von C und C++ verbinden soll

    Autor: AnApple 11.11.09 - 17:31

    http://www.heise.de/security/meldung/Luecke-im-Linux-Kernel-erlaubt-Root-Zugriff-Update-849799.html

    Muss ich noch was zur Sicherheit sagen? ;-)

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


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

Stellenmarkt
  1. Bayerische Versorgungskammer, München
  2. Dataport, Magdeburg, Halle (Saale)
  3. BHS Corrugated Maschinen- und Anlagenbau GmbH, Weiherhammer
  4. MEPA- Pauli und Menden GmbH, Bonn

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. mit Gutschein: NBBX570
  2. (Samsung 970 EVO PLus 1 TB für 204,90€ oder Samsung 860 EVO 1 TB für 135,90€)


Haben wir etwas übersehen?

E-Mail an news@golem.de


iPad 7 im Test: Nicht nur für Einsteiger lohnenswert
iPad 7 im Test
Nicht nur für Einsteiger lohnenswert

Auch mit der siebten Version des klassischen iPads richtet sich Apple wieder an Nutzer im Einsteigersegment. Dennoch ist das Tablet sehr leistungsfähig und kommt mit Smart-Keyboard-Unterstützung. Wer ein gutes, lange unterstütztes Tablet sucht, kann sich freuen - ärgerlich sind die Preise fürs Zubehör.
Ein Test von Tobias Költzsch

  1. iPad Einschränkungen für Apples Sidecar-Funktion
  2. Apple Microsoft Office auf neuem iPad nicht mehr kostenlos nutzbar
  3. Tablet Apple bringt die 7. Generation des iPads

Alexa: Das allgegenwärtige Ohr Amazons
Alexa
Das allgegenwärtige Ohr Amazons

Die kürzlich angekündigten Echo-Produkte bringen Amazons Sprachassistentin Alexa auf die Straße und damit Datenschutzprobleme in die U-Bahn oder in bisher Alexa-freie Wohnzimmer. Mehrere Landesdatenschutzbeauftragte haben Golem.de erklärt, ob und wie die Geräte eingesetzt werden dürfen.
Von Moritz Tremmel

  1. Digitaler Assistent Amazon bringt neue Funktionen für Alexa
  2. Echo Frames und Echo Loop Amazon zeigt eine Brille und einen Ring mit Alexa
  3. Alexa Answers Nutzer smarter Lautsprecher sollen Alexa Wissen beibringen

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. IW: Zerschlagung von Amazon und Marketplace gefordert
    IW
    Zerschlagung von Amazon und Marketplace gefordert

    Amazon soll nicht länger als Betreiber eines Marktplatzes und als Anbieter fungieren. Laut einer Studie nutzt der Konzern fremde Kundendaten womöglich wettbewerbswidrig für eigene Zwecke.

  2. Videostreaming: Netflix klassifiziert Zuschauer nach drei Gruppen
    Videostreaming
    Netflix klassifiziert Zuschauer nach drei Gruppen

    Einschaltquoten oder etwas Vergleichbares gibt es bei keinem in Deutschland aktiven Streaminganbieter. Immerhin hat Netflix mitgeteilt, dass Zuschauer nach drei Kategorien sortiert würden - und zumindest Produzenten entsprechendes Zahlenmaterial erhielten.

  3. BDI: Industrie für schnelle 5G-Errichtung statt Vertrauensschwüre
    BDI
    Industrie für schnelle 5G-Errichtung statt Vertrauensschwüre

    Die deutsche Industrie will keine Vertrauenswürdigkeitserklärung von den 5G-Ausrüstern einholen müssen. Diese Erklärungen seien wirkungslos, gefragt sei dagegen Cyber-Resilienz.


  1. 09:02

  2. 07:56

  3. 18:53

  4. 17:38

  5. 17:23

  6. 16:54

  7. 16:39

  8. 15:47