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.
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
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.
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.
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 ?
> 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.
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...
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.
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.
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?
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.
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 :-)
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-32ae1fa4e015https://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:
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.
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-toolsWalter 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...)
