Warum schlägst Du genau dieses Vorgehen vor?Ich würde erstmal auf die neuste Asterisk 16 LTS gehen. Dann ein wenig spielen und ausprobieren. Und dann auf Asterisk 18 LTS.
Warum nicht direkt auf das 18er Branch?
LG
Warum schlägst Du genau dieses Vorgehen vor?Ich würde erstmal auf die neuste Asterisk 16 LTS gehen. Dann ein wenig spielen und ausprobieren. Und dann auf Asterisk 18 LTS.
Ich hatte mir diesen Satz mehrfach durchgelesen und war mir nicht sicher, wie ich ihn verstehen sollte. Das erste Verständnis war so, wie Du es jetzt beschrieben hast - das hielt ich aber für absurd. Daher bin ich nach dem Motto "think positive" vorgegangen - aber es zeigt halt auch mal wieder: schlimmer geht immer - was meine obigen folgenden Ausführungen ja noch mehr bestätigt.Probiere meinen Post einfach nochmal zu lesen: Alle Branches, die noch aktiv sind, erhalten Security-Fixes. Aber die Debian-basierten Linux erhalten in „ihrem“ Repository einmal eine Version und diese erhält (aktuell) dann keine Security-Updates mehr, weil Asterisk dort nicht im entsprechenden Repository-Bereich ist.
Natürlich. Allerdings darf sich jeder bzw. jede Firma ihre Nutzer selbst aussuchen. Das Ergebnis muss nicht zwangsweise zu meinem Vorteil sein. Ich bezahle ja die Entwickler nicht.Ja, das ist eine Einschätzung von Dir, ein „Excuse“ für die Machenschaften bei Sagoma. Eine Plattform lebt auch von Nutzern.
Woher weißt Du das? Scheinbar können Sie mit dem Status Quo leben - sonst würden sie ja kaum so fahren. Wie gesagt, mit "nicht Kunden" wie ich (und vielleicht Du und viele andere Hobiisten) läßt sich keine Firma finanzieren.Und das ist die Crux bei Digium zum Schluss gewesen, dass bei jedem neuen Branch ganz viele Nutzer (Privat aber besonders auch Professionell) verloren gehen.
Ja, so ist das. Hast Du aber beim Linux-Kernel genauso. Da fahre ich z.B. auch nur die LTS-Kernel (falls ich vom Distri-Kernel aus welchen Gründen auch immer abweichen muss). Auch da kann man sehen, wieviele Patche da jede Woche reinkommen in die noch etwas aktuelleren LTS-Kernel.Diese Verlorenengegangen testen dann die nicht-LTS-Branches nicht vor, in einem Testbed. Und dann können auch deren neuen Features nur mit wahnsinnig viel Aufwand im Master-Branch zusammengebracht werden.
Du hast ja auch da durchaus Recht - aber musst Du das? Nein - musst Du nicht. Ich mache meine Patches mittlerweile nur noch für mich, meine Version, die ich einsetze und für Interessierte. Da die Jungs an "meinem" use case kaum / kein Interesse haben, mache ich in der Richtung eben nichts. Ob ich das gut oder schlecht finde, hilft am Ende des Tages nicht weiter und ist irrelevant - ist halt so. Ich kann damit aber wunderbar leben und freue mich, dass ich eine trotz allem ziemlich hochwertige Telefoniesoftware inkl. Frontend bekomme zum Nulltarif, die ich auf meine eigenen Anforderungen / Bedüfrnisse anpassen kann und die professionell gewartet wird. Ich bin damit ganz glücklich.Ein anderes Problem sind Nachrenner – zu denen gehöre ich –, die auf einem alten Branch hängen, einen Software-Bug finden, und dann auf allen neueren Branches diesen Bug-Fix einpflegen müssen (inklusive testen). Oder anders formuliert: Ich als Nutzer, Hobbist, muss (auch) alle (anderen) Branches bedienen, um meine Änderungen reinzubekommen. Warum sollte man das nach Deiner Einschätzung überhaupt machen?
Hättest Du FreePBX würde das out of the box vollautomatisch gehen. Da Du aber Deinen eigenen Weg gehst, musst Du eben in den sauren Apfel beißen und selber schauen, wie Du von a nach b kommst. Viel Spaß!OK, Verstanden.. Macht Sinn...
Gibts ne Möglichkeit auf das aktuellste 16er Branch zu update ohne Astersrik vorher zu killen?
Du kannst es drüber installieren. Aber das würde ich nicht machen, weil Du aktuell im Packet-Manager apt mehrere Packages systemweit als „automatisch installiert“ markiert hast. Wenn Du ein Upgrade auf eine neue Debian-Version machst und eines der Packages dann doch im Security landet … Chaos erster Klasse vorprogrammiert.Gibts ne Möglichkeit auf das aktuellste 16er Branch zu update ohne Asterisk vorher zu killen?
Dann fragt mal lieb nach, ob das wirklich sein kann. Das zeigt Neugierde. Dann macht es auch Spaß das zu beantworten.… das hielt ich aber für absurd
Ja, das ist der Denkfehler. Du nimmst an, dass wir absichtlich Abfall sind. Daran glaube ich nicht. Digium und Sangoma scheinen es nicht besser zu können, wollen es aber eigentlich, so wie ich die Herrschaften verstehe.selbst aussuchen
Witzigerweise doch. Denn wir querfinanzieren durch unsere Mitarbeit den Maintainer.mit "nicht Kunden" wie ich (und vielleicht Du und viele andere Hobbyisten) läßt sich keine Firma finanzieren
Geh auf die AstriCon und sprich mit (Top-) Contributern. Wenn die Dir so nebenbei erzählen, dass die nicht einmal auf einem aktiven Branch sind, dann läuten bei mir die Alarmglocken.Woher weißt Du das?
Wenn ich einen Bug-Fix contribute, dann muss ich alle aktiven Branches bedienen. Gleichzeitig. Ich kann nicht einmal erst Master contributen, reviewen lassen und dann nach Lust und Laune back-porten. Wenn ich ein neues Feature contribute, dann muss es kompatibel mit Master sein. Der Maintainer bei diesem Projekt hievt es nicht automatisch auf die andere Branches um. Das macht Contributen sehr schwer, weil ich dann alle Braches testen und (deren Architektur-Änderungen) nachvollziehen muss. Selbst ein Profi hat niemals mehr als zwei Versionen in seinem Test-Bett (LTS → LTS oder vorheriger Branch → aktueller Branch).… aber musst Du das?
Du hast Dich auf die nicht-funktionale Anforderung spezialisiert, verschlüsselt mit einem Tarif der Telekom Deutschland telefonieren zu können. Vieles was Du heute benutzt, entstammt von anderen Contributern, die sich die Mühe gemacht haben. Es ist fraglich, ob Digium überhaupt je einen bezahlten Kunden hatte, der SIP-over-TLS mit SDES-sRTP benutzt bzw. bezahlt hat. Das sind jetzt wieder zwei Technologien, die in funktionale Anforderungen gegossen wurden. Ja. Aber die entstammen einer nicht-funktionalen Anforderung, nämlich vertraulich zu telefonieren. Genau dieser Umgang mit nicht-funktionalen Anforderungen ist ein Baustein im Erfolg eines (Open-Source) Software-Projekts. Besonders bei einem Software-Produkt mit hoher Interoperabilität wie VoIP/SIP, ist nicht nur White-Box-Testing, Black-Box-Testing sondern auch Feld-Testing wichtig. Ich als Hobbyist kann nicht einmal alle meine Use-Cases durchtesten. Wieder ein Beispiel für nicht-funktionale Anforderungen, Interoperabilität. Ein konkretes Beispiel für nicht-funktionale Anforderungen ist auch der Unterschied im Installer zwischen Debian und Ubuntu.nur noch für mich
Habe nochmal rumgeschaut und fand immer noch keine keine Ziel-Definition, warum Asterisk so viele Branches fährt. Entsprechend kann man auch nicht überprüfen, ob Digium bzw. Sangoma seine Ziele damit immer noch erreicht. Das Beste was ich fand, war ein Blog-Eintrag von Leif Madson, einem der Mitautoren des Asterisk-Buchs (ein echter Tipp für Dich, Tiieto, weil Du aktuell noch auf Asterisk 16 LTS bist).Warum kursieren überhaupt so viele unterschiedliche Versionen?
Jupp, als unerfahrener Asterisk´er der es gerade mal hinbekommen hat das das System mit den Minimalanforderungen läuft, ist das eigentlich ja auch ne berechtigte Frage...Tiieto, Du fragst eigentlich, welche Version Du nutzen solltest.
Hat niemand bezweifelt, dass die Frage berechtigt ist. Nur leider gibt es keine wirkliche Antwort, egal wie tief Du drin steckst. Als weiteren Einwurf: Gab mal RasPBX. Keine Ahnung, ob das noch aktiv ist. Aber man auf jeden Fall davon Lernen.eigentlich ja auch ne berechtigte Frage
Mein Tipp: Starte Deine ersten Gehversuche auf einem Desktop-System z.B. in einer Virtualisierung. So musst Du nicht ewig warten, wenn Du etwas baust bzw. änderst.als unerfahrener Asterisk´er der es gerade mal hinbekommen hat das das System mit den Minimalanforderungen läuft