Marketing muß folgendes ausdrücken: "Unser Produkt ist leistungsfähiger als das eines beliebigen Konkurrenten. Selbst dann wenn es nur genauso leistungsfähig oder weniger leistungsfähig ist." Das ist eben allgemeines Blabla aus der Marketingecke von Novell. Es ist nicht wichtig ob etwas dahinter steckt oder nicht. Es ist nur wichtig daß es gesagt wurde. Vor allem weil man nach Canonical auf die Idee mit den virtuellen Services kam.
Von Christopher Bratusek am Mi, 19. März 2008 um 20:05 #
Der BuildService von SuSE kann RPMS für SuSE/Mandriva/Fedora und DEBs für Debian/*buntu erstellen. Der Ubuntu Service (nach meinem Wissensstand) nur DEBs für Ubuntu. Von daher ist mir der OpenSuSE-BuildService lieber.
Von Sierk Bornemann am Mi, 19. März 2008 um 23:33 #
> Der BuildService von SuSE kann RPMS für SuSE/Mandriva/Fedora und DEBs für Debian/*buntu erstellen.
Richtig.
>Der Ubuntu Service (nach meinem Wissensstand) nur DEBs für Ubuntu.
Zumal Ubuntus Build Service zeitlich deutlich *nach* dem von openSUSE und noch deutlicher *nach* dem von Fedora ins Leben gerufen worden ist.
> Von daher ist mir der OpenSuSE-BuildService lieber.
Er ist universeller und hat einen höheren Anspruch als der von Ubuntu.
Hier ein kurzer Vergleich eines Benutzers beider Build Services (Stand: 12/2007): http://blog.jbbr.net/2007/12/22/ vergleich-opensuse-build-service-vs-launchpad-ppa/
Ubuntu wird ja auch von Builservices (Buildservern) gebaut, was ist daran neu?!
Hier ist nicht die Rede von Softwarepaketen, sondern von Software Appliances die vom Buildservice gebaut werden. Also eine Software die das Betriebssystem mitbringt.
Dann erklärs doch bitte mal oder gib nen Link auf sinnvolle Infos. Ein "Buildservice" ist nun wirklich nichts neues, und vielmehr als Infos aus Newsreleases findet man als SuSE Fremder nunmal nicht "mal eben".
ich habe es so verstanden (ohne mich näher schlaugemacht zu haben): JeOS ist eine spezielles Ubuntu- Flavour für VmWare, das die Ubuntu- Leute gebastelt haben.
Der Build-Service bietet wohl dem Kunden Werkzeuge, sich selber eine angepaßte Distribution zusammenzustellen, die für seine spezielle Hardware (Appliance) optimiert ist.
Ich denke, Jordi hat hier die Roadmap des Buildservice im Hinterkopf. Dort ist u.a. nachzulesen, dass man mit dem Buildservice ein Verfahren entwickeln möchte, in welchem sich Entwickler - aufbauend auf verschiedenen Repositories des Buildservice - selbst eine Distribution _zusammenklicken_ können.
Wenn ich also später eine "Software-Applicances" anbieten möchte, die auf *buntu, CentOS, SLES oder eben openSUSE beruht und zusätzliche Pakete vom KDE-Repository und meine eigenen Pakete (aus meinem Repository) enthält, dann soll ich das über den openSUSE Buildservice mit ein paar _Mausklicks_ zusammenstellen können. Sicher: auch das gibt es in der einen oder anderen Form schon - nur eben nicht unbedingt Benutzerfreundlich und Distributionsübergreifend.
Ob die Endnutzer später dann so erfreut darüber sind, zweitausend verschiedene *buntu oder *SuSE oder fedora* Versionen bei Distrowatch zu finden, lasse ich mal dahingestellt. Aber immerhin kann man sich dann evtl. später mal "sein eigenes" Linux mit genau den Anwendungen zusammenklicken, dass man dann immer dabei hat. Sozusagen ein "personal OS" - mit genau den Anwendungen (als Livesystem inkl. Installer) die man persönlich bevorzugt. ...und dieses "personal OS" gibt es dann (dank KIWI) eben sowohl als Live-Image, als Installationsmedium auf CD oder USB-Stick - und der Buildservice erzeugt mir automatisch ein neues Image, wenn sich einzelne Pakete ändern.
Wie groß ist denn so ein Image, sagen wir mal mit x und einer Arbeitsumgebung (so ca.)? Ich hätte gerne eine Distri dessen Image man noch auf eine CD brennen kann und ein vernünftiges und halbwegs aktelles Paketmanagement hat.
Das kleinste mit Grafischer Oberfläche und vernünftigen (deb) paketmanagement dürfte DamnSmallLinux sein, braucht nur 50MB und läuft auch noch auf einem 486er
Alle Distributionen die ich bisher testwürdig fand waren auf eine CD brennbar und die besseren davon hatten auch ein "halbwegs aktuelles" Paketmanagement. Meine persönlichen Favoriten für verschiedene Einsatzzwecke:
Archlinux auf dem Desktop/Laptop und auf dem Heimserver. (~ alle Kisten die ich sehr häufig für alles mögliche hardcore benutze, die dafür aber auch gerne mal einen Tag ausfallen können) Ubuntu auf allen Linuxdesktop die ich verwalten darf bei Freunden und Familie + eigene Arbeitsrechner. (~ alle Desktops die ich nur selten warten möchte, Ausfallhäufigkeit so niedrig wie möglich) Debian auf den produktiven Servern. (~ Server, die eine definierte Anzahl von Diensten bieten, und ausser für Sicherheitsupdates seltenst angefasst werden, Ausfallhäufigkeit limes gegen 0)
Birnen schmecken besser als Schokolade, weil sie auf einem Baum wachsen.
????????
Vielleicht kann ja jemand die relevanten Vorteile mal konkret aufzeigen.
Was ergeben sich den für konkrete Vorteile für LimeJeOS daraus?
Sehr, sehr wahr.
Allerdings hat das nichts mit den (oft der Faulheit geziehenen) Kastanien zu tun!
"Vielleicht kann ja jemand die relevanten Vorteile mal konkret aufzeigen."
Ich finde das nicht notwendig (Kastanien...).
Klärt mich bitte auf!
Das ist eben allgemeines Blabla aus der Marketingecke von Novell. Es ist nicht wichtig ob etwas dahinter steckt oder nicht. Es ist nur wichtig daß es gesagt wurde. Vor allem weil man nach Canonical auf die Idee mit den virtuellen Services kam.
Ich finde außerdem die offensichtliche namensähnlichkeit Interessant.
Richtig.
>Der Ubuntu Service (nach meinem Wissensstand) nur DEBs für Ubuntu.
Zumal Ubuntus Build Service zeitlich deutlich *nach* dem von openSUSE und noch deutlicher *nach* dem von Fedora ins Leben gerufen worden ist.
> Von daher ist mir der OpenSuSE-BuildService lieber.
Er ist universeller und hat einen höheren Anspruch als der von Ubuntu.
Hier ein kurzer Vergleich eines Benutzers beider Build Services (Stand: 12/2007):
http://blog.jbbr.net/2007/12/22/
vergleich-opensuse-build-service-vs-launchpad-ppa/
Hier ist nicht die Rede von Softwarepaketen, sondern von Software Appliances die vom Buildservice gebaut werden. Also eine Software die das Betriebssystem mitbringt.
ich habe es so verstanden (ohne mich näher schlaugemacht zu haben): JeOS ist eine spezielles Ubuntu- Flavour für VmWare, das die Ubuntu- Leute gebastelt haben.
Der Build-Service bietet wohl dem Kunden Werkzeuge, sich selber eine angepaßte Distribution zusammenzustellen, die für seine spezielle Hardware (Appliance) optimiert ist.
Wenn ich also später eine "Software-Applicances" anbieten möchte, die auf *buntu, CentOS, SLES oder eben openSUSE beruht und zusätzliche Pakete vom KDE-Repository und meine eigenen Pakete (aus meinem Repository) enthält, dann soll ich das über den openSUSE Buildservice mit ein paar _Mausklicks_ zusammenstellen können. Sicher: auch das gibt es in der einen oder anderen Form schon - nur eben nicht unbedingt Benutzerfreundlich und Distributionsübergreifend.
Ob die Endnutzer später dann so erfreut darüber sind, zweitausend verschiedene *buntu oder *SuSE oder fedora* Versionen bei Distrowatch zu finden, lasse ich mal dahingestellt. Aber immerhin kann man sich dann evtl. später mal "sein eigenes" Linux mit genau den Anwendungen zusammenklicken, dass man dann immer dabei hat. Sozusagen ein "personal OS" - mit genau den Anwendungen (als Livesystem inkl. Installer) die man persönlich bevorzugt. ...und dieses "personal OS" gibt es dann (dank KIWI) eben sowohl als Live-Image, als Installationsmedium auf CD oder USB-Stick - und der Buildservice erzeugt mir automatisch ein neues Image, wenn sich einzelne Pakete ändern.
Ich hätte gerne eine Distri dessen Image man noch auf eine CD brennen kann und ein vernünftiges und halbwegs aktelles Paketmanagement hat.
Archlinux auf dem Desktop/Laptop und auf dem Heimserver. (~ alle Kisten die ich sehr häufig für alles mögliche hardcore benutze, die dafür aber auch gerne mal einen Tag ausfallen können)
Ubuntu auf allen Linuxdesktop die ich verwalten darf bei Freunden und Familie + eigene Arbeitsrechner. (~ alle Desktops die ich nur selten warten möchte, Ausfallhäufigkeit so niedrig wie möglich)
Debian auf den produktiven Servern. (~ Server, die eine definierte Anzahl von Diensten bieten, und ausser für Sicherheitsupdates seltenst angefasst werden, Ausfallhäufigkeit limes gegen 0)