Eigentlich mag ich diese Linux versus Windows Diskussionen nicht so, weil ich beide Betriebssysteme nutze und ich beide Ok finde. Jetzt ist mir aber was komisches aufgefallen. Und zwar ganz egal welche Toolchain Variante und IDE ich verwende, der arm-gcc scheint unter Linux gefühlt mindestens 5x so schnell zu sein, wie unter Windows. Kann das sein, oder spinne ich? Beim avr-gcc und beim gcc für Desktop Anwendungen (also Linux bzw. Windows Targets) ist mir ein solch krasser Unterschied nicht aufgefallen.
:
Verschoben durch User
Stefan U. schrieb: > der arm-gcc scheint unter Linux > gefühlt mindestens 5x so schnell zu sein, wie unter Windows. Die Frage wäre eher, wie er gegen den Keil oder IAR abschneidet. Vom Prinzip her würde ich vermuten, daß Keil und IAR um einiges langsamer sein müßten, weil beide ja vor dem tatsächlichen Arbeiten jedesmal ihre Lizenz abfragen und sich bestätigen lassen. Sowas kostet auch Zeit. Aber zum GCC: Wenn du mal in eine GCC-Distribution für Windows hineinschaust (z.B. Yagarto), wirst du feststellen, daß sich da von allen ausführbaren Dateien mehrere binärgleiche Exemplare unter unterschiedlichen Namen tummeln. Möglicherweise ist das bei Linux-Distributionen ganz anders gehandhabt, so daß zusätzliche Ladezeiten und die Übergabe intermediärer Dateien einfach entfallen. Aber vielleicht ist das Ganze ja nur eine der vielen Täuschungen bei Linux: Ich kenne das vom Kopieren von Dateien mit dem Krusader. Wenn man da eine Datei (von, sagen wir mal 200 MB oder größer) von HD auf Stick kopiert, ist nach Anzeige der Kopiervorgang binnen 1..2 Sekunden abgeschlossen und die Fortschrittsanzeige zeigt auch "100% kopiert" an. Oh Mann, Linux ist ja wirklich viel schneller als Windows... Aber die Wirklichkeit ist anders. Da dauert es nämlich minutenlang, bis das ganze Anzeigefenster zuklappt, denn der eigentliche Kopiervorgang ist wesentlich langsamer. Was man da als Benutzer sieht, ist reine Verarschung. Ich hab schon etliche Kollegen in der Firma erlebt, die angesichts von "100% kopiert" den Stick herausgezogen und sich davongemacht haben (und sich anschließend beschwert haben). Eigentlich haben sie Recht, denn wo 100% draufsteht, sollte verdammtnochmal auch 100% drin sein. W.S.
Stefan U. schrieb: > Kann das sein, oder spinne ich? Also eigentlich letztes. Scnr. Bei vielen Anwendungen ist Windows auf kernelebene auch Performant. Wie rufst du den GCC auf? Neuere make nutzen mehrere cores deines Prozessors. Unter Linux ist das evtl. Sogar Default. Unter Windows muss man das mit -j erzwingen. Könnte das der Fall sein? Schau Mal wieviele cores dein buildsystem auslastet.
W.S. schrieb: > Wenn man da eine Datei (von, sagen wir mal 200 MB oder größer) von HD > auf Stick kopiert, ist nach Anzeige der Kopiervorgang binnen 1..2 > Sekunden abgeschlossen und die Fortschrittsanzeige zeigt auch "100% > kopiert" an. Oh Mann, Linux ist ja wirklich viel schneller als > Windows... Das macht nicht nur Linux so, sondern auch die meisten Unix-Varianten. Sieh' dir die Manpage zu 'sync' an. Also Dateien copiert man auf einem Memorystick nicht mit einem GUI, sondern mit cp und anschliessendem sync.
Der GCC ist unter Linux definitiv deutlich schneller. Und das ist auch nicht wie von W.S. nur "fake-schneller", das Kompilat liegt dann wirklich auch vor. Das "-j" macht hier auch keinen Unterschied. Liegt vermutlich daran, dass der GCC die POSIX-API's nutzt die von MinGW emuliert/auf Win32-API umgesetzt werden müssen. Es hilft ein bisschen, sich selbst einen amd64-Compiler für Windows zu bauen, da fertig zum Download nur 32bit-Binaries zur Verfügung stehen. Der kann dann auch mehr RAM nutzen. Hier mein Ergebnis dieses Vorgehens: https://bugs.launchpad.net/gcc-arm-embedded/+bug/1742188
olibert schrieb: > Also Dateien copiert man auf einem Memorystick nicht mit einem GUI, > sondern mit cp und anschliessendem sync. Besser umount.
W.S. schrieb: > Eigentlich haben sie Recht, denn wo 100% draufsteht, sollte > verdammtnochmal auch 100% drin sein. Bei Windows ist der Sync für Wechseldatenträger automatisch eingestellt. Den kann man allerdings als normaler User mit wenigen Klicks abstellen. Dann hast Du denselben Effekt wie unter Linux.
Niklas G. schrieb: > Liegt vermutlich daran, dass der GCC die POSIX-API's nutzt die von MinGW > emuliert/auf Win32-API umgesetzt werden müssen. Naja. Welche vielen Systemaufrufe werden bei einem compiler denn verwendet, wo die Übersetzung der Aufrufe einen Faktor von 5 ausmachen soll? Ist das eine Vermutung oder gibt's dazu was handfestes? Nicht falsch verstehen. Interessiert mich.
> Das "-j" macht hier auch keinen Unterschied.
Das kann ich gar nicht glauben.
Die richtige Option heißt -j 8 für einen PC mit Quadcore-CPU mit
hyperthreading). Die Verwendung dieser Option beschleunigt das
Komplieren in Windows um Faktoren.
W.S. schrieb: > Was man da als Benutzer sieht, ist reine Verarschung. Ich hab schon > etliche Kollegen in der Firma erlebt, die angesichts von "100% kopiert" > den Stick herausgezogen und sich davongemacht haben (und sich > anschließend beschwert haben). Eigentlich haben sie Recht, denn wo 100% > draufsteht, sollte verdammtnochmal auch 100% drin sein. Aua, das Rausziehen ohne unmount ist immer eine Dumme Idee, selbst unter Windows.
Karl der erste von oben schrieb: > Naja. Welche vielen Systemaufrufe werden bei einem compiler denn > verwendet, wo die Übersetzung der Aufrufe einen Faktor von 5 ausmachen > soll? Beim Schreiben der .o und temporären Dateien können u.U. viele Hundert MB durchgereicht werden. Dafür werden gewiss der eine oder andere Syscall getätigt. Aber es ist in der Tat nur eine Vermutung. Helmut S. schrieb: > Die Verwendung dieser Option beschleunigt das > Komplieren in Windows um Faktoren. Korrekt. Aber wenn man unter Linux und Windows die gleiche -j Option verwendet, ist das unter Linux immer noch deutlich schneller. Es liegt also nicht daran, dass man unter Linux mit -j kompilieren würde und das unter Windows vergessen hätte. TriHexagon schrieb: > Aua, das Rausziehen ohne unmount ist immer eine Dumme Idee, selbst unter > Windows. Sollte eigentlich jeder wissen, der schonmal einen Computer benutzt hat, ganz besonders Leute die im Ingenieurswesen unterwegs sind...
WS, ich kann deinen Ärger bezüglich der Fortschrittsanzeigen verstehen. Von dem Effekt sind Linux und Windows gleichermaßen betroffen. Bei beiden Systemen kannst du das Pufferverhalten des Kernels konfigurieren. Bei Windows sind lediglich die Defaults für externe Laufwerke anders. Dieser Puffer macht aber Sinn, weil er die Systeme insgesamt erheblich performanter macht. Vor allem, wenn mehrere Programme gleichzeitig aktiv sind. Ich denke, der Effekt hat aber nicht mit diesem Thread zu tun. Bei meinen Projekten erzeugt der Compiler nur wenige kleine Dateien, da spielen Verzögerungen durch den Puffer kaum eine Rolle. > Bei vielen Anwendungen ist Windows auf kernelebene auch Performant. Eben deswegen kommt es mir auch merkwürdig vor. > Wie rufst du den GCC auf Ich rufe ihn unter Linux exakt mit den selben Parametern auf, wie unter Windows (absehen von Verzeichnis- Namen). Single vs. Multi-Threaded ändert nichts am Effekt, das der gcc unter Linux viel schneller compiliert.
Stefan U. schrieb: >> Bei vielen Anwendungen ist Windows auf kernelebene auch Performant. > > Eben deswegen kommt es mir auch merkwürdig vor. Warum? Der GCC wurde doch im Hinblick auf typische *nix Systeme entwickelt und optimiert. Da Windows und Linux eine ganz andere Architekturen haben, haben die Syscalls unterschiedliche Laufzeiten (Overhead). Man denke da nur an fork(). Da der GCC sehr IO lastig ist, kommt es dadurch zu großen Laufzeitunterschieden. IO-Syscalls sind unter Linux, glaube ich, auch schneller.
Windows ist beim Erzeugen von Prozessen signifikant langsamer als Linux. http://www.bitsnbites.eu/benchmarking-os-primitives/ In obigem Link Faktor 20. Wenn man viele kleine Sourcefiles übersetzen muß, dann erzeugt man dabei jedesmal einen neuen Prozess, der dann nur kurz läuft. Was hilft: ordentliche Qt-Programme übersetzen (pulseview z.B.), da läuft der Compiler lange ;-)
Interessanter Benchmark. Der scheint tatsächlich meine Beobachtung zu bestätigen. Dann müssten altmodische CGI Scripte unter Windows ja so richtig schlecht performen. Webserver kenne ich auch nur mit Linux, Solaris und AIX, mal abgesehen von ein paar kleinen Spielereien.
Carl D. schrieb: > Was hilft: ordentliche Qt-Programme übersetzen (pulseview z.B.), da > läuft der Compiler lange ;-) Meiner Erfahrung nach ist auch das Kompilieren einzelner Dateien unter Windows deutlich langsamer. Mit viel templates und Optimierung kann man mit wenigen Zeilen in einer einzelnen Datei schnell Minuten (bis Tage) Kompilier-Zeit erreichen, und das ist unter Windows auch langsamer. Stefan U. schrieb: > Dann müssten altmodische CGI Scripte unter Windows ja so richtig > schlecht performen. Die ./configure.sh Scripte von vielen Open Source Projekten sind unter Windows unerträglich langsam - wohl weil da für jede Kleinigkeit ein neuer Prozess gestartet wird. Stefan U. schrieb: > Webserver kenne ich auch nur mit Linux, Solaris und > AIX, mal abgesehen von ein paar kleinen Spielereien. Naja, Windows-Server werden durchaus auch genutzt. Aber dann wohl nicht mit CGI, das wird ja eh nicht mehr viel genutzt - auch unter Linux wird nicht mehr für jedes php-Script ein Prozess gestartet.
Stefan U. schrieb: > Ich rufe ihn unter Linux exakt mit den selben Parametern auf, wie unter > Windows So meinte ich das nicht. Verwendest du make? -j ist eine Option deines make. Unter Windows gibt es durchaus Versionen die -j akzeptieren aber nicht umsetzen. Beobachtest du das Verhalten beim compiler einer einzigen Datei oder eines ganzen Projekts?
> Beobachtest du das Verhalten beim compiler einer einzigen > Datei oder eines ganzen Projekts? Der Effekt Betrifft beide Fälle und tritt mit -j1 ebenso auf, wie mit -j8 (mein Rechner hat 8 Kerne).
Niklas G. schrieb: > Die ./configure.sh Scripte von vielen Open Source Projekten sind unter > Windows unerträglich langsam - wohl weil da für jede Kleinigkeit ein > neuer Prozess gestartet wird. Die basieren eben auf der Verfügbarkeit eines schnellen "fork". Windows wurde dafür nicht gebaut. Und -j<n> ändert am Verhältnis 20 nichts. Das n kürzt sich raus.
:
Bearbeitet durch User
Niklas G. schrieb: > Die ./configure.sh Scripte von vielen Open Source Projekten sind unter > Windows unerträglich langsam Und auch überflüssig, denn da Windows keinen Distri-Wildwuchs hat, werden Applikationen einfach fertig verteilt.
Nop schrieb: > Und auch überflüssig, denn da Windows keinen Distri-Wildwuchs hat, > werden Applikationen einfach fertig verteilt. Es soll vorkommen dass man Open-Source-Anwendungen modifizieren und selbst neu kompilieren möchte. Und mangels so praktischen Dingen wie pkg-config und "-dev"-Paketen ist das unter Windows deutlich weniger spaßig... Carl D. schrieb: > Die basieren eben auf der Verfügbarkeit eines schnellen "fork". Windows > wurde dafür nicht gebaut. Ja... Da sind Build-Systeme die z.B. auf Python oder ruby basieren besser, weil die eine ganze Menge selbst können (z.B. String-Verarbeitung, Dateizugriffe) ohne neue Prozesse starten zu müssen.
ARM-GCC habe ich unter Linux nicht. Aber mit LaTeX tritt der gleiche Effekt auf. Der Performance-Unterschied verschwindet allerdings vollständig mit dem Abschalten des Virenscanners.
Ja, gcc/make u.s.w sind unter Windows erheblich langsamer. Ich denke auch, dass den größten Anteil daran die Tatsache hat, dass Windows kein Äquivalent zu fork() bietet und das Erzeugen eines neuen Prozesses erheblich langsamer ist. Dazu kommt dann noch , dass Windows soweit ich weiß bei vielen kleinen Dateien auch nicht allzu performant ist (das ist auch einer der Gründe, warum die Registry eingeführt wurde), aber gerade das braucht man beim Compiler sehr viel (etliche Source- und Header-Files u.s.w., die immer wieder neu geöffnet werden müssen - vielleicht bringen precompiled headers da was?). Carl D. schrieb: > Wenn man viele kleine Sourcefiles übersetzen muß, dann erzeugt man dabei > jedesmal einen neuen Prozess, der dann nur kurz läuft. Nicht nur einen Prozess, sondern mehrere. gcc ist ja nur das Frontend für den eigentlichen Compiler. Und auch der Assembler wird z.B. jedesmal aufgerufen.
Walter T. schrieb: > ARM-GCC habe ich unter Linux nicht. Aber mit LaTeX tritt der gleiche > Effekt auf. Der Performance-Unterschied verschwindet allerdings > vollständig mit dem Abschalten des Virenscanners. Stimmt, Windows darf ja Daten nur gefiltert lesen. ;-) Da kommen dann zum Lesen/Schreiben von Dateien jeweils noch 2 Kontextwechsel dazu.
Stefan U. schrieb: > der arm-gcc scheint unter Linux > gefühlt mindestens 5x so schnell zu sein Mir ist das auch mal aufgefallen auf meinem Linux-Notebook, also Linux als Host-OS. Habe dann den Test gemacht, ein Projekt auf der Windows-Maschine in einer Linux-VM zu übersetzen. Selbst das war schneller, als dasselbe Projekt direkt auf diesem Windows-Host zu übersetzen.
Hi Ich kann das auch bestätigen. Faktor 5 kann ich jetzt nicht bestätigen aber Faktor zwei ist es auf jeden Fall. Matthias
Carl D. schrieb: > Stimmt, Windows darf ja Daten nur gefiltert lesen. ;-) Kurioserweise ist das sogar beim Löschen so. Wenn man eine große Anzahl Dateien löscht (z.B. die Boost-Library) geht das mit abgeschaltetem Windows-Defender ca. doppelt so schnell. Nicht dass man versehentlich ein böses Virus löscht!
Niklas G. schrieb: > Carl D. schrieb: >> Stimmt, Windows darf ja Daten nur gefiltert lesen. ;-) > > Kurioserweise ist das sogar beim Löschen so. Wenn man eine große Anzahl > Dateien löscht (z.B. die Boost-Library) geht das mit abgeschaltetem > Windows-Defender ca. doppelt so schnell. Nicht dass man versehentlich > ein böses Virus löscht! Daß man an den Eingangstüren Kontrollen macht, kann ich ja noch verstehen. Aber warum werden auch im Saal ständig die Taschen der Anwesenden durchsucht?
Niklas G. schrieb: > Carl D. schrieb: >> Stimmt, Windows darf ja Daten nur gefiltert lesen. ;-) > > Kurioserweise ist das sogar beim Löschen so. Wenn man eine große Anzahl > Dateien löscht (z.B. die Boost-Library) geht das mit abgeschaltetem > Windows-Defender ca. doppelt so schnell. Nicht dass man versehentlich > ein böses Virus löscht! Was, wenn der Virus nicht das ist, was gelöscht wird, sondern das, was die Löschaktion durchführt? Carl D. schrieb: > Daß man an den Eingangstüren Kontrollen macht, kann ich ja noch > verstehen. Aber warum werden auch im Saal ständig die Taschen der > Anwesenden durchsucht? Falls doch mal jemand unbemerkt an den Kontrollen vorbei gekommen ist, soll der sich nicht einfach frei beliebig austoben können.
Stefan U. schrieb: > Jetzt ist mir aber was komisches aufgefallen. Und zwar ganz egal welche > Toolchain Variante und IDE ich verwende, der arm-gcc scheint unter Linux > gefühlt mindestens 5x so schnell zu sein, wie unter Windows. Kann das > sein, oder spinne ich? Naja, Faktor fünf ist vermutlich ein wenig übertrieben, aaaber: wir machen sehr umfangreiche Performance-Tests und haben dabei festgestellt, daß schon Windows' Speicherverwaltung, je nach Version, bis zu 50% langsamer zu sein scheint als die von Linux. Unter Windows 7 betrug das etwa 50%, unter 8.1 ungefähr 30%, und unter Windows 10 liegt es wieder eher bei 50%. Unsere C/C++-Entwickler sagen zudem, daß der g++ in der neuem Linux-Umgebung unter Windows 10 spürbar schneller sein soll als nativ unter Windows -- dieselben Versionen, natürlich. Wenn Du möchtest, kann ich unsere Leute nächste Woche nochmal genau nach ihren Erfahrungen fragen, werde jedoch leider wohl weder Beispielcode noch konkrete Testergebnisse veröffentlichen dürfen. Unter Linux kannst Du den Compiler oder Make mit "/usr/bin/time -v <cmd>" starten und bekommst dann eine wesentlich detailliertere Ausgabe als mit dem Shell-Builtin "time" der Bash. Keine Ahnung, ob es sowas auch unter Windows gibt und die Ergebnisse dann vergleichbar sind.
W.S. schrieb: > Aber zum GCC: > Wenn du mal in eine GCC-Distribution für Windows hineinschaust (z.B. > Yagarto), wirst du feststellen, daß sich da von allen ausführbaren > Dateien mehrere binärgleiche Exemplare unter unterschiedlichen Namen > tummeln. Möglicherweise ist das bei Linux-Distributionen ganz anders > gehandhabt, so daß zusätzliche Ladezeiten und die Übergabe intermediärer > Dateien einfach entfallen. Ich vermute mal, daß das unter UNIXoiden mit Symlinks gehandhabt wird. Da Windows die nur beherrscht, wenn das POSIX-Subsystem aktiviert ist, wird den Entwicklern daher nicht viel anderes übrig bleiben, als entweder das POSIX-Subsystem vorauszusetzen oder binärgleiche Kopien anzulegen, wo in einem UNIX-Dateisystem nur ein Symlink wäre. > Aber vielleicht ist das Ganze ja nur eine der vielen Täuschungen bei > Linux: Ich kenne das vom Kopieren von Dateien mit dem Krusader. Wenn man > da eine Datei (von, sagen wir mal 200 MB oder größer) von HD auf Stick > kopiert, ist nach Anzeige der Kopiervorgang binnen 1..2 Sekunden > abgeschlossen und die Fortschrittsanzeige zeigt auch "100% kopiert" an. > Oh Mann, Linux ist ja wirklich viel schneller als Windows... Beim Schreiben auf einen USB-Stick ganz sicher nicht, das macht halbwegs moderne Hardware mit der linken Arschbacke. Aber das Kommando kommt früher zurück, weil der Dateisystempuffer sehr effizient ist und Krusader wohl auf einen fsync(2) verzichtet. Deswegen sollte man USB-Sticks und andere lahme Medien immer korrekt auswerfen, statt sie einfach herauszuziehen, aber das ist unter Windows ja kein bisschen anders. > Was man da als Benutzer sieht, ist reine Verarschung. Ich hab schon > etliche Kollegen in der Firma erlebt, die angesichts von "100% kopiert" > den Stick herausgezogen und sich davongemacht haben (und sich > anschließend beschwert haben). Eigentlich haben sie Recht, denn wo 100% > draufsteht, sollte verdammtnochmal auch 100% drin sein. Auch unter Windows gibt es einen Dateisystempuffer, und auch dort muß ein USB-Stick sauber ausgehangen werden -- ich glaube, da heißt die Funktion "sicher entfernen". Ähnliche Probleme kenne ich im Übrigen von Kollegen, die den Windows Explorer oder den "Total Commander" benutzen und nach Kopieraktionen das "sicher entfernen" vergessen haben.
Frank M. schrieb: > olibert schrieb: >> Also Dateien copiert man auf einem Memorystick nicht mit einem GUI, >> sondern mit cp und anschliessendem sync. > > Besser umount. Oder eject(1). ;-)
Frank M. schrieb: > Bei Windows ist der Sync für Wechseldatenträger automatisch eingestellt. > Den kann man allerdings als normaler User mit wenigen Klicks abstellen. > Dann hast Du denselben Effekt wie unter Linux. Das Äquivalent unter Linux ist, Wechseldatenträger mit der Option "sync" zu mounten. Dann kommt jeder write(2) auch wirklich erst dann zurück, wenn die Daten tatsächlich geschrieben und geflusht sind.
Hallo,
> ...und auch dort muß ein USB-Stick sauber ausgehangen werden...
Naja, muss man nicht unbedingt wenn man nur lange genug wartet.
Allerdings ist man mit dem manuellen "Hardware sicher entfernen und
Medium auswerfen" immer auf der sicheren Seite.
rhf
Karl der erste von oben schrieb: > Neuere make nutzen mehrere cores deines > Prozessors. Unter Linux ist das evtl. Sogar Default. Nein, ist es nicht. Auch unter Linux muß man die Option "-j" angeben, wenn man Make parallel ausführen will.
Helmut S. schrieb: >> Das "-j" macht hier auch keinen Unterschied. > > Das kann ich gar nicht glauben. > Die richtige Option heißt -j 8 für einen PC mit Quadcore-CPU mit > hyperthreading). Die Verwendung dieser Option beschleunigt das > Komplieren in Windows um Faktoren. Ich glaube, Helmut meinte "macht [...] keinen Unterschied" zwischen Windows und Linux. Auch unter Linux läuft GNU Make nicht per Default im parallelen Modus, den muß man explizit (mit "-j") einschalten. Auch unter Linux kann diese Option das Kompilieren um Faktoren beschleunigen.
Stefan U. schrieb: > Dieser Puffer macht aber Sinn, weil er die Systeme insgesamt erheblich > performanter macht. Vor allem, wenn mehrere Programme gleichzeitig aktiv > sind. Vor allem, wenn mehrere Programme auf unterschiedliche Bereiche einer herkömmlichen Festplatte ("Rotierender Rost") schreiben. Dann versucht Linux die Festplattenzugriffe nämlich so anzuordnen, daß die Schreib- / Leseköpfe und die Diskplatter möglichst bewegt werden müssen. > Ich rufe ihn unter Linux exakt mit den selben Parametern auf, wie unter > Windows (absehen von Verzeichnis- Namen). Single vs. Multi-Threaded > ändert nichts am Effekt, das der gcc unter Linux viel schneller > compiliert. Echt jetzt, Faktor 5? In derselben Compilerversion mit denselben Optionen?
Niklas G. schrieb: > Die ./configure.sh Scripte von vielen Open Source Projekten OT: Autoconf und Automake benutzen normalerweise nur "./configure", ohne .sh.
Nop schrieb: > Niklas G. schrieb: >> Die ./configure.sh Scripte von vielen Open Source Projekten sind unter >> Windows unerträglich langsam > > Und auch überflüssig, denn da Windows keinen Distri-Wildwuchs hat, > werden Applikationen einfach fertig verteilt. Natürlich kann man auch unter Linux fertige Applikationen verteilen, und dank des dabei üblichen Paketmanagement und offener Lizenzen funktioniert das auch ganz wunderbar -- und wesentlich streßfreier als unter Windows, wo man jedes installierte Programm dauernd einzeln aktualisieren muß, oder ständig von den Autoupdatern der installierten Programme genervt wird. ;-) Autoconf und Automake sind natürlich sehr nützlich für die Leute, die die Pakete erstellen, haben aber eigentlich einen ganz anderen Fokus: nämlich, die Unterschiede zwischen verschiedenen UNIX-Versionen abzubilden. Deswegen kann ich dieselbe Software unter Free- und anderen BSDs, Sun Solaris, IBM AIX, HP-UX, IRIX oder MacOS/X übersetzen, dabei werden die Build-Optionen mittels Autoconf und Automake automatisch (sic!) an das entsprechende UNIX-System angepaßt. Und da gibt es wesentlich größere Unterschiede als unter den verschiedenen Linux-Distributionen. ;-) Daß Autoconf und Automake dadurch auch das Leben der Paketmaintainer unter den verschiedenen Linux-Distributionen sehr viel einfacher machen, ist nur ein (durchaus nicht unangenehmer) Nebeneffekt.
Walter T. schrieb: > ARM-GCC habe ich unter Linux nicht. Aber mit LaTeX tritt der gleiche > Effekt auf. Der Performance-Unterschied verschwindet allerdings > vollständig mit dem Abschalten des Virenscanners. Guter Punkt -- ein On-Access-Scanner, nehme ich an?
Roland F. schrieb: >> ...und auch dort muß ein USB-Stick sauber ausgehangen werden... > > Naja, muss man nicht unbedingt wenn man nur lange genug wartet. > Allerdings ist man mit dem manuellen "Hardware sicher entfernen und > Medium auswerfen" immer auf der sicheren Seite. Auch darin unterscheiden sich Windows und Linux nicht. ;-)
Roland F. schrieb: >> ...und auch dort muß ein USB-Stick sauber ausgehangen werden... > > Naja, muss man nicht unbedingt wenn man nur lange genug wartet. Das ist aber abhängig vom konkreten Speichermedium. Nur weil alle Daten über den USB geschaufelt wurden heißt das nicht, das irgendwas ins Flash geschrieben wurde. > Allerdings ist man mit dem manuellen "Hardware sicher entfernen und > Medium auswerfen" immer auf der sicheren Seite. Eher. Sorry für OT. Sheeva P. schrieb: > Nein, ist es nicht. Auch unter Linux muß man die Option "-j" angeben, > wenn man Make parallel ausführen will. OK, gut zu wissen. Zum Rest deiner Beiträge: Respekt. Mehr davon ?
> Wenn Du möchtest, kann ich unsere Leute nächste Woche nochmal > genau nach ihren Erfahrungen fragen Nicht nötig, trotzdem Danke für das Angebot.
> Echt jetzt, Faktor 5? > In derselben Compilerversion mit denselben Optionen? Ja echt jetzt, Faktor 5 - gefühlt. Gemessen habe ich nicht. Die Version ist vermutlich nicht exakt die selbe, aber sie sind nahe beieinander.
Ich verwende keinen Virenscanner auf meinen Linux-Systemen. Beruflich mußte ich mal was für Windows unter Visual-Studio (MS-Hausmarke) compilieren. Nachdem ich dort den Virenscanner abgeschaltet hatte, lief es dreimal so schnell.
Manchmal lohnt es bei Windows (insbesondere bei Systemen, die länger nicht neu aufgesetzt wurden), sich die PATH Environmentvariable kritisch anzuschauen. Jedes Hinz-und-Kunz-Programm hätte da gerne einen Eintrag an prominenter Stelle (und trägt sich dann auch noch im System- und im User-Environment ein), was dazu führt, dass die ellenlang und die Suche nach ausführbaren .EXE (die mir sowieso nicht sonderlich effizient zu sein scheint) öd langsam wird. Schmeisst man da alles raus, was man nicht braucht, kann man u.U. schon eine deutliche Beschleunigung feststellen (wenn auch die Linux-Performance nie erreicht wird).
gaaanz blöde Frage, ein im Hintergrund laufender Virusscanner hat da keinen Einfluss ? Auf meinen Firmenrechner mit Win10 gehen ca. 1/3 der compilezeit an den McAfee virenscanner, dazu kommt noch, dass die HDD vom McAfee und nicht von der HDD selbst verschlüsselt wird. Hat jemand schon das Win10 feature WSL (Windows Subsystem for Linux) ausprobiert? da würde mich mal der performance unterschied interessieren.
> Hat jemand schon das Win10 feature WSL (Windows Subsystem for Linux) > ausprobiert? Ich habe es letztes Jahr ausprobiert, wollte es als OpenSsh Server nutzen. Hat nicht funktioniert. Selbst beim openssh Client funktionierten nur die Basis-features. Ich nutze lieber CygWin weil es damit einfacher ist, Linux Kommandos mit Windows Kommandos zu mixen. In WSL sind diese beiden Welten ziemlich stark voneinander getrennt. Es ist schon schön, wenn man in der cmd Shell grep nutzen kann oder in der Bash Windows-Programme.
Ich habe gerade mal auf der Arbeit mit einem großen Java Programm getestet (habe dort keine C/C++ Entwicklungsumgebung): 1. build&clean mit Defender und Veracrypt: nicht gewertet 2. build&clean mit Defender und Veracrypt: 7:41 Minuten 3. build&clean mit Veracrypt: 6:51 Minuten Da war der Unterschied jetzt nicht so groß wie ich nach den obigen Hinweisen bezüglich Virenscanner erwartete.
Äh. Ja. Dass die Build-Partition verschlüsselt ist, ist je eher ein nebensächliches Detail und hat ja mit der Build-Geschwindigkeit fast nichts zu tun.
Sicher spielt das eine Rolle, deswegen habe ich es hingeschrieben. Aber daran darf ich momentan nichts ändern.
Stefan U. schrieb: > Sicher spielt das eine Rolle, deswegen habe ich es hingeschrieben. > Aber > daran darf ich momentan nichts ändern. Ich habe auch auf meinem Linux-Laptop ein verschlüsseltes Home-Verzeichnis. Trotzdem ist der (bei vergleichbarer Hardware) locker um ein Mehrfaches schneller als der Windows-Rechner mit Bitlocker + Cylance AV.
Das Effekt tritt meinen Beobachtungen nach auch bei der Arduino-Plattform auf. Während unter Linux das Compilieren ruckzuck vonstatten geht, gibt es unter Windows immer so eine Art "Gedenkminute" in der erstmal gar nichts zu passieren scheint. Die Windows-Nutzer kennen das halt nicht anders, für mich sah das immer wie "kaputte Installation" aus und hab zur Neuinstallation geraten...
Joerg W. schrieb: > "Gedenkminute" Um genau zu sein, sind es drei Gedenksekunden. Hier mal kein ganz kleines Projekt (Rebuild, Zeit inklusive löschen):
1 | ||=== Firmware_all_Targets, STM32F446_Debug ===| |
2 | ||Program size (bytes): 123836| |
3 | ||Data size (bytes): 2492| |
4 | ||BSS size (bytes): 868| |
5 | || ----------------| |
6 | ||Total size (bytes): 127196 (R/W Memory: 3360)| |
7 | ||| |
8 | ||=== Build finished: 0 errors, 27 warnings (0 minutes, 24 seconds) ===| |
Das ist kein "nichts", aber immer noch weit weg von einer Minute. Im Vergleich zu der Zeit, die benötigt wird, um das Programm aufs Target zu schieben, ist es wenig. Was übrigens bei Linux deutlich schneller geht, ist die Ausgabe auf der Konsole. In vielen Fällen bekommt man den Build durch eine Einschränkung der Geschwätzigkeit oder Umleitung in eine Datei noch ein Stück schneller.
:
Bearbeitet durch User
Sheeva P. schrieb: > Natürlich kann man auch unter Linux fertige Applikationen verteilen, und > dank des dabei üblichen Paketmanagement und offener Lizenzen > funktioniert das auch ganz wunderbar Nein, funktioniert es nicht. Linus Torvalds hat dazu auf der Debconf 2014 auch sehr deutliche Worte gefunden, was die Applikations-Distribution unter Linux angeht: "fucking pain in the ass". Der Paketmanager ist da eher ein Ärgernis, weil er OS und Anwendungen zusammenklatscht. Rein für OS und OS-nahe Programme (Grundausstattung wie Bash usw) sowie fürs DE wäre der Paketmanager ja gut, aber nicht für Anwendungen. Zur Geschwindigkeit, ich hab mal einen Test mit einem CPU-begrenzten Programm gemacht. Singlethread und sowohl unter Linux als auch Win-7 mit GCC durchgezogen, auf demselben Rechner natürlich. Das Ergebnis war 10% mehr Performance unter Linux. Allerdings schiebt der Windows-Taskmanager die Berechnungen wahllos zwischen den Kernen herum, anstatt das auf einem Kern zu lassen. Vermutlich kann daher der Turboboost nicht richtig anspringen, das wäre nämlich genau in dieser Größenordnung. Ausgaben auf der Konsole, das kommt sehr drauf an, wie man die macht, und was man für Pufferung auswählt. Wenn dermaßen viel ausgegeben wird, daß das zu Performance-Problemen führt, dann ist die Anwendung dazu aber ohnehin fragwürdig programmiert.
Nop schrieb: > Allerdings schiebt der Windows-Taskmanager die Berechnungen wahllos > zwischen den Kernen herum, anstatt das auf einem Kern zu lassen. Wenn Du das brauchst, kannst Du das beeinflussen. https://msdn.microsoft.com/de-de/library/windows/desktop/ms686247(v=vs.85).aspx
wenn Du mal die Patches für Spectre und Meltdown installiert hast, brauchst Du das eh' nicht mehr...
Rufus Τ. F. schrieb: > Wenn Du das brauchst, kannst Du das beeinflussen. Ich weiß, aber das hat dann Seiteneffekte, denn dann migriert Windows nichtmal dann, wenn es sinnvoll wäre. Also etwa wenn der Thread suspended und wieder aufwacht, dann aber ein anderer Kern als vorher frei wird. Oder wenn nach Überbelegung was frei wird. Besonders bei Hyperthreading oder den AMD-Modulen wäre es besser, wenn man auf einen komplett freien Kern verlegt wird, anstatt sich den bisherigen physikalischen Kern teilen zu müssen. Eigentlich bräuchte man nur eine Funktion, mit der man sagen kann, daß das Herumgeschubse unerwünscht ist, falls es keinen wirklich guten Grund gibt. Idealerweise würde der Scheduler so einen Unsinn ja von selber einfach unterlassen.
Nop schrieb: > daß > das Herumgeschubse unerwünscht ist, falls es keinen wirklich guten Grund > gibt. Idealerweise würde der Scheduler so einen Unsinn ja von selber > einfach unterlassen. Das "Herumgeschubse" dient dazu, dass nicht 1 Kern auf 150°C hoch geht während die anderen bei 25°C rumdümpeln, sondern damit die Hitze in etwa gleich verteilt ist. mfg
Felix F. schrieb: > Das "Herumgeschubse" dient dazu, dass nicht 1 Kern auf 150°C hoch geht > während die anderen bei 25°C rumdümpeln, sondern damit die Hitze in etwa > gleich verteilt ist. Wenn sowas droht, ist das Kühlsystem untauglich, denn offensichtlich kann man in dem Fall nicht alle Kerne auslasten.
Nop schrieb: > Felix F. schrieb: > >> Das "Herumgeschubse" dient dazu, dass nicht 1 Kern auf 150°C hoch geht >> während die anderen bei 25°C rumdümpeln, sondern damit die Hitze in etwa >> gleich verteilt ist. > > Wenn sowas droht, ist das Kühlsystem untauglich, denn offensichtlich > kann man in dem Fall nicht alle Kerne auslasten. Haste eben Intel "Wärmeleitpaste" gesagt ;)? http://www.tomshardware.com/reviews/intel-core-i9-7900x-skylake-x,5092-11.html Selbst ein Intel Heizwell i3 wird auf AVX Belastung so heiß, dass er mit dem Boxelkühler runtertaktet. (nein es ist nicht nur die AVX Taktabsenkung, man sieht, dass er ab 95° nochmal runtergeht) Selbst mit nem jetzt ordentlichen Kühler wird der Knalleheiß wegen der von Intel verbauten Affenscheisse. Ausm Silizium Sensor lese ich 80°, aber der Kühler wird nicht mehr als 60° Warm am Sockel. Mein i5-2500k mit verlöteten Die bleibt auch auf Volllast eiskalt.
Auf meinem Skylake 6600K hätte ich sowas noch nicht beobachtet... Boxed Kühler.. da rennt ne Viertelstunde eine transiente Simulation mit getdp. Alles mit den lustigen intel-blas-libs... also volle Hütte AVX auf Daten die im Cache liegen... Wird warm, ja, aber keine Meldung, dass das System runtertakten würde. HT ist ausgeschalten, und Limit auf einen Core habe ich interessehalber auch mal versucht. Das passt schon. Overclocken von der CPU ist ohnehin Bullshit... viel interessanter ist's dem Speichercontroller Beine zu machen wenn die Daten im Ram liegen müssen... 73
Nop schrieb: > Nein, funktioniert es nicht. Linus Torvalds hat dazu auf der Debconf > 2014 auch sehr deutliche Worte gefunden, was die > Applikations-Distribution unter Linux angeht: "fucking pain in the ass". > Der Paketmanager ist da eher ein Ärgernis, weil er OS und Anwendungen > zusammenklatscht. Rein für OS und OS-nahe Programme (Grundausstattung > wie Bash usw) sowie fürs DE wäre der Paketmanager ja gut, aber nicht für > Anwendungen. Ich kann das Argument (zumindest so wie Du es zusammenfasst) nicht nachvollziehen. Ich kann auch kein Problem in der Praxis beobachten. Mir ist auch nicht klar was "zusammengeklatscht" bedeuten soll und an wen oder was sich die mutmaßliche Kritik überhaupt richtet. Was ich jedoch weiß ist daß Paketmanager zur Softwareinstallation ein wahrer Segen für die Anwender sind, also das genaue Gegenteil von Ärgernis.
Felix F. schrieb: > Das "Herumgeschubse" dient dazu, dass nicht 1 Kern auf 150°C hoch geht > während die anderen bei 25°C rumdümpeln, sondern damit die Hitze in etwa > gleich verteilt ist. Wo hast denn das geträumt?
Dauert bei euch der Build echt so lange, dass da 10% Prozent Geschwindigkeitszuwachs interessant sind?
> Dauert bei euch der Build echt so lange, dass da 10% Prozent > Geschwindigkeitszuwachs interessant sind? Nein, es war mir einfach nur aufgefallen. Deswegen würde ich nicht das Betriebssystem wechseln oder die Sondergenehmigung erbitten, ohne Virenscanner arbeiten zu dürfen.
Walter T. schrieb: > Dauert bei euch der Build echt so lange, dass da 10% Prozent > Geschwindigkeitszuwachs interessant sind? Also wenn auf exakt derselben Hardware ein OS 10% mehr rausholt als ein anderes, dann finde ich das ganz grundsätzlich interessant. Außerdem, wenn man weiß, daß unter Linux neue Prozesse billig sind und unter Windows nicht, dann würde man eine Anwendung, die zumindest AUCH auf Windows laufen soll, sinnigerweise nicht so designen, und das ist ja auch durchaus gut zu wissen.
Nop schrieb: > dann würde man eine Anwendung, die zumindest AUCH > auf Windows laufen soll, sinnigerweise nicht so designen Wenn man dazu das ganze Konzept und bewährte best practices (one job one tool) über den Haufen werfen müsste dann wohl eher nicht. Warum sollte man sich auch von so einem Außenseiter-OS wie Windows die Obergrenze des technisch machbaren limitieren lassen?
Nop schrieb: > Sheeva P. schrieb: >> Natürlich kann man auch unter Linux fertige Applikationen verteilen, und >> dank des dabei üblichen Paketmanagement und offener Lizenzen >> funktioniert das auch ganz wunderbar > > Nein, funktioniert es nicht. Linus Torvalds hat dazu auf der Debconf > 2014 auch sehr deutliche Worte gefunden, was die > Applikations-Distribution unter Linux angeht: "fucking pain in the ass". > Der Paketmanager ist da eher ein Ärgernis, weil er OS und Anwendungen > zusammenklatscht. Rein für OS und OS-nahe Programme (Grundausstattung > wie Bash usw) sowie fürs DE wäre der Paketmanager ja gut, aber nicht für > Anwendungen. Ach, auch Linus redet manchmal Unfug, da bist Du in guter Gesellschaft. ;-) Tatsächlich lassen sich Repositories von Drittanbietern problemlos in jeden besseren Packagemanager integrieren. Zur Auflösung von Abhängigkeiten und viele andere Aufgaben sind die nun einmal die mit Abstand beste Methode -- das dürfte der Grund dafür sein, weshalb nicht nur Linux, sondern auch die kommerziellen UNIXe allesamt mit Paketmanagern arbeiten. Ansonsten gibt es natürlich noch Paketmanager wie 0install, Flatpack und Snappy, die jeweils ihre eigene Paket- und Abhängigkeitswelt aufziehen und dann parallel zum systemweiten Paketmanagement arbeiten, aber sonst alle hübschen Vorzüge des Paketmanagement bieten. Und wem das noch nicht reicht, der nimmt eben Docker oder LXC.
Ich halte das Linux-Paketmanagement durchaus auch für einen Segen; dass da sowohl Anwendungen als auch OS-Pakete "zusammengeklatscht" werden, stellt ja gerade sicher, dass Abhängigkeiten sauber dargestellt und potentielle Konflikte erkannt werden. Warum man allerdings für ein Betriebssystem (Linux) gefühlt 10 verschiedene Paketmanager (für jede Distribution eine?) braucht, entzieht sich meinem Verständnis. Wenn die Entwicklungsaufwände für RPM, APT, Yast, Yum und wasweissich stattdessen in einen Paketmanager eingeflossen wären, wäre der heute sicher besser als alle zusammen...
Bernd K. schrieb: > Wenn man dazu das ganze Konzept Ein Design zu machen bedeutet, das Konzept überhaupt erst zu erstellen. > Warum sollte > man sich auch von so einem Außenseiter-OS wie Windows die Obergrenze des > technisch machbaren limitieren lassen? Weil Windows am Server in der Tat Außenseiter ist, aber am Desktop hat Linux keinen relavanten Marktanteil. Nicht jeder will bloß kostenlose Opensource für eine verschwindend geringe Nutzerschar erstellen. Android wäre, nativ programmiert, ebenfalls als Linux zu sehen, aber auf einem Smartphone ergibt keine Anwendung einen Sinn, die dermaßen viele Prozesse losläßt. Und anyway, ich halte daran fest, daß Paketmanager für mehr als OS und OS-nahe Sachen ein Krampf sind, den sich Linuxnutzer schönreden.
Markus F. schrieb: > Ich halte das Linux-Paketmanagement durchaus auch für einen Segen; dass > da sowohl Anwendungen als auch OS-Pakete "zusammengeklatscht" werden, > stellt ja gerade sicher, dass Abhängigkeiten sauber dargestellt und > potentielle Konflikte erkannt werden. Richtig. > Warum man allerdings für ein Betriebssystem (Linux) gefühlt 10 > verschiedene Paketmanager (für jede Distribution eine?) braucht, > entzieht sich meinem Verständnis. Wenn die Entwicklungsaufwände für RPM, > APT, Yast, Yum und wasweissich stattdessen in einen Paketmanager > eingeflossen wären, wäre der heute sicher besser als alle zusammen... Wenn die Entwickler dieser Werkzeuge sich zusammengetan hätten, um einen Paketmanager zu entwickeln, dann würden sie heute noch diskutieren und es wäre noch keine einzige Zeile Code geschrieben. Solche und ähnliche Aussagen lese ich immer wieder -- "wenn die Entwickler der Distributionen sich zusammengetan hätten", "wenn die Entwickler von Office-Paketen sich zusammengetan hätten", und so weiter. Im Kern ist das auf den ersten Blick ja vielleicht auch nicht ganz falsch, verkennt aber auf einerseits ganz grundsätzlich, wie OpenSource funktioniert ("rough consensus and running code"), und auf der anderen Seite, daß genau dieser Ansatz der Grund dafür ist, daß sich OpenSource-Software so enorm schnell entwickelt und dabei eine so hohe Qualität, Flexibilität, Stabilität und Performanz erreicht -- und warum OSS dem Anwender zudem die Freiheit gibt, wählen zu können, welche Lösung am Besten zu seinem Problem paßt. Daniel Albrecht hat daher zum Beispiel die Freiheit, Devuan mit SysV-Init und LXC-Container statt Debian mit systemd zu benutzen, während ich auf Debian und Ubuntu mit Docker-Containern setze. Wir beide haben gute Gründe für unsere jeweilige Wahl, und dank konkurrierender Implementierungen eben auch die Möglichkeit, die für unseren Anwendungsfall passendste Software auswählen und nutzen zu können. Und am Ende, wie gesagt: ich habe schon in zu vielen kommerziellen und freien Projekten mitgearbeitet, um die oben erwähnte Gefahr, sich zu Tode zu diskutieren und vor lauter Diskussionen nichts, etwas Halbherziges, ein "gewollt ist nicht gekonnt" oder eine inkonsistente Mischung verschiedener Ansätze zu produzieren, nicht zu Genüge aus der Praxis zu kennen. Deswegen ist die OpenSource-Welt so, wie sie ist, und das ist auch gut so. Immerhin ist OpenSource ohnehin nichts für Leute, die mit Freiheit (und dazu zählt natürlich auch die Wahlfreiheit) nichts anzufangen wissen.
Nop schrieb: > Und anyway, ich halte daran fest, daß Paketmanager für mehr als OS und > OS-nahe Sachen ein Krampf sind, den sich Linuxnutzer schönreden. Mich täte interessieren, was daran für dich so krampfig ist... ich arbeite jetzt seit fast 20 Jahren mit Debian, und hatte da noch nie ernsthafte Probleme. im Gegenteil, wenn ich mir so ansehe, wie viel Zeit (wofür eigentlich?) Windows allein mit der Update-Suche verbringt, hat mir das schon gefühlte 2 Jahre Lebenszeit gebracht ;-)
Michael R. schrieb: > Mich täte interessieren, was daran für dich so krampfig ist... Veraltete Anwendungen, Zwang zum Systemupdate, um auch nur halbwegs aktuelle Anwendungen ausführen zu können, die Hürden, um überhaupt Anwendungen da reinzukriegen, Mangel an kommerziellen, ernsthaften Anwendungen, und deswegen der Krampf mit den Tarballs bei kleineren Projekten auf Github, wo weder configure noch install richtig funktioniert. > im Gegenteil, wenn ich mir so ansehe, wie viel Zeit > (wofür eigentlich?) Windows allein mit der Update-Suche verbringt, hat > mir das schon gefühlte 2 Jahre Lebenszeit gebracht ;-) Windows kann genauso wie Linux seine Updates auch selber suchen, da mußt Du nicht die ganze Zeit gebannt auf den Bildschirm starren.
Sheeva P. schrieb: > Wenn die Entwickler dieser Werkzeuge sich zusammengetan hätten, um einen > Paketmanager zu entwickeln, dann würden sie heute noch diskutieren und > es wäre noch keine einzige Zeile Code geschrieben. Auch das ist natürlich ein valides Argument (und den Rest deines Textes kann ich auch nachvollziehen). Trotzdem kann ich als Schwabe nicht aus meiner Haut: schade um die ganze Blindleistung.
Sheeva P. schrieb: > Wenn die Entwickler dieser Werkzeuge sich zusammengetan hätten, um einen > Paketmanager zu entwickeln, dann würden sie heute noch diskutieren und > es wäre noch keine einzige Zeile Code geschrieben. Ist ja direkt ein Wunder, wie die ganzen RFCs zustandegekommen sind, deretwegen das Internet überhaupt funktioniert. Was für ein Glück, daß die heutigen forkwütigen Ego-Darsteller noch in die Windeln gemacht haben, als das festgezurrt wurde. ^^
Nop schrieb: > Michael R. schrieb: > >> Mich täte interessieren, was daran für dich so krampfig ist... > > Veraltete Anwendungen, Zwang zum Systemupdate, um auch nur halbwegs > aktuelle Anwendungen ausführen zu können, Hmm, das kann ich hier nicht nachvollziehen. Zumindest unter Ubuntu erhält man durchaus die aktuellen Versionen - zumindest soweit ich das hier überblicke. > die Hürden, um überhaupt > Anwendungen da reinzukriegen, Neue Repositories (bspw. den nightybuild von FreeCAD oder auch KiCad) kann man problemlos mit einpflegen und parallel laufen lassen. > Mangel an kommerziellen, ernsthaften > Anwendungen, Da versteht jeder etwas anderes drunter - uns bspw. reicht Vielfalt und Leistungsfähigkeit der OSS-Pakete aus. Das ist allerdings kein Problem der Paketmanager. > und deswegen der Krampf mit den Tarballs bei kleineren > Projekten auf Github, wo weder configure noch install richtig > funktioniert. Naja - es ist kein Problem der Paktemanager, wenn Software außerhalb dieser sich nicht so verhält wie sie soll. Das ist dann ein Problem der Projekte. Wobei mittlerweile deutlich mehr viele kleinere Projekte Archive für Debian anbieten - oder eben direkt ein Repository. >> im Gegenteil, wenn ich mir so ansehe, wie viel Zeit >> (wofür eigentlich?) Windows allein mit der Update-Suche verbringt, hat >> mir das schon gefühlte 2 Jahre Lebenszeit gebracht ;-) > > Windows kann genauso wie Linux seine Updates auch selber suchen, da mußt > Du nicht die ganze Zeit gebannt auf den Bildschirm starren. Für den Windows-Kern gilt das - für viele nachträglich installierte Software leider nicht. Ich bin auch vom Debian-Paketsystem überzeugt. Es funktioniert hier einfach.
:
Bearbeitet durch Moderator
> die heutigen forkwütigen Ego-Darsteller
Ich benutze fork() sehr gerne...
Nop schrieb: > Windows kann genauso wie Linux seine Updates auch selber suchen, da mußt > Du nicht die ganze Zeit gebannt auf den Bildschirm starren. Beim Runterfahren abends gehts ja noch, da interessierts mich nicht wenn er noch die halbe Nacht rumrödeln muss bevor er ausgeht, aber was mach ich beim Booten? Soll ich morgens ne halbe Stunde früher am Arbeitsplatz erscheinen oder soll ich einfach ne halbe Stunde Pause machen?
Chris D. schrieb: > Hmm, das kann ich hier nicht nachvollziehen. Google mal nach xscreensaver, das Drama war unterhaltsam. Und das ist nicht die einzige Anwendung, die um Jahre veraltet ausgeliefert wurde. Es ist nur die einzige, wo der Autor dermaßen genervt war über Reports zu längst gefixten Bugs, daß er eine Dialogbox eingebaut hat, die ab zwei Jahren Alter die Anwender nerven würde. Was dann natürlich zu noch mehr Popcorn geführt hat, weil man auf Debianseite nicht nachvollziehen konnte, was der Autor überhaupt wollte. Der war inzwischen SO angefressen, daß alles, was er noch wollte, die Entfernung seines Projektes aus Debian war. > Neue Repositories (bspw. den nightybuild von FreeCAD oder auch KiCad) > kann man problemlos mit einpflegen und parallel laufen lassen. Wie wird die Systemintegrität gesichert? Wie wird das für die verschiedenen Basisdistris getestet? > Da versteht jeder etwas anderes drunter - uns bspw. reicht Vielfalt und > Leistungsfähigkeit der OSS-Pakete aus. Kommt auch drauf an, worin man tätig ist. Für alles, was Geeks brauchen, ist das natürlich top, was kein Wunder ist bei einem System von Geeks für Geeks. Allerdings ist nicht nur die Leistungsfähigkeit ein Argument, sondern vor allem auch die Abwesenheit jeglicher UI-Standards. Und die Tatsache, daß ein System von Programmierern, aber ohne den ganzen Rest eines echten Entwicklungsteams (UI-Designer, UX-Experten etwa) auch dementsprechend aussieht: http://okcancel.com/strips/okcancel20031010.gif > Das ist allerdings kein Problem der Paketmanager. Doch, weil sie ein schlechter Workaround für die Dependency-Hell sind. Flatpak & Co könnten, wie Sheeva schon richtig angemerkt hat, hier was ändern, aber bislang sehe ich noch nicht, daß die wirklich angenommen würden. > Naja - es ist kein Problem der Paktemanager, wenn Software außerhalb > dieser sich nicht so verhält wie sie soll. Doch, es ist ein Problem eines Systems, wo man nicht einfach setup.exe ausführen kann, sondern diesen Workaround hat. Blamegame ist zwar üblich, hat aber noch nie irgendwas verbessert. > Für den Windows-Kern gilt das - für viele nachträglich installierte > Software leider nicht. Nein, und das will der Anwender ja auch gar nicht unbedingt. Wenn ja, kann er das pro Anwendung einstellen. Wenn nicht, dann behält man lieber die gegenwärtige Version. Und das alles ist auch noch ganz unabhängig von Systemupdates, die für die Anwendungen nicht notwendig sind. Das ist alles am Server kein Problem, weil der erstens nicht von Endnutzern betrieben wird und zweitens ohnehin ein Standardset an installierter Software haben soll. Neue Features sind dort nicht wichtig, ganz im Gegenteil (kann ja was zerbrechen), aber Security-Patches sollen verfügbar sein ohne Feature-Updates. Und genau das leistet Linux ganz hervorragend. Am Server würde ich übrigens auch kein Windows wollen. Im Gegenteil, wenn mein Hoster auf die Idee käme, mir den Apache durch einen IIS zu ersetzen, wäre das für mich ein Kündigungsgrund.
Bernd K. schrieb: > Beim Runterfahren abends gehts ja noch, da interessierts mich nicht wenn > er noch die halbe Nacht rumrödeln muss bevor er ausgeht, aber was mach > ich beim Booten? Du läßt Windows einfach die Updates komplett einspielen. Bei Win-7-Geräten ohne SSD am einfachsten, indem Du noch am selben Tag "Updates installieren" klickst und zum Feierabend dann auf "Rechner neu starten". Bei Win-8 mit SSD reicht "aktualisieren und herunterfahren", da ist am nächsten Morgen selbst mit Updates beim Booten so wenig Gerödel, daß es nichtmal mehr zum Holen des ersten Kaffees ausreicht.
Nop schrieb: > Chris D. schrieb: > >> Hmm, das kann ich hier nicht nachvollziehen. > > Google mal nach xscreensaver, das Drama war unterhaltsam. Und das ist > nicht die einzige Anwendung, die um Jahre veraltet ausgeliefert wurde. > Es ist nur die einzige, wo der Autor dermaßen genervt war über Reports > zu längst gefixten Bugs, daß er eine Dialogbox eingebaut hat, die ab > zwei Jahren Alter die Anwender nerven würde. Sicherlich gibt es immer irgendwo Ärger. Ich kann die Aktualität zumindest für die bei uns genutzten größeren Programmpakete bestätigen. Es gibt durchaus auch alte Pakete - das ist aber meist dann der Fall, wenn die Software nicht mehr weiterentwickelt wurde, weil mittlerweile bessere Lösungen existieren. Bei manchen denke ich auch: braucht man die wirklich noch? Aber andererseits: warum nicht? Mich schränkt das ja nicht ein. >> Neue Repositories (bspw. den nightybuild von FreeCAD oder auch KiCad) >> kann man problemlos mit einpflegen und parallel laufen lassen. > > Wie wird die Systemintegrität gesichert? Indem der Paketmanager das neue Repository integiert. Gäbe es Kollisionen, würde dieser meckern. Klappt einwandfrei. > Wie wird das für die > verschiedenen Basisdistris getestet? FreeCAD stellt bspw. für sehr viele Distris Pakete bereit. Ich kann hier aber nur für Ubuntu sprechen und da habe ich quasi jeden Tag ganz automatisch sowohl die offizielle "stabile Version" als auch die "druckfrische Entwicklungsversion" auf dem Rechner und kann diese parallel nutzen. Ebenso bei KiCad (und vermutlich bei vielen weiteren, wir haben aber nur die beiden hinzugefügt). >> Da versteht jeder etwas anderes drunter - uns bspw. reicht Vielfalt und >> Leistungsfähigkeit der OSS-Pakete aus. > > Kommt auch drauf an, worin man tätig ist. Für alles, was Geeks brauchen, > ist das natürlich top, was kein Wunder ist bei einem System von Geeks > für Geeks. Wir arbeiten hier ganz normal damit, machen unsere Entwicklungen, unsere Office-Arbeiten, (E-)CAD, Softwareentwicklung etc. Man muss kein Geek sein, um mit diesen Programmen produktiv zu sein. > Allerdings ist nicht nur die Leistungsfähigkeit ein Argument, sondern > vor allem auch die Abwesenheit jeglicher UI-Standards. Und die Tatsache, > daß ein System von Programmierern, aber ohne den ganzen Rest eines > echten Entwicklungsteams (UI-Designer, UX-Experten etwa) auch > dementsprechend aussieht: > > http://okcancel.com/strips/okcancel20031010.gif Das ist aber auch kein Argument gegen Paketmanager. >> Naja - es ist kein Problem der Paktemanager, wenn Software außerhalb >> dieser sich nicht so verhält wie sie soll. > > Doch, es ist ein Problem eines Systems, wo man nicht einfach setup.exe > ausführen kann, sondern diesen Workaround hat. Blamegame ist zwar > üblich, hat aber noch nie irgendwas verbessert. Es ist bei OSS nun einmal so, dass Dir immer die Quellen zur Selbstübersetzung Verfügung gestellt werden. Wer das nicht möchte, greift zu einem Paketmanager. Die Vielzahl der Linux-Derivate würde es auch ad absurdum führen, für jede Distribution ein Paket zu schnüren. Das "Problem" hat man unter Windows nicht - es gibt da nur eine Plattform. Übrigens gibt es natürlich auch unter Linux kommerzielle Software, die sich mit einem "./install.sh" installieren lässt. Aber eben nicht für alle Distributionen. >> Für den Windows-Kern gilt das - für viele nachträglich installierte >> Software leider nicht. > > Nein, und das will der Anwender ja auch gar nicht unbedingt. Und wenn er es doch möchte? Ich möchte das bei 95% meiner Nutzprogramme haben und nicht ständig alles auf neue Versionen untersuchen müssen. > Wenn ja, > kann er das pro Anwendung einstellen. Wenn nicht, dann behält man lieber > die gegenwärtige Version. Und das alles ist auch noch ganz unabhängig > von Systemupdates, die für die Anwendungen nicht notwendig sind. Das geht selbstverständlich auch mit einem Paketmanager. Der Debian-Paketmanager zeigt mir vor jedem Update an, was erneuert wird, was wegfällt usw. Ich kann dann entscheiden: Software, die ich auf aktuellem Stand einfrieren möchte, trage ich hier nur in die Liste ein (bzw. andere entfernen das Häkchen) - dann wird sie ausgenommen. Das funktioniert unter dem Ubuntu-System sehr gut. Und natürlich kann man auch dafür sorgen, dass der Paketmanager sich das merkt :-)
:
Bearbeitet durch Moderator
Nop schrieb: > Allerdings ist nicht nur die Leistungsfähigkeit ein Argument, sondern > vor allem auch die Abwesenheit jeglicher UI-Standards. Also wie bei Windows. Da ist die GUI total inkonsistent und sieht überall anders aus. z.B.: https://filestore.community.support.microsoft.com/api/images/751202c9-35ed-42f6-953b-32ae1fa4e015 https://twitter.com/zacbowden/status/619947511868997632 In der Systemsteuerung hat jedes Fenster ein anderes Design - je nachdem aus welcher Windows Version es stammt, bis zurück zum guten alten Windows 2000 Design. Wenn man unter deutschem Windows 10 den Geräte-Manger sucht, muss man in der Start-Menü-Suche "Gerät" eingeben. Wenn man "Geräte" eingibt, findet er den Geräte-Manager nicht mehr. Die schnellste und einzig immer funktionierende Art und Weise den zu finden ist es, WinKey+R zudrücken und "devmgmt.msc" einzugeben. Total nutzerfreundlich. Altbekanntes Beispiel sind die Netzwerk-Verbindungen. Die findet man unter jeder Windows Version woanders. Über die Startmenü-Suche findet man die gar nicht. Im Gegensatz zu Linux kann man die Hotkeys für die Fenster-Verwaltung nicht anpassen. WinKey+F1 ist im explörer.exe hart kodiert und kann nicht überschrieben werden. Man kann keine Hotkeys für die Desktops zuordnen (sehr schade - sonst wären die enorm nützlich). Da gibt es bestimmt noch 1000 weitere Punkte. Da ist mir Ubuntu mit der konsequenten Nutzung von Gtk+ und dem damit einhergehenden konsistenten Design und Nutzerführung doch deutlich lieber. Der Network Manager wird da auch nicht mit jeder Version tiefer versteckt...
Tut mir echt leid Nop, aber was du hier alles schreibst ist schlicht weg Mist bzw. nur die halbe Wahrheit. Nop schrieb: > Veraltete Anwendungen, Zwang zum Systemupdate, um auch nur halbwegs > aktuelle Anwendungen ausführen zu können, die Hürden, um überhaupt > Anwendungen da reinzukriegen, Mangel an kommerziellen, ernsthaften > Anwendungen, und deswegen der Krampf mit den Tarballs bei kleineren > Projekten auf Github, wo weder configure noch install richtig > funktioniert. Veraltete Anwendungen sind ein Problem der konkreten Distribution. Nimm Arch oder Gentoo und du hast immer die aktuellsten Versionen. Der "Zwang" zum Systemupdate haellt sich in grenzen und ist unter Windows genauso vorhanden. Nop schrieb: > Google mal nach xscreensaver, das Drama war unterhaltsam. Und das ist > nicht die einzige Anwendung, die um Jahre veraltet ausgeliefert wurde. > Es ist nur die einzige, wo der Autor dermaßen genervt war über Reports > zu längst gefixten Bugs, daß er eine Dialogbox eingebaut hat, die ab > zwei Jahren Alter die Anwender nerven würde. Das ist ein Distributions spezifisch Problem, in dem konkreten Fall war das Debian. https://www.heise.de/newsticker/meldung/Screensaver-bei-Debian-Software-mit-Verfallsdatum-3172970.html
1 | In einem erklärenden Blog-Beitrag (und im Quelltext von Xscreensaver) |
2 | erläutert Zawinski die Gründe für den Hinweis – und beklagt die Reaktion |
3 | der Debian-Community: Dort fordert ein Bug-Report von Anfang April dazu |
4 | auf, die Warnmeldung aus Xscreensaver zu entfernen. Klar, Xscreensaver |
5 | ist Open Source unter BSD-Lizenz, und der Paket-Maintainer darf eine |
6 | veränderte Version von Xscreensaver erstellen und über die |
7 | Debian-Distribution verteilen. |
8 | |
9 | Zawinski wünscht sich allerdings einen anderen Umgang mit dem Problem: |
10 | Entweder sollten Distributoren eine halbwegs aktuelle Version seiner |
11 | Software vertreiben – oder aber Xscreensaver gar nicht mehr verwenden. |
12 | Die derzeitige Situation mache alle unglücklich: Die Entwickler müssten |
13 | sich mit Beschwerden wegen Fehlern rumärgern, die längst repariert sind, |
14 | und Anwender wüssten nicht, wie sie eine neuere Version der Software in |
15 | ihre Distribution einbauen können. |
Das hat im Allgemeinen also weder was mit Linux noch mit dem Paketmanager zu tun, sondern mit der konkreten Distribution. Nop schrieb: > Was dann natürlich zu noch mehr Popcorn geführt hat, weil man auf > Debianseite nicht nachvollziehen konnte, was der Autor überhaupt wollte. > Der war inzwischen SO angefressen, daß alles, was er noch wollte, die > Entfernung seines Projektes aus Debian war. Das Problem war, das der Entwickler seine Patches nicht sauber getrennt hat. Da hat dann ein Patch schon mal sowohl Bugfixes als auch neue Sachen, die mit dem Bug nichts zu tun haben. Und da haben sich die Debianmaintainer quergestellt. Haette der Entwickler die Patches sauber getrennt, waere das kein Problem gewesen und die Debianmaintainer haetten den Bugfix eingespielt. Debian ist nun mal eine sehr zurueckhaltene Distri, weil der Fokus eben auf stabilitaet liegt. Da ist es doch logisch, das du nicht immer die aktuellsten Versionen erhaeltst. Wer auf Debian & Co. setzt, und dann ueber veraltete Pakete mault, sollte sich vielleicht mal an die eigene Nase fassen. Du willst immer aktuelle Pakete? Dann nimm eine Distri die dir das frei haus bietet, z.B. Arch und Gentoo. Gleiches gilt auch fuer Sicherheitspatches. Bei Arch bekomme ich das einfach so, bei Debian muss man dafuer erst ein Repo eintragen. https://www.debian.org/security/
1 | In order to receive the latest Debian security advisories, subscribe |
2 | to the debian-security-announce mailing list. |
3 | |
4 | You can use apt to easily get the latest security updates. This |
5 | requires a line such as |
6 | |
7 | deb http://security.debian.org/debian-security stretch/updates main contrib non-free |
8 | |
9 | in your /etc/apt/sources.list file. Then execute apt-get update && apt-get |
10 | upgrade to download and apply the pending updates. The security archive |
11 | is signed with the normal Debian archive signing keys. |
Auch hier wieder: Ein Distributionsspezifisches Problem, und kein(!) allgemeines. Nop schrieb: > Doch, weil sie ein schlechter Workaround für die Dependency-Hell sind. Wovon redest du eigentlich? Unter Arch habe ich null Probleme mit irgendwelchen Abhaengigkeiten. Nop schrieb: > Nein, und das will der Anwender ja auch gar nicht unbedingt. Wenn ja, > kann er das pro Anwendung einstellen. Wenn nicht, dann behält man lieber > die gegenwärtige Version. Auch hier verstehe ich dein Problem nicht. Ich kann ganz gezielt Anwendungen updaten, bzw. eine Anwendung von dem Update ausnehmen. Und wenn ich eine Anwendung update, und die dann nicht geht, kann ich genauso einfach die alte Version installieren. Zeig mir doch mal wie du unter Windows, ohne Krampf(!), die vorherige Version installierst. Da faengt der Rotz dann doch erst an. Deinstallieren, neu installieren, etc... Bei mir sieht das so aus:
1 | yaourt -Syyu |
2 | ... |
3 | neue Version: Anwendung-XY-1.15 |
4 | Update einspielen? j/n |
Oh, die neue Version ist buggy? Egal, eben die alte Version installieren:
1 | yaourt -U /var/cache/pacman/pkg/Anwendung-XY-1.14.pkg.tar.xz |
Ist alles kein Problem und verursacht auch keine Schmerzen. Keine Ahnung von wann deine Erfahrungen sind, aber aktuell sind sie definitv nicht.
:
Bearbeitet durch User
Kaj G. schrieb: > Tut mir echt leid Nop, aber was du hier alles schreibst ist > schlicht weg Mist bzw. nur die halbe Wahrheit. Naja, es ufert aus und ist eh Offtopic.. von meiner Seite aus nur soviel: Mich wundert der nicht existente Marktanteil von Desktoplinux nicht. Wenn in einer Marktwirtschaft ein Gut sich nicht einmal zum Nullpreis nennenswert verbreitet, dann sagt das Einiges.
Nop schrieb: > Mich wundert der nicht existente Marktanteil von Desktoplinux > nicht. Die vorherrschende Stellung von Windows resultiert gewiss hauptsächlich aus dem Vendor-Lock-In, eben daraus dass sehr viel Software nur dafür verfügbar ist - ein sich selbst verstärkender Effekt. Selbst Mac OS, welches ja sehr stark auf Usability setzt, hat einen vergleichsweise geringen Marktanteil, der sich aber auch mehr aus "Kult-Status" und "Lifestyle" denn aus konkreten Produktmerkmalen nährt. Dazu kommt, dass Microsoft PC-Hersteller mehr oder weniger dazu zwingt, PC's mit Windows auszuliefern und allgemein eine Menge Marketing betreibt. Keiner macht Werbung für Desktop-Linux... Bei den wenigen Fällen, wo Hersteller PC's mit Linux ausgeliefert haben, haben sie es leider geradezu mutwillig vermurkst, indem sie stark eingeschränkte Distributionen genutzt haben, was die Kunden nicht besonders erfreut hat. Das Anhängen an Windows ist wie bei Religion - einmal mit Windows aufgewachsen, bleibt man auch dabei, und stört sich an jeder kleinen Macke der Alternativen, und übersieht großzügig die Probleme von Windows. Natürlich sind Linux-Systeme auch nur das geringere Übel, aber gerade Paket-Manager sind etwas was man unter Windows schmerzlich vermisst... Und Chocolatey & Co sind keine Alternative zu z.B. APT. Allein schon wegen der Qualität & Stabilität der Implementation.
Dr. Sommer schrieb: > Das Anhängen an Windows ist wie bei Religion Was natürlich bei den Linuxern komplett anders ist. Die Bewertung des absolut sinnvollen und zweckmäßigen zweiten Beitrags dieses Threads ist ja ein deutliches Zeichen für die Weltoffenheit der GNU-Hirsche.
Dr. Sommer schrieb: > Dazu kommt, dass > Microsoft PC-Hersteller mehr oder weniger dazu zwingt, PC's mit Windows > auszuliefern und allgemein eine Menge Marketing betreibt. Keiner macht > Werbung für Desktop-Linux... Eine weitere, nicht unwichtige Frage: Wie misst man die Verbreitung eines OS, das sich jeder selbst herunterladen und vielfach installieren kann, ohne dass irgendjemand davon etwas mitbekommt? Unsere acht Desktop-Rechner hier tauchen sicherlich nirgendwo in der Statistik auf :-) Mir persönlich ist das (und auch die vielen Derivate) eigentlich sehr Recht - das erspart uns die Malware, Virenscanner und den ganzen Kram.
:
Bearbeitet durch Moderator
Walter T. schrieb: > Die Bewertung des > absolut sinnvollen und zweckmäßigen zweiten Beitrags dieses Threads ist > ja ein deutliches Zeichen für die Weltoffenheit der GNU-Hirsche. Ich weiß nicht wie der sachlich korrekte Beitrag und dessen verdient positive Bewertung auf die Weltoffenheit von Hirschen oder Nichthirschen schließen lässt. Beim besten Willen nicht.
Nop schrieb: > Chris D. schrieb: >> Neue Repositories (bspw. den nightybuild von FreeCAD oder auch KiCad) >> kann man problemlos mit einpflegen und parallel laufen lassen. > > Wie wird die Systemintegrität gesichert? Wie wird das für die > verschiedenen Basisdistris getestet? Langsam frage ich mich, warum Du in jedem Linux-Thread aufpoppst und da jedesmal inkompetentes Offtopic-Gesabbel abseiherst. Bist Du so ein "Microsoft Most Valuable Professional" (MVP) und wirst von Microsoft mit verbilligten Lizenzen bezahlt? Oder bist nur so ein Moby, der es nicht ertragen kann, wenn jemand etwas Positives über Linux oder etwas Negatives über Windows sagt?
Chris D. schrieb: > Wie misst man die Verbreitung eines OS, das sich jeder selbst > herunterladen und vielfach installieren kann, ohne dass irgendjemand > davon etwas mitbekommt? http-Requests oder Umfragen würde ich mal meinen. Beides hat natürlich seine Tücken aber bei SO gab es erst kürzlich eine Umfrage zu dem Thema: https://insights.stackoverflow.com/survey/2018/#development-environments-and-tools Walter T. schrieb: > Dr. Sommer schrieb: >> Das Anhängen an Windows ist wie bei Religion > > Was natürlich bei den Linuxern komplett anders ist. Der Unterschied ist der, dass ein durchschnittlicher Linux-User überdurchschnittlich viel Ahnung von Windows hat, weil er eben (gewollt oder nicht) damit aufgewachsen ist. Umgekehrt trifft das aber eben in absolut keinster Weise zu.
Jedenfalls kann ich alle meine Programme sowohl unter Linux als auch unter Windows compilieren. Da ich beim Hobby unter beiden Betriebssystemen weitgehend die selben Entwicklungsumgebungen und Tools benutze, habe ich die Freiheit, nach Lust und Laune hin und her zu wechseln. Und wisst ihr was: Beide Betriebssysteme sind für mich Ok, haben unterschiedliche Vor- und Nachteile und sind nicht perfekt. Momentan ist Linux mein Favorit, weil Windows mich in den letzten 2 Jahren mit Probleme bei und nach Updates genervt hat.
Wie gut dass -j bei make wirkt, hängt in erster Linie davon ab ob die Abhängigkeiten richtig und vollständig in den Makefiles erfasst sind. Bei ein paar Handvoll Quellcodedateien in einem Verzeichnis keine Sache. Aber bei einigen hundert Quellcodedateien, verteilt in mehrstufigen Unterverzeichnisse (sinnvoll modularisiertes Projekt, mit Libs) kommt es sehr auf die Details an, z.B. ist rekursives make schlecht für kurze Buildzeiten.
Markus F. schrieb: > Sheeva P. schrieb: >> Wenn die Entwickler dieser Werkzeuge sich zusammengetan hätten, um einen >> Paketmanager zu entwickeln, dann würden sie heute noch diskutieren und >> es wäre noch keine einzige Zeile Code geschrieben. > > Auch das ist natürlich ein valides Argument (und den Rest deines Textes > kann ich auch nachvollziehen). Trotzdem kann ich als Schwabe nicht aus > meiner Haut: schade um die ganze Blindleistung. Das ist aber keine Blindleistung, sondern vielmehr genau der Wettbewerb, der bekanntlich das Geschäft belebt. Und während sich im ökonomischen Wettbewerb häufig nicht der Beste, sondern der Billigste oder leider oft auch jener mit den unfairsten Methoden durchsetzt, konkurrieren OpenSource-Projekte meist über Funktionalität, Flexibilität, Stabilität, Usability und Lizenzmodell. Wie man am Erfolg von Linux sieht, welches sich ohne riesige Marketingbudgets und ohne zentrale Organisation inzwischen zum Marktführer in zentralen Bereichen Server, Embedded, Super-, Distributed-, und Cloud-Computing gemausert hat, funktioniert dieses Modell ausgesprochen gut. Daß die Desktop- und Office-Monopole noch nicht gefallen sind: geschenkt. Die verteidigt deren Platzhirsch ja auch mit unglaublich großem Aufwand, viel Geld und häufig halbseidenen Methoden. Letzten Endes ist aber gerade dies wiederum ein Ausweis der hohen Leistungsfähigkeit von Linux und des Drucks, unter den besagter Hersteller dadurch gesetzt wird. Denn wenn es wirklich so wäre, daß Linux ein "von Hobbyprogrammierern am Küchentisch" zusammengestoppelt wäre, wie es der wegen seines eigenwilligen Tanzstils bekannt gewordene Ex-CEO dieses Herstellers einmal geäußert hat, müsste besagter Hersteller sich weder so viel Mühe noch die Blöße geben, wegen halbseidener Geschäftspraktiken zu hohen Strafen verurteilt zu werden. Letzten Endes profitieren aber auch die Nutzer anderer Software von der enormen Leistungsfähigkeit von Linux. Ohne diesen Wettbewerber hätte der Monopolist nämlich keinen Anreiz, seine Produkte zu verbessern oder sie billiger zu machen -- und beides hat er in den letzten Jahren deutlich getan. So schließt sich der Kreis zum erwähnten Wettbewerb, von welchem letztlich alle durch bessere und preiswertere Software profitieren.
Sheeva P. schrieb: > Ohne diesen Wettbewerber hätte der > Monopolist nämlich keinen Anreiz, seine Produkte zu verbessern oder sie > billiger zu machen -- und beides hat er in den letzten Jahren deutlich > getan. Ich kann weder noch erkennen, ganz im Gegenteil. Wenn man zB SQL- oder BizTalk-Lizenzänderungen ansieht, könnte man meinen, da sieht jemand seine Felle davonschwimmen, und melkt nochmal schön.
Nop schrieb: > Sheeva P. schrieb: >> Wenn die Entwickler dieser Werkzeuge sich zusammengetan hätten, um einen >> Paketmanager zu entwickeln, dann würden sie heute noch diskutieren und >> es wäre noch keine einzige Zeile Code geschrieben. > > Ist ja direkt ein Wunder, wie die ganzen RFCs zustandegekommen sind, > deretwegen das Internet überhaupt funktioniert. Was für ein Glück, daß > die heutigen forkwütigen Ego-Darsteller noch in die Windeln gemacht > haben, als das festgezurrt wurde. ^^ Anscheinend hast Du noch keinen RFC gelesen und weißt wohl auch nicht, was die Abkürzung "RFC" überhaupt bedeutet, nämlich "request for comment". Auf einem RFC prangen nämlich ganz oben die Namen seiner Autoren, und das sind nur sehr selten mehr als eine Handvoll. Da haben sich also einige Menschen zusammengesetzt und einen Vorschlag für einen Standard erarbeitet. Dieser kann dann angenommen, also akzeptiert und verwendet werden, dadurch wird dann aus dem Vorschlag ein Standard. Übertragen auf die Softwareentwicklung passiert im OpenSource-Bereich etwas sehr Ähnliches. Nur, daß in diesem Prozess keine Standarddokumente, Lasten- oder Pflichtenhefte zur Diskussion gestellt werden, stattdessen wird einer Anwendergemeinde eine lauffähige Software vorgestellt. Und dann sind es die Anwender, die darüber entscheiden, ob sie diese Software nutzen können und wollen, oder eben nicht. Im ersten Fall setzt sich die Software durch. In beiden Fällen ist es meistens eine kleine Gruppe von Menschen, die erst ihre Ideen und Lösungsvorschläge ausarbeitet und dann der Öffentlichkeit zuführt, die dann dann darüber entscheidet, ob sich der Standard oder die Software durchsetzen oder eben nicht. Daß übrigens ausgerechnet Du über "Ego-Darsteller" spottest, finde ich ausgesprochen witzig. TY, YMMD!
Eigentlich ging es doch mal um die Frage, warum die Laufzeiten eines speziellen Programms stark vom OS abhängt. Und die schlichte Antwort, daß es da Designunterschiede gibt, die sich auswirken. Nun wieder das bekannte meins-deins-Geprügel. Schade! Es scheint an dem Assembler-Befehl zu liegen, der nur den Zweck hat, Zeit zu verplempern. Also der perfekte NickName.
Karl Käfer schrieb: > Langsam frage ich mich, warum Du in jedem Linux-Thread aufpoppst und da > jedesmal inkompetentes Offtopic-Gesabbel abseiherst. Guck Dir das zweite Posting im Thread an, dann weißt Du, wer hier wo mit inkompetentem Offtopic-Gesabbel aufpoppt. Aber das ist auch so ein Phänomen in Linuxkreisen, diese aggressive Haltung, mit der erst jegliche Kritik abgebügelt wird, und man kann die Uhr danach stellen, wann das direkt in Beschimpfung ausartet. Sheeva P. schrieb: > Übertragen auf die Softwareentwicklung passiert im OpenSource-Bereich > etwas sehr Ähnliches. Nein, tut es nicht. Deine Aussage war "dann würden sie heute noch diskutieren und es wäre noch keine einzige Zeile Code geschrieben", und dem ist bei den RFCs offensichtlich nicht so, denn sonst hätten wir keine Grundlage für interoperable Protokolle und daher darauf aufbauend auch keine Applikationen.
Nop schrieb: > Google mal nach xscreensaver, das Drama war unterhaltsam. Und das ist > nicht die einzige Anwendung, die um Jahre veraltet ausgeliefert wurde. > Es ist nur die einzige, wo der Autor dermaßen genervt war über Reports > zu längst gefixten Bugs, daß er eine Dialogbox eingebaut hat, die ab > zwei Jahren Alter die Anwender nerven würde. Ja, unterhaltsam war's, aber eigentlich nur ein Beispiel dafür, daß Jamie Zawinski die Releasepolicy von Debian nicht verstanden hat. Debian ändert keine Paketversionen im Stable Release, und das ist auch der Grund dafür, weshalb Debian so gerne auf Servern eingesetzt wird. Da bleiben innerhalb eines Stable Release nämlich alle Schnittstellen gleich, so daß man weder etliche gigabyte-großen Versionen eines .NjET-Framework installieren noch sich irgendwelche Sorgen darüber machen muß, daß eine Software nach einem Update nicht mehr funktioniert. Trotzdem werden Bugfixes natürlich auch in das Stable Release eingepflegt, weswegen mir es etwas schwer fällt, Jamies Argument sonderlich ernst zu nehmen. Solche Probleme kannten Microsoft-Kunden noch vor wenigen Jahren so gut, daß viele sich gar nicht mehr getraut haben, ein Update zu machen. Bis heute liest man nicht nur, aber auch hier im Forum viele Anwender, die immer noch das längst abgekündigte und nicht mehr mit Sicherheitsupdates versorgte XP benutzen, aus Angst, daß dann entweder ihre Software nicht mehr läuft oder keine Treiber für ihre ältere Hardware erhältlich sind. Irgendwie erscheint mir das wesentlich dramatischer zu sein, als dieses Anekdötchen von Jamie Zawinski und seinem xsceensaver. Genau diesem Update-Problem wollen die Debian-Leute entgegenwirken, indem sie eine extrem konservative Releasepolicy pflegen. Deswegen benutzen wir Debian auf dem Server und müssen unsere Softwarekomponenten nur anpassen, wenn ein neues Stable Release ansteht. Dabei würde ich ganz persönlich mir beim Debian-Projekt eine etwas verlässlichere Zeitlinie wünschen, und aus diesem Grund haben wir vor einigen Wochen beschlossen, nicht mehr Debian, sondern Ubuntu LTS auf unseren Servern zu benutzen, weil das eine stabile, vorhersagbare Releasepolicy implementiert. Bei RHEL ist die Sache übrigens richtig übel, denn da bringt sogar die aktuellste Version 7.4 noch einen uralten C/C++-Compiler in Version 4.8 mit, der nicht einmal C++11 unterstützt, geschweige denn C++17. Immerhin bietet RedHat mit dem Developer Toolset DTS eine Möglichkeit, zusätzlich zum uralten Default-Compiler eine aktuellere GCC-Version zu installieren. Aber mal im Ernst: Releasepolicies sind keine Probleme von Linux, sondern solche einzelner Distributoren. Daß man zuverlässige und vorausplanbare Releases mit aktueller Software machen kann, beweisen Ubuntu und seine Derivate seit vielen Jahren immer wieder und sehr stabil.
Bernd K. schrieb: > Nop schrieb: >> Windows kann genauso wie Linux seine Updates auch selber suchen, da mußt >> Du nicht die ganze Zeit gebannt auf den Bildschirm starren. > > Beim Runterfahren abends gehts ja noch, da interessierts mich nicht wenn > er noch die halbe Nacht rumrödeln muss bevor er ausgeht, Mich schon. Denn ich habe keine Lust, ewig zu warten, bevor der Laptop endlich ausgeht und ich ihn in die Tasche stecken kann. Vor allem, wenn man dringend mit Rechner zu einem Termin muss, ist es echt ätzend, wenn dann auf dem Bildschirm für 20 Minuten "Schalten Sie den Computer nicht aus!" steht…
Walter T. schrieb: > Dr. Sommer schrieb: >> Das Anhängen an Windows ist wie bei Religion > > Was natürlich bei den Linuxern komplett anders ist. Da kann ich natürlich nur für mich sprechen, aber ich kämpfe nicht für das Evil Empire -- eigentlich sogar nicht einmal dagegen, von mir aus kann und soll bitte jeder Windows benutzen, der das will. Allerdings werde ich mein kleines Reich des Guten verteidigen, wenn jemand wie Nop versucht, das mit Halb- und Unwahrheiten nieder zu machen oder mich zum Idioten zu erklären, weil ich mich gegen ihn und seine Komplizen entschieden habe und kein Teil seines Evil Empire sein und werden will. ;-) > Die Bewertung des > absolut sinnvollen und zweckmäßigen zweiten Beitrags dieses Threads ist > ja ein deutliches Zeichen für die Weltoffenheit der GNU-Hirsche. LOL Da mußt Du aber noch ein bisschen dran basteln, damit daraus so etwas wie ein Argument wird. Und wer sagt, daß da nicht auch ein paar frustrierte Windows-Anwender auf "lesenswert" geklickt haben? Ein erheblicher Teil der mir persönlich bekannten Windows-Anwender ist nicht besonders glücklich mit dem System und der darauf laufenden Software, und ein anderer, ebenfalls recht umfangreicher Teil derselben Windows-Anwender wäre schon glücklich, wenn er wenigstens eine Wahl hätte.
Christopher J. schrieb: > Chris D. schrieb: >> Wie misst man die Verbreitung eines OS, das sich jeder selbst >> herunterladen und vielfach installieren kann, ohne dass irgendjemand >> davon etwas mitbekommt? > > http-Requests oder Umfragen würde ich mal meinen. Beides hat natürlich > seine Tücken aber bei SO gab es erst kürzlich eine Umfrage zu dem Thema: > https://insights.stackoverflow.com/survey/2018/#development-environments-and-tools Also wenn Du mich umbringen willst, war das ein guter Versuch. Jedenfalls wäre ich vor Lachen gerade fast erstickt. ;-) Aber ok, ich bin da sehr robust. Viel spannender finde ich eigentlich, was diese Umfrage zum Thema Plattformen sagt, nämlich: [1]. Bei den am meisten geliebten Plattformen liegt Linux mit 76,5 % ganz vorne, während "Windows Desktop and Server" auf Platz 13 liegt. Andererseits kommt Linux bei den "meistgefürchteten" Plattformen gar nicht vor, während "Windows Desktop and Server" dort auf Platz 14 und "Windows Phone" sogar auf 5 steht. Bei den "mot wanted platforms" hingegen liegt Linux auf Platz 4, "Windows Desktop and Server" hingegen findet sich erst auf Platz 16. Auch bei den "Platforms" [2] liegt Linux zwar nicht allzu weit, aber doch relativ eindeutig vor "Windows Desktop and Server" auf Platz 2, sowohl insgesamt als auch bei den professionellen Entwicklern. Ansonsten: Visual Gedöns gibts längst auch unter Linux, genauso wie den Microsoft SQL Server. Weiß keiner und nutzt keiner, is aber so. ;-) [1] https://insights.stackoverflow.com/survey/2018/#technology-most-loved-dreaded-and-wanted-platforms [2] https://insights.stackoverflow.com/survey/2018/#technology-platforms
Michael R. schrieb: > Sheeva P. schrieb: >> Ohne diesen Wettbewerber hätte der >> Monopolist nämlich keinen Anreiz, seine Produkte zu verbessern oder sie >> billiger zu machen -- und beides hat er in den letzten Jahren deutlich >> getan. > > Ich kann weder noch erkennen, ganz im Gegenteil. Wenn man zB SQL- oder > BizTalk-Lizenzänderungen ansieht, könnte man meinen, da sieht jemand > seine Felle davonschwimmen, und melkt nochmal schön. Lieben Dank für Deinen Hinweis, aber bisher konnte ich mich immer sehr gut davor drücken, die Lizenzen kommerzieller Software zu lesen. Das werde ich auch weiterhin so halten, fürchte ich. ;-) Das ändert aber nichts daran, daß Microsoft seine Lizenzen für Windows und Office heute wesentlich preiswerter anbietet als noch vor ein paar Jahren. Und es ändert auch nichts daran, daß Microsoft die Architektur seit einigen Jahren deutlich verbessert hat. Daß die Informatiker diese Änderungen schon lang davor empfohlen haben, hat Microsoft früher nie interessiert, und daß einige der Änderungen schlicht eine zwangsweise Folge davon sind, um die modernen Multicore- und SMP-Architekturen sauber unterstützen zu können: geschenkt. Fakt ist: Windows ist wesentlich stabiler, in vieler Hinsicht auch sicherer und an manchen Stellen auch einfach besser geworden. Versteh' mich bitte nicht flashc, ich habe keinerlei Interesse daran, hier oder woanders Werbung für MS zu machen. Aber wenn sie auch mal was richtig machen, dann erkenne ich das natürlich an und sage das auch. ;-)
Nop schrieb: > Karl Käfer schrieb: >> Langsam frage ich mich, warum Du in jedem Linux-Thread aufpoppst und da >> jedesmal inkompetentes Offtopic-Gesabbel abseiherst. > > Guck Dir das zweite Posting im Thread an, dann weißt Du, wer hier wo mit > inkompetentem Offtopic-Gesabbel aufpoppt. Ach Du liebe Güte, auf so ein Sprüchlein springst Du schon an? Da muß die Not ja wirklich groß sein. :-) > Sheeva P. schrieb: >> Übertragen auf die Softwareentwicklung passiert im OpenSource-Bereich >> etwas sehr Ähnliches. > > Nein, tut es nicht. Deine Aussage war "dann würden sie heute noch > diskutieren und es wäre noch keine einzige Zeile Code geschrieben", und > dem ist bei den RFCs offensichtlich nicht so, denn sonst hätten wir > keine Grundlage für interoperable Protokolle und daher darauf aufbauend > auch keine Applikationen. LOL Im OpenSource-Umfeld wird auch viel diskutiert, genauso übrigens wie bei den RFCs. Aber das ändert nichts daran, daß in beiden Fällen zunächst eine eher überschaubare Gruppe von Menschen einen Vorschlag ausarbeitet, einerseits in Form eines Standardvorschlags (RFC) und andererseits in Form einer konkreten Software (OpenSource). In beiden Fällen setzt sich dieser Vorschlag dann entweder durch, oder eben nicht. Betrachten wir das anhand eines Beispiels: seit vielen Jahren haben sich die Linux-Systementwickler darüber Gedanken gemacht, wie man ein modernes, paralleles Bootsystem umsetzen kann, das aktuelle Hardwarearchitekturen (think Multicore, SMP, NUMA, SSD, NVME, ...) unterstützt. Da hat es ein paar Ansätze gegeben, das runit-System von Void Linux etwa, OpenRC von Gentoo, und Canonicals Upstart, das einige Ubuntu-Versionen hatten. Lennert Poettering und Kay Sievers haben dann ein neues Initsystem namens systemd entwickelt und der Nutzergemeinde vorgestellt. Mittlerweile, und zum Leidwesen meines hochgeschätzten Kollegen Daniel Albrecht, ist dieses systemd zum Standard in allen Major-Distributionen geworden. Dabei ist genau das abgelaufen, was bei RFCs auch passiert: erst schlagen einige wenige Leute etwas vor, und wenn es gut ist, dann setzt es sich in der Breite durch -- wie eben systemd.
Da der Thread jetzt sowieso bei OffTopic gelandet ist:
Der "Witz" an dem Ganzen ist ja, insbesondere im Real Live, dass Leute
die gerne mal über Linux sticheln ("siehst du, ... geht nur mit
Windows") bei Problemen sofort persönlich beleidigt sind, wenn ich ihnen
dann sage, dass es ein Windows-Problem und somit IHR Problem ist.
Das hat aber nix mit religiösem Eifer zu tun, vielleicht kommt manchmal
halt ein bisschen Schadenfreude auf (Wer den Schaden hat...)
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.