Longtemps que je ne suis plus le projet (malheureusement, en effet je suis énormément occupé par Cream-Browser qui avance grandement). Mais que de belle avancées je vois :)

N'oubli pas de développer le coté serveur de Logram, je n'ai pas encore trouvé la distrib que je metterai sur le mien Si tu me propose une belle suite d'outil pour mettre en place un serveur web j'en ferai la promotion :)

linkdd: j'ai pourtant déjà dit qu'un des buts principal de Logram est de ne surtout pas être serveur . Jamais ne n'accepterai le moindre patche augmentant un aspect serveur en diminuant l'aspect «normal»

Bon, bien entendu, si des améliorations d'un aspect sont profitables à un autre, je ne suis absolument pas contre .

Donc je doute que Logram conviennent pour un serveur critique, même si c'est vrai que pour un serveur perso, y'aura normalement pas de problèmes et tu pourras jouer avec Setup .

Ce que tu ne semble pas comprendre, c'est que créer un paquet ne change pas l'orientation du projet.

Si tu créé un paquet lighttpd, un postgresql et un paquetcompliquépourmmemichu, ca va pas pour autant faire de Logram un truc compliqué. Il faudra juste que l'user qui veut installer ces logiciels sache comment les utiliser. La question était pas "fait moi un Logram Server", mais "Pourrais tu m'empaqueter quelques logiciels pour que je fasse un serveur sur mon pc ?".

A prendre au second degré bien sur, car je n'ai qu'a les empaqueter moi même (après tout je suis un packager xD)

C'est ce que je dis .

Je ne suis pas contre créer un paquet, mais le genre de patch (typiquement du noyau) qui ralentit l'utilisateur normal en privilégiant l'utilisateur serveur, ça non. Pas de SELinux dans Logram par exemple, et pas question de virer BFS du noyau, etc.

Et pourquoi pas proposer des paquets qui appliquent ces patchs ? Ce que fait par exemple Ubuntu/Debian/etc...

Des paquets avec des dépendances de type "replace" (genre linux-image-server qui remplace linux-image) ?

Mouais, possible, mais on n'en n'est pas encore là .

Par exemple, mais si la chose est bien géré, par exemple un diff de binaire qu'on applique parfaitement bien ca pourrait rendre l'installation bien plus rapide.

On pourrait donc "tagguer" les paquets :

• linux-image | Available tags : server (off), patch1854 (on)

setup tag linux-image server=on patch1854=off

• Accès à la base de donnée, application d'un patch "binaire"

Il me semble que ce serait plus rapide que de désinstaller linux-image et d'ensuite installer linux-image-server et ca laisserait plus de place sur le dépot et moins de choses à télécharger.

Idée à développer (peut-être une mauvaise idée très mal pensé dailleurs, venant du fait que j'y pense en rédigeant ce message).

Pour l'utilisateur, c'est effectivement une bonne idée, mais côté code, il faudrait ajouter 10k lignes pour que ça marche .

Déjà, les deltas, on n'est pas encore prêt à les avoirs (y compris pour les mises à jour), sauf si on se contente d'un XDelta incompressable en XZ ou de bsdiff, lui aussi incompressable (les deux compressent eux-mêmes en Bzip2).

Ensuite, déclencher un tel traitement (téléchargement et application du patch) au taggage d'un fichier est un peu spécial, surtout qu'il faut gérer le cas ou l'utilisateur met à on les deux tags, et que les patches sont en conflits (comment détecter ça ? Il faut des deltas énormes contenant des lignes de contexte comme les deltas textes ?).

Donc bonne idée, truc pas mal, mais entre une solution qui prend 10s et une qui prend 1s mais qui va ajouter 30 bugs et du bloat dans Setup, je préfère l'élégante première .

[Errata : je fais mon chieur, mais c'est pour la bonne cause]

qu'ils sont les meilleurs qu'ils peuvent

qu'ils soient le mieux possible/qu'ils soient de la meilleure qualité possible

incompressable

ce mot n'existe pas. => incompressible

pas encore prêt à les avoirs

pas encore prêt de les avoir

[Réponse au sujet]

Je pense que pour rendre une distribution populaire, il faut qu'elle soit adaptée aux besoins de tous. Je ne parle pas d'un immense corpus de paquets qui deviennent plus lourds chaque fois qu'on les adapte à un utilisateur cible, mais bien d'un système modulaire, qui propose des solutions personnalisées et performantes.

Ce que propose linkdd me paraît intéressant, pourquoi ne pas l'étendre ensuite à des besoins très spécifiques ? Du style Musique Assistée par Ordinateur ? => nécessité d'un noyau temps réel... Après le taggage des paquets n'est peut-être pas la meilleure solution, peut-être faut-il opter pour l'ajout de paquets "noyau serveur", "noyau mao"... ? (est-ce bien ce que tu suggères en fin de post Denis ?)

Pour les paquets debug, ne pas en avoir va surtout alléger les dépots :)

Pour les deltas où en sont tes recherches ? Si tu patches Clang ça te permettra des les implémenter ensuite ?

Jk.