Batchyx a écrit 1261 commentaires

il crée un risque pour certains utilisateurs de la distribution (ceux qui ont désactivé la vérification des signatures GPG).

Y a vraiment des gens qui font ça ? Non parce que si ces gens existent, ils méritent de se faire pirater la gueule. Il n'y a pas besoin d'attendre que debian-multimedia soit racheté par un distributeur de malware pour réagir: Les dépots officiels Debian sont distribués en clair, n'importe qui peut faire un man in the middle et te faire installer n'importe quoi.

l'argument ne tiens pas.

Il faut voir quelles sont les expressions rationnelles que tu utilise. Sur certaines, on peut gagner pas mal en cherchant à la main. Sur d'autres, on peut optimiser le cas ou l'expression n'est pas trouvée. Sinon, il y a bien d'autres optimisations possibles sur les chaînes de caractères.

Et plusieurs liens physiques à un fichier, pour ceux qui utilisent maildir…

On va aller loin comme ça…

Ça va bien tant que tu est en face de bibliothèques en C. en C++ dès que tu utilise une classe dans ta bibliothèque, tu peux oublier dlopen().

Le but du workflow normal est que même si l'os a fermé dans ton dos une appli background que tu utilisais, l'appli est relancée et doit revenir dans l'état qu'elle était à la fermeture. Je sais bien que ça ne marche pas tout le temps, mais le but est celui-là.

C'est bien joli les principes, mais les faits sont là: ça marche pas, et même quand ça marche, c'est chiant à utiliser: Parfois j'ai envie de "laisser une appli ouverte" pour faire autre chose, parfois j'ai simplement envie de la fermer. Sauf que le système ne fait pas la différence, donc je sais pas la prochaine fois que j'ouvrirai mes SMS si je tomberai sur les derniers messages reçus ou sur le dernier message que j'ai lu. Le genre de problème que j'avais jamais sur un certain téléphone libre avec un OS ou on pouvait et devait fermer les tâches

Mais ça marche déjà en soit très bien..

Non ça marche pas. Si tu veux task-switcher entre deux applis, t'est obligé de retourner au menu principal. On se croirait sous DOS à devoir quitter une appli pour en lancer une autre. Je vois vraiment pas la peine d'avoir un OS multitâche avec une gestion intelligente de la mémoire si la seule manière de l'utiliser c'est de faire comme sur les OS mono-tâches ou comme sur les navigateurs sans onglets ni bouton précédent. Si c'est ça ta "bonne feature", moi j'appelle ça une régression par rapport à tout ce qu'on à pu faire en informatique et en interface utilisateur.

C'est pourtant pas les solutions qui manquent: Liste de tâches controllées par l'utilisateur, bureaux virtuels, gestionnaires de fenêtres pavant (je déconne, quoi-que, sur les tablettes…)…

Pour avoir utilisé un OS mobile qui n'avait qu'une croix comme moyen de fermeture d'une appli, je ne vois vraiment pas l'intérêt qu'on ferme mes applications dans mon dos et qu'on me laisse pas le faire en temps normal.

Déjà quand il n'y a pas de gestionnaire de tâches intégré, c'est une galère pour passer d'une appli à une autre. Alors si en plus l'OS choisi de virer la mauvaise appli de la mémoire, et que mon navigateur web n'est plus loggué à ce site web qui utilise des cookies de sessions et dont le mot de passe est aussi long, ça commence à bien faire. Avec un gestionnaire de tâches, c'est un poil mieux, mais tu te retrouve avec toutes les applis que tu à lancées, et même celles que t'a pas lancées, et tu à intérêt à savoir ce que tu voulais faire.

Alors que si on me laisse gérer une liste d'application ouverte, et bien il n'y aura que les applications que j'utilise qui seront ouvertes. Ensuite tu me met une flèche pour passer à l'application suivante et précédente (un équivalent d'alt-tab), et le multitâche deviens un vrai bonheur; tu ne redoute pas de faire des allées/retours entre ton carnet d'adresse et ton navigateur pour copier-coller une adresse postale vers un nouveau contact. Et au cas ou j'oublie ce que j'étais en train de faire, un coup d'œil sur la liste (très courte!) des tâches ouvertes, et je sais ou j'en suis.

Si ton script shell peut trouver des bugs avant d'appeler le débuggeur, je vois pas ou est le problème.

Le fait que memcheck puisse lancer gdb lorsqu'il détecte un problème le classe dans la catégorie des front end de débuggeurs, au moins.

Linus n'a jamais dit que ces patches étaient foireux, juste qu'ils sont bien trop spécifiques et trop chiants pour être upstream.

Franchement, on peut faire les mêmes critiques à tout les patches que les gens écrivent pour un besoin particulier sans considération pour être intégrés upstream. C'est le cas à chaque fois que des développeurs utilisent le noyau Linux pour faire autre chose qu'un noyau généraliste.

Saloperie de faits qui viennent factuellement dire que Mme Michu, qui n'est qu'un reflet statistique, veut ça.

Ce n'est pas parce que Mme Michu achête plus facilement quelque chose qu'elle le fait de manière consciente et de son plein gré.

Parce que sinon, c'est comme si tu accusait Mme Michu de préférer les produits dont on fait la publicité partout, alors que c'est précisément le rôle de la publicité de manipuler les gens.

L'option CONFIG_IKCONFIG_PROC n'est pas activée sous Debian. donc pas de /proc/config.gz.

Iceweasel afficherait une page "attention, ce site contient des pubs, si vous cliquez sur continuer, vous accéderez au contenu, mais êtes exposés à la pub".

Personnellement, ça me pose pas de problème. Aujourd'hui, il n'y a pas de moyen de savoir, simplement en regardant un lien, si le site viens avec de la pub ou non. Si je ne veux pas de pub, j'ai le choix entre toutes les bloquer ou ne visiter aucun site. Au moins, avec cette méthode, je pourrais surfer uniquement sur le web non-commercial.

Ça ne fait que restorer la sémantique d'un l'achat classique: tu me propose quelque chose en échange de publicités, mais j'ai le droit de refuser.

La seule petite amélioration que je verrais, c'est que cette page me décrive ce qu'est le site ("Youtube est une plateforme de partage de vidéo"), pour quand je tombe sur un lien vers un site que je ne connais pas.

Ce qui est chiant avec les cellules photo-voltaiques, c'est que si on les utilise bêtement, elles n'ont pas le meilleur rendement possible.

Les cellules sont des générateurs de courants, dont l'intensité du courant varie en fonction de l'éclairement. La tension limite au delà de laquelle le générateur s'éffondre (le courant baisse) augmente aussi un peu en fonction de l'éclairement.

Donc si tu le fait fonctionner à tension constante, ton courant va varier fortement, surtout si tu est autour de la tension limite pour ton éclairement. Si tu l'utilise comme un générateur de courant constant, c'est plus stable. Mais dans les deux cas, tu sous-utilise ta cellule.

Pour maximiser U×I sur un générateur à courant constant, il faut en gros se placer à la tension la plus haute avant que l'intensité ne s'éffondre de trop, donc à la tension limite. Qui varie en fonction de l'éclairement et des caractéristiques de ta cellule.

La plupart des vendeurs de cellules vendent aussi le circuit adapté à la cellule pour utiliser le meilleur régime possible et convertir ça en une tension constante utilisable.

Chez moi il me pose la question. Suffit juste de choisir la bonne priorité debconf ;)

Euh… sur tes 4 points, les deux qui ne sont pas normales me semblent être une bonne pratique. C'est un peu comme si tu disais qu'avec Java t'es obligé (je ne suis même plus sûr de savoir si c'est une obligation ou de si ça pète juste un warning) de déclarer une seules classe par fichier (sans compter les hinners classes), ça me semble être une bonne pratique.

C'est sans doute une bonne pratique en Java (on y est un peu obligé), mais en C++ c'est totalement artificiel, vu que la bibliothèque standard ne respecte pas cette convention, et heureusement. Personne ne s'amuserait à créer un fichier pour y mettre uniquement

# include <implementation_detail/binary_operator>
namespace std {
    template <typename T>
    struct less : std::__implementation_detail::binary_operator<bool, T,T> {
        bool operator()(const T& a, const T& b) const { return a < b; }
    };
}

et à faire ça 6 fois pour les opérateurs relationnels sans parler de la centaines de classes/fonctions de la bibliothèque standard qui s'implémentent en moins de dix lignes ou qui ne sont que des alias/typedef.

Non, la bonne pratique en C++ c'est d'activer son cerveau et de distinguer les grosses classes/fonctions à mettre dans un fichier séparé des petites classes/fonctions que l'on peut regrouper intelligemment dans un seul fichier si ça a un sens de les mettre ensemble. Sachant que, bien entendu, les petites classes sont préférables aux grosses (il faut mieux casser des grosses classes pour les remplacer par un typedef d'amas de petites classes templates).

Pareil pour les namespaces; La bibliothèque standard ne met pas tout ses includes dans std/. Et les namespaces de boost ne correspondent pas forcement aux répertoires dans lequel se trouvent les includes.

Enfin bref: "Apply common sense".

Pour comparer avec le C++, tu dois remplacer Toto par TotoProvider et le package 2 fois chacun (une fois pour l'entête et une fois pour le corps). Puis changer les directives d'include conditionnelle dans le corps (à 2 endroits au moins, personnellement je préfère aussi le mettre en commentaire à la suite de la fin du if). Pareil je parle pour une classe qui n'est pas utilisée.

C'est certes plus de boulot, mais toutes ces opérations impliquent uniquement d'utiliser son éditeur de texte. C'est beaucoup plus confortable que de devoir créer un répertoire et y déplacer ses fichiers.

Et tu te retrouve avec un dossier src qui contient en vrac différents namespace.

Mauvaise idée, vaut mieux faire le contraire: les namespaces en C++ ne servent pas à catégoriser les classes ou a limiter leur visibilité comme en Java, mais uniquement à éviter les conflits de noms. Utiliser un ou deux namespaces par projet est suffisant (exemple: la bibliothèque standard, encore une fois…), il n'y a pas de raison d'en avoir plus si tu ne compte pas avoir de conflits de noms (les principaux types de conflits étant ceux liés à la recherche dépendant des paramètres). Et même lorsque tu à besoin d'un namespace, tu peux toujours le planquer en utilisant un typedef ou autre.

Absolument rien ne t'empêche de simplement séparer tes fichiers dans des répertoires différents en gardant le même namespace.

Les imports à « grains fin » (tu peut utiliser des wildcard, mais je n'aime pas)

Le compilo non plus, ça augmente ses temps de compilations, mais pas autant qu'une compilation C++.

permettent de voir ce qui est utilisé ou non dans la classe. Là encore à comparer au C++, il va falloir ajouter des includes qui vont bien, les modifier ou pas va dépendre de comment tu organise tes classes.

Si tu sépare des classes intelligemment, tu n'a pas plus de problème qu'avec des wilcards en Java. Parce que les imports à grain fin, en plus de rentre inintelligible la liste de ce que tu utilise, t'oblige à la maintenir avec un IDE. Une liste d'include est plus courte et mieux catégorisée.

Tu entends quoi par là ? La javadoc, me paraît tout à fait lisible (et immédiatement à jour par rapport à cppreference ou cplusplus ()j'apprécie beaucoup ces 2 sites là n'est pas la question) qui sont moins à jour et qui, dans le cas de cppreference, se contente de décrire l'API (Java à ce genre de choses). Après je trouve qu'il mange des chose, j'aimerais bien avoir dans la javadoc la complexité de certaines fonctions et indiquer de manière systématique si une méthode est thread-safe ou non.

Gahh, des frames, en 2013. Passons, j'ai pris une classe au hasard: AbstractQueue: http://docs.oracle.com/javase/7/docs/api/java/util/AbstractQueue.html

J'ai :
- de l'information bateau qui m'intéresse pas forcement (savoir de quoi ça hérite, qui l'implémente …) mais qui se trouve au début, donc c'est ce qui s'affichera en premier dans une petite fenêtre
- La doc (normal)
- Les constructeurs/méthodes de la classe avec leur description courtes (normal)
- Un trop bref résumés des méthodes héritées des classes mères, alors que pourtant, elles font partie de l'API.
- Le détail des méthodes, qui prend une place absolument folle.

La plupart des programmeurs Java que je vois préfèrent naviguer dans les méthodes et leur documentations dans leur IDE (ou son autocompléteur de code) que regarder la javadoc. Il y a peut-être une raison. Bizarrement, les IDE ne planquent pas les méthodes héritées, et n'affichent les hiérarchies de classe que dans la doc.

Excuse-moi de revenir à C++, mais c'est le langage le plus proche que je connaisse. Peut être que Objective-C ou un autre langage fait mieux.

Je fais du C++ avec vim. Et j'ai pas absolument besoin de ses fonctionnalités d'IDE les plus avancées (elles ne font qu'augmenter ma productivité). Des windowsiens utilisent des éditeurs plus pauvres comme notepad++ pour des petits projets C/C++, et ça ne semble pas les gêner pas tant que ça.

Mais en Java, je n'ai jamais vu quelqu'un utiliser un IDE moins lourd que netbeans ou eclipse, même pour des petits projets de 3 classes. C'est juste impossible de programmer sans.

Quiconque ayant déjà renommé une classe Java et changé son namespace package à la main te dira que c'est Java qui nécessite un IDE et non le contraire.

(je parle pas de changer le code des utilisateurs de la classe hein, juste de changer le nom et le package d'une classe).

Pour information, pour ceux qui ne pratiquent pas java, voilà ce que le langage impose de faire si je veux renommer une classe Toto (pas encore utilisée) dans le namespace par défaut en com.bloat.providers.TotoProvider:

• Remplacer Toto par TotoProvider dans le fichier (normal).
• Rajouter package com.bloat.providers; (normal).
• Créer le répertoire com/bloat/providers (mkdir -p est ton ami, avec une GUI tu crève).
• Déplacer Toto.java dans com/bloat/providers, et le renommer en TotoProvider.java, en pensant au gestionnaire de version.

Autrement dit, tu va retaper Toto deux fois, com.bloat.providers au moins trois fois et TotoProvider deux fois, et t'a pas intérêt à faire une typo quelque part, sinon ça va être coton à savoir ou.

Enfin bref, c'est super chiant, et tu ne fera jamais ça plus d'une fois dans la journée.
Java à besoin d'un IDE pour renommer une classe, même si elle n'est pas utilisée.

Après on peut parler des ìmport à grain trop fin, de la javadoc illisible par défaut, ou des bibliothèques bloats qui sont inutilisables sans autocompléteur/générateur de code.

Il existe aussi des cas ou les débuggeurs n'existent pas ou n'ont pas d'équivalent faciles à mettre en place.

iptables -t nat -A OUTPUT -p tcp --dport 40000 -j REDIRECT

optionnellement avec l'option --to-ports pour rediriger vers un port local différent de 40000 (ça sert si ton numéro de port est inférieur à 1024).

De loin, ça à l'air d'être une bonne idée. Sauf que ip évolue bien plus lentement que iw, parce que globalement, si IPv4/IPv6 n'a pas trop changé en 10 ans, Wi-Fi à juste eu trois révision complète de la norme, sans parler du nombre d'amendements.

Et surtout, en pratique, les mainteneurs de iw et de la couche Wi-Fi du noyau préfèrent refourger toutes les responsabilités précédemment dans le noyau à wpasupplicant, et du coup, décourager l'utilisation simple d'iw, puisque le noyau seul n'a pas toutes les fonctionnalités de wpasupplicant.

Parce que tes outils sont déjà cassés dès que tu essaye de les utiliser pour des configurations un tant soit peu avancées. Et que les couches de compatibilitées sont tellement grosses qu'elles sont obligées de mentir, surtout pour iwconfig (notamment sa qualité de signal…), mais ifconfig et route ne sont pas épargnés dès que l'on met plusieurs adresses par interfaces, ce qui est normal en IPv6…

Franchement, on ne peut plus faire confiance a la sortie de ces outils : ils ne montrent pas toutes les informations, ils mentent et leur utilisations peuvent péter une conf réseau qui aurait marché avec ip/iw/netlink, a cause de ces petites options qui font la différence entre un réseau qui marche et un réseau qui marche pas.

Tes outils sont cassés et tu ne t'en est pas encore rendu compte.

NetworkManager s'adapte à toutes les situations, du simple utilisateurs de base qui veut se connecter de partout à l'alpha-geek qui souhaite une configuration IPv6 poussée

Est-ce que NM supporte enfin l'autodétection ARP a la guessnet ? Parce que sinon, ça reste très moyen pour l'alphageek que je suis…

Plus de 150 personnes utilisent encore iwconfig/ifconfig, alors que les deux sont carrément obsolète sous linux, surtout le premier.

Certes, ce choix inclus peut-être des utilisateurs de BSD qui n'ont pas vu que iwconfig n'existait pas sur leur système, mais quand même. Les utilisateurs de Linux devraient apprendre à se servir d'ip et iw à la place.

Il est (presque) interdit de vendre un produit avec du plomb en Europe, depuis les directives RoHS.

Indice: c'est pas à Paris.

Tu dois dezipper un fichier de 1gb, tu preferes quoi:

Un processus à part, avec qui tu communique, et sur lequel tu à bien plus de contrôle que sur un thread. Tu peut définir plus finement sa priorité, ce que tu partage avec lui, et, point bonus, si jamais ton imbécile d'utilisateur idiot change d'avis, tu peux tuer ton processus et l'oublier, pas comme avec les threads ou tu est obligé de faire des hacks foireux.