News Linux-Distribution für Profis: Red Hat Enterprise Linux 9 als Beta erschienen

zatarc schrieb:
Wenn ich von ZFS (auf Linux) rede, dann meine ich natürlich auch OpenZFS. DAS ZFS gibt es natürlich nicht für Linux.
Wie gesagt. Das Problem liegt nicht bei mir, sondern bei Dir. Du hast OpenZFS und Oracle zusammengeworfen. Ich hab lediglich darauf hingewiesen.

zatarc schrieb:
Für eine Integration in den Upstream-Kernel müsste Oracle aktiv werden und Teile des Codes, der noch aus Sun-Zeiten stammt, relizenzieren. Tun sie halt nicht.
Genau so gut kann man sagen, das die Kernel-Leute aktiv werden müssten damit CDDL-Code im Linux-Kernel integrierbar ist.
Abgesehen davon: Selbst wenn Oracle heute ihren ZFS-Code heute unter die GPL stellen würde hieße das ja nicht, das OpenZFS morgen in den Kernel könnte.
Wie bereits gesagt, haben sich die beiden Implementationen auseinander entwickelt. Klar würde man das hinkriegen, aber es wäre halt kein Automatismus.

zatarc schrieb:
OpenZFS verwendet die CDDL Lizenz. Diese ist nun mal nicht mit GPLv2 kompatibel. Die Bedenken der Kernel-/Linux-Community sind absolut nachvollziehbar, vor allem wenn man Oracle damit einen Hebel gibt alles lahmzulegen.
Achja. Was würde denn im schlimmsten Fall passieren? Du tust ja so, als würde das das potentielle Ende von Linux bedeuten. Das Schlimmste was passieren kann ist, das Oracle irgendwann sagt "Ihr dürft das nicht mehr mit dem Linux-Kernel rausgeben". Das klingt jetzt nicht gerade nach einem Daklomesschwert.

Abgesehen davon spricht ja nix dagegen ZFS (wie jetzt auch) einfach out-of-tree weiter zu führen. Im wesentlichen ist ja weniger interessant, ob man das zusammen runterladen kann (was ja der eigentliche Knackpunkt ist), sondern es würde ja bereits ausreichen wenn die Kernel-Entwickler und OpenZFS-Entwickler kooperieren. Leider zeigen sich die Linux-Entwickler (offenbar aus ideologischen Gründen) nicht besonders kooperativ.
Eine Zusammenarbeit ginge schon, wenn man denn wollte.
Und das wäre ja auch kein Novum. Gibt ja noch andere out-of-tree Module oder auch sowas wie Firmware. (deren Lizenzen oftmals sogar noch restriktiver sind und wo es häufig nicht mal nen Source-Code gibt) Und da klappt das in der Praxis ja auch.

zatarc schrieb:
Natürlich ist das ein Problem in der Praxis. Eine Integration in den Upstream-Kernel ist ein must-have, wenn man ZFS wirklich überall haben will.
....
Das ist kein Enterprise-tauglicher Ansatz.
Genau. Die OpenZFS-Leute machen den Linux-Support auch nur so zum Spaß falls da draußen ein paar Nerds sind, die damit etwas herumexperimentieren wollen. Aber "in echt" setzt das natürlich niemand ein. 🙄
Komisch nur das die treibende Kraft hinter OpenZFS das ZFSonLinux-Projekt war/ist. Aber das hieß sicher nur zufällig so.

zatarc schrieb:
Und ja, Debian ist per Definition keine Enterprise-Distribution. Vielleicht solltest du mal Google fragen was Enterprise-Distributionen sind.
Du magst damit recht haben, aber dann andererseits anhand von Fedora zu belegen das ZFSonLinux nicht "funktioniert" passt dann aber auch nicht.
Warum gehst Du nicht auf das Proxmox-Beispiel ein? Vermutlich weil es nicht zu Deinen Ansichten passen würde und Du dann einräumen müsstest, das Du vielleicht doch nicht ganz richtig liegst.
Na wenn das so ist, hab ich keine weiteren Fragen, Euer Ehren.

zatarc schrieb:
Man muss dann immer warten bis das OpenZFS-Projekt nachzieht und den neusten Kernel unterstützt.

Mit einer Upstream-Integration gäbe es diese Probleme nicht
Klar wäre das schöner. Aber an OpenZFS liegts nicht. Eher am Unwillen einiger Kernel-Entwickler. Aber es ist natürlich einfacher die Schuld einseitig auf Oracle abzuschieben. Das passt so schön ins einfache Weltbild, wo Oracle ja bereits die Bad Company ist.
 
  • Gefällt mir
Reaktionen: foo_1337
Salamimander schrieb:
Enterprise Distro = Support mit SLAs.

Setz dich mal mit den IT-Richtlinien der BaFin für Versicherungen/Banken (VAIT/BAIT) auseinander. Dort ist klar definitiert was du einsetzen darfst und was nicht. Diese verbieten es dir Produktionssysteme ohne Enterprise-Support zu betreiben.

Also ja, Debian ist per Definition keine Enterprise-Distro. Das sind per Definition nur RHEL, SLES, Ubuntu und ein paar Exoten.
Ergänzung ()

andy_m4 schrieb:
Konrintherkackerei. Selbst Linus Torvalds spricht nur von ZFS, wenn er von OpenZFS redet ....

andy_m4 schrieb:
https://itsfoss.com/linus-torvalds-zfs/
andy_m4 schrieb:
Du kennst Oracle? Ja? Die Firma die Google verklagt hat, weil die eine Java-kompatible API gebaut haben?

https://itsfoss.com/linus-torvalds-zfs/

andy_m4 schrieb:
https://itsfoss.com/linus-torvalds-zfs/

andy_m4 schrieb:
Fedora war ein Beispiel. Ersetze es gegen jede andere Distro. Ändert nichts an dem grundlegenden Problem, dass nach jedem Kernel-Update ein neues Compile-n-Pray startet. Das funktioniert auf Dauer einfach nicht.
Ich hab hier aus dem Firmen-Alltag unzählige Beispiele, wie es selbst IBM und Red Hat einfach nicht gebacken bekommen, Kernel und Kernel-Module (z.B. GPFS/Spectrum Scale) synchron zu halten. Und die beiden sind mittlerweile eine Firma....
Einzige Lösung: Integration in den Upstream. Sieht selbst IBM mittlerweile so....
andy_m4 schrieb:
Bist du Oracle Berater? :)
 
Zuletzt bearbeitet von einem Moderator:
Endlich wirst du konkret! Ja, es gibt da Vorgaben. Ja ich kenne sie. Du solltest dich aber selbst fragen: Gibt es diese Vorgaben, weil es Sinn macht oder gibt es diese Vorgaben, weil da viele „Berater“ beraten haben? Nicht alles was irgendwo steht, ist technisch und organisatorisch nachvollziehbar. Wenn das Unternehmen sich an diese Vorgaben halten muss, dann bleibt nur der kleine Haufen an Software über. Dennoch sagt das NICHTS (!) über die Qualität und Sicherheit von zB Debian oder FreeBSD aus, gerade die Qualität und Sicherheit versuchst du hier aber schlecht zu reden. Und genau da ging die Diskussion los und genau deshalb greife ich hier ein.
 
zatarc schrieb:
Enterprise Distro = Support mit SLAs.
Du kriegst Support von Redhat für Redhat Linux und von Canonical für ubuntu. Du kriegst kein Support von Debian für Debian. Das ist korrekt. Aber das bedeutet nicht, das Du generell kein professionellen Support für Debian kriegst. Eine ganze Reihe an Firmen widmen sich dem Support-Geschäft.

Debian wird auch in nennenswerten Umfang im kommerziellen Umfeld eingesetzt. Ja. Es ist nicht die klassische Enterprise-Distribution a-la Redhat oder SuSE. Aber Du kriegst es dennoch hin.

zatarc schrieb:
Ein Link wo lediglich die Meinung des obersten Linux-Guru zelebriert wird.

Linus ist kein ZFS-Fan. Das war er noch nie und das ist auch unabhängig von irgendwelchen Lizenzfragen. Mach ich ihm das zum Vorwurf? Nein. Er hat seine Meinung dazu und die akzeptiere ich. Es macht es aber halt auch schwierig, wenn er dazu etwas sagt. Weil es halt nicht objektiv ist.

Abgesehen davon, das ich einfach nur Links hinwerfen so nach dem Motto "Sieh zu was Du daraus machst" etwas dünn finde.
Er entkräftet nicht wirklich das was ich sagte. Vielleicht übersehe ich was. Aber dann solltest Du das halt konkret darlegen.

zatarc schrieb:
Fedora war ein Beispiel. Ersetze es gegen jede andere Distro.
Der Punkt war, das Du was von Enterprise-Distro faselst und dann Fedora als Beispiel nimmst. Das passt halt nicht zusammen.

zatarc schrieb:
Ändert nichts an dem grundlegenden Problem, dass nach jedem Kernel-Update ein neues Compile-n-Pray startet.
Wie schon gesagt: Es ist ja nicht so, das Du Dir da Deinen Kernel von kernel.org ziehst und dann irgendwie hoffst, das der mit Deiner Distribution auf Deinen Maschinen funktioniert. Sondern Du benutzt eine Distribution die dann sogar noch offiziell OpenZFS-Support hat (sowas wie ubuntu; ist sogar laut Dir eine Enterprise-Distribution!!!). Da läufst Du in solche Probleme gar nicht.

Auch hier wieder das selbe wie bei Fedora. Du nimmst irgendwein obskures Beispiel und zeigst daran, wie alles krachend schief geht und das hältst Du uns dann als Beleg vor die Nase das das alles nicht funktioniert und sämtliche Pro-Argumente (ubuntu, Proxmox) werden völlig ignoriert.
Sorry. Aber wenn Du auf dem Niveau diskutieren willst, dann mach das mit Dir selbst.

zatarc schrieb:
Bist du Oracle Berater?
Ähm nein. Ich bin kein Oracle-Berater und auch kein Oracle-Fan. Ich war damals auch ziemlich erschüttert als Oracle Sun gekauft hat.
Nur lege ich kein Schwarz-Weiß-Denken an den Tag. Ich sag ja auch nicht, das Oracle die Guten sind. Ich sag ja nur: Ok. Selbst wenn man Oracle als miese Firma ansieht (Gründe genug liefern sie) stellt sich immer noch die Frage: Was kann man tun, um trotzdem Technologien wie ZFS für sich zu nutzen. Und meine Einschätzung ist: Die Kernel-Leute könnten mehr tun. Wie, habe ich dargelegt. Du konntest dem auch nicht wirklich widersprechen. So wie Du die ganze Zeit schwierigen Aspekten (die Deiner Meinung widersprechen) umgehst.

Widersprüchlich ist ja auch, das Oracle zwar hier als Bad Company gezeichnet wird aber das offenbar keine Rolle bei btrfs und deren Finanzierung durch Oracle gespielt hat. Das löst diese ganze Nummer a-la "Oracle sind die Bösen und mit den wollen wir nix zu tun haben" in Luft auf.

Für mich stellt sich die Nummer relativ einfach dar:
Linus ist technisch kein Fan von ZFS. Und die Lizenzgründe werden dazu benutzt, ob sich nicht mit den (Open)ZFS-Leuten zusammeenarbeiten zu "müssen".

PS: Bevor jetzt mir wieder irgendwas untertstellt wird a-la "Du kannst Linus nicht leiden und bist doch Oracle-Berater"
Ich schätze Linus Torvalds als Entwickler der auch wirklich was auf dem Kasten hat und den ich respektiere. Es gibt aber ein paar Punkte, da bin ich nicht mit ihm eine Meinung. Und daran finde ich auch nix verwerfliches. Ich hab manchmal das Gefühl, Linus wird als so eine Art Godfather of Linux gesehen und allem was er sagt wird einfach blind gefolgt ohne das zu reflektieren.
Deswegen finde ich es auch nicht gut, wenn irgendwelche Torvalds-Zitate als Argumente gebracht werden. Argumente sollten stechen, weil sie inhaltlich gut sind und nicht weil sie von Linus (oder einem anderen Guru) kommen.


Salamimander schrieb:
Endlich wirst du konkret! Ja, es gibt da Vorgaben. Ja ich kenne sie. Du solltest dich aber selbst fragen: Gibt es diese Vorgaben, weil es Sinn macht oder gibt es diese Vorgaben, weil da viele „Berater“ beraten haben?
Ja. Darüber kann man wirklich streiten. Diese ganzen SLAs sind zwar ganz nett, aber werden auch teilweise massiv überschätzt. Ein maßgeblichen Aspekt hast Du ja bereits genannt. Der war so sinngemäß, das man jemand durchs Telefon ziehen kann wenn was nicht läuft.
Aber allein davon gehen ja Deine Probleme nicht weg. Was man ja haben will sind Lösungen. Und in vielen Fällen kriegt man die ja durchaus auch. Aber wenn es ein tiefgreifendes Problem ist dann kann man da (zumindest auf die Schnelle) nix machen und dann nützt Dir auch kein SLA mit garantierten 24h Service nix.

Das erinnert mich so ein bisschen an diese Kapitallebensversicherungen mit Garantiezins. Garantie klingt ja so schön verlässlich. Das kann allerdings halt nur klappen, wenn der Markt diesen Zinssatz auch her gibt. Und z.B. im Zuge der Finanzkrise hat man ja schön gesehen was im Zweifel solche Garantien wert sind.

Nichtsdestotrotz kommt man in solchen Bereichen nicht ohne Vorgaben und ohne Service/Support aus.
Der Punkt ist (aus meiner Sicht) gar nicht, das man solche Sachen überhaupt nicht braucht. Der Punkt ist: Man kann diese Sachen auch kriegen ohne zu einer der typischen Enterprise Distributionen zu greifen (gerade Debian was ja in der Wirtschaft sehr viel vorkommt) beweist das ja.

Das war ja auch immer so mit das Ding das bei Linux so mitschwingt. Bei Windows wurde immer der Vorwurf gemacht, das man total abhängig von Microsoft ist. Windows kommt von Microsoft. Der Support kommt von Microsoft. Alles was irgendwie mittelbar und unmittelbar mit Windows zu tun hat ist von Microsoft abhängig.

Linux bricht das auf. Weil Du hast nicht mehr DEN einen Hersteller. Du hast nicht mehr DIE eine Möglichkeit Support zu bekommen. Du kannst das System nehmen und ganz exakt auf Deine individuellen Bedürfnisse zuschneiden. Und wenn Dir das Produkt oder der Supporter nicht gefällt, kannst Du wechseln. Klar solche Wechsel sind nicht völlig schmerzfrei aber es ist überhaupt erst mal möglich was vorher bei Windows gar nicht ging.

Und dann gehst Du hin und kaufst RHEL und den Support von Redhat und betreibst das auch alles redhat-vorgabegemäß, weil Dir sonst Dein SLA wegbröselt.
Ähm ja. Irgendwie hat sich ja dann doch nicht wirklich viel geändert. :-)
 
  • Gefällt mir
Reaktionen: foo_1337 und Salamimander
Danke, du sprichst mir da aus der Seele. Ich schaffe es nur nicht so viel Zeit in die Beiträge zu stecken :D

Im übrigen stelle ich nicht alle Vorgaben grundsätzlich in Frage (das wirfst du mir auch nicht vor, ich will das nur dem Rest klar machen), sondern weise darauf hin, das nicht immer alles so Sinn macht. Wer sich mal mit ISO27001 bzw ISO27002 auseinander setzt, bekommt Haarausfall und weis dann genau, was ich meine :)
 
Salamimander schrieb:
Wer sich mal mit ISO27001 bzw ISO27002 auseinander setzt, bekommt Haarausfall und weis dann genau, was ich meine
You had me at ISO ;)
EDV steht ja für Ende der Vernunft und nirgends manifestiert sich das so großartig, wie in dem ganzen ISO-Kram.
Man muss aber auch sagen, das die Prozesse in Firmen teilweise so miserabel ist das selbst dies immer noch besser ist, als gar keine Baseline zu haben.

Die Tragödie die darin liegt ist halt, das genauso wie das solche Firmen halt hochzieht, es gute Unternehmen runterziehen kann. Weil es dann plötzlich anfängt nicht mehr um die Sache zu gehen, sondern man seine Energie dafür braucht irgendwelche Compliances zu erfüllen.

Meiner Erfahrung nach gibts kaum jemand, der mit Absicht schlechte Arbeit abliefert. Am besten funktioniert es, was Du ein gutes Team zusammenstellst und denen dann auch wirklich den Raum gibst ihre Arbeit ordentlich zu erledigen. Häufig ist diese Voraussetzung schon nicht erfüllt und die daraus resultierenden Probleme werden dann versucht mit ISOschießmichtot und Co zu fixen und das klappt dann natürlich nicht so gut.

Wie gesagt. Ganz ohne Vorgaben geht es nicht. Wenn ich ein Kinderspielzeug kaufe, will ich mich darauf verlassen können das sich die Kleinen daran nicht verletzten. Wenn ich auf eine Leiter steige will ich darauf vertrauen können, das die nicht einfach zusammenbricht weils ne Fehlkonstruktion ist. Ich bin froh das Balkone eine Brüstung haben und das nicht nur weil es architektonisch passt oder der Erbauer zufällig daran gedacht hat, das das vielleicht doch sicherer wäre, sondern weils ne beschissene Vorschrift dafür gibt.
Ich denke, Du siehst das ähnlich. Mich treibt aber die gleiche Sorge wie Dich um. Das es da draußen halt auch genug Leute gibt, die das in nen falschen Hals kriegen und denken die haben es da mit einem F**k-the-rulez-Arnacho zu tun. :-)
 
Salamimander schrieb:
Aus Erfahrung kann ich sagen: macht Sinn.

Vor allem wenn man nicht 0815-Hardware einsetzt, sondern spezielle Hardware - sorry muss jetzt sein: Enterprise-Hardware. Beispiel: HPE DL380/DL560 Server. Dort haben wir schon viele ... spezielle ... Dinge gesehen, die wir nur mit Support klären konnten. Es geht hier nicht um Bedienungssupport, sondern um rein technischen Support (a.k.a. "Firmware Update XY zerstört HBA-Controller" oder "AMSD crasht das System"), den man bei HPE nur mit unterstützten Betriebssystemen bekommt (nur RHEL, SLES oder Ubuntu). Das sind alles so Vendor-spezifische Sachen, die du mit keiner Community-Distro supportet kriegst und auch keine Infos dazu in irgendeinem Forum findest.
 
Zuletzt bearbeitet von einem Moderator:
Komisch, unser HP Support ist nicht an das OS gebunden, denen ist da völlig Wurst ob da Debian, CentOS, Windows oder Nutanix (Also der AHV) drauf läuft.
 
  • Gefällt mir
Reaktionen: foo_1337
andy_m4 schrieb:
Du kriegst Support von Redhat für Redhat Linux und von Canonical für ubuntu. Du kriegst kein Support von Debian für Debian. Das ist korrekt. Aber das bedeutet nicht, das Du generell kein professionellen Support für Debian kriegst. Eine ganze Reihe an Firmen widmen sich dem Support-Geschäft.
Dann versuch mal Support* für z.B. HPE Server (Marktführer) für Debian zu bekommen:
https://techlibrary.hpe.com/us/en/enterprise/servers/supportmatrix/index.aspx
Hoppla, bestimmt nur eine Ausnahme!

Schauen wir mal bei Dell:
https://www.dell.com/support/conten...source-center/server-operating-system-support
Na sowas.

Huawai machts ein bisschen komplizierter:
https://support-it.huawei.com/ftca/en/product/rack-server
(Spoiler: kein Debian)

* Support im Sinne: Stellen Treiber, Software und Firmware-Updates für dieses OS zu Verfügung und unterstützen dies auch. JA Firmware-Updates sind z.B. bei HPE OS-abhängig! Die werden mit proprietärer Software eingespielt. Sowas rufst du nicht auf Debian auf und hoffst, dass es klappt.

andy_m4 schrieb:
Abgesehen davon, das ich einfach nur Links hinwerfen so nach dem Motto "Sieh zu was Du daraus machst" etwas dünn finde.
Er entkräftet nicht wirklich das was ich sagte. Vielleicht übersehe ich was. Aber dann solltest Du das halt konkret darlegen.
Zusammengefasst: GPLv2 und CDDL sind nicht kompatibel. Beide verletzten sich gegenseitig. Die konkreten und realistischen Befürchtungen sind: Oracle könnte Firmen verklagen, die Linux kommerziell vertreiben. Wenn ZFS in den Upstream kommt, dann automatisch irgendwann auch bei Red Hat und SuSE usw. Diese Unternehmen wären von Oracle angreifbar. Gerade Red Hat (IBM) wäre ein idealer Kandidat für Oracle.

Sollten sie das wirklich tun, wäre das ein Horrorszenario für Linux und für alle, die Linux in kommerziellen Produkten vertreiben. Der Kernel wäre "vergiftet".

Aus dieser Sicht verstehe ich komplett, dass Linus ZFS erst aufnimmt, wenn Oracle entweder schriftlich bestätigt: "das ist ok" oder den Code relizensiert. Beides tut Oracle nicht.

Ubuntu geht hier seinen eigenen Weg und ist der Meinung, dass sie juristisch nicht angreifbar wären. Deren Meinung. Andererseits ist Ubuntu zu klein für Oracle.


andy_m4 schrieb:
Der Punkt war, das Du was von Enterprise-Distro faselst und dann Fedora als Beispiel nimmst. Das passt halt nicht zusammen.


Wie schon gesagt: Es ist ja nicht so, das Du Dir da Deinen Kernel von kernel.org ziehst und dann irgendwie hoffst, das der mit Deiner Distribution auf Deinen Maschinen funktioniert. Sondern Du benutzt eine Distribution die dann sogar noch offiziell OpenZFS-Support hat (sowas wie ubuntu; ist sogar laut Dir eine Enterprise-Distribution!!!). Da läufst Du in solche Probleme gar nicht.

Auch hier wieder das selbe wie bei Fedora. Du nimmst irgendwein obskures Beispiel und zeigst daran, wie alles krachend schief geht und das hältst Du uns dann als Beleg vor die Nase das das alles nicht funktioniert und sämtliche Pro-Argumente (ubuntu, Proxmox) werden völlig ignoriert.
Sorry. Aber wenn Du auf dem Niveau diskutieren willst, dann mach das mit Dir selbst
Nochmal. Fedora war nur ein Beispiel und ist alles andere als obskur.

Du willst ein Beispiel aus der Enterprise-Welt? Ok:
https://access.redhat.com/errata/#/?q=kernel&p=1&sort=portal_publication_date desc&rows=100&portal_product=Red Hat Enterprise Linux&portal_product_version=7&portal_architecture=x86_64

Hier hast du alle Kernel-Updates von RHEL 7, von Release bis heute. Die Anzahl wird bald vierstellig. Stand heute müsstest du nach jedem Update das ZFS-Modul neu kompilieren und hoffen, dass die Community von ZFS und die Red Hat Entwickler nichts kaputt gemacht haben oder Inkompatibilitäten eingebaut haben. Der von Red Hat gepflegte Kernel hat es da in sich. Ist noch ein 3.10er Kernel, der dennoch ständig Backports vom Upstream bekommt (hauptsächlich Treiber, Bugfixes und Security-Fixes).

Du würdest in dieser Situation ernsthaft von einem Enterprise-fähigem Einsatz von ZFS reden? Würdest du sowas ein einer Umgegung mit einer vierstelligen Anzahl von Servern persönlichen verantworten wollen? "Wird schon laufen" und falls es Probleme gibt, gibts ja ein OpenZFS Forum?

andy_m4 schrieb:
Die Kernel-Leute könnten mehr tun. Wie, habe ich dargelegt. Du konntest dem auch nicht wirklich widersprechen. So wie Du die ganze Zeit schwierigen Aspekten (die Deiner Meinung widersprechen) umgehst.
Was sollen sie denn tun? Den ZFS-Code komplett reimplementieren? Und dann trotzdem auf Gnade Oracles hoffen, weil sie ja offensichtlich kopiert haben (nichts anderes hat Google gemacht und einen jahrelangen Rechtsstreit geführt)
Oder mehr bei Oracle um eine Relizensierung bitten?
Oder was stellst du dir konkret vor?

andy_m4 schrieb:
Nichtsdestotrotz kommt man in solchen Bereichen nicht ohne Vorgaben und ohne Service/Support aus.
Der Punkt ist (aus meiner Sicht) gar nicht, das man solche Sachen überhaupt nicht braucht. Der Punkt ist: Man kann diese Sachen auch kriegen ohne zu einer der typischen Enterprise Distributionen zu greifen (gerade Debian was ja in der Wirtschaft sehr viel vorkommt) beweist das ja.
Ich habe dir ja schon die Hardware-Beispiele genannt. Das ganze Spiel können wir jetzt noch mit Branchensoftware weiterspielen, die typischerweise nur RHEL oder SLES supporten.
 
„Branchensoftware“

Übersetzt: „Wir haben kein KnowHow und kaufen deshalb ein“. Klar, kann man machen, machen viele. Ist ein einer der Gründe warum der Ruf der deutschen Industrie beim Thema Digitalisierung so klasse ist. Es ist eine Businessentscheidung am Ende, sagt aber WEITERHIN nichts über die Professionalität oder Sicherheit eines OS aus.
 
Salamimander schrieb:
Komisch, unser HP Support ist nicht an das OS gebunden, denen ist da völlig Wurst ob da Debian, CentOS, Windows oder Nutanix (Also der AHV) drauf läuft.
Ich rede von HPE, nicht HP.
Ergänzung ()

Salamimander schrieb:
„Branchensoftware“

Übersetzt: „Wir haben kein KnowHow und kaufen deshalb ein“. Klar, kann man machen, machen viele. Ist ein einer der Gründe warum der Ruf der deutschen Industrie beim Thema Digitalisierung so klasse ist. Es ist eine Businessentscheidung am Ende, sagt aber WEITERHIN nichts über die Professionalität oder Sicherheit eines OS aus.
Ja genau. Du hast die Welt verstanden. Also implemtentiert jetzt jede Bank oder Versicherung seine eigene Logistik-Software für die interne Lagerverwaltung? Ist ja genau deren Geschäftsfeld.

Tausche Logistik-Software gegen jede beliebige Back-Office-Software/ERP-Software die jedes große Unternehmen braucht
 
zatarc schrieb:
Aus Erfahrung kann ich sagen: macht Sinn.

Vor allem wenn man nicht 0815-Hardware einsetzt, sondern spezielle Hardware - sorry muss jetzt sein: Enterprise-Hardware. Beispiel: HPE DL380/DL560 Server. (...) Das sind alles so Vendor-spezifische Sachen, die du mit keiner Community-Distro supportet kriegst und auch keine Infos dazu in irgendeinem Forum findest.
Ich bin jetzt mal arschig. Die HP(E) DL, insbesondere 360/380 sind Brot und Butter 0815 HW. Wir haben den Kram schon genutzt als da noch Compaq drauf stand. Darauf läuft bzw. lief in all den Jahren schon:
FreeBSD 3.x - 13 (seit vielen Jahren mit dem bööööösen ZFS)
Ubuntu seit 06.10
Debian seit Sarge
RedHat Linux 7 (nein, nicht RHEL) - RHEL 8, respektive CentOS und jetzt halt OEL
OpenBSD 4-7
ESX(i) 3-7.0
Inbesondere die CCISS Controller waren immer Top und ein Grund auf Compaq^WHP^WHPE zu setzen. Es tut mir leid das zu sagen, aber anstatt auf irgendwelchen bescheuerten Support zu setzen, setzen wir auf fähige Mitarbeiter. RHEL nutze ich wenn es nicht anders geht. Die Gründe sind: Oracle RDBMS oder der Kunde will es so. Den RedHat Support habe ich noch nie angerufen. Den von HP auch nur dann, wenn irgendein Bauteil defekt ist. Wenn ihr das nicht auf die Reihe bekommt ist das ja ok, dafür gibt es den Vendor support. Aber bitte verallgemeinere das nicht. Danke.
 
  • Gefällt mir
Reaktionen: andy_m4
foo_1337 schrieb:
Ich bin jetzt mal arschig. Die HP DL, insbesondere 360/380 sind Brot und Butter 0815 HW. Wir haben den Kram schon genutzt als da noch Compaq drauf stand. Darauf läuft bzw. lief in all den Jahren schon:
FreeBSD 2.x - 13 (seit vielen Jahren mit dem bööööösen ZFS)
Ubuntu seit 06.10
Debian seit Sarge
RedHat Linux 7 (nein, nicht RHEL) - RHEL 8, respektive CentOS und jetzt halt OEL
OpenBSD 4-7
ESX 3-7.0
Inbesondere die CCISS Controller waren immer Top und ein Grund auf Compaq^WHP^WHPE zu setzen. Es tut mir leid das zu sagen, aber anstatt auf irgendwelchen bescheuerten Support zu setzen, setzen wir auf fähige Mitarbeiter. RHEL nutze ich wenn es nicht anders geht. Die Gründe sind: Oracle RDBMS oder der Kunde will es so. Den RedHat Support habe ich noch nie angerufen. Den von HP auch nur dann, wenn irgendein Bauteil defekt ist. Wenn ihr das nicht auf die Reihe bekommt ist das ja ok, dafür gibt es den Vendor support. Aber bitte verallgemeinere das nicht. Danke.
Draufen laufen != supportet.

Ich musste schon eine zweistellige Anzahl von Tickets bei HPE auf machen weil deren Dreckstool "HPSUM" oder mittlerweile nur noch "SUM" verbuggter Mist ist. Das Problem bei HPE ist tatsächlich deren Software zum managen der Server. SUM ist proprietäre Software. Was machst du denn da, wenn die nicht funktioniert? In deren Forum schreiben und sehen, wie es ignoriert wird?
Oder was machst du, wenn iLO Fehler hat?
 
zatarc schrieb:
Draufen laufen != supportet.
Wie gesagt: Es interessiert mich nicht, was "supported" ist oder nicht. Wir supporten uns selbst.

zatarc schrieb:
Ich musste schon eine zweistellige Anzahl von Tickets bei HPE auf machen weil deren Dreckstool "HPSUM" oder mittlerweile nur noch "SUM" verbuggter Mist ist. Das Problem bei HPE ist tatsächlich deren Software zum managen der Server. SUM ist proprietäre Software. Was machst du denn da, wenn die nicht funktioniert?
Ganz einfach: Ich benutze sowas nicht. Egal ob von HP, Dell oder Supermicro (gut, die haben sowas eh nicht).

zatarc schrieb:
Oder was machst du, wenn iLO Fehler hat?
Was für Fehler? Defekt? Dann kommt jemand vorbei und repariert den Kram. Hier hat noch niemand gefragt, welches OS darauf läuft. Das geht den HW Support auch nichts an, der sieht eh nichts davon.
 
foo_1337 schrieb:
Wie gesagt: Es interessiert mich nicht, was "supported" ist oder nicht. Wir supporten uns selbst.


Ganz einfach: Ich benutze sowas nicht. Egal ob von HP, Dell oder Supermicro (gut, die haben sowas eh nicht).
Ahja? Ihr macht also nie Firmware-Updates? Vertrauenserweckend!
foo_1337 schrieb:
Was für Fehler? Defekt? Dann kommt jemand vorbei und repariert den Kram. Hier hat noch niemand gefragt, welches OS darauf läuft. Das geht den HW Support auch nichts an, der sieht eh nichts davon.
iLO hat ständig Bugs. Meldet irgendwelche (falschen) Hardware- oder Netzwerkfehler, die bei uns dann automatisch Tickets erstellen und Leute aufscheuchen oder in blöden Fällen werden Leute nachts herausgeklingelt.
Wie supportet man sowas denn selbst? In Zukunft die gemeldeten Hardwaredefekte von iLO einfach ignorieren?!
 
zatarc schrieb:
Ahja? Ihr macht also nie Firmware-Updates? Vertrauenserweckend!
Ich hoffe dir ist bekannt, dass man dafür nicht SUM benötigt?

zatarc schrieb:
In Zukunft die gemeldeten Hardwaredefekte von iLO einfach ignorieren?!
Korrekt. iLO ist für uns ausschließlich KVM, wenn es denn mal gebraucht wird. Die restliche Sensorik wird direkt im OS abgefragt und die Metriken gehen ans Monitoring, was dann ggf. Alerts erzeugt. Da unsere Setups jedoch build to fail sind, wird niemand nachts rausgeklingelt, wenn irgendwo ein Lüfter oder PSU oder eben eine ganze Kiste ausfällt.

Blech ist Blech - ich will hier so wenig Vendor spezifische abhängigkeit wie möglich haben. Wenn mir HPE morgen keinen Server liefern kann, der meinen Vorstellungen entspricht, nehme ich einen von Dell. Wenn ich dafür dann meine Infrastruktur umbauen müsste, hätte ich ein riesen Problem.
 
foo_1337 schrieb:
Ich hoffe dir ist bekannt, dass man dafür nicht SUM benötigt?
Es gibt bei HPE keine andere Möglichkeit.
Entweder online, SUT oder die SPP-ISO. Alle 3 Wege rufen intern smartupdate auf (SUM).
foo_1337 schrieb:
Korrekt. iLO ist für uns ausschließlich KVM, wenn es denn mal gebraucht wird. Die restliche Sensorik wird direkt im OS abgefragt und die Metriken gehen ans Monitoring, was dann ggf. Alerts erzeugt. Da unsere Setups jedoch build to fail sind, wird niemand nachts rausgeklingelt, wenn irgendwo ein Lüfter oder PSU oder eben eine ganze Kiste ausfällt.
OS-Monitoring ist das eine; bringt dir aber nichts, wenn auf der Hardware z.B. Software-Appliances laufen. Dort ist das OS eine Blackbox und du hast nichts anderes als iLO als Hardware-Monitoring.
 
zatarc schrieb:
Es gibt bei HPE keine andere Möglichkeit.
Entweder online, SUT oder die SPP-ISO. Alle 3 Wege rufen intern smartupdate auf (SUM).
Früher via scexe, heute via rpm2cpio und ./hpsetup. Und im BSD Fall halt via iLO oder SPP-ISO. Insbesondere die letzten beiden Varianten haben wieder mal nichts damit zu tun, ob das OS was läuft, supported wird. Und genau darum geht es doch hier die ganze Zeit?

zatarc schrieb:
OS-Monitoring ist das eine; bringt dir aber nichts, wenn auf der Hardware z.B. Software-Appliances laufen. Dort ist das OS eine Blackbox und du hast nichts anderes als iLO als Hardware-Monitoring.
Ich spreche davon, dass ich keine unterstützte Linux "Enterprise Distro" brauche. Du sagst, dass du die wegen des Supports brauchst. Und jetzt kommst du mit Appliances um die Ecke? Was unterstützt HPE denn da so? ESXi unter anderem, aber auch da kannst du den Kram aus dem OS Monitoren.
 
foo_1337 schrieb:
Früher via scexe, heute via rpm2cpio und ./hpsetup. Und im BSD Fall halt via iLO oder SPP-ISO. Insbesondere die letzten beiden Varianten haben wieder mal nichts damit zu tun, ob das OS was läuft, supported wird. Und genau darum geht es doch hier die ganze Zeit?
Doch. Wenn du einen Fehler hast und du auf einer unsupporteten Platform unterwegs bist, dann bist du auf dich anleine gestellt. Das gilt auch für das manuelle Ausführen der hpsetup-Scripte. Ist nicht supportet.
foo_1337 schrieb:
Ich spreche davon, dass ich keine unterstützte Linux "Enterprise Distro" brauche. Du sagst, dass du die wegen des Supports brauchst. Und jetzt kommst du mit Appliances um die Ecke? Was unterstützt HPE denn da so? ESXi unter anderem, aber auch da kannst du den Kram aus dem OS Monitoren.
Wir brauchen es wegen dem Support und weil es u.a. einen gesetzliche Vorgabe der BaFin ist. Du kriegst auch keine ISO-Zertifizierung wenn du Produktionssysteme ohne Enterprise-Support betreibst - ob du es für sinnvoll hälst oder nicht.
Und ja, Appliances. Dort übernimmt der Hersteller der Software-Appliances den Support der Hardware. Unter anderen dadurch, dass er selbst nur unterstützte OSes einsetzt. Trotzdem willst du die ja irgendwie monitoren. Das kann ja schlecht der Hersteller tun.
 
zatarc schrieb:
Doch. Wenn du einen Fehler hast und du auf einer unsupporteten Platform unterwegs bist, dann bist du auf dich anleine gestellt. Das gilt auch für das manuelle Ausführen der hpsetup-Scripte. Ist nicht supportet.
Wie gesagt: Das nehme ich gerne in Kauf. Wir wissen uns zu helfen ;)
zatarc schrieb:
Du kriegst auch keine ISO-Zertifizierung wenn du Produktionssysteme ohne Enterprise-Support betreibst - ob du es für sinnvoll hälst oder nicht.
Diese Aussage ist schlicht falsch bzw. von welcher ISO Zertifizierung sprechen wir?. Ein funktionierendes ISMS setzt sowas in keiner Weise voraus. Es setzt nur voraus, dass du deinen Kram im Griff hast. Eine Firma, die ausschließlich Open Source Produkte einsetzt kann dennoch ohne weiteres eine Zertifizierung erhalten.
zatarc schrieb:
Und ja, Appliances. Dort übernimmt der Hersteller der Software-Appliances den Support der Hardware. Unter anderen dadurch, dass er selbst nur unterstützte OSes einsetzt. Trotzdem willst du die ja irgendwie monitoren. Das kann ja schlecht der Hersteller tun.
Ok, da haben wir wohl eine unterschiedliche Vorstellung von Appliances. Aber da die mittlerweile ohnehin immer mehr als VM laufen, ist das Thema Monitoring in dem Fall eh obsolet ;)
 
Zuletzt bearbeitet von einem Moderator:
Zurück
Oben