Thema: Ex-MS-Mitarbeiter zum Kernel: "Die Fäulnis setzt bereits ein"

Heute habe ich folgenden Artikel gelesen, dessen Meinung ich nicht ganz zustimmen kann:

Microsoft: "Die Fäulnis setzt bereits ein"

Ehrlich gesagt glaube ich das nicht so ganz wirklich.

Golem.de

Außerdem verliere Microsoft immer mehr talentierte Entwickler an andere Konzerne, etwa Google.

Klar ist, dass Microsoft gute Leute an Google verliert, schliesslich ist das ja (nach einer aktuellen Studie, ja, ich weiss, Studien und so...) der beliebteste Arbeitgeber bei Studenten. Bei Google können die Leute auch "breiter" lernen.

Golem.de

Bevand kritisierte in seinem Posting, dass Entwickler bei Microsoft im Vergleich zu den Linux-Hackern kaum einzelne Kernel-Komponenten systematisch optimierten. Microsoft-Entwickler hätten weder mit Prozess-Schedulern experimentiert, noch versucht, Dateisysteme oder TCP/IP-Stacks im WLAN-Modul so zu optimieren, wie es die Linux-Entwickler getan hätten, schreibt Bevand, der selbst als Entwickler im Bereich Low-Level-Programming und High-Performance-Computing arbeitet. Multi-Plattform-Code, den er in C oder Java geschrieben habe, laufe unter Windows immer langsamer als unter Linux, beklagt Bevand. Jüngst habe er Leistungseinbußen unter Windows auf einem fragmentierten Master File Table (MFT) im Windows-Dateisystem NTFS ausgemacht.

Persönlich erwarte ich auch, dass der NT-Kernel relativ stabil entwickelt wird, anstatt auf Featuritis zu setzen, das macht ja auch der Linux-Kernel so. Man kann Microsoft aber nicht vorwerfen, sie würden sich nicht um Alternativen kümmern, schliesslich haben sie mit dem NT6er-Kernel (ich will damit nicht cool wirken, aber "mit Vista" ist mir zu schwammig) den TCP/IP-Stack von FreeBSD übernommen. Ob da auch am WLAN etwas geändert wurde, kann ich aber nicht beurteilen.
Den Absatz über das fragmentierte MFT habe ich nicht ganz verstanden, vielleicht kann mir hier jemand weiterhelfen. Gibt es nicht überall Leistungseinbussen, wenn etwas fragmentiert wird? Oder meint der Herr, dass sowas gar nicht fragmentiert werden darf, oder sogar durch NTFS "bewusst" fragmentiert wird?

Golem.de

Die Vorwürfe, Microsoft vernachlässige Leistungsverbesserungen zu Gunsten neuer Funktionen, ist nicht neu. Windows Vista geriet in die Kritik, weil es deutlich langsamer lief als zuvor Windows XP auf gleicher Hardware. Erst mit Windows 7 setzten die Microsoft-Entwickler wieder auf Leistungsoptimierungen, die teilweise auch in Windows 8 umgesetzt wurden.

Den Absatz mit Vista zu W7 zu W8 unterschreibe ich so, das war tatsächlich so. Mit der Einschränkung, dass 2009 die Geräte standardmässig mehr RAM hatten als 2006/7, aber Vista lief auch auf neueren Geräten schlechter als W7.

Golem.de

Externe Patches würden kaum akzeptiert, schreibt der Kernel-Entwickler bei Microsoft. Solche Patches verärgerten den Leiter einer Entwicklungsabteilung, denn sie bedeuteten zusätzlichen Pflegeaufwand. Das Testing-Team ärgere sich über zusätzliche Arbeit und Verantwortung. Der zuständige Produktmanager fürchte sich vor einer möglichen Terminverschiebung. Es gebe immer mehr Gründe eine neue Funktion abzulehnen, als sie zu akzeptieren.

Klar werden externe Patches nicht gerne gesehen, schliesslich müssen diese später auch gewartet werden. Raymond Chen hat das mal gut ausgedrückt, sinngemäss: "Wenn wir einen Fehler einbauen, wird sich irgendwann irgendjemand auf diesen Fehler verlassen und wir müssen ihn weiterziehen."
Leider zeigt sich das auch sonst in seinem Blog (dieser handelt unter anderem von "obskuren Verhaltensweisen" unter heutigen oder früheren Windows-Versionen und ihren Ursprüngen): jemand schrieb als Kommentar sinngemäss "Gibt es eigentlich noch eine andere Argumentation gegen neue Funktionen als "Would break compatibility"?".

Golem.de

Änderungen, die kleinere Leistungsoptimierungen mit sich brächten, würden von den Linux-Entwicklern gelobt, bei Microsoft aber ignoriert - wenn sie überhaupt übernommen würden, schreibt der Microsoft-Mitarbeiter. Vorschläge zu inkrementellen Optimierungen würden andere Entwickler dort nur nerven. Erst spektakuläre, neue Funktionen würden vom oberen Management registriert und könnten der Karriere dienen.

Dass sie zuwenig Lob bekommen wurde schon von anderen so erzählt, ist also glaubhaft. Allerdings habe ich auf Linux-Kernel Mailinglisten auch nicht immer nur Bewunderung gelesen, dazu muss ich aber ehrlich zugeben, dass ich kein grosses Bild dieser Mailinglisten habe und vielleicht auch nur immer in den falschen Stellen gelesen habe. Vielleicht kennt sich hier jemand besser aus.

Golem.de

Stattdessen würden zwar neue, aber auch redundante Funktionen umgesetzt, etwa die Power Shell. Aus seiner Sicht wäre es besser gewesen, die herkömmliche CMD-Shell zu erweitern, schreibt der Windows-Entwickler. Dafür hätten sich zahlreiche Entwickler eingesetzt, es sei aber abgelehnt worden.

Persönlich bin ich von der Powershell begeistert und finde den Reboot besser, als weiter an der alten CMD-Shell "zu basteln". Diese ist einfach nicht mehr auf dem aktuellen Stand und jede Weiterentwicklung würde, meiner Meinung nach, viele alte Skripte inkompatibel machen, oder es könnte vieles nicht umgesetzt werden. Mit der Powershell kann man komplett neu beginnen.

Golem.de

Als weiteres Beispiel nennt der anonyme Entwickler den NTFS-Code, den er einen "viktorianischen Horror-Roman" nennt, der unter dem Einfluss von Opium entstanden sei, etwa weil das Windows-Dateisystem globale rekursive Sperren nutze. Der Nachfolger ReFS sei auf der Codebase von NTFS entstanden. Die Entwickler hätten zunächst lediglich den NTFS-Code kopiert, die Hälfte der Funktionen entfernt und deshalb Checksums eingeführt, um mit ReFS so "cool zu sein wie ZFS", dabei aber die ebenso wichtigen Quotas vergessen.

Mit Dateisystemen kenne ich mich zuwenig aus, deshalb habe ich keine Meinung zum ReFS-Absatz. Meiner Meinung nach unterstützt aber NTFS Quotas (Speicherplatzbeschränkungen pro Benutzer), oder ist das hier gerade der Kritikpunkt?

Golem.de

Microsoft habe immer noch einige talentierte Entwickler, die die Komplexität der Kernel-Entwicklung erkennen und ein Auge für gutes, sauberes Design haben, resümiert der frustrierte Microsoft-Mitarbeiter. In einigen Bereichen sei der NT-Kernel deutlich besser als der Linux-Kernel, etwa bei der Speicherverwaltung. Es mangele Microsoft aber an jungen talentierten Entwicklern. Bei dem Windows-Hersteller habe "die Fäulnis bereits eingesetzt."

Beim letzten Absatz stört mich etwas: Er stört sich daran, dass Studenten eingesetzt werden, aber auch daran, dass keine jungen, talentierten Entwickler da seien. Vielleicht verfolgt MS mit der Studenten-Strategie ja genau das, diese jungen Entwickler weiter zu fördern, aber da kann ich nur spekulieren.

Würde mich über eine Diskussion freuen

Naja, Ex-Mitarbeiter tritt gegen Ex-Arbeitgeber nach.

Dreami

Ehrlich gesagt glaube ich das nicht so ganz wirklich.

Warum denn nicht? Windows hat seit Windows 2000 in seiner Grundfunktionalität keine spürbaren Fortschritte mehr gemacht. Es wurden immer nur neue Designs und Features hinzugefügt. Geschwindigkeitszuwachs brachte uns in den letzten Jahren nur die Hardware inkl. Treiberoptimierungen selber. (und natürlich der Sprung von x86 auf x64)
Der gute Mann hat einfach Recht. Man ruht sich bei M$ auf den Lorbeeren aus. Man hat einen funktionierenden Kernel, der nicht allzu schlecht ist.

Dreami

Den Absatz über das fragmentierte MFT habe ich nicht ganz verstanden, vielleicht kann mir hier jemand weiterhelfen. Gibt es nicht überall Leistungseinbussen, wenn etwas fragmentiert wird? Oder meint der Herr, dass sowas gar nicht fragmentiert werden darf, oder sogar durch NTFS "bewusst" fragmentiert wird?

Ja, fragmentierung = unperformant. Und der Master File Table ist das Kernstück des NTFS Dateisystems. Hier kommt es zu gewaltigen Performance-Einbrüchen. Kurzum, der MFT dürfe gar nicht erst fragmentiert werden. Dem entgegenzuwirken würde Arbeit bedeuten, aber es würde die Performance bei Platten jenseits der 500GB enorm erhöhren. Man könnte zb regelmäßig beim Boot nach den Updates den MFT defragmentieren. Das würde das Problem lösen.

Dreami

Klar werden externe Patches nicht gerne gesehen, schliesslich müssen diese später auch gewartet werden. Raymond Chen hat das mal gut ausgedrückt, sinngemäss: "Wenn wir einen Fehler einbauen, wird sich irgendwann irgendjemand auf diesen Fehler verlassen und wir müssen ihn weiterziehen."

Das selbe gilt für eigene Inhalte. Nur weil es nicht aus eigener Hand kommt sollte man nicht alles ablehnen. Hier ist das Stichwort passend: Über den Tellerrand hinausschauen.

Dreami

Persönlich bin ich von der Powershell begeistert und finde den Reboot besser, als weiter an der alten CMD-Shell "zu basteln". Diese ist einfach nicht mehr auf dem aktuellen Stand und jede Weiterentwicklung würde, meiner Meinung nach, viele alte Skripte inkompatibel machen, oder es könnte vieles nicht umgesetzt werden. Mit der Powershell kann man komplett neu beginnen.

Geschmackssache. Ich hasse die Powershell, obwohl ich zur Zeit im Windows Server Umfeld arbeite.

Dreami

Mit Dateisystemen kenne ich mich zuwenig aus, deshalb habe ich keine Meinung zum ReFS-Absatz. Meiner Meinung nach unterstützt aber NTFS Quotas (Speicherplatzbeschränkungen pro Benutzer), oder ist das hier gerade der Kritikpunkt?

NTFS unterstützt Quotas. Da liegst du richtig. Jedes Dateisystem unterstützt Quotas (zumindest jedes welches eine Dateigrößenabfrage zulässt ), da diese auch applikationsbasierend umgesetzt werden können. Aber Quotas sind kein Garant für ein gutes Filesystem.

Alles in allem ein gelungener Artikel, welcher mal Licht auf die andere Seite der Medaille M$ wirft.

ButterZ

Geschmackssache. Ich hasse die Powershell, obwohl ich zur Zeit im Windows Server Umfeld arbeite.

Darf ich fragen, was dich an der Powershell stört?

Dreami

Darf ich fragen, was dich an der Powershell stört?

Ich sehe es einfach nicht ein die Eigenheiten einer komplett neuen Scriptsprache zu lernen nur damit ich Windows-Maschinen besser administrieren kann. Es gibt in meiner Welt größere Prioritäten als die komfortable Administration von Windows-Systemen. Für meine Zwecke reicht die Kommandozeile komplett aus, und falls ich doch mal mehr brauche kann ich meine Anwendungen und Scripts unterstützend mit C++ & VB ausschmücken Dies sind Technologien die ich bereits beherrsche. Außerdem ist meine Spezialisierung die Automatisierungstechnik, da habe ich keinen Nutzen von PS. Da investiere ich meine Zeit lieber in wichtigere Dinge.

Ich muss sagen, dass mich die Powershell im Moment für unser Deployment einfach überzeugt hat, aber wir arbeiten in dem Teil auch sehr Windows-lastig. Die restlichen Server sind natürlich weit Unix-lastiger, mit denen komme ich auch zurecht, aber ich find die Powershell etwas komfortabler

Mir gefällt z.B. die einfache Objekterstellung. Zurzeit schreibe ich ein Skript zum Deployment unserer Schulungsraumes, 8 Geräte mit je 3 Eigenschaften. In der Powershell kann ich diese Attribute in XML hinterlegen und dann sehr einfach, ohne grösseres Parsen, die Einstellungen auslesen, in eine Funktion pumpen und erhalte meine 8 Objekte, deren Attribute ich dann im ganzen Skript auslesen kann.

Weiter gefällt mir, dass es konsistenter ist. Wenn ich VB-Skripte anschaue, muss ich leider öfters nachschauen, was jetzt damit gemeint ist, die Befehle sind also nicht sprechend, die Argumente auch nicht. Du kennst bestimmt diese ellenlangen VB-AD-Join-Skripte, bei uns ist das ein einfacher Join-Computer -Domain (...) -Credentials (...), fertig. Noch etwas Drumgeschmücke herum, Fehler abfangen, und so weiter, aber das wars dann.

Das beste finde ich aber, dass ich (im Gegensatz zu Unix) nicht Text parsen muss, um meinen Output weiter zu verarbeiten. Beim Bash-skripten musste ich leider einige Male erst die richtige Option herausfinden, damit das Programm in der Pipeline etwas fabriziert, was nicht nur ich, sondern auch das nächste Programm in der Pipeline weiterverarbeiten kann. PS arbeitet hier mit Objekten, die das nächste Programm dann gleich so weiterverarbeiten kann, du siehst nur einen Auszug dieser Objekte.
Dabei muss ich die Powershell ISE (vorallem ab 3.0) wirklich loben, sie bietet auch Tab Completion (mit/und IntelliSense) für Parameter an, inkl. einem GUI um diese Parameter gleich abzufüllen. Ich weiss, für .NET-Programmierung alter Kaffee, aber um einiges einfacher als die VB-Befehle auswendig zu lernen, oder dauernd MSDN offen zu haben

Kann dich aber verstehen, es ist schon eine Randsprache. Ich kann sie dir aber nur wärmstens empfehlen, sofern du System-Automatisierung meinst, und nicht die Arbeit des "Automatikers"

Dreami

Kann dich aber verstehen, es ist schon eine Randsprache. Ich kann sie dir aber nur wärmstens empfehlen, sofern du System-Automatisierung meinst, und nicht die Arbeit des "Automatikers"

Mein Kerngebiet und Interesse ist die Entwicklung von Routinen und Abläufen auf verschieden Microcontrollern. Desweiteren entwickle ich Funktionspläne und Anweisungslisten für Speicherprogrammierbare Steuerungen (Siemens S5 - S7). Ich bin zwar Informatiker, und habe Kenntnisse in allen Bereichen, aber die Automatisierung ist die spannendste Facette. Aber wie oben schon angemerkt, man kann im Leben leider nicht immer das machen was man gerne möchte, deshalb bin ich zZ im Windows Serverumfeld tätig. Aber wahrscheinlich werde ich dort nicht lange genug sein um PS wirklich zu brauchen. Denn bevor ich das den Rest meines Lebens mache geh ich lieber wieder zurück in die Hardware- oder Datenbankentwicklung

Ich sag es mal so: Das bei MS gern die Faulheit (und in Zuge dessen auch die Fäulnis) einsetzt wenn sie sich nicht ganz konkret einen wirklichen Vorteil von etwas versprechen ist nicht erst seit drei Tagen bekannt. Es gab immer mal wieder Bereiche die vor sich "hingesiecht" sind, bis dann endlich mal ein gutes Konkurrenzprodukt ein wenig Druck aufgebaut hat. Dann verschlafen sie die Entwicklung auch gern, um dann mit Hauruck-Aktionen wieder Fuß zu fassen zu versuchen.

Das bekannteste aber bei weitem nicht das einzige Beispiel dürfte in dieser Hinsicht die Internet Explorer Geschichte sein. Es ist schon regelrecht traurig wie lange da ein Fortschritt ausgebremst wurde, da der IE keine wirkliche Konkurrenz hatte. Bis in immer mehr Statistiken plötzlich der Firefox und später auch Chrome auf signifikante Marktanteile kamen und MS endlich einen Grund hatte, mal wieder etwas nachzulegen.

Bei Windows wird es nicht anders sein. Auch wenn ich Linux gern hab (und Apple zumindest im Blickfeld) sehe ich hier auf dem Desktop-Markt allerdings auch wieder keine wirkliche Konkurrenz und somit keine Chance, dass sich da viel ändern wird. Höchstens durch Druck auf dem (ohnehin fast verschlafenem) Tablet-Markt, wo die effiziente Ausnutzung der Hardware-Ressourcen eben noch wichtiger ist.

Ist letztlich auch eine natürliche Entwicklung: Optimierungen auf hohem Niveau bei gleichzeitig zu garantierender Stabilität sind eben sozusagen exponentiell teurer als neue Bling-Bling-Features. Gefährlich wird es erst dann, wenn man dadurch wirklich sichtbar ins Hintertreffen gerät, so wie eben beim IE damals. Bis jetzt sehe ich nicht, dass das hier der Fall wäre. Auch wenn schon seit Jahrzehnten vom Anfang des Untergangs geunkt wird.


Kleine Ergänzung zum Thema Powershell: Gut, ich muss damit jetzt nicht beruflich großartig mit arbeiten, insofern fehlt mir vielleicht Erfahrung wie auch Notwendigkeit. Als jemand, der viel unter Linux arbeitet (und dort auch viel per Konsole macht) wirkt auf mich die alte CMD eben auch genau so: Ein verwaistes Relikt aus alten Tagen, das schon seit Ewigkeiten nicht mehr angefasst (im Sinne von weiterentwickelt) wurde. Scheint eher noch vorhanden weil man eben Konsolenbedienung auch im Windows-Bereich (insbesondere Server) hier und da einfach benötigt, ist dabei aber im Vergleich extrem unkomfortabel.

Auch wenn die Powershell nun vielleicht auch nicht in jeder Hinsicht der Weisheit letzter Schluss ist, so wirkte sie dennoch schon von Beginn an sehr viel moderner, komfortabler und mächtiger. Klar, die Nutzung erfordert dann ein neues Anlernen, aber wenigstens wurde jetzt mal eine Alternative entwickelt, die nicht noch aus den 90ern zu stammen scheint.

ButterZ

Mein Kerngebiet und Interesse ist die Entwicklung von Routinen und Abläufen auf verschieden Microcontrollern.

da brauchst du die PowerShell ja eh nicht

aber wenn ich die Wahl hätte zwischen Assembler und PowerShell, ich wüste was ich nehme, Bits schubsen ist zwar nett, aber naja....