Das ist doch wie Weihnachten!
-
vista schrieb:
mich stören unter linux solche kleinigkeiten wie z.b. dass es kein einheitliches 'clipboard' gibt.
Klar gibt es das. So ungefähr mindestens seit 20 Jahren...
rüdiger schrieb:
Aber ich will ja niemandem meine Meinung aufzwingen). Aber das schlimmste ist doch _für_ Windows zu entwickeln...
welche negativen erfahrungen hast du gemacht?
zB die genannten: DLLs, Unicode
Außerdem Skalierbarkeit und das schlimmste ist wohl die WinAPI (Wer denkt sich bitte eine derartig beschissene API aus? Sicher ist die POSIX-API nicht die tollste. Aber im Vergleich zur WinAPI...)
rüdiger schrieb:
(zB Windows aka das Betriebsysstem was DLLs nicht hinbekommt...
was heisst 'nicht hinbekommt'
Gut, als C-Programmierer fällt einem das sicher nicht so sehr auf. Aber für C++ sind DLLs im Prinzip unbrauchbar. Es gibt keine einheitliche ABI. Ganz gewöhnliche Sachen wie Speicherverwaltung und Exceptions gehen total in die Hose. Für Plugins sind DLLs auch nur eingeschränkt verwendbar, da man einer DLL keine globalen Symbole zur Verfügung stellen kann etc.
-
zB die genannten: DLLs, Unicode
Bist du dir auch ganz sicher hier nicht in der Vergangenheit zu leben?
MfG SideWinder
-
rüdiger schrieb:
vista schrieb:
mich stören unter linux solche kleinigkeiten wie z.b. dass es kein einheitliches 'clipboard' gibt.
Klar gibt es das. So ungefähr mindestens seit 20 Jahren...
dann scheinen viele linux-anwendungen das clipboard nicht oder auf ungewöhnliche art zu benutzen?
rüdiger schrieb:
rüdiger schrieb:
Aber ich will ja niemandem meine Meinung aufzwingen). Aber das schlimmste ist doch _für_ Windows zu entwickeln...
welche negativen erfahrungen hast du gemacht?
Außerdem Skalierbarkeit und das schlimmste ist wohl die WinAPI (Wer denkt sich bitte eine derartig beschissene API aus? Sicher ist die POSIX-API nicht die tollste. Aber im Vergleich zur WinAPI...)
ja, winapi ist recht unübersichtlich, aber es gibt eine übersichtliche dokumentation dafür. ich finde das macht es wieder wett.
rüdiger schrieb:
rüdiger schrieb:
(zB Windows aka das Betriebsysstem was DLLs nicht hinbekommt...
was heisst 'nicht hinbekommt'
...Aber für C++ sind DLLs im Prinzip unbrauchbar.
das kann ich nicht nachvollziehen
wenn dem so wäre, wer verursacht das problem? sind es die DLLs oder ist es C++?rüdiger schrieb:
Ganz gewöhnliche Sachen wie Speicherverwaltung und Exceptions gehen total in die Hose.
das stimmt nicht.
windows hat ein im betriebssystem integriertes exception handling und die speicherverwaltung funktioniert auch tadellos. alles davon lässt sich selbstverständlich in DLL's nutzen.rüdiger schrieb:
Für Plugins sind DLLs auch nur eingeschränkt verwendbar, da man einer DLL keine globalen Symbole zur Verfügung stellen kann etc.
auch das ist falsch.
du kannst in einer DLL globale objekte anlegen, die prozessweit gültigkeit haben, und solche, auf die systemweit zugegriffen werden kann (dafür wird automatisch shared memory benutzt, ohne dass man viel programmieren muss).
-
vista schrieb:
rüdiger schrieb:
vista schrieb:
mich stören unter linux solche kleinigkeiten wie z.b. dass es kein einheitliches 'clipboard' gibt.
Klar gibt es das. So ungefähr mindestens seit 20 Jahren...
dann scheinen viele linux-anwendungen das clipboard nicht oder auf ungewöhnliche art zu benutzen?
Nö. Bisher hatte ich damit auch noch nie ein Problem.
ja, winapi ist recht unübersichtlich, aber es gibt eine übersichtliche dokumentation dafür. ich finde das macht es wieder wett.
Aber es sind doch einige Teile der API einfach kaputt. So wie diese High-Performance-A/IO-API, bei der man keinen Timeout für Verbindungen angeben kann, so dass jemand einfach nur fleißig Verbindungen öffnen muss und der Server ist gedost etc. (Gut, das Problem ist jetzt sehr spezifisch. Windows für Server einzusetzen ist ja eh wahnsinnig)
[quote="rüdiger"]
das kann ich nicht nachvollziehen
wenn dem so wäre, wer verursacht das problem? sind es die DLLs oder ist es C++?Wenn man betrachtet, wie gut dynamische Libs unter Linux mit C++ klappen, müssen es wohl die DLLs sein.
rüdiger schrieb:
Ganz gewöhnliche Sachen wie Speicherverwaltung und Exceptions gehen total in die Hose.
das stimmt nicht.
windows hat ein im betriebssystem integriertes exception handling und die speicherverwaltung funktioniert auch tadellos. alles davon lässt sich selbstverständlich in DLL's nutzen.Kann sein, dass ich da nicht mehr up-to-date bin. Habe nur in Erinnerung, dass es Probleme gibt, wenn man Speicher in der Hauptanwendung anlegt und in der DLL freigibt bzw. andersrum.
auch das ist falsch.
du kannst in einer DLL globale objekte anlegen, die prozessweit gültigkeit haben, und solche, auf die systemweit zugegriffen werden kann (dafür wird automatisch shared memory benutzt, ohne dass man viel programmieren muss).Ich meine das andersrum: Die DLL greift auf die Symbole der Hauptanwendung zu.
-
rüdiger schrieb:
Aber es sind doch einige Teile der API einfach kaputt. So wie diese High-Performance-A/IO-API, bei der man keinen Timeout für Verbindungen angeben kann, so dass jemand einfach nur fleißig Verbindungen öffnen muss und der Server ist gedost etc.
man kann doch die anzahl der verbindungen begrenzen oder verbindungen nach einer bestimmten zeit abbrechen. dafür bietet windows einiges an möglichkeiten. wenn eine API sowas nicht von sich aus anbietet, muss man es eben selbst programmieren, das sollte kein hindernis sein.
rüdiger schrieb:
(Gut, das Problem ist jetzt sehr spezifisch. Windows für Server einzusetzen ist ja eh wahnsinnig)
manche tun es mit erfolg.
was stört dich daran?
vielleicht, dass windows-server eine grafische oberfläche haben, die man nicht abschalten kann?rüdiger schrieb:
das kann ich nicht nachvollziehen
wenn dem so wäre, wer verursacht das problem? sind es die DLLs oder ist es C++?Wenn man betrachtet, wie gut dynamische Libs unter Linux mit C++ klappen, müssen es wohl die DLLs sein.
windows-DLLs können beim laden C++ konstruktoren aufrufen und beim entladen die destruktoren. was fehlt dir?
rüdiger schrieb:
auch das ist falsch.
du kannst in einer DLL globale objekte anlegen, die prozessweit gültigkeit haben, und solche, auf die systemweit zugegriffen werden kann (dafür wird automatisch shared memory benutzt, ohne dass man viel programmieren muss).Ich meine das andersrum: Die DLL greift auf die Symbole der Hauptanwendung zu.
eine windows-DLL ist nach dem laden bestandteil des prozesses. der prozess kann auf jedes byte der DLL zugreifen und andersherum geht es auch völlig problemlos. ich nehme an, du hast dich nur nicht genügend mit dem thema auseinandergesetzt...
-
vista schrieb:
rüdiger schrieb:
(Gut, das Problem ist jetzt sehr spezifisch. Windows für Server einzusetzen ist ja eh wahnsinnig)
manche tun es mit erfolg.
was stört dich daran?
vielleicht, dass windows-server eine grafische oberfläche haben, die man nicht abschalten kann?Das passt gerade so schön:
http://www.c-plusplus.net/forum/viewtopic-var-p-is-1263691.html#1263691Bei Linux muss ich höchstens mal neu booten wenn sich der Kernel ändert ... selbst wenn die gesamte graphische Oberfläche oder Systemkomponenten aktualisiert werden. Bei Windows muss man dagegen wegen fast jedem popeligen Sicherheitsupdate neu starten. Was für ein tolles System. Es sind Tage wie dieser an denen sich Windows noch unbeliebter macht als es eh schon ist
-
Ich sag's ja, nimm Windows für Desktop und Linux für den Server und nicht umgekehrt - das bringt nur unsägliches Leid :p
-
minhen schrieb:
Bei Linux muss ich höchstens mal neu booten wenn sich der Kernel ändert ... selbst wenn die gesamte graphische Oberfläche oder Systemkomponenten aktualisiert werden. Bei Windows muss man dagegen wegen fast jedem popeligen Sicherheitsupdate neu starten. Was für ein tolles System. Es sind Tage wie dieser an denen sich Windows noch unbeliebter macht als es eh schon ist
ja, bei win ist die oberfläche ganz tief im system drin. dafür ist die oberfläche aber auch ruckelfrei.
-
minhen schrieb:
Das passt gerade so schön:
http://www.c-plusplus.net/forum/viewtopic-var-p-is-1263691.html#1263691ok, das kann man als argument gegen windows-server gelten lassen.
obwohl, selbst mein desktop windows update ich manuell.
bei einem server würde ich es erst recht nicht mögen, wenn der selbständig neu startet...
-
vista schrieb:
rüdiger schrieb:
Aber es sind doch einige Teile der API einfach kaputt. So wie diese High-Performance-A/IO-API, bei der man keinen Timeout für Verbindungen angeben kann, so dass jemand einfach nur fleißig Verbindungen öffnen muss und der Server ist gedost etc.
man kann doch die anzahl der verbindungen begrenzen oder verbindungen nach einer bestimmten zeit abbrechen. dafür bietet windows einiges an möglichkeiten. wenn eine API sowas nicht von sich aus anbietet, muss man es eben selbst programmieren, das sollte kein hindernis sein.
Das Problem ist wohl bei AcceptEx. Das Prinzip dahinter soll sein, dass der Kernel die Verbindungen für dich annimmt, aber sich erst bei dir meldet, wenn er die passenden Daten in einen Buffer gelesen hat. Da gibt es keinen Weg Timeouts selbst zu programmieren, außer man zerstört das Konzept dahinter (und dann ist es ja nichts mehr wert...)
rüdiger schrieb:
(Gut, das Problem ist jetzt sehr spezifisch. Windows für Server einzusetzen ist ja eh wahnsinnig)
manche tun es mit erfolg.
was stört dich daran?
vielleicht, dass windows-server eine grafische oberfläche haben, die man nicht abschalten kann?Unter anderem. Ansonsten skaliert Windows aber phänomenal schlecht: Siehe zB hier, wo Windows 16 MB/s schafft, während Linux (trotz NTFS-Dateisystem) 60-102 MB/s erreicht.
Oder schau dir die dazu gehörigen Benchmarks an, wo der IIS 161 Verbindungen pro Sekunde schafft, während alle Unix-Artigen Betriebssysteme im kiloVerbindungen/s Bereich liegen. Ganz zu schweigen von der schlechten Dateisystem performance und den Problemen durch fragmentierte Partitionen.
Das mit den DLLs werde ich mir bei Gelegenheit noch mal angucken. Ist länger her, das ich damit gefrickelt habe.
-
Naja, Rüdiger, "vorgestellt auf dem Linux Kongress 2006".
Erinnert mich irgendwie an "eine unabhängige von Microsoft in Auftrag gegebene Studie".
-
SeppSchrot schrieb:
Naja, Rüdiger, "vorgestellt auf dem Linux Kongress 2006".
Erinnert mich irgendwie an "eine unabhängige von Microsoft in Auftrag gegebene Studie".Kannst die Benchmarks ja selbst ausführen bzw. dir den Code angucken :p Ich denke das ist schon ein wenig objektiver als diese esotherischen Microsoft Sowi-Studien
-
volkard schrieb:
minhen schrieb:
Bei Linux muss ich höchstens mal neu booten wenn sich der Kernel ändert ... selbst wenn die gesamte graphische Oberfläche oder Systemkomponenten aktualisiert werden. Bei Windows muss man dagegen wegen fast jedem popeligen Sicherheitsupdate neu starten. Was für ein tolles System. Es sind Tage wie dieser an denen sich Windows noch unbeliebter macht als es eh schon ist
ja, bei win ist die oberfläche ganz tief im system drin. dafür ist die oberfläche aber auch ruckelfrei.
Wenn du nicht gerade den vesa Treiber verwendest, ist X11 ebenfalls ruckelfrei.
-
X11 vielleicht - aber ehe die GNOME-Anwendung über die MessageQueue erfährt, dass der Windowmanager das Fenster verkleinert hat, weil der über die netzwerktransparente XLIB genötigt wurde, die Pointerbewegung des Anwenders auszuwerten und bevor die Anwendung dann geeignete Maßnahmen ergreift, wie Fensternachrichten an die entsprechenden Widgets zu leiten, vergehen schon mal ein paar Microsekunden.
-
Nami schrieb:
Wenn du nicht gerade den vesa Treiber verwendest, ist X11 ebenfalls ruckelfrei.
nungut, ich gebe zu, daß ich jetzt auf meinem neuen AMD Sempron 3000+ bei 0% prozessorauslastung kein ruckeln bemerkt habe.
-
rüdiger schrieb:
Unter anderem. Ansonsten skaliert Windows aber phänomenal schlecht: Siehe zB hier, wo Windows 16 MB/s schafft, während Linux (trotz NTFS-Dateisystem) 60-102 MB/s erreicht.
Oder schau dir die dazu gehörigen Benchmarks an, wo der IIS 161 Verbindungen pro Sekunde schafft, während alle Unix-Artigen Betriebssysteme im kiloVerbindungen/s Bereich liegen. Ganz zu schweigen von der schlechten Dateisystem performance und den Problemen durch fragmentierte Partitionen.von diesen tests hab' ich auch schon einige gesehen, allerdings war dabei immer freebsd der gewinner
ich nehme auch an, dass die solaris nicht auf 'ner SPARC-kiste gefahren haben, sondern solaris/x86 auf 'nem PC. das ist natürlich unfair.
man sollte bei solchen benchmarks immer sehr misstrauisch sein, erst recht, wenn sie von einem fanclub oder hersteller eines betriebssystems kommen.
aber klar, das ist ja allgemein bekannt, dass windows-server nicht so tolle ergebnisse haben, wenn sie gequält werden.
im normalbetrieb ist das aber kein problem.
-
SeppSchrot schrieb:
X11 vielleicht - aber ehe die GNOME-Anwendung über die MessageQueue erfährt, dass der Windowmanager das Fenster verkleinert hat, weil der über die netzwerktransparente XLIB genötigt wurde, die Pointerbewegung des Anwenders auszuwerten und bevor die Anwendung dann geeignete Maßnahmen ergreift, wie Fensternachrichten an die entsprechenden Widgets zu leiten, vergehen schon mal ein paar Microsekunden.
Und? Ein paar Microsekunden merkt doch niemand. Außerdem würde ich wetten, dass Windows auch nicht schneller ist.
-
Stimmt, Millisekunden wäre passender.
Und wen's nicht stört, den stört's halt nicht.
-
Gut, GNOME stinkt. Hat ja aber nichts direkt mit Linux zu tun, da man ja nicht an so etwas gebunden ist (und man kann unter Linux immerhin die Prozesspriorität des Window-Managers anheben oder das Ding gar auf nem eigenen Prozessor laufen lassen, falls man das Gefühl hat die Fenster reagieren zu lahm
:p)
-
rüdiger schrieb:
Gut, GNOME stinkt. Hat ja aber nichts direkt mit Linux zu tun, da man ja nicht an so etwas gebunden ist (und man kann unter Linux immerhin die Prozesspriorität des Window-Managers anheben oder das Ding gar auf nem eigenen Prozessor laufen lassen, falls man das Gefühl hat die Fenster reagieren zu lahm
:p)man kann sich auch ein ein paar millisekunden gewöhnen. man soll aber nicht so tun, als sei jede linux-designentscheidung immer das alleinseligmachende und windows immer mist. mir schien, minhen war da ein wenig einseitig.