-
Gesamte Inhalte
403 -
Benutzer seit
-
Letzter Besuch
Inhaltstyp
Profile
Forum
Downloads
Kalender
Blogs
Shop
Alle Inhalte von SystemError
-
Hmmm... Also ich mache das eigentlich immer mit dem "sizeof" Operator? #include <iostream> using namespace std; main() { int b; char a[97]; cout << ((unsigned) &-((unsigned) &a) << endl; cout << sizeof(a) << endl; } [/code] Das ganze liefert auf einem AthlonXP mit FreeBSD als OS GCC 3.4.2 folgendes Ergebnis: [code] bash-2.05b$ ./testa.bin 124 97 bash-2.05b$ Der sizeof Operator leifert mir die zu erwartenden 97 Byte; dein Ausdruck zur Adressberechnung nicht. Kann es sein das dieser Ausdruck fehlerbehaftet ist? Verstehe ich es richtig dass Du die Differenz der Adresse des Integer Wertes und der Adresse des Arrays von einander abziehst? Macht das keinen Sinn oder verstehe ich das was falsch? Bye SystemError, blutiger C++ Anfänger
-
Hmmm, also ich würde dir das Kommandozeilen Tool wget ans Herz legen: http://www.gnu.org/software/wget/wget.html Auf Windows Systemen läuft das auf alle Fälle aus einer CygWin Umgebung heraus; es gibt auch eine Windows native Variante, habe ich aber nie getestet. Vorteil an einem KommandozeilenTool ist halt dass Du das Ding leicht skripten kannst. So von wegen 1 Sktipt das viele, viele wgets loslaufen lässt... Bye SystemError
-
Nope. Dem ist definitiv nicht so. Der Produktname ist einfach nur verwirrend. Stell Dir die Dinger einfach wie ein "Monster"Diskettenlaufwerk vor. Bye SystemError
-
Nein. Bei den IomegaZipDrives handelt es sich um Wechselplattenlaufwerke der Firma Iomega; mit WinZip // PkZip Kompression haben die Dinger nichts zu tun... Hmmm, irgendwo sollte ich noch ein USBZipDrive rumfahren haben; aber im Zeitalter der USBSticks und USBPlatten werden die Dinger ja nicht mehr wirklich oft verwendet. ;-) Quellen: 1.) http://de.wikipedia.org/wiki/ZIP_%28Dateiformat%29 2.) http://de.wikipedia.org/wiki/Iomega_Zip Bye SystemError
-
Ähmmm... Ist es nicht eher so dass viele große Firmen gerade im Bereich unternehmenskritscher ServerSysteme traditionell auf Unix setzen? Und dass eben diese Firmen mit Linux ein viel kleineres Problem haben weil Linux ja auch irgendwie "unixoid" ist? Linux tummelt sich nicht erst seit Gestern in den Rechenzentren großer Konzerne. Stichwort Oracle & DB2 UDB Datenbanken auf Linux für x86... Von den kommerziellen Unix Derivaten ganz zu schweigen. Bye SystemError
-
Hmmm, also ich habe immer rdesktop bzw. tsclient benutzt. Wobei tslcient nur ein hübsches Frontend für rdesktop, vnc & co ist. Bei rdekstop handelt es sich um einen RDP Client. Das hat jetzt natürlich zunächst mal nix mit KDE zu tun. Hoffe der Hinweis ist torzdem irgendwie hilfreich. ;-) By the way: Welche Linux Distribution? Bye SystemError
-
Ja, auf alle fälle simpler als sich mit der .netrc rumzuschlagen. scp ist aber auch nicht wirklich kompliziert zu benutzen: [peeter@deinpc ~]$ scp deine.datei user@hostname:/dein/pfad/deine.datei Bye SystemError
-
Laptop mit Einwahlmöglichkeit via GSM oder ISDN einpacken? Hmmm, ok das sind dann etwas erschwerte Randbedingungen, sollte aber trotzdem mit der entsprechenden Vorbereitung kein Problem sein.
-
Moin, machst Du [milkakuh@kuhstall ~]$ man netrc. Funktioniert prima mit den üblichen FTPClients unter Linux; keine Ahnung was ncftp damit so macht. Anbei eine beispielhafte .netrc Datei: [FILE] machine nocheinkuhstall login milkakuh password muuuuh macdef init put milka.txt quit [/FILE] Diese Datei sollte im Homeverzeichnis des Benutzers liegen, der das FTPScript ausführen will; die Rechte sollten auf 600 stehen; jeder FTPLogin zum Rechner "nocheinkuhstall" wird automatisch mit dem hinterlegten Benutzername und Passwort durchgeführt, anschliessend wird noch das "init" Makro ausgeführt, welches die Datei "milka.txt" überträgt. Mit der netrc solltest Du aber aufpassen; zum einen stehen Benutzername und Passwort im Klartext drin; zum anderen beeinflusst eine .netrc Datei alle FTP Logins des entsprechenden Benutzers zu den jeweiligen Zielrechnern. Man kann sich eine ".netrc" natürlich auch zur Laufzeit vom ShellSkript erzeugen lassen und nach erfolgter Benutzung wieder löschen. Abschliessend möchte ich noch anmerken, dass ich für skriptgesteuerte Dateiübertragungen scp oder über SSH getunneltes RSync empfehle. Statt Passwörten dann PublicKeys verwenden; das sollte dann eine Nummer sicherer sein. ;-) Bye SystemError
-
Studieren aber was ist sinnvoll ??
SystemError antwortete auf stupid_Invader's Thema in Ausbildung im IT-Bereich
Hohoho, da muss ich chickie nun wirklich recht geben. Frag doch mal einen WINF wie man Physik schreibt... ;-) Bye SystemError -
Brutto? Netto? Was für ein BruttoJahresGehalt incl. ALLER Zulagen schwebt Dir denn so vor? Bye SystemError
-
Nein. Schau Dir doch mal die intelbasierten ServerBauReihen von HP oder IBM an... ...da sind Treiber für Linux einfach kein Thema sondern Standard. Und irgendwelche USB-Modems für die es eben keine Treiber für Linux gibt sind mir auf meinen Server herzlich egal. Und ausserdem: Wenn ich mir einen Server für den späteren Einsatz von Linux zulege dann kläre ich doch im Vorfeld ab ob die gesamte Software // Hardware Konstellation passt, oder? Was für kommerzielle Software kaufst Du? Natürlich sind MicrosoftProdukte in der Regel für die Windows Plattform bestimmt. Aber die Datenbankprodukte von Oracle oder IBM? Oder MQSeries und WebSphere von IBM? Oder der SAP Kram? Oder diverse kommerzielle Hochverfügbarkeitsprodukte? Oder kommerzielle BackupSoftware? Da ist eine LinuxVersion einfach Pflicht. Die IBM Produkte bekomme ich mittlerweile ja schon für Linux auf nonIntelPlattformen... Vorsicht mit Studien. Kannst gerne den Link posten. Aber ist es nicht merkwürdig dass alle von Microsft gesponserten Studien den Einsatz von Microsoft Windows empfehlen und alle von IBM gesponserten Studien u.a. den Einsatz von Linux? Hmmm... warum nur? Ich werde ganz sicher NICHT Emulatoren wie Wine als Argument für Linux ins Feld führen. Imho hat sowas a.) auf einem Server nix verloren b.) nichts mit den Stärken von Linux zu tun *lol* Der ist gut.... ...was mir zum Thema Datenbankserver aus dem Mediamarkt im Unternehmenseinsatz einfällt ist nur: *highway to hell!* Ich weiss, auch da gibt es andere Meinungen zu. Ich wollte es nur nicht tun. ;-)
-
Stichwort Patchmanagement: Ich achte eigentlich immer darauf nur LinuxDistros einzusetzen, die einen ausreichend langen Produktlebenszyklus (z.B. Debian oder ein RHEL) haben. Eine Distro, die bereits nach einem Jahr keine Bug & Security Updates mehr bereitstellt (z.B. die Fedora Cores) kommt auf gar keinen Fall auf einen Server. ...auf meinem persönlichem Desktop System mag das aber wieder anders aussehen. ;-) Yup. Einmal Unix immer Unix? *g* Bye SystemError
-
Und deswegen habe auch ein entsprechendes Enterprise Linux erwähnt. Da kann ich nur zustimmen. Es ist wirklich praktisch Tools wie RSync, SSH, bzip2, etc gleich mit dem OS fertig verschnürt zu bekommen. Habe persönlich keine Erfahrungen mit dem Microsoft Support; wohl aber mit dem Support von IBM und HP für die entsprechenden Unix Derivate. Und der macht nun wirklich was her. Man bleibt einfach nicht mit seinen Problemen im Regen stehen. Wir hatten vor ca. 6 Jahren (vor der Zeit von RHEL) einen 5 Incident SupportVertrag mit RedHat gekauft. Von diesen 5 Incidents haben wir bis heute keinen "aufgebraucht". Stichwort Support: Wenn ich mir mal die Zertifizierungsmatrix von Oracle 10G ansehe dann komme ich einfach nicht um ein entsprechendes Enterprise Linux umhin. Und ich werde mich hüten Software für 40.000$/CPU auf einer nicht vom Softwarehersteller zertifizierten LinuxDistro laufen zu lassen. Ob nun wirklich für jeden Apache // MySQL // Sendmail // Samba // etc LinuxServer ein entsprechender SupportVertrag notwenig ist lasse ich jetzt mal dahingestellt. Ist wohl auch eine Frage der Unternehmensphilosophie. Hehe. Ich halte das Vorhandensein eines SupportVertrages NICHT für einen Hinweis auf die Inkompetenz des entsprechenden Admins. Jegliche Software ist buggy. Egal ob sie von MS, IBM oder einer OpenSource Community stammt. Und wenn ich auf einen Bug laufe dann ist schon wirklich praktisch einen Hersteller // Supporter zu haben der den Kram fixt. Vielleicht sollte ich mich auf bezüglich des SupportVertrages relativieren? Wie wäre es denn mit: "Für jedes produktive Unix // Linux System mit kommerzieller Datenbanksoftware ein SupportVertrag für RDBMS und OS." ack. Bye SystemError
-
Hmm, ist Unix da wirklich billiger? Ich habe jetzt keine Ahnung was ein Windows Server, Solaris, HP-UX oder AIX SupportVertrag kostet; die RedHat Enterprise Linuxe z.B. kosten aber auch eine Stange Geld pro Jahr. Und ohne SupportVertrag kein System im Produktionsbetrieb. Von den Preisen von non x86 Hardware mal ganz zu schweigen. Bye SystemError
-
Hmmm, also was sich wirklich, wirklich bezahlt macht wenn man immer wieder ähnliche // identische System aufsetzen muss: Eine automatisierte Art der Netzwerkinstallation! Das ganze soweit ausgefeilt dass sich eine Neuinstallation eigentlich auf ein paar Kommandos beschränkt. NIM für AIX lebe hoch. Man sollte dann natürlich eine Art "MasterKonfiguration" in der Schublade haben, von der bekannt ist dass sie die entsprechenden Anforderungen erfüllt, sonst war die Übung leider Umsonst... Soweit ich weiss stellt da jedes UnixDerivat eigene Tools & Methoden zur Verfügung; die WindowsFraktion hat da ja euch ihre "Unattended Installation" und so... Was ein Weg ins garantierte Unglück ist: Im Vorfeld der Installation die Rahmenbedingungen nicht abzuklären bzw. Installationsvoraussetzungen einfach ignorieren. Solange also nicht klipp und klar feststeht welches OS & welche Datenbanksoftware mit welchem Patchlevel würde ich gar nicht erst mit einer Installation beginnen. Aber gilt das nicht auch genauso für Windows? Bye SystemError
-
Hallo, Nun ja, das war traditionell immer so... an dieser Ecke tut sich aber was. Siehe z.B. die HP Integrity SuperDome mit bis zu 128 Itanium CPUs; auf diesem Ding läuft u.a. ein 64Bitiger Windows Server 2003 als Betriebssystem. Ein anderes Beispiel wäre die IBM xSeries 445 mit bis 32 x86 CPUs... Wobei ich mir über die Produktionsreife der 64Bitigen Windowse einfach nicht im klaren bin. Da kann ich Devil nur zustimmen. Ein IT-System ist dann ein gutes IT-System wenn es die an es gestellten Anforderungen erfüllt und nicht wenn das einzig WAHRE[tm] Betriebssystem darauf läuft. Und einen Unix vs. Windows FlameWar können wir doch getrost dem HeiseForum überlassen, oder? ;-) @Blue55: Vielleicht ist Deine Frage auch einfach zu allgemeiner Natur um sie eindeutig beantworten zu können. Ich meine ein "Datenbankserver" kann einmal dieser Server mit 3 MySQLDBs und 10 Anwendern sein, oder aber ein Monstrum mit 16 CPUs und tonnenweise RAM... Letzendlich wird imho die Antwort auf Deine Frage immer auf ein "es kommt ganz drauf" an hinauslaufen. Die bereits vorhandene IT-Infrastruktur eines Unternehmens wird immer eine grosse Rolle spielen; wenn also schon 10 UnixAdmins mit 150 UnixMaschinen dasitzen warum dann ohne Not einen WindowsServer aufstellen? (...natürlich auch umgekehrt) Bye SystemError UnixBenutzer aus LeidenSchaft
-
Hallo, machst Du [root@doom3 root]# vi /etc/inittab. Und dann such mal nach folgender Sektion: ... # Default runlevel. The runlevels used by RHS are: # 0 - halt (Do NOT set initdefault to this) # 1 - Single user mode # 2 - Multiuser, without NFS (The same as 3, if you do not have networking) # 3 - Full multiuser mode # 4 - unused # 5 - X11 # 6 - reboot (Do NOT set initdefault to this) # id:5:initdefault: ... Und dann entsprechend in der Zeile "initdefault" von 5 auf 3 stellen. Solltest Du auf graphische Tools stehen so werden Dir die "system-config*" RPM Pakete für Fedora gefallen. Jedes dieser Tools ermöglicht die Konfiguration von einer "Sache". Ggf. einfach nachinstallieren; eine Liste der "system-config*" Tools kannst Du einer entsprechenden PaketListe für den jeweiligen FedoraCore entnehmen, z.b. hier: http://download.fedora.redhat.com/pub/fedora/linux/core/3/i386/os/Fedora/RPMS/ Bye SystemError
-
Danke! Das hilft mir für meinen Teil als NichtThreadErsteller wirklich weiter. :-) Bye SystemError
-
[Suche] Schlankesten Browser, ohne Schnickschnack...
SystemError antwortete auf Schlaubi's Thema in Linux
Also lass mal sehen ob ich das richtig verstehe... Die Rechner "kunden-ssh-rechner" und "defendo" sind 2 verschiedene Kisten, ja? Folglich sind 3 Rechner beteiligt: defendo, kunden-ssh-rechner und dein Workstation im Büro, richtig? Hmmm, dann ist dieser Fall wohl eher was fürs "RemotePortForwarding"... ...ich hoffe ich bekomme jetzt die Syntax auf die schnelle hin: [schlaubi@work]$ ssh -g -R 12345:192.168.1.11:443 root@kunden-ssh-rechner Ich habe für dieses Beispiel einfach mal eine private Adresse für den Defendo Rechner angenommen um es anschaulicher zu machen... Dieses Kommando sollte folgendes bewirken: a.) den Port 12345@kunden-ssh-rechner öffnen und nach 192.168.1.11:443 weiterleiten b.) den Port 12345@kunden-ssh-rechner dank dem "-g" auch für andere Rechner im Netz zur Verfügung stellen Nun sollte es Dir imho möglich sein Dich mit einem HTTPS-fähigem WebBrowser auf 12345@kunden-ssh-rechner zu verbinden... ...das "-g" evtl. auch mal weglassen. Ach ja: Auch noch eine Möglichkeit das dieses Defendo Dings auch noch den Port 80 benötigt... ...in diesem Fall einfach 2 Ports mit 2 SSH Sessions forwarden! Meine "heissgeliebten" WebSphere V5 AdminConsolen haben jeweils ein Forwarding für HTTP und HTTPS benötigt. Bye SystemError -
Eine Verbindung mit nem MySQLClient kannst Du aber herstellen, ja? Also ich habe gerade Deinen Post im NachbarThread zum Thema "Umbenennen von Spalten" gelesen und vermute jetzt mal Du verwendest MySQL... ...in diesem Fall wird Dir das Tool "mysqlshow" weiterhelfen. Verwendung wie folgt: [deinuer@deinpc deinuser]$ mysqlshow -i -h dein.server.de -u deinuser -p DEINEDB Schau Dir dann mal die Spalte "Data_length" an. Diese Infos kann man evtl. auch per SQL direkt aus der DB ziehen; keine Ahnung ob und wie. Bye SystemError
-
Ein "Relationales Datenbank Management System": http://de.wikipedia.org/wiki/Datenbankmanagementsystem Nachtgeist will einfach wissen welches Datenbanksystem Du verwendest. Oracle? DB2 UDB? MySQL? ... Bye SystemError
-
[Suche] Schlankesten Browser, ohne Schnickschnack...
SystemError antwortete auf Schlaubi's Thema in Linux
Hallo, ich sehe es richtig dass Du mit SSH direkt auf die Büxe kannst, ja? Falls ja kannst Du wie folgt vorgehen: [schlaubi@schlaubisrechner schlaubi]$ ssh -L 12345:localhost:80 user@remotehost Dieser Befehl stellt zum einenm eine reguläre SSH-Verbindung zum Rechner remotehost her, öffnet zum anderen aber auch den TCP/IP Port 12345 auf deinem Rechner. Alle Anfragen die auf deinem Rechner auf Port 12345 eingehen werden nun über einen sog. SSH-Tunnel (läuft standardmässig über Port 22) an remotehost Port 80 weitergeleitet... Dieses SSH-Feature ist einfach nur genial! Du kannst übrigens SSH-Tunnel auch kaskadieren. Schau dir mal die Optionen -R, -L und -g in der entsprechenden man Seite an. Bye SystemError PS: Im SSH Buch von O'Reilly wird auf dieses Feature ausführlich eingegangen. -
Solange Du darauf achtest, dass die Gesamtkonfiguration von Hardware, BetriebsSystem (64 Bit Version nehme ich an?) und Datenbankträgersystem (ebenfalls 64 Bit Version nehme ich an?) zertifiziert ist, JA. Ich empfehle die Zertifizierungsfrage im Vorfeld gründlich zu klären um keine bösen Überaschungen zu erleben... Für Produktivsysteme empfehle ich Komplettsysteme von einem renomierten Hersteller (HP, IBM, Sun, Dell, Siemens, ...) mit entsprechendem PlattenSubSystem bzw. HBA Adapter für eine evtl. vorhandene SAN. Ich habe persönlich sehr gute Erfahrungen mit den 32 Bit Modellen der ProLiant DL Baureihe von HP gemacht: http://h18004.www1.hp.com/products/servers/platforms/index-dl.html Aus der selben Baureihe gibt es jetzt auch Opteron Modelle. Ansonsten macht sich für einen DBServer immer gut: ---> RAM im Überfluss vorausgesetzt das Datenbankträgersystem kann diesen auch verwenden, --> 64 Bit Version? ---> Schnelle Platten ---> Viele Platten... Ein gewissen Restrisiko mag bleiben: ---> Die Intel Xeons + passende Chipsätze sind einfach schon länger auf dem Markt... Man könnte von einem wirklich konservativem Standpunkt aus argumentieren, dass die Opteron Modelle ein höheres Risiko bergen... Nun ja, dass mag jeder selbst entscheiden, eine definitive Antwort wird es wahrscheinlich nicht geben. Bye SysteError
-
[EDIT] Und mir fällt gerade auf dass das Problem schon gelöst ist... ...jaja wer lesen kann ist klar im Vorteil. ;-) Sorry. [/EDIT] Erhälst Du denn eine Fehlermeldung? Wenn ja, welche? Wenn nein, porbier mal folgendes: Evolution aus nem xterm heraus starten (im Vordergrund), dann den Import anstarten. Etwaige Fehlermeldungen sollten jetzt im xterm rauslaufen... Habe vor 2 Wochen mein 1.4er Evolution Postfach + Kontakte nach 2.xyz importiert. Hat problemlos geklappt. Hatte allerdings vor einem Jahr oder so mal Probleme Evolution-Daten von einer FreeBSD Workstation auf eine Linux Büxe zu übernehmen; damals hat oben beschriebene Methode mit dem xterm wirklich sehr geholfen... Bye SystemError