Login
Newsletter
0
Von klopskind am Do, 17. Oktober 2019 um 12:01

Moment - ich kritisiere PD ja explizit nicht dafür, daß sie wechseln, bzw. halte unter den Voraussetzungen, die sie machen, den Wechsel für völlig nachvollziehbar.
Dann hatte ich Ihren Kommentar wohl teils falsch aufgefasst.

Ich dachte, Sie würden zumindest im Subtext versuchen, die von mir gegebene Antwort als Klärung der Entscheidungsgrundlage des Projekts zu relativieren. Welche Aussage meines Kommentars ist falsch? Was verschweigt mein Kommentar vorsätzlich?

Es kommen aber jetzt natürlich Fragen auf, die undifferenziert fragen, ob denn FreeBSD wirklich untauglich sei. Und das ist meiner Erfahrung nach so pauschal zu verneinen.
Ich sagte nur, dass es für den Desktop derzeit untauglicher als Linux sei. Das müssen Sie auch als Antwort auf die Fragen des Eingangskommentars bewerten. In diesem Sinne habe ich also einen Vergleich gezogen, statt absolut referenzlose Aussagen bezüglich FreeBSD zu treffen. In letztere Kategorie könnte man am Ehesten noch meine Aussage "Kurz gefasst, ja." interpretieren. Diese relativiere ich im folgenden Satz aber gleich selbst wieder.

Jetzt stellt sich mir die Frage: An welchem Punkt kommen diese undifferenzierten Fragen auf?

zu 1) Ja, scheinbar kann oder konnte man das irgendwie hinfrickeln mit Linuxulator und den 32-bit CUDA-Bibliotheken für Linux. Aber realistisch wird es nicht so unterstützt, wie unter Linux. Werden die Bibliotheken für 32-bit seitens Nvidia tatsächlich noch angeboten? Quellen: 1, 2, 3

zu 2) Ja, es klappt meiner Erinnerung nach zumindest für ThinkPads ganz okay. Natürlich mit einigen Macken, die teils auch bei Linux existier(t)en. Die proprietären Schnittstellen der meisten Docks werden zunehmend durch Thunderbolt ersetzt. Letzteres steht auf der ToDo-Liste des erwähnten Intel-Entwicklers (Stand Juli 2018; daran hat sich meines Wissens nach nichts geändert).

zu 3)
3a) USB: Meines Wissens gab es unter FreeBSD lange Zeit das Problem, dass das Abstecken von USB-Speichergeräten reproduzierbar einen Kernel-Panic verursachte, falls noch ein Dateisystem, das darauf lag, im System eingebunden gewesen ist. Natürlich sollte man das als Endanwender unterlassen, da es in jedem Fall zu einem korrupten Dateisystem führen kann, aber ein Kernel-Panic muss nicht sein. Andere Betriebssysteme schaffen das auch. Die Unterstützung für USB3 ließ ebenfalls auf sich warten im direkten Vergleich zu Linux.

3b) Wireless: Ich stimme Ihnen soweit zu. Man kann den aktuelleren Stand - und um den geht es ja hier - in diesem Wiki nachvollziehen und vergleichen.

4) Ich glaube, dass die Ursprünge heute größtenteils irrelevant sind. Auch habe nie behauptet, dass es unter Linux gravierende und zu FreeBSD analoge Einschränkungen nicht gegeben hätte (und sogar weiterhin gibt).

Um zum Projekt und deren Entscheidung zurückzukommen: Wäre diese Einstellung bzw. deren konsequente Fortführung optimal im Sinne der vom Projekt formulierten Ziele/Gründe? Ich meine, dass dies nicht der Fall ist.

5) Ja, kann sein. Wir werden sehen. Ich glaube nicht, dass es eine falsche Entscheidung ist. Im Gegenteil: Ich denke, dass sich diese Entscheidung nicht nur fürs Projekt, sondern auch das restliche Ökosystem, positiv auswirken wird. Denn diejenigen, die einen Desktop auf Basis von FreeBSD wünschen, haben weiterhin GhostBSD, NomadBSD oder MidnightBSD zur Wahl. Und die anderen können bei Projekt Trident bleiben, oder eine bestehende Linux-Distro mit Desktop-Fokus nutzen.
Falls das Projekt dabei mangels Nutzern doch eingehen sollte, wäre die Diversität des Ökosystems nicht geschrumpft. Die bisherigen Nutzer hätten sich lediglich auf die Alternativen verteilt, was einer scheinbar unnötigen Fragmentierung des Ökosystems entgegenwirken würde und weitere Synergien und Potentiale wecken könnte. Was wäre daran so "falsch" (tragisch?)?

0
Von Monika L. am Do, 17. Oktober 2019 um 11:54

Linux 5.2.20 wurde auch lange nach 5.3.0 veröffentlicht und dann noch die ganzen 3.x und 4.x LTS

Erschienen diese ganzen Releases auch nach dem angekündigten EOL-Datum?

0
Von Monika L. am Do, 17. Oktober 2019 um 11:47

iOS und macOS basieren beide auf Darwin, welches wiederum auf BSD basiert.

Wo gibt es da eine Monokultur?

0
Von Bert am Do, 17. Oktober 2019 um 11:40

Echt? Du willst ein Wettrennen? ;-)
Im Artikel oben ging es um KDE Plasma 5.17 und ich schrieb von Kubuntu.
Mit 7GB Installation hast Du kein Kubuntu und vermutlich noch nicht mal Plasma 5.17. 2:0 für mich. ;-)

RAID10 und der Klon davon mit SSD bootet in 14 Sekunden
Bei doppelter Lade-Geschwindigkeit rechnen wir mal zwei - dann bin ich aber mit meinem Billig-Kärtchen aber relativ schneller. :-) 3:0 für mich. ;-)
Mit was gebootet? Windows XP? ;-) Das war vor acht Jahren noch aktuell.

In meiner Testinstallation ging es nicht um "schnell", sondern in Zeiten der Klimakrise um "Strom sparen", und darum, eine alte Festplatte zu entfernen und lediglich eine M.2-SATA-SSD für 24€ zu testen. 4:0 für mich. ;-)

Im Mischbetrieb mit einer Festplatte. Die schreibintensiven Verzeichnisse /var und der User liegen auf der Festplatte, die ladeintensiven Programme auf der SSD. Dass macht den Faktor sechs beim Booten aus. Und so kommt man mit einer kleinen, kostengünstigen SSD zurecht. Für Testbetrieb reicht das allemal.

Um damit kostengünstig die Funktionalität eines PCIe-M.2-Adapters zu testen.
Die bis zu siebenmal schnelleren NVMe-SSDs kommen erst noch. 5:0 für mich. ;-)
Wir warten noch ein bisschen bis die Preise gefallen sind.

Und weil das so gut läuft, haben wir beschlossen, das fünf Jahre alte Mainboard zu belassen, nochmal acht Gigabyte RAM wegen der noch günstigen DDR3-Preise nachzurüsten, und erst nächstes Jahr eine effizientere Hardware zu kaufen. Ein acht Jahre alter Spielerechner, der mal modern war, ist für uns deutlich zu alt. 6:0 für mich. ;-)

Wir erfreuen uns daran, dass Kubuntu jetzt erstmal sechsmal so schnell bootet wie in der alten Installation. Und mit 16GB ist der Rechner leistungsfähig genug, unsere Vereinszeitung per DTP zu gestalten. Meine Frau bekommt dafür mehr Speicher, und ich bekomme mehr RAM für /tmp. Und wir beide profitieren von etwas größerem Arbeitskomfort. Reicht doch. Die Kosten dafür haben wir nächstes Jahr wieder raus, wenn neue Hardware deutlich billiger geworden ist. Aber erstmal machen wir auf unserer zuverlässigen Hardware weiter.

Dann weiter: es reicht der ganz normale Backup mit USB3-Festplatten. RAID10 ist sowas von oversized und ersetzt auch nicht Backup. Das bedeutet vierfachen Verschleiß im Verhältnis zu absoluter Sicherheit, die keine ist. Was machst Du denn, wenn eine Deiner vier SSDs ausfällt? Dein Konzept ist keines, wenn Du sie nicht sofort ersetzt. Hast Du dann noch genügend Geld, sofort eine neue 2TB-SSD zu kaufen? An einem veralteten Spielerechner? Ich würde sagen: 7:0 für mich. ;-)

Aber nur zu. Meine Frau hat genug Chips gekauft. 8:0 für mich. ;-)

pointer schrieb:

Bei Tendenz zu negativem Denken empfehle ich gerne "Anleitung zum Unglücklichsein" von Paul Watzlawick.

Gerald Hüther ist auch nicht schlecht. ;-)

0
Von Monika L. am Do, 17. Oktober 2019 um 11:05

und was hat das mit der Lizenz, speziell der von gtk zu tun um welches im Artikel so gar nicht geht?

LGPL-Bibliotheken ermöglichen die Entwicklung geschlossener, kommerzieller Software auf Systemen, wo die erforderlichen LGPL-Bibliotheken entweder bereits vorhanden sind, oder per Paketmanager nachinstalliert werden können (also z.B. auf üblichen Linux-Distributionen). Bei statisch gelinkten Anwendungen oder Binärpaketen ist das aufgrund der Bedingungen Ziff. 6 II a.) LGPL v2 so gut wie unmöglich (Es sei denn, man stellt den Quell- oder Objekt-Code für Neukompilierungen durch den Kunden zur Verfügung und sorgt dafür das der Kunde das neue Binary auch installieren kann).

Die weiter oben stehende Aussage, (verkürzt): "GTK+ / LGPL / open source oder kommerziell-geschlossen / alles ist möglich", ist also falsch. Google hat das z.B. bei Android erkannt und verwendet deshalb keine LGPL-Bibliotheken, für die Hersteller von eingebetteten Systemen gilt das analog (man stelle sich nur vor, ein Autohersteller wäre aufgrund der Verwendung von LGPL-Bibliotheken dazu gezwungen dafür zu sorgen, dass der Kunde seinen Instrumenten-Cluster mit einer vom Kunden geänderten LGPL-Bibliothek neu kompilieren und installieren kann).

Fazit: LGPL-Bibliotheken sind in vielen Fällen also keineswegs eine Alternative zu einer kommerziellen Lizenz und deshalb ist GTK+ auch keine Alternative zu Qt (da es GTK+ weder unter einer kommerziellen Lizenz, noch unter der BSD- oder MIT-Lizenz gibt).

Ich hoffe, damit ist Deine Frage beantwortet.

1
Von wurzel am Do, 17. Oktober 2019 um 10:34

da sind wir uns ja mal einig ...
Der Grund wird sein, dass Plasma wg. der erhebliche höheren Komplexität mehr Anpassungsaufwand verlangt. Das sparen sich einige eben.


Plasma ist das kleinste verfügbare Übel ..

0
Von Anonymous am Do, 17. Oktober 2019 um 10:27

Der getroffene Hund jault?

Du hast um 0:14 wirres Zeug ohne Punkt und Komma geschrieben, nicht ich.

0
Von Robert am Do, 17. Oktober 2019 um 10:19

pypy3


Test minimum average operation overhead
-------------------------------------------------------------------------------
BuiltinFunctionCalls: 0ms 5ms 0.01us 0.005ms
BuiltinMethodLookup: 0ms 1ms 0.00us 0.005ms
CompareFloats: 0ms 1ms 0.00us 0.005ms
CompareFloatsIntegers: 0ms 1ms 0.00us 0.003ms
CompareIntegers: 0ms 1ms 0.00us 0.009ms
CompareInternedStrings: 0ms 1ms 0.00us 0.023ms
CompareLongs: 0ms 1ms 0.00us 0.003ms
CompareStrings: 0ms 1ms 0.00us 0.015ms
ComplexPythonFunctionCalls: 7ms 9ms 0.05us 0.006ms
ConcatStrings: 0ms 1ms 0.00us 0.012ms
CreateInstances: 13ms 15ms 0.13us 0.013ms
CreateNewInstances: 9ms 14ms 0.17us 0.012ms
CreateStringsWithConcat: 0ms 1ms 0.00us 0.014ms
DictCreation: 0ms 1ms 0.00us 0.004ms
DictWithFloatKeys: 38ms 42ms 0.05us 0.010ms
DictWithIntegerKeys: 10ms 11ms 0.01us 0.014ms
DictWithStringKeys: 13ms 14ms 0.01us 0.016ms
ForLoops: 3ms 6ms 0.26us 0.003ms
IfThenElse: 0ms 1ms 0.00us 0.012ms
ListSlicing: 18ms 18ms 1.31us 0.003ms
NestedForLoops: 10ms 10ms 0.01us 0.003ms
NestedListComprehensions: 8ms 11ms 0.94us 0.002ms
NormalClassAttribute: 5ms 6ms 0.01us 0.011ms
NormalInstanceAttribute: 4ms 5ms 0.00us 0.023ms
PythonFunctionCalls: 0ms 2ms 0.01us 0.007ms
PythonMethodCalls: 53ms 58ms 0.26us 0.012ms
Recursion: 6ms 7ms 0.14us 0.008ms
SecondImport: 115ms 126ms 1.26us 0.003ms
SecondPackageImport: 118ms 121ms 1.21us 0.003ms
SecondSubmoduleImport: 128ms 134ms 1.34us 0.003ms
SimpleComplexArithmetic: 0ms 1ms 0.00us 0.007ms
SimpleDictManipulation: 12ms 16ms 0.01us 0.008ms
SimpleFloatArithmetic: 0ms 1ms 0.00us 0.010ms
SimpleIntFloatArithmetic: 0ms 1ms 0.00us 0.010ms
SimpleIntegerArithmetic: 0ms 1ms 0.00us 0.010ms
SimpleListComprehensions: 6ms 8ms 0.70us 0.003ms
SimpleListManipulation: 3ms 4ms 0.00us 0.011ms
SimpleLongArithmetic: 0ms 1ms 0.00us 0.005ms
SmallLists: 3ms 4ms 0.01us 0.007ms
SmallTuples: 0ms 1ms 0.00us 0.007ms
SpecialClassAttribute: 5ms 6ms 0.00us 0.011ms
SpecialInstanceAttribute: 4ms 5ms 0.00us 0.024ms
StringMappings: 574ms 589ms 2.34us 0.022ms
StringPredicates: 6ms 8ms 0.01us 0.143ms
StringSlicing: 0ms 1ms 0.00us 0.016ms
TryExcept: 0ms 0ms 0.00us 0.012ms
TryFinally: 0ms 2ms 0.01us 0.007ms
TryRaiseExcept: 0ms 1ms 0.01us 0.007ms
TupleSlicing: 38ms 38ms 0.15us 0.003ms
WithFinally: 0ms 2ms 0.01us 0.007ms
WithRaiseExcept: 0ms 1ms 0.02us 0.008ms


python3.7

Test minimum average operation overhead
-------------------------------------------------------------------------------
BuiltinFunctionCalls: 47ms 49ms 0.10us 0.098ms
BuiltinMethodLookup: 24ms 25ms 0.02us 0.115ms
CompareFloats: 18ms 18ms 0.01us 0.131ms
CompareFloatsIntegers: 29ms 29ms 0.03us 0.098ms
CompareIntegers: 28ms 28ms 0.02us 0.198ms
CompareInternedStrings: 25ms 25ms 0.02us 0.499ms
CompareLongs: 16ms 16ms 0.02us 0.115ms
CompareStrings: 24ms 24ms 0.02us 0.337ms
ComplexPythonFunctionCalls: 32ms 32ms 0.16us 0.165ms
ConcatStrings: 19ms 21ms 0.04us 0.193ms
CreateInstances: 30ms 31ms 0.27us 0.146ms
CreateNewInstances: 22ms 24ms 0.28us 0.116ms
CreateStringsWithConcat: 44ms 45ms 0.04us 0.325ms
DictCreation: 24ms 24ms 0.06us 0.129ms
DictWithFloatKeys: 33ms 34ms 0.04us 0.252ms
DictWithIntegerKeys: 28ms 29ms 0.02us 0.327ms
DictWithStringKeys: 25ms 25ms 0.02us 0.324ms
ForLoops: 18ms 19ms 0.76us 0.036ms
IfThenElse: 23ms 23ms 0.02us 0.244ms
ListSlicing: 33ms 33ms 2.38us 0.022ms
NestedForLoops: 22ms 22ms 0.01us 0.014ms
NestedListComprehensions: 31ms 32ms 2.63us 0.032ms
NormalClassAttribute: 66ms 67ms 0.06us 0.167ms
NormalInstanceAttribute: 30ms 31ms 0.03us 0.192ms
PythonFunctionCalls: 26ms 26ms 0.08us 0.097ms
PythonMethodCalls: 32ms 33ms 0.15us 0.054ms
Recursion: 50ms 51ms 1.02us 0.168ms
SecondImport: 8ms 8ms 0.08us 0.066ms
SecondPackageImport: 10ms 10ms 0.10us 0.066ms
SecondSubmoduleImport: 21ms 21ms 0.21us 0.066ms
SimpleComplexArithmetic: 22ms 23ms 0.03us 0.134ms
SimpleDictManipulation: 55ms 56ms 0.05us 0.192ms
SimpleFloatArithmetic: 22ms 22ms 0.02us 0.202ms
SimpleIntFloatArithmetic: 24ms 25ms 0.02us 0.204ms
SimpleIntegerArithmetic: 24ms 24ms 0.02us 0.202ms
SimpleListComprehensions: 26ms 27ms 2.26us 0.033ms
SimpleListManipulation: 25ms 26ms 0.02us 0.218ms
SimpleLongArithmetic: 16ms 16ms 0.02us 0.100ms
SmallLists: 28ms 28ms 0.04us 0.133ms
SmallTuples: 30ms 30ms 0.06us 0.151ms
SpecialClassAttribute: 66ms 67ms 0.06us 0.167ms
SpecialInstanceAttribute: 30ms 30ms 0.03us 0.167ms
StringMappings: 53ms 53ms 0.21us 0.140ms
StringPredicates: 23ms 24ms 0.03us 0.495ms
StringSlicing: 30ms 31ms 0.05us 0.274ms
TryExcept: 14ms 14ms 0.01us 0.252ms
TryFinally: 17ms 17ms 0.11us 0.129ms
TryRaiseExcept: 10ms 10ms 0.15us 0.134ms
TupleSlicing: 35ms 36ms 0.14us 0.013ms
WithFinally: 27ms 27ms 0.17us 0.129ms
WithRaiseExcept: 26ms 26ms 0.33us 0.162ms
-------------------------------------------------------------------------------

0
Von Moinsen am Do, 17. Oktober 2019 um 10:14

Dafür gibt es ja die BETA. Bei einem BETA-Produkt erwarte ich als Benutzer das noch Fehler auftreten, auch gravierende. Von einem fertigen Produkt erwarte ich zumindest keine gravierenden mehr. Von einem fertigen Produkt erwarte ich vorallem "Stabilität", und nicht das an allen Ecken und Enden noch herumgeschraubt und verändert wird.

Besseres User Feedback bekommst du ohnehin nur von Beta-Usern, die sich bewußt dafür entscheiden

0
Von Batman am Do, 17. Oktober 2019 um 10:08

Windows 10, denn dies bietet die selben Funktionen wie KDE und darüber hinaus.

Träum weiter Joker! Bei der Funktionalität ist Plasma Windows 10 um Lichtjahre vorraus. Windows 10 ist dagegen eher so spartanisch wie Gnome.

0
Von Fitzefisch am Do, 17. Oktober 2019 um 10:05

Naja, Gnome & Plasma sind mit je 30% ungefähr gleichauf. Wobei noch abzuwarten bleibt, wie sich die Entscheidung so mancher Distribution auswirken wird Plasma nicht mehr zu unterstützen :(

BTW: Ich mußte die letzten Monate mit Gnome arbeiten. Also nicht mal nur kurz ausprobiert. Es mußte Gnome verwendet werden. Mir absolut unverständliche, wie man mit so einem Desktop arbeiten kann. Da macht ja Windows 10 noch mehr Spaß. Ach ja, Plasma mag ich auch nicht xD, aber immer noch 1000x besser als dieses Gnome.

0
Von ehWurst am Do, 17. Oktober 2019 um 09:50

Nicht weitersagen, aber es gibt tatsächlich noch trinitydesktop.org. Ich nütze es auch - auf meinem Pi4.

0
Von Verfluchtnochmal_5987108 am Do, 17. Oktober 2019 um 09:46

Wie stellst du dir das vor?

In der Realität wird dann ein Jahr länger an Dingen rumgebastelt ohne user feedback und kommt genau das gleiche raus, die releasen ja jetzt auch nicht nach dem Motto "Bräuchten zwar noch ein jahr aber lasst und mal stable drauf kleben"

0
Von kraileth am Do, 17. Oktober 2019 um 09:39

Genau diese Befürchtung teile ich auch. Linux-Anwender haben (ich gehörte auch dazu) lange Jahre immer wieder darauf hingewiesen, wie blöd es ist, wenn neue Entwicklungen nur auf bestimmten Systeme unterstützt werden und alle anderen außenvorgelassen werden. Nun ist man Teil von „nur bestimmte Systeme“ und hat sich ganz gut eingerichtet. Dann ist inzwischen teilweise sogar POSIX plötzlich ein Dorn im Auge, da „lästig“, und die anderen Systeme „nutzt eh keiner“. Das war alles mal ganz anders, als man selbst unter „nutzt eh keiner“ fiel. Keine schöne Entwicklung.

0
Von kraileth am Do, 17. Oktober 2019 um 09:31

Moment - ich kritisiere PD ja explizit nicht dafür, daß sie wechseln, bzw. halte unter den Voraussetzungen, die sie machen, den Wechsel für völlig nachvollziehbar. Es kommen aber jetzt natürlich Fragen auf, die undifferenziert fragen, ob denn FreeBSD wirklich untauglich sei. Und das ist meiner Erfahrung nach so pauschal zu verneinen.

1) CUDA: Ich meine, daß es irgendwo vor etlichen Jahren mal jemanden gab, der behauptete, daß auch die FreeBSD-Treiber CUDA unterstützen. Das Problem war, wenn ich mich richtig erinnere, daß nVidia die libcuart nicht unter FreeBSD zur Verfügung stellen will (was der Experimentierfreudige damals mittels der Linux-Bibliotheken und dem Linuxulator zumindest initial gelöst hatte). Aber es stimmt freilich, daß es keine offizielle Unterstützung gibt.

2) Mit Dockingstationen habe ich leider keinerlei Erfahrungen, weder positiv noch negativ. Aber ich weiß, daß manche Leute damit arbeiten. Es muß also zumindest teilweise funktionieren (auch wenn es wohl teilweise Kämpfe damit gab, daß manche Dinge beim Umschalten nicht gut klappten - aber auch das sollte besser geworden sein).

3) USB / Wireless: Was ist bei USB Ihrer Meinung nach das Problem? Späte USB3-Unterstützung? Denn grundsätzlich hat USB schon um die Jahrtausendwende mit 4.X funktioniert. Wireless ist eine andere Baustelle. Da hatte Linux ja auch lange zu knabbern und die Situation ist zugegebenermaßen weiterhin nicht gerade befriedigend.

4) Batterieleistung: Ich will nicht besteiten, daß einigen Leuten jedes bißchen Leistung wichtig ist und das ist auch legitim. Aber ich werde zumehmend das Gefühl nicht mehr los, daß einige Linuxer die Ursprünge vergessen haben (oder vergessen wollen). Denn so lange ist es noch nicht her, daß man, wenn man denn Linux wollte, gravierende Einschränkungen hinzunehmen hatte. Aber wenn man es ernst meinte, dann nahm man die in Kauf. Ganz im Sinne von: Ist nicht für Jedermann und sicher nicht für jeden Zweck. Jeder muß wissen, was er oder sie will.

5) PD tauscht teilweise seinen Nutzerkreis aus. Bisher haben es überwiegend Leute benutzt, die einen FreeBSD-Desktop mit einigen Modernisierungen wollten und Qt, sowie Lumina mochten. Jetzt wird's eine andere Zielgruppe sein - Leute, die Linux nutzen wollen (oder zumindest damit leben können) und statt Systemd Runit bevorzugen, die XBPS mögen oder ähnliches. Man wird sehen müssen, was passiert. Die bisherige Benutzerzahl hielt sich ohnehin in Grenzen (im Telegram-Chat waren nach Projektangaben um die 300 Benutzer angemeldet). Wenn's mehr werden und sich dazu ein paar weitere Entwickler finden, ergibt sich aus Projektsicht ein Nettogewinn. Wenn es hinterher noch weniger Leute anspricht, dann war's die falsche Entscheidung.

0
Von Antiquities am Do, 17. Oktober 2019 um 09:04

Nach 40 Jahren nun der Offenbarungseid für BSD. Sicher als tumbes Serversystem wird es, gefördert von älteren Verantwortlichen, die in den 80ern auf der Uni mit BSD on VAX gelernt haben, noch eine Weile in Nischen überleben. Das Desktop Experience ist jedoch vorbei. Es kann nur einen geben: LINUX!!!

0
Von pointer am Do, 17. Oktober 2019 um 07:05

Bis zu Plasma 6 in wenigen Jahren. Dann fängt das trauerspiel wieder bei null an...

Noch eins: Ich glaube, dass KDE neue Versionen immer *viel zu früh* auf die User loslässt. Solche unausgereiften Arbeiten schaden dann mehr als sie nutzen. Meine Empfehlung wäre: Lieber noch ein Jahr dranhängen und fünf Betas ausgeben als überhastet eine wackelige NEU.0.

0
Von was ist das am Do, 17. Oktober 2019 um 05:39

Wenn ich das richtig verstanden habe ist die Entwicklung unter FreeBSD restriktiv und langsam und mehr Server orientiert. Linux hatte hier den Vorteil, lockerer zu sein und alles zu implementieren, auch wenn es nicht fertig war. Ist für gewisse Leute natürlich spannender. Darum ist Linux auch bekannter geworden, obwohl BSD eigentlich älter ist und zuerst da war.

0
Von Verfluchtnochmal_5987108 am Do, 17. Oktober 2019 um 01:04

Wenn man so gar keine Ahnung wie du hat weiss man natürlich nicht dass die Datenmenge sekundär ist denn der hauptsächliche overhead bei https liegt im Handshake während dir aes-ni zwischen 2500 und 3000 MB pro Sekunde verschlüsselt (Megabyte, nicht Mbit)

Es ist nicht komplizierter, der cluster zeichnet ein Liniendiagramm mit der durchschnittlichen CPU last aller VM's auf allen nodes in MHz

Und nein, es ist nicht sehr wahrscheinlich dass genau am selben Tag wo man alles auf https umstellt nach 5 Jahren die Zugriffe auf alle Kundeseiten zufällig gewaltig einbrechen und den von dir behaupteten Anstieg der Last durch die Verschlüsselung zufällig verstecken

Natürlich wird es ein paar Rechenzyklen brauchen aber nicht signifikant sonst hätten wir 2018 nach Spectre/Meltdown und 2 Monate nach Umstellung auf https nicht bei der neuen Hardware nichtsschlicht und ergreifend die CPUs halbiert weil nach PHP7 zweijJahre zuvor die Hardware nur Däumchen gedreht hat

Wenn du dämlich recht hättest wäre der neue Cluster physisch gleich stark geblieben und wir hätten uns darüber gefreut dass die Optimierungen der letzten beiden Jahre Ressourcen für https frei geschaufelt haben, war aber nicht der Fall und ja der Austausch war seit 2015 geplant

0
Von Verfluchtnochmal_5987108 am Do, 17. Oktober 2019 um 00:47

Was genau hast du am deutschen Wort "hauptsächlich" nicht verstanden und was hat das mit der Lizenz, speziell der von gtk zu tun um welches im Artikel so gar nicht geht?


 
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten