Mozilla will Firmen doch nicht vernachlässigen

Da die Mozilla Foundation ihren Browser Firefox inzwischen in deutlich kürzeren Abständen aktualisiert, kommt die Software für viele Unternehmen nicht mehr in Frage, da der Aufwand zu groß wäre, so oft einen neuen Browser zu installieren und zu ... mehr... Browser, Logo, Firefox, Mozilla Bildquelle: Mozilla Browser, Logo, Firefox, Mozilla Browser, Logo, Firefox, Mozilla Mozilla

Diese Nachricht vollständig anzeigen.

Jetzt einen Kommentar schreiben
 
Diese Überschrift "...doch nicht vernachlässigen". Davon war doch nie die Rede. Das Gefühl kam bei den Firmen nur dadurch zu Stande, da bisher auf das Problem des schnelleren Releasezyklus nicht wirklich eingegangen wurde. Die jetztige Lösung mit den Diskussionsgruppen finde ich persönlich sehr gut gelöst, da die Probleme genau erörtert werden können und die Firmen nicht wieder lediglich mit Beschlüssen konfrontiert werden.
 
@Mister-X: Sicher war davon die Rede. Der gute Asa Dozer hat wortlich geschrieben:
Enterprise has never been (and I’ll argue, shouldn’t be) a focus of ours.
und weiter: I’d much rather Mozilla spending its limited resources looking out for the billions of users that don’t have enterprise support systems already taking care of them.
http://mike.kaply.com/2011/06/23/understanding-the-corporate-impact/#comment-10598
 
@Andy74: Für mich macht das aber einen Unterschied, ob ich klarstelle, dass eine Zielgruppe von vornherein nie fokusiert wurde oder ob ich sie vernachlässige.
 
@Mister-X: Das beste an der Geschichte: Wenn die nicht so einen beknackten Release-Zyklus hätten gäbe dieses Problem gar nicht. Außerdem hab ich das so verstanden, dass sie Hilfe geben wenn eine neue Version erschienen ist. Von einem Mitspracherecht für zukünftige Versionen lese ich nichts. Scheint also, als ob Unternehmen weiterhin vor vollendete Tatsachen gestellt werden und den Updates hinter Testen dürfen und sie lediglich dabei Hilfe bekommen. Ich weiß nicht ob ich mir als Admin den Aufriss machen würde.
 
@Zwulf: der Release-Zyklus ist nicht das Problem, sondern, dass mit einer neuen Version die vorigen nicht mehr unterstützt werden (z.B. Sicherheitlücken schlissen). Alles was die Firmen brauchen ist eine LTS-Version
 
@Mister-X: Firmen "doch nicht vernachlässigen" hört sich eher so an als hätte jemand Mozilla den Rücken gekehrt (große Firma) und die haben plötzlich rausgefunden dass bei freien Projekten oft von Firmen das Geld kommt... Klarer Fall von Winfuture-Überschrift. Ich bin nur rein weil ich dachte hier gibts n Flamewar.
 
Schön das sich die Browser auch im Business sich weiterhin gegenseitig Konkurenz machen. Kann nicht schaden.
 
Warum sind die kürzeren Abstände der Aktualisierungen bei Firefox ein Problem und bei anderen Browsern wie z.B. Chrome nicht? Und MS läßt diese doch in ihre regelmäßigen Sicherheits-Updates / Windows Updates einfließen, auch öfters! Gilt bei Chrome und IE "...so oft einen neuen Browser zu installieren und zu testen. Die Gefahr, dass benötigte Add-Ons oder interne Websites nicht mehr funktionieren, besteht mit jedem Update...." das nicht und nur bei Firefox ist das ein Problem?
Verstehe ich nicht.
 
@Uechel: weil firefox stärker auf addons setzt die bei einer neuen version eventuell nicht mehr funktionieren. chrome spielt im business bereich bisher eine geringere rolle. Die sicherheitsupdates bei IE sind meisten keine tiefen eingriffe in den browser
 
@DNFrozen: Das müssen nicht mal unbedingt Addons sein, hier reichen schon einfache Webseiten, die eventuell nicht mehr funktionieren. Ich sehe das bei uns, da funktionierten nach der Umstellung von Firefox 3.x auf 4 bzw. 5 einige Skripte nicht mehr so wie vorher, einfach weil da im Firefox irgendwas geändert wurde. Dasselbe übrigens auch von IE8->9.
 
@dodnet: das liegt aber wohl daran, dass diese Seiten dreckig programmiert sind und sich nicht 100%tig an die Standards halten...
Schon allein bei Javascript zicken manche Browser rum, weil man die schönen semikolons nie reinbaut (zu Opera rüberwink).
Das sind so kleine Programmierfehlerchen, die keiner kennt, weil die Seite auch mit diesen Fehlern wunderbar klappt, aber kommt mal eine neue Browserversion, die zum Beispiel pingeliger ist, so kanns dann leider schonmal vorkommen, dass der Code nicht mehr funktioniert.
Finde es eh schade, dass die Browser so viele Fehler zulassen... :(
 
@Ninos: Naja, das Problem bei Webseiten/Skripten ist ja oft, dass es keine richtigen Standards gab oder gibt bzw. die von jedem Browser anders verarbeitet werden. Auch wenn die Unterschiede zum Teil nur sehr klein sind, hat das manchmal fatale Folgen. Spitzenbeispiel immer noch der IE, der Elendsbrowser :D
 
@dodnet: das stimmt auch immer, finds halt schade, dass man bei den "Programmiersprachen", welche für den Browser bestimmt waren, nicht von Anfang an sich an eine Richtlinie gehalten hat.. :(
Naja, was sollen wir tun, schon vorbei :D
 
@DNFrozen: Es geht weniger darum, worauf *Firefox* setzt, sondern vielmehr darum, was man als Unternehmen nutzen kann. Beispiel VMware: die haben ein riesiges Plugin-Paket für den Firefox (> 20MB), mit dem man eine VM direkt im Browser laufen lassen kann. Das geht dann natürlich nur mit genau DIESER Versionfamilie (zB 3.6.x), aber was ist mit 4.x, 5,x, oder gar 6, 7, 8, etc? Momentan ist Nightly = 8, vor ~ 6 Monaten war Nightly noch 4. Viele Unternehmen setzen auf Virtualisierung, ein großer Teil derer auf die VMware-Infrastruktur. Keine dieser Firmen *kann* auf Mozilla setzen, selbst wenn sie's wollten - das Ausfallrisiko ist einfach zu groß.
 
@Uechel: Weil in Firmen oft verschiedene Programme erst mit neuen Browser-Versionen getestet werden müssen. Wenn das nur Patches wie bei IE sind, die Funktionalität aber gleich bleibt ist das i.d.R. kein Problem. Wenn aber bei jedem Patch neue Funktionen dazukommen, kann das keiner mehr sinnvoll testen.
 
@Uechel: Kennst Du ein Großunternehmen, das Chrome einsetzt? (Würde mit größter Sicherheit schon an Googles laxem Datenschutz scheitern...)
 
@Uechel: Es geht um Stabilität, und der /Garantie/ auf Stabilität. Bei Mozilla heißt das insbesondere auch API-Stabilität (für add-ons und Plug-Ins) bzw zu erwartende Unterstützung von Webstandards (oder vielleicht besser gesagt, eine sich nicht verändernde Unterstützung derselben). DAZU kommt dann noch eine stabile Benutzerschnittstelle - damit die Angestellten nicht alle paar Wochen wie ein Idiot vor nem neuen Interface sitzen und sich fragen, wie geht das denn jetzt? All das treibt die Produktivität in die Knie, wenn man sich als Unternehmen nicht auf Stabilität verlassen kann -- und Mozilla's neuer "Releasezyklus" gefährdet dies nicht nur, sondern schmeißt es explizit über Bord. Tja und da bei jedem neuen Release das vorhergehende End-of-Life gesetzt wird, wäre man schön blöd, wenn man nach sechs oder so Wochen Einarbeit seine Erkenntnissse alle über Bord werfen müßte - denn dann ist die aktuelle Ausgabe vom Tisch und man müßte sich in die nächste einarbeiten. Das macht natürlich keiner. Umso lustiger, da es die *Unternehmen* sind, die Mozilla erst zu dem gemacht haben, was sie sind - nicht zuletzt durch finanzielle Unterstützung und IIRC war IBM da ganz vorne mit dabei - also diejenigen, die jetzt von Mozilla diesen Korb bekamen. Aus demselben Grund (nehm ich mal an) werden Unternehmen auch kein Google Chrome einsetzen - es sei denn, es gibt noch ne Langzeit-Support-Version von der ich nichts weiß. Ganz anders bei Microsoft; der IE6 wird, wenn ich nicht irre, nach wie vor unterstützt *obwohl* Microsoft alles tut, um ihn loszuwerden.
 
Ok! Ok! Ich verstehe, da gibt es Probleme. Zu den Antworten: Ob Chrome gewerblich genutzt wird, kann ich nicht beurteilen. Das Problem scheint mir aber mit Firefox doch sehr ähnlich. Ob Sicherheitsupdates bei IE meistens keine tiefen Eingriffe in den Browser darstellen mag sein, aber dennoch sollte wohl jeder Eingriff schon aus Sicherheitsgründen firmenseitig geprüft werden oder verläßt man sich auf MS, dann wäre man manchmal aber verlassen, wie Sicherheitslücken oder Änderungen von IE 8 zu 9 zeigen. Aber ich bekenne, ich habe das wohl auch als "Privat-User" zu vereinfacht gesehen.
 
@Uechel: In vielen Firmen werden auch einzelne Patches erstmal getestet, bevor sie eingespielt werden. Allerdings wird da oft nur geprüft ob ein Beispiel-System mit dem Patch Probleme hat. Bei einer komplett neuen Version z.B. IE8->9 sind die Tests dann viel weitreichender und umfangreicher. Das kann dann lange Zeit in Anspruch nehmen. Aus eben diesen Grund wird bei vielen Firmen ja auch noch "veraltete" Software eingesetzt (Windows NT, 2000, ja teilweise sogar 95/98).
 
@Uechel: Du hast schon Recht, nur ist es ohne weiteres möglich, sämtliche MS-Updates über WSUS auszurollen (oder eben auch nicht), nachdem sie geprüft wurden. (Selbst dann ist davon auszugehen, daß es keine Änderungen in der Funktionalität gibt.) Das geht bei Firefox - genauer: bei allen Mozilla-Produkten - nicht; die haben ihren eigene Update-Routine, die sich bestenfalls abschalten läßt (aber, soweit ich weiß, nicht weiter kontrollierbar ist). Den zweite Punkt sprichst Du ja schon an: Major Updates, so wie von IE8 zu -9, machen Probleme --- und hier liegt der Hund begraben, man MUSS nicht von IE8 zu 9 aktualisieren. Ganz im Gegenteil: es gibt seitens MS eigens Blocker, um eben dies zu verhindern. Alle Betriebssysteme, die momentan unterstützt werden, schließen den InternetExplorer in dieser Unterstützung ein und die Servicepacks aktualisieren den IE nicht, weswegen mit XP noch IE6, mit Vista (IIRC) IE7 unterstützt werden und das /garantiert/. Auf der anderen Seite hast Du Mozilla (und Google's Chrome), die Dir das Upgrade praktisch aufzwingen und ältere Versionen eben NICHT mehr unterstützen, sprich: mit Sicherheitsupdates versorgen. Für kritische Umgebungen - sei es sicherheits- oder produktionsbezogen- sind daher Firefox & Co. mementan strikt nicht einsetzbar.
 
Wenn ich mal nicht weiter weiß, bilde ich einen Arbeitskreis. Mal abgesehen wvon diesen ständigen Versionserscheinung, die Firmen haben gar nicht die Zeit sich ständig mit neune Versionen zu beschäftigen. Oder sollte man es einfach nur anders verkaufen? WEniger Versionen, statt dessen es als Updates verkaufen? Ist beim IE ja auch nicht anders, warum also auch nicht hier?
 
@hk12840: Weil man durch ein Release eines Firefox 7 mehr im Fokus der Öffentlichkeit steht, als mit einem Firefox 6.1.
Ausserdem will man dem google chrome nicht hinterherhinken, welche ja auch mit den Versionsnummern um sich schmeissen.
 
@hk12840: Das Problem besteht darin dass Mozilla den Support für ältere Versionen schnell einstellen will, sobald ein neues Hauptrelease da ist. Das kann z.B. heißen das eine Firma, die FF 6 auf ihren 500 Computern installiert hat, nach ein paar Monaten schon wieder neu testen und neu ausrollen muss, weil es ein neues Hauptrelease gab und der Support für die eingesetzte Version bald endet. Das ist ein nicht zu unterschätzender Aufwand zu dem man als Firma keinen Gegenwert erhält. Erschwerend kommt noch hinzu, dass Mozilla neue Features möglichst schnell an den Benutzer bringen will, eben durch diese Hauptversionen. Das ist zwar nett gemeint, aber eine Firma läuft eben so bei jedem Update Gefahr dass ihre Webanwendungen nicht mehr in der neuen Firefox Version laufen.
 
@DennisMoore: Ich arbeite selbst in einer IT Abteilung. Von daher kann ich dieses ganz gut beurteilen und bin froh das wir kein FF einsetzen. Aber mal davon abgesehen, auch der IE heißt aktuel nicht mehr IE8. Offziel ja, aber wer sich mal die Info genaueranschaut sieht dort eine andere Versionsnummer.
 
@hk12840: Das ist es ja. Beim IE mag sich die Versionsnummer ändern. Mal mehr mal weniger, mal versteckt mal nicht so versteckt. Aber es wird immer auf Kompatibiltät und Langzeitsupport geachtet. Das beweist ja geradezu die Kompatibilitätsansicht die in der aktuelleren Versionen des IE vorhanden ist. Eben das genaue Gegenteil von dem was Mozilla vorhat. Letztendlich hat das alles nicht wirklich was mit Versionsnummern zu tun und der Frage ob man die nun an erster Stelle hochzählt, an zweiter oder an dritter, sondern damit was gändert wird und was an Kompatibilität, Support und Zuverlässigkeit flöten geht.
 
Mozzila ist im Firmenbereich einfach nicht anwendbar. Das hat aber weniger mit ständig neuen Versionen zu tun. Das Problem besteht im grundliegenden Design. Stichwort Gruppenrichtlinien etc. Ein so wichtiges und auch Sicherheitsrelevantes Programm wie der Bowser MUSS global verwaltet und mit Richtlinien gesichert werden können.
 
@notme: totaler Unsinn den du erzählst. Ich weiß das der Standard Browser bei Bosch und bei Bosch Rexroth AG Mozilla ist. Ist zwar noch eine 3xx Version aber das ist ja egal. Und nun erzähl mir noch was das dieser keine Firmenbrwoser ist.
 
@J3rzy: Was erzählst du für nen Quatsch! Hier geht es nicht darum, dass Firefox eingesetzt wird, sondern darum per Gruppenrichtlinien auf einfach Art und Weise die Einstellungen in Firefox zu ändern (und gegebenenfalls für die User zu sperren), Proxy-Einstellungen vorzunehmen, etc. Die Einstellungen sind aber alle in einer Datei und nicht in der Registry unter HKLM\Software\Policies bzw. HKCU\Software\Policies. Wenn wir schon dabei sind, ne MSI von Firefox wäre dann auch wünschenswert, wenn man in Firmen gut vertreten sein will.
 
@DPX: Naja, MSI hat dann doch weniger mit "vertreten sein wollen" als mit oben genannten Sicherheitsrichtlinien bzw. Automatisierung zu tun.... darüber hinaus würde man bei Einsatz von MSI die Patches ebenfalls über MSI laufen lassen können - mit anderen Worten, die Chose wäre mit WSUS zentral verwaltbar. Deswegen wollen ja auch so viele die MSI-Unterstützung für Mozilla's Weichware, nur sieht das Mozilla halt anders - bis heute ist es ohne weiteres möglich, einfach ein ZIP-Archiv auszupacken und ein Mozilla-Programm direkt ohne Installation zu starten. Gut für den Privatanwender, ohne Frage - nur halt nicht für Unternehmen.
 
@DPX: "Die Einstellungen sind aber alle in einer Datei und nicht in der Registry.... " und das ist auch gut so, wenn man die gleiche software auf mehreren betriebsystemen anwenden will/muss/möchte. scheint also ein generelles windows "problem" zu sein, denn unter linux macht das alles die paketverwaltung über root. edit: ich halte auch das prinzip datenbank für einstellungen/konfigurationen eh für veraltet, aber das isn anderes thema :)
 
@buckliger: Naja, die DB für die Einstellungen kam ja erst '95 und hat die guten alten INI-Dateien abgelöst, von daher ist es nicht unbedingt veraltet, aber ein Blödsinn war das jedenfalls schon immer. ;)
 
@Johnny Cache: so blödsinn war das damals nicht. die festplatten waren wesentlich langsamer als heute. aber heute is das einlesen tausender konfigfiles überhaupt kein problem mehr.
 
@buckliger: Wieso tausende Configs? Normalerweise gab es genau eine einzige INI pro Programm, welches man für Multiuser auch im Userprofile hätte speichern können. Die Registry war und ist definitiv langsamer als die guten alten INIs.
 
@Johnny Cache: ... und dann kocht wieder jeder sein eigenes Süppchen und keiner hat mehr einen Plan, welches Programm was, wo, und vor allem WIE speichert. Ich find' eine zentrale Konfigationsschnittstelle schon ganz gut - und scheinbar die Macher von GNOME und KDE auch, siehe zB GConf & Co - nur mit der Kaskadierung läufts scheinbar noch nicht so ganz, ebenso wie mit der Idee der niedrigst-notwendigen Authentifizierung. Aber das ist kein Registry-Problem, eher eines der Programmierer, die derartige Paradigmen halt nicht erfüllen (oder wollen).
 
@RalphS: Zentral heißt aber eben auch single point of failure. Möchte gar nicht wissen wie oft ich Windows schon neu machen mußte nur weil es die Registry zerrissen hat. Außerdem ist es deutlich komplizierter eine Kiste neu aufzuziehen wenn man erst mal tausend Programme neu installieren und konfigurieren muß. Mit INI-Dateien kopiert man einfach und alles ist in Butter. Wobei sowas auch heute noch mit ThinApps ginge, man muß nur richtig wollen. ;)
 
@Johnny Cache: Okay, guter Punkt; allerdings kann ich das bisher der Erfahrung nach nicht bestätigen. Man muß die Registry halt nur n Ruhe lassen und nicht mit irgendwelchen "Cleaner"n bombardieren. ;o) Ich geh auf jeden Fall soweit mit, daß die derzeitige Implementierung überholt ist. Die gesamte Registry im RAM? Wozu? Wenn man das Ganze (bspw) als SQLite-Datenbank implementieren würde, wären Transaktionen, atomic writes sowie ein Journal für die Wiederherstellung (und Konsistenz) gleich eingebaut und man müßte die Datenbank nur für Zugriffe in den Speicher laden. Noch ein, zwei automatisch angelegte Backups dazu, und die Registry ist so sicher und geschützt wie sie nur irgend sein kann.
 
@Johnny Cache: 1000 war jetzt nur eine zahl, aber es kommen schon einige dateien zusammen und ungecached war das damals doch sehr langsam. und das zentrale speichern der konfigs ist eigentlich gut. unter windows leider nur nicht, eine partition für alles und so dumm blöd verschachtelt, versteckt, einfach nur grauenhaft schlecht und das bleibt auch noch so. auweia :)
 
@RalphS: aber dann is doch alles wie vorher auch: man sitzt dann verduzt vor irgentwelchen 747837637Fg3747- Einträgen und hat keine ahnung was das nun sein soll^^ in dateien kann wenigstens nen entwickler noch ne kommentarzeile einfügen oder beispiele geben.
 
@buckliger: Ach Devs. Das beste was ich bisher erlebt habe war wohl die boot.ini von EVE Online in C:, welche sie nach dem Update auch gewissenhaft entfernt haben. Hätten sie ihrer Datei bloß keinen sprechenden Namen gegeben und vielleicht in %temp% gespeichert. ;)
Kommentar abgeben Netiquette beachten!

WinFuture Mobil

WinFuture.mbo QR-Code Auch Unterwegs bestens informiert!
Nachrichten und Kommentare auf
dem Smartphone lesen.

Folgt uns auf Twitter

WinFuture bei Twitter

Interessante Artikel & Testberichte