Beiträge von Daedalus

    Hallo,

    ich habe 2 Rechner mit genau den gleichen Prozessoren (1x Quad 2.4 GHz, 1x Duo 3.0 GHz) - Arbeiten tu ich eigentlich lieber auf dem Quad. Beim kompilieren von Software, sofern das Buildsystem das unterstützt (bei make unter Linux zumindest kein Problem) ist der Quad doch schneller, trotz der geringeren Taktfrequenz. Allerdings hat Intel ja vor kurzem neue Core 2 Quads angekündigt, die in 45nm-Technologie gefertigt werden, die müssten eigentlich bald lieferbar werden. Sollen zumindest bis auf das Spitzenmodell nicht teurer als die alten Quads (Q6600, Q6700) werden, evtl. lohnt sich da noch etwas Warten.

    Cinema4D kenne ich nicht, wenns aber Multithreading unterstützt würde ich auch da vermuten, dass der Quad schneller ist.

    Zur Sache mit dem RAM: Die Chipsets für die Core 2 Prozessorfamilie haben alle 2 Speicherkanäle. Die FSB-Frequenzangaben vom Prozessor sind nicht die gleichen, die der Speicher haben muss! z.B. für einen 1066 MHz FSB Prozessor reichen zwei DDR2-667 oder DDR2-800 Speichermodule, die dann in die richtigen Slots am Mainboard reinmüssen (normalerweise farblich gekennzeichnet bzw . im Handbuch beschrieben). Alles darüber ist soweit ich weiss hauptsächlich für die Overclocker gedacht, damit die über Erhöhen des FSB die Prozessortakfrequenz steigern können, was ja automatisch den Takt vom RAM erhöht...

    Ich kenne zwar Chello nicht, aber das sollte problemlos möglich sein. Die MAC-Adresse bezieht sich soweit ich weiss nur auf das Gerät, welches sich beim Provider einwählt, in diesem Fall also der Router.

    Wie gesagt, die Chello-Geräte kenne ich nicht, zuhause habe ich inode xDSL mit einem Linksys WRT54GL, der hat einen eingebauten Switch und drauf läuft ein DHCP-Server, heisst also man kann beliebig neue Rechner anstecken, die automatisch eine IP-Adresse und DNS-Daten zugeteilt bekommen und somit auch ins Internet können.

    Wenns bei der Konfiguration deiner Freundin jetzt hingegen so ist, dass sich die Rechner dort über den Router separat einwählen ("VPN-Verbindung"), dann funktioniert das evtl. nicht so einfach.

    Hallo,

    lässt sich eine normale (nicht Enterprise) - Distribution mit einem aktuellen Intel Xeon 8-Core System betreiben?

    Konkreter: es geht um ein System mit Tyan Tempest i5400XT (S5396) Mainboard, zwei Intel Xeon E5450 Prozessoren, 8 GB RAM. Darauf soll ein aktuelles (wahrscheinlich Debian oder Ubuntu) System drauf.

    Laut Kompatibilitätsliste des Mainboardherstellers wird z.B. Red Hat Enterprise Linux 5.0 (damit vermutlich auch Kompatibilität zu CentOS gegeben) und SuSE Enterprise Server 10 unterstützt.

    Kann man daraus jetzt schliessen, dass auch andere (neuere) Distributionen mit dem System klarkommen? Oder sind in den Enterprise-Versionen für diese Boards irgendwelche unfreien Bestandteile enthalten, die andere Distributionen nicht beinhalten (z.B. Treiber für einige Hardwarebestandteile)

    hatte so eine ähnliche Warnung bei Funktionen der libxml2...

    du könntest folgendes probieren:

    Code
    ora_oci_query((unsigned char *)"SELECT blah FROM foo;");

    bzw.

    Code
    ora_oci_query((text *)"SELECT blah FROM foo;");

    hat meine warnings damals eliminiert

    Also der letzte Teil ist von mir bearbeitet, habs eben, wie man sieht, auch schon versucht, selbst zu mappen, aber hab davon leider gar keine Ahnung :p


    Wenn deine Windows-XP-Partition sda5 ist, versuche folgendes:

    Code
    title Windows XP
    rootnoverify (hd0,4)
    makeactive
    chainloader +1

    Wichtig ist dabei, dass GRUB bei den Festplatten und Partitionen bei Null zu zählen beginnt, daher ist z.B. sda5 = hd(0,4), sdb3 = hd(1,2) usw.

    Mir ist auch aufgefallen, dass der Mountpoint der Windows Partition in /media/sda5 ist, müsste das nicht /dev sein? Also könnts am Mountpoint liegen?1


    GRUB hat mit den Mountpoints in Ubuntu eigentlich nichts am Hut. /media/sda5 passt auch, über /dev/sd* wirst du nicht auf das Filesystem zugreifen können, das ist nur das zugehörige Device-File (der entsprechende Treiber greift darüber auf die Festplatte/Partition zu)

    Hallo,

    dieses Projekt ist wie geschaffen für den Einstieg in das Reich der Microcontroller :D

    Habe vor einiger Zeit die Microcontroller-VL absolviert und da gab es ein wirklich sehr ähnliches Beispiel: Durch Drücken eines Tasters sollte ein LED-"Lauflicht" immer um einen Schritt weitergeschaltet werden. War damals in Assembler zu programmieren (erste Runde der VL) und auch wirklich einfach.

    Empfehlenswert ist meiner Meinung nach trotzdem, sich nicht lange mit Assembler abzugeben und möglichst schnell auf einen C-Compiler umzusteigen (wobei ich AVRStudio nicht kenne, arbeite immer wie in der Microcontroller-VL und Embedded Systems Engineering-Übung mit GCC und der AVR-libc).

    Unter Linux gibts auch Ultra-Low-Cost-Alternativen, das Ding zu programmieren (Programmieradapter besteht im wesentlichen aus einem 9-poligen Flachkabel, 9-pin D-Sub Stecker, der an die serielle Schnittstelle des Rechners angeschlossen wird und einem Stecker der an den Controller angeschlossen wird, alles für wahrscheinlich < 5 Euro beim Conrad zu haben), programmiert wird dann z.B. mit UISP. Möglicherweise geht das alles auch unter Windows, da ich das aber nie versucht habe, kann ich das nicht mit Sicherheit sagen.

    Die Implementation der Controllersoftware wäre auch kein Problem: Schon der ATmega16 hat 3 externe Interrupts, also kann jeder der 3 Taster in deiner Skizze an einen Interrupt-Pin angeschlossen werden. Damit erreicht man, dass bei jedem Druck auf den Taster die dazugehörige Interrupt-Service-Routine ausgeführt wird, in der dann einfach eine Variable inkrementiert wird und die LEDs aktualisiert werden :)

    Ideal zum Herumprobieren ist sicher auch ein Microcontroller-Labkit (Infos auf der LVA-Homepage) - bei diesem Board sind zahlreiche "Sicherheitsfunktionen" wie Schutzdioden, Strombegrenzungswiderstände usw. eingebaut, so dass man es auch bei falscher Beschaltung nicht leicht totkriegt. Kann man sich wie gelbasack schon geschrieben hat am Institut unter Anleitung selbst zusammenlöten oder ein fertiges gegen einen Einsatz ausborgen bzw. kaufen.

    Es ist jedoch davon auszugehen, dass ein Track, der vom Studiomaterial erzeugt wird, und dann z.B. mit 1 mbit encodet wird, wesentlich besser sein kann, als eine CD. Mit "near-CD" Qualität suggeriert man ja nur, dass die CD das Optimum ist. Und das ist sie nicht. Und viele Musikfans tun so, als ob ein mp3 zu Ohrenkrebs führt, und eine CD eine wohltuende Schalmei.


    Ich glaub wir reden über verschiedene Dinge. Da ich vor einiger Zeit 2 Lieder über den iTunes Music Store gekauft habe und seither DRM-"geschützte" Musik komplett verweigere, weiss ich nicht, welche Bitraten dort aktuell verwendet werden. Damals wars 128 kBit/s AAC, und auch die Tatsache, dass der Begriff "near-CD-Qualität" suggeriert, dass die CD das Optimum ist ändert nix daran, dass das 128 kBit/s AAC eben "near-CD" ist...

    Wenns einen Online-Store gibt, bei dem man wirklich Musik mit 1 MBit/s verlustbehaftet komprimiert bekommt, würd ich vielleicht - sofern ich eine Möglichkeit habe, mich dem DRM zu entledigen, ohne eben wieder Qualitätsverlust in Kauf nehmen zu müssen - statt CDs dort meine Musik kaufen...

    welches audiosystem hast du damit du dass hoerst?


    z.B. Auto (Standard - Audi Symphony Sonderausstattung in meinem Fall)
    zu Hause Sennheiser-Kopfhörer (mit denen hör ich am liebsten Musik, mit ordentlichen sind auch die Ohrschmerzen nach längerem Hören quasi nicht vorhanden :) )

    Als ob eine CD verlustfrei wär. Auf dem Platz, den ein unkomprimierter Track belegt, könnte man locker einen komprimierten 32 Bit, 96 kHz Track unterbringen.

    Das Märchen von der ach-so-perfekten CD ist lächerlich. Die meisten Leute hören eh keinen Unterschied, schon gar nicht mit den mickrigen Stöpseln in der lärmenden U-Bahn.


    Klar ist eine Audio-CD nicht auf dem Niveau von Studioaufnahmen, die wohl zur Herstellung der CD verwendet werden, hat ja aber eh keiner behauptet. Trotzdem gilt z.B. bei AAC eine Bitrate von 128 kBit/s immer noch "nur" als "CD-nah", was ich als jetzt mal als "minimal schlechter als CD-Qualität" interpretiere.

    Und wenn ich eben nicht zu der von dir genannten Gruppe der "meisten, die eh keinen Unterschied hören" zähle, und ich für ca. das gleiche Geld einen Datenträger bekomme, der sich im Gegensatz zu dem iTunes-Store-AAC wirklich fast überall ohne Probleme abspielen lässt, was werd ich da lange überlegen, wem ich mein Geld gebe?

    inwiefern leidet beim legalen musikdownload die qualitaet der musik ?


    Ich vermute damit ist die verlustbehaftete Kompression gemeint (MP3, Ogg Vorbis, WMA, ...) im Vergleich zu dem verlustlos auf einer CD gespeicherten Musik (oder eben verlustlos komprimiert wie FLAC, Apple Lossless, ...). Hier sagt zwar fast jeder etwas anderes, ich selbst bilde mir aber auch ein, da mit einem guten Audiosystem einen Unterschied zu hören...

    Danke für die Ratschläge!

    habe in der Zwischenzeit etwas mit autoconf/automake herumgespielt, nach einigen :cuss:-Erlebnissen geht jetzt das simple Kompileren das vorher auch schon gegangen ist...

    werde mir wirklich mal CMake anschauen, schlimmer kanns nicht mehr werden :D

    Verwundert mich nur warum so viel noch immer mit autoconf/automake gearbeitet wird, fast jedes "kleinere" softwarepaket hat halt das obligatorische ./configure && make && make install dabei...

    Hallo,

    ich spiele mit dem Gedanken, ein kleines Kommandozeilen-Tool, welches bisher einfach über "make" kompiliert wird, auf eine autoconf/automake - Buildvariante umzustellen.

    Das Programm besteht aus ein paar Source-Dateien (C++) und den dazugehörigen Headers und verwendet ein paar ganz simple Textdateien zur Konfiguration. Bisher ist in der Makefile also einfach ein Befehl beim install-Target dabei, der diese Konfigurationsdateien in ein Unterverzeichnis von /etc kopiert und beim Kompilieren ein Makro auf den kompletten Pfad dieses Verzeichnisses setzt, welches dann zum Öffnen der Dateien verwendet wird.

    Ich will das jetzt eleganter lösen:

    • Benutzer führt ./configure mit einer benutzerdefinierten Option (sowas wie ./configure --prefix=/usr/local --configdir=/bla)
    • Das configure-Skript fügt dann in der generierten config.h eine Präprozessor-Direktive mit diesem Pfad hinzu (#define CONFIGFILE=/bla)
    • make kompiliert das ganze
    • make install kopiert das Programm und die dem Source-Code beiliegenden Default-Konfigurationsdatei in das so angegebene Verzeichnis

    Jetzt bin ich aber als autoconf/automake-Noob relativ ratlos... habe mich durch ein paar Tutorials und die offizielle Dokumentation gequält, aber leider keine Anleitung zu so einem Vorhaben gefunden. Kann mir da einer Tips bzw. einen Link zu so einem Tutorial geben?

    Danke im Vorraus!

    Jetzt steh sich vor dem Problem, dass gcc nicht funktionieren will.
    schreibt immer er findet stdio.h nicht...


    Eventuell mal folgenden Befehl laufen lassen:

    Code
    sudo apt-get install build-essential

    Das sollte eigentlich das meiste zum Compilieren von Software benötigte Zeug installieren

    Welche Ubuntu-Version verwendest du denn?

    http://archlinux.org/ ist eine schoene mischung aus gentoo und slackware. die meisten pakete (die immer sehr aktuell sind) werden in ihrer standardkonfiguration ausgeliefert, d.h. mehr oder weniger ist viel handarbeit angesagt. falls ein gewuenschtes paket nicht in den repositories existiert kann man es einfach in der distributionseigene paketverwaltung (pacman) im emerge-style selbst kompilieren und installieren.
    ist nicht umbedingt sooo zach wie gentoo aber der lerneffekt ist trotzdem da, auch wenn nicht so hoch ;) als einsteiger distribution ist es nicht zum empfehlen; da waere ubuntu wohl auch meine erste empfehlung (suse saugst :x)


    Bin momentan auch bei Arch hängen geblieben :)

    Wollte das System ursprünglich wegen der rolling distribution ausprobieren und um etwas dazuzulernen, habe eine Installation vernichtet, die zweite ist mittlerweile zum Produktivsystem geworden und hat Ubuntu "verdrängt". Würde einem weniger erfahrenen Linux-Anwender aber auch Ubuntu ans Herz legen, bei Arch muss man wirklich viel selbst einrichten (z.B. hat man nach der Grundinstallation gerade mal ein Basissystem im Textmodus laufen, welches über die Paketverwaltung genau dort erweitert wird, wo man bestimmte Software braucht)...

    Will jetzt nachdem ich Arch recht gut kenne nix anderes mehr haben :D

    btw. die Software zum Kompilieren eigener Pakete ist nicht pacman (das ist der Paketmanager), sondern ABS/makepkg </klugscheiss> ;)