Ce qui est sympa avec vim, c'est la façon dont les choses se combinent entre-elles et de façon assez intuitive. Si tu sais comment faire un marqueur et comment effacer du texte, tu sais naturellement comment effacer du texte jusqu'au marqueur.
Il n'y a pas très longtemps que j'utilise vim, mais voilà ma cheat sheet perso qui a encore besoin d'être complétée mais qui contient déjà pas mal de trucs bien pratiques :
Invocation :
vim
vim file
vim file1 file2
commande | vim -
view #mode lecture seule
vimdiff file1 file2 #mode merge
Ouvrir/sauver/quitter :
:w - sauve le fichier courant
:q - quitte
:q! - force quitte
:wq - sauve et quitte
:e file - ouvrir "file" dans un nouveau buffer
:bn - passe au buffer suivant
:bp - passe au buffer précédent
:wn - sauvegarde et passe au buffer suivant
Modes :
Vim est un éditeur modal, il y a donc différents modes
ESC - quitte le mode en cours
Mode insertion (édition) :
(i = insert, a = append, o = open)
i - insère avant le curseur
a - insère après le curseur
I - insère au début de la ligne
A - insère à la fin de la ligne
o - ouvre une nouvelle ligne sous la ligne en cours
O - ouvre une nouvelle ligne au-dessus de la ligne en cours
ctrl-p - propose l'auto-complétion du mot en cours à partir des mots du document
ctrl-x - propose l'auto-complétion du mot en cours à partir des mots du dictionnaire
Mode visuel (sélection) :
v - passe en mode visuel (sélection)
V - passe en mode visuel lignes (sélection de lignes)
ctrl-v - passe en mode visuel bloc (sélection d'un cadre de texte)
> - indenter la sélection
< - désindenter la sélection
= - indentation automatique de la sélection
Déplacement :
0 - début de ligne
^ - premier caractère significatif de la ligne
$ - fin de ligne
G - fin de fichier
:n - aller à la ligne n
Un chiffre devant une action du curseur répète l'action, par exemple 5 suivit de flèche vers le bas descend de cinq lignes.
Recherche :
/pattern - cherche "pattern" vers l'avant
?pattern - cherche "pattern" vers l'arrière
* - cherche le mot actuellement sous le curseur
n - continue la recherche vers l'avant
N - continue la recherche vers l'arrière
Rechercher/remplacer :
Vim accepte en gros les mêmes expressions que sed :
:%s/search/replace/ - remplace toutes les occurences du fichier
:%s/search/replace/c - idem mais demande confirmation
:'<,'>s/search/replace/ - remplace toutes les occurences du début à la fin de la sélection
Exemples :
indenter les lignes commençant par foo avec des tabulations :
:%s/^foo/\t/
commenter la sélection avec des # :
sélectionner des lignes de texte avec V puis :
:'<,'>s/^/#/
supprimer les retours chariot pour convertir les sauts de ligne CRLF ("DOS") en sauts de ligne LF ("Unix") :
:%s/\r//
Couper/Copier/Coller :
(d = delete, y = yank, p = paste)
d - coupe la sélection
dw - coupe un mot
dd - coupe la ligne courante
y - copie la sélection
yw - copie un mot
yy - copie la ligne courante
p - colle après le curseur
P - colle avant le curseur
(remplace la sélection si on est en mode visuel)
Ces actions peuvent être précédées d'un nombre et suivies d'un indicateur tel que 0, ^, $...
Exemples:
5dd - coupe 5 lignes
d$ - coupe jusqu'à la fin de la ligne
dG - coupe jusqu'à la fin du fichier
3yw - copie 3 mots
y0 - copie jusqu'au début de la ligne
2p - colle deux fois
Marqueurs :
Les marqueurs sont en gros un système de favoris à l'intérieur du document, pratique pour se déplacer dans les grands fichiers
mz - crée un marqueur "z" à la ligne courante
'z - va jusqu'au marqueur "z"
Les marqueurs peuvent être combinés avec d'autres commandes :
d'z - coupe jusqu'au marqueur "z"
y'z - copie jusqu'au marqueur "z"
Autres commandes de base :
:!foo - exécute la commande externe "foo" et en affiche la sortie
u - (undo) annule la dernière opération
ctrl-r - (redo) rejoue la commande annulée
. - rejoue la dernière opérationn
Configuration :
Vim est configurable via des variables
:set - montrer les valeurs qui diffèrent de la configuration par défaut
:set all - montrer toutes les valeurs
:set foo? - montre la valeur de foo
:set foo - active foo
:set foo=bar - assigne la valeur bar à foo
On peut mettre les variables dans ~/.vimrc pour une configuration persistente (dans ce cas, ne pas mettre le ':' devant set)
Variables utiles :
:set number - active la numérotation des lignes
:set dictionary=/usr/share/dict/words - dictionnaire, pour l'auto-complétion et la vérification orthographique
Plus d'infos :
:help
http://www.worldtimzone.com/res/vi.html
http://www.cs.swarthmore.edu/help/vim/home.html
http://vim.wikia.com
http://arstechnica.com/open-source/guides/2009/05/vim-made-easy-how-to-get-your-favorite-ide-features-in-vim.ars
Et mon .vimrc :
set nocompatible
set backupdir=~/.cache/vim
set smartcase
set hlsearch
" set number
syntax on
filetype plugin on
" remember last position
autocmd BufReadPost *
\ if line("'\"") > 0 && line("'\"") <= line("$") |
\ exe "normal! g`\"" |
\ endif
Pour les utilisateurs de vim sous bash :
echo "set -o vi" >> ~/.bashrc
et les commandes vi deviennent utilisables sous bash (par défaut en mode emacs) !
Mais systemd n’empêche pas d’utiliser fstab comme avant pour qu’il soit monté en dur avant le gestionnaire de connexion.
C'est même le par défaut. Pour faire du autofs il faut le spécifier explicitement via un 'comment=systemd.automount' à mettre dans les options de montage de /etc/fstab.
Perso je vois quelques avantages sur un serveur. À mon lieu de travail, sur certaines machines avec de fortes contraintes d'uptime à respecter sur des services donnés, bien souvent on se retrouve, sur des trucs un foireux, à devoir mettre en place des scripts de redémarrage de certains services (souvent des trucs à base de tomcat d'ailleurs...) lorsqu'ils plantent ou cessent de répondre.
La surveillance des services et la capacité de garder les requêtes qui arrivent quand le service est down pour les lui transmettre une fois démarré semblent intéressantes.
Le fait de killer proprement les services avec des cgroup devrait également éviter les problèmes liés aux scripts d'init qui n'éteignent pas tout ce qu'ils ont démarré quand on les stoppe. J'imagine aussi qu'on doit pouvoir se passer de xinetd et d'autofs au moins pour une partie des cas d'usages. Et le fait d'avoir directement le support de fonctionnalités qu'il fallait coder à la main dans chaque script d'init devrait aider à réduire leur complexité et le nombre de bugs dans ceux-ci.
Bref, ça devrait être plus simple, plus fiable et moins bancal dans pas mal de cas que les scripts d'init traditionnels et les hacks foireux parfois mis en place pour les accompagner, et ça ne peut qu'être bénéfique, qu'on soit sur un serveur ou un desktop.
D'après le lien ci-dessus :
> the longer term plan is to support translations for the descriptions the same way as .desktop files have them.
Ce qui veut dire que les traductions seront DANS les fichiers .service, vu que c'est comme ça que c'est fait avec les .desktop. Du coup, comme pour les .desktop, on risque de se retrouver avec, pour chaque valeur traduisible, un truc du genre :
Name=PulseAudio Sound System
Name[as]=PulseAudio শব্দ ব্যৱস্থা
Name[bn_IN]=PulseAudio শব্দ ব্যবস্থা
Name[ca]=Sistema de so PulseAudio
Name[cs]=Zvukový systém PulseAudio
Name[de]=PulseAudio Sound System
Name[de_CH]=PulseAudio Sound System
Name[es]=Sistema de Sonido PulseAudio
Name[fi]=PulseAudio-äänijärjestelmä
Name[fr]=Système de son PulseAudio
Name[gu]=PulseAudio સાઉન્ડ સિસ્ટમ
Name[hi]=पल्सऑडियो ध्वनि तंत्र
Name[hu]=PulseAudio hangrendszer
Name[it]=Sistema sonoro PulseAudio
Name[kn]=PulseAudio ಧ್ವನಿ ವ್ಯವಸ್ಥೆ
Name[ml]=PulseAudio സൌണ്ട് സിസ്റ്റം
Name[mr]=PulseAudio आवाज प्रणाली
Name[nl]=PulseAudio geluidssysteem
Name[or]=PulseAudio ଧ୍ୱନି ତନ୍ତ୍ର
Name[pa]=ਪਲਸਆਡੀਓ ਸਾਊਂਡ ਸਿਸਟਮ
Name[pl]=System dźwięku PulseAudio
Name[pt]=Sistema de Som PulseAudio
Name[pt_BR]=Sistema de som PulseAudio
Name[sr]=PulseAudio звучни систем
Name[sr@latin]=PulseAudio zvučni sistem
Name[ta]=பள்ஸ் ஆடியோ ஒலி கணினி
Name[te]=PulseAudio శబ్దపు సిస్టమ్
Name[uk]=Звукова система PulseAudio
Name[zh_CN]=PulseAudio 声音系统
Est-ce qu'on perd pas un peu l'avantage du côté clair et concis qu'on semblait avoir gagné ?
Un soucis quand même, à moins que ça ait changé récemment, syslog-ng patine lors de l’arrêt.
Quand j'ai testé mais ça date un peu il fallait prendre le syslog-ng-systemd ou un truc dans le genre sur AUR. Il a plus l'air d'exister donc j'imagine que ça doit avoir été fixé dans le paquet normal.
D'ailleurs le jour ou on aura des ACLs fournies de base, des processus qui ne se lancent jamais en root mais qui récupèrent les droits sur tel ou tel port à coup de setcap sur les utilisateurs et les fichiers, là je serais assez content. Ca fait plus de dix ans qu'on a les moyens de faire comme çà. Et aucune distrib Linux ne s'y est jamais vraiment attaché.
Ça avance quand même... Sous fedora, il n'y a je crois plus aucun binaire setuid root, que des capabilities. Et sous Suse, les ACLs sont activées par défaut (depuis longtemps).
Le portage de systemd sous ArchLinux s'intègre avec le /etc/rc.conf... Ce sont plutôt les scripts shell trouvés dans /etc/rc.d qu'il faut comparer aux fichiers de conf type INI de systemd pour les services/sockets/units etc.
j'ai sacrément peur de voir arriver ce truc qu'est systemd et qui me semble incroyablement lourd et inutile, pour une tâche aussi futile qu'améliorer le temps de démarrage
Le temps de démarrage n'est qu'un des aspects de systemd. Il s'agit aussi de faciliter l'exploitation de certaines fonctionnalités sympas de linux (cgroups, namespaces), d'économiser des ressources (ne démarrer certains services à l'usage occasionel que lorsqu'ils sont sollicités), d'augmenter la fiabilité du système (le service trucmuche qui fournit un socket utilisés par d'autres applications crashe ? pas de problème, systemd s'occupe de le redémarrer et s'assure que tous les messages qui sont envoyés sur le socket entretemps lui soient bien transmis) etc.
Personnellement déjà que policykit/consolekit on sais toujours pas à quoi ça sert
Ça tombe bien, je crois que le développement de consolekit (qui à ce que j'ai compris est plus ou moins un équivalent "++" à utmp/wtmp utilisé pour les droits côté policykit) à été repris par lennart pour le faire dégager au profit de systemd...
Mais c'est vrai qu'il y a une tendance à l'usine-à-gaz-ification du système ces derniers temps. C'est pas tant les ressources bouffées que le temps perdu à comprendre comment ça s'utilise et se configure qui me gêne (PolycyKit il en fout un peu dans /etc, un peu dans /var/lib et un peu dans /usr/share, même si dans ce dernier cas c'est plutôt pour les devs, avec du format INI et du XML histoire de varier sans doute...).
Je me lancerai pas dans un discussion là dessus, il y a du pour et du contre. Mais je crois qu'il se moque (dans les deux sens du terme) des autres distro comme il se moque de bsd.
Si tu fais une recherche sur des mots comme "suse" ou "debian" dans les messages de commit de systemd (http://cgit.freedesktop.org/systemd/), tu verras que le monsieur a à son actif une floppée de patchs destinés ni plus ni moins qu'à la compatibilité avec les autres distribs.
Donc je sais pas s'il "fait un noeud à sa capote avec", mais en tout cas il contribue du code...
NX est trop compliqué avec la documentation actuelle
Euh bof, FreeNX en tout cas est très facile à mettre en place.
Sinon pour améliorer les performances de X11 il faudrait déjà passer de Xlib vers XCB mais apparement il y a pas mal de résistance sur le sujet (voir le blog de Julien Danjou, auteur de Awesome).
Pour KMS, à partir du moment où FreeBSD va l'avoir, les autres BSD pourront sans doute se baser dessus pour le porter. Apparement DragonFly s'y est déjà mis et pourtant c'est pas un très gros projet :
"For those not using FreeBSD but rather DragonflyBSD, the code as of right now in FreeBSD 9-CURRENT has been ported to this BSD as well."
Il semble que la licence utilisée pour le code de freedesktop et le code du kernel Linux soit la licence MIT, donc compatible BSD, ce qui facilite la réutilisation.
Et sur la page du portage vers DragonFly on peut lire "We feel the fastest path to porting is through the DragonFly BSD project, but we intend for our code to be the basis for ports to all the BSDs." "We intend to write a portability layer that will allow the BSDs to use as much of the Linux drm code as possible. ". Ils disent aussi qu'une fois que les gars de FreeBSD ont porté le code le gros du travail était fait et que le diff avec leur version est pas énorme.
À mon avis il n'y a donc pas trop de quoi s'inquiéter concernant les *BSD, ça devrait aller vite.
Quand aux EFL, Fltk etc ils tourneront peut-être un certain temps dans un serveur X de compatibilité, comme le font certaines applications non-cocoa sous Mac OS. D'après ce thread sur le Phoronix qui date d'il ya presque un an les dev des EFL pensent que ça ne représente pas beaucoup de travail de porter sur Wayland et attendent juste une API stable et que le projet soit un peu moins "vaporware" (ce qui est surement le cas maintenant j'imagine ?).
Ce n'est pas juste une "différence de version", c'est un fork par un ancien employé de Red Hat, avec incrémentation du numéro de version au passage pour avoir l'air mieux.
Après laquelle est la meilleure je sais pas on trouve pas tellement d'infos sur le net, les deux ont l'air activement maintenues si l'on en juge par le nombre de commits. La plupart des distribs utilisent le RPM original (rpm.org) et rpm5 continue à utiliser CVS pour sa gestion de code, si ça peut être considéré comme des indicateurs valables...
Ah oui j'avais oublié cette histoire de compilation, faut dire que le seul truc que j'ai publié sur Launchpad c'est du python alors...
Ma question c'était de savoir si en ayant des sources sous bzr chez-eux ils pouvaient régénérer les paquets automatiquement, genre lorsque je commit ou une fois par jour.
Sinon personne a utilisé le truc de Suse (build service) ? Si je me souviens bien c'est supposé générer des paquets et des dépots pour plusieurs distribs, ce serait intéressant d'avoir un comparatif avec package-builder par quelqu'un qui a utilisé les deux.
sur Launchpad, les sources sont recompilees par le repo lui meme
Ah ? Comment tu fais-ça ? J'ai du passer à côté d'un truc, moi à chaque fois que je veux régénérer mes paquets je le fais à la main et les upload avec dput. Y'a moyen que Launchpad les reconstruise à chaque commit ?
Sinon concernant ta question si le projet permet de pondre des .deb on doit pouvoir les envoyer sur un depot debian genre un ppa via dput justement. En tout cas je vois pas ce qui l'empêcherai.
Bon OK ça permet de mettre deux fichiers cote à cote ce qui est pratique quand on fait un diff ou autre, mais 80 caractères je trouve ça trop court, se limiter à 100 ou 120 m'éviterait souvent de devoir passer à la ligne juste pour ça.
Après pour les gens qui codent en C et qui suivent la tradition d'avoir des noms de fonctions/variables les plus courts et cryptiques qui soient (genre appeler la moitié de ses variables "buf") c'est peut-être trop long, comme pour les dev C#/Java qui font quasiment des phrases en CamelCase c'est peut-être trop court, mais en tout cas on devrait définir cette limite selon les besoins d'aujourd'hui plus que selon la largeur des terminaux d'il y a 30 ans.
La dernière fois que j'ai utilisé Ant, j'avais un lien symbolique vers un dossier contenant des fichiers nécessaires au programme dans le dossier de build. En lançant "ant clean", cet abruti, plutôt que d'effacer le lien symbolique, a récursivement effacé le contenu de la cible... Bon heureusement tout était versionné je n'ai rien perdu, mais ça donne pas envie de poursuivre avec ant.
Et les fichiers XML de 50000 lignes c'est à se flinguer.
Je me sert pas souvent d'OCR mais il me semble que tesseract marche plutôt pas mal non ?
En tout cas après un petit test sur une image de texte scanné prise au hasard sur le web, il met la patée à ocrad 0.17 (ocrad 0.21 n'est pas packagé dans ma distrib et la flemme de compiler).
Après vérif sur un redmine 1.1 tout frais, ça n'est pas disponible par défaut. C'est vrai que ce serait sans-doute bien pratique.
Il y a un bug report avec un patch apparement destiné à la 1.0.4 sur http://www.redmine.org/issues/1675 (aucune idée de si le patch marche avec la 1.1, pas testé).
OOo a peut-être apporté des innovations, mais ça pourrait bouger beaucoup plus que ça les suites bureautiques...
Je ne sais pas ce qu'ils entendent par "changement de paradigme" mais s'ils comptent revoir certains concepts fondamentaux qui n'ont pas évolué depuis 20 ans ça pourrait être positif.
Par exemple le traitement de texte pourrait évoluer vers quelque chose de plus proche de LyX, avec une vraise séparation de fond/forme (oui je sais y'a les styles mais c'est assez limité et ça reste un truc bâtard avec la tradition de tout mélanger) permettant de changer les feuilles de style sur plein de documents d'un coup et d'en générer plusieurs versions selon le support auquel ils sont destinés.
Je trouve un peu fort de se prendre encore la tête aujourd'hui avec des mises en page, des marges et des sauts de ligne à placer à taton pour tomber juste sur les fins de page, alors que non seulement ça pourrait être automatisé mais bien souvent le document ne sera même pas imprimé et donc toute notion de page n'a aucun intérêt. Je sais qu'on va me dire que telle ou telle fonctionnalité permet de s'affranchir de ces problèmes, mais ce sont des ajouts pas vraiment intégrés à la philosophie du logiciel.
Et il en va de même pour les autres applications : pourquoi se borne-t-on a faire des présentations qui ne sont que des succession linéaires de slides alors qu'on pourrait imaginer bien d'autres façon de faire plus appropriées à certains contenus et/ou plus vivantes.
Bref s'ils sont prêts à tout casser moi ça me va !
Sauf que tant qu'il a pas utilisé ton mot de passe la banque doit annuler la transaction sans que tu ais à verser le moindre sous (paraîtrait que les banquiers essayent de faire raquer les gens quand même en profitant de leur ignorance de la loi, mais ça me semble étonnant on sait tous que ce sont des gens biens qui choisissent ce métier par amour pour le service rendu, à l'éthique irréprochable).
[^] # Re: En vrac, mes préférés
Posté par daemontux . En réponse à la dépêche Vim fête son 20e anniversaire. Évalué à 9.
Ce qui est sympa avec vim, c'est la façon dont les choses se combinent entre-elles et de façon assez intuitive. Si tu sais comment faire un marqueur et comment effacer du texte, tu sais naturellement comment effacer du texte jusqu'au marqueur.
Il n'y a pas très longtemps que j'utilise vim, mais voilà ma cheat sheet perso qui a encore besoin d'être complétée mais qui contient déjà pas mal de trucs bien pratiques :
Et mon .vimrc :
Pour les utilisateurs de vim sous bash :
echo "set -o vi" >> ~/.bashrc
et les commandes vi deviennent utilisables sous bash (par défaut en mode emacs) !
[^] # Re: Troll
Posté par daemontux . En réponse à la dépêche Firefox Sept : consommation mémoire nettement améliorée. Évalué à 10.
[^] # Re: .
Posté par daemontux . En réponse à la dépêche Linux Foundation tombe à son tour. Évalué à 6.
C'était. Du Solaris et du FreeBSD. Ils ont voulu migrer vers Windows dès 1997 et ont réussi vers 2005...
[^] # Re: Diverses remarques
Posté par daemontux . En réponse à la dépêche Évolutions techniques de systemd. Évalué à 2.
C'est même le par défaut. Pour faire du autofs il faut le spécifier explicitement via un 'comment=systemd.automount' à mettre dans les options de montage de /etc/fstab.
[^] # Re: Merci
Posté par daemontux . En réponse à la dépêche Évolutions techniques de systemd. Évalué à 9.
Perso je vois quelques avantages sur un serveur. À mon lieu de travail, sur certaines machines avec de fortes contraintes d'uptime à respecter sur des services donnés, bien souvent on se retrouve, sur des trucs un foireux, à devoir mettre en place des scripts de redémarrage de certains services (souvent des trucs à base de tomcat d'ailleurs...) lorsqu'ils plantent ou cessent de répondre.
La surveillance des services et la capacité de garder les requêtes qui arrivent quand le service est down pour les lui transmettre une fois démarré semblent intéressantes.
Le fait de killer proprement les services avec des cgroup devrait également éviter les problèmes liés aux scripts d'init qui n'éteignent pas tout ce qu'ils ont démarré quand on les stoppe. J'imagine aussi qu'on doit pouvoir se passer de xinetd et d'autofs au moins pour une partie des cas d'usages. Et le fait d'avoir directement le support de fonctionnalités qu'il fallait coder à la main dans chaque script d'init devrait aider à réduire leur complexité et le nombre de bugs dans ceux-ci.
Bref, ça devrait être plus simple, plus fiable et moins bancal dans pas mal de cas que les scripts d'init traditionnels et les hacks foireux parfois mis en place pour les accompagner, et ça ne peut qu'être bénéfique, qu'on soit sur un serveur ou un desktop.
[^] # Re: localisation
Posté par daemontux . En réponse à la dépêche Évolutions techniques de systemd. Évalué à 9.
D'après le lien ci-dessus :
> the longer term plan is to support translations for the descriptions the same way as .desktop files have them.
Ce qui veut dire que les traductions seront DANS les fichiers .service, vu que c'est comme ça que c'est fait avec les .desktop. Du coup, comme pour les .desktop, on risque de se retrouver avec, pour chaque valeur traduisible, un truc du genre :
Est-ce qu'on perd pas un peu l'avantage du côté clair et concis qu'on semblait avoir gagné ?
[^] # Re: Co(qu)illes
Posté par daemontux . En réponse à la dépêche Un entretien avec Lennart Poettering. Évalué à -10.
Euh ouais... Le minimum de la politesse quand on moinsse c'est d'expliquer pourquoi...
[^] # Re: Question sur systemd
Posté par daemontux . En réponse à la dépêche Un entretien avec Lennart Poettering. Évalué à 2.
Quand j'ai testé mais ça date un peu il fallait prendre le syslog-ng-systemd ou un truc dans le genre sur AUR. Il a plus l'air d'exister donc j'imagine que ça doit avoir été fixé dans le paquet normal.
[^] # Re: Co(qu)illes
Posté par daemontux . En réponse à la dépêche Un entretien avec Lennart Poettering. Évalué à 6.
Ça avance quand même... Sous fedora, il n'y a je crois plus aucun binaire setuid root, que des capabilities. Et sous Suse, les ACLs sont activées par défaut (depuis longtemps).
[^] # Re: Question sur systemd
Posté par daemontux . En réponse à la dépêche Un entretien avec Lennart Poettering. Évalué à 5.
Le portage de systemd sous ArchLinux s'intègre avec le /etc/rc.conf... Ce sont plutôt les scripts shell trouvés dans /etc/rc.d qu'il faut comparer aux fichiers de conf type INI de systemd pour les services/sockets/units etc.
[^] # Re: Modestie...
Posté par daemontux . En réponse à la dépêche Un entretien avec Lennart Poettering. Évalué à 8.
Le temps de démarrage n'est qu'un des aspects de systemd. Il s'agit aussi de faciliter l'exploitation de certaines fonctionnalités sympas de linux (cgroups, namespaces), d'économiser des ressources (ne démarrer certains services à l'usage occasionel que lorsqu'ils sont sollicités), d'augmenter la fiabilité du système (le service trucmuche qui fournit un socket utilisés par d'autres applications crashe ? pas de problème, systemd s'occupe de le redémarrer et s'assure que tous les messages qui sont envoyés sur le socket entretemps lui soient bien transmis) etc.
Ça tombe bien, je crois que le développement de consolekit (qui à ce que j'ai compris est plus ou moins un équivalent "++" à utmp/wtmp utilisé pour les droits côté policykit) à été repris par lennart pour le faire dégager au profit de systemd...
Mais c'est vrai qu'il y a une tendance à l'usine-à-gaz-ification du système ces derniers temps. C'est pas tant les ressources bouffées que le temps perdu à comprendre comment ça s'utilise et se configure qui me gêne (PolycyKit il en fout un peu dans /etc, un peu dans /var/lib et un peu dans /usr/share, même si dans ce dernier cas c'est plutôt pour les devs, avec du format INI et du XML histoire de varier sans doute...).
[^] # Re: Modestie...
Posté par daemontux . En réponse à la dépêche Un entretien avec Lennart Poettering. Évalué à 5.
Si tu fais une recherche sur des mots comme "suse" ou "debian" dans les messages de commit de systemd (http://cgit.freedesktop.org/systemd/), tu verras que le monsieur a à son actif une floppée de patchs destinés ni plus ni moins qu'à la compatibilité avec les autres distribs.
Donc je sais pas s'il "fait un noeud à sa capote avec", mais en tout cas il contribue du code...
[^] # Re: Plusieurs questions et remarques
Posté par daemontux . En réponse à la dépêche Effervescence autour de la pile graphique libre. Évalué à 8.
Sinon pour améliorer les performances de X11 il faudrait déjà passer de Xlib vers XCB mais apparement il y a pas mal de résistance sur le sujet (voir le blog de Julien Danjou, auteur de Awesome).
[^] # Re: Darwin vs diversité
Posté par daemontux . En réponse à la dépêche Effervescence autour de la pile graphique libre. Évalué à 8.
Pour KMS, à partir du moment où FreeBSD va l'avoir, les autres BSD pourront sans doute se baser dessus pour le porter. Apparement DragonFly s'y est déjà mis et pourtant c'est pas un très gros projet :
"For those not using FreeBSD but rather DragonflyBSD, the code as of right now in FreeBSD 9-CURRENT has been ported to this BSD as well."
Il semble que la licence utilisée pour le code de freedesktop et le code du kernel Linux soit la licence MIT, donc compatible BSD, ce qui facilite la réutilisation.
Et sur la page du portage vers DragonFly on peut lire "We feel the fastest path to porting is through the DragonFly BSD project, but we intend for our code to be the basis for ports to all the BSDs." "We intend to write a portability layer that will allow the BSDs to use as much of the Linux drm code as possible. ". Ils disent aussi qu'une fois que les gars de FreeBSD ont porté le code le gros du travail était fait et que le diff avec leur version est pas énorme.
À mon avis il n'y a donc pas trop de quoi s'inquiéter concernant les *BSD, ça devrait aller vite.
Quand aux EFL, Fltk etc ils tourneront peut-être un certain temps dans un serveur X de compatibilité, comme le font certaines applications non-cocoa sous Mac OS. D'après ce thread sur le Phoronix qui date d'il ya presque un an les dev des EFL pensent que ça ne représente pas beaucoup de travail de porter sur Wayland et attendent juste une API stable et que le projet soit un peu moins "vaporware" (ce qui est surement le cas maintenant j'imagine ?).
[^] # Re: Intérêt
Posté par daemontux . En réponse à la dépêche Mageia : La Primavera est là !. Évalué à 5.
Ce n'est pas juste une "différence de version", c'est un fork par un ancien employé de Red Hat, avec incrémentation du numéro de version au passage pour avoir l'air mieux.
Après laquelle est la meilleure je sais pas on trouve pas tellement d'infos sur le net, les deux ont l'air activement maintenues si l'on en juge par le nombre de commits. La plupart des distribs utilisent le RPM original (rpm.org) et rpm5 continue à utiliser CVS pour sa gestion de code, si ça peut être considéré comme des indicateurs valables...
[^] # Re: Migration depuis OOo
Posté par daemontux . En réponse à la dépêche LibreOffice est de sortie !. Évalué à 7.
mv ~/.openoffice.org ~/.libreofficeAu passage ils auraient pu profiter de renommer le dossier pour se mettre en conformité avec la spec XDG...
[^] # Re: Adieu JVM
Posté par daemontux . En réponse à la dépêche Project-Builder 0.10.1 est disponible. Évalué à 2.
Ma question c'était de savoir si en ayant des sources sous bzr chez-eux ils pouvaient régénérer les paquets automatiquement, genre lorsque je commit ou une fois par jour.
Sinon personne a utilisé le truc de Suse (build service) ? Si je me souviens bien c'est supposé générer des paquets et des dépots pour plusieurs distribs, ce serait intéressant d'avoir un comparatif avec package-builder par quelqu'un qui a utilisé les deux.
[^] # Re: Adieu JVM
Posté par daemontux . En réponse à la dépêche Project-Builder 0.10.1 est disponible. Évalué à 1.
Ah ? Comment tu fais-ça ? J'ai du passer à côté d'un truc, moi à chaque fois que je veux régénérer mes paquets je le fais à la main et les upload avec dput. Y'a moyen que Launchpad les reconstruise à chaque commit ?
Sinon concernant ta question si le projet permet de pondre des .deb on doit pouvoir les envoyer sur un depot debian genre un ppa via dput justement. En tout cas je vois pas ce qui l'empêcherai.
[^] # Re: Ant ?
Posté par daemontux . En réponse à la dépêche Redo, un remplaçant de choix pour Make. Évalué à 2.
Bon OK ça permet de mettre deux fichiers cote à cote ce qui est pratique quand on fait un diff ou autre, mais 80 caractères je trouve ça trop court, se limiter à 100 ou 120 m'éviterait souvent de devoir passer à la ligne juste pour ça.
Après pour les gens qui codent en C et qui suivent la tradition d'avoir des noms de fonctions/variables les plus courts et cryptiques qui soient (genre appeler la moitié de ses variables "buf") c'est peut-être trop long, comme pour les dev C#/Java qui font quasiment des phrases en CamelCase c'est peut-être trop court, mais en tout cas on devrait définir cette limite selon les besoins d'aujourd'hui plus que selon la largeur des terminaux d'il y a 30 ans.
[^] # Re: Ant ?
Posté par daemontux . En réponse à la dépêche Redo, un remplaçant de choix pour Make. Évalué à 2.
Et les fichiers XML de 50000 lignes c'est à se flinguer.
[^] # Re: OCR
Posté par daemontux . En réponse à la dépêche GNU ddrescue 1.14 et GNU Ocrad 0.21. Évalué à 3.
En tout cas après un petit test sur une image de texte scanné prise au hasard sur le web, il met la patée à ocrad 0.17 (ocrad 0.21 n'est pas packagé dans ma distrib et la flemme de compiler).
[^] # Re: scrum
Posté par daemontux . En réponse à la dépêche Gérez vos projets avec Redmine. Évalué à 1.
Il y a un bug report avec un patch apparement destiné à la 1.0.4 sur http://www.redmine.org/issues/1675 (aucune idée de si le patch marche avec la 1.1, pas testé).
[^] # Re: Sortir de sa léthargie
Posté par daemontux . En réponse à la dépêche LibreOffice : ça va bouger !. Évalué à 8.
Je ne sais pas ce qu'ils entendent par "changement de paradigme" mais s'ils comptent revoir certains concepts fondamentaux qui n'ont pas évolué depuis 20 ans ça pourrait être positif.
Par exemple le traitement de texte pourrait évoluer vers quelque chose de plus proche de LyX, avec une vraise séparation de fond/forme (oui je sais y'a les styles mais c'est assez limité et ça reste un truc bâtard avec la tradition de tout mélanger) permettant de changer les feuilles de style sur plein de documents d'un coup et d'en générer plusieurs versions selon le support auquel ils sont destinés.
Je trouve un peu fort de se prendre encore la tête aujourd'hui avec des mises en page, des marges et des sauts de ligne à placer à taton pour tomber juste sur les fins de page, alors que non seulement ça pourrait être automatisé mais bien souvent le document ne sera même pas imprimé et donc toute notion de page n'a aucun intérêt. Je sais qu'on va me dire que telle ou telle fonctionnalité permet de s'affranchir de ces problèmes, mais ce sont des ajouts pas vraiment intégrés à la philosophie du logiciel.
Et il en va de même pour les autres applications : pourquoi se borne-t-on a faire des présentations qui ne sont que des succession linéaires de slides alors qu'on pourrait imaginer bien d'autres façon de faire plus appropriées à certains contenus et/ou plus vivantes.
Bref s'ils sont prêts à tout casser moi ça me va !
[^] # Re: Haiku vs TiltOS
Posté par daemontux . En réponse à la dépêche Bon anniversaire Haiku !. Évalué à 1.
[^] # Re: Pointer dans le bus
Posté par daemontux . En réponse au journal Ici on parle de liberté, de surveillance et de Twisto.. Évalué à 3.