FreeBSD in-depth Verständnis

Einen schnellen Einstieg was die Shell angeht findest Du auch hier: https://wiki.bsdforen.de/howto:shell-scripting
Bietet es sich von der Reihenfolge her an, erst mit Shellscripting anzufangen, dann mit Python und dann mit C und C++ weiter zu machen?


Nimm's mir nicht übel, aber so wird's vermutlich gar nix bzw. jede Menge Halbwissen.

Erst mal: Wozu?

Das ist auch deshalb wichtig, weil Bücher lesen ein (1) Teil von mehreren ist und auch ein durchaus wichtiger, aber beleibe nicht der Einzige und vermutlich nicht mal der Wichtigste.
(Vermutlich - je nach Sichtweise) der wichtigste Teil ist die Praxis, also Übung, Übung, Übung.

Aber die Frage "Wozu?" ist auch wichtig, weil davon viel für die Beantwortung deines Anliegens abhängt. Wenn du z.B. Richtung System Admin gehen willst, dann wird shell scripting und vielleicht noch Python wichtig sein, aber nicht C oder java. Dafür wird aber das solide Verstehen von OS und Netzwerken wichtig sein. Wenn du Richtung Programmierung gehen willst, dann ist zumindest ein gutes Grundverständnis von C wichtig, aber shell scripting weniger. Und überhaupt sind Sprachen eh so ein Kapitel für sich.
Nur mal als Beispiel: C wurde im Grunde als eine Art meta-Assembler erdacht und entwickelt (und ursprünglich genutzt). Zu einer Zeit und in einer Welt, in der hervorragend ausgebildete Fachleute vergleichsweise primitive Computer programmiert haben und Betriebssysteme praktisch durchgehend in Assembler programmiert wurden. *Das* ist der Kontext von C. Der Umstand, dass C *miss*braucht wurde als "Hochsprache" ist für zigtausende bugs und Sicherheitsprobleme verantwortlich.
Versteh mich nicht falsch, das ist kein C bashing! C ist immer noch ein hervorragender meta Assembler und wird nicht grundlos auch heute noch für die Programmierung von Betriebssystemen und "Schwergewichten" (server, Datenbanken ,etc) verwendet. Aber es ist ein entscheidender Unterschied, ob da ein 20-Jähriger Fummler "hackt" oder ein gut ausgebildeter Profi mit 20 Jahren Erfahrung.

Vor allem: All das wonach du fragst sind letztlich Werkzeuge. Betriebssysteme, Sprachen, usw - alles Werkzeuge. Und wie bei jedem Werkzeug ist die entscheidene Frage, was man damit machen will, wozu man es braucht.

Wenn du das für dich besser definieren und eingrenzen kannst, dann können wir dir auch bessere Antworten geben. Eins jedenfalls ist klar: Auch nur ein brauchbarer Macher in irgendeinem dieser Bereiche wirst du nicht ohne jede Menge Übung. Auch FreeBSD z.B. kann man nur bis zu einem bestimmten Punkt aus Büchern verstehen.
 
C ist noch viel mehr. Wenn man es richtig gebraucht, dann ist das Ergebnis portabel bis zum gehtnichtmehr. Das kriegst Du nie hin mit Sprachen, die angeblich portabel sind wie oder sowas Java. C gibt es überall. Java und sonstiges eben nicht.

Sicherheitsprobleme kommen durch Leute und Faulheit/Unerfahrenheit nicht durch die Sprache ("guns don't kill people... people kill people"). Man kann C nach einer gewissen Zeit sehr gut und sicher gebrauchen. Dazu braucht man aber viel Erfahrung und Disziplin. Eine High-Level-Sprache schützt nicht vor Sicherheitsproblemen. Schminkt Euch diese Illusion ab!
 
C ist noch viel mehr. Wenn man es richtig gebraucht, dann ist das Ergebnis portabel bis zum gehtnichtmehr. Das kriegst Du nie hin mit Sprachen, die angeblich portabel sind wie oder sowas Java. C gibt es überall. Java und sonstiges eben nicht.

Sicherheitsprobleme kommen durch Leute und Faulheit/Unerfahrenheit nicht durch die Sprache ("guns don't kill people... people kill people"). Man kann C nach einer gewissen Zeit sehr gut und sicher gebrauchen. Dazu braucht man aber viel Erfahrung und Disziplin. Eine High-Level-Sprache schützt nicht vor Sicherheitsproblemen. Schminkt Euch diese Illusion ab!

Da irrst du, zumindest teilweise. Einfach deshalb, weil eine entsprechend konzipierte Sprache so manche Fehler gar nicht erst entstehen lässt.

Aber, wie gesagt, mein Beitrag war kein C-bashing. Ich habe selbst 20+ Jahre damit gearbeitet und verwende es nach wie vor als meta-Assembler.

Zum anderen: Das (was du sagst) ist ja alles schön und gut - theoretisch. Aber praktisch ist es halt nicht so, dass nur Profis C verwenden. Übrigens, das nur am Rande: Man kann C Code auch sehr schwer prüfen, weil die Sprache so einige nicht eindeutige Stellen hat, die z.B. Compilerbauer jeweils unterschiedlich auslegen.
 
Es gibt Sprachen, wie zum Beispiel Haskell, die Typensicherheit inne haben. Wenn Du Dich etwas anstrengst, dann kannst Du typensicher auch in C programmieren. Da fallen schon ca. 50% der dummen Fehler raus. Wenn Du zudem strikt programmierst (Nutzung von const, static und sonstigen guten/wohlbekannten Konzepten) fallen weitere 40% der Fehler raus.

Wenn Du C anschaust, dann kriegt man damit Arbeit erledigt. Schnell und zuverlässig. Wenn man eine Sprache nimmt, die High-Level ist, dann schlägst Du Dich mit einzelnen Problemen herum, die wegen der Sprache selbst existieren (ich hasse Garbage-Collections; ich hasse, keine Pointer zu haben; ich hasse dass mein Programm nicht klein ist, sondern einen Riesenrattenschwanz von Libs miteinkompilieren muss; ich hasse es, so etwas wie *printf sehr umständlich zu haben; ich hasse es Latenzen bei der Ausführung zu haben). Eine Programmierumgebung hat minimal zu sein und gleichzeitig universell. Das schafft nicht einmal C++ (und zwar unter beiden Gesichtspunkten nicht!).

Ich bin offen für Programmiersprachen. Ich sehe, dass einige (Haskell zum Beispiel) Potenzial haben. Aber solange sie nicht erwachsen sind wie C, kann man erstmal alles als Spielerei ansehen.

C hat eine feste Spezifikation, die viel undefiniertes Verhalten aufweist. Schau Dir diese Fälle genau an. Jeder einzelne ist architekturtechnisch sinnvoll entschieden. Undefiniertes Verhalten wurde sorgfältig für diese Fälle definiert, sozusagen. So weit muss man erstmal sein, bei anderen Sprachen, um so Spezifikationen zu formulieren.

Teilweise gebe ich Dir Recht, dass man C als Meta-Assembler ansieht. Der Punkt ist die Sprache ist low-level "genug" und high-level "genug", um in allen Fällen brauchbar zu sein. Das ist ein unschlagbares Argument für C. So einen Effekt hast Du nirgendwo.
 
High-Level Sprachen führen zu High-Level-Fehlern, Low-Level Sprachen zu Low-Level Fehlern.
Und es ist keiner per se schlimmer als der andere, da wo ein Low-Level Fehler Speicher rausrückt, der privat sein sollte,
da führt ein High-Level Fehler dazu, dass unberechtigte Nutzer alle Daten sehen können…
 
Schlimmer ist, dass High-Level-Sprachen es nicht anbieten, auf Low-Level-Niveau Anpassungen zu machen, weil man es eben als Entwickler besser weiß, wie es dort laufen sollte (für einige Fälle)!

Beispiele für Fails:
  • Bei Java hast Du wegen Exceptions und Nebeneffekten finally (voll der Scheiß, aber muss so sein wegen Fehlens von Destruktoren... ja Kacke, nix hier automatische Garbage-Collection!).
  • Oder seit neuestem: Versuch mal bei Java HTTPS (selbstsignierte Zertifikate mit eigener inoffizieller CA zu betreiben). Da kriegst Du Spaß. Du musst nämlich nicht nur die eine Verbindung auf eigene CA-Liste umbiegen, sondern gleich alle in der laufenden JVM. Und Oracle findet das so toll, dass sie das System unsicher gemacht haben, obwohl eigene CAs zu betreiben, das Bombensicherste schlechthin ist!
  • Bei Haskell musst Du Strategien entwickeln (wegen fehlenden Nebeneffekten) wie man eine Baumstruktur verwaltet, insbesondere wenn innere Knoten oft beschrieben werden. Was trivial bei C ist, wird zum Alptraum auf High-Level.
Und was dann? Bei High-Level-Sprachen beschäftigst Du Dich mit Kinderkacke, anstatt Programmieren. Und warum? Weil sie für einen das Denken übernommen haben und meinen, dass das alles so gut ist.

Das Beste ist, die Welt offen zu lassen: Internet ohne Blockaden, Bücher ohne DRM, CPUs die man übertakten/schmelzen lassen kann, Autos ohne Drosselung und Zwangsgurte,... usw... und letztendlich: Programmiersprachen die Virenprogrammierung zulassen und sich selbst in den Fuß zu schießen.
 
Es ging mir nicht um high-level vs. low-level oder dass das eine besser ist als das andere.

Nur, bitte, verschont mich mit Theorien. Die Realität da draussen zeigt uns ziemlich brutal (heartbleed, shell-shock ...) wie es wirklich aussieht.

Ich habe C nicht nur 20+ Jahre benutzt - und gerne benutzt! - sondern es auch unterrichtet. Und ich will es sicher nicht schlecht machen.

Nur: Menschen sind nun mal Menschen. Deswegen ist die Lösung nicht die zu sagen "Man *kann* in C auch sicher und korrekt programmieren" sondern die, dass eine Sprache möglichst viele Fehler gar nicht erst zulassen sollte.
Denn all die zigtausend bugs und Sicherheitslücken sind nicht entstanden, weil man mit C ordentlich programmieren *kann* sondern weil es erschreckend oft *nicht getan wird*, weil man auch und zwar schockierend leicht und bequem akut giftiges Zeug hacken kann (ohne das zu wollen).

Was Java angeht, sage ich besser nix, sonst kriege ich hier Hausverbot *g

Übrigens fällt mir immer wieder auf, dass C und C++ Leute sehr häufig und ziemlich automatisch ablehnend auf Kritik oder Alternativen reagieren.

Mein Ansatz ist ein recht simpler, der nämlich, den status quo zu hinterfragen und dann weiter zu fragen, wie es denn besser gehen könnte. Und dabei stelle ich immer wieder fest, dass andere und oft bessere Ansätze eben nicht gescheitert sind, weil sie nicht gut waren, sondern weil der status quo von einer mächtigen lobby aus Industrie-Interessen und Alt Eingesessenen verteidigt und zementiert wurde - inkl. einer Menge heiliger Dogmas wie dem, dass nur C wirklich schnellen Code erzeugt.
Übrigens wurde und wird ganz ähnlich nun java gepusht.

Was "sich mit Kinderkacke beschäftigen" angeht, also mit housekeeping, sollte C einfach dezent schweigen. Wir (ja, "wir", ich gehörte ja dazu) haben es doch Jahrzehnte lang verpennt, eigentlich simple Konstrukte für C zu schaffen, die andernorts gängig (und Fehler-reduzierend!) sind.

Aber egal. Mich interessiert zu dem Thema schon lange kein "meine Sprache ist besser als deine!" mehr oder Flame-wars. Mich interessiert, wie wir wirklich(!) effizient zuverlässigeren Code mit weniger Fehlern hinkriegen. Und der Weg für diese Suche war lang und wenig erfreulich. Denn Ada, um ein Beispiel zu nennen, ist ja wohl keine attraktive Lösung für jeden Tag (und selbst für Flugzeuge bezweifle ich das)
 
Schlimmer ist, dass High-Level-Sprachen es nicht anbieten, auf Low-Level-Niveau Anpassungen zu machen, weil man es eben als Entwickler besser weiß, wie es dort laufen sollte (für einige Fälle)!
Dafür gibt es FFis, SharedLibs etc.

Was trivial bei C ist, wird zum Alptraum auf High-Level.
Und was in (einigen) HL-Sprachen trivial ist, ist in C ein Albtraum.
Bei High-Level-Sprachen beschäftigst Du Dich mit Kinderkacke, anstatt Programmieren. Und warum? Weil sie für einen das Denken übernommen haben und meinen, dass das alles so gut ist.
Das ist doch Unsinn. Der Vorzug von C ist das minimale Laufzeitsystem und ist von daher für die Unix Philosophie (one tool, one job) bestens geeignet. Bei umfangreicheren Projekten implementiert man dann per Hand das in C das was die HL-Sprachen schon eingebaut haben, - oder sucht geeignete Libs die man dann findet, oder auch nicht. Klar, werd die Welt neu erfinden will braucht C/C++.

Der Vergleich LL/HL hinkt immer. Wenn, dann muss man konkrete Sprachen für ein bestimmtes Projekt vergleichen: ASM vs. C, C vs. Java, Java vs. Erlang, Erlang vs. Haskel etc pp.

Das entscheidende menschliche Problem scheint mir zu sein dass man nicht in mehr als 2-3 Sprachen wirklich gut sein kann und dann sind halt alle doof die nicht meine Sprache sprechen. Aber OK, C muss man in jedem fall können aber Mehrsprachigkeit ist auch hier von Vorteil.
 
Ja natürlich wählt man eine Sprache passend zum Projekt. Keine einzige Sprache unterstützt Shared-Libs so gut wie C. Fast alles sind immer C-Bindings. Bei Java kann man ClassLoader was nachladen. Versuch dann aber auch zu entladen und anderes an die gleiche Stelle zu laden (Plugin-Prinzip). Da bekommst Du Spaß. C++ weicht auf C aus beim dynamischen Linker. Was macht man da? Richtig... nichts, man wählt das Richtige, nämlich C.

Bei C ist es nur ein Alptraum, wenn es keine Bibliothek dafür gibt. Sag mir doch mal was Dir fehlt. Du brauchst nur auf blankes C herunter zu steigen, wenn Du wirklich nichts findest. Du kannst doch nicht bei High-Level sagen, dass es Libs gibt und verschweigen, dass es für das viel weiter verbreitete C das größte Angebot überhaupt gibt. Man braucht hier nicht die Welt neu zu erfinden. Aber die Sprache macht es möglich und einfach, dies zu tun. Nochmals möchte ich den Punkt der "Universalität von C" betonen.

Zum Thema Sicherheit:

Sicherheit hängt nicht von der Sprache ab. Du kannst doch nicht anhand von Shellshock etc die Qualität von C messen. So gesehen sind Autos gefährlicher als Wingsuits. Möchte jemand von Euch zur Arbeit aus dem Flugzeug lieber mit nem Wingsuit fliegen? Da bringen sich ja viel weniger Leute mit um.

Nein... das wichtigste und ausschlaggebenste bei der Sicherheit ist der Exponiertheitsgrad der Systeme. Die Systeme an die man dran kann sind die, auf die man am meisten aufpassen soll. Jemand, der die Flugzeugsteuerung in Ada programmiert, muss auch zusichern, dass keiner überhaupt an das System kommt (ob physikalisch oder per Netz). Problem ist, dass Server massig angegriffen werden, mit verschiedenen Taktiken. Ich habe von vornerein beschlossen nicht bash-Skripte zu machen, sondern Bourne-Shell (normale sh) und ich bin hier nicht exponiert an dieser Stelle.

Das zweitwichtigste ist der Nutzen, den ein Angreifer haben könnte, wenn er in ein System einbricht. Und das Dritte ist die Masse von Systemen, die man leicht übernehmen kann, weil sie zum Beispiel alle gleich verwundbar sind. Wir sind hier überhaupt nicht bei Programmiersprachen. Sie sind nicht der Kern des Problems.

Zu meiner Einstellung:

Es ist nicht in meinem Interesse, den Evangelisten von C zu machen. Das versteht ihr wohl falsch. Ich habe diese Schlüsse aus Beobachtungen gemacht und meiner Erfahrung. Ich lerne sehr viel und alles wird von mir sorgfältig beäugt und eigentlich auch wohlwollend angeschaut. Ich sehe viel Gutes, aber ich werde auch nicht die schlechten Seiten verschweigen.

Das mir persönlich wichtigste ist die Universalität. Es ist wichtig, dass eine Sprache alle Möglichkeiten hat. Ob es Leute gibt, die Mist bauen, ist mir persönlich nicht so wichtig. Mir ist wichtig, dass ich nicht an allen Ecken durch Sprachkonzepte behindert werde. Meine Beobachtung ist, dass je abstrakter (mehr high-level) die Konzepte sind, desto mehr Hürden hat man vor sich, um das Elementare zu verstehen und gut lösen zu können. Bei der Wahl der Sprache muss man aufpassen, dass man sich nach Jahren noch den Weg nicht verbaut. Und das ist sehr schwierig zu sagen, insbesondere wenn die Anforderungen sehr schwammig sind.
 
Auch wenn es inzwischen sehr Offtopic ist, machen wir mal munter weiter: Ich sehe auch ein großes Problem darin, dass zwar munter jedes Jahr unzählige neue Sprachen entwickelt und einige von ihnen für kurze Zeit in den Olymp gehypet werden, aber sich niemand mehr für die wirklich wichtigen Einsatzbereiche weit unten im Stack interessiert. So kann man inzwischen aus gefühlt 1005 Java-Derivaten für die JVM wählen. Aber geht es um eine nahezu overheadfreie, direkt zu Maschinencode übersetzende, objektorientierte Sprache, ist dort neben C++ kalte Stille im Wald. Ja, es gibt ein paar Ansätze. D, Rust, nun neu von Apple Swift. Aber diese sind zum Teil seit Ewigkeiten in der Entwicklung und besitzen keinen festen Syntax, die Standard-Bibliotheken sind mies, Bibliotheken von Drittanbietern erst gar nicht vorhanden. Die Unterstützung durch Tools oft auch nur ein schwarzes Loch. Einmal ganz davon abgesehen, dass Low-Level-Entwickelung nicht mal zwingen im Profil liegt... Geht man noch eine Ebene weiter hinab und schaut sich C an, fällt mir nun auf Anhieb nicht eine einzige Sprache ein, die zumindest theoretisch als Ersatz diesen könnte.
Daher ist es immer leicht auf C und C++ zu schimpfen. Und viele Argumente gegen diese Sprachen haben durchaus ihre Berechtigung. Aber auf der anderen Seite sind sie nun einmal - um Mutti zu zitieren - alternativlos.
 
... Sicherheit hängt nicht von der Sprache ab. Du kannst doch nicht anhand von Shellshock etc die Qualität von C messen. So gesehen sind Autos gefährlicher als Wingsuits. Möchte jemand von Euch zur Arbeit aus dem Flugzeug lieber mit nem Wingsuit fliegen? Da bringen sich ja viel weniger Leute mit um.

Nein... das wichtigste und ausschlaggebenste bei der Sicherheit ist der Exponiertheitsgrad der Systeme. Die Systeme an die man dran kann sind die, auf die man am meisten aufpassen soll. Jemand, der die Flugzeugsteuerung in Ada programmiert, muss auch zusichern, dass keiner überhaupt an das System kommt (ob physikalisch oder per Netz). Problem ist, dass Server massig angegriffen werden, mit verschiedenen Taktiken. Ich habe von vornerein beschlossen nicht bash-Skripte zu machen, sondern Bourne-Shell (normale sh) und ich bin hier nicht exponiert an dieser Stelle.

Das zweitwichtigste ist der Nutzen, den ein Angreifer haben könnte, wenn er in ein System einbricht. Und das Dritte ist die Masse von Systemen, die man leicht übernehmen kann, weil sie zum Beispiel alle gleich verwundbar sind. Wir sind hier überhaupt nicht bei Programmiersprachen. Sie sind nicht der Kern des Problems.

...

Das mir persönlich wichtigste ist die Universalität. Es ist wichtig, dass eine Sprache alle Möglichkeiten hat. Ob es Leute gibt, die Mist bauen, ist mir persönlich nicht so wichtig. Mir ist wichtig, dass ich nicht an allen Ecken durch Sprachkonzepte behindert werde. Meine Beobachtung ist, dass je abstrakter (mehr high-level) die Konzepte sind, desto mehr Hürden hat man vor sich, um das Elementare zu verstehen und gut lösen zu können. Bei der Wahl der Sprache muss man aufpassen, dass man sich nach Jahren noch den Weg nicht verbaut. Und das ist sehr schwierig zu sagen, insbesondere wenn die Anforderungen sehr schwammig sind.

Äh ... Nö.

Was du da beschreibst, ist zwar pragmatisch verständlich, aber trotzdem daneben. Der Grad der Exponiertheit eines Systems sagt z.B. nichts über seine Sicherheit aus und ist auch nicht relevant für seine Sicherheit. Ein öffentlich zugängliches System wird lediglich schneller geknackt, *wenn* es nicht sicher ist.

Und ja, ich kann sehr wohl die Sicherheit einer Sprache *auch* an shellshock oder heartbleed festmachen. Gründe: Zum Beispiel Readability. heartbleed z.B. *wurde* "kontrolliert" und zwar von einem Profi. Nur dass so manche Kleinigkeit in C code eben leicht zu übersehen ist.
Wie gesagt, Theorie ist schön, aber eben Theorie. Am Ende zählt doch, was dabei rauskommt in der Praxis.

Ich persönlich finde z.B. den Ansatz attraktiv, C als intermediäre Sprache für Compiler zu verwenden. Einfach deshalb, weil C ja wirklich gewichtige Vorteile hat, den z.B. auf praktisch jeder Plattform verfügbar zu sein und weil Maschinen ganz erheblich besser sind in genauem, pingeligem, korrektem Arbeiten.

Aber wie auch immer ... der TE wollte was wissen und wir haben ihm geantwortet (und noch ein bisschen mehr *g). Und ich denke, das hat auch in seinem Sinne was Gutes, weil er so hautnah mitbekommt, wie komplex die IT Welt und all ihre diversen Ecken sind. Gleich, was es sein mag, wofür er sich entscheidet: Er wird neben Büchern lesen auch eine Menge Zeit und Aufwand in Praxis und Erwerb von Erfahrung stecken müssen.
 
Auch wenn es inzwischen sehr Offtopic ist, machen wir mal munter weiter: Ich sehe auch ein großes Problem darin, dass zwar munter jedes Jahr unzählige neue Sprachen entwickelt und einige von ihnen für kurze Zeit in den Olymp gehypet werden, aber sich niemand mehr für die wirklich wichtigen Einsatzbereiche weit unten im Stack interessiert. So kann man inzwischen aus gefühlt 1005 Java-Derivaten für die JVM wählen. Aber geht es um eine nahezu overheadfreie, direkt zu Maschinencode übersetzende, objektorientierte Sprache, ist dort neben C++ kalte Stille im Wald. Ja, es gibt ein paar Ansätze. D, Rust, nun neu von Apple Swift. Aber diese sind zum Teil seit Ewigkeiten in der Entwicklung und besitzen keinen festen Syntax, die Standard-Bibliotheken sind mies, Bibliotheken von Drittanbietern erst gar nicht vorhanden. Die Unterstützung durch Tools oft auch nur ein schwarzes Loch. Einmal ganz davon abgesehen, dass Low-Level-Entwickelung nicht mal zwingen im Profil liegt... Geht man noch eine Ebene weiter hinab und schaut sich C an, fällt mir nun auf Anhieb nicht eine einzige Sprache ein, die zumindest theoretisch als Ersatz diesen könnte.
Daher ist es immer leicht auf C und C++ zu schimpfen. Und viele Argumente gegen diese Sprachen haben durchaus ihre Berechtigung. Aber auf der anderen Seite sind sie nun einmal - um Mutti zu zitieren - alternativlos.


Nur mal zum Nachdenken:

Praktisch alle "großen" (oder mainstream) Sprachen kommen von jenseits des Atlantik. Ist das wirklich so, weil die so viel schlauer sind als wir? Schauen wir doch mal Europa:

Da finden wir einen der ganz Großen, Prof. Wirth. Jeder weiss, dass der Pascal entwickelt hat. Und das Pascal, äh, nun ja, nicht optimal ist. Aber er hat das wetr entwickelt zu Modula-2 und später zu Oberon. Klar, diese Sprachen haben nur wenig und kurz Aufmerksamkeit genossen, aber das sagt wenig über ihre Qualität und Fähigkeiten aus. Und der Mann hat ganz klar und indiskutabel einen Nagel getroffen mit seinen knappen Spezifikationen. Man vergleiche mal die Standards von Modula-3, C, C++ und Ada im Hinblick auf Länge, Wuchtigkeit, Konsistenz und - extrem wichtig - Eineindeutigkeit!

Aber C++ oder Java sind halt "cool" und alle "echten Profis" arbeiten damit, bla, bla.

Nein, tun sie eben nicht. Profis verwenden die Sprache, deren Vorteile und Stärken ihre Kosten und Macken für eine gegebene Aufgabe deutlich übertreffen und die die nötigen Fähigkeiten hat. Bei einem kernel sind das Faktoren, die C bietet; bei einer FiBu sind das Faktoren, die eher Pascal bietet oder Modula; und bei einer kleinen utility sind das Faktoren, die z.B. python oder ((t)c)sh bieten.
Häufig kommen dazu noch sehr pragmatische Faktoren wie z.B. eine brauchbare IDE, verfügbare Plattformen, Guis, etc.
 
Natürlich sind Systeme, die exponiert sind, die unsichersten. Wer auf Sicherheit wert legt, macht die Sicht auf das System "schmal", indem er die Zahl der Angriffsvektoren reduziert. Das ist viel effektiver als Sprach-Features zu nutzen.

Nein. Heartbleed wurde eben nicht kontrolliert. Da fehlt Geld und Personal und vor allem sind die Systeme, die von Heartbleed betroffen sind öffentlich zugänglich (total bloßgestellt; exponiert!). Das gleiche gilt für bash. Übrigens ist ein Parser überhaupt ein schwieriges Unterfangen, in allen Sprachen. Auch für C gibt es da formale Vorgehensweisen, aber jeder strickt ja seinen eigenen Strick. Und vor allem wegen Aktualität Sachen als Argumente vorzulegen ist nicht angebracht. Da muss man schon etwas breiter und tiefer Bohren.

Was schlägst Du vor? Hast Du gesehen, wieviele Sicherheitsprobleme die JVM und die APIs von Java haben? Es gab Zeiten, da hab ich die JVM nur schief angeguckt und sie hat einen SEGFAULT geschmissen. Heute habe ich erst Haskell beim Beenden eines Unterprozesses zum SEGFAULT gebracht, reproduzierbar. OpenBSD-Hostap habe ich platt gemacht, mit einem Division by Zero per WLAN (also pseudo-remote). Meinen MP3-Player im Auto habe ich gecrasht mit einem Lied, bis heute funktioniert's (muss das Lied immer überspringen). Internet Explorer habe ich nach dem 4ten Versuch gecrasht, einfach durch Eingabe von URLs... auch reproduzierbar und dann auch Remote-Exploit dafür geschrieben, den Microsoft auch jahrelang fein ignoriert hat. Ich kann einfach Schrott irgendwie "riechen", aber ich würde nicht sagen, dass C hier statistisch dominiert. Dafür, dass es am meisten verbreitet ist, hält es sich ziemlich gut.

Nebeninfo: Und ich bin weder ein Sicherheitsexperte, noch gezielt irgendwo auf der Suche nach Sicherheitslücken.
 
Bei der Wahl der Sprache entscheidet eher vor allem die Fähigkeit der angestellten Entwickler. Also konkret, das womit sie programmieren, wird gewählt. Deswegen werden wir uns nun lange mit Java-Kram schlagen, weil das immer noch aktuell an den Unis beigebracht wird. Und dann wird Dir sowieso jeder erzählen, dass das was er kann, das beste ist.

Das ist so wie mit iPhones. Die sind viel besser als alle anderen Handys. Mercedes ist auch das beste Auto und das beste Waschpulver ist sowieso Perwoll.

Solche Unterhaltungen nützen nichts, wenn Dir jemand was empfiehlt was er hat. Was soll er sonst empfehlen? Soll er zugeben, dass er Schrott gewählt hat?

Du musst nicht unbedingt auf mich hören, aber auf Leute, die weit und breit Erfahrung gesammelt haben und zwar nicht in Form eines Spielzeugs, sondern seriösen Projekten, die keine Einzelfälle sind. Das sind alles Details, bei der Analyse von Code-Qualität, die einem die Sicht trüben. Auch das, dass gerade mal wieder Sicherheitslücken in weit verbreiteten Komponenten gefunden worden sind. Da hört man besser temporär auf, Schlüsse zu ziehen, bis die Vernunft wieder einkehrt.
 
Nein. Heartbleed wurde eben nicht kontrolliert.

Bitte nachlesen und informieren. heartbleed wurde von dem deutschen Diplomanden implementiert und von einem openssl maintainer (der an einer englischen uni arbeitet) abgenickt und zumindest seinen Angaben zufolge kontrolliert.

Nebeninfo: Ich bin im Bereich Sicherheit tätig. Daher auch mein Interesse an Lösungsansätzen, *auch* und besonders im Bereich Sprachen.
 
Bitte nachlesen und informieren. heartbleed wurde von dem deutschen Diplomanden implementiert und von einem openssl maintainer (der an einer englischen uni arbeitet) abgenickt und zumindest seinen Angaben zufolge kontrolliert.
Stimmt was aber nichts daran ändert, dass das Projekt hoffnungslos unterfinanziert war/ist! [1] So weit ich weiss, gabs ja nicht mal automatierte Tests dafür.

[1] ... Normalerweise verzeichnet das Projekt nur etwa 2000 USD Spenden pro Jahr....
[1] http://www.pro-linux.de/news/1/2099...tbleed-fehler-patches-audits-und-spenden.html
 
Bei der Wahl der Sprache entscheidet eher vor allem die Fähigkeit der angestellten Entwickler. Also konkret, das womit sie programmieren, wird gewählt. Deswegen werden wir uns nun lange mit Java-Kram schlagen, weil das immer noch aktuell an den Unis beigebracht wird. Und dann wird Dir sowieso jeder erzählen, dass das was er kann, das beste ist.

Das ist so wie mit iPhones. Die sind viel besser als alle anderen Handys. Mercedes ist auch das beste Auto und das beste Waschpulver ist sowieso Perwoll.

Solche Unterhaltungen nützen nichts, wenn Dir jemand was empfiehlt was er hat. Was soll er sonst empfehlen? Soll er zugeben, dass er Schrott gewählt hat?

Du musst nicht unbedingt auf mich hören, aber auf Leute, die weit und breit Erfahrung gesammelt haben und zwar nicht in Form eines Spielzeugs, sondern seriösen Projekten, die keine Einzelfälle sind. Das sind alles Details, bei der Analyse von Code-Qualität, die einem die Sicht trüben. Auch das, dass gerade mal wieder Sicherheitslücken in weit verbreiteten Komponenten gefunden worden sind. Da hört man besser temporär auf, Schlüsse zu ziehen, bis die Vernunft wieder einkehrt.

Da hast du zum Teil durchaus recht, aber eher bei kleineren Firmen und Projekten.

Das Problem mit der Code-Qualität und entsprechenden Analysen ist, dass C eben nicht eineindeutig (und leider auch mittlerweile sehr komplex) spezifiziert ist.
Du sprachst Parser an; ich habe in meinem Bereich damit zu tun und kann aus konkreter Erfahrung sagen, wie parsing (nicht nur) bei C oft in Grauzonen-Rätselraten mündet.
Es ist einfach wichtig zu verstehen, wie C entstand und in welchem Kontext. Zu dem Zeitpunkt damals hieß OS proprammieren quasi notwendig "Assembler". Was nicht mal ein Problem gewesen wäre, aber zu einem wurde, weil zu dieser Zeit auch immer neue Architekturen dazukamen und sich abzeichnete, dass es ineffizinter Irrsinn wäre, die OSs für jede gewünschte Architektur neu zu schreiben (in Assembler). Der interessante Punkt von C war es, 1 mal für eine Architektur einen "Treiber" (ein compiler backend) für einen meta Assembler zu schreiben und dann zumindest weite Teile eines OS bequem portieren zu können.
Das war der Kickpunkt und die Triebfeder und das ist nach wie vor die Stärke von C (wenn man auch heutzutage mehr Wert auf readability legen würde; aber, wie gesagt, im Vergleich zu assemblern war C auch in dieser Hinsicht bereits ein Fortschritt).

Wenn du Code-Qualität willst, dann kommst du bei größeren Projekten nicht um Maschinen-unterstützte Analyse herum. Und da sieht's bei C mau aus.

Aber mal grundsätzlicher:

Ein weiteres Problem ist Inkonsistenz. Nimm als Beispiel mal unit-tests. Die sind praktisch immer in der selben Sprache wie der Code geschrieben, was, nun ja, etwas blauäugig ist. Vermutlich noch schlimmer aber ist die Spezifikationsseite. Denn es geht ja nicht nur darum, die Code Qualität zu prüfen, sondern auch darum zu prüfen, ob der Code leistet, was er leisten soll und nicht tut, was er nicht soll. Die nötigen Spezifikationen liegen heute praktisch immer irgendwo im Bereich "Hat jemand innem Editor (oder spreadsheet * grusel) aufgeschrieben" und "ham wir uns mal so ausgedacht" (die Entwickler). Nur: Wie willst du sowas Maschinen-unterstützt testen?
Da gibt es noch weitere Probleme, das z.B., das beim unit test so manches emuliert wird, weil der Code halt nicht unter echten Bedingungen läuft.

Dabei gibt es durchaus sehr brauchbare und vielversprechende Ansätze, z.B. DbC (Design by Contract) von Prof. B. Meyer (Wieder ein Europäer ...). Nur leider musste man dazu viele Jahre auch gleich noch eine neue Sprache verwenden (Eiffel) und die kostete Tausende Lizenzgebühren. Nun frag dich mal, was Müller&Meier Software GmbH verwenden ... C/C++ plus kostenlose oder billige IDE (scheiss auf Solidität, Tests, usw.) für lau ... oder eine neue Sprache plus IDE für Tausende @ pro Entwickler ...
Ada 2012 hat Dbc weitgehend aufgegriffen in Ada 2012, aber auch Ada ist teuer und obendrein als bürokratisch und pingelig und ineffizient verschrieen.
C und C++ glänzen da weitgehend durch Ignoranz und zu java sage ich lieber erst gar nichts ausser, dass ich es (wie perl auch) wie die Pest meide.
 
Stimmt was aber nichts daran ändert, dass das Projekt hoffnungslos unterfinanziert war/ist! [1] So weit ich weiss, gabs ja nicht mal automatierte Tests dafür.

[1] ... Normalerweise verzeichnet das Projekt nur etwa 2000 USD Spenden pro Jahr....
[1] http://www.pro-linux.de/news/1/2099...tbleed-fehler-patches-audits-und-spenden.html

Das mag ja so sein, aber das gehört in eine andere Abteilung, nämlich diese -> "Wie ultradämlich weit jenseits von debil muss man sein, um die Kronjuwelen unbeachtet im Stall liegen zu lassen, aber klicki-bunti Zeug wie gnome oder kde oder hobbyzeug wie linux Millionen nachzuschmeissen?".

Und ich bleibe dabei: Die sehr schlechte readability von C hat zu heartbleed beigetragen, weil sie Fehlerkennung, auch algorithmische, erheblich erschwert.
Das ist auch deshalb dumm, weil code nunmal weitaus öfter gelesen als geschrieben wird (siehe maintenance, updates, ...).
 
Mir geht es doch nicht um C- bashing, das Gegenteil ist der Fall. Ich meine dass es die Lingua-Franka der Programmierung ist so dass jeder zumindest die Basics von C/C++ beherrschen sollte.
Bei C ist es nur ein Alptraum, wenn es keine Bibliothek dafür gibt. Sag mir doch mal was Dir fehlt. Du brauchst nur auf blankes C herunter zu steigen, wenn Du wirklich nichts findest. Du kannst doch nicht bei High-Level sagen, dass es Libs gibt und verschweigen, dass es für das viel weiter verbreitete C das größte Angebot überhaupt gibt. Man braucht hier nicht die Welt neu zu erfinden. Aber die Sprache macht es möglich und einfach, dies zu tun. Nochmals möchte ich den Punkt der "Universalität von C" betonen.
Natürlich bekommt man alles immer irgendwie hin, aber das ist doch nicht der Punkt. Die Frage ist doch wie groß ist der Aufwand denn die C-Libs muss man sich zusammensuchen was nicht heißt dass sie auch zusammen passen (Speicherverwaltung, Ausnahmebehandlng, Threadsafety etc pp). Und dann muss man sich die Interna anschauen um beurteilen zu können was Sache ist, was ja meist nicht trivial ist. Vergleiche das mal mit dem Aufwand den man z.B. in Erlang betreiben muss wo nahezu alles gut zusammen paßt. Klar, auch für Erlang mußt du einen Preis bezahlen: Laufzeitnachteile (geringe, meist nicht das wichtigste), steile Lernkurve und für spezielle Sachen mußt du dann doch auf C zurückgreifen. Umsonst bekommst du eben nichts, auch nicht bei C.

Und eines ist mir noch wichtig: Das Programmieren sollte Spass machen und bei allzuzuviel Frickelei hört der schnell auf. Aber ich bin auch kein Profi so dass sich mir solchen Luxus leisten kann. :)
 
Und ich bleibe dabei: Die sehr schlechte readability von C hat zu heartbleed beigetragen
Quatsch. Das OpenBSD Team hat sehr schnell und auch sehr wirksam erkannt was Schrott ist im Code in diesen schleunigst entfernt. Es ging nicht lange und ihnen wurde klar, dass sie mit einem Fork besser bedient sind. Die Frage ist: Warum haben die OpenSSL Entwickler dies nicht erkannt und solche Aufräumaktionen nie gemacht?
 
Quatsch. Das OpenBSD Team hat sehr schnell und auch sehr wirksam erkannt was Schrott ist im Code in diesen schleunigst entfernt. Es ging nicht lange und ihnen wurde klar, dass sie mit einem Fork besser bedient sind. Die Frage ist: Warum haben die OpenSSL Entwickler dies nicht erkannt und solche Aufräumaktionen nie gemacht?

Nimm's mir nicht übel, aber ich sehe bei dir keine Basis für eine konstruktive Diskussion. Kämpfe gern und mit wem du willst, aber halt nicht mit mir.

Angenehmen Abend noch.
 
Auch wenn es inzwischen sehr Offtopic ist, machen wir mal munter weiter: Ich sehe auch ein großes Problem darin, dass zwar munter jedes Jahr unzählige neue Sprachen entwickelt und einige von ihnen für kurze Zeit in den Olymp gehypet werden, aber sich niemand mehr für die wirklich wichtigen Einsatzbereiche weit unten im Stack interessiert.
Warum sollte man sich dafür interessieren wenn man das via FFI/SharedLibs mit C erledigen kann? Diese ökologische Nische ist eben mit C besetzt, - mehr schlecht als recht. D und Rust versuchen das ja besser zu machen, aber m.E. hätte es gereicht einige Schwachpunkte von C auszumerzen anstatt eine neue Sprache zu entwickeln was aber wohl nahezu unmöglich ist.

Diesbezüglich fand ich das C-- Projekt ganz interessant und auch LLVM öffnet da möglicherweise einige Türen...
 
Mit Java lassen sich GUIs ganz schnell machen. Ich habe noch nie Java mit einer IDE programmiert (das kann ich gar nicht), aber GUIs kriege ich locker mit geschlossenen Augen hin mit allen Details und eben Sonderlocken, die keine IDE überhaupt hinkriegt. Go ist ganz nett und interessant. Haskell habe ich schon benannt. Sehr umfangreich und Libs für jeglichen Pipapo. Perl mag ich für regexp-lastige Sachen. sh für sehr einfache Skripte. PHP für schnell erstellte Web-Dienste (wenn man lightweight bleiben will). Alles mögliche kann man wählen aus allen möglichen Gründen. Mit C kann man alles obige machen, wenn die Lösung edleres Produkt werden soll, dafür mit mehr Aufwand, aber deswegen weil ich eben sage, dass die obigen Sachen dafür ja gedacht sind was ich mit denen mache. Also immer locker bleiben, alles ist für irgendwas gut. Auch BASIC... wie der Name sagt: Beginnersprache aber vielmehr nicht.
 
Nimm's mir nicht übel, aber ich sehe bei dir keine Basis für eine konstruktive Diskussion.
Das ist Schade. Ich bin schon etwas länger hier im Forum aktiv unterwegs und darf, so glaube ich sagen, dass ich noch nie jemanden auf die Füsse getreten bin. Ich weiss jetzt nicht wo dein Problem liegt. Solltest du noch etwas zu klären haben bitte PN. Das ist alles OT hier.
Kämpfe gern und mit wem du willst, aber halt nicht mit mir.
Das hat nichts mit kämpfen zu tun! Das ist ein Meinungsaustausch, welcher hier in diesem Forum eigentlich immer sachlich und anständig untereinander geführt wird.
Angenehmen Abend noch.
Danke zurück.
 
Warum sollte man sich dafür interessieren wenn man das via FFI/SharedLibs mit C erledigen kann? Diese ökologische Nische ist eben mit C besetzt, - mehr schlecht als recht. D und Rust versuchen das ja besser zu machen, aber m.E. hätte es gereicht einige Schwachpunkte von C auszumerzen anstatt eine neue Sprache zu entwickeln was aber wohl nahezu unmöglich ist.

Diesbezüglich fand ich das C-- Projekt ganz interessant und auch LLVM öffnet da möglicherweise einige Türen...

Da stimme ich zu. Allerdings hat C-- leider nie richtig abgehoben. Aber der Ansatz war recht gut.
 
Zurück
Oben