Hi,
also mal ganz abnehmerfreundlich:
zu 1.) Postings verschwinden, weil nicht persistiert rechtzeitig wird
---
Na, dann hast du doch gehoert, was los ist. Ich schreibe es dir gern auch noch ein weiteres
mal: die Interaktion mit dem Dateisystem verlangsamt einen Prozess um mindestens den Faktor
hundert. Das war zumindest auf Heimdall nicht akzeptabel.
Der Datenverlust wird begruendet mit der nicht hinreichend verfuegbaren CPU-Zeit, die ein regelmaessigeres Sichern (sagen wir mal nur des Threadbestands) als einmal alle 300 Sekunden zulaesst.
Das ist auch das einzig zulaessige Gegenargument.
Allerdings traue ich diesem nicht, da waeren Messungen bzgl. der CPU- und Plattenauslastung erforderlich. Sollten diese Daten tatsaechlich darauf hinweisen, dass Deine Aussage stimmt, also das die Systemauslastung so hoch ist, das nicht ausreichend regelmaessig der Datenbestand persistiert werden kann, was ich erst nach eingehenden Messungen und deren Analyse bestaetigen wuerde, dann, ja dann ist das System (Heimdall) unterdimensioniert, also untauglich.
Es gab in der Vergangenheit gewisse Hardware-Probleme mit Heimdall nach meiner Kenntnis, zudem soll das System statt mit vorgesehenen zwei CPU nur mit einer gefahren worden sein. Die Entwickler waeren also in diesem Punkt moeglicherweise, sollten also weitere diesen Sachstand belegende Fakten angefuehrt werden koennen, scheinbar bzw. anscheinend entlastet.
Nichtsdestotrotz sollte ein Softwaresystem nicht bestimmte erforderliche (zumindest duerfte das allgemein so gesehen werden)Leistungen nicht erbringen, weil die Hardware auf der es laeuft, ohnehin diese Leistung nicht erbringen kann. Also: eher nicht auf die Hardware schauen, wenn etwas entwickelt wird, sondern das ganze Potential der Unternehmung incl. Investitionsmoeglichkeiten im Auge haben, auch weit in die Zukunft hinein denken. (Das Potential dieser Unternehmung scheint mir recht gross zu sein, was auch durch das Spendenvolumen belegt ist.)
Inzwischen kann man darueber nachdenken, ob man Postings direkt bei ihrem Eintreffen
schonmal in einer Art Failsafe-Datei speichern will, und in der Tat existiert bereits
schon ein entsprechendes Modul.
OK.
2.) kein RDBMS am Start
---
[Ausfuehrungen von henryk Ploetz, das kein RDBMS am Start, weil keine Entitaeten(!) gegeben (erkennbar) sind)]
Richtig. Und siehst du welche? Ein RDBMS fuer hierarchisch angeordnete Daten zu nehmen
ist, gelinde gesagt, eine Vergewaltigung des Systems. [...] Also gibt es auch keinerlei Vorteile,
hoechstens Nachteile, die ein RDBMS bieten wuerde. »Use the right tool for the right job.«
Also, wir wollen ja keine Systeme vergewaltigen, sondern skalierbare, wartungsfreundliche und weiterentwicklungsfaehige erschaffen.
Das angefuehrte Gegenargument ist wieder fast das einzig richtige. Ein weiteres, was haette genannt werden koennen, ist die geringe Komplexitaet des Systems. Dieses Argument ist dankenswerterweise nicht genannt worden. Ein drittes wieder mal: die inperformante Hardware.
Warum kommt bei einem einfachen System (mit vielleicht nur einer Entitaet) kein RDBMS an den Start? - Weil man mit einem RDBMS Relationen hegt und pflegt, ganz einfach. Liegen aber Relationen vor, ist das System komplex, dann wird man nach meiner Erfahrung mit "flacher" Datenhaltung nicht mehr so recht gluecklich.
Zum Argument, dass hier keine Entitaeten gegeben sind, das System also nicht komplex ist, moechte ich aus Gruenden der Freundlichkeit nicht mehr viel sagen, ausser, ja ausser, dass <Inhalt bitte selbst abstrahieren>.
Zu den Performaceueberlegungen, die die Systemarchitektur beeinflussen, bitte ich meine Ausfuehrungen aus Kapitel 1 in dieses Kapitel hineinzulesen, soz. dem Copy-Konzept entsprechend.
- spaeter las man noch sowas https://forum.selfhtml.org/?t=89740&m=539895
Und was willst du mir jetzt damit sagen?
Das Henryk Ploetz zumindest Humor hat.
Ferner werden immer (wie auch in 1) Performanceueberlegungen genannt. (Fuer mich steht
ueberigens immer die Architektur des Produkts an erster Stelle.)
Tja, gutes Software-Design ist ein Kompromiss aus Performance-Ueberlegungen und
Architektur-Ueberlegungen. Das sagt dir jedes informatische Lehrbuch. Wieder ein Punkt,
wo ich an deinem Sachverstand zweifeln muss.
Ich bin eigentlich sicher, dass wir hier einer Meinung sind. Erst denkt man ans System, dann an die Moeglichkeiten der Umsetzung mithilfe der gegebenen Infrastruktut.
3.) C++-Anwendung am Start mit unbehandelten Ausnahmen
---
Es lag eine C-Anwendung mit unbehandelten Ausnahmen vor. Ich hoffe, das ist nun richtig?!
4.) hohe Unverfuegbarkeit (ca. 3% p.a. ?)
---
Selbst wenn es so waere -- was ich bezweifeln moechte, zumindest aus technischen
Gruenden -- sind wir zu keinerlei Verfuegbarkeit verpflichtet.
Der Nihilismus des Entwicklers. Kenne ich. Dummerweise sind wir Entwickler in der Regel an Geschaeftsmodelle gebunden, die wiederum von bestimmten Leuten, sog. Managern oder allg. gefasst Abnehmern gepflegt werden. Denen musst Du dann nur noch erklaeren, dass unten oben ist.
Nuechtern beobachtend duerfte allerdings bereits jeder ernsthafte Forumsteilnehmer, sagen wir mal Wiederholungstaeter, hier eine deutliche Unverfuegbarkeitsquote festgestellt haben. Und das findet der Abnehmer in aller Regel nicht gut. Vergl. auch meine Ausfuehrungen zum zweiten Abnehmerkreis.
In den letzten Jahren gab es regelmaessig Unverfuegbarkeiten. Warum?
Aufgrund von Programmier-Fehlern in der Software.
Ich habe jetzt eigentlich keine Lust zu widersprechen, aber waren es wirklich nur "Programmierfehler"?
5.) "Unklarheiten" bei Registrierung und Anmeldung => soz.Folge: Mobbing
---
Da ist nichts unklar. Und das »Mobbing«, wie du es nennst, hat sich der entsprechende
Poster aufgrund seines Verhaltens selber zuzuschreiben.
Soz. verdientes Mobbing?
Das mit dem "Namenschuetzen" fuehrt dazu, dass sich ein Nutzer, der immer mit demselben
Namen posten moechte, registrieren _muss_.Selbstverstaendlich nicht.
Jeder Nutzer, der mit einem bestimmten Namen posten moechte und die zukuenftige Verfuegbarkeit dieses Namens sicherstellen moechte, muss den genannten Namen "schuetzen". Das geschieht ueber die Registrierungseinstellungen. Dann kann sein Forumsverhalten hier zumindest theoretisch gespeichert und analysiert werden.
Nur, indem man entweder eine Zwangsregistrierung oder das Schuetzen der Namen weglaesst.
Beides nicht tragbar. Denn _ich_ will nicht wieder gefaked werden (suche im Archiv, um
diesen Hinweis zu verstehen. Duerfte so um 2000 rum gewesen sein).
Nun, es ist zumindest eine Loesung denkbar, wo durch eine zweite Information sichergestellt ist, dass Du ein registrierter Nutzer bist, der Logik folgend "Christian Kruse + registriert"=="Christian Kruse".
6.) kein automatisches Restarten des Daemons, wenn abgestuerzt
---
Ganz im Gegenteil. Es hat einen Grund, warum der Forums-Daemon abstuerzt. Und bevor der
nicht geklaert ist, ist es gefaehrlich, das Forum einfach so neu zu starten. Mal abgesehen
davon, dass durchaus Sachen in einem undefinierten Zustand sein koennen, wenn der
Forums-Daemon abstuerzt. Ein automatischer Restart waere gefaehrlich und unverantwortlich.
Wir konfigurieren unsere Dieste in der Regel so, dass wenn sie abgeigen, sie wiedergestartet werden, und zwar automatisch. Deine Argumentation ist allerdings, je nach Anforderungslage, schluessig, mit einem bestimmten Schluessigkeitsgrad.
7.) kein offenes Diskussionsverhalten der Verantwortlichen bei erkannten und bekannten Maengeln
---
Das aendert sich ja gerade.
OK.
8.) Chef-Admin i.p. sozialer Kompetenz stark gefordert, d.h. dieser veroeffentlicht auch Forumsinterna, die auf internen Informationen basieren
---
Auch fast nur ein OK, allerdings weise ich Dich und andere Devs noch einmal explizit auf Eure gesteigerte persoenliche Verantwortung hin.
9.) Daemon nicht mandantenfaehig, stattdessen mehrere Daemons am Werk (4 Foren, also 4 Daemons ;-)
---
Falsch. Das ist kein Mangel. Das ist Absicht so.
Es ist ganz einfach. Wenn die Jobs, die von den permanent laufenden Programmen zu bearbeiten sind, sich zu einem grossen Teil gleichen, dann benoetigt man mandantenfaehige Logik. Aus allerverschiedensten Gruenden.
Wie Henryk und auch ich schon bereits
schrieben, ist die Komplexitaet, die die Einfuerung der »Mandantenfaehigkeit«, wie du
es nennst, mit sich bringen wuerde, unverantwortlich. Ich ueberlasse die schwierigen
Aufgaben lieber dem Betriebssystem, das kann das viel besser als ich.
Du meinst der Aufwand ist zurzeit zumindest nicht zu leisten?
[...] der zu Coderedundanzen fuehrt.
Du hast trotz mehrfacher Nachfrage nicht gesagt, warum das zu »Code-Redundanzen« fuehren
sollte. Das ist totaler Humbug, wieder ein Punkt, an dem ich deinen Sachverstand in Frage
stellen muss.
Also, wenn ein und dieselbe Aufgabe von verscheidenen Routinen erledigt werden muss, dann haben wir Code-Redundanz, oder?
Aber vielleicht meinst Du etwas, das sich mir nicht sofort, soz. exoterisch, erschliesst. Dann bitte ich Dich um Erlaeuterung.
10.) allg. uncooles Kommunikationsverhalten der Devs
---
Ok, ist schon cooler geworden, aber bitte nicht mehr so viele Schimpfwoerter, mit 'a' und so. Und mach Dich mal locker, es soll doch eine sachliche Diskussion mit Gewinnern auf allen Seiten werden. So zu sagen, ein "n-faches" Aufgrunzen.
Gruss,
Ludger
"Machts der Gerd nicht, machts der Franz."