Abo
  1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › Open Source: Xscreensaver…

Solche Diskussionen hätte man schon vor 15 Jahren ....

  1. Thema

Neues Thema Ansicht wechseln


  1. Solche Diskussionen hätte man schon vor 15 Jahren ....

    Autor: nille02 06.04.16 - 15:30

    ... führen müssen.

    Seit langem nutze ich nun schon eine Rolling-Release Distribution und hatte damit bisher auch keinerlei Probleme.

    Das was Debian und einige andere Distributionen machen, ist meist nur hinderlich.
    Der Upstream ist genervt von alten Bugreports (auch da Distributionen gerne an den Upstream verweisen).
    Die User sind genervt von alten Versionen die Teils Funktionen vermissen lassen.
    Die Distributoren sind genervt über das mehr an Arbeit.

  2. Re: Solche Diskussionen hätte man schon vor 15 Jahren ....

    Autor: laserbeamer 06.04.16 - 15:34

    Kommt auf den Anwendungszweck an auf meinem Server will ich nicht immer neue Versionen sondern nur Sicherheitsupdates.
    Da reicht mir mein SLES 12, auf dem desktop mag das anders aussehen.

  3. Re: Solche Diskussionen hätte man schon vor 15 Jahren ....

    Autor: Seitan-Sushi-Fan 06.04.16 - 15:41

    nille02 schrieb:
    ----------------

    > Das was Debian und einige andere Distributionen machen, ist meist nur
    > hinderlich.

    Also Fedora liefert ja auch einfach neue Software-Versionen in Paketen aus, sofern sie die Kompatibilität nicht brechen.
    Es geht also auch ohne Rolling Release. Man muss nur wollen und halt ein QA-Team dran setzen, die die Kompatibilität testen.
    In einem sog. Leaf Package sehe ich keinen triftigen Grund gegen ein schlichtes Update auf die neue Version.

  4. Re: Solche Diskussionen hätte man schon vor 15 Jahren ....

    Autor: nille02 06.04.16 - 15:41

    laserbeamer schrieb:
    --------------------------------------------------------------------------------
    > Kommt auf den Anwendungszweck an auf meinem Server will ich nicht immer
    > neue Versionen sondern nur Sicherheitsupdates.

    Aber warum? Doch nur aus der Erfahrung hinaus das in neuen Versionen oft etwas anders ist und man sich erst mal einarbeiten und testen muss.

    Entsprechende Projekte pflegen ja schon oft mehrere Versionen, siehe Kernel oder PHP.

    Aber wenn ein Projekt nun mal nur eine Version pflegt, ist es eher kontraproduktiv daran noch herumzubasteln nur um nicht upgraden zu müssen.

  5. Re: Solche Diskussionen hätte man schon vor 15 Jahren ....

    Autor: nille02 06.04.16 - 15:42

    Seitan-Sushi-Fan schrieb:
    --------------------------------------------------------------------------------
    > Also Fedora liefert ja auch einfach neue Software-Versionen in Paketen aus,
    > sofern sie die Kompatibilität nicht brechen.

    Eben, wobei ich Fedora bisher selten genutzt habe, da ich mir zu viel Software von dritten besorgen musste.

    > Es geht also auch ohne Rolling Release. Man muss nur wollen und halt ein
    > QA-Team dran setzen, die die Kompatibilität testen.

    damit könnten sich Distributoren Beschäftigen und nicht an alten Paketen herumzupatchen.

  6. Re: Solche Diskussionen hätte man schon vor 15 Jahren ....

    Autor: heubergen 06.04.16 - 16:52

    nille02 schrieb:
    --------------------------------------------------------------------------------
    > Aber warum? Doch nur aus der Erfahrung hinaus das in neuen Versionen oft
    > etwas anders ist und man sich erst mal einarbeiten und testen muss.
    Willst du jetzt ernsthaft vorschlagen dass Server mit aktuellen OS arbeiten sollten? Warst du jemals Server-Admin eines wichtigen Servers?

  7. Re: Solche Diskussionen hätte man schon vor 15 Jahren ....

    Autor: Proctrap 06.04.16 - 17:58

    Um mal ein bisschen mehr Wind aus den Segeln zu nehmen, den heubergen gerade hinein gelegt hat:
    Ich muss Systeme die 24/7 laufen sollen, und das kann ein x-beliebiger Server sein, natürlich mit Sicherheitsupdates versorgen.
    Allerdings sind solche Maschinen in der Regel optimierte, auf ihr Aufgabenfeld zusammengestellte Systeme. Das heißt: Ich verwende eine Kette von Software auf diesen Systemen, welche genau so funktioniert. Meist weil genau auf dem Ist-Zustand erzeugt. Ich programmiere Software immer auf Basis dessen, was ich habe, nicht dessen was vielleicht sein könnte.

    Natürlich muss ich irgendwann auch unter Debian ein System-Upgrade durchführen. Dies ist allerdings planbar, ich weiß: Alle X Jahre muss ich mal mein System komplett upgraden. Meine Firma muss Updates liefern etc.

    Aber ich muss nicht mit jedem Sicherheitsupdate damit rechnen, dass es mir mein System zerschießt, weil i-ein Feature plötzlich für einen Bruch in meinem System sorgt.
    Beispiel: Ich habe ein Programm das auf dem Kommando "pdftohtml" basiert und den Output parst.
    Pdftohtml hat einen Bufferoverflow und benötigt ein update. Durchgeführt, das Tool hat aber auch ein Feature-Update und schon kann ich mit dem Output nichts mehr anfangen, das komplette System, was bisher als ein Teilglied diese Lib verwendet hat, bricht auseinander.
    Dieses Beispiel ist der Realität entlehnt, nur handelte es sich hierbei um einen Fehler, der mit dem Distri-Upgrade und damit erwartbar aufgetreten ist.

    Würde Microsoft auf Windows mit jedem Sicherheitspatch auch gleich mal seinen aktuellen Entwicklungsstand von z.b. .NET bei dir installieren, würden 90% deiner Programme jeden Monat mal den Geist aufgeben, bis jemand eine neue Version auf aktueller Basis von .NET / der C++ Runtime von MS heraus bringt.

    Kurz: Für vieles brauchst du sich nicht ändernde Systeme oder Bestandteil = Zeitweise Standards.

  8. Re: Solche Diskussionen hätte man schon vor 15 Jahren ....

    Autor: xUser 06.04.16 - 19:14

    laserbeamer schrieb:
    --------------------------------------------------------------------------------
    > Kommt auf den Anwendungszweck an auf meinem Server will ich nicht immer
    > neue Versionen sondern nur Sicherheitsupdates.
    > Da reicht mir mein SLES 12, auf dem desktop mag das anders aussehen.

    Genau dieses Verhalten für mittel- bis langfristig in die Katastrophe. Entweder der Server wird gehackt (veraltete Software, wo Sicherheitsfeatures nicht nachgezogen wurden) oder es kommt zu einem dicken Datenverlust, weil Fehler nicht behoben wurden und die Signifikanz der Fehler vom Maintainer nicht erkannt wurde.

    Wenn ein System wichtig ist, dann muss man halt ein QA-Umgebung daneben stellen und regelmäßig die Updates vorher testen. Keine QA-Umgebung, kein wichtiges System!

    Außerdem ist es zielführender und kostensparender, wenn man regelmäßig kleinere Updates macht und die dabei auftretenden Probleme behebt, als wenn man alle x Jahre ein großes Update macht, wo an allen Enden etwas kaputt geht. Dann wird entweder das Update aufgespart oder es werden allen möglichen Stellen Legacy-Layers benutzt, wodurch sich die Fehlerwahrscheinlichkeit weiter erhöht. Letztlich ist dies eine Abwärtsspirale, welche bei regelmäßigen Updates gar nicht erst auftreten würde.

  9. Re: Solche Diskussionen hätte man schon vor 15 Jahren ....

    Autor: felix.schwarz 06.04.16 - 19:50

    xUser schrieb:
    > Außerdem ist es zielführender und kostensparender, wenn man regelmäßig
    > kleinere Updates macht und die dabei auftretenden Probleme behebt, als wenn
    > man alle x Jahre ein großes Update macht, wo an allen Enden etwas kaputt
    > geht.

    Der Kernpunkt für jeden Admin ist die Planbarkeit. Das Anpassen an geänderte Konfigurationen u.ä. ist weniger ein Problem (wenn ich genau eine Distribution unterstütze), wenn man sich denn das Zeitfenster innerhalb von 3-4 Monaten frei wählen kann. Das geht mit den klassischen Distro-Upgrades ohne Stress. Wenn aber jederzeit ein Update etwas ändern kann, werden selbst die vielen kleinen Änderungen ein Problem.

    Ein zusätzliches In-House-Testingsystem erhöht auch nur den Zeitraum bis Updates eingespielt werden, weil Testen auch Zeit benötigt (und kostet). Wenn jeden Tag Updates kommen, ist man schon bei wenigen System nur noch damit beschäftigt.

    Die Alternativstrategie ist, dem Distributor bei Sicherheitsupdates praktisch blind zu vertrauen und die sofort einzuspielen. Größere Feature-Updates ("Service-Packs") werden halt entsprechend vorher getestet.
    (Wenn man natürlich google.com betreibt, wird man auch jedes Sicherheitsupdate genau unter die Lupe nehmen.).

  10. Re: Solche Diskussionen hätte man schon vor 15 Jahren ....

    Autor: felix.schwarz 07.04.16 - 00:09

    felix.schwarz schrieb:
    > (Wenn man natürlich google.com betreibt, wird man auch jedes
    > Sicherheitsupdate genau unter die Lupe nehmen.).

    Meine Antwort war aus Zeitgründen etwas knapp: Für google.com würde man auch die Updates einfach auf 0,1% der Maschinen ausrollen und das Monitoring (Performance, Fehlerrate usw.) messen lassen, ob das Update gut ist. Dann Ausrollen auf 1% der Maschinen, 10%, ...

    tldr: Jedes Update "downstream" (also "in der Firma") komplett durchzutesten, macht kaum keiner, weil es sehr (zu) teuer ist.

  11. Re: Solche Diskussionen hätte man schon vor 15 Jahren ....

    Autor: Wallbreaker 07.04.16 - 14:18

    heubergen schrieb:
    --------------------------------------------------------------------------------
    > Willst du jetzt ernsthaft vorschlagen dass Server mit aktuellen OS arbeiten
    > sollten? Warst du jemals Server-Admin eines wichtigen Servers?

    Ich bin seit etlichen Jahren für hunderte von Servern zuständig. Und die sind alle immer auf dem neuesten Softwarestand. Die eigene Software im Hause wird auch nachhaltig entwickelt, sodass Probleme mit Updates außerordentlich selten auftreten. Aus eigener Sicht ist das nicht nachvollziehbar was Andere hier tun. Das mutet grundsätzlich an als würde dort mangelhafte Softwareentwicklung stattfinden, anstatt die Software modular/dynamisch aufzubauen, und nicht strikt an irgendwelche Softwareversionen zu münzen. Ebenso lassen sich unter Linux viel Funktionen einfach über Scripte realisieren, selbst hochkomplexe Vorgänge. Dazu bedarf es weder zusätzlicher Binarys noch neuen Programmen. Vieles lässt sich völlig einheitlich und unabhängig vieler Software coden, dass Updates nahezu egal werden und nur ein neuer heftig veränderter Kernel dies ändern könnte.



    2 mal bearbeitet, zuletzt am 07.04.16 14:26 durch Wallbreaker.

  12. Re: Solche Diskussionen hätte man schon vor 15 Jahren ....

    Autor: 1ras 09.04.16 - 02:44

    Wallbreaker schrieb:
    --------------------------------------------------------------------------------
    > heubergen schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Willst du jetzt ernsthaft vorschlagen dass Server mit aktuellen OS
    > arbeiten
    > > sollten? Warst du jemals Server-Admin eines wichtigen Servers?
    >
    > Ich bin seit etlichen Jahren für hunderte von Servern zuständig. Und die
    > sind alle immer auf dem neuesten Softwarestand. Die eigene Software im
    > Hause wird auch nachhaltig entwickelt, sodass Probleme mit Updates
    > außerordentlich selten auftreten. Aus eigener Sicht ist das nicht
    > nachvollziehbar was Andere hier tun. Das mutet grundsätzlich an als würde
    > dort mangelhafte Softwareentwicklung stattfinden, anstatt die Software
    > modular/dynamisch aufzubauen, und nicht strikt an irgendwelche
    > Softwareversionen zu münzen. Ebenso lassen sich unter Linux viel Funktionen
    > einfach über Scripte realisieren, selbst hochkomplexe Vorgänge. Dazu bedarf
    > es weder zusätzlicher Binarys noch neuen Programmen. Vieles lässt sich
    > völlig einheitlich und unabhängig vieler Software coden, dass Updates
    > nahezu egal werden und nur ein neuer heftig veränderter Kernel dies ändern
    > könnte.

    Deine Story kaufe ich dir nicht ab. Denn dann wäre dir bekannt, dass es beim Zusammenspiel unterschiedlicher Software immer wieder zu Inkompatibilitäten kommt, welche es im Produktivbetrieb strikt zu vermeiden gilt. Es gilt deshalb die Maxime, Sicherheitsupdates von regulären Updates zu trennen.

    Sicherheitsupdates sind bevorzugt zu behandeln um diese möglichst schnell einspielen zu können. Da sich durch Sicherheitsupdates regelmäßig nur kleine Codeteile ändern, sind diese gezielt und deshalb beschleunigt prüfbar.

    Reguläre Updates sind hingegen vollumfänglich zu testen, da sich an jeder erdenklichen Stelle eine Inkompatibilität eingeschlichen haben kann. Dies ist entsprechend zeitintensiv.

    Ein Rolling Release in welcher keine Trennung nach Sicherheitsupdates und regulären Updates erfolgt, ist hierfür denkbar ungeeignet. Es sei denn man hat zu viel Zeit, testet nur unzureichend oder gar nicht.

  13. Re: Solche Diskussionen hätte man schon vor 15 Jahren ....

    Autor: xUser 09.04.16 - 11:58

    1ras schrieb:
    --------------------------------------------------------------------------------
    > Ein Rolling Release in welcher keine Trennung nach Sicherheitsupdates und
    > regulären Updates erfolgt, ist hierfür denkbar ungeeignet. Es sei denn man
    > hat zu viel Zeit, testet nur unzureichend oder gar nicht.

    Oder man reserviert ein Budget für Ausfälle und zieht dies am Ende des Jahres heran um die Boni auszuzahlen.
    Dafür braucht man natürlich eine vernünftiges Monitoring und eine Continuous-Integration Platform, wo auch funktionale Tests automatisch ablaufen.
    Wer im 90-Jahre Stil alles per Hand testet, wird natürlich nie auf einen grünen Zweig kommen.
    Und wenn Systeme nicht 24/7 laufen müssen, dann verschiebt man ein Update einfach in ein Zeitfenster wo es nicht weh tut.

  14. Re: Solche Diskussionen hätte man schon vor 15 Jahren ....

    Autor: 1ras 09.04.16 - 19:05

    xUser schrieb:
    --------------------------------------------------------------------------------
    > 1ras schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Ein Rolling Release in welcher keine Trennung nach Sicherheitsupdates
    > und
    > > regulären Updates erfolgt, ist hierfür denkbar ungeeignet. Es sei denn
    > man
    > > hat zu viel Zeit, testet nur unzureichend oder gar nicht.
    >
    > Oder man reserviert ein Budget für Ausfälle und zieht dies am Ende des
    > Jahres heran um die Boni auszuzahlen.
    > Dafür braucht man natürlich eine vernünftiges Monitoring und eine
    > Continuous-Integration Platform, wo auch funktionale Tests automatisch
    > ablaufen.
    > Wer im 90-Jahre Stil alles per Hand testet, wird natürlich nie auf einen
    > grünen Zweig kommen.

    Da du die Software in der Regel nicht selbst entwickelst, bringen dir deine Entwicklungsansätze herzlich wenig, da du darauf regelmäßig keinen Einfluss hast.

  15. Re: Solche Diskussionen hätte man schon vor 15 Jahren ....

    Autor: rocket_to_russia 17.04.16 - 06:57

    Wallbreaker schrieb:
    --------------------------------------------------------------------------------
    > heubergen schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Willst du jetzt ernsthaft vorschlagen dass Server mit aktuellen OS
    > arbeiten
    > > sollten? Warst du jemals Server-Admin eines wichtigen Servers?
    >
    > Ich bin seit etlichen Jahren für hunderte von Servern zuständig. Und die
    > sind alle immer auf dem neuesten Softwarestand. Die eigene Software im
    > Hause wird auch nachhaltig entwickelt, sodass Probleme mit Updates
    > außerordentlich selten auftreten. Aus eigener Sicht ist das nicht
    > nachvollziehbar was Andere hier tun. Das mutet grundsätzlich an als würde
    > dort mangelhafte Softwareentwicklung stattfinden, anstatt die Software
    > modular/dynamisch aufzubauen, und nicht strikt an irgendwelche
    > Softwareversionen zu münzen.

    Man mag diese Aussagen kaum glauben. Nutzt du keinen Apache?

    Ich hatte bisher bei jedem (Debian) update danach erst mal zu tun, um die Änderungen in den Konfigurationen einzuarbeiten. D.h. nach einem Versionsupgrade leifen die Server nicht.

    Das gleiche passiert bei PHP oder anderen Modularen Sprachen. Es werden Funktionen oder Module gestrichen oder geändert. Und da ich auch fremde Software benutze, muss ich mich dann auch noch darauf verlassen, das die Autoren dies schon berücksichtigt haben.

    Insofern sind deine Thesen, das es ja nichts ausmacht auf hunderten Server mal eben immer den aktuellsten Versionsstand auszuliefern, sehr optimistisch. Mir reicht es schon was es an Arbeit macht, bei einem halben Dutzend.

    Ich bin daher sehr dankbar für Debian update Politik, du kannst dich lange auf einen stabilen Servern, der schnell mit Sicherheitsupdate versorgt wird, verlassen.

    Rein aus Interesse, was setzt du denn auf deinen Server so sein?

  16. Re: Solche Diskussionen hätte man schon vor 15 Jahren ....

    Autor: felix.schwarz 17.04.16 - 09:16

    rocket_to_russia schrieb:
    > Wallbreaker schrieb:
    > > Ich bin seit etlichen Jahren für hunderte von Servern zuständig. Und die
    > > sind alle immer auf dem neuesten Softwarestand. Die eigene Software im
    > > Hause wird auch nachhaltig entwickelt, sodass Probleme mit Updates
    > > außerordentlich selten auftreten. (...)
    >
    > Man mag diese Aussagen kaum glauben. Nutzt du keinen Apache?
    >
    > Ich hatte bisher bei jedem (Debian) update danach erst mal zu tun, um die
    > Änderungen in den Konfigurationen einzuarbeiten. D.h. nach einem
    > Versionsupgrade leifen die Server nicht.

    Ich kenne solche Szenarien durchaus: Meist wird die Software (z.B. eine Webplattform) in-house entwickelt, es handelt sich um das/ein Kernprodukt der Firma, so dass dauerhaft und kontinuierlich Entwickler daran arbeiten.

    Gleichzeitig ist die eigene Software im Verhältnis zum Rest so groß, dass die Versionsunterschiede der externen Komponenten (z.B. Apache, Datenbank) nicht signifikant sind. Man hat also das System komplett in der Hand und kann sämtliche Fehler selbst diagnostizieren, es gibt keine großen Monolithen, bei denen man auf Fremdunterstützung angewiesen ist (z.B. SAP, Oracle).

    In so einer Umgebung kann man natürlich in der Entwicklung regelmäßig z.B. Fedora testen, Software darauf anpassen und (automatisiert) in der eigenen Landschaft deployen.

    Wenn man aber eher "Admin" ist, d.h. Software nur noch konfiguriert, liegt der Fokus meist auf dem störungslosen Betrieb. Oft gibt es überhaupt nicht die Ressourcen, um sich intensiv um die Systeme zu kümmern bzw. es gibt viele verschiedene Systeme, so dass man nicht alle einzeln testen kann. In dieser Situation will ich natürlich, dass sich möglichst wenig ändert.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. DEPOT - Gries Deco Company GmbH, Niedernberg
  2. Freie und Hansestadt Hamburg, Behörde für Inneres und Sport, Landesamt für Verfassungsschutz, Hamburg
  3. BPG Beratungs- und Prüfungsgesellschaft mbH, Krefeld
  4. BG-Phoenics GmbH, Hannover

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. 289€
  2. täglich neue Deals bei Alternate.de
  3. 239,00€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Minecraft Dungeons angespielt: Fehlt nur noch ein Klötzchen-Diablo in der Tiefe
Minecraft Dungeons angespielt
Fehlt nur noch ein Klötzchen-Diablo in der Tiefe

E3 2019 Von der Steuerung bis zu den Schatzkisten: Minecraft Dungeons hat uns beim Anspielen bis auf die Klötzchengrafik verblüffend stark an Diablo erinnert - und könnte gerade deshalb teuflisch spaßig werden!

  1. Augmented Reality Minecraft Earth erlaubt Klötzchenbauen in aller Welt
  2. Microsoft Augmented-Reality-Minecraft kommt zum zehnten Jubiläum
  3. Jubiläum ohne Notch Microsoft feiert Minecraft ohne Markus Persson

Wolfenstein Youngblood angespielt: Warum wurden diese dämlichen Mädchen nicht aufgehalten!?
Wolfenstein Youngblood angespielt
"Warum wurden diese dämlichen Mädchen nicht aufgehalten!?"

E3 2019 Der erste Kill ist der schwerste: In Wolfenstein Youngblood kämpfen die beiden Töchter von B.J. Blazkowicz gegen Nazis. Golem.de hat sich mit Jess und Soph durch einen Zeppelin über dem belagerten Paris gekämpft.
Von Peter Steinlechner


    Ada und Spark: Mehr Sicherheit durch bessere Programmiersprachen
    Ada und Spark
    Mehr Sicherheit durch bessere Programmiersprachen

    Viele Sicherheitslücken in Software sind auf Programmierfehler zurückzuführen. Diese Fehler lassen sich aber vermeiden - und zwar unter anderem durch die Wahl einer guten Programmiersprache. Ada und Spark gehören dazu, leider sind sie immer noch wenig bekannt.
    Von Johannes Kanig

    1. Das andere How-to Deutsch lernen für Programmierer
    2. Programmiersprachen, Pakete, IDEs So steigen Entwickler in Machine Learning ein

    1. Netzausbau: Städtebund-Chef will 5G-Antennen auf Kindergärten
      Netzausbau
      Städtebund-Chef will 5G-Antennen auf Kindergärten

      Der Deutschen Städte- und Gemeindebund spricht ein Tabuthema an: 5G-Antennen auf Schulen und Kindergärten. Der Mast strahle nicht auf das Gebäude, auf dem er steht.

    2. Ladesäulenbetreiber Allego: Einmal vollladen für 50 Euro
      Ladesäulenbetreiber Allego
      Einmal vollladen für 50 Euro

      Nach und nach stellen die Ladesäulenbetreiber auf verbrauchsgenaue Abrechnungen bei Elektroautos um. Doch eichrechtskonform sind die Lösungen teilweise immer noch nicht. Dafür aber bei Anbietern wie Allego recht teuer.

    3. Funklöcher: Telekom sucht sich den schlechtesten Antennenstandort aus
      Funklöcher
      Telekom sucht sich den schlechtesten Antennenstandort aus

      Ein Gemeinderat und Funktechnikexperte berichtet, wie die Telekom einen sinnvollen Standort für eine Mobilfunkstation ablehnte. Damit wird ein Ortsteil weiter nicht versorgt.


    1. 19:10

    2. 18:40

    3. 18:00

    4. 17:25

    5. 16:18

    6. 15:24

    7. 15:00

    8. 14:42