1. Foren
  2. Kommentare
  3. Internet-Forum
  4. Alle Kommentare zum Artikel
  5. › NPM: Über 250 Node-Module wegen…

Das hasse ich auch immer an Linux

Neue Foren im Freiraum! Raumfahrt und freie Software haben jetzt einen Platz, die Games tummeln sich jetzt alle in einem Forum.
  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Das hasse ich auch immer an Linux

    Autor: /mecki78 23.03.16 - 20:42

    Paketabhängigkeiten! Wenn man am Mac (OS X) eine App herunterlädt, dann ist die self-contained. D.h nicht, dass sie ein monolithischer Block ist. Sie kann intern aus 100 Libraries und 1000 Modulen bestehen, in eigenen Dateien, teilweise nur weak-gelinkt... egal. Es ist "ein Ding". Wenn ich es von System A nehmen und auf System B kopieren und starte, dann läuft es, denn alles was es zum laufen braucht, das bringt es mit. Mac Apps sind meistens self-contained.

    Linux mit Paketmanagement hingegen sieht so aus: Ich will ein kleines Paket installieren, sage also den Paketmanager, dass ich das hier brauche, ein Paket, das gerade mal 10 KB ist. Und dann kommt der Paketmanager und sagt mir, dass ich dafür 80 andere Paket installieren muss, die alle zusammen 500 MB brauchen. WTF?!? Jetzt könnte man sagen, ja, das ist halt so, weil diese eine Paket braucht das halt alles. Stimmt aber meistens gar nicht. Das kleine Teil braucht nur eine winzige Funktion aus einer Library. Diese Funktion ist gerade mal 100 Zeilen C Code. Man hätte sie einfach aus der Library rauskopieren können und gut ist, weil dieser Code nicht einmal weitere Abhängigkeiten hat. Aber der Entwickler linkt stattdessen gegen dieses Library und diese wird somit zu einer Abhängigkeit.

    Diese Library, nennen wir sie mal LibA hat aber wiederum Abhängigkeiten zu anderen Libs, LibM, LibN und LibO. Wohlgemerkt, die 100 Zeilen Code von oben, die brauchen gar nichts davon, aber LibA hat ja mehr als nur diese 100 Zeilen und irgendwo anders braucht er halt was von den anderen Libs... mal mehr und mal weniger. Und jede von diesen Libs hat weitere Abhängigkeiten, eine zu einer weiteren Lib und die braucht gleich ein komplettes Subsystem einer anderen Programmiersprache um zu funktionieren, das wiederum 20 andere Libs braucht, usw., usw., usw.

    Die Idee von kleinen, schlanken Linux, das aus lauter kleinen schlanken Tools und Libs besteht wird dadurch zerstört, dass das Abhängigkeitsgeflecht derart hoch ist, das quasi nichts mehr läuft ohne ein Subsystem von mehreren GB aus Abhängigkeiten zu installieren, selbst dann, wenn die meisten Apps oft nur minimal Funktionalität brauchen.

    Hatte mal ein ganz tolles Beispiel aus der realen Welt. Da waren es nicht einmal 100 Zeilen. Da war eine Library abhängig wegen nur einem einzigen Funktionsaufruf und diese Funktion waren (kein Scheiß!) 4 Zeilen C Code! Wegen 4 Zeilen C Code wurde eine Lib als Abhängigkeit definiert, die selber jeder Menge weitere Abhängigkeiten nach sich zog.

    Don't repeat yourself (DRY) in alle Ehren, aber bevor ich ein Abhängigkeit zu einem ganzen Geflecht an Modulen/Libs schaffe, implementiere ich halt diese Kackfunktion selber in meinen Code. Die 4 Zeilen werden keinen Menschen töten und schon bin ich alles diese Abhängigkeiten auf einen Schlag los geworden.

    Und auch die Angst vor statischen Linking ist unbegründet. Klar hat es Vorteile wenn große Libs wie glibc nicht statisch gelinkt werden. Dadurch würden alle Binaries sonst 20-60% größer werden und anders als shared libs können sich die Binaries dann nicht den Arbeitsspeicher teilen (der RAM Verbrauch würde genauso wachsen, denn eine dynamisch Lib muss nur einmal im Speicher sein, egal wie viele Apps die nutzen), aber wenn man nur minimal Funktion einer anderen Lib braucht, dann heißt statisches Linken oft nur, dass das Binary vielleicht 4-8 KB größer wird, dynamisches linken heißt ich muss eine 400 KB Lib dazu installieren und wenn die außer mir keiner braucht, dann hat da auch Null Vorteile was Speicher angeht.

    Bis zu einem gewissen Grade sind Pakete und Abhängigkeiten okay, aber wenn es ausartet, dann wird das schnell zu einem Problem und zwar einen das größer ist als die Probleme, die man damit ursprünglich mal lösen wollte!

    /Mecki

  2. Re: Das hasse ich auch immer an Linux

    Autor: zZz 23.03.16 - 21:17

    Wie gut, dass vorkompilierte Apps nie Abhängigkeit haben, nicht war? .NET Runtime? VisualBasic Runtime? Was soll das denn sein?

    Bei bekannter Software hat man eh die Wahl, ob man das per Paketmanager oder von der Webseite des Anbieters runterlädt. Und weil Du Mac OS X anführst: noch nie was über denn AppStore geladen? Homebrew noch nie verwendet?

  3. Re: Das hasse ich auch immer an Linux

    Autor: Neutrinoseuche 23.03.16 - 21:21

    Finde ich auch okay. Alle nötigen Libs einfach in das Programm includen und dann nur eine Datei ausliefern. Dann hat man zwar viele Dateien x-fach und x unterschiedlichen Versionen auf der Festplatte liegen, aber wen juckt das schon .... nein

    Linux macht es richtig. So wird immer nur die aktuellste Version des Pakets genutzt. Es gibt keine x-verschiedenen Versionen der gleichen Datei/Lib und damit müllt man das System auch nicht zu. Zusätzlich ist es möglich die Pakete auch einzeln zu updaten. Das ist viel effizenter als alles in eine Datei zu packen die dann mit dem nächsten Patch am BS wieder komplett neu gezogen werden muss weil eine Lib in der Datei nicht mehr funktioniert.

  4. Re: Das hasse ich auch immer an Linux

    Autor: /mecki78 23.03.16 - 21:47

    Neutrinoseuche schrieb:
    --------------------------------------------------------------------------------
    > Finde ich auch okay. Alle nötigen Libs einfach in das Programm includen und
    > dann nur eine Datei ausliefern. Dann hat man zwar viele Dateien x-fach und
    > x unterschiedlichen Versionen auf der Festplatte liegen, aber wen juckt das
    > schon ....

    Hat man eben nicht. Wo bitte liegen da x-fach die gleichen Dateien rum, wenn man sie in das Programm included? Das was du schreibst macht gar keinen Sinn, bzw. du widersprichst dir ja schon im ersten Satz selbe selber.

    Und wenn man es wie am Mac macht, dann sieht jedes Programm abgesehen von den System Libraries nur seine eigenen und niemals die von anderen Programmen. Das hat diverses Vorteile:

    - Verschiedene Apps können verschiedene, zueinander inkompatible Versionen der gleichen Lib nutzen.

    - Jede App ist wie ein eigener VM Container. Sieht nur seine Libs und kann problemlos zwischen Systemen kopiert werden, da alle Abhängigkeiten automatisch immer mit kopiert werden.

    - Man braucht keinen Paketmanager der Pakete und Abhängigkeiten verwaltet. App installierten heißt: Herunterladen und irgendwo hin kopieren. Fertig. App deinstallieren? Einfach App in den Papierkorb werfen und alle Abhängigkeiten sind mit weg. Keinen Dateileichen irgendwo im System.

    - Es wird nie passieren, dass du irgendwo eine Library updates und auf einmal brechen diverse Apps, weil die mit der neuen Lib kompatibel sind. Umgekehrt kann aber jede App im nächsten Release beliebig neue Versionen einer Lib mitbringen (so kann eine App z.B. auch eine Alpha Version nutzen, während alle anderen die stabile Release Version nutzen)

    So was wie die DLL Hölle, das ist ein typisches Windows Problem, so was gibt und gab es am Mac noch nie.

    /Mecki

  5. Re: Das hasse ich auch immer an Linux

    Autor: /mecki78 23.03.16 - 21:53

    zZz schrieb:
    --------------------------------------------------------------------------------
    > Wie gut, dass vorkompilierte Apps nie Abhängigkeit haben, nicht war?

    Keine Ahnung wovon du hier sprichst. Ich habe mich in meinem Post nur auf vorkompilierte Apps bezogen. Ich benutze doch keine Linux Distribution, die Pakete von Source baut, das dauert mir viel zu lange, wenn ich schnell mal ein Tool installieren will.

    > Bei bekannter Software hat man eh die Wahl, ob man das per Paketmanager
    > oder von der Webseite des Anbieters runterlädt.

    Was nur geht, wenn hier alles statisch gebaut wurde oder auf sämtliche Libraries verzichtet wurde, die man nicht sowieso auf jeden typischen Linux System immer findet. Ansonsten kannst du "runterladen von der Webseite" vergessen, weil ohne Paketmanager bekommt kein Mensch die 200 Abhängigkeiten gebacken.

    > Und weil Du Mac OS X
    > anführst: noch nie was über denn AppStore geladen?

    Doch, dauernd. Und da kommt jede App eben nur für sich. Da werden keine Abhängigkeiten installiert. Jede App muss Abhängigkeiten selber mitbringen im Bundle oder statisch gelinkt sein. Ich glaube du hast meinen Post nicht verstanden, kann das sein?

    > Homebrew noch nie verwendet?

    Nein, auf keinen Fall. Das vermüllt mein OS X System dann genauso wie mein Linux System. Ich habe keine Lust drauf das irgend ein Tool irgendwo in mein System irgendwelche Dateien ablegt, von denen ich dann nachher nicht sagen kann warum die da liegen, wo die herkommen und wer die noch braucht. Ein System, dass nur über einen Paketmanager wartbar ist nervt mich schon bei Linux, so was brauche ich am Mac nicht. Am Mac bin ich mein eigener Paketmanager und kann dir jederzeit zu jeder Datei sagen, wo die herkommt.

    /Mecki

  6. Re: Das hasse ich auch immer an Linux

    Autor: baltasaronmeth 23.03.16 - 22:07

    Bist du sicher, dass du den richtigen Artikel kommentiert hats?

  7. Re: Das hasse ich auch immer an Linux

    Autor: /mecki78 23.03.16 - 22:24

    baltasaronmeth schrieb:
    --------------------------------------------------------------------------------
    > Bist du sicher, dass du den richtigen Artikel kommentiert hats?

    Ja, habe ich. Es geht um Abhängigkeiten. Es geht darum, wie in kürzester Zeit ein komplexes Geflecht aus Abhängigkeiten entsteht, wo dann eben 250 wichtige, große Pakete von einer winzigen, total unwichtigen Library abhängig sind, oft wegen einer lächerlichen Funktion, die man leicht hätte selber implementieren können und wenn dann wie im aktuellen Fall auf einmal diese Library fehlt, dann bricht dir das ganz Geflecht zusammen. So war es bei NPM und so ist es heutzutagen eben auch bei jeden Linux System. Verschiedene Systeme, gleiche Problematik.

    Die Idee, dass Entwickler nicht den gleichen Code zigfach schreiben müssen (DRY) und dass es leichter für Einsteiger ist fertige Bausteine von anderen zu nutzen, damit sie mit noch weniger Code noch schneller noch mehr erreichen, ist grundsätzlich eine gute Idee. Aber sobald das ganze dann zu einen totalen wirren, unüberschaubaren Geflecht führt, wo quasi fast jede Komponente von jeder anderen abhängt, dann hast du nur oberflächlich betrachtet ein flexibles, dynamisches System mit fein granulären Abhängigkeiten geschaffen. In Wahrheit ist das ganze System längst ein unflexibler, statischer und monolithischer Klotz geworden, wie ein Turm aus Bausteinen und jeden Baustein den du da raus ziehst, bringt den kompletten Turm zum Einsturz.

    /Mecki

  8. Re: Das hasse ich auch immer an Linux

    Autor: zettifour 23.03.16 - 23:13

    Naja, so schlimm mit Homebrew ist es nicht am Mac. Ist tatsächlich nur ein einziges eigenes Verzeichnis in /usr wo der Kram landet. Passt schon. Habe selbst ein Programm in C und GTK als GUI geschrieben (in Xcode). Ohne eine einzige Zeile Code zu ändern, compiliert und läuft es problemlos unter Linux und OS X. Die Hölle kam dann bei der Portierung auf Windows. Posix Threads und Regex - schlimm. Ging aber dann mit MinGW. Nach langem Probieren. Um das Ding dann zu verteilen, muß ich natürlich zig dll Files mit ausliefern.
    Ich will damit nur sagen, dass eigentlich Windows der Aussreisser aller Betriebssysteme ist. Aller anderen sind unixoid und mehr oder weniger gut kompatibel.

  9. Re: Das hasse ich auch immer an Linux

    Autor: DASPRiD 23.03.16 - 23:45

    /mecki78 schrieb:
    --------------------------------------------------------------------------------
    > - Man braucht keinen Paketmanager der Pakete und Abhängigkeiten verwaltet.
    > App installierten heißt: Herunterladen und irgendwo hin kopieren. Fertig.
    > App deinstallieren? Einfach App in den Papierkorb werfen und alle
    > Abhängigkeiten sind mit weg. Keinen Dateileichen irgendwo im System.

    Das macht dir auf Debian-Systemen apt-get autoremove.

  10. Re: Das hasse ich auch immer an Linux

    Autor: vlad_tepesch 23.03.16 - 23:49

    interessante gedanken.
    Man bräuchte also soe was wie ein Pseudo-Dynamic-static-linking.

    Wenn der genutzte Anteil an einer lib ausreichend klein ist, erzeugt der compiler eine eigene dynamische version dieser lib und legt sie dem Programm bei.
    Das OS schaut beim PRogrammstart ob es die Lib bereits geladen hat und falls nicht läd es zuerst nur die minimierte version, welche muss eine vollständigere geladen werden durch die vollständigere eresetzt wird.
    Zusätzlich könnte das os beim programmstart schauen, ob es eine neuere version hat, die sicherheitskritische lücken patcht, dann sollte ebenfalls die neuere os-lib genommen werden.

  11. Re: Das hasse ich auch immer an Linux

    Autor: Moe479 24.03.16 - 01:25

    es ist mal so mal so richtig ... entsprechend der konkreten situation, wenn es z.b. um soetwas kritisches verschlüsselung geht willst du ansich nicht dass jeder sein eigenes ggf. schlechter betreutes 'ding' nutzt, sondern möglichst ein gemeinsames was möglichst viele mitbetreuen ... es sei denn hiding/knowledge ist dein konzept ...

    natürlich erzwingt das auch mitunter leidige kompromisse die um so lästiger werden sobald etwas sehr spezielles erreicht werden soll was nicht wircklich im fokus der verwendeten base liegt, da es ggf. viel arbeit erfordert auf eine ganz oder von auch von anderen gepflegte sich im detail rapid verändernde gemeinsamme basis zu setzen ...

    das ist schon ein spagat zwischen dem was man selbst noch leisten/betreuen kann und wie stabil, im hinblick auf den nutzen für einen selbst. und der nutzer die arbeit der anderen sich bewegt.

    ich denke da gibt es kein sogn. 'patentrezept', einfach nur immer statisch mitgeliferte ggf. hornalte libaries zu nutzen setzt einen ggf. dem problem aus auch einstige fehler ewig mitzuführen weil man sich nicht mit allem unbedingt immer beschäftigen kann ...

    soetwas kann genauso im desaster enden wie von den fortentwicklungen anderer ständig überollt zu werden, und nur noch an kompatiblitäts bedingten änderungen zu sitzen anstatt seinen darauf aufsetzenden kram effektiv zu erweitern.

  12. Re: Das hasse ich auch immer an Linux

    Autor: Moe479 24.03.16 - 01:34

    wie gehst du damit um wenn jahre später ein fehler/exploit in deiner hornalten libary base entdeckt wird der morgen in der aktuellen version gefixt wird ... maxhst du dann nen backport derer patches auf deine uralte version ... was ist wenn das garnicht mehr so einfach geht ... fängst du erst dann dich mit den veränderungen in base zu beschäftigen ... ist das nicht reichlich spät, wäre deine base aktuell, wäre ggf. morgen der bug durch dritte gefixt ohne dein zutun bzw. eine veränderung bei dir ... so hast du plötzlich ggf. viel mehr arbeit anstatt vorsorge durch ständige kompatiblität zu einer aktuellen common base zu gewährleisten.

  13. Re: Das hasse ich auch immer an Linux

    Autor: lear 24.03.16 - 02:38

    Ja, OSX hat die Probleme, die sich jetzt bei Docker auftun, schon ewig...

    Deine Kritik geht doch fehl. Bzw. in der Zusammenfassung, nicht aber im Detail.
    Das Problem sind sinnfreie Abhängigkeiten, die anders besser gelöst wären - nur was hieße dieselbe Problematik denn im OSX/Docker Modell?
    Die selben gewaltigen Abhängigkeitsbäume, aber in jedem Kontainer kopiert.
    Zusätzlich zur Patchproblematik.
    Und wenn Du libFoo in 10 Versionen hast, hast Du die auch zwingend parallel im Speicher - selbst wenn eigentlich alle Anwendungen mit derselben Version klarkämen. Toll! - ?

    Der "Vorteil" dieses Ansatzes ist die Lösung von "Für Hadoop brauche ich zwingend libFoo vX.Y, aber http benötigt zwingend libFoo vY.Z... wahhhhhhhh", also nochmal ein anderes "Schludrigkeitsproblem" - das ehrlich gesagt auch besser anders gelöst wäre - im Prinzip wären wir mit statischen Links noch besser bedient als mit Docker, aber das geht ja nicht mit Java.

  14. Re: Das hasse ich auch immer an Linux

    Autor: gadthrawn 24.03.16 - 07:44

    Moe479 schrieb:
    --------------------------------------------------------------------------------
    > wie gehst du damit um wenn jahre später ein fehler/exploit in deiner
    > hornalten libary base entdeckt wird der morgen in der aktuellen version
    > gefixt wird ... maxhst du dann nen backport derer patches auf deine uralte
    > version ... was ist wenn das garnicht mehr so einfach geht ... fängst du
    > erst dann dich mit den veränderungen in base zu beschäftigen ... ist das
    > nicht reichlich spät, wäre deine base aktuell, wäre ggf. morgen der bug
    > durch dritte gefixt ohne dein zutun bzw. eine veränderung bei dir ... so
    > hast du plötzlich ggf. viel mehr arbeit anstatt vorsorge durch ständige
    > kompatiblität zu einer aktuellen common base zu gewährleisten.


    Warum gibt es Docker? Versuch aus der Abhängigkeitshölle zu gelangen. Braucht ein altes Programm Funktionen erobert allen dll Heisst das nicht, das eine neue die noch hat. APIs ändern sich. Sachen werden deprecated. Hat mich vor Jahren schon bei iperf für Linux genervt, das bei sles das on einst neuen Version erst mal nicht mehr lief, dann massiver Aufwand nötig war es zum laufen zu bekommen.

  15. Re: Das hasse ich auch immer an Linux

    Autor: Neutrinoseuche 24.03.16 - 08:01

    /mecki78 schrieb:
    --------------------------------------------------------------------------------
    > Und wenn man es wie am Mac macht, dann sieht jedes Programm abgesehen von
    > den System Libraries nur seine eigenen und niemals die von anderen
    > Programmen. Das hat diverses Vorteile:

    Ich dachte immer ein Mac ist für Profis. Das man nun aber alle nötigen Ressourcen in eine Datei includen muss, damit der arme User keine Möglichkeit hat da irgendwas zu beschädigen, das klingt für mich eher nach Bevormundung als nach Vorteil.

    Das Problem an der Sache ist auch, sobald am MacOSX etwas durch Patch oder neuer Version geändert wird und dadurch eine Ressource in einer Programmdatei nicht mehr läuft, muss man eine ganze Programmdatei neu runterladen anstatt nur die eine Ressource. Eventuell bekommt man noch einen Patch wenn man Glück hat. Wie großzügig. :)

    Die Methode alles in eine Programmdatei zu packen mag Vorteile haben, das streite ich gar nichtg ab. Aber meiner Meinung nach ist das eher eine Bevormundung als das Zugeständnis dass der User mündig genug ist um in der Lage zu sein sein System am laufen zu halten. Es wird einfach auf Nummer sicher gegangen damit der gemeine Nutzer nichts kaputtmachen kann und ja bequem ist auch.

    Verteilte Ressourcen wie in Windows oder Linux, AmigaOS etc. pp. finde ich wesentlich besser. Wenn ein Programm eine bestimmte Version einer Ressource braucht, dann liefert es diese mit und installiert sie im Programmverzeichnis. Ansonsten läuft es auch mit einer zentralane Ressource. Funktioniert seit Jahren bei allen möglichen Betriebssystemen prima, nur MacOSX will die User "schützen".

  16. Re: Das hasse ich auch immer an Linux

    Autor: baltasaronmeth 24.03.16 - 10:30

    Es ist richtig, dass die Abhängigkeitsbäume in Linuxdistributionen Probleme verursachen können. Wenn ich aber lese "Das hasse ich auch immer an Linux", unter einem Artikel, in dem es darum geht, dass Firmen direkt auf die Distributoren Einfluss nehmen, wenn es um Markennamen geht, und diese Distributoren dann einfach einlenken ohne alle Parteien anzuhören und man ihnen vorwerfen kann, in kommerziellem Interesse zu handeln, anstatt sich ihre Community zu kümmern, dann wundere ich mich, ob du den Artikel gelesen oder nur überflogen hast.

    Du hast aber in so fern Recht, dass dieses Abhängigkeitsmodell Auswirkungen auf die Tragweite solcher Streits ist. Zum Glück gibt es inzwischen Widerstand in der Linuxgemeinde. ich bin selbst ein Verfechter des bisherigen Distributionsmodells, aber den Mangel an bequemen Alternativen halte ich nicht für förderlich, weil Einheitsgrößen nie jedem passen.

  17. Re: Das hasse ich auch immer an Linux

    Autor: caldeum 24.03.16 - 10:55

    Also wenn 10 KB ganze 500MB in Abhängigkeiten hinter sich herziehen, installiert man meist ein ganzes KDE oder Gnome oder Qt mit und hat eigentlich nur die falsche Wahl getroffen was die Anwendung angeht.

  18. Re: Das hasse ich auch immer an Linux

    Autor: aFrI 24.03.16 - 11:40

    Was machst du jetzt wenn z.B. die libpng einen eklatanten Fehler hat? Vertraust du darauf, dass die Maintainer alle Deiner genutzten selfcontained-Pakete das direkt mitbekommen und patchen?
    Wie kannst du dann garantieren, dass alle deine Pakete in deinem System up-to-date sind? Ich nehme an garnicht.

    Die Modularität eines globalen Paketsystems ist doch gerade die Stärke!
    Klar, Dein kleines Wunschpaket ist vielleicht nur 10kb groß und hat die Abhängigkeiten zu anderen Paketen welche dann vielleicht größere Datenmengen erfodern.
    Dafür hast du aber die Sicherheit dass durch den Patch des systemweit genutzten Pakets alle Stellen in denen es genutzt wird abgedeckt hast und brauchst nicht jede library mehrfach über jeden selfcontained-Paket doppelt herunterladen.

    In meinen Augen bist du ein Troll. Wenn nicht, dann mach mal weiter wie du es für richtig hälst. Ich kann nur meinen Kopf schütteln..

  19. Re: Das hasse ich auch immer an Linux

    Autor: aFrI 24.03.16 - 11:45

    Bei einer Linux-Distribution mit Paketmanager kann aber nicht jeder Hans und Franz mal eben ein Paket einstellen. Dort wird der Paketbaum mit seinen Abhängigkeiten und Kompatibilitäten gepflegt.

    Bei npm kann jeder machen was er will.

    Dein ganzes Einstiegsposting ist daher imho etwas deplatziert..

  20. Re: Das hasse ich auch immer an Linux

    Autor: aFrI 24.03.16 - 11:55

    gadthrawn schrieb:
    --------------------------------------------------------------------------------
    > Braucht ein altes Programm Funktionen erobert allen dll Heisst das nicht,
    > das eine neue die noch hat.

    Kannst du den Satz bitte noch mal mit einem Sinn füllen?

    Was sind dlls und was haben diese mit Linux/Docker zu tun?

    Docker gibt es nicht um aus Abhängigkeiten heraus zu kommen, sondern um gewisse Dienste in chroot-Umgebungen laufen zu lassen und so für eine stärkere Abstraktion zwischen den Dienst-Containern schaffen zu können.

    Beispiel: Du könntest auf einer Maschine ein Staging-Environment parallel zu dem Live-Environment laufen lassen und dort zuerst die neuen Versionen der gepatchten Pakete einspielen und schauen ob die Funktionalität deines Dienstes immernoch gewährleistet ist, ohne das Live-System dabei anfassen zu müssen.

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Product Designer UX/UI (m/f/d)
    ToolTime GmbH, Berlin
  2. IT-Spezialist als Systemarchitekt (m/w/d)
    Evangelische Landeskirche in Württemberg, Stuttgart
  3. Inhouse Berater SAP (m/w/d)
    über Hays AG, Giengen an der Brenz
  4. IT-Koordinator II Anwendungsentwicklung (m/w/d)
    WEMAG Netz GmbH, Schwerin

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 7,99€
  2. 8,99€
  3. 49,99€
  4. ab 79,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


IT-Studium und Jobaussichten: Hauptsache was mit Informatik
IT-Studium und Jobaussichten
Hauptsache "was mit Informatik"

Wegen des Fachkräftemangels ist es im Fall von Informatik fast egal, welche Fachrichtung man studiert. Ein paar Gedanken sollte man sich trotzdem machen.
Von Peter Ilg

  1. Überwachung bei Examen Datenschützer geht gegen Spähsoftware an Unis vor

Einführung in MQTT: Alles läuft über den Broker
Einführung in MQTT
Alles läuft über den Broker

MQTT eignet sich hervorragend für Sensoren und IoT-Anwendungen. Wir geben eine Einführung in das Protokoll für Machine-to-Machine-Kommunikation.
Von Florian Bottke

  1. Ohne Google, Android oder Amazon Der Open-Source-Großangriff
  2. Internet der Dinge Asistenten wie Alexa und Siri droht EU-Regulierung

Kosmologie: Die Raumzeit ist kein Gummituch!
Kosmologie
Die Raumzeit ist kein Gummituch!

Warum das beliebte Modell von den Kugeln im Gummituch in die Irre führt - und wie man es retten kann.
Von Helmut Linde

  1. Indische Regierung Wir haben noch "kein 5G-Netz, was Corona verursachen könnte"