Et moi je dis l'inverse, je crois que finalement ils ont laissé tomber. Même nouveaux utilisateurs qui ne sont pas clients de Free peuvent quand même mettre à jour leur page. À vérifier.
C'est même plus valable ça je crois. La seule distinction, c'est connexion FTP sur login.free.fr pour les clients, et ftpperso.free.fr pour les autres. Ceci dit, il y a eu pas mal de volte-faces, donc je me trompe peut-être ; moi j'ai des vieux comptes, j'ai jamais été client Free, et je met à jour mes pages sans problème.
Fortran 77, juste dis non. Tu ne vas pas apprendre à bien programmer, tu vas directement prendre de mauvaise habitudes surrannées. Un Fortran plus moderne (Fortran 90) ok, si tu as un compilateur qui supporte bien tout (et donc pas g77 si je ne m'abuse), et un bon cours pour aller avec dans la découverte de la programmation.
Pourquoi ne pas utiliser un langage plus agréable et plus accessible ? Tu as des impératifs de performance exceptionnels ? Je pense à Python par exemple.
Sinon, pour ton problème, tu ne donnes pas assez de détails sur les colonnes : sont-elles de largeur fixe, par quoi sont-elles séparées ? Est-ce un travail ponctuel ou devra-t-il être effectué toutes les nuits en moins de six secondes ? Etc.
Et pour un exemple pas du tout complet de remplacement en Fortran :
integer*4 I
character*100 LIGNE ! à adapter à la réalité bien sûr
! je suppose que tu as rempli LIGNE par ailleurs
I = index(LIGNE, '/')
LIGNE(I:I) = ' '
I = index(LIGNE, '/') ! pour deux itérations, je fais même pas une boucle ;-)
LIGNE(I:I) = ' '
I = index(LIGNE, ':')
LIGNE(I:I) = ' '
I = index(LIGNE, ':')
LIGNE(I:I) = ' '
Ça dépend effectivement du serveur (le DNS en recense 66), certains marchent très bien, puisqu'on n'en entend jamais parler, d'autre galèrent depuis quelques semaines, surtout les serveurs 200 et suivants.
Free a l'air d'avoir diminué ses moyens au niveau de la gestion des serveurs, ou est dépassé par le passage à 1 Go de stockage. En tout cas, clairement, il y a beaucoup plus de problèmes de perf depuis environ un mois que par le passé, et même si Free en corrige (difficile de savoir), il y a une certaine constance dans la galère. Si ton site chez Free est vraiment important pour toi, il va falloir penser à le migrer.
Pas du tout. Pas plus que d'utiliser un monstre comme un compilateur C pour ça. Et certainement moins que d'utiliser un navigateur web (et ses dizaines de milliers de lignes de codes) pour interpréter un langage de description de page qui contient un autre langage, le résultat de l'exécution n'étant même pas transférable à d'autres programmes sans intervention de l'utilisateur.
Sauf qu'on peut trivialement faire du centralisé quand on sait faire du décentralisé, l'inverse étant plus difficile.
Le quotidien de l'utilisateur de base en décentralisé reste le commit et le merge, avec quelques push/pull sur des URI fixes (et généralement stockées dans la config) ; le quotidien de l'administrateur passe de surveillance de se qui se passe dans le dépôt (ou confiance aveugle) à série de push/pull avec URI variables effectivement. (Quoi que... Avec Darcs, ce quotidien peut aussi être : réception des mails, merge.) Notons à ce niveau que les URI de Darcs sont nettement plus sympa que celles d'Arch et de Monotone.
Effectivement, un outil de tracking devient indispensable, même si l'open source se permet souvent d'être moins organisé et planifié que le commercial. À ce propos, il existe un patch pour utiliser Darcs au lieu de Subversion dans Trac.
J'ai toujours eu un problème avec Linux c'est le manque de tracabilité du code dans le temps. BK à permis d'assurer cela pour la période ou il a été en fonction mais apparement on repart de 0.
Houla, faut pas comprendre ça de travers ! C'est pas comme si Linus avait effacé tout l'historique, ou qu'il s'en foutait. Simplement, il trouve (et tous les autres devs trouvent) que mettre 3,2 Go de données dans un système vieux d'à peine quelques semaines, c'est trop lourd. Ça imposerait que chaque personne voulant utiliser git pour envoyer des patches à Linus devrait télécharger ces 3,2 Go. Merci la bande passante et les resources des serveurs ! Ça ne servirait pas à grand chose, car il n'y a pas encore d'outils pour explorer confortablement l'historique.
Bref, après avoir vérifié que tout l'historique était bien récupérable des dépôts BitKeeper et CVS, et qu'ils pouvaient facilement mettre l'historique dans un git, les développeurs ont décidé de repousser à plus tard la création d'une archive intégrant le tout, et de travailler avec des dépôts pour l'instant plus légers.
On dirait une constitution plus un code pénal plus un code des marchés plus un code civil plus.... bref pas juste une constitution
Ben non, puisqu'il s'agit d'une unification des multiples traités qui ont formé l'Union au fil des années (et des ajouts, objets d'infinis débats). Appeler ça une constitution, ça ne s'est fait que pendant les travaux d'unification, pas quand le projet a été lancé.
Quant à son unique dépôt, je ne vois pas trop le désavantage. Dans la boite où je travaille, CVS est l'outil "standard" et il y a un dépôt pour chaque projet.
Le désavantage, c'est qu'il faut ouvrir des droits pour chaque personne qui veut contribuer au projet, et ensuite gérer finement ses autorisations, ou lui faire confiance pour ne pas tout foutre en l'air. Un système distribué permet lui à tout un chacun de travailler dans son coin avec tous les bénéfices d'une gestion de version, et de venir contribuer quand il a quelque chose de correct (et la gestion de version n'est pas interrompue). Ceci dit, je comprends tout à fait qu'une boîte préfère Subversion.
c'est orienté vu que les gars de arch le disent eux-mêmes
Pas forcément puisque c'est un wiki ouvert à tous. Je me souviens d'un moment (il y a un an environ) où un fan de Subversion venait quotidiennement ajouter le moindre truc bénéfique à Subversion en le plaçant au même niveau que des fonctionnalités plus importantes, et voulait enlever certains détails pas intéressants (de son point de vue bien sûr). Enfin bref, toujours lire plusieurs sources, et pas qu'une page d'un wiki...
On pourrait aussi imaginer que Linus aurait laisser tomber le développement du noyau, ne tenant plus la charge. On pourrait aussi imaginer que Bill Gates aurait repris le développement pour se changer les idées, après tout c'est facile d'imaginer.
On peut aussi se dire que l'utilisation d'un logiciel proprio a explicitement motivé plusieurs projets (notamment GNU Arch), et que sans ça on aurait pas eu toute cette palette de nouveaux outils qui arrivent à maturité en ce moment.
N'oublions pas aussi que The Register est un site qui n'hésite pas à jouer la carte du senstionnalisme et qu'il est avec Torvalds vs. Tridgell sur un superbe filon.
Torvalds (qui n'est pas un saint) n'a clairement pas été content de la « faute » de Tridgell et n'a pas mâché ses mots sur le moment. Celui-ci en dit le moins possible, un comportement recommandé par son avocat, et qui dans le contexte me semble raisonnable. Ceci dit, même si je comprends une part de l'énervement de Linus (paf, obligé de laisser tomber le meilleur outil du monde créé exprès pour lui ou presque), je pense comme beaucoup d'autres que c'est surtout l'auteur de BitKeeper, le sanguin et volubile Larry McVoy, qui est à blâmer avec ses licences encore plus débiles que celles de Microsoft, et sa volonté de les appliquer. (Larry McVoy qui n'est par ailleurs pas le dernier des cons, parce que BitKeeper, techniquement parlant, ça a l'air de bien roxer.) Pour ce que j'en sais, Trigdell était dans son bon droit, éthiquement à coup sûr, légalement je l'espère aussi.
Enfin bref, je pense que globalement cette « affaire BitKeeper » a fait plus de bien (accélération du développement du noyau, accélération des solutions libres concurrentes) que de mal (grinçages de dents des plus libristes, potentielle « affaire Tridgell »).
git indexe les fichiers par leurs somme de contrôle (leur nom sur le disque est leur somme de contrôle). Donc si un fichier ne change pas, sa somme de contrôle ne change pas, il n'est stocké qu'une seule fois sur le disque. S'il change, les deux versions sont stockées sur le disque.
Pour créer un diff, il suffit de regarder les deux commit, voir dans les arbres correspondants si le fichier a changé, et si oui, appeler la bonne vieille commande diff avec les deux fichiers à comparer.
Pour appliquer un diff, il suffit d'extraire la version voulue (a priori la plus récente), d'utiliser patch, et de stocker la nouvelle version créée.
Quant à savoir ce que c'est qu'un patch au sens rcs ou un système de fichier loopback (à tes souhaits)... Pas la moindre idée.
Avant que tout le monde (enfin, sauf les deux commentaires précédents) n'imagine que Linus a fait mieux que BitKeeper (et Subversion, Arch, Darcs, Monotone, etc.) en deux semaines, voici quelques précisions sur git.
git est un outil de bas niveau, simple et très performant, qui a pour but de gérer l'évolution du contenu d'une arborescence. Il gère en gros trois types d'objets de manière très rapide, caractérisés par leur somme de contrôle SHA-1 : des blobs (fichiers de base), des arbres (listes de blobs et d'arbres) et des commit (un arbre correspondant à une version donnée, et liste des commits précédents ayant permis d'en arriver là). Il gère par ailleurs un index, afin d'accélerer le travail sur un arbre voulu. Il permet quelques opérations en plus (affichage du contenu d'un blob à un moment donné, fusion simple d'arbres), et c'est tout. On est très loin des autres systèmes en termes de fonctionnalités (mais Linus n'a pas besoin de tout), et très en avance en termes de performance (car Linus en a bien besoin).
Et voilà et c'est tout et c'est déjà pas mal. C'est suffisant pour bosser (avec plein de scripts autour pour automatiser, je suppose) en attendant que d'autres solutions deviennent plus matures, ou que git lui-même évolue encore plus.
Le truc intéressant au niveau des performances, c'est que du coup les gestionnaires de version qui n'utilisent pas de base de données (Arch, Darcs) sont très intéressés par se servir de git sous le capot pour le stockage des fichiers, tout en offrant leurs fonctionnalités plus évoluées.
Bref, la gestion de source dans le monde du libre, qui avait déjà pas mal évolué ces dernières années et ces derniers mois, s'est encore pris un coup d'accélérateur grâce à git. Finalement, BitKeeper aura pas mal fait bouger les choses, quitte à être le bâton plus que la carotte. :-)
Voir notamment la série d'articles sur les instituions européennes (les 28/03, 31/03, 03/04, 09/04, 13/04, 16/04) et une analyse de la partie III de la constitution (les 29/03, 31/03, 02/04, 05/04, 11/04, 18/04).
Et si tu veux mon opinion : la « constitution » (je préfère avec guillemets) reprend l'existant, le fusionne, et apporte quelques améliorations (voir les articles du blog indiqués ci-dessus). C'est pour ça qu'elle est très indigeste, c'est inévitable. Refuser la constitution, c'est garder l'existant (aussi mauvais que la constitution, du point de vue de ceux qui n'aiment pas), par ailleurs illisible puisque empilement de traités sur une cinquantaine d'années. Il y en a qui préfèrent stagner, moi je préfère aller de l'avant.
je n'ai pas sauvegardé les réglages d'alsamixer dans 'alsactl' mais en l'éditant (avec un traitement de texte quelconque) j'ai vu qu'il y avait des hiéroglyphes
Mais bien sûr, c'est un exécutable binaire ! Mais pourquoi ô pourquoi voudrais-tu éditer un exécutable binaire avec un éditeur de texte ? J'ai l'impression que tu confonds un peu tout.
La commande alsa restore
Il n'y a pas de commande « alsa ». La seule chose possible, c'est « alsactl restore » ou « /usr/sbin/alsactl restore ».
* Subversion est conçu pour remplacer CVS. Au niveau des concepts, c'est le plus proche. Subversion, c'est aussi un serveur Apache, un protocole propriétaire, une base de données (à éviter de corrompre), donc une approche assez « lourde ». Subversion, c'est soutenu par des gros acteurs et développé par une « grosse » équipe, donc c'est pro, bien documenté, y'a une grosse communauté, etc. Par contre, Subversion reste sur un modèle centralisé, un seul dépôt, et soit tu fais partie de l'équipe de dev d'un projet et tu peux y écrire, soit (comme pour CVS) Subversion ne te sert que d'outil pour récupérer la version la plus à jour d'un projet. En tant que chef de projet, tu dois gérer les permissions d'accès et surveiller un peu ce que font les devs dans le dépôt.
* Arch est conçu pour être complètement décentralisé. Tout le monde peut facilement créer son dépôt à partir du tien, développer un ou deux trucs (correctifs, nouvelles fonctionnalités), et toi ensuite tu peux aller choper la modif dans leur dépôt. Beaucoup plus adapté à un développement de type « open source ». Arch c'est un seul exécutable, pour le stockage c'est le système de fichiers qui est utilisé, pour l'échange de fichiers tout fait l'affaire (serveur HTTP, serveur FTP, serveur SSH, tout moyen de mettre des fichiers à disposition du monde suffit). Arch c'est aussi beaucoup de choses à apprendre (plein de commandes de bas niveau à combiner pour obtenir ce que l'on désire), une documentation pas toujours excellente (mais suffisante, quand même), un développeur principal que l'on aime ou que l'on aime pas (Tom Lord, une forte personnalité, un peu comme RMS), plusieurs forks qui se développent en parallèle (tla, baz, bazaar-ng). Puissant mais pas très facile d'approche.
* Darcs est conçu de manière similaire à Arch (développement décentralisé, utilisation du système de fichiers, partage par HTTP, FTP, mail, etc.). Il a la particularité de se débarrasser du concept de dépôt stocké à part sur le disque (tout ce dont il a besoin est stocké dans un sous-répertoire du projet), et de pouvoir réordonner les patches (composant un projet) dans tous les sens, tout en gérant leur dépendance, bien sûr -- le résultat le plus important, c'est qu'il est facile de ne prendre que les petits bouts intéressants dans une branche ou un fork, et vu que c'est très facile de faire des « forks », c'est important. Darcs est très simple, très facile à comprendre, bien documenté, très agréable d'utilisation, et très puissant (vu sa simplicité). Il souffre de quelques problèmes de performance sur des très gros projets (1 Go de source...), mais la situation s'est très nettement améliorée ces dernières semaines. Enfin bref, Darcs c'est super bien.
* Monotone, je connais pas trop, je crois que c'est bien aussi. Il utilise une base de données pour stocker les révisions, c'est le genre de truc qui me bloque un peu.
/usr/sbin/alsactl est un programme, on n'y stocke pas les paramètres d'ALSA (ou alors, pas étonnant qu'il soit corrompu !)
« alsactl store » enregistre les réglages dans /etc/asound.state, et n'importe quel autre fichier pourrait être utilisé, par exemple « alsactl store /home/moi/reglages.alsa ». Au démarrage, ou à tout moment, « alsactl restore » lit /etc/asound.state, ou bien sûr « alsactl restore /home/moi/reglages.alsa ».
Si ton fichier /etc/asound.state est corrompu, le mieux à faire est de l'effacer, de rebooter, et de faire un « alsactl store » peu après le démarrage. Ça fait une bonne base de départ.
KEducaBuilder permet de construire des questionnaires (questions ouvertes, questions à choix multiples, etc.) avec pas mal de flexibilité. KEduca permet ensuite de « passer » ces questionnaires.
Ton journal a la qualité d'une dépêche, tu devrais le/la soumettre aux modérateurs de LinuxFr. Même si la nouvelle ne concerne pas directement Linux, Adobe (et encore plus Adobe+Macromedia) a une importance certaine sous Linux (ne serait-ce qu'avec tous ces plugins, les débats sur les formats ouverts, le support Linux de la part de gros éditeurs, etc.)
Cette histoire d'images de pochettes de disque me faire marrer.
1) Ce qui m'importe, c'est que le lecteur ne prenne pas de place à l'écran ; une icône en bas à droite, c'est amplement suffisant, et un popup bien mis en page lors d'un changement de morceau, c'est très bien (merci JuK).
2) Si je veux regarder une pochette (rare), je tends le bras, je prends l'album.
3) Si j'aime vraiment une pochette (rare encore plus), j'achette le 33 tours (s'il existe), parce que niveau format, c'est le pied.
Franchement, enfreindre tout plein de licences pour afficher une petite image pixellisée dans un coin d'interface, quel intérêt ?
The codec was written by Karl Morton (a Team17 contract programmer) in the mid-90's and was a 256 colour decompresser that allowed palette changes per frame. This was mainly to support high-frame playback on slow CD players (1-4x in those times) since many people didn't like FMV's installed to Hard Drive (as is the norm now).
The actual compression codec is not around or accessible but it can be decoded these days and reconverted.
Aucune précision sur le décodage, pourtant possible d'après l'auteur du commentaire. Le fil de discussion contient plusieurs pistes pour un réencodage possible des vidéos de Worms 2.
[^] # Re: Lenteurs....
Posté par Boa Treize (site web personnel) . En réponse au journal Les applications PHP chez Free. Évalué à 1.
[^] # Re: Lenteurs....
Posté par Boa Treize (site web personnel) . En réponse au journal Les applications PHP chez Free. Évalué à 4.
# Heu...
Posté par Boa Treize (site web personnel) . En réponse au message Mega debutant fortran77. Évalué à 2.
Pourquoi ne pas utiliser un langage plus agréable et plus accessible ? Tu as des impératifs de performance exceptionnels ? Je pense à Python par exemple.
Sinon, pour ton problème, tu ne donnes pas assez de détails sur les colonnes : sont-elles de largeur fixe, par quoi sont-elles séparées ? Est-ce un travail ponctuel ou devra-t-il être effectué toutes les nuits en moins de six secondes ? Etc.
Et pour un exemple pas du tout complet de remplacement en Fortran :
integer*4 I
character*100 LIGNE ! à adapter à la réalité bien sûr
! je suppose que tu as rempli LIGNE par ailleurs
I = index(LIGNE, '/')
LIGNE(I:I) = ' '
I = index(LIGNE, '/') ! pour deux itérations, je fais même pas une boucle ;-)
LIGNE(I:I) = ' '
I = index(LIGNE, ':')
LIGNE(I:I) = ' '
I = index(LIGNE, ':')
LIGNE(I:I) = ' '
[^] # Re: Dépend du serveur
Posté par Boa Treize (site web personnel) . En réponse au journal Les applications PHP chez Free. Évalué à 2.
Free a l'air d'avoir diminué ses moyens au niveau de la gestion des serveurs, ou est dépassé par le passage à 1 Go de stockage. En tout cas, clairement, il y a beaucoup plus de problèmes de perf depuis environ un mois que par le passé, et même si Free en corrige (difficile de savoir), il y a une certaine constance dans la galère. Si ton site chez Free est vraiment important pour toi, il va falloir penser à le migrer.
[^] # Re: ridicule
Posté par Boa Treize (site web personnel) . En réponse au journal générateur de mot de passe. Évalué à 10.
Pas du tout. Pas plus que d'utiliser un monstre comme un compilateur C pour ça. Et certainement moins que d'utiliser un navigateur web (et ses dizaines de milliers de lignes de codes) pour interpréter un langage de description de page qui contient un autre langage, le résultat de l'exécution n'étant même pas transférable à d'autres programmes sans intervention de l'utilisateur.
[^] # ... et mkpasswd
Posté par Boa Treize (site web personnel) . En réponse au journal générateur de mot de passe. Évalué à 2.
Par défaut sur pas mal de Linux et d'Unix.
[^] # Re: Suggestions
Posté par Boa Treize (site web personnel) . En réponse au journal Gestionnaire de versions. Évalué à 2.
Le quotidien de l'utilisateur de base en décentralisé reste le commit et le merge, avec quelques push/pull sur des URI fixes (et généralement stockées dans la config) ; le quotidien de l'administrateur passe de surveillance de se qui se passe dans le dépôt (ou confiance aveugle) à série de push/pull avec URI variables effectivement. (Quoi que... Avec Darcs, ce quotidien peut aussi être : réception des mails, merge.) Notons à ce niveau que les URI de Darcs sont nettement plus sympa que celles d'Arch et de Monotone.
Effectivement, un outil de tracking devient indispensable, même si l'open source se permet souvent d'être moins organisé et planifié que le commercial. À ce propos, il existe un patch pour utiliser Darcs au lieu de Subversion dans Trac.
Trac :
http://www.edgewall.com/trac/(...)
[^] # Re: Tracabilité
Posté par Boa Treize (site web personnel) . En réponse à la dépêche Le développement du noyau continue autour de Git. Évalué à 7.
Houla, faut pas comprendre ça de travers ! C'est pas comme si Linus avait effacé tout l'historique, ou qu'il s'en foutait. Simplement, il trouve (et tous les autres devs trouvent) que mettre 3,2 Go de données dans un système vieux d'à peine quelques semaines, c'est trop lourd. Ça imposerait que chaque personne voulant utiliser git pour envoyer des patches à Linus devrait télécharger ces 3,2 Go. Merci la bande passante et les resources des serveurs ! Ça ne servirait pas à grand chose, car il n'y a pas encore d'outils pour explorer confortablement l'historique.
Bref, après avoir vérifié que tout l'historique était bien récupérable des dépôts BitKeeper et CVS, et qu'ils pouvaient facilement mettre l'historique dans un git, les développeurs ont décidé de repousser à plus tard la création d'une archive intégrant le tout, et de travailler avec des dépôts pour l'instant plus légers.
[^] # Re: Pour te faire ta propre opinion...
Posté par Boa Treize (site web personnel) . En réponse au journal Un journal de plus : OUI ou NON ?. Évalué à 3.
Ben non, puisqu'il s'agit d'une unification des multiples traités qui ont formé l'Union au fil des années (et des ajouts, objets d'infinis débats). Appeler ça une constitution, ça ne s'est fait que pendant les travaux d'unification, pas quand le projet a été lancé.
[^] # Re: Suggestions
Posté par Boa Treize (site web personnel) . En réponse au journal Gestionnaire de versions. Évalué à 2.
Le désavantage, c'est qu'il faut ouvrir des droits pour chaque personne qui veut contribuer au projet, et ensuite gérer finement ses autorisations, ou lui faire confiance pour ne pas tout foutre en l'air. Un système distribué permet lui à tout un chacun de travailler dans son coin avec tous les bénéfices d'une gestion de version, et de venir contribuer quand il a quelque chose de correct (et la gestion de version n'est pas interrompue). Ceci dit, je comprends tout à fait qu'une boîte préfère Subversion.
[^] # Re: comparatif tout fait + GUI + doc
Posté par Boa Treize (site web personnel) . En réponse au journal Gestionnaire de versions. Évalué à 2.
Pas forcément puisque c'est un wiki ouvert à tous. Je me souviens d'un moment (il y a un an environ) où un fan de Subversion venait quotidiennement ajouter le moindre truc bénéfique à Subversion en le plaçant au même niveau que des fonctionnalités plus importantes, et voulait enlever certains détails pas intéressants (de son point de vue bien sûr). Enfin bref, toujours lire plusieurs sources, et pas qu'une page d'un wiki...
[^] # Re: BK vs git.
Posté par Boa Treize (site web personnel) . En réponse à la dépêche Le développement du noyau continue autour de Git. Évalué à 8.
On peut aussi se dire que l'utilisation d'un logiciel proprio a explicitement motivé plusieurs projets (notamment GNU Arch), et que sans ça on aurait pas eu toute cette palette de nouveaux outils qui arrivent à maturité en ce moment.
[^] # Re: Torvalds vs Tridgell
Posté par Boa Treize (site web personnel) . En réponse à la dépêche Le développement du noyau continue autour de Git. Évalué à 3.
Torvalds (qui n'est pas un saint) n'a clairement pas été content de la « faute » de Tridgell et n'a pas mâché ses mots sur le moment. Celui-ci en dit le moins possible, un comportement recommandé par son avocat, et qui dans le contexte me semble raisonnable. Ceci dit, même si je comprends une part de l'énervement de Linus (paf, obligé de laisser tomber le meilleur outil du monde créé exprès pour lui ou presque), je pense comme beaucoup d'autres que c'est surtout l'auteur de BitKeeper, le sanguin et volubile Larry McVoy, qui est à blâmer avec ses licences encore plus débiles que celles de Microsoft, et sa volonté de les appliquer. (Larry McVoy qui n'est par ailleurs pas le dernier des cons, parce que BitKeeper, techniquement parlant, ça a l'air de bien roxer.) Pour ce que j'en sais, Trigdell était dans son bon droit, éthiquement à coup sûr, légalement je l'espère aussi.
Enfin bref, je pense que globalement cette « affaire BitKeeper » a fait plus de bien (accélération du développement du noyau, accélération des solutions libres concurrentes) que de mal (grinçages de dents des plus libristes, potentielle « affaire Tridgell »).
[^] # Re: git, un outil de bas niveau
Posté par Boa Treize (site web personnel) . En réponse à la dépêche Le développement du noyau continue autour de Git. Évalué à 4.
Pour créer un diff, il suffit de regarder les deux commit, voir dans les arbres correspondants si le fichier a changé, et si oui, appeler la bonne vieille commande diff avec les deux fichiers à comparer.
Pour appliquer un diff, il suffit d'extraire la version voulue (a priori la plus récente), d'utiliser patch, et de stocker la nouvelle version créée.
Quant à savoir ce que c'est qu'un patch au sens rcs ou un système de fichier loopback (à tes souhaits)... Pas la moindre idée.
# git, un outil de bas niveau
Posté par Boa Treize (site web personnel) . En réponse à la dépêche Le développement du noyau continue autour de Git. Évalué à 10.
git est un outil de bas niveau, simple et très performant, qui a pour but de gérer l'évolution du contenu d'une arborescence. Il gère en gros trois types d'objets de manière très rapide, caractérisés par leur somme de contrôle SHA-1 : des blobs (fichiers de base), des arbres (listes de blobs et d'arbres) et des commit (un arbre correspondant à une version donnée, et liste des commits précédents ayant permis d'en arriver là). Il gère par ailleurs un index, afin d'accélerer le travail sur un arbre voulu. Il permet quelques opérations en plus (affichage du contenu d'un blob à un moment donné, fusion simple d'arbres), et c'est tout. On est très loin des autres systèmes en termes de fonctionnalités (mais Linus n'a pas besoin de tout), et très en avance en termes de performance (car Linus en a bien besoin).
Et voilà et c'est tout et c'est déjà pas mal. C'est suffisant pour bosser (avec plein de scripts autour pour automatiser, je suppose) en attendant que d'autres solutions deviennent plus matures, ou que git lui-même évolue encore plus.
Le truc intéressant au niveau des performances, c'est que du coup les gestionnaires de version qui n'utilisent pas de base de données (Arch, Darcs) sont très intéressés par se servir de git sous le capot pour le stockage des fichiers, tout en offrant leurs fonctionnalités plus évoluées.
Bref, la gestion de source dans le monde du libre, qui avait déjà pas mal évolué ces dernières années et ces derniers mois, s'est encore pris un coup d'accélérateur grâce à git. Finalement, BitKeeper aura pas mal fait bouger les choses, quitte à être le bâton plus que la carotte. :-)
# Opinion
Posté par Boa Treize (site web personnel) . En réponse au journal Un journal de plus : OUI ou NON ?. Évalué à 7.
http://publiusleuropeen.typepad.com/publius/(...)
Voir notamment la série d'articles sur les instituions européennes (les 28/03, 31/03, 03/04, 09/04, 13/04, 16/04) et une analyse de la partie III de la constitution (les 29/03, 31/03, 02/04, 05/04, 11/04, 18/04).
Et si tu veux mon opinion : la « constitution » (je préfère avec guillemets) reprend l'existant, le fusionne, et apporte quelques améliorations (voir les articles du blog indiqués ci-dessus). C'est pour ça qu'elle est très indigeste, c'est inévitable. Refuser la constitution, c'est garder l'existant (aussi mauvais que la constitution, du point de vue de ceux qui n'aiment pas), par ailleurs illisible puisque empilement de traités sur une cinquantaine d'années. Il y en a qui préfèrent stagner, moi je préfère aller de l'avant.
Tiens, un article d'opinion que me plait :
http://www.liberation.fr/page.php?Article=290807(...)
[^] # Re: alsactl toujours pas réparé
Posté par Boa Treize (site web personnel) . En réponse au message fichier corrompu - ALSA- Help Please !. Évalué à 2.
Mais bien sûr, c'est un exécutable binaire ! Mais pourquoi ô pourquoi voudrais-tu éditer un exécutable binaire avec un éditeur de texte ? J'ai l'impression que tu confonds un peu tout.
La commande alsa restore
Il n'y a pas de commande « alsa ». La seule chose possible, c'est « alsactl restore » ou « /usr/sbin/alsactl restore ».
# Suggestions
Posté par Boa Treize (site web personnel) . En réponse au journal Gestionnaire de versions. Évalué à 10.
* Arch est conçu pour être complètement décentralisé. Tout le monde peut facilement créer son dépôt à partir du tien, développer un ou deux trucs (correctifs, nouvelles fonctionnalités), et toi ensuite tu peux aller choper la modif dans leur dépôt. Beaucoup plus adapté à un développement de type « open source ». Arch c'est un seul exécutable, pour le stockage c'est le système de fichiers qui est utilisé, pour l'échange de fichiers tout fait l'affaire (serveur HTTP, serveur FTP, serveur SSH, tout moyen de mettre des fichiers à disposition du monde suffit). Arch c'est aussi beaucoup de choses à apprendre (plein de commandes de bas niveau à combiner pour obtenir ce que l'on désire), une documentation pas toujours excellente (mais suffisante, quand même), un développeur principal que l'on aime ou que l'on aime pas (Tom Lord, une forte personnalité, un peu comme RMS), plusieurs forks qui se développent en parallèle (tla, baz, bazaar-ng). Puissant mais pas très facile d'approche.
* Darcs est conçu de manière similaire à Arch (développement décentralisé, utilisation du système de fichiers, partage par HTTP, FTP, mail, etc.). Il a la particularité de se débarrasser du concept de dépôt stocké à part sur le disque (tout ce dont il a besoin est stocké dans un sous-répertoire du projet), et de pouvoir réordonner les patches (composant un projet) dans tous les sens, tout en gérant leur dépendance, bien sûr -- le résultat le plus important, c'est qu'il est facile de ne prendre que les petits bouts intéressants dans une branche ou un fork, et vu que c'est très facile de faire des « forks », c'est important. Darcs est très simple, très facile à comprendre, bien documenté, très agréable d'utilisation, et très puissant (vu sa simplicité). Il souffre de quelques problèmes de performance sur des très gros projets (1 Go de source...), mais la situation s'est très nettement améliorée ces dernières semaines. Enfin bref, Darcs c'est super bien.
* Monotone, je connais pas trop, je crois que c'est bien aussi. Il utilise une base de données pour stocker les révisions, c'est le genre de truc qui me bloque un peu.
# Oula
Posté par Boa Treize (site web personnel) . En réponse au message fichier corrompu - ALSA- Help Please !. Évalué à 2.
« alsactl store » enregistre les réglages dans /etc/asound.state, et n'importe quel autre fichier pourrait être utilisé, par exemple « alsactl store /home/moi/reglages.alsa ». Au démarrage, ou à tout moment, « alsactl restore » lit /etc/asound.state, ou bien sûr « alsactl restore /home/moi/reglages.alsa ».
Si ton fichier /etc/asound.state est corrompu, le mieux à faire est de l'effacer, de rebooter, et de faire un « alsactl store » peu après le démarrage. Ça fait une bonne base de départ.
# KEduca
Posté par Boa Treize (site web personnel) . En réponse au journal apprendre par coeur. Évalué à 3.
C'est également dans le paquet kdeedu.
[^] # Re: mouataplass
Posté par Boa Treize (site web personnel) . En réponse au journal Jeter une batterie d'ordinateur portable ?. Évalué à 1.
[^] # Re: dos2unix
Posté par Boa Treize (site web personnel) . En réponse au message Problème CR/LF. Évalué à 5.
# Dépêche
Posté par Boa Treize (site web personnel) . En réponse au journal Adobe rachète Macromedia. Évalué à 4.
[^] # Re: Facile a contourner
Posté par Boa Treize (site web personnel) . En réponse au journal Amarok ça pue.. Évalué à 1.
1) Ce qui m'importe, c'est que le lecteur ne prenne pas de place à l'écran ; une icône en bas à droite, c'est amplement suffisant, et un popup bien mis en page lors d'un changement de morceau, c'est très bien (merci JuK).
2) Si je veux regarder une pochette (rare), je tends le bras, je prends l'album.
3) Si j'aime vraiment une pochette (rare encore plus), j'achette le 33 tours (s'il existe), parce que niveau format, c'est le pied.
Franchement, enfreindre tout plein de licences pour afficher une petite image pixellisée dans un coin d'interface, quel intérêt ?
# Plus d'info
Posté par Boa Treize (site web personnel) . En réponse au message comment lire une video en KMVC ?. Évalué à 4.
The codec was written by Karl Morton (a Team17 contract programmer) in the mid-90's and was a 256 colour decompresser that allowed palette changes per frame. This was mainly to support high-frame playback on slow CD players (1-4x in those times) since many people didn't like FMV's installed to Hard Drive (as is the norm now).
The actual compression codec is not around or accessible but it can be decoded these days and reconverted.
Aucune précision sur le décodage, pourtant possible d'après l'auteur du commentaire. Le fil de discussion contient plusieurs pistes pour un réencodage possible des vidéos de Worms 2.