Pinaraf a écrit 3682 commentaires

C'est quoi le rapport avec le fork de KOffice ?
Le fork de KOffice est là surtout parce que le mainteneur de KWord était un casse couilles professionnel qui refusait l'aide de Nokia sur le projet par exemple.

* GVFS s'intègre avec Fuse ce qui permet d'accéder en console aux accès distants monté par Nautilus;
Il est possible de faire ça également avec les KIO, et ce depuis KDE 3 il me semble, à l'aide de http://techbase.kde.org/Projects/KioFuse
Mais les KIO peuvent exprimer des choses qui ne sont pas exprimables avec le VFS POSIX...

* NM avec nmcli pour contrôler interfaces et connexions;
C'est quoi le rapport avec la choucroute ? Network Manager se veut multi-bureaux, et nmcli est indépendant du bureau.

(il n'est pas possible de spécifier son DNS, par exemple).
Il me semble que c'est disponible sur les dernières versions, je devrais réessayer (vu toutes les merdes que j'ai eu avec network manager et wicd, je suis passé à un simple ifup/ifdown en ligne de commande, largement plus simple et plus efficace)

Phonon rempli son boulot parfaitement il me semble : si l'équipe de KDE avait choisi, mettons, xine à l'époque de KDE 4.0 (gstreamer, avec la difficulté de migration lors du passage de la 0.8 à la 0.10, n'était pas du tout le meilleur candidat à l'époque), on leur reprocherait sûrement ce choix maintenant.
On reprochait également à KDE 4 la création de Solid comme abstraction au dessus de Hal. Maintenant, avec udisks/upower qui remplace Hal (mais qui n'est pas il me semble encore disponible sur les BSD), il est nécessaire de supporter les deux systèmes en même temps... Merci donc à Solid pour ça !

J'ai la chose en stock chez moi, en attente d'une installation de Linux.
Je n'ai pas encore réussi, je posterai un journal à ce sujet. Pour l'instant je peux installer un linux sur une carte SD et le faire booter.
J'utilise buildroot, ça permet de faire un système très léger adapté à la cible.
Le noyau, une debian clé en main et deux trois trucs sont dispos sur le net en cherchant bien.
Par contre, mettre un linux sur la mémoire nand provoque chez moi un écran noir au boot pour l'instant. Et l'accès au port de debug sur la carte mère implique un passage au fer à souder...

Sauf que la consigne interne est de ne pas retourner le couteau dans la plaie, une majorité ne s'étant pas dégagée lors de votes pour officiellement éjecter le mainteneur de KWord de la communauté de KOffice.

- visualisation en ligne directe (pas à ouvrir le document sur son poste, pas besoin de le télécharger, pas besoin d'avoir le bon lecteur suivant le format : pdf, ppt, pptx, etc)
Heu, je préfère de très loin un lien vers un pdf, qui sera ouvert directement dans mon navigateur (Konqueror) grâce à Okular... Alors que l'horreur en question, scribd, ne me permet pas de voir le document dans mon navigateur.
Ho, bien sûr je pourrais télécharger le document ... Ha, non, raté, je dois avoir un compte facebook (le nouveau SSO du Web ?) ou un compte sur scribd.

Donc non, je ne comprends pas l'intérêt d'un tel service.

Apparemment, l'auteur de HAL n'est pas de ton avis, puisque c'est lui qui a commencé à travailler sur un remplaçant, ce qui a donné Udisks et Upower, basés directement sur Udev. Et même X.org envisage de ne plus utiliser HAL.
Et sur les OS où HAL n'est pas encore remplacé, on supprime tout et on vire les fonctionnalités associées ? J'en connais qui vont être contents...

On peut faire à Solid le même reproche que Phonon : c'est le strict minimum, puisqu'on s'attache au plus petit dénominateur commun entre les systèmes sous-jacents possibles.
On peut faire à Upower le même reproche : c'est le strict minimum, à moins de ne pas être portable sur différents OS...

Justement, c'est quoi ces nouvelles fonctionnalités ? Je n'ai pas réussi à comprendre ce qu'ils veulent dire par « faceted ». Et au vu des captures, ça ne semble pas différents de ce que sait faire Nautilus.
Recherche dans les tags, diverses méta données... Donc à moins que nautilus n'ait progressé récemment, ce n'est pas une fonctionnalité que j'y ai vu... (Je n'ai pas testé les deux dernières versions, mais je n'ai rien vu de tel dans le changelog)

C'est quasiment ça : la possibilité de laisser les utilisateurs lambda créer des partages Samba, notamment avec un clic droit/propriétés. Mais je ne m'en sers pas non plus (entre Unix, pas besoin de Samba).
J'utilise pas Samba non plus, mais j'ai déjà un clic droit => propriétés => partager dans KDE 4.4...

Effectivement, mea maxima culpa, je ne classais pas du tout la majorité des trucs listés sur la page http://sourcemaking.com/refactoring comme étant du refactoring.
Maintenant, tu peux me dire tout de même comment l'exemple très simple que j'ai donné peut être réalisé avec un langage dynamique ?
À savoir deux classes A et B contenant une méthode test, et tu veux renommer test dans la classe A...

En même temps, quel intérêt de se débarasser de HAL, qui marchait, pour passer à un ensemble qui à ma connaissance est encore moins portable que HAL ? Udisks est dispo pour FreeBSD maintenant (c'était une critique que j'ai souvent lue, et ça semble ne pas être dispo après une rapide recherche google) ?
Au contraire, et on voit là l'intelligence d'une des décisions de KDE 4 : KDE est capable d'utiliser HAL ou les nouveaux trucs spécifiques à linux, sans impacter chaque application... Alors que dans le cas de Gnome, sans les devs payés par Canonical ou Redhat pour convertir chaque appli (et pourquoi ils n'ont payé personne pour faire le backend Solid ?), ça aurait pris plus de temps je pense.
Pour l'intégration de Git, à l'ouest rien de nouveau, perso je conseillais git-cola jusqu'à maintenant.
Pour les recherches, nautilus + tracker ne permet pas ce que permettent les nouvelles fonctionnalités de dolphin il me semble (et de toute façon, tant qu'il n'y a pas de fanotify ou équivalent utilisable sous Linux, tout système d'indexation des fichiers sera merdique).
Quant aux usershares... Heu, c'est quoi honnêtement ? La possibilité de partager un dossier depuis le navigateur, ou quelque chose d'autre ?

Comprend pas ton exemple.
Le monsieur parlait de refactoring. Du refactoring en python, ruby ou autre langage dynamique, c'est quasi impossible : ça implique, pour l'outil de refactoring, de faire une reconnaissance des types utilisés à travers tout le code...

En attendant de trouver une solution, je me demande si le choix d’Ubuntu de passer en mode Rolling Release est une bonne idée, je me demande bien comment un utilisateur standard va bien pouvoir s’en sortir sans tripatouiller la configuration en ligne de commandes.
Non, Ubuntu ne va pas passer en Rolling Release.
Il n'y a pas encore eu suffisamment de démentis ?
http://theravingrick.blogspot.com/2010/11/ubuntu-is-not-movi(...) (blog de Rick Spencer, "Engineering Director" d'Ubuntu)

À noter que MS Office pour Android n'existe pas, et qu'OpenOffice non plus (peut être est-il trop lourd pour fonctionner sur les SmartPhone ou Netbook ?)
Ce n'est pas qu'une question de poids. Vu la puissance des derniers appareils sortis...
Premier point, OpenOffice.org n'est pas conçu pour une interface de type smartphone ou un écran trop petit (pour un netbook, c'est donc limite)
Deuxième point, Android est trop différent d'une plateforme Linux traditionnelle pour qu'une simple recompilation suffise pour y porter OpenOffice.org : il faudrait installer un serveur X, revoir aussi pas mal d'éléments de l'interface graphique... Porter proprement OpenOffice.org sur Android sera(it) un travail titanesque (en jouant avec le NDK, et en réécrivant pas mal de morceaux d'OpenOffice.org, ça doit être faisable), je ne pense pas que beaucoup de volontaires se présentent pour le réaliser...

En effet, excuse moi, je voulais parler de typage statique. (Ne plus commenter si tard)

Le soucis, c'est que (en tout cas dans mon cas) en cours, on apprend aux pauvres petits étudiants les EJB, struts et autres horreurs...
Forcément après quand ils voient <?php echo "hello world"; ?> ils sont excités et passent du côté obscur :)

Tu as tout à fait raison sur les points que tu évoques je pense.
Pour ma part, je déplore fortement la non-popularité des langages fortement typés. Le duck typing de python par exemple me semble très nocif pour la maintenabilité à long terme d'une application. Bon, le random typing de PHP, c'est pire, n'en parlons pas...
Pour l'absence d'IDE "potable", c'est lié à deux choses :
- les choix personnels : tout le monde n'apprécie pas un monstre tel eclipse ou netbeans. Pour ma part, j'aime bien KDevelop mais surtout Qt Creator, qui est léger et contient juste ce qu'il me faut.
- l'absence de typage rendant très délicates des opérations comme le refactoring. Soient deux classes A et B contenant chacune une méthode test. Si tu renommes A::test en A::plop, comment s'assurer que ce qui est renommé dans le code est bien une instance de A et pas une instance de B ?

Par contre à l'inverse, la plupart des frameworks dans des langages avec un typage fort vont être imbuvables ou avoir une architecture ultra compliquée (je pense que c'est lié à la fois techniquement et par "l'état d'esprit" des développeurs dans ces langages)...
C'est le principal soucis des framework Web Java à ma connaissance... À quand le Java on Rails ? :) Ou le C+lons :)

J'ai mis un serveur à genoux avec moins que ça, oui... Grâce à des frameworks PHP pas optimisés du tout, c'est facile à faire...
Et une page d'accueil qui bouffe 2 secondes de CPU côté serveur (et avec les caches du framework activés), c'est pas la joie.
Au passage, je n'ai pas dit que c'est un mauvais choix, loin de là, je demande juste pourquoi Ruby On Rails en prenant en compte la réputation que j'en ai perçu, c'est tout. Si jugement il y a, c'est dans ton interprétation de mon commentaire, pas dans mon commentaire.

Pareil pour Django.
Pareil pour Synphony.
Pareil pour tout framework bien foutu quoi...

Heu, honnêtement, choisir un CMS ça a été considéré sérieusement pour Linuxfr ??
Vu les performances de ces trucs en général... (j'ai bouffé du drupal, je veux plus jamais y toucher)

Merci pour cette explication de l'abandon de Templeet... Ça fait des années qu'on nous dit que Templeet pour Linuxfr pose des problèmes, il est clair qu'il faut migrer un jour ou l'autre.
Par contre, pourquoi choisir Ruby on Rails ?
Est-ce un choix justifié techniquement, ou juste une préférence personnelle ?
J'ai souvent lu des critiques concernant les performances souvent mauvaises de Ruby on Rails, et pour un site comme LinuxFR je pense que les performances ça compte énormément. Actuellement, la navigation est très fluide, le site ne rame pas du tout, c'est un plaisir à utiliser. Si demain le site devenait plus lent, ce serait une réelle régression...
À titre personnel, je ne contribuerai pas à un LinuxFR en Ruby on Rails tout simplement parce que je n'aime pas le développement web et que je ne connais ni Ruby ni Ruby On Rails.

au fait, le serveur espagnol qui permet de définir des zones et de sauvegarder en local toutes les cartes, toutes selon le niveau, de gmaps, fonctionnent toujours...
Et ?
Ça sert à rien pour le projet OSM (ça serait totalement illégal).
Et ça reste des données non éditables, en raster uniquement, alors qu'avec un simple maposmatic tu peux avoir une carte en vectoriel avec par exemple un index des rues...

Je suis pas certain qu'on puisse parler de pourcentages de priorité. En tout cas, à ma connaissance, c'est pas implémenté sous Linux. Au mieux tu as une liste fixe de niveaux de priorité, et c'est heureusement suffisant pour normalement tous les cas.

Pour clarifier : choisir ce qui est prioritaire : un utilisateur lambda, les services du système...
Par exemple tu peux imaginer rendre SSH super prioritaire, avoir un utilisateur guest le moins prioritaire possible, ton utilisateur à toi être plus prioritaire que certains services à la con...
Bref, tu peux configurer et choisir.

Ben de toute façon ce que tu suggères n'est tout simplement pas viable.
Je vois mal un mplayer sur un film HD, un jeu, un compilateur ou autre tenir avec moins de 5% du CPU (l'init a quand même une cinquantaine d'enfants chez moi).
La séparation en groupe est suffisante, sans allouer de manière fixe des portions de CPU ce qui serait un énorme retour en arrière...

Comme déjà expliqué : un cgroup par fils lancé par l'init. Ensuite tu peux imaginer compter les fils de chaque groupe pour déterminer si il faut plus ou moins de CPU pour ce groupe, mais dans ce cas c'est risquer qu'une fork bomb prenne tout le CPU pour elle toute seule...

Paquet cgroup-bin (pour debian et dérivés, pour Fedora c'est dans un autre paquet il me semble), tu as la commande cgexec.
Tu dois pour l'utiliser
1) configurer un ensemble de groupes (en les nommant, par exemple un groupe "compilation barbare", un groupe "service ultra prioritaire"...) : fichiers de configuration /etc/cgrules.conf et /etc/cgconfig.conf
2) cgexec -g cpu,memory:compilation_barbare make -j 2000000

Bien sûr, tu peux imaginer créer à la volée des groupes, à l'aide de cgcreate.