Le projet Chakra, un live CD fait par de amoureux d'Arch Linux et de KDE, annonce sa séparation d'Arch. Chakra avait déjà ses propres paquets KDE découpés plus finement qu'Arch, un installeur graphique (Tribe), un outil graphique de gestion des paquets (Shaman), un outil de configuration (Arxin), ainsi qu'un système de création de Live CD (BuildEnv).
Ils décident désormais d'avoir leurs propres dépôts, séparés d'Arch, sans Gnome, Gtk, etc. ; un nouveau moyen d'installer des logiciels tiers (a priori inspiré de la méthode utilisée sur MacOSX) ; un remplaçant de pacman qui ne leur convient plus.
Leur souhait semble donc d'être indépendant, d'avoir une meilleure intégration de KDE ainsi qu'un système tourné vers l'utilisateur lambda.
Journal Chakra se sépare d'Arch
30
mai
2010
# Lien ?
Posté par Nuclear . Évalué à 3.
http://chakra-project.org/tools-buildenv.html
Je ne vois pas de rapport avec un gestionnaire de paquets, mauvais lien peut-être ?
[^] # Re: Lien ?
Posté par Dr BG (site web personnel) . Évalué à 4.
Pour les non-anglophones ne connaissant pas pacman : http://wiki.archlinux.fr/arch:pacman
# chakra ça veut dire roue...
Posté par B16F4RV4RD1N . Évalué à 9.
dommage car archlinux était une excellente base.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: chakra ça veut dire roue...
Posté par claudex . Évalué à 8.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: chakra ça veut dire roue...
Posté par GeneralZod . Évalué à 3.
[^] # Re: chakra ça veut dire roue...
Posté par claudex . Évalué à 5.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: chakra ça veut dire roue...
Posté par seginus . Évalué à 5.
Depuis la séparation des paquets kde4, kdemod avait bien moins d'intérêt dans archlinux.
Le travail de création des paquets de chakra se simplifiera donc en limitant les dépendances vers des paquets dont ils n'ont pas de contrôle et donc de faire une distribution très « propre », un peu à la macos comme dit dans le journal.
Est-ce réinventer la roue ? je ne trouve pas, j'attendais d'ailleurs la sortie d'une telle distribution.
Une sorte d'Ubuntu, basé sur Arch, je trouve que c'est une très bonne initiative, pourquoi pas éventuellement d'ailleurs partir sur un système de release. avec une sortie toute nouvelles version de kde et entre les deux des mises à jours de sécurités.
La base d'Arch le permet, et je trouve que c'est une super idée d'avoir une distribution à la fois simple pour le lambda et néanmoins basé sur le système d'Arch.
Je pense que de part sa conception très simple permettant beaucoup de chose, arch va devenir à son tour la source d'autres distributions.
Voir naître des enfants d'Arch est je trouve quelque chose de très gratifiant pour cette distribution et je suis bien voir d'autres variantes venir.
[^] # Re: chakra ça veut dire roue...
Posté par Dr BG (site web personnel) . Évalué à 3.
# Gestionnaire de paquets de Chakra
Posté par steckdenis (site web personnel) . Évalué à 7.
Le projet akabei ( http://git.chakra-project.org/akabei ) contient leur gestionnaire de paquets.
J'ai parcouru ses sources il y a quelques temps, et c'est un gestionnaire de paquets intéressant. J'ai toutefois relevé quelques problèmes (sachant que je développe aussi un gestionnaire de paquets) :
* Ils utilisent une base de donnée SQLite, qu'ils interrogent en SQL. Ça va les tuer du côté des performances, car le moindre accès à la BDD passe par la création d'une requête SQL, puis son parsing. Ils seront obligés de faire de grosses requêtes (mais pas souvent), puis du traitement du côté C++ pour rattraper le coup.
* Leur solveur de dépendance est un peu trop proche de celui de pacman, c'est à dire «quick and dirty» : on trouve les dépendances, on retire les conflits, et si ça marche pas, on geule. Ça marche bien dans 99% des cas, mais si on a un truc complexe, ça ne va plus.
Par contre, ils ont une belle implémentation des delta-packages, en utilisant XDelta (rapide et efficace, même si moins efficace que bsdiff).
Le code est propre et agréable à lire. Il ne me semble pas qu'il manque trop de fonctionnalités, j'ai lu sur le site qu'ils l'ont testé et que ça marche.
Wait & see donc, mais ça pourrait être intéressant.
[^] # Re: Gestionnaire de paquets de Chakra
Posté par Pierre Bourdon . Évalué à 8.
Ils utilisent une base de donnée SQLite, qu'ils interrogent en SQL. Ça va les tuer du côté des performances, car le moindre accès à la BDD passe par la création d'une requête SQL, puis son parsing. Ils seront obligés de faire de grosses requêtes (mais pas souvent), puis du traitement du côté C++ pour rattraper le coup.
Créer une requête SQL et la parser c'est surement moins d'1% du temps d'exécution de la requête. Relativement c'est minuscule et ça permet par contre beaucoup de choses impossibles, complexes ou lentes par rapport à des formats binaires classiques. À côté de ça, SQLite est un SGBDR très rapide pour tout ce qui est lecture sans locks (surement 99% des accès pour un package manager, et 100% des choses pour lesquelles on lui demande d'être rapide). Utiliser une BDD permet également d'indexer facilement sur les différents champs pour optimiser les opérations de recherche courantes (à un certain coût lors des modifications, mais on s'en fiche pas mal par rapport au nombre de lectures).
Je ferais remarquer également sur l'argument de la vitesse que pacman, qui est considéré comme un des packages managers les plus rapides (mais bon, il gère moins de choses que les autres aussi) utilise le filesystem pour gérer la database des paquets. Un dossier par dépot dans /var/lib/pacman/sync, et un dossier par paquet du dépot qui contient un fichier « desc » et un fichier « depends ». C'est tout sauf optimisé pour le problème, c'est indexé n'importe comment et de manière non contrôlée par le filesystem, et c'est pourtant très rapide. Utilise une DB ne pourra être que mieux sur ce point (d'ailleurs, ça fait partie des choses prévues pour pacman, mais pour lesquelles personne n'a encore proposé de patch).
Bref, c'est bien beau de balancer des faits sans rien derrière. Faut juste éviter de se planter complètement comme tu viens de le faire.
[^] # Re: Gestionnaire de paquets de Chakra
Posté par houra . Évalué à 1.
Sedullus dux et princeps Lemovicum occiditur
[^] # Re: Gestionnaire de paquets de Chakra
Posté par gnumdk (site web personnel) . Évalué à 3.
Il semble qu'il ait posé problème au devs d'amarok...
Et quand je compare le chargement complet de ma collection dans la playlist entre amarok 2 et Clementine (amarok 1 version Qt4 donc utilisant sqlite), ben y'a pas photos, le premier fait ça en quelques secondes, le second rame comme une grosse daube pendant de (trop) nombreuses secondes...
[^] # Re: Gestionnaire de paquets de Chakra
Posté par GeneralZod . Évalué à 4.
sqlite est très rapide à condition de savoir s'en servir (ce qui est loin d'être gagné). C'est sûr que si tu fais des milliers de requêtes sans encadrer le tout dans une transaction, ce sera très lent vu que SQLite ouvrira/initialisera ses structures internes/fermera le fichier contenant la base de donner pour chaque requête.
Les performances de SQLite sont aussi fonction de la taille de la base de données, au-delà de la centaine de Mo, ça commence à faire mal au delà du Go, c'est inutilisable. Mais bon, on sort du cadre d'utilisation normale c-a-d base de données embarquées, définition de format de fichiers personnalisés etc ...
> Il semble qu'il ait posé problème au devs d'amarok...
Entre le gugusse qui écoute occasionnellement de la musique et le fou furieux qui a plusieurs centaines de Go de musique ... c'est sûr que si le premier prends une base MySQL pour gérer 100 titres, et que le second une base SQLite, c'est loin d'être gagné.
[^] # Re: Gestionnaire de paquets de Chakra
Posté par steckdenis (site web personnel) . Évalué à 1.
En effet, j'ai été regarder dans le dossier /var/lib/pacman, et ça fait peur. Je n'y étais jamais allé, merci de me faire découvrir pourquoi la moitié des inodes de ma partition sont déjà pris, et pourquoi un pacman -Sy prend tant de temps.
Sinon, le SQL peut être très rapide, j'ai eu l'occasion de beaucoup de tester. Il y a un an, j'avais fait un gestionnaire de paquet (j'aime développer des gestionnaires de paquets :-° ) qui utilisant une base SQLite, en passant par QtSql.
Alors oui, il y a des requêtes un peu lourdes, mais assez efficaces. Mais il y a aussi le problème des multiples requêtes.
Par exemple, tu dois résoudre les dépendances d'un paquet. Pour cela, deux solution :
* Une grosse requête qui te dump la table packages_deps, et tu traite le tout en C++. Grosse consommation de RAM
* Plein de petites requêtes quand t'en a besoin
Les deux solutions sont lentes. Je t'invite à regarder comment on peut gérer ça élégamment avec des fichiers mappés : http://gitorious.org/logram/setup/blobs/master/libpackage/da(...) .
Oui, complexité O(nombre de dépendances), très rapide. Du C pur*, pas d'accès à une BDD, c'est indexé, etc.
En fait, une base de donnée binaire fait-maison est la solution la plus rapide qu'il soit, car c'est adapté au problème. Maintenant, obtenir cette rapidité est difficile (perso : 2 mois de réflexion au moins).
Le résultat : à la sortie de Setup 0.1-alpha2, je ferai une vidéo montrant l'instantanéité de tous les traitements de Setup, malgré le fait qu'il utilise un solveur à graphe orienté : http://logram-project.org/news-2-66-1-un-nouveau-solveur-de-(...) . (Solveur d'ailleurs pas encore optimisé, qui compare des chaînes de caractère. Je dois encore faire en sortie qu'il compare des index de chaînes, sachant que toutes les chaines de caractères de la BDD sont indexées).
*Sauf l'ajout à une QList, mais il est possible de ne pas utiliser cette fonction et donc de ne pas avoir ce confort qu'on paie côté perfs.
[^] # Re: Gestionnaire de paquets de Chakra
Posté par Pierre Bourdon . Évalué à 5.
4s top chrono ici en comptant le DL. Sur du ReiserFS. C'est simple et suffisant.
Par exemple, tu dois résoudre les dépendances d'un paquet. Pour cela, deux solution :
Non, trois. La troisième étant d'avoir une BDD conçue pour répondre au problème. Sans trop chercher je ferais ça avec une table deps qui a deux champs qui référencent des entrées de la table packages. Du coup, récupérer les dépendances d'un paquet ça se fait en une requête SQL pas trop complexe (un join).
Je t'invite à regarder comment on peut gérer ça élégamment avec des fichiers mappés :
Tu mélanges des trucs qui n'ont pas de rapport. Que tu mmap tes fichiers ou que tu y accèdes en seekant et en gérant ton cache manuellement ça n'a aucun rapport avec la structure et le format du fichier.
En fait, une base de donnée binaire fait-maison est la solution la plus rapide qu'il soit, car c'est adapté au problème.
Et beaucoup plus error-prone tout en ne permettant pas à d'autres programmes de lire facilement ta BDD. Je remarque d'ailleurs que ton code ne fonctionne que sur des processeurs little endian et dépend de l'alignement des champs de ta structure fait par le compilateur.
[^] # Re: Gestionnaire de paquets de Chakra
Posté par steckdenis (site web personnel) . Évalué à 3.
1)
Ça dépend des dépôts. ReiserFS est conçu pour ce genre de choses, donc je veux bien croire que ça aille vite. Il faut aussi compter l'age de l'installation d'ArchLinux. Mon premier update s'est fait en quelques secondes, alors que je suis maintenant à près d'une minute (avec le système inutilisable à cause des IO).
2)
Justement, tu prends en fait la 2e solution. Pour obtenir les dépendances d'un paquet, tu dois faire une requête. Pour chaque dépendance, tu dois prendre leurs dépendances, et ainsi de suite. Finalement, tu te retrouves avec une quantité impressionnante de requêtes sur ta BDD.
Tu peux également faire un gros SELECT qui te ramène toutes les deps, ce qui est justement ma solution 1.
3)
Non, je ne mélange pas. Je parle en fait d'accès, et je n'oppose pas le mmap contre l'accès séquentiel, mais bien l'idée «Je passe par une lib tier à laquelle je parle en requête textuelle» par rapport à «Je fait tout moi-même, sans couche d'abstraction». Sauf que les fichiers mmapés ont également comme avantage d'être plus rapides et d'utiliser moins de RAM (le noyau les considère comme un swap supplémentaire, et utilise un chemin de code rapide et optimisé pour lire les pages, au lieu de passer par des syscalls lents et répétitifs).
4)
La base de donnée est écrite par Setup lui-même (il récupère du serveur des fichiers de texte comme ceux utilisés par Debian, donc en gros du INI). Il n'y a donc aucun problème d'edianess ou d'alignement, le compilateur se charge de tout.
Le fait que ce soit illisible par d'autres programmes n'est pas embêtant pour deux points. Premièrement, Setup utilise une bibliothèque, donc un programme qui veut gérer des paquets utilise cette bibliothèque. Deuxièmement, ce n'est pas comme si c'était un fichier de configuration ou un dépôt de mails, devant être lu par tout le monde. C'est le cache de Setup, ça doit juste être rapide et sûr.
Si un programme devait néanmoins lire la liste des paquets installés, il lui suffit de lire /var/cache/lgrpkg/db/installed_packages.list. C'est un fichier INI lisible avec un QSettings. Setup lit ce fichier quand il reconstruit sa base de donnée (oui, ma BDD a comme problème d'être en lecture seule, donc quand on met à jour, il faut l'effacer et la reconstruire. Ça prend 6 secondes pour y mettre les 27 000 paquets de Sid).
[^] # Re: Gestionnaire de paquets de Chakra
Posté par med . Évalué à 1.
T'as fait un pacman -Sc ? Ça donne un coup de balai dans le cache en enlevant les vieux paquets et ça va nettement plus vite après.
[^] # Re: Gestionnaire de paquets de Chakra
Posté par Dr BG (site web personnel) . Évalué à 4.
[^] # Re: Gestionnaire de paquets de Chakra
Posté par Kangs . Évalué à 1.
* Ils utilisent une base de donnée SQLite, qu'ils interrogent en SQL. Ça va les tuer du côté des performances, car le moindre accès à la BDD passe par la création d'une requête SQL, puis son parsing.
[...]
Tu n'est pas obligé de 'parser' systématiquement ta requête, tu peux gérer un cache et réutiliser les requêtes. Si tu ne 'bind' pas tes requêtes tu as tout faux.
[...]
Ils seront obligés de faire de grosses requêtes (mais pas souvent), puis du traitement du côté C++ pour rattraper le coup.
[...]
Je pense que tu ne connais pas suffisamment bien le sql, il est imbattable pour la manipulation d'ensembles (quand tu fais du sql il faut perdre tes réflexes de programmeur c, C++, perl, etc)
sqlite avait des défauts de jeunesse mais depuis les version 3.6.x il s'est vraiment améliorée dans l'analyse des requêtes, tu peux maintenant soumettre des requêtes syntaxiquement complexe il les comprendra.
Le seul gros point noir, pour moi, de sqlite c'est qu'il place des verrous en lecture et pour du multi-threading ce n'est pas top.
# J'ai du mal à comprendre
Posté par dave . Évalué à 3.
Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.
[^] # Re: J'ai du mal à comprendre
Posté par B16F4RV4RD1N . Évalué à 4.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: J'ai du mal à comprendre
Posté par Anonyme . Évalué à 2.
[^] # Re: J'ai du mal à comprendre
Posté par aurel . Évalué à 3.
[^] # Re: J'ai du mal à comprendre
Posté par gnumdk (site web personnel) . Évalué à 7.
# Lien vers la discussion du forum
Posté par dave . Évalué à 4.
http://chakra-project.org/bbs/viewtopic.php?id=2688
Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.
# Rolling release
Posté par vincent_k (site web personnel) . Évalué à 4.
Mon dieu, une rolling release pour utilisateur lambda.
Haha
[^] # Re: Rolling release
Posté par Grunt . Évalué à 1.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Rolling release
Posté par B16F4RV4RD1N . Évalué à 4.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Rolling release
Posté par imr . Évalué à 7.
Au final on obtient quelque chose qu'on peut avoir avec une distro normale, garder sa distro dans une version stable et mettre une source "instable" de KDE pour avoir un KDE backporté de la version suivante, ce qu'ils appellent "rolling". Perso, c'est ce que je fais, et je mets à jour mon KDE tous les jours sans soucis.
Par contre, la différence qui n'est pas évidente à première vue, c'est que le core lui est mis à jour tous les ans au lieu de 6 mois. Donc au final, il a la possiblité d'être plus stable que les distros "6 mois", à condition qu'on puisse le garder et qu'il soit maintenu au delà de ces 6 mois. Ce qui n'est pas évident vu l'esprit "rolling distro" arch et leurs ressources. On verra.
[15:37:47] ok, to start: i think at least some of you have noticed that arch linux is a fine platform for what we want to deliver, but there are some little "annoyances"
[15:37:50] mainly:
[15:37:59] -.so bumps every few weeks
[15:38:25] -the general "freshness"
[15:38:37] -a lot of manual interaction needed (sometimes)
[15:39:14] everyone can see these problems when looking at the forums, _most_ of them are related to updates
[15:40:57] in one sentence: to do what we really want to do, we need a stable platform.
[15:44:01] <drf__> exactly. boom1992, the problem funkyou is trying to address is not the fact that arch is breaking on us, but that the rolling release model of arch is not suitable for what we want to achieve
[15:44:20] drf__: so what do we wnat to archieve? :)
[15:44:26] <drf__> basically
[15:44:30] <drf__> a half-rolling release model
[15:44:53] <drf__> so, having as funkyou said, a stable platform, which would be a "freezed" core
[15:45:04] <drf__> and on the top of that, our packaged kde+dependencies
[15:45:08] <drf__> rolling
[15:45:49] <drf__> to provide a stable system to users, which is exactly what we miss now. updates are breaking stuff and some times you need to do manual intervention
[15:46:04] <drf__> and that's also why ras0ir is here I suppose :)
[15:46:16] <drf__> there is a project called archserver
[15:46:25] <drf__> which is doing almost exactly what I told you
[15:46:46] <drf__> for everyone: http://www.archserver.org/
[15:47:20] <drf__> yes, definitely ras0ir could explain everyone better what archserver is and what they are trying to achieve
[15:47:48] ok let me tell some about archserver
[15:48:20] as you know, a server needs more stable packages compared to the rolling releases
[15:48:57] so we've decided to create a stable one
[15:49:04] stable as in debian or centos etc.
[15:49:30] we are thinking of releasing new versions a periodic basis
[15:49:37] on a*
[15:49:53] until a new release, we only get security patches to packages
[15:50:10] ras0ir: are you taking pkgbuilds an building it or you just using the binaries from arch repos?
[15:50:35] jofko: taking pkgbuilds and build them
[15:50:46] we're not taking binaries from arch repos
[15:52:22] How often does this 'release cycle' happen ?
[15:53:50] djszapi: it's not decided yet, but it'll be one release per year
[15:54:49] we might need to add some newer libs etc if needed on top of that when kde needs it ...
[15:55:57] so far there are 2 ideas:
[15:56:01] do the same like the archserver guys = sync core/extra/etc from arch once in a time and apply only bug-/security-fixes
[15:56:41] or (a small variation): work together with the archserver guys on their [server-core] and use that combined with timed snapshots from arch [extra]
[15:57:53] second sounds better for me since they do it a little longer than we ;) and we can trade code and devs
[15:58:03] <drf__> I favor the second option
[15:58:25] <drf__> of course some packages will diverge (kernel for example) but we already do that
[15:58:40] here is the whole idea: http://chakra-project.org/temp/core.png
[16:00:15] 1. we can strip down the archserver core a little bit, i am down at 155 pkgbuilds for [core]
[16:00:38] 2. the dependencies needed for kde: ~300 packages
[16:01:04] (this is with gtk/wx/tk etc, i guess we can strip that down quite a lot)
[16:02:00] funkyou: we can't? as we're not in sync with arch anymore?
[16:02:26] boom1992: well, thats the main thing: it wont be arch anymore, everything will be at our repos
[16:03:12] <drf__> boom1992: it's much more feasible than what appears - "extra" packages out of kde stuff would be handled in a slightly different way
[16:03:24] <drf__> and it will also be possible to sync with arch binaries
[16:04:05] <drf__> we have a ~year of a stable platform (and with platform I mean kernel 'n stuff)
[16:04:15] <drf__> and on the top of that, everything else rolling
[16:05:03] and the "everything else" wont be much, we will do it for kde only, no gtk, no other gui stuff, just based on Qt
[16:05:16] so we stick for example with kernel 2.6.32 series when arch has 2.6.35 for example
[16:05:17] <drf__> it's really not much more than what we do now
[16:05:32] we just take real control over releases
[16:05:45] <drf__> and if you consider the manpower which gets lost in fixing stuff during updates, you have the exact manpower needed for performing the additional packaging
[16:05:48] and I don't have all the troubles I've now with live-cds
[16:08:52] <drf__> do not make stuff "rolling" for the sake of having it rolling
[16:09:00] <drf__> but make stuff roll if it's feasible
[16:09:12] <drf__> now, suppose for a moment there is a conflict in package xyz
[16:09:18] <drf__> or an update on that breaks the whole kde
[16:09:29] <drf__> simply we don't sync that package any longer
[16:09:36] like X or so
[16:09:40] <drf__> the good thing about kde is that we won't have problems with so versions
[16:09:54] it all boils down to what we want: kde on an all-purpose platform (like arch) or KDE on a platform made for KDE (what we would do)
[16:09:54] <drf__> since we can rely on backends that work with older software (take policykit for example)
[16:10:32] for example I need older aufs2 to get livecd working
[16:10:35] <drf__> of course the goal is to deliver a stable platform, and update whenever possible
[16:10:52] <drf__> and to tailor this for
[16:15:39] "Our goal with Chakra is to provide a operating system for desktops that is easy to use, but still has all the functionality, clarity, power and speediness of a KISS operating system. In the long term, we want to build an operating system based on Arch Linux that meets most requirements desktop users have today, like easy installation of software, graphical system administration, configuring power management on mobile devices or sharing an internet connection."
[16:25:18] <drf__> so basically what I want to tell you is an idea that appears bad and controversial, but I urge you to let me finish before any critics :)
[16:25:40] <drf__> to the point: arch's pacman is no longer suitable for us.
[16:25:45] <drf__> now to the explaination
[16:25:53] <drf__> I know pacman pretty well - I hacked the shit out of it
[16:26:25] <drf__> aqpm "kinda" works, but will never be perfect. The problem with it is that simply libalpm is created to be run on a terminal, in a single-threaded blocking program
[16:26:30] <drf__> not really our use case
[16:26:54] <drf__> however, there is one good thing in all of this: pacman is extremely simple, and creating a clone is a matter of nothing
[16:27:02] <drf__> so basically, what is the idea?
[16:27:12] <drf__> create a "pacman clone" in Qt, with some added goodness
[16:27:27] <drf__> like a real database
[16:27:34] <drf__> (sqlite)
[16:27:47] <drf__> hooks in addition to scriptlets, mimetype associations and stuff
[16:28:40] <drf__> now, after some talks with funkyou, we also found out some stuff about bootstrapping and dependencies
[16:28:44] <drf__> this is the main idea
[16:28:52] <drf__> having a 2-level package manager
[16:29:39] <drf__> a library handling transactions (install, remove, stuff), and one handling sync operations (download, etc). Both would be very small and I already have a somewhat working POC. Guess what, it's smaller than aqpm and it manages to handle arch's packages basically
[16:29:56] <drf__> so we're to the point where still remains the problem of third party software
[16:30:16] <drf__> boom1992 was right: if we want to distribute firefox, but we don't package gtk and gecko, what the hell?
[16:30:25] <drf__> I have a solution for this, and it's called bundle
[16:30:53] <drf__> I'm studying a bundle system (integrated with the package manager) which would also be able to take binaries from arch's packages
[16:31:19] <drf__> so basically we would have third party software handled in a single file representing a filesystem (more or less like mac os)
[16:31:40] <drf__> and handle everything "extragear" this way.
[16:32:07] <drf__> in the bundle system? There's no KISS, but your system stays extremely clean and simple
[16:32:22] <drf__> and I can assure you the code needed for all of this is extremely simple
[16:32:35] <drf__> implementing this stuff seems hard, but it's really not
[16:34:15] drf__: so we need to "unpack" a program every time we run it?
[16:34:28] boom1992: no, we just mount an image i guess :)
[16:34:39] every freakin run
[16:34:41] sucks...
[16:34:48] and remember performance...
[16:36:12] <drf__> boom1992: why? trust me, bundles are just as fast as anything else
[16:36:12] and deps as well
[16:36:22] <drf__> boom1992: no deps, it's a bundle because of that
[16:36:37] drf__: so we go back to windows way to have deps installed like hundreds of times...
[16:36:39] <drf__> it is completely self contained except from system libraries
[16:36:44] we have gtk installed 4 times or wut?
[16:36:45] all the deps goes in the bundle
[16:36:48] <drf__> exactly
[16:36:57] firefox will be one pkg with all needed in it.
[16:37:02] yes so we have gtk installed 4 times for 4 differeent gtk progs
[16:37:12] <drf__> what is -not- present in our repo will go into the bundle
[16:41:04] <drf__> boom1992: ah, and bundles also have a strong plus: security
[16:41:11] <drf__> because everything is sandboxed
[16:40:23] so basically our goal is to get from distrolet -> distro
[16:40:36] yes, for the sake of our mission :)
[17:04:39] <drf__> the whole point is that I'm not saying this things just because I like to reinvent the wheel, and you know it, given what I do in kde
[17:05:00] <drf__> it's just because - if we want to reach the goal we have, we have to do some brave decisions
[^] # Re: Rolling release
Posté par Grunt . Évalué à 2.
Mais c'est génial \o/
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Rolling release
Posté par imr . Évalué à 5.
Non, ils vont faire une base stable, c'est à dire une base pas du tout rolling, puisque rolling se traduit par instable/en développement quand on croit pas tout ce qui est écrit sur internet.
Elle sera aussi solide que arch l'est au moment où ils la figeront plus le travail qu'ils pourront fournir en fonction de leurs ressources moins le travail que va demander la mise au point de leurs outils moins le fait que ces outils vont avoir une phase de développement ou ils ne vont être ni solide ni stable, voire pire (genre "aaaaah ma bdd sqllite est corrompue, je peux plus installer ou désinstaller!!! keskejefait?").
Inutile de te dire que les probabilités que ce soit aussi stable ou solide qu'une des distros qui existent actuellement sont quasi nulles avant longtemps mais on peut espérer.
Enfin, pour des utilisateurs de arch, ça devrait pas leur faire peur, et ça ne peut qu'être plus stable.
avec une interface "cutting edge".
Oui, comme tout le monde qui a une distro, sauf qu'eux ils peuvent choisir en plus les paquets stables voire les paquets super stables supportés pendant x années.
Mais c'est génial \o/
Oui, ça s'appelle une distro! C'est fou!
Un truc de dingue qui est pas foutu en l'air quand xorg ou le kernel ou les drivers intel ou autres subissent une évolution. Et qui a aussi une version "rolling" pour les masochistes et les contributeurs qui s'appelle la version de développement!
C'est de la bombe, bébé!
# Précisions
Posté par Dr BG (site web personnel) . Évalué à 4.
# ubuntarch
Posté par nomorsad . Évalué à 1.
Finalement, on peut penser que ce genre précis de fork semble s'imposer aux distributions phares. Probablement que les distributions pur geek ont besoins à un moment donné de s'ouvrir aux utilisateurs qui utilisent leur ordinateur pour autre chose que le dev ou le test.
Moi je dit pourquoi pas, mais je resterai quand meme auprès de mon Arch !
# C'est vraiment dommage.
Posté par MCMic (site web personnel) . Évalué à 2.
Je sais plus quoi faire xD
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.