News Microsoft setzt auf Git als Versionsverwaltung

[fethomm]

alle Office Produkte!

Die Rede war nicht von Programmen, sondern von Tools, wie eben Git.

 

[noxon]

also, das linux tools nicht als einzelne abgeschlossene tools zu betrachten sind solltest du wissen. deswegen gibt es für's shell skripting WEIT mehr als die shell eigene skriptsprache.

Wohl war, aber alle Tools müssen immer mit Strings herumhantieren. Wenn du Daten von einem Tool an ein anderes weiterreichen willst, dann geht das nur über Zeichenketten und dort musst du dann die Daten herausparsen, die du haben willst.
Mit der Powershell entfällt das Ganze komplett da sie objektorientiert arbeitet. Daten werden dort in Objekte verpackt und du kannst auf einzelne Eigenschaften zugreifen oder auch Methoden auf sie anwenden.

Anstatt zum Beispiel mit sed in einem ls output wild herumzuparsen kannst du mit (ls).Name den Dateinamen ermitteln, mit (ls).Length die Dateilänge oder mit (ls).LastWriteDate das letzte Zugriffsdatum.

Systemadministration war damit noch nie so einfach. Folgendes Skript beendet zum Beispiel alle nicht mehr reagierenden Prozesse.
"Get-Process | where Responding -eq $false | Stop-Process"
Da Responding hier eine Eigenschaft des Process-Objekts ist, ist die Handhabung wirklich super einfach. Ich würde gerne mal ein vergleichbares Bash-Script sehen, dass alle Zombie-Prozesse killt.

das kann ich umgekehrt auch.

Das hat niemand bezweifelt. Ich kann das auch. Sogar massenhaft, aber fethomm tat so, als ob jegliches Linux Tool grundsätzlich besser wäre als alle Windows-Tool, was natürlich vollkommener Quatsch ist.

mal davon abgesehen, dass ich nicht mehr probleme habe mit eclipse, als ich sie mit visual studio hatte (zwar andere aber nicht weniger), so ist eclipse nicht die einzige ide für linux und für alles ausser java bei weitem nicht die beste.

Mit dem Visual Studio kann aber wirklich keine IDE mithalten. OK. Es braucht vielleicht nicht jeder alle Features, aber welche IDE kann schon GPU Debugging, bietet einen so guten HLSL und GLSL Support, beherscht ein sehr gutes Parallel Execution Debugging, Intellitrace, eine tolle ALM Integration, und und und.
Es enthält sogar ein Tool zur grafischen Shaderprogrammierung, einen rudimentären 3D-Designer, ein Icon Editor, ein Bildbearbeitungsprogramm und mit dem neusten Update werden jetzt noch die Expression Tools mit in das VS integriert. Auch wenn du Office-Vorlagen erstellen willst, dann binden sich die Excel oder Word Dokumente direkt in das VS ein und lassen sich so direkt in der IDE editieren. All diese Dinge gibt es in keiner anderen IDE.
Von den ganzen Kleinigkeiten die ich insgesamt besser finde als an allen anderen IDEs fang ich am Besten gar nicht Mal an.

 

[Floletni]

Ich bin jetzt nicht ganz firm in diesen Themen und habe entsprechend ein paar Fragen.

1. Ist der Team Foundation Server ein Art Zusatz/Erweiterung zu Visual Studio?
2. Welchen Nutzen hat es Git in MS TFS zu integrieren? So wie ich das verstanden habe hat ja TFS alles integriert. Will man damit Unix Nutzer anlocken? Oder ist ihre Versionverwaltung so schlecht das man sich bei Git bedient?

 

[Matthias247]

TFS ist eine zentrale Versionsverwaltung, git eine dezentrale. Dadurch hat git eben gewisse Vorteile. Andere mögen möglicherweise wohl auch Nachteile darin sehen.

 

[Sukrim]

Naja, welches andere DVCS hätten sie auch nehmen sollen... bazaar ist stark an Launchpad und Canonical gebunden, Mercurial wäre noch eine Möglichkeit aber dann würden ohnehin wieder viele Entwickler "warum nicht gleich Git?!" schreien. Alternativ eben noch eine Eigenentwicklung, die aber wieder zumindest kompatible zu Git sein müsste.

Daher ist es schon sinnvoll, Git gleich einzubinden - hoffentlich kommt von eventuellen Verbesserungen auch Upstream was an.

 

[ChilliConCarne]

Kurz zum Thema: Hab schon paar mals gelesen, dass einige MSDN Leute git ganz gut finden. Vor allem ist interessant, dass einige auch den Emacs gerne nutzen. So nun zum Rest.

Aber es gibt auch Tools wie die SysternalTools die ich sehr stark unter Linux vermisse.

Vermisst du das im Sinne eines Gesamtpakets, oder weil du die einzelnen Tools nicht findest? Letzteres würde irgendwie den Eindruck erwecken, du hättest nie Linux verwendet, was ich jetzt bezweifle. Was die Toolkits und das Debuggen usw. angeht, halte ich es wie Dese. Ich sehe es ebenfalls anders. Aber das kommt eben stark darauf an mit was und wie man arbeitet. Entwicklungen mit C# und Dot NET mache ich sicherlich nicht unter Linux. Nichtsdestotrotz erzählen mir hauptsächlich Windows beheimatete User immer wieder wie toll und schnell Dinge - abseits C# und Dot NET - nur unter deren Lieblingssystem gehen und dass alles unter Linux so kompliziert sei und viel länger dauert. Nach einer Vorführung meinerseits wie man es unter Linux 'richtig' macht bzw. machen kann, ist dann entweder großes Schweigen da, oder es kommen Fragen (sofern diese 'Schelte' angenommen wird) wie das geht und wo das nachzulesen sei. Und das letzt Genannte ist die Krux. Es ist unabstreitbar, dass man unter Windows recht schnell eine schöne und vor allem gute Arbeitsumgebung hat. Man muss, auch wenn eine da ist, nur eine kleine Lernkurve meistern. Das ist ja auch legitim. Nur sollten dann entsprechende Leute, sich in der Aburteilung eines Systems, in das sie sich nicht vollständig einarbeiten wollen zurückhalten und Leuten die beide Welten kennen einfach mal glauben, dass genug Dinge unter Linux und dessen Haustools sehr wohl effektiv ggf. effektiver machbar sind als unter Windows. Respektive anders herum. Heißt unterm Strich: Beide Welten nehmen sich nicht viel. Und ob fethomm nun so tat als ob es unter Windows keine besseren Werkzeuge gibt, oder im Thread einfach nur Beispiel wollte, sei mal dahingestellt.

Aber mal zum Thema stream- und objektorientierte Shell.

Get-Process | where Responding -eq $false | Stop-Process

Das ist auf den ersten Blick zur Veranschaulichung ein schlechtes Beispiel, da dies unter einer Linux Shell mit folgendem Einzeiler geht:

kill -9 `ps -A -opid:1,stat | grep ' Z$' | cut -d' ' -f1`

Erklärung: Prozesse mit den Spalten der ID und des Status ausgeben, alles mit Status Z, also defunct am Ende nehmen, die erste Spalte projezieren und das geht dann an kill.

Ich sage dazu, dass ich dein Beispiel mit der Aufforderung das mal in der Bash zu machen, so verstanden habe, als würde das nicht gehen. So kommt es zumindest rüber.

Es kommen aber ein paar Punkte die ich selbst als Einwand nenne. Einmal vermischst du "nicht reagierenden Prozess" und "Zombies". Jedoch ist das sogar zu deinem Vorteil. Ein Äquivalent der nicht reagierenden Prozesse unter Linux wären vielleicht die mit Status D. Das "nicht reagieren" unter Windows tritt laut der System Diagnostics API dann ein, wenn ein künstliches Event zu keiner Reaktion eines Prozesses, der an der Oberfläche hängt, führt. Einmal gibt es so einen Prozesszustand mit dieser Semantik - meines Wissens - unter Linux nicht und zum anderen liese sich das zwar nachbilden, aber selbsterklärend wärs dann das mit meinem Einzeiler oben. Ein Zombie ist wirklich tot und nicht durch seinen Parent aufgeräumt und belegt auch keine Resourcen, außer (ironisch gesagt) ein paar Byte für den Eintrag in der Prozesstabelle. Mein Einzeiler ginge mit 'killall -r <defunct>' zwar noch einfacher, aber ich habe versucht den Ablauf aus Sicht der Shell möglichst identisch zu halten. In der Form ist der Einzeiler der Powershell für jemanden der beide Welten nicht kennt sicherlich schneller zu verstehen. Dies liegt jedoch in diesem Beispiel eher an der syntaktischen Natur. Aus 'where Responding -eq $false |' wird 'grep ' Z$' | cut -d' ' -f1'. Wer beide Welten kennt, versteht beides gleich gut. Der eigentliche Clou ist, dass 'where .. -eq' hier gewissermaßen einen Operator darstellt der durchgehend für alle Ausgaben nutzbar ist. Der Vorteil dessen kommt erst richtig in anderen Beispielen zur Geltung, von denen ich weiß, sie mal gesehen zu haben, mich aber nicht mehr im Detail erinnere.

Allgemein zur Powershell und exemplarisch der Bash gesehen, haben beide Ansätze denke ich ihre Vor- und Nachteile. Ich habe Beispiele gesehen, die zeigten, dass ein objektorientierter Ansatz in gewissen Situationen zu hässlichem Code führen kann. Wie oben kann ich mich jedoch nicht mehr an den Code selbst erinnern. Zusammenfassend gewann ich den Eindruck, dass sich kürzere Aufgaben, trotz des im Kontrast obigen Beispiels, kompakter mit einer stream basierten Shell erledigen lassen. Bei komplexeren Aufgaben bietet sich der objekt orientierte Ansatz an. Ist ja wie bei der Entscheidung zwischen C und C++. Im Sinne der Interaktivität bringt der objektorientierte Ansatz konzeptionell gewisse Hürden mit. Mal ganz abstrakt gesehen ist der Input eines Nutzer gewissermaßen als Stream zu sehen und es muss durchgehend für eine Vermittlung zwischen dem und der Interpretation als Element einer Klasse gewährleistet werden. Ob das effektiv zu nennenswerten Einschränkungen führt, kann ich so momentan nicht abschätzen. Ein weiterer Punkt ist noch die Laufzeit. Auf technischer Sicht werden die IO Umlenkungen ja auch bei der Powershell bzw. vom System als byte stream verschickt. Die Objektorientierung bzw. die Abbildung des Streams auf eine Struktur die als Objekt interpretiert wird, findet ja auf der Shell-/Applikationsebene statt. Und das permanent. Jedoch dürfte sich der Overhead in Grenzen halten. Ein Umstand der sich unter der Powershell (wie auch jeder anderen modernen Skriptsprache) nicht vermeiden lässt, ist jedoch wenn Binaries oder Werkzeuge zum Einsatz kommen, die die CLR gar nicht kennen. Dann muss über das Stream.IO Modul ein stream basierter Ansatz dazu gemixt werden, was eine gewissen Hack darstellt. Gut, das ist jetzt aber weniger ein Problem das speziell der Powershell angerechnet werden muss. Was man aber eindeutig zu Gute halten kann, ist dass hinter der Powershell aufgrund der C# Implementierung das komplette .NET Framework, nahezu perfekt verzahnt dahinter steht. Und das ist nicht ohne. Dadurch gewinnt die Powershell eher den Character einer vollwertigen Anwendugs-Skriptsprache mit shell typischen Syntax Elementen und Werkzeugen.

In meinen Augen ist es letztlich eine konzeptionelle Sache, die nicht so leicht entschieden werden kann. Ich tue mir zumindest schwer zu sagen, das Eine oder das Andere sei besser. Ähnlich hält es jemand in diesem guten Kommentar: Object oriented Shell for nix. Die Idee der objekt orientierten Shell ist ja nicht neu oder von Microsoft erfunden. Da gab es schon lange Gedankengänge dazu. Folgender Post zum Beispiel ist glaube ich von 2006: Object-oriented shell for linux?. Es ist auch nicht so, dass ich nicht irgendwo unter Linux eine objekt orientierte Shell nutzen könnte. Da gibt es oobash, zoid, perl shell, irb, ipython und und und. Ist eben nur nicht Usus und vor allem nicht als /bin/sh Instanz zu gebrauchen!

Was das Thema IDEs angeht, kann ich jetzt nicht viel aus praktischer Erfahrung sagen, da ich mir meine Tools selbst zusammenstelle und quasi abstimme. Kostet zwar Zeit, aber meine Arbeitsumgebung topt keine IDE und wird es auch in Zukunft nicht. Aber wenn wir mal bei IDEs bleiben ist VS sicherlich einer der Top Spitzenkandidaten, sofern man nur unter Windows arbeitet. Aber was die Features angeht sehe ich da jetzt nicht so einen riesen Abstand. Gewiss vereint VS wahnsinnig viel, aber GPU Debugging geht zum Beispiel mit Nvidia Nsight. Intellitrace ist analog zu den records des gdb. Wobei Letzterer das auch unter C++ kann. Bei Intellitrace siehts so aus:

Das Debuggen von C++, Skript oder anderen Sprachen wird von IntelliTrace nicht unterstützt.

Als ALM ist afaik Eclipse MyLyn ein gern genommenes Pendant. Und Intellisence ist eine sematische Vervollständigung die einige IDEs, so wie ich das sehe in der Form ebenfalls beherrschen. Da wären Codeblocks oder QtCreator, oder eben auch Eclipse.

Da halte ich es schlussendlich rein aus Sicht der IDE Nutzung für gewagt, dass man unter Windows per se produktiver sei.

 

[noxon]

Vermisst du das im Sinne eines Gesamtpakets, oder weil du die einzelnen Tools nicht findest? Letzteres würde irgendwie den Eindruck erwecken, du hättest nie Linux verwendet, was ich jetzt bezweifle.

Natürlich gibt es unter Linux auch viele der Tools, die es auch in den Sysinternal-Tools gibt. Viele gibt es zum Teil gar nicht da sie ganz einfach windowsspezifisch sind, aber einige sind unter Linux einfach nicht so gut, wie zum Beispiel der Process Explorer. Unter Linux gibt es nichts Vergleichbares mit dem sich Prozesse und das System so gut analysieren lassen wie mit diesem Tool. Das mag vielleicht mit 20 einzelnen Tools auch gehen, aber ich hätte so etwas schon gerne alles unter einer Oberfläche.

Heißt unterm Strich: Beide Welten nehmen sich nicht viel.

Sehe ich ähnlich. Wichtig ist nur, dass man sich in die Sache hineinarbeitet. Das gilt für Linux als auch für Windows.

Ich sage dazu, dass ich dein Beispiel mit der Aufforderung das mal in der Bash zu machen, so verstanden habe, als würde das nicht gehen. So kommt es zumindest rüber.

So war das nicht gemeint. Ich weiß natürlich, dass das auch mit der Bash funktioniert, aber ich bin darin nicht gut genug um das Beispiel zu erstellen und deswegen habe ich die Aufgabe in den Raum gestellt. Und wie man sieht ist die Sache ja auch um einiges komplexer als in der PS.

Es kommen aber ein paar Punkte die ich selbst als Einwand nenne. Einmal vermischst du "nicht reagierenden Prozess" und "Zombies".

Der Unterschied ist mir schon bewusst. Ich habe mit Absicht Zombie-Prozesse gewählt, da es unter Linux kein wirkliches Äquivalent zu nicht reagierenden Prozessen gibt. Für das Beispiel war es ja auch relativ egal um was für ein Merkmal es sich hier handelt nachdem gefiltert werden soll. In der Hauptsache ging es ja um das Skript.

Allgemein zur Powershell und exemplarisch der Bash gesehen, haben beide Ansätze denke ich ihre Vor- und Nachteile. Ich habe Beispiele gesehen, die zeigten, dass ein objektorientierter Ansatz in gewissen Situationen zu hässlichem Code führen kann.

Du meinst sicherlich so etwas hier:

gps | ? { $_.Res -eq $false } | spps -f

Befehle wie "Get-Process" oder "Stop-Process" haben oftmals Aliases wie "gps" oder "spps".
Das "where" wird von den Profis als "?" geschrieben.
Vor der Version 3.0 der Powershell musste man noch die For_Each Zählvariable "$_" vor die Property mit angeben.
Alle Angaben müssen nur so lang sein bis sie eindeutig identifiziert werden können. "Responding" kann also auch mit "Res" oder "r" abgekürzt werden, solange es eindeutig ist.

All das macht den Code natürlich wieder etwas kryptischer. Seit Version 3.0 kann man ihn aber auch sehr ordentlich und einfach schreiben wenn man will. So wie in meinem Beispiel aus dem ersten Posting. Es geht aber auch kurz und kryptisch. So schreibt man eher die Skripte, wenn man es profesioneller macht.

ps | ? {!$_.res} | kill -f

Außerdem sichert man sich so den Arbeitsplatz
Obwohl. Den Arbeitsplatz sichert man sich wohl eher hiermit.

kill -9 `ps -A -opid:1,stat | grep ' Z$' | cut -d' ' -f1`

Ein weiterer Punkt ist noch die Laufzeit. Auf technischer Sicht werden die IO Umlenkungen ja auch bei der Powershell bzw. vom System als byte stream verschickt. Die Objektorientierung bzw. die Abbildung des Streams auf eine Struktur die als Objekt interpretiert wird, findet ja auf der Shell-/Applikationsebene statt.

Um die Performanceaspekte habe ich mich noch gar nicht mal so sehr gekümmert. Bisher hatte ich dort noch kene Probleme. Ich weiß noch nicht einmal ob die Skripte nur interpretiert oder sogar gejittet werden. Ich tippe auf letzteres, was ja sogar einige Optimierungen zur Folge hätte.

Da halte ich es schlussendlich rein aus Sicht der IDE Nutzung für gewagt, dass man unter Windows per se produktiver sei.

Das ist natürlich nicht grundsätzhlilch so, aber wie produktiv man sein kann hängt immer stark von den Tools ab, die einem zur Verfügung stehen und bloß weil es solche Plugins wie Nsight auch für Eclipse gibt heißt es nicht, dass sie auch den gleichen Umfang liefern.
Zwischen der Version für Eclipse und der für das Visual Studio bestehen schon einige Unterschiede.
Game-Developer in großen Studios verwenden ja auch nicht umsonst das Visual Studio für $14.000 anstatt das kostenlose Eclipse.

Das Alles ist jetzt aber auch sehr stark aus der Sicht von Spezielanwendern gesehen, wie zum Beispiel Spieleentwicklern. Der normale 0815 Entwickler braucht diese Features natürlich nicht und kommt auch mit einem kostenlosen Eclipse zurecht.