Fusselbär
Makefile Voyeur
Ich sehe gerade beim nvidia-driver in den Ports:
Da habe ich mal gegoogelt: http://www.ballywulff.de/unternehmen/bally-wulff
Läuft FreeBSD auf Spielautomaten?
- Ersteller Fusselbär
- Erstellt am
bananenBrot
Well-Known Member
Geben die auch an warum?FreeBSD läuft inzwischen fast überall.Das ist kein Witz. Man kann beobachten, dass immer mehr Unternehmen FreeBSD statt Linux als Grundlage nehmen.
foxit
Well-Known Member
95% wegen der Lizenz. GPL gefällt einfach keiner Firma...
kmh
Well-Known Member
Naja.... ziemlich pauschale Aussage und so sicherlich falsch
Quelle?
Abgesehen von Netflix, die schon seit der Gründung 1997 FreeBSD einsetzen (damals war FreeBSD technisch noch weit voraus), ist mir in letzter Zeit nichts untergekommen.
Bitte keine Lizenzdiskussion an dieser Stelle, den meisten Firmen ist das völlig egal. Bei besagter Spieleautomaten-Firma handelt es sich aber um einen Hardware-Hersteller. Die Firma muss dank BSD ihr geistiges Eigentum nicht veröffentlichen, was bei so hochintegrierten Geräten einen Wettbewerbsvorteil darstellen dürfte.
Na du sagst es doch selbst.
lechindianer
Kritiker
Rakor sagt es doch schon - mit der GPLv3 und der Tavoisierung ist Linux für Hardware schon etwas kniffelig
Ich wollte Pauschalaussagen pro und contra BSD und GPL vorbeugen und einen konkreten Vorteil für den Hersteller in seinem Marktumfeld herausstellen.
Ansonsten bin ich natürlich immer für eine ergebnislose Grundsatzdiskussion zu haben.
foxit
Well-Known Member
Ich weiss jetzt nicht, wie das zu einer Diskussion GPL vs. BSD führen sollte, in Bezug auf diesen Fall hier aber ja den meisten Firmen ist das sicher nicht egal und vermutlich der Grund schlechthin. Netapp z.B. wird vermutlich zusätzlich an ZFS und ein paar anderen Features interessiert sein. So wie Privider an einem Einsatz als Router.
Ich kenne mehrere Personen und Unternehmen, die in dem großen Bereich "Embedded" tätig sind. Vor allem Industrietechnik. Natürlich setzt die Mehrheit nach wie vor auf Linux - Linux ist in diesem ganzen Bereich "Embedded" wohl nahe eines Monopols - oder sogar die Produkte des sympathischen Weltmarktführers aus dem sonnigen Redmont. Allerdings sind auch einige mit neuen Produkten oder Auftragsarbeiten auf eine FreeBSD-Basis gewechselt. Wenn man nach dem Wieso fragt, sind es eigentlich immer die gleichen Gründe:
- Die Lizenz. Die meisten Entwickler haben kein Problem mit der GPL2 und auch nicht mit der GPL3. Das Problem sehen sie eher darin, wie die GPL3 zustande kam. Die berüchtigte "TiVo-Klausel" hat sehr viel Vertrauen zerstört, denn sie verdeutlichte wie leicht Ideologen freie Software als politische Waffen missbrauchen können. Wer sagt, dass eine eventuelle GPL4 keine "Hans Müller Industriesoftware GmbH"-Klausel haben wird und man aufgrund der großen Verbreitung von Software aus dem direkten FSF-Dunstkreis plötzlich ohne aktualisierbaren Softwarestack darsteht? In die Kerbe schlagen z.B. auch die (juristisch natürlich völlig korrekten) Busybox-Klagen, wo man sich schon mal wegen 2 trivialen Zeilen vor'm Kadi sah oder das ständige Geschrei einige Parteien betreffend Closed Source Module für den Linux-Kernel. Natürlich hat ein Entwickler jedes Recht seine Software zu lizensieren, wie er möchte und auch diese Lizenz durchzusetzen. Aber umgekehrt haben Anwender auch das Recht Software aufgrund ihrer Lizenz und der Durchsetzung der Lizenz nicht mehr zu nutzen.
- POLA, auch als "Frickelfaktor" bekannt. Im Linux-Umfeld gibt es nur eine einizige ABI / API, die dauerhaft kompatibel ist. Ja sogar erstaunlich kompatibel, kompatibler als bei den BSDs. Das Interface zwischen dem Linux-Kernel und seinem Userland. Alles andere ist in einem beständigen Fluss. Es hat sicherlich seine Vorteile, aber wenn man ein proprietäres Produkt über 10 oder vielleicht sogar 20 Jahre warten will, wird es zu einem großen Problem. Ein heute geschriebenes Modul für den Linux-Kernel wird sich schon in zwei Jahren sehr weit von der Realität der dann aktuellen Kernel entfernt haben. Kernelupgrades sind daher in einem solchen Fall mit einem enormen Aufwand verbunden, teilweise nahezu unmöglich. Umgekehrt kann man ältere Kernel auch nur sehr eingeschränkt selbst weiterpflegen. (Free)BSD hat diese Probleme nicht. Auch dort muss man über die Zeit Anpassungen an seinen Kernelmodulen vornehmen, aber der Aufwand hält sich zumeist in Grenzen. Zudem ist es relativ problemlos möglich, aktuelle Änderungen in ältere Branches zurückzuportieren. Im Userland ist es ähnlich. Sobald man Busybox verlässt, ist man in dem Strudel ständiger Änderungen gefangen. Wenn ich heute auf systemd setze (zugegeben für Embedded-Anwendungen noch nicht unbedingt relevant), ist das Risiko hoch, dass es schon in 3 Jahren zur ungeliebten und kaum mehr unterstützten Altlast geworden ist. Die BSDs sind dort beständiger.
- Der Community-Faktor. Linux hat eine riesige Community. Das ist erstaunlich und wunderbar, hat aber einen Nachteil. Als einzelner Entwickler geht man schnell unter. Wenn man z.B. ein Problem mit dem Kernel hat, findet man im Linux-Lager nur noch mit einer sehr tiefgehenden Analyse und idealerweise einem Patch Gehör. Ansprechpartner sind zudem oft schwer auszumachen. Die Doku spärlich und häufig veraltet. Hat man nur begrenzte Ressourcen, kommt man kaum drum herum sich Wissen einzukaufen. Im BSD-Lager ist es noch deutlich persönlicher. Auch diffuse Probleme und Fragen werden oftmals diskutiert, man kann mit den Entwicklern zusammen Fehler suchen. Es gibt mehr Doku und dank weitgehend stabiler APIs / ABIs veraltet sie deutlich langsamer.
Im größeren Umfeld wird man wahrscheinlich wieder anders argumentieren. Dort dürfte die Lizenz durchaus ein nochmals schlagendes Argument sein. Ich kann mir sehr gut vorstellen, dass ein Unternehmen wie ScaleEngine FreeBSD als Basis für ihre Produkte gewählt hat, um nicht alle Optimierungen hinsichtlich Videostreamings am Kernel offen legen zu müssen. Sony wird die Playstation 4 sicher auch aus gutem Grund nicht auf Linux-Basis gebaut haben. Wer will schon riskieren, dass aufgrund der Lizenz offen gelegter Code in kurzer Zeit zum ersten Emulator führt?
Ich glaube es war Sandvine, die einmal argumentierten, dass FreeBSD ihnen einen deutlich größeren Gestaltungsspielraum im Upstream-Projekt einräumt, als es bei Linux der Fall wäre. Änderungen, die kein Geschäftsgeheimnis darstellen, kann man in FreeBSDs Code-Tree entwickeln und ins eigene Produktion zurückportieren. Man hat nicht den Aufwand eines umgekehrtes Weges, gleich eine Community die es verfolgt und auf Fehler hinweist. Am Ende profitiert man selbst dadurch genauso sehr wie die Allgemeinheit.
- Die Lizenz. Die meisten Entwickler haben kein Problem mit der GPL2 und auch nicht mit der GPL3. Das Problem sehen sie eher darin, wie die GPL3 zustande kam. Die berüchtigte "TiVo-Klausel" hat sehr viel Vertrauen zerstört, denn sie verdeutlichte wie leicht Ideologen freie Software als politische Waffen missbrauchen können. Wer sagt, dass eine eventuelle GPL4 keine "Hans Müller Industriesoftware GmbH"-Klausel haben wird und man aufgrund der großen Verbreitung von Software aus dem direkten FSF-Dunstkreis plötzlich ohne aktualisierbaren Softwarestack darsteht? In die Kerbe schlagen z.B. auch die (juristisch natürlich völlig korrekten) Busybox-Klagen, wo man sich schon mal wegen 2 trivialen Zeilen vor'm Kadi sah oder das ständige Geschrei einige Parteien betreffend Closed Source Module für den Linux-Kernel. Natürlich hat ein Entwickler jedes Recht seine Software zu lizensieren, wie er möchte und auch diese Lizenz durchzusetzen. Aber umgekehrt haben Anwender auch das Recht Software aufgrund ihrer Lizenz und der Durchsetzung der Lizenz nicht mehr zu nutzen.
- POLA, auch als "Frickelfaktor" bekannt. Im Linux-Umfeld gibt es nur eine einizige ABI / API, die dauerhaft kompatibel ist. Ja sogar erstaunlich kompatibel, kompatibler als bei den BSDs. Das Interface zwischen dem Linux-Kernel und seinem Userland. Alles andere ist in einem beständigen Fluss. Es hat sicherlich seine Vorteile, aber wenn man ein proprietäres Produkt über 10 oder vielleicht sogar 20 Jahre warten will, wird es zu einem großen Problem. Ein heute geschriebenes Modul für den Linux-Kernel wird sich schon in zwei Jahren sehr weit von der Realität der dann aktuellen Kernel entfernt haben. Kernelupgrades sind daher in einem solchen Fall mit einem enormen Aufwand verbunden, teilweise nahezu unmöglich. Umgekehrt kann man ältere Kernel auch nur sehr eingeschränkt selbst weiterpflegen. (Free)BSD hat diese Probleme nicht. Auch dort muss man über die Zeit Anpassungen an seinen Kernelmodulen vornehmen, aber der Aufwand hält sich zumeist in Grenzen. Zudem ist es relativ problemlos möglich, aktuelle Änderungen in ältere Branches zurückzuportieren. Im Userland ist es ähnlich. Sobald man Busybox verlässt, ist man in dem Strudel ständiger Änderungen gefangen. Wenn ich heute auf systemd setze (zugegeben für Embedded-Anwendungen noch nicht unbedingt relevant), ist das Risiko hoch, dass es schon in 3 Jahren zur ungeliebten und kaum mehr unterstützten Altlast geworden ist. Die BSDs sind dort beständiger.
- Der Community-Faktor. Linux hat eine riesige Community. Das ist erstaunlich und wunderbar, hat aber einen Nachteil. Als einzelner Entwickler geht man schnell unter. Wenn man z.B. ein Problem mit dem Kernel hat, findet man im Linux-Lager nur noch mit einer sehr tiefgehenden Analyse und idealerweise einem Patch Gehör. Ansprechpartner sind zudem oft schwer auszumachen. Die Doku spärlich und häufig veraltet. Hat man nur begrenzte Ressourcen, kommt man kaum drum herum sich Wissen einzukaufen. Im BSD-Lager ist es noch deutlich persönlicher. Auch diffuse Probleme und Fragen werden oftmals diskutiert, man kann mit den Entwicklern zusammen Fehler suchen. Es gibt mehr Doku und dank weitgehend stabiler APIs / ABIs veraltet sie deutlich langsamer.
Im größeren Umfeld wird man wahrscheinlich wieder anders argumentieren. Dort dürfte die Lizenz durchaus ein nochmals schlagendes Argument sein. Ich kann mir sehr gut vorstellen, dass ein Unternehmen wie ScaleEngine FreeBSD als Basis für ihre Produkte gewählt hat, um nicht alle Optimierungen hinsichtlich Videostreamings am Kernel offen legen zu müssen. Sony wird die Playstation 4 sicher auch aus gutem Grund nicht auf Linux-Basis gebaut haben. Wer will schon riskieren, dass aufgrund der Lizenz offen gelegter Code in kurzer Zeit zum ersten Emulator führt?
Ich glaube es war Sandvine, die einmal argumentierten, dass FreeBSD ihnen einen deutlich größeren Gestaltungsspielraum im Upstream-Projekt einräumt, als es bei Linux der Fall wäre. Änderungen, die kein Geschäftsgeheimnis darstellen, kann man in FreeBSDs Code-Tree entwickeln und ins eigene Produktion zurückportieren. Man hat nicht den Aufwand eines umgekehrtes Weges, gleich eine Community die es verfolgt und auf Fehler hinweist. Am Ende profitiert man selbst dadurch genauso sehr wie die Allgemeinheit.
FreeBSDuser
Well-Known Member
Das WhatsApp Backend läuft auch auf FreeBSD.
bananenBrot
Well-Known Member
Gibts da auch irgendwo ne Erklärung warum?
Nicht, dass das intern läuft und einfach nicht mehr portierbar ist - quasi to big to switch
Nicht, dass das intern läuft und einfach nicht mehr portierbar ist - quasi to big to switch
darktrym
Fahnenträger
lme
FreeBSD Committer
Jap, ich habe schon vor ein paar Jahren bei der EuroBSDCon in Cambridge mit jemandem von BW geredet, die setzen das schon länger ein, damals zumindest auf x86 Maschinen, möglicherweise ist es inzwischen embedded.
Nein, die haben einen ejabberd-Stack und brauchen einen anständigen Netzwerkstack. Außerdem sind das glaube ich Ex-Yahoo-Leute, die ich wenn ich mich recht entsinne ziemliche BSD-Fans sind.Gibts da auch irgendwo ne Erklärung warum?
Nicht, dass das intern läuft und einfach nicht mehr portierbar ist - quasi to big to switch
Kurzum sie müssen sehr groß skalieren können und das geht sowohl mit Erlang, als auch mit BSD ganz gut und beides ist ja historisch genau in der Branche groß geworden. FreeBSD bei ISPs und Erlang im Telekommunikationsbereich. Ist also für ihr Vorhaben die perfekte Kombination.
Scaling und einfache Wartung dürfte aber wohl auch auf DuckDuckGo zugreifen. Das ist ein FreeBSD/Perl Stack. Das ist wohl die Entscheidung weil das quasi ein Ein-Mann-Projekt ist. Da willst du auch nichts haben wo du riesige Admin-Teams brauchst.
Ist generell ein wenig eine Beobachtung die ich gemacht habe. FreeBSD hast eben eher bei Leuten, die wirklich darauf angewiesen sind ihre Sachen durch und durch zu kennen. Andere Stacks sind so bei Standardsetups eher zu Hause, wie bei 0815-Wordpress-Systemen (also nicht nur Blogs). Die willst du auch nicht unbedingt so in die Breite skalieren. Das kann man mit Linux schonmal besser dran sein, so mit Debian oder CentOS und alle paar Jahre mal einem Upgrade der Software.
Bei FreeBSD kannst du was deinen Entwicklungsstack angeht sehr aktuelle Software haben ohne dass alles gleich instabil wird. Das zahlt sich schon aus, wenn du weißt dass die neue Version von XY dein großes Bottleneck deutlich performanter werden lässt. Auf CentOS und Debian kann das mitunter die Hölle sein, da ein Upgrade außerhalb der Releases zu machen. Kommt aber dann natürlich auf die Software an und was für Möglichkeiten die zur Verfügung stellt. Ein offizielles Debian-Repository kann da schon vieles verbessern.
FreeBSDuser
Well-Known Member
Es ist kein ejabberd mehr. Hier sind folien eines Vortrags von 2012: http://www.erlang-factory.com/upload/presentations/558/efsf2012-whatsapp-scaling.pdf
Netflix mit der Open Connect Box: http://people.freebsd.org/~scottl/Netflix-BSDCan-20130515.pdf
Netflix mit der Open Connect Box: http://people.freebsd.org/~scottl/Netflix-BSDCan-20130515.pdf
SolarCatcher
Well-Known Member
Oh, das fühlt sich gut an! Wenn man bsdforen.de verfolgt, bekommt man schon das Gefühl, man sei der letzte, der noch auf UFS mit SU+J setzt.
Ich habe auch noch viele Daten auf UFS2. Wieso auch nicht? Wenn man nur Daten speichern möchte und kein Volumenmanagement braucht, ist UFS nach wie vor große Klasse. Es ist schnell, ressourcensparend und zuverlässig. Was will man mehr? Schade ist nur, dass das Journaling auf Desktophardware nicht wirklich funktioniert und man daher nach wie vor ein fsck benötigt. Leider wird sich das auch kaum ändern, da sich niemand die Mühe machen wird, die notwendige Magie wie Write Barriers einzubauen.
