freem a écrit 5019 commentaires

Imaginons une requête SQL particulièrement complexe ou sur une quantité de données particulièrement impressionnante.
Compte tenu du fait que ce n'est pas progressif, comment tu fais pour envoyer les résultats progressivement?

Enfin bon, à mon très humble avis, un site qui mets 5 minutes à renvoyer un résultat, il y a peu de personnes qui vont y rester.

Je serai curieux de voir un binaire issu d'un programme bash?

Euh… sérieux?
Tu as vraiment pris cette valeur pour une référence? Dommage, c'était pas le but, j'aurai tout aussi bien pu dire 42 pixels, ou 1337…

Sinon, pour la taille des écrans:
$ xrandr --output VGA1 --mode [TAB][TAB]
1024x768 1152x864 1280x1024 1280x720 1280x800 1280x960 1400x1050 1600x900 1680x1050 1920x1080 640x480 720x400 800x600

Moi, je monte quand même à 1920 ( marrant le 8192 d'ailleurs? ) de large… et si j'étais un dev égocentrique, je pourrais faire une assertion sur le fait que tout le monde à les mêmes écrans que moi, et au fond, le matos, ça coûte pas cher, le client n'a qu'a upgrade ( petite pensée pour un de mes profs de BTS au passage… mouarf! ).
Et je n'ai aucune raison de supposer que mon application web n'est pas seule au monde, non plus. Après tout, le navigateur, c'est bien le nouvel OS? Alors pourquoi devrait-je partager "mon" espace écran avec quelqu'un d'autre?

Bref, malheureusement, oui, j'ai déjà eu la joie de tomber sur des sites qui font des assertions foireuses sur la taille de ma… mon écran.

PS: est-ce qu'il existe un moyen que linuxfr n'interprète pas le contenu d'une portion de texte? Parce que le rendu de la commande "$xrandr" avec tous les espaces en préfixe est complètement illisible…

Hum… dans le cas d'un outil tournable, pourquoi pas, mais je me vois mal tourner mon écran de bureau dans tous les sens, en plus il faut pour ça que je me rappelle la connectique de l'écran sur laquelle je mets mon brouteur…

Désolé, mais je n'ai pas l'impression qu'il me manque énormément de choses dans le vim de base, que ce soit pour mes projets C++, pour les documents LaTeX que je gribouille ou pour les scripts bash que je bricole.

Le débogueur, comme je l'ai dis, ce n'est à mon avis pas le boulot de l'éditeur de texte, et taper "!cg" ( pour rappeler la dernière invocation de cgdb ) dans un terminal ne me pose aucun problème.
Pour le reste, je ne suis pas sûr…
Par inspecteur mémoire, tu parles bien de valgrind?
Personnellement, dans ma phase de développement, je m'arrange déjà pour que ça marche. Une fois que c'est le cas, je m'occupe d'optimiser ce qui coûte trop cher. Pour ce qui est des memory leaks, j'avoue avoir plutôt confiance dans les smart pointers du C++ et la RAII.

Quant au modèle sémantique, je ne comprend absolument pas de quoi tu parles? L'auto-complétion? Si je voulais un truc riche, j'utiliserais ctag, mais… en fait, je n'en ai pas besoin: il me suffit d'inclure un header local pour avoir accès aux mots qui y sont inclus. Je n'ai pas besoin de plus en la matière.

Je me trompe peut-être, et je serai heureux de découvrir ces outils dont tu parles. Si ça se trouve, j'en trouverais un utile.

« langage de script » ça ne veut pas dire grand chose techniquement

Je cite wikipédia: "En informatique, un script est un programme en langage interprété (voir Langage de script)."
Donc, un langage de script est un langage interprété.

la question n'est pas si telle ou telle fonctionnalité est originale

Si tu veux vendre un langage ayant une fonctionnalité que tout le monde la possède déjà, je ne parviens pas à imaginer que l'on puisse considérer ça comme un avantage sur les autres.
Et les habitudes de dev, d'une part, ça varie vachement entre utilisateurs d'un langage, et d'autre part ça dépend des utilisateurs, pas du langage.

Pour finir, le fait qu'un langage soit plus vieux qu'un autre ne me semble pas un argument pertinent pour dire qu'il est meilleur. Par exemple, le langage C ne me semble pas meilleur que C++, pourtant il est plus vieux et plus répandu.
Objectivement, l'âge du capitaine n'a rien a voir avec le fait qu'il soit ou pas un bon capitaine.

Ce qui est dit dans je journal, c'est que ça ne cible que des configuration précises. Il me semble qu'il y avait assez d'emphase le sur le fait que cette faille est compliquée à exploiter à cause de ce fait d'ailleurs?

Pourquoi mettre une contrainte?

Si le texte occupe toute la largeur de l'application, il n'y à aucun problème. Si l'utilisateur utilise la largeur totale de son écran, c'est que ça lui plaît, sinon, une fenêtre, ça se redimensionne.

Quand un site fait l'assertion que mon écran fait plus de 1500 px de large, bah c'est assez horrible. Sur mon desktop, je dois limite tourner la tête à chaque ligne, et sur mon netbook je dois scroller!
Peu importe le cas, je suis emmerdé par les largeurs fixes, sans parler des bugs d'affichage…

Ahhhhh ouai, en fait, le truc que j'utilisais déjà quand je tapais mes 1ères lignes de code avec QBasic!
Il était d'ailleurs même possible de modifier le code en cours de déboguage, voire d'insérer ponctuellement du code en milieu d'exécution.

Mais bon, je pense que tous les langages de scripts avec un IDE potable le permettent, non?
D'ailleurs, je ne sais pas le faire avec gdb pour les langages compilés, mais je ne suis pas sûr que ce soit une limite du débogueur, juste de l'utilisateur—moi—pour le coup ( je sais qu'il est possible de modifier le contenu d'une variable et de fixer la prochaine instruction à exécuter, je ne sais juste pas s'il est possible d'insérer du code en cours d'exécution. Ça me semble complexe, mais pas infaisable. Peut-être que LLDB en sera capable, même si GDB ne l'est pas? A voir. ).

Bon, allez, je t'accorde ça: comparé à QB, pharo n'est pas fermé, ni produit par MS, et peut gérer des fenêtre graphiques. Je ne maîtrise pas suffisamment les langages de scripts plus modernes, mais je ne doute pas qu'ils aient aussi ces caractéristiques tout en permettant l'insertion/l'altération de code en live.

Mon éditeur de texte ne fait pas tout ça, dans la configuration que je lui ai faite. Et je ne veux pas.
Par contre, j'ai d'autres outils, des scripts et petits gadgets, qui eux, me permettent de le faire.
En fait, mon IDE, c'est mon système complet, alors que toi, tes outils réinventent sans cesse la roue. Combien as-tu de gestionnaires de fenêtre qui tournent au total sur ton système quand tu programme?
Le WM du système, probablement celui de ton navigateur internet, celui de ton IDE, tu utilises peut-être un outil d'administration de BDD séparé?

Du coup:

• le trou de mon bureau en dessous de ma souris à cessé de se creuser, et mon poignet de me faire souffrir ( hum… je n'aurais peut-être pas dû mentionner ça… XD )
• je peux adapter n'importe lequel de mes outils à ma tâche du moment ( je ne connais aucun IDE permettant de faire à la fois du C++, du perl, du bash, du SQL et du LaTeX… à chaque fois il faut apprendre à utiliser un nouvel outil. Pas avec vim. )
• mon système ne contiens presque plus d'outils redondants, et je suis donc capable de programmer quasi aussi efficacement avec un ultraportable qu'avec une machine de bureau multi-écrans. Essaies donc avec eclipse+gnome, qu'on se marre…
• je n'ai plus besoin de configurer séparément chaque usine à gaz pour qu'elle se comporte de la même façon que les autres qui ont un rôle proche et/ou partagé.

Répéter la philosophie UNIX, ce n'est pas juste utiliser des outils non interactifs ( y a pas que grep dans la vie ), au fait.
Je considère, par exemple, que mpd+mpc ( rien à voir avec la programmation, je sais ) respectent très bien cette philosophie, pourtant c'est interactif, et je ne vois aucun défaut à leur approche. A part que, du coup, on à un vaste choix de clients, du coup il faut choisir lequel correspond le mieux à son propre besoin… choisir, ça prend du temps, avec un lecteur classique c'est plus facile, il n'y a que les skin à choisir… ( et on se tape un lecteur de musique qui affiche de la visualisation dont on à pas besoin… ok, c'est une option opt-out, mais bon… ça reste discutablement utile à 90% des usages. )

Pour conclure, je dirais que la philosophie UNIX est très proche de la philosophie objet: chaque composant fait une chose et la fait bien, possède une interface claire, à un couplage le plus faible possible avec les autres.
Je ne répète pas UNIX, je pense objet.

Mouai.

Changer de paradigme est un truc qui m'effraie tellement que je suis passé en moins de 5 ans de windows à Debian, puis de l'usage d'un DE monolithique à un ensemble d'applications sélectionnées par mes soins, des gestionnaires de fenêtre en pile à ceux pavant, et enfin de l'usage d'IDE monolithiques à l'utilisation des outils que me propose mon système*.

Chaque fois, j'ai eu l'impression de maîtriser de plus en plus mon environnement, et chaque fois, j'ai "gagné un niveau" comme on dirait dans chez les joueurs de rpg.

Le changement ne me fait pas peur, par contre, avant de changer, je pèse le pour et le contre. Changer pour changer… non merci.

*: et ma roadmap inclue d'aller voir du côté des bsd et/ou de gentoo

Je me suis mis à blender récemment ( enfin, j'essaie d'apprendre ).

Par contre, ma CG ( nvidia ) n'est pas vraiment un truc super puissant.

Toujours est-il que NVidia propose des pilotes pour Debian, et si tes packages sont trop anciens, rien ne t'empêche de ne pas utiliser Debian stable, mais testing, ou unstable.
Si tu préfères garder majoritairement du stable mais n'upgrade que quelques paquets, tu peux utiliser la technique dite de l'apt-pining:
tu mets les 2 versions de debian que tu veux dans tes sources, puis tu crées un fichier /etc/apt/preferences ( ou mieux, tu ajoutes un fichier dans /etc/apt/preferences.d ) qui mets la plus stable en priorité plus haute pour tous les paquets, et ensuite tu mets une priorité plus élevée aux paquets plus récents que tu souhaites.

Il y a pas mal de littérature sur le sujet sur la toile, donc je pense que je peux te laisser taper apt-pinning sur ton moteur favori?

Note: suite à une dépêche récente, il semblerait que les paquets KDE soient un peu en retard dans Debian, à cause du manque de mainteneurs. Pour ma part, je n'utilise de toute façon aucun DE monolithique, mais une configuration à base de TWM et d'outils choisis à la main.

Ça, ça reste à prouver.

Je ne peux plus retourner à google pour les recherches, à cause du fait que DDG ajoutes pas mal de features que google n'a(vait?) pas, genre, pour "test" proposer plusieurs significations. Ou proposer le site officiel avec un bandeau pour bien le reconnaître et pas confondre avec un distributeur de malwares.

Sinon, il suffit d'ajouter "kl=fr-fr" à l'URI.
Mais bon, ça fait partie des trucs que DDG aide justement à contourner, l'effet bulle ( qui, parfois, peut être souhaitable, certes ).

Sinon, selon:

In the settings, you can change your region, which boosts results for that region.

You can switch regions quickly on a per-query basis by adding r:fr to the end of the query (e.g. in that case the region would be France). That is a shorthand for the full syntax of region:fr-fr (full list of available regions is at our URL params page).

Using the region setting will boost results within that region (as opposed to exclusively displaying results for that region). Alternatively, you can restrict results to country domains, by adding site:uk to the end (for *.uk).

Unfortunately, we don't have complete control of the regions as we rely on some external sources to help us with them. But we're constantly monitoring them to allow for more.

Il suffit d'ajouter site:fr ou region:fr-fr à la recherche.

Ça, franchement, c'est plutôt un truc qui me fait peur pas qui m'attire…

Mon éditeur de texte est un outil. Mon compilateur en est un autre. De même pour mon gestionnaire de fenêtres, mon débogueur, etc.
Le fait que ce soient des outils distincts, souvent exploitables en ligne de commande, me permet de les utiliser pour de multiples usages et de configurer mon "environnement de bureau" à ma sauce, parce qu'aucun dev ne saura jamais ce dont j'ai besoin actuellement, et encore moins demain.
Ça permets aussi de remplacer n'importe quel outil par un autre plus adapté sans devoir changer la totalité de mes habitudes.

Et accessoirement, ça me donne l'impression qu'il faut encore rajouter une surcouche… comme si les systèmes modernes n'en avaient pas déjà trop?

Enfin, j'ai peut-être mal compris, et il est peut-être possible d'utiliser ce langage en dehors de l'environnement limité par l'imagination de ses dev ( ce n'est pas une insulte, tout le monde à une imagination limitée, c'est pourquoi je trouve la philosophie UNIX très intéressante, elle bride moins les utilisateurs que la philosophie tout en un, même si la contrepartie est un temps d'apprentissage pour la maîtrise supérieur. Comme tout outil puissant et flexible, en fait. )

Je n'ai pas écouté la vidéo, suis au boulot, mais je n'ai rien vu de transcendant.
Pourrais-tu être plus explicite sur la fonctionnalité que tu pointes?

C'est vrai. On peut passer par un moteur de recherche, comme la plupart des gens. Ou des signets, ou des images dans le speed dial.
Moi, je préfère les raccourcis claviers, donc, CTRL+T et je tape mon URI quand je la connais. Je vais vachement plus vite comme ça qu'en devant saisir ma souris pour aller cliquer sur un fichu machin ( d'ailleurs, je rage plutôt pas mal quand les navigateurs et/ou moteurs de recherche cherchent à me dire ce que je veux/doit faire et me font perdre un temps monstrueux comme ça. Genre, une recherche sur le C++… toujours drôle. ).

C'est un peu comme la ligne de commande: c'est tellement pas pratique… sauf qu'en fait, je suis passé de la ligne de commande quand j'étais gosse aux ihm semi-graphiques ( toujours en étant gosse ). Puis par la suite aux IHM graphiques toutes jolies.
Depuis 2-3 ans, je suis repassé à la ligne de commande, vachement plus intuitive et rapide au final.

Pour les URI, c'est le même combat.

Conclusion: je ne pense pas qu'il existe un outil moins bien que l'autre. Il y a l'outil bas-niveau, plus rapide ( moins d'intermérdiaires ), mais moins accessible ( il faut savoir utiliser un clavier, et connaître des noms de commandes sites web internet—et pas web parce qu'il n'y a pas que le http auquel on peut accéder ainsi—).
Celui-la est bien pour le professionnel ou l'utilisateur avancé.

Puis il y à l'outil graphique, plus intuitifs, plus clinquant, plus joli. Ça, c'est comme les IHM, très bien quand on ne veut pas avoir besoin de se creuser la tête pour découvrir comment faire quelque chose pour la première fois.

Ceci est, bien sûr, mon avis personnel, et je ne considère pas les utilisateurs d'IHM graphiques comme des béotiens, ni les autres comme des génies, bien au contraire ( je suis plus proche du béotien que du génie, après tout ).
Ah, à moins que ce point ne méritait lui-même pas de réponse? :p

Bof, personne n'a écrit "journaliste professionnel" que je sache?

Pour moi le terme journaliste est plutôt réaliste, et si on compare avec ce qu'on peut voir dans les médias classiques, j'ai envie de dire qu'il y a régulièrement plus de recherche et de traitement de l'information sur linuxfr.

Que celui qui n'a jamais vu 2 "journaux" télévisés identiques à 90% me jette la première pierre…

On peut aussi utiliser l'analogie des logiciels. Certains codent sur leur temps libre, des choses de qualité parfois inférieure à ce qu'un pro peut faire, mais parfois de qualité supérieure. Sont-ils des programmeurs?
Pour moi oui, juste des amateurs ( pas dans le sens mauvais niveau, mais dans le sens ou ils aiment ça ) et pas des professionnels ( qui eux sont payés, pour faire de la m… ou de la qualité selon la compétence de l'employé et les désidérata de son employeur ).

Bon, bah, reste plus qu'a attendre que quelqu'un en fasse quelque chose…

Désolé, pas pu m'en empêcher, surtout que ce… truc m'a méchamment traumatisé… 10 ans après je me souviens de l'ennui qui en irradie :/

Sûrement :)

Mais je fais partie des exploiteurs qui au moins essaient de remonter les bugs, avec, quand ils sont assez doués ( les exploiteurs, pas les bugs ) des pistes pour corriger voire des patch.

Ok, merci beaucoup pour toutes ces explications, je pense que je vais consacrer un peu de mon temps à lire la doc de ce truc, c'est bien plus utile que je ne le supposais.

Que les devs soient payés n'implique pas vraiment qu'ils aient beaucoup plus de comptes à te rendre.

Pas dis le contraire. D'autant que je n'utilise pas FF et que je n'y ai fait absolument aucune contribution. C'est un peu, au final, comme utiliser un windows craqué mais en version légale.

La seule chose que j'aie tenté de dire, c'est que je les trouve trop malléable dans leurs "idéaux" du coup. Par exemple, ils utilisent GA. Admettons qu'il n'y ai pas d'exploitation frauduleuse des données par Google, parce qu'ils auraient isolé "galvaniquement" le truc.
Bon.
De mémoire, il me semble avoir lu que des membre de la MoFo, ( je ne sais plus s'ils étaient représentatifs ou pas mais il me semble que oui ) trouvaient regrettable l'abandon par opera de leur moteur de rendu maison, parce que la diversité c'est le bien. Ok. Bon, alors si la diversité c'est bien, pourquoi ils utilisent google par défaut dans le navigateur ( argent, oui, je sait… mais je pense que certains projets, à l'instar de gimp ou debian, n'ont pas besoin d'être sponsorisés par leurs concurrents pour vivre )? Pourquoi ils utilisent GA, leader je pense incontesté ( et clairement controversé ) dans ce domaine?

Voila ce que je dis, et rien de plus.

Que les dev soient payés ou pas, je m'en tamponne, tout comme je me tamponne qu'ils écoutent ou pas les râleurs sur le web. Ça, c'est le problème de la MoFo. Par contre, le fait que la MoFo dise des choses qu'elle ne pense ni ne fait, ça, vu le poids qu'ils ont sur le web, c'est un problème qui deviendra celui de tout le monde, parce que l'air de rien, ils sont le symbole grand public des idées qu'ils prétendent défendre.
C'est ce point qui me gêne.

De plus, je ne recommande Fedora 20 que comme palliatif en attendant RHEL/CentOS 7

Autrement dit, tu conseilles d'utiliser ce qui est, j'en ai bien l'impression, une version de test. Un peu comme si je conseillais aux gens d'installer Debian testing sur des serveurs de prod en somme.
Chose amusante, j'ai vu passer des thread sur la ml ou la plupart des interlocuteurs considéraient qu'il valait mieux utiliser unstable ou stable que testing sur un serveur de production. Avec un certain nombre d'arguments pertinents pour ceux qui préféraient stable et/ou unstable.

Par défaut avec Ubuntu tu installes la version desktop sur un serveur ? Non, tu prends la version serveur pour les serveurs.

Je ne sais pas, je n'ai pas installé de Ubuntu depuis… 6-7 ans, peut-être?
En tout cas, avec Debian, je ne crois pas qu'il existe une version serveur/desktop ( si c'est le cas, je ne suis pas au courant ).
Il ne s'agit que d'une option lors de l'installation ( on sélectionne les tâches que la machine sera amenée à exécuter ). Je t'avoue, je ne suis pas un grand fan de cette approche ( pour être plus précis, je trouve qu'ils n'ont pas poussé assez loin, mais bon, facile à dire sans contribuer… ), mais au moins, il suffit d'une iso pour les installer toutes.

et je n'aurais peut-être pas dû mettre cette mince remarque en premier lieu.

Sur un journal déjà très trollifère, si ce n'était pas le but de troller, c'est clair. Sinon ça à sa place :D

Ok, ça fait un peu comme nohup mais en mode interactif, si je comprend bien: détachement du processus de son lanceur?

Pour le fait que certains aillent critiquer un format ou l'autre, perso je m'en moque, je ne me permettrait pas de critiquer les deb alors que je ne connais que ça ( et les .exe, .msi, .run, mais bon, ça compte pas comme de vrais formats… quoique msi… mouai. ).
Ma question était relative au format, pas aux outils. On peut ne pas aimer les outils qui vont autour. Genre, on pourrait dire que j'aime bien HTML et HTTP, qui sont un format et un protocole, mais ce qui est clair, c'est que je n'aime à l'heure actuelle aucun navigateur qui les exploite de ceux que j'ai testés ( IE, FF, opera, midori, uzbl, et divers autres dont j'ai oublié le nom ).

En tout cas, le delta rpm à effectivement l'air très puissant, merci.

Le truc c'est que si en gros deb veut dire utiliser apt-get (ou aptitude)

Ou dselect, ou dpkg, ou synaptic, et j'en oublie sûrement.

Je ne sais pas si l'environnement autour de rpm est fragmenté ou pas, mais celui autour de deb n'est pas uniforme.