KaOS

@cellix
D'une condition, en l'occurence un fichier mhwd-x86_64.conf à placer dans /etc dans l'overlay idoine pour "rebuilder" une iso en pur 64 bits & qui est traité par /usr/bin/mhwd-gpu à l'install (& dont je me demande d'un coup si il n'aurait pas à voir avec l'installation//ou pas du pilote graphique sur une compatible 32 bits depuis la net-install, mais c'est une autre histoire...)

Effectivement, j'ai toujours rien compris ! :rigole:

Et d'un, il n'y a pas de mhwd sur KaOS, et de deux, je ne vois pas comment on pourrait "rebuilder" KaOS en 32bits, strictement aucun paquet présent dans les dépôts n'étant prévu en 32 bits… :saispas:

@ T... : Tu peux tenter, effectivement. Tiens-nous au courant des résultats.

cellix a écrit :Effectivement, j'ai toujours rien compris !
Et d'un, il n'y a pas de mhwd sur KaOS, et de deux, je ne vois pas comment on pourrait "rebuilder" KaOS en 32bits, strictement aucun paquet présent dans les dépôts n'étant prévu en 32 bits…

@ T... : Tu peux tenter, effectivement. Tiens-nous au courant des résultats.

Cellix : fassil parle pour manjaro. Il faut que tu apprennes à décoder le fassilien :rire

Faudra me donner des cours accélérés, alors… :rigole:

Rejette un oeil au post original, j'ai édité/souligné ce qui manquait pourqu'il soit + clair :clindoeil:

cellix a écrit :À tes risques et périls : contrairement à Manjaro, KaOS n'est pas basé sur Arch.

je croyais qu'elle était basée sur Arch et utilisait ses dépôts. effectivement, dans ce cas, il vaut mieux ne pas utiliser un multilib qui n'a pas les mêmes versions de softs que le dépôt principal.
elle est basée sur quoi au fait ? et quels dépôts elle utilise ?
d'un autre coté, s'il y a un arbre ABS quelque part pour cette distro, ça doit être faisable assez simplement de se créer un dépôt local avec quelques lib32.

Loubrix a écrit :je croyais qu'elle était basée sur Arch et utilisait ses dépôts. effectivement, dans ce cas, il vaut mieux ne pas utiliser un multilib qui n'a pas les mêmes versions de softs que le dépôt principal.

Toi, t'as pas lu la FAQ ! :rire

http://kaosx.us/fr/faq/#KaOS_nrsquoest- ... _de_Chakra

Loubrix a écrit :elle est basée sur quoi au fait ? et quels dépôts elle utilise ?

Comme dit dans la FAQ, elle est basée sur rien du tout (From Scratch) et utilise ses propres dépôts. Ce qui explique le peu de paquets et quelques sacrifices nécessaires comme l'absence de support du 32bits qui nécessiterait un boulot monstre pour une si petite équipe.

Loubrix a écrit :d'un autre coté, s'il y a un arbre ABS quelque part pour cette distro, ça doit être faisable assez simplement de se créer un dépôt local avec quelques lib32.

Il y a toujours possibilité, mais maintenir la centaine de paquets nécessaires pour la lib32, c'est quand même colossal. Et vaut mieux s'équiper d'une bonne machine, dans ce cas, parce que la compilation risque de prendre un bon bout de temps.

@fassil: Bah voilà, ça change tout ! Bon, bah pour te répondre, il n'y a pas d'équivalent. :gsourire:

d'un autre coté, si c'est juste pour un pilote d'imprimante, il doit falloir une ou deux lib: c'est pas la mort à compiler en 32, et si les versions sont correctes, on peut aussi aller les piquer dans le dépôt Arch à la main, sans ajouter le dépôt.

Je pense que j'avais déjà essayé ça mais ça n'avait pas fonctionné.

Le clip du moment avec le groupe KaOsX :siffle

by Gource

Jolie et sympa au début, après, un longuet et répétitif! Merci

surtout que dans un dépôt où il n'y a pratiquement que des PKGBUILDs, c'est assez monotone...

sinon j'ai testé KaOS: force est de constater que le Kf5 embarqué dedans (j'ai pris la dernière ISO) est particulièrement stable et performant; on sent bien la différence quand les devs se concentrent sur un seul environnement (d'ailleurs, j'ai piqué le thème Midna pour installer chez moi, tant il est vrai que les thèmes pour Kf5 sont encore rares).
pour le coeur, j'ai le même reproche à faire que pour Manjaro: les noyaux sont trop patchés, c'est plus KISS du tout; d'ailleurs je capte pas tout: je comprend que pour le live on a besoin d'AUFS, mais à ce moment là, autant compiler deux noyaux, pour ne pas devoir embarquer les patchs AUFS dans un noyau installé en dur.
je suis un peu plus dubitatif sur KCP. autant je comprend qu'ils veuillent avoir leurs propres dépôts, vu la particularité technique de la distribution, mais le dépôt KCP (équivalent de AUR) me semble inutile: il est trop peu achalandé et je pense qu'utiliser AUR aurait pu convenir; d'ailleurs, je suis me demandé pourquoi les PKGBUILDs n'étaient pas signés, et pourquoi certains n'ont pas de dépendances.

Pour répondre à tes questions :

1. Concernant AUFS. Certes, cela n’est pas particulièrement utile pour le système une fois installé. Mais entre créer deux noyaux (l’un sans patch, l’autre avec) n’est pas particulièrement KISS non plus, d’autant qu’il faudrait maintenir les deux en parallèle. Et cela compliquerait également l’installation du système, le live devant dans ce cas posséder les deux noyaux, et il devrait y avoir un module supplémentaire dans calamares pour supprimer le noyau patché après copie des fichiers… Dans tous les cas, ce serait contraire à la philosophie de KaOS qui consiste à maintenir le moins de paquets possible.

2. Concernant KCP. Comme tu le dis, KaOS est beaucoup trop différent de Manjaro/Arch Linux pour pouvoir utiliser AUR, d’où un dépôt spécifique. Quant au fait qu’il soit peu fourni, il faut rappeler qu’il est encore jeune (il a peine plus d’un an) et les utilisateurs de KaOS sont nettement moins nombreux que ce d’Arch et dérivés. Les PKGBUILDs ne sont pas signés car il n’y a tout simplement pas de mainteneur désigné pour tel ou tel PKGBUILD. Tout un chacun peut maintenir/créer un paquet. De plus, l’utilisation de github permet d’avoir un historique très précis des modifications et savoir qui a fait quoi. Quant à l’absence de dépendances, probablement que certains n’en ont pas besoin. Pour le reste, KCP souffre du même défaut de base qu’AUR : il s’agit d’un dépôt communautaire, d’où une qualité inégale des PKGBUILDs suivant les personnes qui l’ont créées. À charge pour la personne qui installe un paquet depuis KCP de bien vérifier des fichiers d’installation et de les modifier si nécessaire. Concernant l’application kcp (équivalent de yaourt), elle présente une sécurité, par rapport à sa consœur, de ne gérer strictement QUE les paquets communautaires, et ne peut en aucun cas servir pour la mise à jour et l’installation des paquets officiels ou toute autre opération gérée par pacman (suppression de paquet, gestion du cache, etc.). En effet, les utilisateurs étant, de manière générale, peu enclins à lire les sorties du terminal (tout comme la documentation, d’ailleurs), il n’y a aucun risque de confusion entre les paquets des dépôts officiels (contrôlés, vérifiés, testés) et les paquets communautaires (par définition non fiables).

créer deux noyaux (l’un sans patch, l’autre avec) n’est pas particulièrement KISS non plus, d’autant qu’il faudrait maintenir les deux en parallèle

pas nécessairement, le noyau du live n'a pas besoin d'être renouvelé aussi régulièrement, ni de suivre les évolutions upstream...

il devrait y avoir un module supplémentaire dans calamares pour supprimer le noyau patché après copie des fichiers

c'est tout le problème des live-CDs qui installent par extraction d'un squashfs, au lieu d'installer des paquets contenus dans le CD (comme chez Debian par exemple): il faut ensuite enlever tout ce qui ne servait que pour le live.
cela dit, il me semble bien qu'à la création du live, il est possible de ne pas inclure un certain nombre de choses dans le squashfs (ceux qui maitrisent Manjaroiso confirmeront, ou pas).
évidemment, c'est une critique qui concerne aussi Manjaro; et du coup on comprend mieux pourquoi chez Arch ils préfèrent ne pas se prendre la tête avec un installateur.

Quant à l’absence de dépendances, probablement que certains n’en ont pas besoin.

pour les 2 ou 3 paquets dont j'ai regardé les PKGBUILDs, normalement, des dépendances étaient requises; d'ailleurs j'ai comparé avec ceux de AUR, pour les mêmes logiciels (mêmes sources) pour m'en assurer (et aussi pour voir ce qui pouvait différencier KaOS sur ce point). mais les rubriques "depends" étaient vides...
sur une distro où les dépôts officiels sont allégés, le dépôt communautaire prend une importance particulière, et c'est dommage que ça ne soit pas plus surveillé. un logiciel dont les dépendances manquent s'installera très bien, mais il ne fonctionnera pas, ce qui a de fortes chances de décourager les nouveaux venus.

Concernant l’application kcp (équivalent de yaourt), elle présente une sécurité, par rapport à sa consœur, de ne gérer strictement QUE les paquets communautaires

je ne l'ai pas essayé, n'ayant pas encore eu le temps; mais Yaourt n'est pas le gestionnaire pour AUR, et certains autres ne prennent en charge que AUR.
tu veux dire qu'un paquet installé par Kcp doit être désinstallé par Kcp aussi, que Pacman ne peut pas le faire ?

'LLo,

cellix a écrit : Concernant l’application kcp (équivalent de yaourt), elle présente une sécurité, par rapport à sa consœur, de ne gérer strictement QUE les paquets communautaires, et ne peut en aucun cas servir pour la mise à jour et l’installation des paquets officiels ou toute autre opération gérée par pacman (suppression de paquet, gestion du cache, etc.). En effet, les utilisateurs étant, de manière générale, peu enclins à lire les sorties du terminal (tout comme la documentation, d’ailleurs), il n’y a aucun risque de confusion entre les paquets des dépôts officiels (contrôlés, vérifiés, testés) et les paquets communautaires (par définition non fiables).

J'agrèe totalement avec ça, l'usage de yaourt (ou kcp) ne devrait s'effectuer qu'en dernier recours quand la voie/dépôt officiel répond absent. Outre l'inégalité de qualité de paquetage, il y a aussi à terme le risque que le mainteneur aille maintenir ailleurs...
Du coup l'activation de yaourt par défaut dans pamac n'est pas terriblement judicieuse à mon sens & personellement j'ai enlevé le "côté bulgare de la gestion de paquets" dans l'iso "net-mais-graphiquE" sur lequel je m'amuse en ce moment :siffle

Ps: Avec manjaroiso, je laisse déjà pas mal de choses inutiles à mon sens (& dans une optique laptop) ne pas s'installer -> les systèmes de fichiers alternatifs (btrfs, reiserfs, ect... + lwm + raid, ect..) mais aufs ne m'a jamais embêté outre-mesure ?
Avec manjaro-tools, pareil & celui-ci permet en + de ne garder certains utilitaires précieux comme gparted par exemple qu'en llive ( bien qu'avec calamarès & en mbr pour l'instant, plus besoin :bien

).

Loubrix a écrit :c'est tout le problème des live-CDs qui installent par extraction d'un squashfs, au lieu d'installer des paquets contenus dans le CD (comme chez Debian par exemple): il faut ensuite enlever tout ce qui ne servait que pour le live.
cela dit, il me semble bien qu'à la création du live, il est possible de ne pas inclure un certain nombre de choses dans le squashfs (ceux qui maitrisent Manjaroiso confirmeront, ou pas).

Entre un Debian qui met des plombes à s’installer et une distro utilisant squashfs qui torche le boulot en une dizaine de minutes, mon choix est vite fait :siffle

Il est probable qu’il soit possible de ne pas inclure certaines choses dans squashfs mais si tel est le cas, je ne suis pas sûr que ce soit plus rapide que la méthode utilisée actuellement (squashfs puis suppression de ce qu’on ne veut pas).

sur une distro où les dépôts officiels sont allégés, le dépôt communautaire prend une importance particulière, et c'est dommage que ça ne soit pas plus surveillé. un logiciel dont les dépendances manquent s'installera très bien, mais il ne fonctionnera pas, ce qui a de fortes chances de décourager les nouveaux venus.

Si tu penses cela, c’est que tu n’as vraiment pas compris la philosophie de KaOS. Si tu as besoin de plus de 3-4 paquets présents dans le dépôt communautaire, c’est qu’il y a un problème et que KaOS n’est pas fait pour toi. Je sais bien que l’on ne peut interdire le péquin moyen d’utiliser un dépôt communautaire, il n’empêche que cela ne devrait être utilisé que par ceux qui connaissent un minimum et c’est valable pour AUR également. Quant à surveiller, les quelques grosses erreurs évidentes le sont, pour le reste, c’est au créateur/aux mainteneurs des PKGBUILDs de s’assurer que leurs paquets fonctionnent. KaOS ne peut pas s’amuser à tester un dépôt communautaire dont il ne se sent nullement responsable.

je ne l'ai pas essayé, n'ayant pas encore eu le temps; mais Yaourt n'est pas le gestionnaire pour AUR, et certains autres ne prennent en charge que AUR.

Je parlais de yaourt parce que c’est la plus utilisée (et la seule supportée dans octopi, d’ailleurs, aarnt ayant abandonné le support de pacaur).

tu veux dire qu'un paquet installé par Kcp doit être désinstallé par Kcp aussi, que Pacman ne peut pas le faire ?

Non. Relis bien ce que j’ai écrit plus haut

cellix a écrit :
tu veux dire qu'un paquet installé par Kcp doit être désinstallé par Kcp aussi, que Pacman ne peut pas le faire ?

Non. Relis bien ce que j’ai écrit plus haut

oui donc c'est bien ce que j'avais compris (j'ai eu un doute par rapport à la formulation): Kcp installe et met à jour les paquets du dépôt communautaire, mais pour désinstaller, il faut utiliser Pacman...

Entre un Debian qui met des plombes à s’installer et une distro utilisant squashfs qui torche le boulot en une dizaine de minutes, mon choix est vite fait

disons que c'est plus long, mais le choix des paquets à installer peut-être fait de façon plus fine, en fonction de la machine sur laquelle on installe (en évitant d'installer par exemple laptop-mode si on n'a pas affaire à un portable).
c'est d'ailleurs assez contradictoire: sur une distro qu'on est appelé à remplacer régulièrement à chaque nouvelle version, on attendrait une install rapide; à l'inverse, sur une rolling qui par définition ne sera installée qu'une fois, on se fiche que ce soit long...

Je sais bien que l’on ne peut interdire le péquin moyen d’utiliser un dépôt communautaire, il n’empêche que cela ne devrait être utilisé que par ceux qui connaissent un minimum et c’est valable pour AUR également.

ce qui m'amène à un problème bien plus général: des distributions comme KaOS ou Manjaro ouvrent leurs portes à des débutants qui ne veulent pas s'embêter à lire de la doc, grâce à un processus d'installation très simplifié, mais après, on leur donne l'accès à des choses qu'on ne devrait pas utiliser sans comprendre ce qu'on fait et sans lire un minimum de choses.
c'est un peu comme si je donnais la main à un enfant pour lui faire traverser la rue, mais qu'arrivé au milieu, je le lâche et le laisse se débrouiller avec la seconde moitié.
si on ne veut pas encadrer les utilisateurs sur l'utilisation des dépôts communautaires, autant ne pas leur donner l'accès à ce dépôt (du moins pas facilement), d'autant que comme tu le dis par ailleurs, si on ne trouve pas son bonheur dans les dépôts officiels, c'est probablement qu'on s'est trompé de distro.

ça peut ressembler à de l’extrémisme façon Arch dit comme ça, mais je vois tellement de problèmes engendrés par l'installation de paquet AUR en lieu et place du paquet officiel (pourtant disponible), parfois même sans s'en rendre compte (merci Octopi de supporter AUR), que je me demande si ce n'est pas contre-productif dans notre démarche de donner un accès facile à une rolling...

des distributions comme KaOS ou Manjaro ouvrent leurs portes à des débutants qui ne veulent pas s'embêter à lire de la doc, grâce à un processus d'installation très simplifié, mais après, on leur donne l'accès à des choses qu'on ne devrait pas utiliser sans comprendre ce qu'on fait et sans lire un minimum de choses.

Evidemment... Encore qu'un jeune automobiliste fraichement "permisé" doit bien faire ses armes sur les routes et sans personne à côté de lui.
Quand on débute dans le monde Linux et qu'on se sèvre des distros clés-en-main comme LinuxMint ou Ubuntu ,faut bien mordre un peu les bas-côtés pour se forger son expérience. Bien sur, ça ne dispense personne de zapper les docs :clindoeil:

Quant à rendre plus pointu l'accès aux dépôts exotiques, Gogole sera là pour contourner la difficulté.

En même temps, on ne peut pas être derrière tous les utilisateurs pour les forcer à lire la documentation. Tout a été fait, côté KaOS, pour faciliter la compréhension, mais les utilisateurs ne lisent pas pour autant. C’est leur problème, après tout, et s’ils flinguent leur système, qu’ils ne viennent pas pleurer. Quand je vois que certains débutant installent les ISO de test (sans, évidemment, prendre la peine de lire les recommandations et les known issues) en les prenant pour des stables et viennent ensuite chouiner sur le forum parce que “ça ne marche pas”…

Ça y est, je peux le dire, c’est officiel : KaOS migre définitivement sur KF5 dès demain !
http://kaosx.us/fr/kf5-move-kde-4-removed/