vlamy a écrit 751 commentaires

Il répertorient des choses diverses et variées sur la liste des ateliers constituant, mais j'avoue qu'il y a beaucoup de choses autour d'Etienne Chouard.

En cherchant bien, je suis sûr que je trouve une dizaine de journaux LinuxFr (ou plutôt séries de commentaires attenants) qui pourraient rentrer dans cette liste.

Chut ! Je le dis pas trop fort, on sait jamais.

Attends j'ai précédé de : « si tu as de la chance » :) Je ne peux pas garantir que la dépêche va intéresser tout le monde, en particulier les « bons relecteurs ».

Mais à priori on sera déjà 2/3 à t'aider, au moins. Et n'hésites pas à laisser la dépêche quelques temps, pour qu'elle puisse se parfaire, vu que la publication n'est pas urgente.

Je me suis fait la même réflexion : « c'est presque autant abstrait qu'un discours politique ».

• Wiki sur la rédaction de dépêche
• Tribune de rédaction pour commencer la dépêche en cliquant sur le gros bouton à droite comportant la mention « Commencer une nouvelle dépêche ».

Allez ! J'insiste sur le fait que ça serait bien que tu crées la dépêche, ça te laissera le contrôle sur la soumission en modération.

J'apporte la structure et on regarde à plusieur pour la mise en page par exemple

Oui et surtout, si tu as de la chance, tu va avoir l'aide de vrais « grammar nazis » et autres stakhanovistes de la mise en page : il n'y aura pas une faute d'orthographe ni un espace insécable manquant :) Enfin si tu as de la chance :) C'est ça le vrai kif de la dépêche LinuxFr : un travail de « qualitay » !

PS : en bonus tu pourras récupérer le source Markdown de la dépêche.

En fait, Wikipedia en parle mieux que moi ;)

Une œuvre peut tomber dans le domaine publique, et cela signifie que le créateur (ou plutôt ses descendants, en l'occurrence) n'aura plus de droits patrimoniaux dessus. Par contre, il conservera ses droits moraux qui sont de toutes façons inaliénables et intemporels.

Oui et justement il me semble que la volonté de l'auteur ne fait pas partie des conditions pour qu'une œuvre tombe dans le domaine publique, contrairement au droit US. C'est ce que je voulais souligner.

Donc on peut tout à fait céder n'importe quelle œuvre au domaine public en France, c'est juste qu'on en cédera moins que si on le faisait aux US (par exemple).

On est d'accord là dessus. Ce que j'ai cru comprendre (et je serais ravi si quelqu'un pouvait me confirmer), c'est qu'en France, si tu publies une œuvre en licence CC0 ou CC-BY, cela a le même effet (uniquement en droit français).

Je crois qu'avec une licence CC-BY tu peux indiquer que tu autorises les utilisateurs à ne pas mentionner la paternité (et c'est valable en droit français), mais pas avec une licence CC0. C'est pas très facile à comprendre tout ça.

Il faut travailler le paquet xfce4, tu peux suggérer ces modifications au mainteneur je pense. Notamment mettre en dépendance optionnelle les trucs que tu mentionnes.

Le principe d'une dépêche collaborative c'est que ce n'est pas toi qui rédige tout, tu peux donner des directives et la laisser se rédiger pendant 15 jours (ou plus) si il faut.

Le truc important, c'est que c'est celui qui initie la dépêche, qui décide de quand elle est complète et « publiable », après passage en modération bien entendu. C'est pour ça que je dis que c'est mieux si c'est quelqu'un de NuTyX qui commence la dépêche.

L'idée c'est de reprendre les commentaires intéressants de ce journal et d'en faire un article plus propre et avec une plus grand visibilité. Du coup, tu pourrais déléguer :)

Excellent ! C'est donc du « libre sans contre partie », ou disons plutôt du « libre qui me convient ».

En fait je n'avais pas compris l'échelle modeste, mais non moins sans mérite de Devosi. Je voyais un gros service avec pleins de serveurs dédiés ou du gros Cloud cher.

Bref, j'essaie de m'inscrire vite avant qu'il n'y ait plus de place :)

Et… merci !

Salut, je me permet de poser la question qui tue : c'est quoi le « business model » de Devosi ?

Je m'explique : cela me paraît super intéressant, je serais prêt à m'inscrire, mais si je pars sur une solution de type Devosi pour mes mails/fichiers/services hébergés, j'ai envie d'évaluer la pérennité de mon engagement (prendre en main les services, migrer mes données,etc).

Personnellement, je serais prêt à payer pour ce genre de service (si je trouve le prix raisonnable) mais je n'ai trouvé aucune informations à part « service gratuit et sans pub ». Donc je pose la question ici : comment se service est-t-il financé ? est-t-il économiquement pérenne ? Est-il prévu qu'il devienne payant un jours ? si oui, une idée du prix ?

Merci d'avance pour les réponses.

Je pense que c'est très encourageant pour toi : le peuple réclame un deuxième journal !

Le peuple réclame une dépêche collaborative (initiée par un membre de la communauté NuTyX ça serait mieux), pour que la communauté LinuxFr puisse y mettre son grain de sel :)

Une belle dépêche avec tous les points techniques de cards détaillés ça serait une vraie bonne pub pour la distrib.

Le refactoring fichier par fichier c'est pas très puissant.

Je pense qu'un projet comme astyle (cf. commentaire d'Anthony Jaguenaud) est plus pertinent pour refactorer tout un projet. À plus forte raison pour un projet communautaire à plusieurs développeurs (si on tolère les contributeurs qui ne codent pas sous Vim).

Cela n'enlève rien à l'intérêt du :retab, dit en passant.

Tu lances emacs et tu fais un "M-x whitespace-cleanup"

C'est pas plutôt fait pour virer les espaces inutiles ça ?

J'imagine qu'on peut dériver son utilisation au prix de quelques lignes de Scheme :)

Juste parce que la nimage qui explique les écoutes judiciaire est intéressante (et que pas tout le mode cliquera sur le lien). On voit bien notamment que la réquisition judiciaire est simplifiée (plus qu'un seul destinataire), mais on a pas les détails…

Avertissement : je n'ai pas tout compris non plus. Du moins pas encore :)

J'ai compris qu'un truc lisait les binaires directement, mais est-ce à l'installation ou la construction du paquet ?

Je dirais à la construction : pour évaluer les dépendances justement. A l'installation il doit vérifier que ces dépendances dont satisfaites je suppose. Si ce n'est pas le cas, je ne sais pas comment il se débrouille…

Quelles sont les infos rentrés à la main pour le constructeur du paquet ? C'est pour savoir à quel point le travail est réduit ou non.

Les dépendances non « runtime », ou les dépendances optionnelles. Il faut regarder l'exemple du paquet « xorg ». Bon je suis pas 100% à l'aise non plus :)

Cela fait un moment que je me demandais si il était possible de manipuler directement les binaires facilement : pour faire des versions des logiciels statiques sans toucher à leur système de build, pour faire un accélérateur de script : l'idée est de garder en mémoire les binaires linké pour éviter le reload à chaque appel.

Si j'ai bien compris tu veux prelink ? Un peu plus ici.

Mais sauvegarder c'est « has been » ! Sur les IDE Jetbrain (Intellij, Webstorm, Pycharm, RubyMine, etc) : plus besoin de sauvegarder, c'est tout automatique et incrémentale.

Et à vrai dire : c'est juste bluffant !

Merci pour les sources ! Malheureusement je n'ai que très peu d'expérience avec le C/C++, mais au moins on a un lien dans les commentaires maintenant :)

Juste parce que je ne trouve pas : où sont les sources de cards ?

Mon programme make préféré, souvent bmake sous Linux a un mode dit méta qui lui permet de détecter automatiquement les dépendances dans le travail de compilation. Sous BSD un processus peut surveiller les I/O de ses fils grâce à filemon(4) ce qui permet cette détection. On peut appliquer la même stratégie à la préparation des paquets: en épiant les I/O des processus fils, on peut automatiquement détecter la liste des dépendances de production.

Si je résume, je peux « épier » tous les fichiers (y compris les ressources statiques genre icônes, *.jpg, *.mp3) que j'installe avec un classique « make install » ? Où cela ne marche que pour les libs utilisées à la compilation ?

La détection complète des dépendances d’exécution me semble beaucoup plus délicate à réaliser puisque l'examen des bibliothèques liées ne détecte que… les bibliothèques, mais il y a beaucoup d'autres exemples de dépendances.

Tout à fait !

En fait je trouverais presque ça malsain de tout faire automatiquement. Exemple : les « environnements de bureau » qui se reposent sur certaines spécifications freedesktop.org, et qui permettent, de fait, de choisir entre plusieurs implémentations pour un même module (widgets systray, gestionnaire de fenêtre, gestionnaire de connexion, etc). Là on est dans un cas ou on doit laisser le choix à l'utilisateur d'exprimer la dépendance, laquelle peut rester malgré tout obligatoire (par exemple un environnement de bureau n'est pas utilisable sans gestionnaire de fenêtres).

Mais bon, après on est pas obliger de tout faire automatiquement non plus :)

En faite la documentation je l'ai bien mis dans ce journal,

Oui et j'ai tout lu :)

Je disais juste que ça serait bien de mettre ce genre d'info plus accessibles, pour les poweruser (y compris sur votre site).

De toute façon je vous proposerais bien de faire une dépêche collaborative sur NuTyX, plus tard, en tenant compte de toutes les remarques sur le journal :)

Me vendre n'a jamais été mon fort

On peut pas être bon partout ! J'ai la critique LinuxFr un peu rapide, mais aussi constructive que faire se peut. J’espère que vous avez compris que j'essayais d'aller dans votre sens (pas par altruisme, mais parce que ma curiosité à été piquée).

Cards ne s'occupe pas de l'installation. Un script que l'on trouve à l'adresse url:
http://downloads.nutyx.org/install-saravane.ash permet d'installer NuTyX saravane sur une partition ou même dans un dossier sans aucune intervention une fois lancée.

Donc c'est compatible poweruser : ouf !

La commande setup-nutyx (qui est la même dans la MINI et dans la NuTyX installée) permet de:
Configurer la langue
Configurer le réseau
Configurer le clavier
Configurer l'horloge
…

Ha ! voilà des informations intéressantes sur l'installation/administration !

Pour cards, je ne sais pas si il existe un wiki, une doc, un tuto, bref des ressources. Mais en tous cas il mérite beaucoup d'attention, car c'est le cœur de la distribution me semble t-il. On dirait qu'il fait plein de trucs sympa, mais j'aurais des questions plus pointues, bien entendu :)

• Comment je fais un paquet ? J'imagine que c'est la une des forces de cards. Si c'est si simple qu'on peut le penser, un petit exemple (Sébastien a tenté dans un commentaire je crois, mais je ne suis pas convaincu), serait vraiment bien venu.
• Comment sont extraites les dépendances quand je crée un paquet ?
• Quels sont les prérequis pour que cards détecte mes dépendances ? Là je développe : Si j'installe un paquet depuis les sources en modifiant certaines variables de l'installateur du source (par exemple, j'installe dans /opt/usr/lib au lieux de /usr/lib), que se passe-t-il ?
• Comment je peux gérer avec cards deux versions du même paquet (Python2 vs Python3, Ruby1.9 vs Ruby2.0).
• Est-ce que cards gère la signature des paquets ? Si oui comment ?

Bon j'imagine que ces questions ont déjà des réponses, et répondre dans ce journal aurait peut d'intérêt. Par contre un lien sur une FAQ/Wiki/documentation de cards/NutyX qui répond à ces questions, ça permettrait de lever les doutes que je ne suis certainement pas le seul à me poser :)

Sinon, merci pour les réponses. Il n'est pas exclu que j'essaie d'installer NuTyX pour ma prochaine installation Laptop :)

Et courage pour la suite, car cette distribution à l'air d'avoir un vrai plus !

Juste pour dire que je trouve le journal absolument pas clair et pas vendeur du tout (c'est dommage pour la distrib).

En fait je trouve surtout qu'on met en avant les aspects « kikoulol », au détriment des vrais avantages. Ce que je trouve inadéquate pour l'audience moyenne de LinuxFr.

Brève listes des trucs qui me dérangent dans le journal :

• Un paragraphe sur l'installation avec plein de screenshots. Heuu… je tombe sur un tutoriel c'est ça ? Du coup j'ai rien retenu des avantages de l'installeur et je ne sais même pas si card permet d'installer la distrib à partir d'un chroot ou de façon automatisée.
• Un paragraphe sur la commande « nu » : vous résumez l'administration d'un Os Linux à la création d'utilisateur ? Je veux dire c'est bien de simplifier la création d'un utilisateur, mais si la team NuTyX ne se penchent pas sur les autres commandes d'administration : c'est un point négatif à ne pas mettre en avant !
• Plein de screenshot pour épater la galerie : là je me suis dit : « ils me prennent pour un jambon ! ». Aujourd'hui on a le bureau qu'on veut indépendamment de la distrib : donc quel rapport avec les spécificités de NuTyx ? Je parie qu'on peut recréer tous ces jolis bureau sous Archlinux (pour l'exemple). Par contre si vous avez une team de graphistes, des icônes, papiers peints spécifiques,… Là oui c'est un vrai avantage ! Mais j'ai pas compris ça :(
• Dernier point non des moindres le gestionnaire de paquet card : 

Vous pouvez utiliser le système de ports et installer vos propres paquets depuis les sources, ils seront intégrés nativement au système, leur gestion sera transparente. 

J'ai rien compris à la première lecture !

"Ailleurs" rien n'est automatique, c'est le paquet qui déclare les dépendances

Là je me dis : « mais qui déclare les dépendances sur NuTyX ? C'est magique ? ».

Après avoir lu le commentaire de Tnut, j'ai cru comprendre que cela voulait dire : « gestion automatisée des dépendances des paquets logiciels, via un scan du système de fichier existant ». C'est ça ? Si oui : c'est de la tuerie (ou à défaut c'est très intéressant). Expliquez le mieux ! Et surtout dites nous en plus ! Je sais, c'est pas facile à expliquer simplement, mais là pour moi ça reste magique. Un exemple serait bien venu.

Et aussi :

En plus les deps sont eurodatées dans l'archive ce qui permettra (pas encore implémenté mais prévu) de faire un sysup très pointu.

Vas y Tnut ! Fais nous rêver ! Faut nous en dire plus là, on a envie de savoir !

Je fais ce commentaire parce que j'ai l'impression que c'est une distribution qui a vraiment des atouts, mais le journal a eut tendance à me faire penser l'inverse (heureusement que j'ai creusé un peu).

Du coup je me pose d'autres questions :

• Quelle politique vis a vis de l'intégration de logiciel non libres ? codecs ? pilotes ?
• Quel cycle de développement ? Rolling Realease ?

Bref, merci pour le journal !

Encore une fois, cela va à l'encontre d'une démocratie représentative (même si ton idée ne me déplaît pas pour autant).

Ce que tu proposes se rapproche d'un mandat impératif : le programme d'un candidat serait alors un ensemble de lois qu'il s'engage à essayer de faire passer. Et ça pose plein de problèmes insolubles (tirés du problème du principal-agent) :

• Comment tu juge l'élu sur la gestion d'un problème non prévu dans son programme (guerre, catastrophe naturelle, …) ?
• Comment évalue tu les résultats ? Toutes les lois ne sont pas aussi simple à faire passer les unes que les autres, n'ont pas le même poids dans une politique globale, elles peuvent être plus ou moins bien appliquées par l'exécutif en place, …etc
• Comment tu compares deux élus qui proposeraient le même programme ?
• Pour palier aux problèmes précédent : on peut imaginer un système hybride, dans lequel l'élu est représentant (il prend les décisions sans avoir de compte à rendre) pour les cas non prévus dans son programme. Puis il est « mandataire » pour les questions soulevées dans son programme. Le problème est alors : à partir de combien de lois/propositions le programme est-t-il valide ? Comment on mesure le degré de liberté que l'on donne au candidat ? Quel part d'impératif doit-on imposer au candidat ?

C'est pas facile :)

Je te confirme : je demande un plus gros salaire pour travailler sur Windows :)

Je veux un truc payant gratuitement !

C'est du viol !