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. intersoft AG, Hamburg
  2. Ragaller GmbH & Co. Betriebs KG, Langenweddingen
  3. CodeCamp:N GmbH, Nürnberg
  4. Schwarz Dienstleistung KG, Neckarsulm

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. 279,90€
  2. 64,90€ (Bestpreis!)


Haben wir etwas übersehen?

E-Mail an news@golem.de


iPad 7 im Test: Nicht nur für Einsteiger lohnenswert
iPad 7 im Test
Nicht nur für Einsteiger lohnenswert

Auch mit der siebten Version des klassischen iPads richtet sich Apple wieder an Nutzer im Einsteigersegment. Dennoch ist das Tablet sehr leistungsfähig und kommt mit Smart-Keyboard-Unterstützung. Wer ein gutes, lange unterstütztes Tablet sucht, kann sich freuen - ärgerlich sind die Preise fürs Zubehör.
Ein Test von Tobias Költzsch

  1. iPad Einschränkungen für Apples Sidecar-Funktion
  2. Apple Microsoft Office auf neuem iPad nicht mehr kostenlos nutzbar
  3. Tablet Apple bringt die 7. Generation des iPads

Internetprovider: P(y)ures Chaos
Internetprovider
P(y)ures Chaos

95 Prozent der Kunden des Internetproviders Pyur bewerten die Leistung auf renommierten Bewertungsportalen mit der Schulnote 6. Ein Negativrekord in der Branche. Was steckt hinter der desaströsen Kunden(un)zufriedenheit bei der Marke von Tele Columbus? Ein Selbstversuch.
Ein Erfahrungsbericht von Tarik Ahmia

  1. Bundesnetzagentur Nur 13 Prozent bekommen im Festnetz die volle Datenrate

IT-Sicherheit: Auch kleine Netze brauchen eine Firewall
IT-Sicherheit
Auch kleine Netze brauchen eine Firewall

Unternehmen mit kleinem Geldbeutel verzichten häufig auf eine Firewall. Das sollten sie aber nicht tun, wenn ihnen die Sicherheit ihres Netzwerks wichtig ist.
Von Götz Güttich

  1. Anzeige Wo Daten wirklich sicher liegen
  2. Erasure Coding Das Ende von Raid kommt durch Mathematik
  3. Endpoint Security IT-Sicherheit ist ein Cocktail mit vielen Zutaten

  1. Archer2: Britischer Top-10-Supercomputer nutzt AMDs Epyc
    Archer2
    Britischer Top-10-Supercomputer nutzt AMDs Epyc

    Der Archer2 soll 2020 die höchste CPU-Leistung aller Supercomputer weltweit erreichen und es dank Beschleunigerkarten in die Top Ten schaffen. Im System stecken fast 12.000 Epyc-7002-Chips und Next-Gen-Radeons.

  2. Corsair One: Wakü-Rechner erhalten mehr RAM- und SSD-Kapazität
    Corsair One
    Wakü-Rechner erhalten mehr RAM- und SSD-Kapazität

    Mit dem i182, dem i164 und dem i145 aktualisiert Corsair die One-Serie: Die wassergekühlten Komplett-PCs werden mit doppelt so viel DDR4-Speicher und doppelt so großen SSDs ausgerüstet.

  3. ChromeOS: Google zeigt neues Pixelbook Go und benennt Start von Stadia
    ChromeOS
    Google zeigt neues Pixelbook Go und benennt Start von Stadia

    Das Pixelbook Go ist ein Clamshell-Notebook mit ChromeOS, das eher eine Ergänzung als ein Nachfolger des Ur-Pixelbooks ist. Zumindest kostet es wesentlich weniger. Auch der genaue Starttermin für Stadia steht jetzt fest.


  1. 18:25

  2. 17:30

  3. 17:20

  4. 17:12

  5. 17:00

  6. 17:00

  7. 17:00

  8. 16:11