Qu'Arch compile ou pas n'est pas un gros problème (c'est le problème des utilisateurs de cette distribution), le fait d'incrémenter toujours le numéros de version permet de s'y retrouver que ce soit le (ou les) développeurs ou les utilisateurs. En plus ça permet de stocker sans problème toutes les versions existantes.
Utiliser la date avec seulement le jour il faut être sur de ne pas sortir 2 versions le même jour.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Rien que la requète SQL peut parfois prendre presque une seconde.
Tu peut dire la même chose pour tout et n'importe quoi. Il y a pleins de façons de mal faire du SQL soit parce que la requête n'est pas optimisée, soit parce que la base ne l'est pas (le schéma d'une base joue beaucoup, le fait de créer des indexes, le partitionnement, etc).
Bref tout ça pour dire que ce n'est pas un bon argument « requète SQL peut parfois prendre presque une seconde », une lecture direct de fichier aussi.
De plus lors des bench, il faut prendre en compte les accès aux données, mais aussi leur (dé)serialisation puisque SQL prends aussi cela en charge.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Il n'y a jamais de write concurrent, juste des reads en concurrence. Il y a un lock sur le fichier qui n'est utilisé que pour les write. Si 2 veulent écrire, il y aura un de bloqué.
Excuse-moi j'ai lu les virgules comme une énumération.
Un système de merge est mis en place (via un processus ad-hoc) pour réconcilier ces cas.
Le plus simple ce n'est pas d'avoir un processus qui à la fois alloue les fichier et détecte les conflits ? On lui demande d'accéder au fichier A, il voit la ou les dernières versions de celui-ci, il donne au processus appelant un fichier où écrire et gère le merge de son coté, une fois fait il met à jour tous les pointeurs (du coup je me demande si les pointeurs ne devrait pas être inversés…).
Merci beaucoup pour tes réponses :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Tu parle de faire du CoW, mais comment u vois que tu n'es pas entrain d'écraser une version ? Il faudrait pouvoir vérifier la version que tu écrase au moment où tu l'écrase et je ne vois pas comment faire ça en garantissant qu'il n'y a pas eu de changement entre la vérification et l'écrasement. Pour le cas de SMIT, il est peut être possible de simplement créer des fichiers d'ajout et faire des passes régulière pour agréger les fichiers d'un bug dans un seul fichier (ou surveiller les nouveaux fichiers via inotify – ça reste du Single writer principle –).
La robustesse consiste à continuer à fonctionner malgré les erreurs et les cas limites. Là on se base sur une précondition de l'utilisation pour pouvoir continuer à fonctionner, c'est pas de la robustesse,
Mmh, je ne vois pas de quoi tu parles.
Pour moi la robutesse ce n'est pas de poser une précondition sur la manière dont on utilise le logiciel mais plutôt l'inverse vérifier que tout fonctionne même quand on l'utilise dans des cas non prévu (quitte à balancer des messages d'erreurs). Ici si on ne prévoit pas ce genre de chose dès que tu as quelques utilisateurs qui font des écritures dans un même bug tu peut avoir le format du fichier qui est pourri, un entrelacement entre les messages, etc.
Ce n'est pas une critique contre SMIT qui répond à un besoin donné j'en suis certain, c'est juste qu'on entends souvent parler de la non utilisation de SGBD dans nos colonnes et que je m'intéresse dans le cas général à comment le mettre en place.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Créer un processus qui reçois les commandes d'écriture et qui les effectues ? C'est ce que je fais quand j'en ai besoin mais je me demandais s'il n'y avait pas d'autres techniques que je ne connaîtrais pas.
Ce n'est pas toujours un bon choix. Mais plutôt que de tout réinventer au niveau applicatif, comprendre et savoir tirer parti des mécanismes de l'OS, dont le VFS, ca permet de parfois des merveilles de simplicité et de performance.
Justement je ne suis pas certain de tout connaître quant aux possibilités du VFS ou des bibliothèques d'accès aux fichiers (type GVFS). Il n'est pas impossible qu'il y ai quelque chose qui m'ai échappé pour ne pas faire la sérialisation des écritures à la main.
Ca laisse plein de marge pour implémenter un truc simple et robuste.
Je suis d'accord avec toi sur le principe, mais je n'appellerais pas ça robuste. La robustesse consiste à continuer à fonctionner malgré les erreurs et les cas limites. Là on se base sur une précondition de l'utilisation pour pouvoir continuer à fonctionner, c'est pas de la robustesse, c'est du pragmatisme, par exemple, mais pas de la robustesse (même si c'est suffisamment robuste).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Vrai question qui m'a toujours freiné quant à l'utilisation directe de fichiers :
Comment garanti tu la cohérence des fichiers ? Si plusieurs utilisateurs accèdent à un rapport de bug comment fais-tu pour t'assurer que les écritures se font dans le bon ordre ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Il y a wt pour faire du web en C++, j ene doute pas qu'il y a d'autres alternative. Le fait de créer le HTML via une API DOM ne me semble pas être une bonne idée pour la maintenabilité.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Notons que certains langages, sans commentaires, sont complètement illisibles. Notamment le langage C. Le python est très lisible, c'est vraiment un plaisir de travailler avec.
Je ne suis pas d'accord, dans les deux cas ça dépend de ce que tu en fait.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Je trouve dommage d'avoir codé en dur la correspondance. En utilisant un fichier, il me semble qu'il aurait pu facilement devenir un traducteur beta code générique (de ce que je vois sur wikipedia le beta code ne sert pas qu'au grec ancien). Le traitement d'un fichier serait trop long face au traitement des fichiers ? Ou pense-tu qu'il vaudrait mieux coder en dur l'ensemble du beta code (ça doit être limité et stable) ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Non, en général passer de LTS en LTS se passe bien mieux, parce que les LTS sont bien plus fiables.
Ça n'a rien avoir. Le fait 2 passer d'un logiciel stable à un autre n'indique en rien que le passage entre les deux soit sans douleur.
c'est à peu près le même nombre de paquets qui sont mis à jours/supprimé/ajouté, et l'opération n'est pas plus longue
Oui sauf qu'au lieu de faire des mises à jour d'une version N à une version N+1, tu fais des mises à jour d'une version N à une version N+2 ou +3 (si ce n'est plus). Les processus de mise à jour d'une version à la version supérieur sont bien plus simple, bien plus éprouvée et souvent fait upstream.
Et surtout, si tu attends la fin du support de ta LTS avant de migrer, tu auras une migration d'autant moins foireuse (exemple : un passage entre la 10.04.4 et la 12.04.2).
La problématique est donc la même qu'avec des versions non-LTS. Il ne faut pas s'attendre à ce que leur processus de stabilisation soit fait avant la sortie d'une version mais plutôt après. Ça vient de Canonical qui a un développement plsu fermé que d'autres distributions communautaires qui mettent plus en avant leur versions de tests (comme Mandriva, Maegia ou évidement Debian avec Sid et testing).
Note je ne dis pas qu'il n'y a pas de pré-versions d'ubuntu disponible publiquement, je dis que comparativement à d'autres distribution, ils communiquent très peu dessus (ce qui fait qu'ils ont moins de retours d'expérience).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Tout ça c'est que des conseils de geek pour geek. Le grand public ne vois ces conseils nul-part et n'est pas particulièrement patient (pourquoi devrait-il attendre quand son ordinateur lui conseil de mettre à jour ?) et ne prévois pas particulièrement de temps lors des mises à jours pour faire un backup, passer du temps sur le forum et listes de diffusion pour contourner les bugs et autre.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Ils sont super ils te disent « hé regardez ! on a une version 13.10 qui vient de sortir ! » et au dernier moment tu as le choix entre la 12.04 et la 13.10 c'est pas perturbant au moins pour l'utilisateur non-geek.
De plus si comme tu le dis la 13.10 n'est pas pour le grand publique, c'est assez idiot de ne parler que d'elle sur la page d'accueil.
Ubuntu a clairement le cul entre 2 chaises entre Fedora et ses releases time-based tous les 6 mois et les distrib' comme Debian ou RedHat qui sont plus en retard. Leur communication n'est pas terrible à ce sujet. De ce que tu dis, ils ont une politique inverse à celle de Mozilla avec Firefox et Thunderbird (chez Mozilla le choix « normal »/par défaut c'est d'utiliser la dernière version et on choisi la version ESR si on veut bouger lentement). Je ne sais même pas où c'est décris.
Personnellement je trouve que passer de LTS en LTS est risqué parce que ce sont des mises à jours bien plus lourdes, je préfère largement faire une mise à jour tous les 6 mois avec au moins un mois de décalage pour ne pas avoir les problèmes des early adopters.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Pour moi c'est 2 choses séparés. La libération de données c'est pouvoir à la fois télécharger les photo, mais aussi leur organisation (l'ordre dans l'album, l'organisation des albums, les éventuels titres et commentaire, etc) alors que le fait de permettre de télécharger l'album c'est juste une question de partage de tes données.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Il n'y a pas que la parallélisation qui accélère le boot, le fait de ne pas lancer 40 fois sed, grep, awk, test, etc joue pas mal aussi à mon avis.
Si c'est vraiment l'accès disque qui te ralentis, je pense que c'est du au fait que systemd parallélise vraiment beaucoup ce qui stress plus le système. Tes têtes de lecture ne doivent plus savoir où donner de la tête…
Si je comprends bien je devrais publier en double licence CeCILL-C/LGPL pour être valide dans les pays anglophones et en France ?
Non c'est inutile, les licences CeCILL font directement appels au droit français uniquement pour ne pas avoir d'ambiguïté, elles s'appliquent partout dans le monde (un coréen peut l'utiliser pour du code distribué uniquement en Australie).
Pour les licences comme la LGPL c'est lors d'un contentieux qu'il faut choisir le droit à appliquer (je ne sais plus comment se passe ce choix par contre).
[^] # Re: Des styles ! Des systèmes de documentation automatique !
Posté par barmic . En réponse à la dépêche Utroff : la renaissance de Troff. Évalué à 2.
Qu'Arch compile ou pas n'est pas un gros problème (c'est le problème des utilisateurs de cette distribution), le fait d'incrémenter toujours le numéros de version permet de s'y retrouver que ce soit le (ou les) développeurs ou les utilisateurs. En plus ça permet de stocker sans problème toutes les versions existantes.
Utiliser la date avec seulement le jour il faut être sur de ne pas sortir 2 versions le même jour.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Absurde
Posté par barmic . En réponse au journal Small Issue Tracker. Évalué à 5.
Tu peut dire la même chose pour tout et n'importe quoi. Il y a pleins de façons de mal faire du SQL soit parce que la requête n'est pas optimisée, soit parce que la base ne l'est pas (le schéma d'une base joue beaucoup, le fait de créer des indexes, le partitionnement, etc).
Bref tout ça pour dire que ce n'est pas un bon argument « requète SQL peut parfois prendre presque une seconde », une lecture direct de fichier aussi.
De plus lors des bench, il faut prendre en compte les accès aux données, mais aussi leur (dé)serialisation puisque SQL prends aussi cela en charge.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: GitHub pour entreprise
Posté par barmic . En réponse au journal Small Issue Tracker. Évalué à 2.
Il parlait de linuxfr… :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: pas mal !
Posté par barmic . En réponse au journal Small Issue Tracker. Évalué à 2.
Excuse-moi j'ai lu les virgules comme une énumération.
Le plus simple ce n'est pas d'avoir un processus qui à la fois alloue les fichier et détecte les conflits ? On lui demande d'accéder au fichier A, il voit la ou les dernières versions de celui-ci, il donne au processus appelant un fichier où écrire et gère le merge de son coté, une fois fait il met à jour tous les pointeurs (du coup je me demande si les pointeurs ne devrait pas être inversés…).
Merci beaucoup pour tes réponses :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: pas mal !
Posté par barmic . En réponse au journal Small Issue Tracker. Évalué à 2.
Tu parle de faire du CoW, mais comment u vois que tu n'es pas entrain d'écraser une version ? Il faudrait pouvoir vérifier la version que tu écrase au moment où tu l'écrase et je ne vois pas comment faire ça en garantissant qu'il n'y a pas eu de changement entre la vérification et l'écrasement. Pour le cas de SMIT, il est peut être possible de simplement créer des fichiers d'ajout et faire des passes régulière pour agréger les fichiers d'un bug dans un seul fichier (ou surveiller les nouveaux fichiers via inotify – ça reste du Single writer principle –).
Pour moi la robutesse ce n'est pas de poser une précondition sur la manière dont on utilise le logiciel mais plutôt l'inverse vérifier que tout fonctionne même quand on l'utilise dans des cas non prévu (quitte à balancer des messages d'erreurs). Ici si on ne prévoit pas ce genre de chose dès que tu as quelques utilisateurs qui font des écritures dans un même bug tu peut avoir le format du fichier qui est pourri, un entrelacement entre les messages, etc.
Ce n'est pas une critique contre SMIT qui répond à un besoin donné j'en suis certain, c'est juste qu'on entends souvent parler de la non utilisation de SGBD dans nos colonnes et que je m'intéresse dans le cas général à comment le mettre en place.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: pas mal !
Posté par barmic . En réponse au journal Small Issue Tracker. Évalué à 3.
Créer un processus qui reçois les commandes d'écriture et qui les effectues ? C'est ce que je fais quand j'en ai besoin mais je me demandais s'il n'y avait pas d'autres techniques que je ne connaîtrais pas.
Justement je ne suis pas certain de tout connaître quant aux possibilités du VFS ou des bibliothèques d'accès aux fichiers (type GVFS). Il n'est pas impossible qu'il y ai quelque chose qui m'ai échappé pour ne pas faire la sérialisation des écritures à la main.
Je suis d'accord avec toi sur le principe, mais je n'appellerais pas ça robuste. La robustesse consiste à continuer à fonctionner malgré les erreurs et les cas limites. Là on se base sur une précondition de l'utilisation pour pouvoir continuer à fonctionner, c'est pas de la robustesse, c'est du pragmatisme, par exemple, mais pas de la robustesse (même si c'est suffisamment robuste).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: pas mal !
Posté par barmic . En réponse au journal Small Issue Tracker. Évalué à 1.
Vrai question qui m'a toujours freiné quant à l'utilisation directe de fichiers :
Comment garanti tu la cohérence des fichiers ? Si plusieurs utilisateurs accèdent à un rapport de bug comment fais-tu pour t'assurer que les écritures se font dans le bon ordre ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Les performances ne sont pas excellentes
Posté par barmic . En réponse au journal Small Issue Tracker. Évalué à 2.
Il n'y a rien de standard dans boobstracker (sinon je suis intéressé par une quelconque définition de ce standard).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: GitHub pour entreprise
Posté par barmic . En réponse au journal Small Issue Tracker. Évalué à 2.
Il y a wt pour faire du web en C++, j ene doute pas qu'il y a d'autres alternative. Le fait de créer le HTML via une API DOM ne me semble pas être une bonne idée pour la maintenabilité.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Code auto-documente
Posté par barmic . En réponse au sondage Les commentaires et vous ? . Évalué à 3.
Je ne suis pas d'accord, dans les deux cas ça dépend de ce que tu en fait.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Correspondance béta-code -> hexa
Posté par barmic . En réponse au journal Jouons avec Unicode: Tchars, un Dchars pour Troff. Évalué à 4.
Je trouve dommage d'avoir codé en dur la correspondance. En utilisant un fichier, il me semble qu'il aurait pu facilement devenir un traducteur beta code générique (de ce que je vois sur wikipedia le beta code ne sert pas qu'au grec ancien). Le traitement d'un fichier serait trop long face au traitement des fichiers ? Ou pense-tu qu'il vaudrait mieux coder en dur l'ensemble du beta code (ça doit être limité et stable) ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: kot kot codec?
Posté par barmic . En réponse au journal Cisco paie le h264 en faveur de Mozilla. Évalué à 4.
Je pense que c'est ce qui était sous-entendu par « si besoin ».
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: bigre
Posté par barmic . En réponse au journal Cisco paie le h264 en faveur de Mozilla. Évalué à 8.
Ils peuvent vérifier à chaque fois le checksum du binaire ça ne coûte pas grand chose.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Bah voila, c'est la cata!
Posté par barmic . En réponse à la dépêche Ubuntu 13.10 The Saucy Salamander. Évalué à 2.
Ouai mais elle n'attends pas la sous-version 2 de la nouvelle LTS pour te pousser à faire la mise à jour.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Bah voila, c'est la cata!
Posté par barmic . En réponse à la dépêche Ubuntu 13.10 The Saucy Salamander. Évalué à 3.
Ça n'a rien avoir. Le fait 2 passer d'un logiciel stable à un autre n'indique en rien que le passage entre les deux soit sans douleur.
Oui sauf qu'au lieu de faire des mises à jour d'une version N à une version N+1, tu fais des mises à jour d'une version N à une version N+2 ou +3 (si ce n'est plus). Les processus de mise à jour d'une version à la version supérieur sont bien plus simple, bien plus éprouvée et souvent fait upstream.
La problématique est donc la même qu'avec des versions non-LTS. Il ne faut pas s'attendre à ce que leur processus de stabilisation soit fait avant la sortie d'une version mais plutôt après. Ça vient de Canonical qui a un développement plsu fermé que d'autres distributions communautaires qui mettent plus en avant leur versions de tests (comme Mandriva, Maegia ou évidement Debian avec Sid et testing).
Note je ne dis pas qu'il n'y a pas de pré-versions d'ubuntu disponible publiquement, je dis que comparativement à d'autres distribution, ils communiquent très peu dessus (ce qui fait qu'ils ont moins de retours d'expérience).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Bah voila, c'est la cata!
Posté par barmic . En réponse à la dépêche Ubuntu 13.10 The Saucy Salamander. Évalué à 1.
Tout ça c'est que des conseils de geek pour geek. Le grand public ne vois ces conseils nul-part et n'est pas particulièrement patient (pourquoi devrait-il attendre quand son ordinateur lui conseil de mettre à jour ?) et ne prévois pas particulièrement de temps lors des mises à jours pour faire un backup, passer du temps sur le forum et listes de diffusion pour contourner les bugs et autre.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Bah voila, c'est la cata!
Posté par barmic . En réponse à la dépêche Ubuntu 13.10 The Saucy Salamander. Évalué à 4.
Ils sont super ils te disent « hé regardez ! on a une version 13.10 qui vient de sortir ! » et au dernier moment tu as le choix entre la 12.04 et la 13.10 c'est pas perturbant au moins pour l'utilisateur non-geek.
De plus si comme tu le dis la 13.10 n'est pas pour le grand publique, c'est assez idiot de ne parler que d'elle sur la page d'accueil.
Ubuntu a clairement le cul entre 2 chaises entre Fedora et ses releases time-based tous les 6 mois et les distrib' comme Debian ou RedHat qui sont plus en retard. Leur communication n'est pas terrible à ce sujet. De ce que tu dis, ils ont une politique inverse à celle de Mozilla avec Firefox et Thunderbird (chez Mozilla le choix « normal »/par défaut c'est d'utiliser la dernière version et on choisi la version ESR si on veut bouger lentement). Je ne sais même pas où c'est décris.
Personnellement je trouve que passer de LTS en LTS est risqué parce que ce sont des mises à jours bien plus lourdes, je préfère largement faire une mise à jour tous les 6 mois avec au moins un mois de décalage pour ne pas avoir les problèmes des early adopters.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Télécharger un album
Posté par barmic . En réponse au journal EnVadrouille, une galerie photo pour vos randos. Évalué à 3.
Mince en reprenant ma phrase j'en ai perdu un mot. Une galerie statique.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Télécharger un album
Posté par barmic . En réponse au journal EnVadrouille, une galerie photo pour vos randos. Évalué à 2.
Pour moi c'est 2 choses séparés. La libération de données c'est pouvoir à la fois télécharger les photo, mais aussi leur organisation (l'ordre dans l'album, l'organisation des albums, les éventuels titres et commentaire, etc) alors que le fait de permettre de télécharger l'album c'est juste une question de partage de tes données.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Télécharger un album
Posté par barmic . En réponse au journal EnVadrouille, une galerie photo pour vos randos. Évalué à 1.
Pourquoi ne pas utiliser une galerie ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: C’est du propre
Posté par barmic . En réponse à la dépêche Entretien avec François Tigeot, développeur DragonFly BSD. Évalué à 3.
Il n'y a pas que la parallélisation qui accélère le boot, le fait de ne pas lancer 40 fois sed, grep, awk, test, etc joue pas mal aussi à mon avis.
Si c'est vraiment l'accès disque qui te ralentis, je pense que c'est du au fait que systemd parallélise vraiment beaucoup ce qui stress plus le système. Tes têtes de lecture ne doivent plus savoir où donner de la tête…
Peut être qu'en configurant ton noyau pour avoir un cache plus grand, il gagnerait beaucoup en performance (jben en avait parlé, il y a maintenant longtemps : https://linuxfr.org/news/supercopier-3#comment-1426182).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Les retours de chariot à la main c'est mal
Posté par barmic . En réponse au journal Un hello world pour Firefox OS, un petit TODO et puis.... Évalué à 5.
C'est une demande des utilisateurs.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pourquoi s'acharner à vouloir apposer une licence ?
Posté par barmic . En réponse au journal Aidez moi à choisir mes licences !. Évalué à 3.
Ou à la Mozilla tu utilise un nom et un logo non-libre (perso ça ne me choque pas vu le besoin).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pourquoi s'acharner à vouloir apposer une licence ?
Posté par barmic . En réponse au journal Aidez moi à choisir mes licences !. Évalué à 4.
Si tu n'appose pas de licence tu es sur le droit d'auteur donc tu ne donne aucun droit. Il faut utiliser le CC0 ou RABL/WTFPL par exemple.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: CeCILL
Posté par barmic . En réponse au journal Aidez moi à choisir mes licences !. Évalué à 2.
Non c'est inutile, les licences CeCILL font directement appels au droit français uniquement pour ne pas avoir d'ambiguïté, elles s'appliquent partout dans le monde (un coréen peut l'utiliser pour du code distribué uniquement en Australie).
Pour les licences comme la LGPL c'est lors d'un contentieux qu'il faut choisir le droit à appliquer (je ne sais plus comment se passe ce choix par contre).
Par contre la FSF met en garde les développeurs au sujet de l'utilisation de la CeCILLv2 : http://www.gnu.org/licenses/license-list.html#CeCILL (faut lire le paragraphe en question).
Au passage, c'est moins dans le vent que github mais la FSF tente de donner des pistes quant au choix de licence : http://www.gnu.org/licenses/license-recommendations.html
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)