Forum: PC Hard- und Software Linux wird nicht wirklich akzeptiert, woran liegt das ?


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 Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
Nop schrieb:
> Oh, als nächstes kommen Flatpak und Docker, was den Distro-Ansatz
> noch mehr demontiert.

Flatpack ja, Docker nein.

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
(prx) A. K. schrieb:
> Sheeva P. schrieb:
>> Microsoft Edge soll bald folgen
>
> Gibt es bereits.

Oh, wußte ich nicht. Danke für den Hinweis! ;-)

von S. R. (svenska)


Bewertung
5 lesenswert
nicht lesenswert
udok schrieb:
> Schön, wie hier auf Argumente eingegangen wird :-)

Ach, das waren Argumente?

> - Kein Sicherheitsupdate für 3 Jahre alte Bugs?
>   => Interessiert keine Linux Sau

Microsoft schafft mehr:
https://www.pcwelt.de/news/Microsoft-behebt-nach-17-Jahren-einen-Windows-Fehler-10847588.html

> - Kommandozeile gibts nur unter Linux
>   => War gefühlte 1000 Posts das Argument pro Linux,
>      nur wars erstunken und erlogen

Das ist Blödsinn. Das Argument war "Linux geht nur mit Kommandozeile", 
und auch das ist erstunken und erlogen.

> - Windows grösster Open-Source Motor?
>   => Bäh, kann nicht sein, Windows ist böse.

Microsoft hat Github gekauft und damit Zugang zum größten 
Open-Source-Repository der Welt... oh, warte... den Zugang hatte vorher 
auch schon jeder. Ne, zählt nicht.

Cyblord -. schrieb:
>> Oder wenigstens eine Linux Version von MS-Office bereit stellen.
>
> Wieso sollte sich MS mit völlig unwichtigen Nischensystemen befassen?
> Think Big. Aber das kennt der Linux-Nerd nicht. Das gehts eher
> Klein-Klein.

Blödsinn. Office 365 läuft zumindest im Browser, Teams gibt's schon für 
Linux, Edge ebenfalls, weitere Programme werden folgen.

Nop schrieb:
> Mit anderen Worten, der ganze Ansatz einer Distro taugt letztlich nicht,

"Microsoft Windows" ist auch eine Distribution. Der Unterschied zu Linux 
ist, dass es davon überhaupt nur eine gibt (und das wiederum haben 
Windows und die BSDs gemeinsam).

> weil man wieder direkt von der Quelle installiert und
> sich damit u.U. auch mal das System zerballern kann.

Hey, ist das nicht das, was Windows-Nutzer grundsätzlich machen 
(müssen)?

von Nop (Gast)


Bewertung
-4 lesenswert
nicht lesenswert
S. R. schrieb:

> "Microsoft Windows" ist auch eine Distribution.

Nein. Ich weiß nicht, was Du für Distros heranziehst, aber die, die ich 
so kenne, bestehen nicht nur aus OS und DE.

> Hey, ist das nicht das, was Windows-Nutzer grundsätzlich machen
> (müssen)?

Jahaaa, und bei Linux heißt es, daß dank Paketmanager mit Distro-Repo 
jede Anwendung allfällige Sicherheitsupdates in Bibliotheken bekommt. 
Was wurde hier gerade vorgeschlagen? Hey, laßt doch jede Anwendungen mit 
einem eigenen PPA anrollen! Ja super Idee!

Uhm, was wurde gerade noch über den Vorteil des Distro-Repos gesagt? 
Uhm, egal, wen interessiert das schon.

Sich dermaßen zu widersprechen, nur um nicht zugeben zu müssen, daß es 
Probleme gibt, ist absurd. Vor allem führt diese Haltung letztlich dazu, 
daß konsequenz jede Verbesserung sabotiert wird. Linux braucht solche 
Argumentatoren daher ungefähr so nötig wie eingewachsene Zehennägel.

von Np R. (samweis)


Bewertung
5 lesenswert
nicht lesenswert
Erwin E. schrieb:
> Ergebnis: Linux ist ganz nett, aber nicht nutzbar, wenn man einfach
> produktiv sein will und keine ideologischen Scheuklappen hat.

Interessant. Also wenn man keine ideologischen Scheuklappen hat, ist 
es nicht nutzbar. Wenn man sie hat, verbessert das die Nutzbarkeit.
Mir war bisher nicht klar, dass diese Scheuklappen bei Computerproblemen 
helfen. Wo bekommt man die? Kann man die nicht im Support einsetzen?

Vielleicht kommen deshalb manche Leute mit Windows so gut klar - die 
haben einfach einen doppelten Satz Scheuklappen.

von Sheeva P. (sheevaplug)


Bewertung
3 lesenswert
nicht lesenswert
Nop schrieb:
> Aus dem Golem-Artikel: "Öffentlich bekannt ist die Lücke seit Juni 2017,
> ich hatte diese in einer Mail an die Mailingliste oss-security
> bekanntgegeben. Auf dieser Mailingliste lesen üblicherweise Personen von
> allen wichtigen Linux-Distributionen mit."
>
> Es wurde bescheid gesagt, aber ignoriert. Da braucht es kein Release.

Naja, auf oss-security kommen häufiger mal Mails von Leuten, sie hätten 
DIIIEEE!!! hochwichtig-schwerwiegendste Sicherheitslücke aller Zeiten 
gefunden, und am Ende stellt sich heraus, daß die ganze Sache nur eine 
Luftnummer war. Wer tatsächlich ernsthafte Sicherheitsforschung 
betreiben wollte, hätte eine CVE-ID beantragt und sicherlich nicht erst 
drei Jahre später einen aufmerksamkeitsheischenden Artikel in einem (!) 
deutschsprachigen (!) Online-Magazin geschrieben, sondern nachgehakt.

Sorry, aber da haben alle Beteiligten Mist gemacht. Der vom Projekt, ja, 
und auch der Sicherheitsforscher. Im Bugtracker des Projekts ist diese 
Änderung nicht als Security Fix markiert, die mit dem Patch 
geschlossenen Bugs sind nicht öffentlich einsehbar. Kommunikation at its 
worst, von beiden Seiten.

Als Maintainer des Pakets bei einem Distributor hätte ich mir das kurz 
angeschaut und dann... die Bälle flachgehalten. Jemand hat behauptet, 
ein Sicherheitsproblem gefunden zu haben... dazu gibt es aber kein CVE, 
keine Aussage des Autors, nichts. Und drei Jahre später behauptet der 
Finder dann auf Golem.de, ich hätte meinen Job nicht ordentlich gemacht? 
Und stellt das dann auch noch als symptomatisch dar, weil die 
Distributoren mit ihren 50.000+ Softwarepaketen nicht jedem Hirnfurz und 
jeder unverifizierten Behauptung nachgehen können und wollen.

von Sheeva P. (sheevaplug)


Bewertung
1 lesenswert
nicht lesenswert
Nop schrieb:
> Jack V. schrieb:
>
>> Keine Distribution popelt sich Kram aus‘m Git-Repo – so funktioniert das
>> einfach nicht.
>
> Ach, und wie machen sie die Backports? Doch wohl auch manuell.

Stimmt. Aber in solchen Fällen gibt es eine bestätigte Sicherheitslücke, 
oder ein großes Interesse, neue Funktionen auch auf älteren Systemen 
verfügbar zu machen.

>> Kann man mögen oder auch nicht, aber Anwendungsprobleme
>> dem OS anzulasten
>
> Wieso das bei Linux anders ist als bei Windows, habe ich bereits
> begründet.

Mit der Userwahrnehmung... ja, da ist zwar durchaus was 'dran, aber das 
ist nur ein kleiner Teil der Wahrheit.

> Man kann nicht stolz auf den Paketmanager verweisen, der
> alles beinhaltet, und dann bei den resultierenden Problem aber wieder
> jeden Zusammenhang abstreiten.

Das Problem ist nicht der Paketmanager, und das weißt Du auch selbst. 
Ich habe mir die Sache jetzt mal etwas genauer angesehen, und das 
Problem ist die Kommunikation: einerseits dieses Sicherheitforschers und 
andererseits des Softwareentwicklers, die sich beide nicht an die 
einschlägigen Standards halten und wohl "vergessen" haben, wichtige 
Informationen öffentlich zu machen.

Richtig ist, daß die schlechte Kommunikation in diesem Fall ein Problem 
war. Richtig ist aber auch, daß solche Probleme nicht die Regel, sondern 
eine Ausnahme sind, und daß ebendiese Kommunikation in anderen -- ich 
würde sogar behaupten: in nahezu allen anderen --  Fällen ganz wunderbar 
funktioniert.

von Sheeva P. (sheevaplug)


Bewertung
2 lesenswert
nicht lesenswert
S. R. schrieb:
> udok schrieb:
>> Schön, wie hier auf Argumente eingegangen wird :-)
>
> Ach, das waren Argumente?
>
>> - Kein Sicherheitsupdate für 3 Jahre alte Bugs?
>>   => Interessiert keine Linux Sau
>
> Microsoft schafft mehr:
> 
https://www.pcwelt.de/news/Microsoft-behebt-nach-17-Jahren-einen-Windows-Fehler-10847588.html

Aber das hat uns doch der Cyb"lord" schon erklärt: Think big! ;-)

> Cyblord -. schrieb:
>> Wieso sollte sich MS mit völlig unwichtigen Nischensystemen befassen?
>> Think Big. Aber das kennt der Linux-Nerd nicht. Das gehts eher
>> Klein-Klein.

Quod erat demonstrandum.

> Nop schrieb:
>> Mit anderen Worten, der ganze Ansatz einer Distro taugt letztlich nicht,
>
> "Microsoft Windows" ist auch eine Distribution. Der Unterschied zu Linux
> ist, dass es davon überhaupt nur eine gibt (und das wiederum haben
> Windows und die BSDs gemeinsam).

Äh... also ich habe ein paar FreeBSD-Maschinen, aber auch mal was mit 
Open- und NetBSD gemacht, und dann gibt (gab) es da noch Windriver, 
DragonFly, TrustedBSD, TrueOS, ... und bestimmt noch drölfzig weitere 
BSD-Distributionen, die ich nicht kenne oder schon wieder vergessen 
habe.

>> weil man wieder direkt von der Quelle installiert und
>> sich damit u.U. auch mal das System zerballern kann.
>
> Hey, ist das nicht das, was Windows-Nutzer grundsätzlich machen
> (müssen)?

<ironie>Ja, aber unter Windows ist das eine gute Sache. Schließlich ist 
es einem Windows-User noch nie passiert, daß er sich mit einem 
Windows-Update sein System oder eine installierte Software zerschossen 
hätte.</ironie>

von Jack V. (jackv)


Bewertung
3 lesenswert
nicht lesenswert
Nop schrieb:
> Ach, und wie machen sie die Backports? Doch wohl auch manuell.

Ja, manuell. Aber auch in den Backports sind veröffentlichte Versionen, 
keine Git-Snapshots. Und hier gab es nunmal kein Release – das war 
doch das eigentliche Problem an der Sache.

von Sheeva P. (sheevaplug)


Bewertung
2 lesenswert
nicht lesenswert
Nop schrieb:
> S. R. schrieb:
>
>> "Microsoft Windows" ist auch eine Distribution.
>
> Nein. Ich weiß nicht, was Du für Distros heranziehst, aber die, die ich
> so kenne, bestehen nicht nur aus OS und DE.

Also ehrlich, so kannst Du das auch nicht sagen. In Windows sind 
immerhin auch wertvolle Anwendungsprogramme enthalten, zum Beispiel der 
Taschenrechner, der Editor, und das Defragmentierungswerkzeug.

>> Hey, ist das nicht das, was Windows-Nutzer grundsätzlich machen
>> (müssen)?
>
> Jahaaa, und bei Linux heißt es, daß dank Paketmanager mit Distro-Repo
> jede Anwendung allfällige Sicherheitsupdates in Bibliotheken bekommt.
> Was wurde hier gerade vorgeschlagen? Hey, laßt doch jede Anwendungen mit
> einem eigenen PPA anrollen! Ja super Idee!

Na komm, der Betreffende hat nicht gerafft, um was es ging...

> Uhm, was wurde gerade noch über den Vorteil des Distro-Repos gesagt?
> Uhm, egal, wen interessiert das schon.
>
> Sich dermaßen zu widersprechen, nur um nicht zugeben zu müssen, daß es
> Probleme gibt, ist absurd. Vor allem führt diese Haltung letztlich dazu,
> daß konsequenz jede Verbesserung sabotiert wird. Linux braucht solche
> Argumentatoren daher ungefähr so nötig wie eingewachsene Zehennägel.

Naja, tatsächlich hat es in diesem Fall ein Problem gegeben, das sich 
nach einer eingehenden Lektüre als... ziemlich bescheuerter Ausnahmefall 
herausgestellt hat. Jetzt so zu tun, als käme so etwas öfters vor -- 
oder sei gar symptomatisch, ist offensichtlich genauso nötig wie die von 
Dir aufgeführten Zehennägel.

von Sheeva P. (sheevaplug)


Bewertung
1 lesenswert
nicht lesenswert
Np R. schrieb:
> Erwin E. schrieb:
>> Ergebnis: Linux ist ganz nett, aber nicht nutzbar, wenn man einfach
>> produktiv sein will und keine ideologischen Scheuklappen hat.
>
> Interessant. Also wenn man keine ideologischen Scheuklappen hat, ist
> es nicht nutzbar. Wenn man sie hat, verbessert das die Nutzbarkeit.
> Mir war bisher nicht klar, dass diese Scheuklappen bei Computerproblemen
> helfen. Wo bekommt man die? Kann man die nicht im Support einsetzen?

Ich biete hiermit ideologische Scheuklappen zum einmaligen Sonderpreis 
von 80,- Euro pro Stück an. Immerhin die Hälfte einer handelsüblichen 
Lizenz für Windows 10 Pro, meine sehr verehrten Damen und Herren! 
Greifen Sie zu, bevor das Angebot vergriffen ist! Lösen Sie sich von der 
Gängelung und Spionage durch fremde Mächte, werden Sie Herrin über Ihren 
Computer und Ihre Daten! ;-)

von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
Sheeva P. schrieb:
> Ich biete hiermit ideologische Scheuklappen zum einmaligen Sonderpreis
> von 80,- Euro pro Stück an.

Auch hier ist wie so oft die Realität der Satire voraus. ;-)

Virtuelle Scheuklappen sind heutzutage modern, werden als Feature von 
Bildschirmen verkauft. Die sich bei Bedarf auf engen Sichtwinkel 
einstellen lassen, damit nicht die ganze Umgebung mitkriegt, was man 
sich grad reinzieht.

: Bearbeitet durch User
von S. R. (svenska)


Bewertung
5 lesenswert
nicht lesenswert
Nop schrieb:
>> "Microsoft Windows" ist auch eine Distribution.
> Nein. Ich weiß nicht, was Du für Distros heranziehst, aber die,
> die ich so kenne, bestehen nicht nur aus OS und DE.

Windows kommt mit diversen Anwendungen und Tools.

Das wichtigste Programm auf modernen Computern ist der Webbrowser, und 
wenn man mal anderthalb Augen zukneifen will, dann würde WordPad für 70% 
der Computernutzer als Textverarbeitung auch ausreichen.

Lange war auch eine Programmierumgebung (QBasic) mit dabei und 
Interpreter (VBScript, cmd.exe) sind es auch heute noch.

Sicher nicht Debian-Niveau, aber deutlich mehr als "Kernel plus 
Desktop".

>> Hey, ist das nicht das, was Windows-Nutzer
>> grundsätzlich machen (müssen)?
> Jahaaa, und bei Linux heißt es, daß dank Paketmanager mit Distro-Repo
> jede Anwendung allfällige Sicherheitsupdates in Bibliotheken bekommt.

Richtig. Das ist ein Vorteil.

> Was wurde hier gerade vorgeschlagen? Hey, laßt doch jede
> Anwendungen mit einem eigenen PPA anrollen! Ja super Idee!

Richtig. Und auch das ist ein Vorteil, nämlich für Software, die sich 
grundsätzlich schneller wandelt als ein typischer Release-Zyklus. Und 
selbst das ist "nicht schlechter" als Windows. Ist das in diesem Thread 
nicht der gottgegebene Vergleichsmaßstab?

> Sich dermaßen zu widersprechen, nur um nicht zugeben zu
> müssen, daß es Probleme gibt, ist absurd.

Es gibt Probleme und Lösungen. Aber es gibt kein one-size-fits-all und 
wie wir hier bereits zu Tode diskutiert haben, gibt es immer irgendeinen 
Idioten, der sich darüber aufregt, dass seine VW-Motorsteuersoftware 
nicht läuft oder Wine grundsätzlich stinkt und verboten gehört oder 
LibreOffice seine Firmenmakros nicht lesen kann.

> Vor allem führt diese Haltung letztlich dazu,
> daß konsequenz jede Verbesserung sabotiert wird.

Redest du von Verbesserung oder redest du von Veränderung?

: Bearbeitet durch User
von Le X. (lex_91)


Bewertung
-1 lesenswert
nicht lesenswert
udok schrieb:
> Schön, wie hier auf Argumente eingegangen wird :-)
>
> - Kein Sicherheitsupdate für 3 Jahre alte Bugs?  => Interessiert keine
> Linux Sau
>
> - Kommandozeile gibts nur unter Linux
>   => War gefühlte 1000 Posts das Argument pro Linux,
>      nur wars erstunken und erlogen
>
> - Windows grösster Open-Source Motor?
>   => Bäh, kann nicht sein, Windows ist böse.
>
> Auf, auf, noch ein paar Posts bis zur 6000 Marke!

Hey udok,
dein Plan ging voll auf, 10/10.
Weiter so!

Beitrag #6475050 wurde von einem Moderator gelöscht.
Beitrag #6475057 wurde von einem Moderator gelöscht.
Beitrag #6475060 wurde von einem Moderator gelöscht.
von Stefan ⛄ F. (stefanus)


Bewertung
2 lesenswert
nicht lesenswert
Cyblord -. schrieb:
>> Meinst du mich damit?
> Denkst du wirklich alles dreht sich um dich?

Du hast immerhin auf einen Kommentar von mir geantwortet. Wenn du jemand 
anderes ansprechen wolltest, dann schreibe das bitte auch klar und tu 
nicht so blöd.

Beitrag #6475093 wurde von einem Moderator gelöscht.
von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
Sheeva P. schrieb:
> aber trotzdem: einen Bugfix und dann drei
> Jahre lang kein Release? Nicht schön.

Das ist jammern auf hohem Niveau.

Ein Kunde bezahlt uns dafür die Software auf einem Server (die wir teils 
selbst entwickeln) stets aktuell zu halten.

Andererseits sollen wir unseres aber mit einem ihrer Systeme verbinden, 
welches eine alte inkompatible Version einer Schnittstelle verwendet. So 
sind wir gezwungen, Bibliotheken einzusetzen, die seit 2005 nicht mehr 
gepflegt wurden. Damit verbunden auch eine veralte Java Version und bald 
vielleicht gar ein veraltetes Betriebssystem.

Solche Szenarien habe ich bereits in drei Firmen erlebt.

Was macht man in so einem Fall? Einmal deutlich drauf hinweisen und dann 
die Füße still halten, sonst verliert man den Job. So läuft das in der 
Realität.

3 Jahre Verzögerung sind dagegen Pillepa, aber trotzdem

>  Nicht schön.

: Bearbeitet durch User
von Stefan ⛄ F. (stefanus)


Bewertung
2 lesenswert
nicht lesenswert
Sheeva P. schrieb:
> In Windows sind immerhin auch wertvolle Anwendungsprogramme enthalten,
> zum Beispiel der Taschenrechner

> der Editor

Der erst nach 30 Jahren lernte, Unix-Zeilenumrüche zu lesen.

> und das Defragmentierungswerkzeug

Dessen Nutzen schon immer fragwürdig war und inzwischen ein echter 
Hardware-Töter geworden ist.

von N. A. (bigeasy)


Bewertung
3 lesenswert
nicht lesenswert
Na dann, auf die nächsten 6000 konstruktiven Beiträge.

Oder anders formuliert: "Störe Dich nicht am Inhalt!"

von Nop (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
>> und das Defragmentierungswerkzeug
>
> Dessen Nutzen schon immer fragwürdig war

Das stimmt so nicht. Zu Zeiten mechanischer HDDs mit Seek-Zeiten ganz 
offensichtlich, guckst Du hier:

https://www.hofmannc.de/en/windows-7-defragmenter-test/benchmarks.html

> und inzwischen ein echter Hardware-Töter geworden ist.

Bei einer SSD gibt's natürlich keine mechanischen Seek-Zeiten, und 
"defragmentieren" bedeutet für Windows heute etwas deutlich anderes als 
früher. Deswegen wird auch nur einmal im Monat aufgeräumt, und weniger 
als bei einer HDD, aber mit gutem Grund:

https://www.hanselman.com/blog/the-real-and-complete-story-does-windows-defragment-your-ssd

Die eigentliche Frage ist jedoch, wieso das eigentlich nach 30 Jahren 
NTFS immer noch nötig ist. Unter Linux fragmentiert mit ext4 nichts 
mehr, solange noch mindestens 20% freier Platz auf der Partition sind. 
Das sollte man unbedingt sicherstellen.

von Nop (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
>> der Editor
>
> Der erst nach 30 Jahren lernte, Unix-Zeilenumrüche zu lesen.

Ach ja, und sowas ist bei MS keineswegs Unfähigkeit, sondern Absicht. So 
ähnlich wie etwas anderes zu sein, aber immer ein bißchen inkompatibel, 
das ist Teil ihrer Standard-Strategy "embrace, extend, extinguish".

Das machen sie, wenn sie einen lock-in schaffen wollen und zugleich 
denken, daß ihre Produkte nicht gut genug sind, um im direkten 
Wettbewerb zu bestehen. Also so gut wie immer.

von Cyblord -. (cyblord)


Bewertung
-7 lesenswert
nicht lesenswert
Nop schrieb:
> Das machen sie, wenn sie einen lock-in schaffen wollen und zugleich
> denken, daß ihre Produkte nicht gut genug sind, um im direkten
> Wettbewerb zu bestehen. Also so gut wie immer.

Tja deren Motto ist halt: Machen statt rumheulen. Der Linux-Nerd steht 
daneben und heult rum wie böse MS ist.

von Nop (Gast)


Bewertung
4 lesenswert
nicht lesenswert
Cyblord -. schrieb:
> Tja deren Motto ist halt: Machen statt rumheulen.

Du hast sichtlich nicht kapiert, wozu "embrace, extend, extinguish" gut 
ist: minderwertige Produkte durchzudrücken, worunter dann auch MS-Nutzer 
zu leiden haben. Es sei nur an die ganzen Sicherheitslücken des IE 
erinnert, die maßgeblich durch ActiveX zustandekamen, was wiederum der 
Versuch war, ein Microsoft-only Web zu erschaffen. Und zwar ohne jeden 
Gedanken an Sicherheit.

von Stefan ⛄ F. (stefanus)


Bewertung
4 lesenswert
nicht lesenswert
Cyblord -. schrieb:
> Tja deren Motto ist halt: Machen statt rumheulen. Der Linux-Nerd steht
> daneben und heult rum wie böse MS ist.

Warum sollte er heulen, er hat doch eine funktionierende Alternative.

Ich erlebe viel mehr heulende Windows User, die nicht wechseln wollen 
oder nicht können. Wobei ich zu ersteren sage: Selbst schuld.

von Nop (Gast)


Bewertung
6 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Ich erlebe viel mehr heulende Windows User

Besonders die ganzen Privatanwender mit ihren Home- oder sog. 
"Pro"-Versionen, die immer noch nicht kapiert haben, daß sie keine 
Kunden sind, sondern kostenlose Betatester.

von Draco (Gast)


Bewertung
-6 lesenswert
nicht lesenswert
Nop schrieb:
> sondern kostenlose Betatester

Bei Linux ist das sogar prinzipiell so. ;-)

von Jack V. (jackv)


Bewertung
5 lesenswert
nicht lesenswert
Draco schrieb:
> Bei Linux ist das sogar prinzipiell so. ;-)

Klar, bei Linux kannst du prinzipiell gerne freiwillig den Testing-Zweig 
der Distribution oder der Software wählen, und so mithelfen. Du bist 
allerdings nicht dazu gezwungen.

von Stefan ⛄ F. (stefanus)


Bewertung
6 lesenswert
nicht lesenswert
Draco schrieb:
>> sondern kostenlose Betatester
> Bei Linux ist das sogar prinzipiell so. ;-)

Nein, bei Linux hast die Wahl, ob die einen aktuellen Snapshot, eine 
Testing Distribution oder ein LTS Release verwenden willst.

Ich bevorzuge LTS Releases wegen ihrer Stabilität. Ggf tausche ich nur 
einzelne Programme durch neuere Versionen aus, was problemlos geht.

von S. R. (svenska)


Bewertung
4 lesenswert
nicht lesenswert
Nop schrieb:
> Die eigentliche Frage ist jedoch, wieso das eigentlich
> nach 30 Jahren NTFS immer noch nötig ist.

Naja, NTFS versucht halt, eine eierlegende Wollmilchsau zu sein und 
vereinigt traditionelle Verfahren mit COW-Semantik (für Snapshots), bei 
gleichzeitiger Beibehaltung aller möglichen Features.

Du darfst halt nicht vergessen, dass NTFS wesentlich mehr Funktionalität 
besitzt als die üblichen Linux-Dateisysteme (z.B. die Reparse-Points, 
separate Namespaces, extrem tiefe ACLs), und das schon seit der 
Frühzeit. Dummerweise wird davon fast nichts genutzt.

> Unter Linux fragmentiert mit ext4 nichts mehr,
> solange noch mindestens 20% freier Platz auf der Partition sind.

Das erkläre mal dem durchschnittlichen Windows-User, der erst dann 
merkt, dass die Platte voll ist, wenn Windows das beim nächsten Foto vom 
Handy ansagt...

Ob ich nun der durchschnittliche Linux-Nutzer bin oder nicht mal 
dahingestellt, aber meine /home-Partition läuft auch mir gelegentlich 
voll (oder nahe dran).

Ext4 ist nicht das Wunderwerk der Technik, sonst gäbe es ZFS und btrfs 
nicht - es ist ein hochperformantes, stabiles POSIX-Dateisystem. Das ist 
NTFS nicht und war es nie.

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
S. R. schrieb:
> Ext4 ist nicht das Wunderwerk der Technik, sonst gäbe es ZFS und btrfs
> nicht - es ist ein hochperformantes, stabiles POSIX-Dateisystem. Das ist
> NTFS nicht und war es nie.

Das schöne an Linux ist, dass man sich ein Filesystem aussuchen kann - 
je nachdem was man braucht. Bei Windows hat man keine Wahl.

Als Softwareentwickler möchte ich auf meinem Desktop ein schnelles 
Filesystem haben, weil sich das direkt und erheblich auf meine 
Arbeitsleistung auswirkt. Und da ist Windows mit seinem NTFS genau das 
Gegenteil von, was ich mir wünsche. Selbst eine Linux VM auf NTFS läuft 
schneller, als natives Windows. Das gibt mir zu denken.

von S. R. (svenska)


Bewertung
4 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Selbst eine Linux VM auf NTFS läuft
> schneller, als natives Windows.

Versuch das mal auf btrfs mit aktiviertem COW. :-)

Scherz beiseite, NTFS ist auf Dateiebene schlicht langsam. Warum, 
schrieb ich bereits (deswegen ist WSL1 auch nahezu unbrauchbar). 
Schreibst du nur innerhalb einer Datei rum (wie VMs und Datenbanken das 
tun) dann ist NTFS nicht nennenswert langsamer als alle anderen 
Dateisysteme da draußen.

Das schöne ist, dass Linux verschiedene Dateisysteme für verschiedene 
Anwendungsfälle bereitstellt und - und da wären wir wieder beim 
Windows-vs-Linux-Thema - vom Benutzer erwartet, dass er da eine 
sinnvolle Entscheidung trifft. Die beim Heimanwender im Jahr 2020 
wahrscheinlich "ext4" lautet.

Windows kann das nicht, denn eine für Microsoft wirklich relevante 
Zielgruppe ist schon mit dem Unterschied zwischen "FAT" und "NTFS" 
überfordert. Kommst du da mit vier Varianten an, wird das noch viel 
schlimmer. (Sieht man übrigens auch am Cyblord schön.)

: Bearbeitet durch User
Beitrag #6475573 wurde vom Autor gelöscht.
von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
Wobei Microsoft seit einigen Jahren auch ein neueres Filesystem im 
Angebot hat: ReFS. Hab aber in der Praxis noch nicht viel davon gehört.

von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
Ist jetzt nicht unbedingt was für Tante Emma, aber warum geht sowas auf 
einfachste Art in Linux, aber nicht in Windows: Mehrere VLANs auf dem 
Ethernet-Anschluss. Auf dem Client-PC.

Das ist nicht so esoterisch wie es manchen erscheinen mag, denn ich mag 
das nicht nur privat so haben, es ist auch in der Firma eine 
Notwendigkeit bei manchen Arbeitsplätzen. Also das normale Netz für das 
Standardsystem, und weitere Netze als VLANs auf dem gleichen Adapter, in 
dem sich Entwicklungs- und Giftschrank-VMs tummeln dürfen, die im 
Produktionsnetz nichts verloren haben.

Ich hatte das zunächst in Win7 mit Intel-Adapter probiert. Es schien 
möglich, stand zur Verfügung und liess sich einrichten. Funktionierte 
aber nicht. Ein Treiber-Release später, mit Win10, war die Funktion weg, 
ersetzt durch das verspätete Eingeständnis Intels, es stünde mit 
irgendwas in Konflikt und hätte deshalb sowieso nicht funktioniert.

In der Firma lösten wir das Problem auf letztjahrhundertige Weise mit 
einem zweiten Ethernet-Adapter. Privat löste ich das mit Linux. War in 
wenigen Minuten gegessen, obendrein ganz in GUI völlig ohne Shell oder 
Configfiles. Nun habe ich VMs, die in einem anderen Netz operieren als 
das Basis-System, aber über den gleichen Adapter. Kessel geflickt.

: Bearbeitet durch User
von udok (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
S. R. schrieb:
> Scherz beiseite, NTFS ist auf Dateiebene schlicht langsam. Warum,
> schrieb ich bereits (deswegen ist WSL1 auch nahezu unbrauchbar).
> Schreibst du nur innerhalb einer Datei rum (wie VMs und Datenbanken das
> tun) dann ist NTFS nicht nennenswert langsamer als alle anderen
> Dateisysteme da draußen.

Kann ich nicht nachvollziehen, und gehört mal wieder in das Reich der 
Legenden.

Ich habe eine flotte SSD mit ca. 3000 MByte / Sekunde.
Unter Windows schaffe ich ohne Verschlüsselung diesen Wert mit grossen
Dateiblöcken (lesen und schreiben).
Mit CPU Verschlüsselung sind es noch immer ca. 2000 MByte / Sekunde.

Der gcc ist aber saulangsam unter Windows.  Ich nehme mal an,
dass der irgendwelche Tricks macht, die unter Linux gut funktionieren,
und unter Windows eben nicht.
Kennt man ja von Intel und AMD zur Genüge.

von (prx) A. K. (prx)


Bewertung
4 lesenswert
nicht lesenswert
udok schrieb:
> Ich habe eine flotte SSD mit ca. 3000 MByte / Sekunde.

Es geht bei beschriebenen Effekt nicht um den Durchsatz grosser Dateien, 
sondern um Metaoperationen im Dateisystem. Files öffnen, anlegen, 
verschieben, umbenennen, löschen. Prozesse starten und beenden. Das 
misst man nicht in GB/s, sondern in Ops/s, weil nicht der Durchsatz 
irgendwelcher Bytes zählt, sondern die Transaktionsverarbeitung des 
Filesystems und des Betriebssystems. Und da kann man durchaus den 
Eindruck gewinnen, Linux sei flotter.

> Ich nehme mal an,
> dass der irgendwelche Tricks macht, die unter Linux gut funktionieren,
> und unter Windows eben nicht.

Nö. GCC ist m.W. völlig harmlos, was API-Nutzung angeht. Der macht 
nichts, was nicht in jedem System ohne Klimmzüge ginge.

: Bearbeitet durch User
von Nop (Gast)


Bewertung
0 lesenswert
nicht lesenswert
udok schrieb:
> Der gcc ist aber saulangsam unter Windows.

Zum einen, mach mal den Virenscanner aus!

Zum anderen ist das Starten eines neuen Prozesses uner Windows deutlich 
langsamer als unter Linux. Wenn Dein Buildsystem pro Übersetzungseinheit 
einen GCC-Aufruf macht, statt mehrere Übersetzungseinheiten auf einmal 
an GCC zu geben, fällt das natürlich bei großen Projekten erhebblich ins 
Gewicht.

von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
Nop schrieb:
> Zum einen, mach mal den Virenscanner aus!

Bremst Microsofts Defender für Linux eigentlich ebenfalls aus? Oder 
scannt der bloss, klingt sich nicht in APIs ein? Irgendwas muss MS ja 
tun, um Linux abzubremsen. ;-)

von Nop (Gast)


Bewertung
1 lesenswert
nicht lesenswert
(prx) A. K. schrieb:

> Bremst Microsofts Defender für Linux eigentlich ebenfalls aus?

Na vielleicht hat MS diese Spionagesoftware für Linux ja wenigstens 
hinsichtlich Performance optimiert, wer weiß. ^^

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
udok schrieb:
> Unter Windows schaffe ich ohne Verschlüsselung diesen Wert mit grossen
> Dateiblöcken (lesen und schreiben).

Der Knackpunkt sind viele kleine Dateien.

von udok (Gast)


Angehängte Dateien:

Bewertung
-3 lesenswert
nicht lesenswert
(prx) A. K. schrieb:
> Es geht bei beschriebenen Effekt nicht um den Durchsatz grosser Dateien,
> sondern um Metaoperationen im Dateisystem. Files öffnen, anlegen,
> verschieben, umbenennen, löschen. Prozesse starten und beenden. Das
> misst man nicht in GB/s, sondern in Ops/s, weil nicht der Durchsatz
> irgendwelcher Bytes zählt, sondern die Transaktionsverarbeitung des
> Filesystems und des Betriebssystems. Und da kann man durchaus den
> Eindruck gewinnen, Linux sei flotter.

Auch die Ops/s sind unter Windows nahe an den Angaben des
SSD Herstellers.
Im Bild siehst du die Ergebnisse für die Corsair Force Series MP510,
gemessen mit CrystalDisk.

Heute wird die Ops/s Performance doch nur vom Cache bestimmt!
Das hat überhaupt nichts mit der Disk IO Performance oder NTFS zu tun.
Kleine Files bleiben vollständig im Cache, und werden erst später
geschrieben, nachdem schon alles fertig übersetzt ist.
Es wird auch standardmässig voraus gelesen.
Wenn die SSD nicht hoffnungslos fragmentiert ist,
dann haben benachbarte kleine Files denselben 256k Block auf der SSD,
und liegt damit schon im Cache.
Das Lesen der Files und auch die Ops/s spielen bei der
Compiliergeschwindigkeit sowieso keine Rolle.
Der Overhead muss also woanders sein.

Man kann unter Windows sehr effizient und programmieren,
auch wenn das zugegebenermassen nur wenige machen.

Ich erinnere mal an die Möglichkeit Overlappend-IO zu machen,
ein Feature das Linux gerade erst vor kurzem äusserst umständlich
und natürlich wieder inkompatibel eingebaut hat.
Damit kann man ein File im Hintergrund lesen, und gleichzeitig
sinnvolle Sachen im Programm machen. Auch wird der Buffer
nur einmal geschrieben, mit DMA, ohne CPU Clocks zu verbraten.
Ist auch im Zusammenhang mit USB 3.x sinnvoll, um die volle
Geschwindigkeit zu erreichen, oder auch mit modernen SSDs.

Oder das Feature, den File-Offset direkt im ReadFile() SysCall
anzugeben, man braucht damit nur einen SysCall, nicht zwei
wie unter Linux (seek & read).
Und SysCalls sind bei der Geschwindikgeit heutiger SSDs Performance 
Killer!
Man sieht bei vielen SysCalls, das die Windows Version etliche
Zusatzparameter hat.  Damit kann man oft mehr Arbeit in einen
SysCall reinpacken, und Syscalls sind relativ kostspielig.

Oder die Möglichkeit, die Thread-Pools zu verwenden!

Linux Programmierer verwenden viel zu oft den antiquierten
fork() Mechanismus!
Das ist ein Performance Bottleneck aus der Steinzeit,
als es noch keine Threads gab.
Mag ja sein, das Linux die Prozess Create Zeiten daher
so stark optimieren musste.  Unter Windows ist das schlichtweg
nicht nötig, da es dort schon immer Threads gab.
Natürlich wissen die wenigsten Linux Programmierer das,
oder sind auch zu faul ihre Programmstruktur entsprechend zu ändern,
um Performance auch unter Windows zu erreichen.

Ich will hier aber nicht gegen Linux wettern.  Der Linux Kern ist schon
sehr gut.  Nur ist das eben kein Alleinstellungsmerkmal von Linux,
und kein Grund zu wechseln.
Ich würde mir wünschen, das Linuxer nicht immer so prepotent auftreten
würden, sondern mal den Windows Usern entgegenkommen würden.
Embrace, Extend & Extinguish ist ja keine MS Erfindung, das machten 
schon
die alten Römer.
Wie wäre es denn mit SysCalls, die zu NT kompatibel sind?
Oder wenigstens Editoren, die standardmässig \r\n verstehen?
Ein Treibermodell, das näher am Windows Treiberstandard ist?
Einfache Dinge, die der SW Industrie sehr helfen würde, Programme
zu portieren.  Aber nein, Linuxer igeln sich gern ein,
und stellen den Rest der Welt gern als Idioten hin.

Danke an den Hinweis  mit dem Virenchecker!
Das könnte der Grund für den langsamen gcc.exe sein,
gerade wenn noch online eine Virendatenbank konsultiert wird.

von Stefan ⛄ F. (stefanus)


Bewertung
2 lesenswert
nicht lesenswert
udok schrieb:
> Heute wird die Ops/s Performance doch nur vom Cache bestimmt!
> Das hat überhaupt nichts mit der Disk IO Performance oder NTFS zu tun.
> Kleine Files bleiben vollständig im Cache, und werden erst später
> geschrieben, nachdem schon alles fertig übersetzt ist.

Offenbar ist es nicht so einfach. Kopiere mal ein Verzeichnis mit zig 
tausend kleinen Dateien (z.B Fotos) unter Windows und dann mache das auf 
dem selben Rechner nochmal unter Linux. Linux ist mehr als doppelt so 
schnell (sowohl mit SSD als auch mit rotierenden Festplatten).

von (prx) A. K. (prx)


Bewertung
5 lesenswert
nicht lesenswert
udok schrieb:
> Auch die Ops/s sind unter Windows nahe an den Angaben des
> SSD Herstellers.

Äpfel, Birnen und so. Das sind keine Filesystem-Ops, sondern Disk-Ops. 
Völlig andere Baustelle.

von Stefan ⛄ F. (stefanus)


Bewertung
5 lesenswert
nicht lesenswert
udok schrieb:
> Ich würde mir wünschen, das Linuxer nicht immer so prepotent auftreten
> würden, sondern mal den Windows Usern entgegenkommen würden.

Deije Kritik geht an der Realität vorbei-

Sie helfen dabei, Linux kennenzulernen. Sie helfen sogar dabei, Windows 
Probleme zu lösen. Denn die Leute, die von Linux Ahnung haben, haben 
auch meist von Windows überdurchschnittlich viel Ahnung.

: Bearbeitet durch User
von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
udok schrieb:
> Ich würde mir wünschen, das Linuxer nicht immer so prepotent auftreten
> würden, sondern mal den Windows Usern entgegenkommen würden.

Sie sollten sich also vorsätzlich dumm stellen, um sich den 
Windows-Usern anzunähern? ;-)))

von S. R. (svenska)


Bewertung
4 lesenswert
nicht lesenswert
udok schrieb:
>> Scherz beiseite, NTFS ist auf Dateiebene schlicht langsam. [...]
>> Schreibst du nur innerhalb einer Datei rum (wie VMs und
>> Datenbanken das tun) dann ist NTFS nicht nennenswert langsamer [...]
>
> Kann ich nicht nachvollziehen, und gehört mal wieder in
> das Reich der Legenden.

Wieso? Hast du doch gerade bestätigt: Deine saugeile 3 GB/s SSD schafft 
diesen Wert unter Windows, wenn du in großen Dateien rumschreibst. Genau 
das schrieb ich.

> Der gcc ist aber saulangsam unter Windows.  Ich nehme mal an,
> dass der irgendwelche Tricks macht, die unter Linux gut funktionieren,

Nö, der macht keine Tricks, sonst würde er ja nicht unter allen 
möglichen Betriebssystemen von Windows bis AmigaOS funktionieren. 
Allerdings spielt er mit vielen Dateien (was NTFS nicht mag) und vielen 
Prozessen (was der Windows-Kernel nicht mag).

udok schrieb:
> Auch die Ops/s sind unter Windows nahe an den Angaben des
> SSD Herstellers.

Das glaube ich dir unbesehen, schließlich ist deine geile SSD geil und 
die meisten Hardwaretreiber unter Windows sind auch ganz tauglich.

Du verkennst aber, dass du unter Linux mit der gleichen SSD und der 
gleichen Ops-Anzahl wegen des besseren Dateisystems wesentlich mehr 
Dateien verarbeiten kannst.

> Heute wird die Ops/s Performance doch nur vom Cache bestimmt!

[x] Du weißt nicht, was Journalling ist.

> Das Lesen der Files und auch die Ops/s spielen bei der
> Compiliergeschwindigkeit sowieso keine Rolle.

Doch, tun sie. Vor allem dann, wenn dein Projekt nicht winzig ist und 
dein Compiler nicht - wie Visual Studio - alles in eine Datei legt, weil 
das Dateisystem nicht viel taugt.

> Der Overhead muss also woanders sein.

Ja, unter anderem bei den Prozessen. Der gcc (der Name steht für "GNU 
Compiler Collection) besteht aus vielen Prozessen, die für einen 
Compilerlauf gestartet werden, ihre Arbeit erfüllen und dann wieder 
enden.

Auf jedem System mit MMU ist "neuen Prozess starten" unter unixoiden 
Betriebssystemen schnell (ohne MMU muss der Speicher umherkopiert 
werden), unter Windows ist das sehr langsam. Ein Grund dafür ist, dass 
Linux-Prozesse eine Verbindung zu ihrem parent haben und erstmal dessen 
Berechtigungen erben. Windows-Prozesse sind selbstständig und müssen 
erstmal ihren eigenen Sicherheitskontext aufbauen.

> Man kann unter Windows sehr effizient und programmieren,
> auch wenn das zugegebenermassen nur wenige machen.

Die beste Möglichkeit, effizient zu programmieren ist, ineffiziente 
Strukturen zu vermeiden. Unter Windows sind das Dateien, Prozesse und - 
zu einem gewissen Teil - auch Threads.

> Man sieht bei vielen SysCalls, das die Windows Version etliche
> Zusatzparameter hat.  Damit kann man oft mehr Arbeit in einen
> SysCall reinpacken, und Syscalls sind relativ kostspielig.

Komplizierte Syscalls sind prinzipiell erstmal langsamer als einfache 
Syscalls. Und dank SYSENTER bzw. SYSCALL müssen sie nicht unendlich 
langsam sein. Unix hat das begriffen.

> Oder die Möglichkeit, die Thread-Pools zu verwenden!

Alternativ kann man Threads auch "billig" machen, dann muss man nicht.

Im Übrigen ist "Thread erzeugen" unter Windows jetzt nicht so schnell, 
dass es nicht mit "Prozess erzeugen" unter Linux konkurrieren könnte. 
:-)

> Wie wäre es denn mit SysCalls, die zu NT kompatibel sind?

Hast du mal eine vollständige Dokumentation griffbereit, mit der man das 
machen könnte? Interessant wäre es nämlich tatsächlich.

Achso, und kannst du sicherstellen, dass die neue Implementation nicht 
gegen geltendes Recht verstößt (Urheberrecht, Patentrecht und so), also 
auch legal einsetzbar ist?

> Oder wenigstens Editoren, die standardmässig \r\n verstehen?

Die meisten Unix-Editoren können das, muss man allerdings einstellen. Im 
Gegensatz zu Windows-Editoren, die meist nichts anderes können.

> Ein Treibermodell, das näher am Windows Treiberstandard ist?

Du meinst sowas wie ndiswrapper oder ndisgen(8)? Ja, das gab es 
tatsächlich und es war nicht besonders schön. Zumal die Linux-Treiber 
mehr Features hatten als die NDIS-Schnittstelle anbieten konnte.

> Einfache Dinge, die der SW Industrie sehr helfen würde, Programme
> zu portieren.

[x] Du weißt nicht, was das Wine-Projekt tut.

> Das könnte der Grund für den langsamen gcc.exe sein,
> gerade wenn noch online eine Virendatenbank konsultiert wird.

Normalerweise sollte nicht für jeden Dateizugriff eine Online-Datenbank 
konsultiert werden, allerdings hast du in jedem Dateizugriff (der, wie 
gesagt, schon prinzipiell langsam ist) noch einen beliebig langsamen 
Haken drin hängen, der den Zugriff im Zweifelsfall abschießen kann.

von Stefan ⛄ F. (stefanus)


Bewertung
4 lesenswert
nicht lesenswert
udok schrieb:
> Wie wäre es denn mit SysCalls, die zu NT kompatibel sind?

Der Linux Kernel kann exe Dateien ausführen und Windows Treiber (z.B. 
für WLAN) benutzen. Das ist doch schon ein guter Anfang, meinst du 
nicht?

> Oder wenigstens Editoren, die standardmässig \r\n verstehen?

Wirklich jeder Linux Editor konnte das schon immer, seit es Linux gibt.

> Ein Treibermodell, das näher am Windows Treiberstandard ist?

Schon da, siehe WLAN Treiber (NdisWrapper).

> Einfache Dinge, die der SW Industrie sehr helfen würde, Programme
> zu portieren.  Aber nein, Linuxer igeln sich gern ein,
> und stellen den Rest der Welt gern als Idioten hin.

Jetzt mach hier mal nicht den Täter zum Opfer!

Wenn Microsoft nicht den Zugang zu Dokumentationen blockiert hätte, dann 
hätte Linux seit mehr als 20 Jahren einen vollwertigen NTFS Support. Die 
anderen Office Programme könnten vollwertig mit MS-Office Dokumenten 
umgehen und die Vernetzung würde sauber funktionieren. Aber da MS das 
alles nicht will, beruht der entsprechende Code auf viel Raten und 
Vermuten. Der Wille ist seitens der Linux Entwickler durchaus vorhanden 
- logischerweise, denn es besteht ja auch Bedarf.

Microsoft will aber nicht, dass Windows Anwendungen leicht nach Linux 
portierbar sind. Anders herum ist es hingegen kein Problem, denn keiner 
blockiert die umgekehrte Richtung. Die allermeisten Entwickler von Linux 
Programmen unterstützen die Portierung auf Windows sogar aktiv, obwohl 
sie selbst gar kein Windows benutzen.

von Stefan ⛄ F. (stefanus)


Bewertung
3 lesenswert
nicht lesenswert
S. R. schrieb:
>> Der gcc ist aber saulangsam unter Windows.  Ich nehme mal an,
>> dass der irgendwelche Tricks macht, die unter Linux gut funktionieren,

> Nö, der macht keine Tricks, sonst würde er ja nicht unter allen
> möglichen Betriebssystemen von Windows bis AmigaOS funktionieren.
> Allerdings spielt er mit vielen Dateien (was NTFS nicht mag) und vielen
> Prozessen (was der Windows-Kernel nicht mag).

Und da steht der gcc keineswegs alleine da. Java ist ebenso betroffen. 
Dabei startet Java nicht einmal viele Prozesse, sondern nur Threads. 
Doch auch da sind es wieder die vielen kleinen Dateien.

Falls du es mir nicht glauben magst, compiliere mal ein größere Java 
Projekt (z.B. SAP Ecommerce) unter Windows und dann nochmal unter Linux. 
Der Unterschied ist ziemlich Krass. Und das habe ich nicht gerade selbst 
erfunden, sondern während der Schulungen erlebt und bestätigt bekommen. 
Kannst du auch dort nachlesen: 
https://answers.sap.com/questions/12769329/build-speed-difference-between-windows-7-or-10-and.html

Windows: 15 Minuten
Linux: 5 Minuten

: Bearbeitet durch User
von (prx) A. K. (prx)


Bewertung
4 lesenswert
nicht lesenswert
(prx) A. K. schrieb:
> udok schrieb:
>> Auch die Ops/s sind unter Windows nahe an den Angaben des
>> SSD Herstellers.
>
> Äpfel, Birnen und so. Das sind keine Filesystem-Ops, sondern Disk-Ops.
> Völlig andere Baustelle.

Worum geht es dabei:

Reine Disk-Operationen gehen am Filesystem vorbei direkt auf die 
Block-I/O der Disk. Geht nur als Admin, egal ob Windows oder Linux, wird 
also von den üblichen Disk-Benchmarks nicht genutzt, zudem vernichtet es 
die Inhalte.

Die gängigen Disk-Benchmarks operieren also auf grossen Container-Files. 
Sie legen ein grosses File an, vorzugsweise wesentlich grösser als der 
Hauptspeicher, um Caching vorzubeugen. Und darin wird dann je nach 
Bench-Zweig sequentiell oder random gelesen und geschrieben. Disk Ops/s 
sind hier zu finden.

Was ich als Metaoperationen des Filesystems bezeichnete, ist hingegen 
etwas völlig Anderes. Wird ein File gelöscht, geschehen eine Reihe von 
internen Aktionen:

- Interne Handles müssen verwaltet werden, andere Prozesse haben 
vielleicht Zugriff. Hier gibt es einen technischen Unterschied, denn in 
Linux kann man Files auch dann löschen, wenn andere Prozesse darauf noch 
zugreifen. Der eigentliche Löschvorgang findet dann erst statt, wenn der 
letzte Prozess dicht macht. Der Directory-Eintrag hingegen verschwindet 
schon vorher. In Windows verläuft das völlig anders.

- Die bisher belegten Blöcke müssen freigegeben werden.

- Filenodes und Directory-Einträge im Filesystem müssen freigegeben 
werden, sämtliche Verweise eingeschlossen (ausser symbolischen).

Bei all diesen Aktionen muss darauf geachtet werden, dass Crashes an 
keinem Zeitpunkt das Filesystem in unbrauchbarem Zustand hinterlassen. 
Das ist bei den Verwaltungsdaten des Filesystems extrem wichtig, nicht 
aber bei den Inhalten. Dafür gibt es in NTFS und ext4 ein sorgsam 
gepflegtes Journal auf der Disk, um Inkonsistenzen zu vermeiden. Diese 
Absicherung der Integrität kann trotz Caching zu erzwungenen strikt 
sequentiellen Schreiboperationen auf die Disk führen.

Es ist diese Komplexität und Integritätssicherung von 
Filesystemoperationen, die bei vielen Operationen auf kleine Files die 
Laufzeit dominiert. Und die in Windows bei wechselbaren Medien zu 
extremen Verhalten führen kann, denn Windows verhält sich bei denen 
deutlich anders, eben weil es damit rechnen muss, dass der Anwender aus 
alter Gewohnheit das Zeug schlicht rauszieht.

An dieser Stelle können verschiedene Klassen von Filesystemen auch 
völlig anders abschneiden. COW-Filesysteme (ZFS, btrfs) arbeiten intern 
vollkommen anders als solche mit Journalling (NTFS, ext4), und können 
Integrität und Caching effizienter miteinander vereinbaren, als 
Journalling das kann (von den FAT Varianten ganz zu schweigen).

: Bearbeitet durch User
von udok (Gast)


Angehängte Dateien:

Bewertung
-5 lesenswert
nicht lesenswert
Ok, ich sehe, hier braucht es mehr Fakten.

Ein einfacher Test:

1.) Kopieren des Linux Source Codes vom Linus github Verzeichnis,
und entpacken nach H:\Temp

2. time Robocopy.exe linux-master xxx -MIR -NDL -NP -LOG:xxx.log

real    0m23.975s
user    0m0.000s
sys     0m0.015s

Das Kopieren der ca. 71000 Files mit ca. 917 MByte dauert gerade
mal 24 Sekunden.
Und das mit einem einzigen Windows Thread!
Robocopy ist leider ein Uraltprogramm, das die Performance
der SSD bei weitem nicht ausnützt.
Von den 6 Cores wird gerade einer lauwarm.

Trotzdem sieht hier jeder mit Hirn, dass das Kopieren von Files eben
nicht der Bottleneck beim gcc oder auch bei anderen Compilern ist.

Den Rest vom ewiggestrigen BlaBla kommentiere ich nicht, draussen
scheint gerade die Sonne..

von S. R. (svenska)


Bewertung
4 lesenswert
nicht lesenswert
Ich hab das mal unter Linux gemacht:
$ time cp -R linux-5.9.8/ copy

real    0m1,874s
user    0m0,311s
sys     0m1,538s
$ sync
$ time (cp -R linux-5.9.8/ copy2; sync)

real    0m5,375s
user    0m0,340s
sys     0m1,575s
$ du -sh *
1,1G    copy
1,1G    copy2
1,1G    linux-5.9.8
$ find linux-5.9.8/|wc -l
74725

Mit Cache-Flush unter 5,4s, ohne Cache-Flush unter 1,9s. Also ein Faktor 
4-10 schneller, je nachdem, wie man zählen will.

Was mache ich falsch?

(Das System ist ein etwas älteres Asus-Notebook mit Intel-CPU und der 
mitgelieferten Toshiba-SSD.)

Achso, als Nachtrag noch: "cp" ist ebenfalls single-threaded.

: Bearbeitet durch User
von Stefan ⛄ F. (stefanus)


Bewertung
3 lesenswert
nicht lesenswert
S. R. schrieb:
> Was mache ich falsch?

Nichts. Hat auf meinem Laptop auch keine 10 Sekunden gedauert.

von Sheeva P. (sheevaplug)


Bewertung
4 lesenswert
nicht lesenswert
udok schrieb:
> S. R. schrieb:
>> Scherz beiseite, NTFS ist auf Dateiebene schlicht langsam. Warum,
>> schrieb ich bereits (deswegen ist WSL1 auch nahezu unbrauchbar).
>> Schreibst du nur innerhalb einer Datei rum (wie VMs und Datenbanken das
>> tun) dann ist NTFS nicht nennenswert langsamer als alle anderen
>> Dateisysteme da draußen.
>
> Kann ich nicht nachvollziehen, und gehört mal wieder in das Reich der
> Legenden.

Aha: alles, was Du nicht nachvollziehen kannst, "gehört [...] in das 
Reich der Legenden".

> Ich habe eine flotte SSD mit ca. 3000 MByte / Sekunde.

Es geht aber gar nicht um den Durchsatz... so ein Mist.

> Der gcc ist aber saulangsam unter Windows.  Ich nehme mal an,
> dass der irgendwelche Tricks macht, die unter Linux gut funktionieren,
> und unter Windows eben nicht.

Ja, das Dateisystem. GCC macht aus dem Quellcode nämlich viele temporäre 
Dateien mit Zwischencode, die dann (wenn man nicht man den Parameter 
"--save-temps" benutzt) wieder gelöscht werden. Das kann NTFS 
erfahrungsgemäß aber nicht sonderlich gut ab, und genau deswegen ist der 
GCC unter Windows bekanntlich vergleichsweise langsam. Verdammte 
Linux-Tricks aber auch, einfach so schnelle Dateisysteme zu haben! ;-)

von Stefan ⛄ F. (stefanus)


Bewertung
3 lesenswert
nicht lesenswert
S. R. schrieb:
> Was mache ich falsch?

Stefan ⛄ F. schrieb:
> Nichts. Hat auf meinem Laptop auch keine 10 Sekunden gedauert.

Jetzt kann ich auch meine Zeiten von Windows nennen:
220 Sekunden mit dem Dateimanager, 98 Sekunden mit xcopy. Beides bei 
deaktiviertem Virenscanner.

Es hat aus bekanntem Grund etwas länger gedauert, aber auch weil ich den 
Test Wiederholt habe, in der Hoffnung dass er dann schneller wird. Wurde 
er aber nicht.

Sogar das Löschen (mit Shift Taste, also ohne Papierkorb) dauert unter 
Windows länger, als das Auspacken der ZIP Datei unter Linux.

Naja, der Laptop ist auch schon ein paar Jahre alt.

: Bearbeitet durch User
von Sheeva P. (sheevaplug)


Bewertung
5 lesenswert
nicht lesenswert
udok schrieb:
> Im Bild siehst du die Ergebnisse für die Corsair Force Series MP510,
> gemessen mit CrystalDisk.

Meine Güte...

> Ich erinnere mal an die Möglichkeit Overlappend-IO zu machen,
> ein Feature das Linux gerade erst vor kurzem äusserst umständlich
> und natürlich wieder inkompatibel eingebaut hat.

Ja, diese bösen Linuxer haben sich bei Async-I/O einfach an die 
POSIX-Standards gehalten... Schrecklich! Aber "inkompatibel"? lol

> Linux Programmierer verwenden viel zu oft den antiquierten
> fork() Mechanismus!

Das Erzeugen eines Prozesses und eines Thread sind zwar sehr 
unterschiedliche Dinge, aber intern benutzen fork(2) und auch das neuere 
vfork(2) natürlich längst das moderne clone(2). Nebenbei war das mit den 
Threads unter Windows auch ein bisschen aus der Not geboren, denn unter 
Windows ist das Erzeugen von Prozessen ebenfalls nicht gerade schnell. 
Unter Linux ist das Erzeugen eines Prozesses dagegen nur ca. 5% 
langsamer als das Erzeugen eines Threads -- intern sind die Operationen 
sehr ähnlich, zudem nutzt Linux' Speicherverwaltung zunächst 
Copy-on-Write für den neu erzeugten Speicherraum. Erst wenn auf diesen 
Speicher geschrieben wird, wird auch tatsächlich neuer Speicher belegt. 
Deswegen gibt es ja so nette Features wie etwa overcommit_memory 
(/proc/sys/vm/overcommit_*) ... ;-)

> Ich würde mir wünschen, das Linuxer nicht immer so prepotent auftreten
> würden, sondern mal den Windows Usern entgegenkommen würden.
> Embrace, Extend & Extinguish ist ja keine MS Erfindung, das machten
> schon die alten Römer.

Hach ja, immer diese alten Römer mit ihren Threads...

> Wie wäre es denn mit SysCalls, die zu NT kompatibel sind?

Wozu sollten wir Windows nachbasteln?

> Einfache Dinge, die der SW Industrie sehr helfen würde, Programme
> zu portieren.  Aber nein, Linuxer igeln sich gern ein,
> und stellen den Rest der Welt gern als Idioten hin.

Linuxer halten sich üblicherweise an offene Standards wie POSIX. Wer 
sich über Jahrzehnte hinweg gezielt und bewußt eingeigelt und seine 
Implementierungen mit voller Absicht und vollem Bewußtsein inkompatibel 
gemacht hat, war Microsoft.

von Nop (Gast)


Bewertung
5 lesenswert
nicht lesenswert
Sheeva P. schrieb:

> sich über Jahrzehnte hinweg gezielt und bewußt eingeigelt und seine
> Implementierungen mit voller Absicht und vollem Bewußtsein inkompatibel
> gemacht hat, war Microsoft.

Zudem nicht nur inkompatibel, sondern dann auch noch schlecht. Hier 
übrigens ein Benchmark, der zwar schon von 2017 ist, aber seitdem hat 
sich das nicht geändert:

https://www.bitsnbites.eu/benchmarking-os-primitives/

von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
Sheeva P. schrieb:
> Nebenbei war das mit den
> Threads unter Windows auch ein bisschen aus der Not geboren, denn unter
> Windows ist das Erzeugen von Prozessen ebenfalls nicht gerade schnell.

Das hat Tradition. Windows NT wurde von DEC VMS inspiriert, der 
Chefdesigner kam aus dieser Ecke. Und bei VMS war diese Funktion 
berüchtigt langsam.

Windows NT hatte Threads von Anfang an drin. Das lag damals in der Luft.

von (prx) A. K. (prx)


Bewertung
2 lesenswert
nicht lesenswert
udok schrieb:
> Ich erinnere mal an die Möglichkeit Overlappend-IO zu machen,
> ein Feature das Linux gerade erst vor kurzem äusserst umständlich
> und natürlich wieder inkompatibel eingebaut hat.

Die Unix Systemcalls kamen ohne asynchrone Operationen aus, was sie sehr 
einfach gestaltete. Sowohl bei der Nutzung, als auch der 
Implementierung. Auch das unterschied Unix von den damaligen 
Mainframe-Betriebssystemen. Linux stammt davon ab und hat dieses Prinzip 
übernommen.

In VMS waren praktisch alle länger dauernden Systemcalls asynchron 
definiert. Windows NT orientierte sich daran, mit synchroner Operation 
als meistgenutzem Spezialfall. Deshalb steckte das von Anfang an in 
WinNT drin. Komplett anderer Ansatz, mit deutlich höherer systeminterner 
Komplexität.

Eine Lösung, um ohne komplexe asynchrone Systemcalls auszukommen, aber 
dennoch überlappende I/O zu ermöglichen, stellen Threads dar. Das lag 
damals wohl in der Luft, denn ich hatte unabhängig vom Rest der Welt 
praktisch die gleiche Idee. Das ist ein generischer Ansatz, der 
universeller einsetzbar ist als spezielle asynchrone APIs. 
Leichtgewichtige Threads nehmen einem System also den Druck ab, 
asynchrone Operationen zu implementieren.

: Bearbeitet durch User
von Sheeva P. (sheevaplug)


Bewertung
8 lesenswert
nicht lesenswert
Nop schrieb:
> Sheeva P. schrieb:
>
>> sich über Jahrzehnte hinweg gezielt und bewußt eingeigelt und seine
>> Implementierungen mit voller Absicht und vollem Bewußtsein inkompatibel
>> gemacht hat, war Microsoft.
>
> Zudem nicht nur inkompatibel, sondern dann auch noch schlecht. Hier
> übrigens ein Benchmark, der zwar schon von 2017 ist, aber seitdem hat
> sich das nicht geändert:
>
> https://www.bitsnbites.eu/benchmarking-os-primitives/

Huch! Danke für diesen Benchmark. Für die Memory Allocation kannte ich 
das schon von den internen Benchmarks unserer C- und C++-Entwickler, 
aber das Windows beim Starten von Programmen und beim Erzeugen neuer 
Dateien einen Ryzen 1800 Octacore mit 3.6 GHz und einer NVMe-SSD 
braucht, um mit einem RasPi3 mithalten zu können -- wohlgemerkt: auch 
nur, wenn Windows Defender und die Dateisystemindexierung abgeschaltet 
sind -- das war mir tatsächlich neu. Meine Güte... ich wußte schon, das 
manche Dinge unter Windows nicht besonders performant sind, aber das...

Bitte, liebe Linux-Freunde, laßt uns diese Grabenkämpfe hier beenden. 
Diese armen Windows-Benutzer verdienen keinen Spott, sondern unser 
Mitgefühl!

von GPL-Nazi (Gast)


Bewertung
2 lesenswert
nicht lesenswert
udok schrieb:

> Linux Programmierer verwenden viel zu oft den antiquierten
> fork() Mechanismus!

fork() und exec() sind um Längen flexibler und schneller als das was 
Windows zu bieten haben. Das ist eher ein PEBKAC.

von GPL-Nazi (Gast)


Bewertung
3 lesenswert
nicht lesenswert
udok schrieb:
> Ich erinnere mal an die Möglichkeit Overlappend-IO zu machen,
> ein Feature das Linux gerade erst vor kurzem äusserst umständlich
> und natürlich wieder inkompatibel eingebaut hat.
> Damit kann man ein File im Hintergrund lesen, und gleichzeitig
> sinnvolle Sachen im Programm machen. Auch wird der Buffer
> nur einmal geschrieben, mit DMA, ohne CPU Clocks zu verbraten.
> Ist auch im Zusammenhang mit USB 3.x sinnvoll, um die volle
> Geschwindigkeit zu erreichen, oder auch mit modernen SSDs.

Knall dir bitte dieses Paper rein, wo erklärt ist warum eine neue 
Schnittstelle geschaffen wurde: https://kernel.dk/io_uring.pdf
Das alte asynchrone Schnittstellendesign war schlicht zu langsam.

Und hier ist ein Ergebnis: 
https://static.sched.com/hosted_files/osseu2020/c8/KVMForum_2020_io_uring_passthrough_Stefano_Garzarella.pdf

Sehr geiles Zeug, so langsam kann mal darüber nachdenken auch 
Monsterdatenbanken (CPUs ~ 200, LUNs > 400, RAM >= 4TB, DB-Grösse > 100 
TB (All-Flash), >= 4 HBA-Ports) auf VMs zu migrieren. Physik ist einfach 
unhandlicher und die Kunden mögen keine Downtimes bei solchen Dingern. 
Ein Grund weniger für AIX.

von GPL-Nazi (Gast)


Bewertung
2 lesenswert
nicht lesenswert
(prx) A. K. schrieb:

> Eine Lösung, um ohne komplexe asynchrone Systemcalls auszukommen, aber
> dennoch überlappende I/O zu ermöglichen, stellen Threads dar. Das lag
> damals wohl in der Luft, denn ich hatte unabhängig vom Rest der Welt
> praktisch die gleiche Idee. Das ist ein generischer Ansatz, der
> universeller einsetzbar ist als spezielle asynchrone APIs.
> Leichtgewichtige Threads nehmen einem System also den Druck ab,
> asynchrone Operationen zu implementieren.

Wobei der gängige Ansatz für jeden Furz eine Thread zu starten nur 
bedingt skaliert. Schau dir mal an was so manche Anwendungen an 
Contextswitches/sec generieren, üblicherweise genau dann wenn die 
Anwender über Performanceprobleme klagen oder irgentwelche Locks oder 
Sync austimen. Da verreckt die Performance in den Contextswitches.

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
GPL-Nazi schrieb:
> Sehr geiles Zeug, so langsam kann mal darüber nachdenken auch
> Monsterdatenbanken (CPUs ~ 200, LUNs > 400, RAM >= 4TB, DB-Grösse > 100
> TB (All-Flash), >= 4 HBA-Ports) auf VMs zu migrieren.

räusper Äh, macht man sowas heute denn noch auf so Monsterbüchsen? 
Immerhin skaliert der Preis exponentiell zur Größe vom Blech. Ist es da 
nicht sinnvoller, bei passenden Workloads auf dynamische Cluster von 
vielen kleinen Commoditymaschinen zu gehen? K8s, Redis, RoCE... sowas in 
der Richtung?

> Physik ist einfach
> unhandlicher und die Kunden mögen keine Downtimes bei solchen Dingern.

High Availability ist bei solchen Speichergrößen halt immer so eine 
Sache, und High Resilience hilft da leider nur bedingt... ;-)

> Ein Grund weniger für AIX.

Yay! ;-)

von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
GPL-Nazi schrieb:
> Wobei der gängige Ansatz für jeden Furz eine Thread zu starten nur
> bedingt skaliert.

Richtig. Man muss Worker-Threads zwar nicht für jeden Furz neu anlegen, 
aber die Last ist höher als bei asynchroner I/O. Andererseits sind 
Threads viel flexibler einsetzbar, während asynchrone I/O eine spezielle 
Lösung darstellt.

Nun, da Linux auch als Grundlage grosser Systeme mit grossen Datenmengen 
genutzt wird, bei denen der Bedarf gegeben ist, hat man darauf eben 
reagiert.

: Bearbeitet durch User
von GPL-Nazi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Sheeva P. schrieb:
> räusper Äh, macht man sowas heute denn noch auf so Monsterbüchsen?
> Immerhin skaliert der Preis exponentiell zur Größe vom Blech. Ist es da
> nicht sinnvoller, bei passenden Workloads auf dynamische Cluster von
> vielen kleinen Commoditymaschinen zu gehen? K8s, Redis, RoCE... sowas in
> der Richtung?

An dem einem Ding baut der Hersteller der Software schon ~8 Jahre an so 
einer Umstellung, Larry freut sich, neue Segelboote sind immer gut.

von GPL-Nazi (Gast)


Bewertung
1 lesenswert
nicht lesenswert
(prx) A. K. schrieb:

> Richtig. Man muss Worker-Threads zwar nicht für jeden Furz neu anlegen,
> aber die Last ist höher als bei asynchroner I/O. Andererseits sind
> Threads viel flexibler einsetzbar, während asynchrone I/O eine spezielle
> Lösung darstellt.

Bei Anwendungen in Java ist das gängige Praxis.

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
GPL-Nazi schrieb:
> An dem einem Ding baut der Hersteller der Software schon ~8 Jahre an so
> einer Umstellung, Larry freut sich, neue Segelboote sind immer gut.

Ach, Leisure Suit Larry... mal persönlich begegnet. Ein ausgesprochener 
Unsympath und die Software... naja.  Wobei: die Boote sind viel cooler 
als die Software, auch wenn die Kiwis seine Leute letztes Mal so extrem 
cool gedemütigt haben, daß es eine wahre Freude war. Einfach großartig! 
;-)

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
4 lesenswert
nicht lesenswert
Sheeva P. schrieb:
> Linuxer halten sich üblicherweise an offene Standards wie POSIX. Wer
> sich über Jahrzehnte hinweg gezielt und bewußt eingeigelt und seine
> Implementierungen mit voller Absicht und vollem Bewußtsein inkompatibel
> gemacht hat, war Microsoft.

BTW: Microsoft stellte mit Windows NT drei Subsysteme bereit:

- Win32
- OS/2
- POSIX

Windows NT implementierte das POSIX-Subsystem hauptsächlich, um Aufträge 
der US-Regierung zu erhalten, da diese im Federal Information Processing 
Standard 151-2 POSIX-Kompatibilität forderten.

Als Microsoft ihre Regierungsaufträge an Land gezogen haben, haben sie 
POSIX wieder rausgekickt.

Nachzulesen unter anderem hier:

https://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem
https://en.wikipedia.org/wiki/Architecture_of_Windows_NT

: Bearbeitet durch Moderator
von Cyblord -. (cyblord)


Bewertung
-6 lesenswert
nicht lesenswert
Frank M. schrieb:
> Als Microsoft ihre Regierungsaufträge an Land gezogen haben, haben sie
> POSIX wieder rausgekickt.

Das ist halt schlau, geschäftstüchtig und ideologiefrei. Der Linuxer 
will ja kein Geschäft machen, er will die Welt verändern und daher steht 
die Ideologie an erster Stelle.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
3 lesenswert
nicht lesenswert
Cyblord -. schrieb:
> Das ist halt schlau, geschäftstüchtig und ideologiefrei. Der Linuxer
> will ja kein Geschäft machen, er will die Welt verändern und daher steht
> die Ideologie an erster Stelle.

Windows NT 3.51 stammt von 1993, da dachte man bei POSIX eher an die 
kommerziellen UNIX-Systeme, nicht an Linux. Das wurde da gerade erst 
geboren.

Ich sehe das eher andersherum: MS hat damals eine große Chance verpasst. 
Nein, ich rede nicht von Desktop-PCs, sondern von echten Serversystemen.

: Bearbeitet durch Moderator
von Cyblord -. (cyblord)


Bewertung
-5 lesenswert
nicht lesenswert
Frank M. schrieb:
> Ich sehe das eher andersherum: MS hat damals eine große Chance verpasst.
> Nein, ich rede nicht von Desktop-PCs, sondern von echten Serversystemen.

Ja hätten sie die Chance nur mal genutzt dann wäre Bill Gates vielleicht 
der reichste Mann der Welt geworden. Oh warte mal....

: Bearbeitet durch User
von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
3 lesenswert
nicht lesenswert
Cyblord -. schrieb:
> Ja hätten sie die Chance nur mal genutzt dann wäre Bill Gates vielleicht
> der reichste Mann der Welt geworden.

Reden wir hier von Betriebssystem-Qualitäten oder davon, mit was man am 
meisten Geld verdienen kann?

Es ging hier um File-I/O, wo Linux jedes Windows um Längen schlägt. Oder 
kennst Du auch nur einen TOP-500 Windows-Rechner?

: Bearbeitet durch Moderator
von Cyblord -. (cyblord)


Bewertung
-3 lesenswert
nicht lesenswert
Frank M. schrieb:

> Reden wir hier von Betriebssystem-Qualitäten oder davon, mit was man am
> meisten Geld verdienen kann?

Du musst mal anfangen zu verstehen dass MS überhaupt nur Software und OS 
schreibt um GELD ZU VERDIENEN. Krass oder?
Das hängt direkt zusammen. Die OS Qualität hat wohl gereicht um 
Wagenladungen an Dollars zu machen. Wirklich unanständig viel Geld.

> Es ging hier um File-I/O, wo Linux jedes Windows um Längen schlägt. Oder
> kennst Du auch nur einen TOP-500 Windows-Rechner?

Und wen interessierts? Die können die TOP-500 Liste nicht sehen weil die 
unter dem Berg von Dollars liegt.

: Bearbeitet durch User
von Stefan ⛄ F. (stefanus)


Bewertung
4 lesenswert
nicht lesenswert
Cyblord -. schrieb:
> Der Linuxer will ja kein Geschäft machen, er will die Welt
> verändern und daher steht die Ideologie an erster Stelle.

Man merkt dass du das Buch von Linux nicht gelesen hast. Seine 
motivation war anfangs viel banaler: Er wollte die Multitasking Features 
seines neuen teuren 386er Rechners ausnutzen. Später wollte er ein Unix 
ähnliches Betriebssystem. Und noch später wollte er OSS fördern. Ich 
glaube nicht, dass er sich einbildete, damit die Welt zu verändern.

So dumm (sich das einzubilden) sind sicher nur wenige Menschen, die 
sollte man nicht Millionen anderen in einen Topf werfen.

Ich bin sicher: Wenn wir Linux nicht hätten, dann wäre ein anderes OS 
zum Erzfeind von Microsoft geworden. Vielleicht Minix, oder Solaris, 
oder Mac OS, oder OS/2, oder ...

: Bearbeitet durch User
von Cyblord -. (cyblord)


Bewertung
-3 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Man merkt dass du das Buch von Linux nicht gelesen hast. Seine
> motivation war anfangs viel banaler: Er wollte die Multitasking Features
> seines neuen teuren 386er Rechners ausnutzen. Später wollte er ein Unix
> ähnliches Betriebssystem. Und noch später wollte er OSS fördern. Ich
> glaube nicht, dass er sich einbildete, damit die Welt zu verändern.

Jede Religion braucht ihre Schöpfungsgeschichte.
Dieses damals ist lange her.
Und ich glaube auch nicht dass Linus die Ideologie der Linuxer vorgibt. 
Das hat sich längst verselbständigt.

von Le X. (lex_91)


Bewertung
3 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Ich bin sicher: Wenn wir Linux nicht hätten, dann wäre ein anderes OS
> zum Erzfeind von Microsoft geworden.

Ich wundere mich immer wieder über solche Begrifflichkeiten.
Ich wiederhole mich: man sollte das Thema "PC-Betriebssystem" weniger 
emotional sehen.
Wo's passt nimmt man das Eine, wo's nicht passt das andere und manchmal 
vielleicht sogar das ganz andere.
Je nach persönlichem Gusto.

Begriffe wie "Erzfeind" implizieren natürlich schon eine irrationale 
Ablehnung und machen eine vernünftige Diskussion im Vorfeld unmöglich.
Denn mit dem Erzfeind diskutiert man nicht, den erledigt man.

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
Cyblord -. schrieb:
> Jede Religion braucht ihre Schöpfungsgeschichte.
> Dieses damals ist lange her.

Sicher. Es könnte auch sein, dass er die Geschichte so darstellt, wie er 
sie am liebsten gehabt hätte. Wir können seine Story nur glauben.

> Und ich glaube auch nicht dass Linus die Ideologie der Linuxer vorgibt.
> Das hat sich längst verselbständigt.

Das ist Schubladen-Denken. Frage mal Besitzer von Pitbulls was die davon 
halten, dass ihre Hunde angeblich Babies fressen.

Es gibt die "die Linuxer".

von Cyblord -. (cyblord)


Bewertung
-3 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Das ist Schubladen-Denken. Frage mal Besitzer von Pitbulls was die davon
> halten, dass ihre Hunde angeblich Babies fressen.

Da kann man ja auch gleich die Frösche fragen bevor man den Teich 
trockenlegt.
Allerdings erscheinen "Die Linuxer" in diesem Thread zwar nicht im 
besten Licht, aber dennoch sehr einmütig um nicht zu sagen homogen.

von N. A. (bigeasy)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Es ging hier um File-I/O, wo Linux jedes Windows um Längen schlägt.

Sehr schön.

Frank M. schrieb:
> Oder kennst Du auch nur einen TOP-500 Windows-Rechner?

Die Topp-500 Liste ist ganz nett, wobei ich mich frage, was diese mit 
dem Thema hier zu tun hat. Das ein Muldenkipper mehr transportieren kann 
als ein Mittelklassekombi ist gemeinhin bekannt. Den braucht Lieschen 
Müller jedoch maximal zum Hausbauen.

Und ganz unabhängig davon, bin ich mir nicht sicher ob File-I/O 
Performance das ausschlaggebende Kriterium für "Topp500"-Numbercrunching 
ist...

von N. A. (bigeasy)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Ich sehe das eher andersherum: MS hat damals eine große Chance verpasst.
> Nein, ich rede nicht von Desktop-PCs, sondern von echten Serversystemen.

Ging es hierbei nicht vorrangig um Desktop-Systeme? --> Th.

von Nop (Gast)


Bewertung
3 lesenswert
nicht lesenswert
N. A. schrieb:
> Und ganz unabhängig davon, bin ich mir nicht sicher ob File-I/O
> Performance das ausschlaggebende Kriterium für "Topp500"-Numbercrunching
> ist...

Es hat ein Windowsnutzer genölt, daß sein Spielestarter-OS lahm ist, 
wenn man es für produktive Entwicklungsarbeit mißbraucht, konkret um mit 
GCC nennenswerte Projekte zu übersetzen.

von Nop (Gast)


Bewertung
3 lesenswert
nicht lesenswert
Cyblord -. schrieb:
> Das hängt direkt zusammen. Die OS Qualität hat wohl gereicht um
> Wagenladungen an Dollars zu machen. Wirklich unanständig viel Geld.

MS hat das sogar noch optimiert, indem sie seit Windows 10 ihre 
QA-Abteilung zusammengestrichen haben und die Endnutzer als kostenlose 
Betatester einspannen. Daß diese Kostenersparnis in MS' Interesse ist - 
klar. Aber daraus folgt nicht, daß das auch in Deinem Interesse als 
Nutzer wäre.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Nop schrieb:
> Daß diese Kostenersparnis in MS' Interesse ist - klar.
> Aber daraus folgt nicht, daß das auch in Deinem Interesse als
> Nutzer wäre.

Ist denen auch wohl ziemlich egal, denn sie haben genug Nutzer an sich 
gebunden. Vor allem mit ihren hauseigenen "Standards", die keiner 
nachbauen kann/darf.

: Bearbeitet durch User
von Cyblord -. (cyblord)


Bewertung
-2 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> denn sie haben genug Nutzer an sich
> gebunden. Vor allem mit ihren hauseigenen "Standards", die keiner
> nachbauen kann/darf.

Einfach nur immer die Dolchstoßlegende Wiederholen. Linux wäre heute 
bestimmt Nr. 1 auf dem Desktop, wenn nur MS nicht so extrem gemein mit 
den Standards wäre.
Gewinner finden Wege, Verlierer finden Gründe.

: Bearbeitet durch User
von Nop (Gast)


Bewertung
5 lesenswert
nicht lesenswert
Cyblord -. schrieb:
> Gewinner finden Wege
MS "gewinnt" aber auf Kosten der Nutzer. Das funktionert hier nicht wie 
ein Fußballfanclub.

von Stefan ⛄ F. (stefanus)


Bewertung
5 lesenswert
nicht lesenswert
Cyblord -. schrieb:
> Gewinner finden Wege, Verlierer finden Gründe.

Genau. Der Gewinner (MS) hat herausgefunden, wie man Kunden an sich 
bindet und nutzt das jetzt erfolgreich aus. Das habe ich nie bestritten.

von GPL-Nazi (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Cyblord -. schrieb:
> Frank M. schrieb:
>> Als Microsoft ihre Regierungsaufträge an Land gezogen haben, haben sie
>> POSIX wieder rausgekickt.
>
> Das ist halt schlau, geschäftstüchtig und ideologiefrei.

Intel macht ja gerade vor wie das funktioniert.

von GPL-Nazi (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Cyblord -. schrieb:

> Jede Religion braucht ihre Schöpfungsgeschichte.
> Dieses damals ist lange her.
> Und ich glaube auch nicht dass Linus die Ideologie der Linuxer vorgibt.
> Das hat sich längst verselbständigt.

Ach Bengel, such es dir selbst aus den Usenet Archiven raus, und 
verbreite hier nicht so einen Unsinn.

von GPL-Nazi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Nop schrieb:

> Jahaaa, und bei Linux heißt es, daß dank Paketmanager mit Distro-Repo
> jede Anwendung allfällige Sicherheitsupdates in Bibliotheken bekommt.
> Was wurde hier gerade vorgeschlagen? Hey, laßt doch jede Anwendungen mit
> einem eigenen PPA anrollen! Ja super Idee!

Bitte zitiere mich richtig, danke.

von GPL-Nazi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jack V. schrieb:
> Nop schrieb:
>> Es wurde bescheid gesagt, aber ignoriert.
>
> Keine Distribution popelt sich Kram aus‘m Git-Repo – so funktioniert das
> einfach nicht. Kann man mögen oder auch nicht, aber Anwendungsprobleme
> dem OS anzulasten, ist nach wie vor irgendwie vollkommen „aber ich
> muss nun was dagegen gesagt haben!!k“.

Schon mal ein openwrt gebaut?
Da zieht sich der Build-Prozess selbst die Sachen aus den öffentlichen 
Source-Repos.

von ACDC (Gast)


Bewertung
1 lesenswert
nicht lesenswert
S. R. schrieb:
> Was mache ich falsch?

In deiner Welt nix.

In der Otto Windows Welt alles.

von S. R. (svenska)


Bewertung
3 lesenswert
nicht lesenswert
Frank M. schrieb:
> BTW: Microsoft stellte mit Windows NT drei Subsysteme bereit:
> - Win32
> - OS/2
> - POSIX

Anzumerken wäre, dass das OS/2-Subsystem auf OS/2 1.x basierte und keine 
grafischen Anwendungen unterstützte und das POSIX-Subsystem kein 
Multithreading unterstützte und damit auch fast wertlos war.

Cyblord -. schrieb:
> Der Linuxer

Mir wäre jetzt nicht bekannt, dass "der Linuxer" eine homogene Gruppe 
wäre. Aber gut, so als Schaf ist die Welt auch recht einfach...

ACDC schrieb:
> S. R. schrieb:
>> Was mache ich falsch?
> In deiner Welt nix.
> In der Otto Windows Welt alles.

Könntest du das bitte etwas konkretisieren?

von Christobal M. (c_m_1)


Bewertung
3 lesenswert
nicht lesenswert
Ich hab mir für den Windows Spielerechner grade eine M.2 SSD zugelegt 
und hab das zum Anlass genommen die alte Windows Installation neu zu 
machen.

Zum Thema "Linux sei so kompliziert", "kaum zu installieren", "immer die 
blöde Shell".
Ich wollte in Windows Autologon haben - bin der einzige Nutzer und sehe 
nicht ein warum ich da immer das Passwort eingeben soll.
Internet sagt man müsse die Windows Taste drücken, und "netplwiz" (was 
soll das eigentlich bedeuten?) eintippen und ausführen, und dort den 
Haken aus "Die User müssen das Passwort angeben" weg machen.
Problem: Das Kästchen war gar nicht da - ich konnte nichts klicken.
Weiter im Internet gestöbert, man solle regedit aufrufen und einen Key 
(welchen konnte ich mir nicht merken, irgendwas mit HKEY-LOCAL-MACHINE 
oder so. (SCNR)) von 2 auf 0 ändern.
Jetzt war, nach Reboot natürlich, das Kästchen wieder da und Autologon 
geht nun.

Eine Stunde rumgefummel wegen so einem Scheiss... Das finde ich als 
Senior Linux Nutzer wohl genau so schlimm wie Windows Nutzer die 
"Scheiss Shell".

von (prx) A. K. (prx)


Bewertung
2 lesenswert
nicht lesenswert
Christobal M. schrieb:
> Eine Stunde rumgefummel wegen so einem Scheiss...

Für solche Frickeleien gibts in Windows natürlich 3rd party Apps, damit 
es nicht so nach Registry aussieht.

von 100Ω W. (tr0ll) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Ralph S. schrieb:
> - "Mein Nachbar sagt, dass die Internetunterstützung für Linux bald
> eingestellt wird und dann muß man sowieso Windows benutzen" -  kein
> Scheiß jetzt, so schon gehört. Da kannst du erklären wie du willst, dass
> die Browser für Android (was große Linuxteile beinhaltet) und Linux
> technisch gesehen nur kleine Unterschiede besitzen

Der Nachbar glaubt aber auch nocht an den Weihnachtsmann?

SCNR

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
> Mein Nachbar sagt, dass die Internetunterstützung für Linux bald
> eingestellt wird

Man kann genau so wenig sagen, dass demnächst das Kaffeepulver nicht 
mehr die Kaffeemaschinen von Philips unterstützen wird.

Es ist ja nicht so, dass Linux vom Internet unterstützt wird, sondern 
umgekehrt.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.