Forum: Offtopic Arm Compiler performance Linux vs. Windows


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Stefan ⛄ F. (stefanus)


Bewertung
-1 lesenswert
nicht lesenswert
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 Moderator
von Walter K (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Ein Techniker oder Ing nutzt ohne Not kein Windows!

von W.S. (Gast)


Bewertung
-6 lesenswert
nicht lesenswert
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.

von Karl der erste von oben (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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.

von olibert (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Niklas G. (erlkoenig) Benutzerseite


Bewertung
9 lesenswert
nicht lesenswert
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

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
olibert schrieb:
> Also Dateien copiert man auf einem Memorystick nicht mit einem GUI,
> sondern mit cp und anschliessendem sync.

Besser umount.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
7 lesenswert
nicht lesenswert
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.

von Karl der erste von oben (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Helmut S. (helmuts)


Bewertung
1 lesenswert
nicht lesenswert
> 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.

von TriHexagon (Gast)


Bewertung
6 lesenswert
nicht lesenswert
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.

von Niklas G. (erlkoenig) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
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...

von Stefan ⛄ F. (stefanus)


Bewertung
2 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von TriHexagon (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Carl D. (jcw2)


Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Niklas G. (erlkoenig) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.

von Karl der erste von oben (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
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?

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
> 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).

von Carl D. (jcw2)


Bewertung
0 lesenswert
nicht lesenswert
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
von Nop (Gast)


Bewertung
-9 lesenswert
nicht lesenswert
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.

von Niklas G. (erlkoenig) Benutzerseite


Bewertung
4 lesenswert
nicht lesenswert
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.

von Walter T. (nicolas)


Bewertung
5 lesenswert
nicht lesenswert
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.

von Rolf M. (rmagnus)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Carl D. (jcw2)


Bewertung
1 lesenswert
nicht lesenswert
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.

von 900ss D. (900ss)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Μαtthias W. (matthias) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Hi

Ich kann das auch bestätigen. Faktor 5 kann ich jetzt nicht bestätigen 
aber Faktor zwei ist es auf jeden Fall.

Matthias

von Niklas G. (erlkoenig) Benutzerseite


Bewertung
7 lesenswert
nicht lesenswert
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!

von Carl D. (jcw2)


Bewertung
6 lesenswert
nicht lesenswert
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?

von Rolf M. (rmagnus)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Sheeva P. (sheevaplug)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Sheeva P. (sheevaplug)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
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). ;-)

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Roland F. (rhf)


Bewertung
3 lesenswert
nicht lesenswert
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

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Sheeva P. (sheevaplug)


Bewertung
1 lesenswert
nicht lesenswert
Niklas G. schrieb:
> Die ./configure.sh Scripte von vielen Open Source Projekten

OT: Autoconf und Automake benutzen normalerweise nur "./configure", ohne 
.sh.

von Sheeva P. (sheevaplug)


Bewertung
4 lesenswert
nicht lesenswert
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.

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

von Karl der erste von oben (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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 ?

von Stefan ⛄ F. (stefanus)


Bewertung
-2 lesenswert
nicht lesenswert
> 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.

von Stefan ⛄ F. (stefanus)


Bewertung
-1 lesenswert
nicht lesenswert
> 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.

von PittyJ (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Markus F. (mfro)


Bewertung
0 lesenswert
nicht lesenswert
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).

von Ben W. (ben_w)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
> 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.

von Stefan ⛄ F. (stefanus)


Bewertung
-1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Walter T. (nicolas)


Bewertung
0 lesenswert
nicht lesenswert
Ä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.

von Stefan ⛄ F. (stefanus)


Bewertung
-1 lesenswert
nicht lesenswert
Sicher spielt das eine Rolle, deswegen habe ich es hingeschrieben. Aber 
daran darf ich momentan nichts ändern.

von Walter T. (nicolas)


Bewertung
0 lesenswert
nicht lesenswert
Pack den Build auf ein Ram-Drive.

von Markus F. (mfro)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Joerg W. (joergwolfram)


Bewertung
1 lesenswert
nicht lesenswert
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...

von Walter T. (nicolas)


Bewertung
0 lesenswert
nicht lesenswert
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
von Nop (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
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.

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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

von Markus F. (mfro)


Bewertung
1 lesenswert
nicht lesenswert
wenn Du mal die Patches für Spectre und Meltdown installiert hast, 
brauchst Du das eh' nicht mehr...

von Nop (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Felix F. (wiesel8)


Bewertung
0 lesenswert
nicht lesenswert
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

von Nop (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
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.

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Hans (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
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

von Bernd K. (prof7bit)


Bewertung
6 lesenswert
nicht lesenswert
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.

von Michael R. (fisa)


Bewertung
-2 lesenswert
nicht lesenswert
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?

von Walter T. (nicolas)


Bewertung
1 lesenswert
nicht lesenswert
Dauert bei euch der Build echt so lange, dass da 10% Prozent 
Geschwindigkeitszuwachs interessant sind?

von Stefan ⛄ F. (stefanus)


Bewertung
-1 lesenswert
nicht lesenswert
> 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.

von Nop (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Bernd K. (prof7bit)


Bewertung
3 lesenswert
nicht lesenswert
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?

von Sheeva P. (sheevaplug)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Markus F. (mfro)


Bewertung
3 lesenswert
nicht lesenswert
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...

von Nop (Gast)


Bewertung
-5 lesenswert
nicht lesenswert
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.

von Sheeva P. (sheevaplug)


Bewertung
4 lesenswert
nicht lesenswert
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.

von Michael R. (fisa)


Bewertung
5 lesenswert
nicht lesenswert
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 ;-)

von Nop (Gast)


Bewertung
-6 lesenswert
nicht lesenswert
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.

von Markus F. (mfro)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Nop (Gast)


Bewertung
-5 lesenswert
nicht lesenswert
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. ^^

von Chris D. (myfairtux) (Moderator) Benutzerseite


Bewertung
5 lesenswert
nicht lesenswert
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
von Joerg W. (joergwolfram)


Bewertung
2 lesenswert
nicht lesenswert
> die heutigen forkwütigen Ego-Darsteller

Ich benutze fork() sehr gerne...

von Bernd K. (prof7bit)


Bewertung
5 lesenswert
nicht lesenswert
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?

von Nop (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Nop (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Chris D. (myfairtux) (Moderator) Benutzerseite


Bewertung
3 lesenswert
nicht lesenswert
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
von Dr. Sommer (Gast)


Bewertung
7 lesenswert
nicht lesenswert
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...

von Kaj G. (Firma: RUB) (bloody)


Bewertung
4 lesenswert
nicht lesenswert
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
von Nop (Gast)


Bewertung
-4 lesenswert
nicht lesenswert
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.

von Dr. Sommer (Gast)


Bewertung
5 lesenswert
nicht lesenswert
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.

von Walter T. (nicolas)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Chris D. (myfairtux) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
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
von Bernd K. (prof7bit)


Bewertung
5 lesenswert
nicht lesenswert
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.

von Karl Käfer (Gast)


Bewertung
4 lesenswert
nicht lesenswert
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?

von Christopher J. (christopher_j23)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von I <3 makefiles (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Sheeva P. (sheevaplug)


Bewertung
5 lesenswert
nicht lesenswert
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.

von Michael R. (fisa)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Sheeva P. (sheevaplug)


Bewertung
5 lesenswert
nicht lesenswert
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!

von Carl D. (jcw2)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Nop (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
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.

von Sheeva P. (sheevaplug)


Bewertung
3 lesenswert
nicht lesenswert
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.

von Rolf M. (rmagnus)


Bewertung
4 lesenswert
nicht lesenswert
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…

von Sheeva P. (sheevaplug)


Bewertung
3 lesenswert
nicht lesenswert
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.

von Sheeva P. (sheevaplug)


Bewertung
2 lesenswert
nicht lesenswert
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

von Sheeva P. (sheevaplug)


Bewertung
2 lesenswert
nicht lesenswert
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. ;-)

von Sheeva P. (sheevaplug)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Joerg W. (joergwolfram)


Bewertung
2 lesenswert
nicht lesenswert
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...)

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, Yahoo oder Facebook? Keine Anmeldung erforderlich!
Mit Google-Account einloggen | Mit Facebook-Account einloggen
Noch kein Account? Hier anmelden.