staging.inyokaproject.org

Alle Formate haben in seinen Augen kleinere Schwächen, die es für die Ubuntu Apps erst auszumerzen gäbe.

Nennt er auch die Schwächen? Und warum nicht die Schwächen ausmerzen, anstatt das Rad neu zu erfinden?

..., dass dieses neue Format nicht die aktuell vorhandenen Paketformate (unter Ubuntu wird APT genutzt) berühren wird.

Ist das Pektformat nicht *.deb und APT die Paketverwaltung? Dann wären yum, pacman, zypper usw. ja eigenständige Paketformate, was sie ja nicht sind.

Was die Schwächen der Paketformate angeht, schliesse ich mich @1: an: Warum nicht die Schwächen ausmerzen, anstatt das Rad neu zu erfinden? Sollte doch einfache, etwas Bekanntes und dessen Schwächen zu verbessern, als etwas komplett Neues zu nehmen? Auch da können (und werden sicherlich auch) andere Schwächen zu finden sein.

Das neue Paketformat soll sehr leichtgewichtig werden, weswegen auch die bei APT so geschätzte Abhängigkeitsstruktur wegfallen wird. Jede Applikation muss ihre Abhängigkeiten also selbst befriedigen.

Meiner Meinung schließt sich das auch. Soll ab jetzt jede Anwendung ihre zig Librarys selbst mitbringen? Das würde doch dazu führen, dass man ein und dieselben Bibliotheken und Befehle doppelt und dreifach installiert.

@1: @2:

Von wegen „Rad neu erfinden“... manche Leute unterstellen den Ubuntu-Entwicklern ein NIH-Syndrom...

@3: Ja, so verstehe ich das auch. Windowsverhältnisse.

Das neue Paketformat soll sehr leichtgewichtig werden, weswegen auch die bei APT so geschätzte Abhängigkeitsstruktur wegfallen wird. Jede Applikation muss ihre Abhängigkeiten also selbst befriedigen.

Das sollte doch mit deb-Paketen auch möglich sein: Alle abhängigen Dateien mit einpacken und keine Abhängigkeiten definieren beim Paketieren.

@4: Ich sage nur Upstart...

Das sollte doch mit deb-Paketen auch möglich sein: Alle abhängigen Dateien mit einpacken und keine Abhängigkeiten definieren beim Paketieren.

Der Paketmanager muss dadurch viel wengier können und kann deswegen deutlich schneller sein.

das ist totaler blödsinn. die paketmanager sind eine der größten stärken eines linux-systems. dies nun zu verwerfen, bedeutet einen unnötigen rückschritt. für die angepeilten mobilgeräte, sollte es an der nötigen leistung zumindest nicht scheitern.

Hmm ja... ein sehr kontroverses Thema 😀

Klar erscheint es auf den ersten Blick wenig sinnvoll, wenn bestimmte Libraries doppelt und dreifach mitgeliefert werden... Andererseits habe ich auch schon öfters Probleme mit dem Konzept der APT-Paketverwaltung gehabt... Beispiel: Sowohl KDEnlive als auch OpenShot haben auf das MLT-Framework zurückgegriffen. Allerdings benötigten beide andere Versionen. Also war es leider nicht möglich, beide Probleme gleichzeitig zu benutzen... Von daher erscheint es - zumindest in einigen Fällen - auch sinnvoll, manche Dinge doppelt vorzuhalten (und mal ehrlich: Heute hat selbst ein Smartphone das Vielfache des Speicherplatzes zur Verfügung, den zum Zeitpunkt der Entwicklung dieses Konzeptes ein Desktoprechner hatte - mein erste Windows XP Rechner hatte damals eine 16GB (oder waren es nur 14GB?) Festplatte 😀 - welche Vorteile das sonst noch haben sollte, weiß ich gerade nicht). Das Wichtigste dürfte aber vor allem sein, dass dadurch eines erreicht wird: Einfachkeit. Das hat vor allem auch den Vorteil, potenzielle Entwickler nicht abzuschrecken.

@1: Natürlich weiß ich nicht, wo genau die Schwächen liegen, aber ich könnte mir gut vorstellen, dass er dort einige konzeptionelle Schwächen sieht. Und zu einem Projekt zu gehen und es von einen mehr oder weniger stark verändertem Konzept zu überzeugen, dürfte wirklich schwer sein (oder hast du schonmal versucht, mit einem Entwickler Grundsatzentscheidungen zu diskutieren? Das versucht man auch nur einmal 😀 (kommt natürlich auf die Person drauf an, aber viele sind da sehr... "eigen" 😉)).

Sehr interessant finde ich auch das Prinzip der Ordnerstruktur, also pro App ein Ordner. Genauso gehört sich das mMn. Das hat mich bei Linux ehrlichgesagt schon länger gestört, dass dort so eine so komplexe Ordnerstruktur gewählt wurde. Zumindest für den Durchschnittsnutzer ist sie nur schwer durchschaubar. Die Trennung von Programmen in Ordnern im Ordner "Programme" unter Windows fand ich da irgendwie schon immer sympathischer (auch wenn es viele Ausnahmen gibt, z.B. die Registry oder die Anwedungsdaten usw.). Ich hoffe mal, dass diese Verstreuung unter Windows hier nicht auch übernommen werden. ☺

Naja, alle Punkte die Colin in seinem Beitrag anspricht, sind *exakt* gleich vom Listaller Project abgedeckt. Und als Listaller Entwickler hat man sich nie bei mir gemeldet, um eventuelle Fragen zu klären.
Insofern ist das schon NIH, allerdings scheint man doch offen für Diskussion zu sein. Da allerdings schon fertiger Code bei Ubuntu existiert und die Canonical-Angestellten den wohl auch nutzen wollen, sehe ich keine allzu großen Chancen für andere Projekte.

@6: Wieso Upstart? Also was meinst du damit?

@7: Ich hatte ein Nokia N900, welches eine vollständige Paketverwaltung besass. Es war tatsächlich APT, denn das Betriebssystem Maemo basierte auf Debian. Obwohl ich totaler Fan von einer Paketverwaltung und inbesondere derjenigen von Debian bin, konnte ich damit auf dem N900 nicht viel anfangen. Die Handhabung war viel zu kompliziert für ein so kleines Gerät.

Unter welchen Umständen machen diese ganzen Canonical Eigenentwicklungen Sinn?

Wenn vom Prizip Freie Software auf Basis freiwilliger oder bezahlter Programierarbeit, auf das Prinzip zentral betriebene Server umgestellt wird? (Das Umwidmungswort lautet SaaS "Software as a Service".)

Wenn Serverkomponenten und damit die Protokolle unter proprietäre Kontrolle gebracht werden sollen?

Wenn man das OS als "Firmware" Images auf Endgeräte spielen möchte?

Wenn man die Installation proprietärer Binärblobs untersützten möchte, für die es darauf ankommt ein feste (ABI) Umgebung in einer bestimmten Version zu haben? (Freie Software wird beim Paketerstellen sonst einfach neu Kompiliert.)

Wenn von einem zentralen "App ecosystem" möglichst nur Canonical profitieren soll, bei dem Andere sich später evtl. anschließen dürfen?

–-

Schon Nokias N900 kam mit .deb, apt-get und einer mobilen apt-Paketverwaltungs "App" zurecht.

Hier ist übrigens eine News mit diesem Artikel als Quelle: http://www.computerbase.de/news/2013-05/ubuntu-apps-sollen-eigenes-paketformat-bekommen/

@10: Ich glaube er meint, dass Upstart eine Canonical Eigenentwicklung war / ist, anstatt auf systemd zu setzen, was viele andere benutzen. (ich war gerade zu faul zu recherchieren, also ohne Garantie auf Richtigkeit, aber das war das, was in meinem löchrigen Gedächtnis gerade noch hängengeblieben ist 😉)

@14: Upstart ist älter als systemd und war früher einsatzbereit. Kann also nicht sein ☺

@14, @15: Ich finde es nicht sinnvoll, dass canonical zu den meisten anderen Distributionen inkompatible Anwendungen entwickelt. Vielfalt ist zwar schön und auch sehr wichtig, in meinen Augen braucht man in bestimmten Bereichen aber auch einheitliche Systeme. Besonders bei systemrelevanten Anwendungen sind einheitliche Standards wichtig, damit man nicht für jede Distribution ein anderes Programm schreiben muss.

Es wäre viel sinnvoller wenn canonical einsehen würde, dass es mehr bringt, wenn man an bestehenden Projekten mitarbeitet und diese dann eventuell an die eigenen Bedürfnisse anpasst, anstatt alles selber zu entwickeln.

Nur weil Upstart früher fertig war, ist es nicht besser, sondern meiner Ansicht nach eher schlechter. Dass Systemd einige Vorteile gegenüber Upstart hat, wird auch dadurch gezeigt, dass Distributionen wie Fedora und OpenSuse nur kurz Upstart angeboten haben, jetzt aber, wie auch Mandriva, Mageia, Gentoo Red und Hat Enterprise Linux, zu Systemd gewechselt sind.

Man sollte sich unbedingt die hier bereits verlinkte Spec-Seite und die Mailing-Liste durchlesen, dann beantwortet sich manche Kritik hier von selbst.

@16: Dann muss du diesen Vorwurf aber genau so an systemd machen - da haben die Entwickler auch "was neues" entwickelt anstatt bestehende Projekte (wie Upstart) zu unterstützen.

Denn gleichen Vorwurf könntest du auch Linus Torvalds machen, dass er Linux entwickelt hat, anstatt ein bestehendes Projekt wie Minix zu unterstützen.

Sprich: wenn du deinen Vorwurf allen Softwareentwicklern machst würden wir alle vielleicht noch ein 70er Jahre Unix benutzen. 😉

@18: Wenn man davon absieht, dass upstart ziemlich broken by design ist, gibts da immernoch die CLA

Nette Randnotiz zum NIH-Syndrom: Upstart hängt von libnih (von Canonical entwickelt) ab.

Das Rad neu erfinden ist vollstens in Ordnung wenn man es gut begründen kann. Daran hapert's aber bei Canonical immer ein wenig.

Schade dass sich die Herrschaften von Canonical nicht mit Lennart Poettering zusammensetzen wollen, der hat nämlich was ähnliches in petto (und wie auch bei systemd vs upstart hat er bessere ideen und argumente...): http://0pointer.de/public/gnome-asia-2013-apps.pdf