Der Sansa Clip+ als Quelle für Kopfhörer-Audio

FAT oder FAT32. Je nachdem, ob mehr oder nicht mehr als 4GB Speicherkapazität.

Edit: Habe den Player zwar nicht, ist aber soweit ich weiß Standard bei den Readern. exFAT versteht nämlich fast kein Gerät. Vielleicht mit den neuen SDXC Karten

FAT32 oder FAT16, was anderes wird er kaum nehmen.

EDIT: Doppelt genäht hält besser, oder so

FAT16, nur das wird er nehmen!

Wenn der Lib-Update nach Entnahme der Karte erfolgt und bei einigen auch nach dem Laden oder runter werfen, dann würde ich auf die SD-Karte als Ursache tippen. Evtl. ein minimaler Wackelkontakt, der den Player zum Neuscan veranlasst, oder die Karte ist nicht schnell genug aktiv.

Chris

Ich hab' seit 2 Wochen die neue FW drauf, seither ist es ruhig geworden mit der ganzen Updaterei.

In Sachen Rockbox werd' ich wohl noch abwarten, bis die Jungs den Status von Unrecommended nach Unstable verschieben.

Nickchen66 schrieb:

Ich hab' seit 2 Wochen die neue FW drauf, seither ist es ruhig geworden mit der ganzen Updaterei.

Bei mir ist es jetzt eigentlich auch gut. Nur noch Update, wenn etwas aufgespielt wurde.

XphX schrieb:

FAT16, nur das wird er nehmen!

Sicher?

Meine SanDisk SDHC-Karte war auf FAT32 vorformatiert. Hatte ich auch nie verändert. Nur neue Daten raufgespielt.Ein Check zeigt auch an, dass das Dateiensystem in Ordnung ist. Wenn ich die Daten auf ein Backup gelegt habe, werde ich die Karte trotzdem neu formatieren und schauen, ob sie dann geht.

Aber wenn nur FAT16 gehen sollte, wüßte ich nicht, wie ich das hinbekommen sollte. FAT16 halte ich auch für veraltert, damit gehen ja nur max 8-Buchstaben-lange Dateiennamen.

Wo hast du denn die Info her, dass nur FAT16 gehen soll? Kann man das überprüfen?

Nattydraddy schrieb:

FAT16 halte ich auch für veraltert, damit gehen ja nur max 8-Buchstaben-lange Dateiennamen.

Das stimmt so glaube ich nicht...

Nickchen66 schrieb:

In Sachen Rockbox werd' ich wohl noch abwarten, bis die Jungs den Status von Unrecommended nach Unstable verschieben.

Ich nutze jetzt wieder Rockbox seit ein paar Tagen. Ich muß sagen: absolut stabil in meinem Anwendungsbereich. Vielleicht gibt es noch Instabilitäten bei den diversen Einstellmöglichkeiten. Wenn man jedoch nur Musik ohne Soundverbieger, etc. hören will, ist das aktuelle Release absolut zuverlässig. Und Schreiben auf dem internen Speicher + microSDHC geht jetzt auch. D.h. man kann jetzt die Datenbank auch nutzen, die beide Speicherinhalte (intern + micro SDHC) zusammen abbildet.

Sehr schön, weiß ich doch direkt womit ich mich nachher zuhause beschäftigen werde

Genauso einfach zu flashen wie die Iriver-Reihe oder muss man tricksen (wie beim Nano z.B.)?

Uriex schrieb:

Genauso einfach zu flashen wie die Iriver-Reihe oder muss man tricksen (wie beim Nano z.B.)?

Es geht nicht ganz so Problemlos, wie bei den iRiver H1XX/3XX-Modellen, da man das Rockbox-Utility zum Installieren der Firmware noch nicht nutzen kann. Aber wenn man mit dem manuellen "Rockboxen" vertraut ist, ist es kein Problem und vergleichbar zur manuellen Rockbox-Installation auf den iRivers.

Ok, also nicht der Akt wie beim Nano.

Da das Rockbox Utility bei mir nicht funktioniert hatte, hatte ich auch den H1xx manuell geflashed, geht da ja zum Glück relativ simpel.

Schön schön, dann wird der Kleine nachher direkt mal bespielt.

Viel Erfolg, wird schon klappen.

Berichte doch bitte mal, ob Du noch auf Probleme gestoßen bist.

Ich muß sagen, ich hab' mich mittlerweile ganz gut an die orginale FW gewöhnt.

Das einzige Rockboxfeature, das ich im Alltag vermisse, ist Crossfade zwischen den Stücken. Das wird aber locker in Schach gehalten von dem Umstand, daß RB von der ohnehin wenig üppigen Batterie-Laufzeit nochmal ein Drittel wegnehmen würde.

Nickchen66 schrieb:

Nattydraddy schrieb: FAT16 halte ich auch für veraltert, damit gehen ja nur max 8-Buchstaben-lange Dateiennamen. Das stimmt so glaube ich nicht...

Stimmt laut meiner Quelle:

...mit dem eine Datei durch einen Namen von 8 Zeichen und eine Erweiterung von 3 Zeichen umschrieben wird. Man nennt dieses System FAT16.

http://de.kioskea.net/contents/repar/fat32.php3

FAT16 ist letztes Jahrhundert. Icg gkaubs nie, dass man eine SDHC-Karte nur mit so einen Dateisystem bespielen kann.

Schaut doch mal bei euch, welche Dateiensysteme ihr auf euren SDHC-Karten ahbt. Wäre nett, wenn einer mir bestätigen könnte, dass bei ihm FAT32 läuft.

Jein. Früher war FAT16 nur 8.3, aber heute werden als Erweiterung auch längere Dateinamen unterstützt.

Auf meinen SDHC Karten läuft übrigens FAT32.

Nattydraddy schrieb:

Schaut doch mal bei euch, welche Dateiensysteme ihr auf euren SDHC-Karten ahbt. Wäre nett, wenn einer mir bestätigen könnte, dass bei ihm FAT32 läuft.

Hallo,

das Format der Speicherkarte ist FAT32.

Ich persönlich würde es jedoch vermeiden, die Speicherkarte (oder auch den internen Speicher des Clip+) als Massespeichermedium, direkt über Laufwerksbuchstaben im Explorer, zu befüllen oder zu formattieren. Das Teil (der Clip+) verhält sich dabei nämlich höchst merkwürdig.

Ich lasse auf dem Clip+ den USB-Verbindungsmodus auf "auto detect", und dann erscheint das Teil auf meinem Windows 7 System eben nicht als Laufwerksbuchstaben, sondern als "Portable Device". Da kann ich die interne als auch die externe Speicherkarte formattieren, aber ich kann kein Dateisystem angeben, noch sehe ich, welches Dateisystem verwendet wird.

Ich würde diese Methode bevorzugen; da kann man nichts falsch machen, weil man keine Auswahl des Dateisystems hat :), und der Clip+ nimmt dann offensichtlich schon das Dateisystem, welches er benötigt.

Wenn ich einen bereits befüllten Clip+ in den Settings umstelle auf "MSC", und den Clip+ dann an den PC anschließe, dann passiert folgendes:

Ich sehe zwar den internen Speicher, als auch die externe Karte, als Laufwerke in meinem Explorer. Der Füllstand (freier Platz) der Karte/des Speichers stimmt ebenfalls. Jedoch sehe ich die Musik-Dateien NICHT. Es sieht so aus, als ob der Clip+ mehr oder weniger komplett leer ist (man sieht nur ein paar Verzeichnisse), aber was genau denn nun auf der Karte den ganzen Platz wegnimmt, sieht man nicht.

(Dies deckt sich mit der Beschreibung eines Posters weiter oben, der sich ebenfalls fragte, was denn da diese 200 KB belegt.)

An dieser Stelle hab ich diesen MSC-Versuch bei mir abgebrochen (bevor ich noch was verhunze), hab den Clip+ getrennt, in den Settings wieder auf "auto detect" umgestellt, und wieder an den PC angeschlossen. Diehe da, die Dateien waren alle wieder da.

Und noch etwas ist mir aufgefallen: wenn man die Karte von Windows aus im "Portable Device"-Modus formattiert, erzeugt der Clip+ schon gleich ein paar Verzeichnisse auf der formattierten Karte. Wahrscheinlich sind dies Verzeichnisse, die der Player braucht oder haben sollte. Wenn man die Karte vom PC aus als Laufwerk formattiert, hat man hinterher diese Verzeichnisse nicht.

Viele Grüße,
Markus

PS: auch dieses ewige, nervige Dauer-Updaten der Media Library macht mein Clip+ nur, wenn ich den Speicher am PC als Laufwerkbuchstaben anspreche.

Lasse ich den Verbindungstyp auf "Portable Device", macht er Media Library Updates wirklich nur dann, wenn ich wirklich was draufgespielt oder gelöscht habe. Offensichtlich hat der Clip+ nur dann "ein Auge drauf" daß sich was getan hat oder auch nicht, wenn man diesen Verbindungstyp wählt. Als MSC hat der Player diese Überwachungsfunktion anscheinend nicht, und so aktualisiert er sicherheitshalber andauernd die Media Library. (So reime ich mir das jedenfalls zusammen aufgrund meiner Beobachtungen.)

Das liegt daran, dass man nur die Dateien sieht, die im jeweiligen Modus raufgeladen wurden. Also wenn man sich für einen Modus entschieden hat, einfach nur diesen benützen (vorher auf den anderen wechseln und dort die Musik löschen).

Ich bin aber im MSC-Modus und habe trotzdem keine andauernden Library-Updates. Ich vermute eher, dass es mit verschiedenen microSDHCs zu tun hat.

McMusic schrieb:

Ich bin aber im MSC-Modus und habe trotzdem keine andauernden Library-Updates. Ich vermute eher, dass es mit verschiedenen microSDHCs zu tun hat.

Verdammt. Wär' ja auch zu einfach gewesen....

McMusic schrieb:

Ich vermute eher, dass es mit verschiedenen microSDHCs zu tun hat.

Meine ist eine 16-GB Karte von Sandisk. Habe extra eine vom gleichen Hersteller wie dem Clip gekauft.

Mit Windows probieren klingt gut, aber erst, wenn ich wieder einen funktionierenden Windows PC habe.

Auf meinen iMac dürfte nur der MSC-Modus gehen.

Nattydraddy schrieb:

Meine ist eine 16-GB Karte von Sandisk.

Die ist bei mir auch im Einsatz.

Man kann ja mal die Karte weglassen und schauen, obs dann immer noch ständige Updates gibt.

McMusic schrieb:

Viel Erfolg, wird schon klappen. Berichte doch bitte mal, ob Du noch auf Probleme gestoßen bist.

So gestern Abend noch auf die schnelle aufgespielt... Ganze 2 Minuten hats gedauert, war noch wesentlich einfacher als beim H120, bei dem ich mit dem Bootimage ein paar Probleme hatte.

Bin auf jeden fall mal wieder und immernoch begeistert von Rockbox... Wesentlich übersichtlicher als das ureigene BS und endlich wieder Crossfade.

Bisher keinerlei Abstürze und wenn die Akkuanzeige nicht spinnt auch kein großer Unterschied zur Standard-Firmware was die Laufzeit angeht.

Wenn man den USB-Modus von auto auf MSC stellt, dann erledigt sich das ständige Update Problem. War jedenfalls bei mir so

endlezz schrieb:

Wenn man den USB-Modus von auto auf MSC stellt, dann erledigt sich das ständige Update Problem. War jedenfalls bei mir so ;)

Ah, das könnte natürlich auch der Grund sein und erklärt, warum ich das Problem nicht hatte.

Es gibt auch noch OS-bedingte Unterschiede, wenn man das Gerät als Massenspeicher nutzt. Vista etwa scheint - im Gegensatz zu älteren Fenstern - IMMER irgendwas draufzuschreiben, selbst wenn man sonst keine Dateien hinzugefügt oder verändert hat.

audiophilanthrop schrieb:

Es gibt auch noch OS-bedingte Unterschiede, wenn man das Gerät als Massenspeicher nutzt. Vista etwa scheint - im Gegensatz zu älteren Fenstern - IMMER irgendwas draufzuschreiben, selbst wenn man sonst keine Dateien hinzugefügt oder verändert hat.

Stimmt bei mir nicht (Vista Ultimate 64Bit).

McMusic schrieb:

audiophilanthrop schrieb: Es gibt auch noch OS-bedingte Unterschiede, wenn man das Gerät als Massenspeicher nutzt. Vista etwa scheint - im Gegensatz zu älteren Fenstern - IMMER irgendwas draufzuschreiben, selbst wenn man sonst keine Dateien hinzugefügt oder verändert hat. Stimmt bei mir nicht (Vista Ultimate 64Bit).

Hängt vielleicht nicht so sehr mit Windows selbst zusammen, sondern mit den Programmen/Services, die man installiert hat. z.B. Diskeeper, wenn er so konfiguriert ist, daß er angehängte Devices automatisch mit-defragmentiert.

(So was hab' ich zum Beispiel.)

(Jetzt wo ich drüber nachdenke, ist das bei mir vielleicht der Grund für den Media-Refresh, wenn ich das Laufwerk als MSC anmelde.... bei Anmeldung als "Portable Device" kommt Diskeeper ja nicht im Direktzugriff auf das Drive dran.)

Viele Grüße,
Markus

Nur so btw, defragmentieren ist unnötig und bringt keinen Gschwindigkeitsvorteil.

XphX schrieb:

Nur so btw, defragmentieren ist unnötig und bringt keinen Gschwindigkeitsvorteil.

Jep, moderne Dateisysteme wie NTFS, HFS+ und ext4 defragmentieren automatisch die Dateien.

Defrag Programme sind Relikte aus der FAT Zeit, mit denen aber immer noch versucht wird Geld zu verdienen.

Und bitte nicht den Flash Speicher des Clip+ defragmentieren.

Darkos schrieb:

Jep, moderne Dateisysteme wie NTFS, HFS+ und ext4 defragmentieren automatisch die Dateien.

Zumindest in Bezug auf NTFS ist das nicht richtig.

Den Clip und alles andere mit SSD sollte man nicht defragmentieren weil es erstens bei SSDs wurscht ist, wie die Daten angeordnet sind und zweitens die Lebensdauer verkürzt wegen der endlichen Anzahl von Schreibzyklen.

j!more schrieb:

Zumindest in Bezug auf NTFS ist das nicht richtig.

Jupp. NTFS defragmentiert von sich aus nichts.

Viele Grüße,
Markus

Ab Vista werden Startdateien automatisch "optimiert", aber generell bringt das Deframentieren keinen Geschwindigkeitsvorsprung. So wars gemeint.

XphX schrieb:

Ab Vista werden Startdateien automatisch "optimiert", aber generell bringt das Deframentieren keinen Geschwindigkeitsvorsprung. So wars gemeint.

Meine Erfahrung ist da anders. Ich bin Software-Chefentwickler für ein großes Softwareprodukt. Ein wirklich großes. Das Zusammenkompilieren aus den >300.000 einzelnen Sourcedateien dauert auf einem i7 Quadcore Rechner mit 64bit und 12GB RAM ca. 5 Stunden. Diesen Vorgang muß ich einmal die Woche machen, mit aktualisierten Quelldateien. Wenn ich keine Festplattendefragmentierung verwende, dauert dieser Prozess nach geraumer Zeit gerne auch mal 5 1/2 Stunden. Mit permanentem Defragmentationsprozess im Hintergrund (besonders über Nacht) bleibt das dauerhaft bei den 5 Stunden.

Hierbei ist es unerheblich ob Windows XP 32bit oder Windows 7 64bit, oder alles dazwischendrin.

Viele Grüße,
Markus

Wird die Geschwindigkeit nicht durch die CPU limitiert? Ich hab nichts mit kompilieren zu tun, doch dachte ich immer, dass die CPU ausschlaggeben ist. Ansonsten müsste ja die Fesplatte voll ausgelastet sein...

mkr_krausm schrieb:

Wenn ich keine Festplattendefragmentierung verwende, dauert dieser Prozess nach geraumer Zeit gerne auch mal 5 1/2 Stunden. Mit permanentem Defragmentationsprozess im Hintergrund (besonders über Nacht) bleibt das dauerhaft

Naja, das sind 10% länger.
Auf der Zeitskala merkbar, aber wenn ein Prozess 3 Sekunden oder 3,3 Sekunde dauert, das merkt man nicht.
Sprich: 10% mehr sind im alltäglichen Umgang nicht spürbar.

@XpjX: kommt drauf an.

Viele Leute sind heute mit einem 1.6GHz Atom zufrieden. In der Vergangenheit hatte ich deshäufigeren festgestellt, das Notbookbesitzer im Netzbetrieb und falschen Powermanagementprofil mit niedrigen CPU-Takt arbeiteten und es nicht merkten.
Für den normalen Haushaltscomputer reicht erstaunlich wenig Rechenleistung.

XphX schrieb:

Wird die Geschwindigkeit nicht durch die CPU limitiert? Ich hab nichts mit kompilieren zu tun, doch dachte ich immer, dass die CPU ausschlaggeben ist. Ansonsten müsste ja die Fesplatte voll ausgelastet sein...

Ab einer gewissen Menge an Dateien, die für einen Kompiliervorgang benötigt werden, spielt durchaus die Platte eine Rolle. Und ja, die Platte *ist* bei mir während dieses Vorgangs voll ausgelastet. Bei diesem Kompilierprozess entstehen viele Temporärdateien mit Größen von 100 MB und mehr. Der Rechner ist dabei so "dicht" daß es eine Minute braucht, wenn ich meine Email währenddessen aufstarten will.

Wenn man nur ein kleines Hobby-VB-Programm mit 5 Dateien zusammentackert, merkt man davon natürlich nichts.

Viele Grüße,
Markus

ZeeeM schrieb:

Naja, das sind 10% länger. Auf der Zeitskala merkbar, aber wenn ein Prozess 3 Sekunden oder 3,3 Sekunde dauert, das merkt man nicht. Sprich: 10% mehr sind im alltäglichen Umgang nicht spürbar.

Das kommt auf die Definition "alltäglichen Umgang" an. Für mich IST diese Arbeit alltäglich.

Ich habe ja nicht behauptet, daß *jeder* die Auswirkung von Defragmentation spürt. Wenn einer nur Lieder in iTunes hört, wird er den Effekt nie bemerken.

Es ist aber falsch zu behaupten "generell bringt das Deframentieren keinen Geschwindigkeitsvorsprung".

Das sind zugegebenermaßen sehr extreme Anwendungen, die 99% aller PC-Benutzer wohl niemals fahren werden. Es gibt aber eben Fälle, wenn auch vereinzelt, wo sich ein Defragmentierungsprogramm durchaus positiv bemerkbar macht.

Wozu ich mich jedoch beschwichtigend hinreißen lassen kann ist, daß der durchschnittlich fehl-informierte PC-Anwender den Nutzeffekt eines Defrags um Zehnerpotenzen überschätzt.

Viele Grüße,
Markus

mkr_krausm schrieb:

Wozu ich mich jedoch beschwichtigend hinreißen lassen kann ist, daß der fehl-informierte PC-Anwender den Nutzeffekt eines Defrags um Zehnerpotenzen überschätzt. Viele Grüße, Markus

Bääähhhh... jetzt hatte ich schon einige Zeilen geschrieben und dann erübrigen die sich.

Wenn Ottonormalverbraucher sein System wieder richtig flott machen will, dann heisst das Neuinstallation.
Ich empfehle denen immer eine externe HD und Acronis Trueimage. Daten regelmässig sichern, von der Grundinstallation ein Image zur Hand und der Frühjahrsputz ist halb so schlimm.

XphX schrieb:

Ab Vista werden Startdateien automatisch "optimiert"

Dieses "optimieren" ist aber kein physikalisches Bewegen der Dateien auf der Platte, sondern Windows lädt sich nach oder während dem Booten diese Startdateien schon vorsorglich in den Cache, damit auf diese dann bei Benutzung nicht mehr so lange gewartet werden muß. (Nennt sich glaube ich "prefetch".)

Windows 7 ist in dieser Beziehung sogar lernfähig. Es merkt sich im Laufe einer Sitzung, mit welchen Dateien der Benutzer häufig arbeitet, und lädt diese ebenfalls beim Start in den Cache.

Das nützt aber nichts, wenn man sequentiell auf >25 GB an Dateien zugreifen muß. Irgendwann geht da dem größten Cache die Puste aus. Und die Festplattenkopfbewegungen, die die Platte dann vollziehen muß, lassen sich sogar messen (Häufigkeit und benötigte Zeit). z.B. mit MS Tools wie "Xperf". Damit ist der Erfolg eines Defrags sogar meß- und protokollierbar.

Viele Grüße,
Markus

ZeeeM schrieb:

mkr_krausm schrieb: Wozu ich mich jedoch beschwichtigend hinreißen lassen kann ist, daß der fehl-informierte PC-Anwender den Nutzeffekt eines Defrags um Zehnerpotenzen überschätzt. Viele Grüße, Markus Bääähhhh... jetzt hatte ich schon einige Zeilen geschrieben und dann erübrigen die sich. Wenn Ottonormalverbraucher sein System wieder richtig flott machen will, dann heisst das Neuinstallation. Ich empfehle denen immer eine externe HD und Acronis Trueimage. Daten regelmässig sichern, von der Grundinstallation ein Image zur Hand und der Frühjahrsputz ist halb so schlimm. ;)

Jaaa oder einfach nicht tausend Programme beim Start in den System Tray laden lassen. Ich seh' das bei meinem Vater, was der sich nach einer Woche immer alles hat installieren lassen...

Viele Grüße,
Markus

Acronis ist nicht meine prominenteste Software, aber mit Sicherheit die wichtigste.

Nickchen66 schrieb:

Acronis ist nicht meine prominenteste Software, aber mit Sicherheit die wichtigste.

Ich mach' so viel es geht in virtuellen Maschinen, und mach' hinterher einfach immer die VM platt. Oder ein Rollback auf einen vorherigen Zustand.

Viele Grüße,
Markus

mkr_krausm schrieb:

j!more schrieb: Zumindest in Bezug auf NTFS ist das nicht richtig. Jupp. NTFS defragmentiert von sich aus nichts. Viele Grüße, Markus

Also hinkt MS den anderen Dateisystemen hinterher.

Komischerweise konnte sich auch Apple nicht dazu entschließen, mit 10.6 ZFS einzuführen. Die Firmen kleben so an ihren Systemen.

Zurück zum Thema: Habe gestern meinen Clip+ mit meinem frischen DT880 Pro gekoppelt -> Fürs leise Musikhören würde es reichen, trotz der 250 Ohm.

Darkos schrieb:

Also hinkt MS den anderen Dateisystemen hinterher. Komischerweise konnte sich auch Apple nicht dazu entschließen, mit 10.6 ZFS einzuführen. Die Firmen kleben so an ihren Systemen.

In Produktivsystemen sind die anderen von Dir genannten Filesysteme nicht sehr weit verbreitet. Das sollte Dir zu denken geben, zusammen mit Deiner Apple betreffenden Festellung. Vielleicht ist das gar nicht so komisch, sondern vorsichtig im besten Sinn.

mkr_krausm schrieb:

Meine Erfahrung ist da anders. Ich bin Software-Chefentwickler für ein großes Softwareprodukt. Ein wirklich großes. Das Zusammenkompilieren aus den >300.000 einzelnen Sourcedateien dauert auf einem i7 Quadcore Rechner mit 64bit und 12GB RAM ca. 5 Stunden. Diesen Vorgang muß ich einmal die Woche machen, mit aktualisierten Quelldateien. Wenn ich keine Festplattendefragmentierung verwende, dauert dieser Prozess nach geraumer Zeit gerne auch mal 5 1/2 Stunden. Mit permanentem Defragmentationsprozess im Hintergrund (besonders über Nacht) bleibt das dauerhaft bei den 5 Stunden.

mkr_krausm schrieb:

Ab einer gewissen Menge an Dateien, die für einen Kompiliervorgang benötigt werden, spielt durchaus die Platte eine Rolle. Und ja, die Platte *ist* bei mir während dieses Vorgangs voll ausgelastet. Bei diesem Kompilierprozess entstehen viele Temporärdateien mit Größen von 100 MB und mehr. Der Rechner ist dabei so "dicht" daß es eine Minute braucht, wenn ich meine Email währenddessen aufstarten will.

Und ihr kompiliert das auf deinem Arbeitsplatz-PC? Schon mal über einen dedizierten Server dafür nachgedacht? Da gibt es ja dann noch diverse Software zur Verwaltung des Build-Prozesses.

Ihr solltet mal über eine SSD nachdenken, die sollte das Kompilieren spürbar beschleunigen.

rille2 schrieb:

Und ihr kompiliert das auf deinem Arbeitsplatz-PC? Schon mal über einen dedizierten Server dafür nachgedacht? Da gibt es ja dann noch diverse Software zur Verwaltung des Build-Prozesses.

Das haben wir außerdem, nur keine Sorge. Buildforge, etc.
Da ich aber 6 solcher PC-Systeme alleine für mich habe, kann ich mir den Luxus leisten, auch mal selbst zu kompilieren.

Ich arbeite die meiste Zeit von zu Hause. Dank Telefon, Internet, Email, Videokonferenzen ist das mittlerweile sehr gut möglich. Mein Team ist über die ganze Welt verstreut (USA, China). Meine Wohnung sieht aus wie ein Rechenzentrum.

(Der Nachteil ist, daß ich solche rein deutschen Feitertage wie den gestern knicken kann.)

Viele Grüße,
Markus

Markus, das ist ja uuur cool