MacBook 32 bit oder 64 bit

[FrankR]

Das ist ganz offensichtlich eine Frage, die er nicht beantworten möchte.

Ich würde die Firma, in der TDD auf die von MacMark beschriebene Art und Weise betrieben wird, wirklich gerne mal kennenlernen.

Alex

Ja, ich auch - bisher dachte ich auch immer "There is no silver bullett", aber offensichtlich hat er sie mit TDD & Co. gefunden. Beneidenswert!

PS: arbeite seit ca. 1 Woche an unserer Code-Basis und habe schon einige schöne Bugs, z.B. C Funktionsaufrufe mit variabler Argumentenliste, bei der das letzte Argument durch einen NULL Pointer dargestellt wird, gefunden - bei 32Bit Code tut es da eine "0" - mit 64Bit Code - naja - aber MacMark wird jetzt sicher sagen, dass der Aufruf mit "0" bisher unprofessionell war - leider war der g++ unter Solaris immer anderer Meinung und mochte dort NULL nicht ... Alles so klitzekleine Probleme, die trotz TDD eine Menge Arbeit kosten.

 

[liquid-me]

Hallo zusammen!

...nicht Steinigen, ich geb´ ja zu, dass ich keine Ahnung hab; trotzdem hab ich einige Fragen:

(1.Macht es Sinn einfach mal zu testen, ob mein MacBook Pro (early 09) mit 64 Bit startet?)
2.Kann ich es rückgängig machen, wenn es nicht "rund" läuft (oder läuft er ganz oder gar nicht?!)
3.Woher weiss ich ob ich Treiber installiert habe, die nicht unter 64 Bit laufen?
4.Gibt es Programme, die nicht 64Bit unterstützen, wenn ja, woher weiß ich, welche meiner Programme es sind?

Danke schon mal!

 

[FrankR]

Hallo zusammen!

...nicht Steinigen, ich geb´ ja zu, dass ich keine Ahnung hab; trotzdem hab ich einige Fragen:

(1.Macht es Sinn einfach mal zu testen, ob mein MacBook Pro (early 09) mit 64 Bit startet?)

(1a) Nein (1b) Ob es für Dich sinnvoll ist, kannst nur Du entscheiden - probiere es einfach aus - s.u. - allerdings glaube ich nicht, dass es DIr performancemäßig viel bringen wird.

2.Kann ich es rückgängig machen, wenn es nicht "rund" läuft (oder läuft er ganz oder gar nicht?!)

ja, natürlich ist ein vernünftiges Backup immer zu empfehlen - kann ja sein, dass doch mal was komisch reagiert

3.Woher weiss ich ob ich Treiber installiert habe, die nicht unter 64 Bit laufen?

a) probieren, b) in Kernel /System/Library/Extensions "herumwaten" und schauen, was dort so liegt

4.Gibt es Programme, die nicht 64Bit unterstützen, wenn ja, woher weiß ich, welche meiner Programme es sind?

Ein 64 Bit Kernel hat kein Problem 32 Bit Code auszuführen.

 

[MacMark]

... Ich würde die Firma ...

Singular?

... in Kernel /System/Library/Extensions "herumwaten" und schauen, was dort so liegt ...

Oder so:

KeyWest:~ macmark$ find /System/Library/Extensions/*/Contents/MacOS -type f -exec file {} \; | grep x86_64 | wc -l
     158
KeyWest:~ macmark$ find /System/Library/Extensions/*/Contents/MacOS -type f -exec file {} \; | grep i386 | wc -l
     177

Mehr 32er- als 64er-Versionen. Für Details einfach die letzte Pipe jeweils weglassen.

 

[below]

Singular?

Kann ja sein, das es viele davon gibt. Ich habe bisher kein einziges kennen gelernt.

Und erfolgreiches TDD in der Praxis zu sehen wäre bestimmt mal sehr spannend. Also: Wer macht's ?

Alex

 

[MacMark]

... Und erfolgreiches TDD in der Praxis zu sehen wäre bestimmt mal sehr spannend. ...

Testgetrieben kann ein jeder auch allein in seinem Aufgabenbereich entwicklen, falls der Rest die Vorteile nicht zu schätzen weiß. Es steht Dir also frei, es selbst zu tun. Ob es erfolgreich wird, liegt an Dir. Sollte jedoch kein Problem sein für einen "Chef und Held von Kosmos" [Signatur von below] :-*

 

[below]

Testgetrieben kann ein jeder auch allein in seinem Aufgabenbereich entwicklen, falls der Rest die Vorteile nicht zu schätzen weiß. Es steht Dir also frei, es selbst zu tun. Ob es erfolgreich wird, liegt an Dir.

Und wieder erfolgreich ausgewichen.

Aber dazu: Wenn's doch so leicht ist, warum sehe ich das nicht überall?

Und alleine irgendwelche Prozesse durchzuziehen ist im Team ziemlich zum Scheitern verdammt. TDD erfordert erstmal Aufwand. Aufwand, den ich "dem Rest" gegenüber erst mal verantworten muss. Und selbst wenn: Was nützt es mir, wenn meine Komponenten 1A top mit UnitTests und allem Kram versehen sind, wenn der Rest es nicht ist?

Das ist ja bei Mac Treibern häufig das Problem: Da wird sehr gerne existierender Linux Code portiert. Den müsste man dann im Nachhinein erstmal mit tests ausstatten.

Sollte jedoch kein Problem sein für einen "Chef und Held von Kosmos" [Signatur von below] :-*

Ach, wenn Du wüssest, mit was sich ein "Raumpilot, galaktisches Diplomat, Entdecker, und, äh, Held von Kosmos" alles herumschlagen muss...

Aber bringen wir es auch den Punkt: Nichts von dem, was Du bisher gesagt hast gibt mir den Eindruck, dass es durch praktische Erfahrung untermauert wäre.

Die Arbeitsrealität, die ich kenne, ist wesentlich komplexer.

Alex

 

[MacMark]

Deine Antwort entspricht den üblichen Bedenken der Leute, die mit TDD keine Erfahrung haben (oder es falsch machen). Es ist kein "Prozeß" und in Summe ist es mit TDD schneller und der Code besser designed. Ich will hier aber keine Nachhilfe in TDD erteilen, ist ja ein Mac-Forum.

 

[below]

Deine Antwort entspricht den üblichen Bedenken der Leute, die mit TDD keine Erfahrung haben (oder es falsch machen).

Diese Kritik nehme ich gerne an, das ist bestimmt so. Allerdings bin ich damit nicht allein, es trifft auch auf meine professionelle und persönliche Umgebung zu.

Aber genau deshalb, weil ich ja immer gerne dazulerne, würde ich das gerne einmal in der Praxis sehen. Bei Leuten, die damit Erfahrung haben, und es richtig machen.

Leider bist Du offensichtlich nicht bereit, zu diesem Thema mehr als Allgemeinplätze zu äussern.

Alex

 

[MacMark]

... würde ich das gerne einmal in der Praxis sehen. Bei Leuten, die damit Erfahrung haben, und es richtig machen. ...

Welche Closed-Source-Software-Entwicklungs-Firma erlaubt denn externe Zuschauer?

 

[below]

Welche Closed-Source-Software-Entwicklungs-Firma erlaubt denn externe Zuschauer?

Keine. Aber Du redest immer davon, das Sachen ja so leicht sind. Nie davon, das Du das aus eigener Erfahrung weist.

Nicht einmal die Frage, ob Du schon mal einen OS X Treiber auf 64 Bit portiert hast, beantwortest Du. Und bei dem Thema lasse ich mich ungerne von jemandem über die Komlexität belehren, der das nur aus der Theorie weiss.

Wenn Du das aus der Praxis weisst, dann würde ich sehr gerne mehr konkrete Informationen haben, wie man diese Aufgabe erleichtern kann.

Alex

 

[MacMark]

... dann würde ich sehr gerne mehr konkrete Informationen haben ...

Ich bin hier schon genug unterwegs und kann mir kein weiteres Support-Hobby leisten.

 

[below]

Ich bin hier schon genug unterwegs und kann mir kein weiteres Support-Hobby leisten.

Nach diesem Statement bleibt mir nur eine Folgerung: Du hast selbst KEINE Erfahrung mit dem Portieren eines OS X Treibers auf 64 Bit. Aber Du masst Dir an, mir zu erzählen wie schwer oder wie leicht das ist. Das finde -- mit Verlaub -- etwas arrogant.

Alex

 

[MacMark]

Probier es so oft Du willst

 

[below]

Probier es so oft Du willst

Probier was?

Alex

 

[Jamsven]

Also TDD ist echt gewöhnunsbedürftig. Habe es bis jetzt nur mal mit JUnit 3 Testklassen gemacht. Man merkt dass es "aufgesetzt" ist. Ich habe die Testsuite gerne in einem anderen Package, das hat aber leider den Nachteil, dass ich alles testbare auf public setzen muss.

 

[MacMark]

-> Jamsven
Nimm einen separaten Sourcefolder für die Tests. Kein anderes Package, kein "public-Setzen". Da ist nichts aufgesetzt, es sein denn die Benutzung des zu testenden Codes ist "aufgesetzt". Dann ist es jedoch ein Hinweis auf miesen Code und Zeit für Refactoring.

-> below
Deine Probleme sind weniger zwingend für Kext-Portierung, sondern mehr spezifisch für Dein Projekt.

 

[below]

-> below
Deine Probleme sind weniger zwingend für Kext-Portierung, sondern mehr spezifisch für Dein Projekt.

Wow! Der Mann kann hellsehen! Ich bin raus aus dem Thread hier.

Alex

 

[MacMark]

Es ist doch offensichtlich: Sonst hätte jede Kext-Portierung auf 64 Bit so viele Probleme.

 

[Amin Negm-Awad]

@MacMark
Ohne deine regelmäßige Versorgung mit humoristischen Beiträgen wäre ich mutmaßlich gar nicht mehr hier.

Weiter so!