Damien Thébault a écrit 337 commentaires

À première vue, ça semble surtout changer la définition des classes, le reste restant en javascript classique.

C'est plutôt intéressant à mon avis, car effectivement la définition de classes en javascript n'est pas très jolie. De plus ça permet à un IDE de détecter les classes et donc de simplifier l'écriture de code (complétion, etc.).

Ah ok.

Donc le seul truc que ça m'apporte c'est d'avoir les données du jeu, donc ça peut être pratique dans certains cas, mais si on a déjà le CD y'a pas vraiment de valeur ajoutée.

Merci pour l'explication

Non en fait dans la plupart des routeurs des FAI, y'a les 2 couches en plus (PPPoE et RFC2684) parce que ça permet d'avoir des équipements plus simples au niveau du FAI.

En effet, au lieu d'avoir du PPP over ATM qui doit se gérer dans les DSLAM et qui ne peut pas être forwardé, c'set du PPP over Ethernet over RFC2684 over ATM, et donc sont des DSLAM sans PPP, qui forwardent les paquets PPP à des serveurs chez le FAI, ce qui lui permet de gérer de manière beaucoup plus simple les serveurs PPP, et d'utiliser du matériel standard Ethernet pour tout ça.

Donc plus de souplesse, moins cher. Ça rajoute quelques couches mais pour les FAI ça vaut largement le coût.

Je me posais notamment la question pour Total Annihilation, ce n'est pas un moteur de jeu commun et il tournait sur Windows (95).
Donc à part Wine je vois pas trop, et j'appellerait pas vraiment ça "natif".

En fait, en PPPoE, la configuration exacte finale pour faire de l'internet (IP) c'est : IP over PPP over Ethernet over RFC2684 over ATM over ADSL.
En IPoE, la configuration c'est IP over Ethernet over RFC2684 over ATM over ADSL.

Ça fait gagner à vue de nez 22 octets par paquet IP.

Le nouvel OS c'est peut-être Windows 8.

Au passage, j'ai pas compris qu'est-ce qu'il y avait de natif linux dans la liste, ni comment ça fonctionnait, c'est très flou.

Le problème à mon avis, c'est que pour accéder aux fichiers qui sont affichés sur le bureau, on doit déplacer ou réduire les fenêtres.
Typiquement, si on a plus d'une fenêtre, c'est rapidement pénible.

Du coup, on demande d'avoir un bouton spécial qui réduit toutes les fenêtres quand on appuie dessus et qui rétablit les fenêtres quand on appuie à nouveau.

Cepandant, si on utilise le bouton la première fois mais qu'on manipule les fenêtres réduites directement au lieu de tout restaurer, la situation devient assez perturbante.

À mon avis, le plus simple, plutôt que d'avoir un bouton pour afficher le bureau qui réduit les fenêtres, ça serait plutôt d'avoir un bouton qui affiche un overlay ou un mouvement 3D avec le contenu du bureau et un petit fond gris foncé à 80/90% d'alpha (avec une petite animation en prime).

Cet état permettrait de faire des clics gauche/droit, et de réorganiser les icônes, mais pas de faire de drag&drop vers un logiciel ou un dossier. On aurait par contre un bouton pour ouvrir le dossier dans un explorateur de fichiers classique, et l'icône permettrait également d'ouvrir un explorateur de fichiers à l'aide d'un clic droit.

Lorsque le bureau est vide (aucune application lancée, ou bien toutes les applications réduites, ou bien aucune application affichée sur l'écran en question en cas de multi-screen), on pourrait alors afficher l'overlay, mais celui-ci disparaîtrait dès qu'une application se lance.

Vu ce qu'ils ont fait avec l'iPad 3 (Nouvel iPad), à mon avis ils vont appeler l'iPhone 5 "Nouvel iPhone".

Il me semble que l'obligation est de fournir un chargeur micro-USB.

Moi ce que je vois comme avantage, c'est que tous les chargeurs seront micro-USB, donc je pourrais demander à n'importe qui de me prêter son chargeur si j'ai oublié le mien.
Le fait que les utilisateurs d'iPhone soient obligés de se trimballer tout le temps avec un adaptateur sur eux pour pouvoir faire la même chose ne me dérange pas le moins du monde. Ça les dérange eux, mais pas moi.

Du coup la décision de l'UE me semble bonne, elle améliore la vie de tous les gens qui n'ont pas d'iPhone et ne change fondamentalement pas la donne pour ceux qui en ont.

Bien vu ! Au temps pour moi, on peut donc bien recevoir NULL même sous GNU/Linux grâce à l'overcommit.

À vrai dire, sous linux par défaut, malloc() et realloc() ne retournent finalement jamais NULL. Ce qu'il se passe plutôt, c'est qu'on reçoit toujours un pointeur, et c'est au moment où on se met à l'utiliser qu'il alloue réellement la mémoire.

Si au moment où on utilise la mémoire, celle-ci n'est pas disponible parce que la mémoire est pleine, alors le OOM-killer rentre en jeu et va tuer un process (que ça soit le process lui-même ou un autre).

Cette technique de lazy allocation permet notamment d'allouer plus de mémoire que ce qui est disponible physiquement (tant que toute cette mémoire allouée n'est pas utilisée). Ce comportement peut être modifié par des paramètres overcommit dans /sys/.

Cependant, même avec l'overcommit totalement désactivé, le noyau linux continuera à renvoyer un pointeur non-NULL, même quand il n'y a plus de mémoire disponible, et OOM-killer sera appelé comme d'habitude quand la mémoire sera accédée.

Au final sous linux il y a à priori une seule façon d'avoir ces fonctions qui retournent NULL, c'est en cas de fragmentation trop importante de l'espace d'adressage du processus qui rendrait impossible une allocation de la taille souhaitée, et c'est vraiment très très rare.

Voilà la raison pour laquelle vérifier le retour de malloc() et realloc() est en général assez peu utile, et pourquoi realloc() est assez souvent non testé pour NULL (les développeurs testent en général quand même avec malloc() car c'est plus facile à faire que avec realloc()).

Je préfère personellement quand même tester la valeur de retour quand même, ça permet d'être tranquille en cas de portage sur un autre unix, ça diminue les retours de logiciels d'analyse statique tel que clang et ça évite les questions en cas de revue de code.

Je trouve que systemd apporte au contraire beaucoup de fonctionnalités supportées nulle part ailleurs. Pour moi les deux fonctionnalités suivantes sont vraiment les plus importantes :

• Activation à partir des socket : quand on démarre un service, si on a besoin d'un autre composant à travers une socket, alors systemd va intercepter cet appel et va retarder sa connection jusqu'au moment où l'autre composant en question est capable de la traiter (c'est à dire que la connection du composant est configurée). Ça permet de démarrer tous les process en même temps et de les faire communiquer le plus tôt possible. Par exemple, plutôt que de lancer dbus, puis lancer NetworkMonitor, on lance les deux en même temps et on gagne du temps (par exemple on résoud les bibliothèque en parallèle pour les deux programmes).
• Gestion des cgroups automatiquement : lorsque l'on démarre un service (par exemple apache), celui-ci est démarré dans un cgroup distinct. Lorsque l'on va arrêter ce service, on va tuer tous les process du cgroup. L'intérêt principal, c'est qu'un serveur qui lancerait plusieurs process en tâche de font va être correctement terminé ainsi que tous les autres process qui y sont liés. Plutôt que de devoir gérer les pids d'une manière toujours différente d'un programme à l'autre, ici c'est générique quel que soit le programme à gérer.

Une liste plus longue est disponible ici : http://0pointer.de/blog/projects/why.html
Elle est à mon avis sujette à interprétation mais ça donne à mon avis quelques points à investiguer.

evdev est une interface linux kernel <-> user-space pour les périphériques d'entrée, ainsi que le nom du module kernel qui gère la fonctionnalité, ainsi que le nom d'un module Xorg qui gère la fonctionnalité.

En ce qui concerne la partie linux (module + interface + création du device dans /dev/), evdev n'a besoin de rien. On peut très bien utiliser devtmpfs, mdev ou mknod pour créer les fichiers dans /dev/.

En ce qui concerne la partie Xorg, on peut le configurer dans /etc/X11/xorg.conf, dans une Section "InputDevice" avec Driver "evdev".
Il y a un paramètre "Device" qui permet de renseigner le chemin du device evdev.

En plus de ça, si on veut se passer du xorg.conf, on peut utiliser l'autodétection qui utilisera alors udev depuis Xorg 1.8. Cette autodétection est désactivable si besoin.

Autant utiliser les drivers kbd et mouse est effectivement à éviter, evdev étant supérieur en tous points, autant on peut se passer de udev si on veut.

Je me base sur le fait que :

• systemd est de plus en plus utilisé sur les grosses distributions linux, et puisque l'écosystème évolue quand même assez vite sous linux, dans quelques mois le support sysv pour différents projets pourra très bien être moins réactif que systemd (À savoir si il y a une modification qui pose problème dans le script d'init, ça sera plus rapidement vu avec systemd qu'avec sysv, surtout si c'est un cas peu courant)
• sysv, utilisé sur les différentes distributions linux, est surtout impacté par les scripts associés. Il suffit de comparer les init debian et gentoo, toutes les deux basées sur sysvinit. Ce qui me fait dire par exemple qu'un script sysv gentoo est installé sur beaucoup moins de machines que le script systemd équivalent.

J'avais installé un init systemd minimal sur un système ARM et ça démarrait rapidement mais vu le peu de services lancés c'est un peu normal et j'ai pas vraiment regardé plus loin sur la consommation mémoire ou quoi (en même temps faut voir ce qu'on appelle "petite machine", c'était quand même un CortexA9 1GHz dual core avec 1Go de RAM).

Sinon il me semble que dbus est une dépendance de systemd parce que Lennart propose un set de fonctionnalité fixé, mais rien ne semble vraiment en dépendre (pas systemctl par exemple), donc à mon avis un petit patch devrait permettre de désactiver facilement dbus.

À vrai dire, sur un serveur à moitié embarqué j'aurais tendance à utiliser un système largement utilisé afin d'éviter au maximum des problèmes.

Si je résume, systemd c'est au final plus de fonctionnalités, moins de bugs, plus rapide. C'est quoi l'intérêt de garder un sysv à l'ancienne qui est lent et moins testé?

Personnellement je ne l'utilise pas encore parce que je ne veux pas casser mes systèmes, mais je l'activerais sûrement lors d'une nouvelle installation sur une distribution qui le supporte.

J'utilise cityssimo, mais les conditions d'utilisation sont un poil trop strictes. Ça ne fonctionne que avec des colissimos envoyés depuis la france.

Du coup il faut faire bien attention sur ce qu'utilise l'expéditeur, si ce n'est pas spécifié noir sur blanc il vaut mieux passer par l'adresse du domicile.

En fait je paierais volontier pour l'équivalent universel, qui réceptionnerait les colis de n'importe quel source.
(Oui on me signale qu'un concierge fait ça en partie, mais y'a quand même plus pratique, et puis le concierge je crois pas qu'il refuse les colis si ils sont abimés.)

Le C++ permet d'utiliser des templates, qui sont résolues à la compilation.

Pour de l'embarqué à ce niveau il faut faire un tout petit peut attention à la taille que rajoute le C++, en général il suffit de désactiver le RTTI et tout roule !

Les templates permettent de faire des horreurs, mais ça permet aussi de faire de très bonnes choses. Ça demande une conception assez différente d'une programmation classique et doit donc en général être imaginée dès le départ.

Ils ont déjà fait beaucoup de ménage dans le code de OpenOffice, et franchement LibreOffice est beaucoup plus agréable à utiliser que OpenOffice ne l'a jamais été.

Du coup je dirais plutôt qu'ils continuent dans cette direction, car tout reprendre de zéro serait un travail énorme.
Il suffit de regarder Calligra/Koffice/AbiWord pour se dire que LibreOffice est quand même un bon truc, alors oui y'a moyen de repartir de zéro, mais ça ferait perdre pas mal de fonctionnalités.

Je pense quand même que quand on écrit un fichier dans un certain format, celui-ci devrait être respecté. Si il ne l'est pas, c'est qu'on utilise (dans notre cas) des balises invalides ou que la syntaxe n'est pas bonne.

Si LibreOffice génère des documents avec un format non-conforme, cela devrait être corrigé. Peut importe si le document original est bon ou mauvais.
Pour moi, un format de document c'est juste une interface, et comme n'importe quelle interface ou protocole, le contrat se doit d'être respecté.

(De la même manière, ce n'est pas parce qu'on est en train de communiquer en WiFi avec un point d'accès buggé qu'on a le droit d'envoyer des trames ethernet buggées vers le switch)

Cependant, c'est un point qui est correctement traîté du côté de libreoffice, et si des bugs sont trouvés, il faut créer des entrées bugzilla comme cela a déjà été fait plusieurs fois :

• https://bugs.freedesktop.org/show_bug.cgi?id=37390
• https://bugs.freedesktop.org/show_bug.cgi?id=49618
• https://bugs.freedesktop.org/show_bug.cgi?id=45447

Le dernier bug est particulièrement intéressant puisqu'il montre un cas où le fait de charger un .docx et de tout de suite l'enregistrer provoque une sortie invalide.
(Mais ce comportement n'est pas un comportement normal et aucun développeur de LibreOffice ne nie que c'est un bug)

J'ai fait une recherche rapidement sur la définition de "sexe par surprise" en Suède, et à priori c'est un terme utilisé pour nier ou plaisanter en parlant d'un viol.

La réalité ça serait qu'il est accusé de "contrainte sexuelle" (« tvang » en suédois), d'agression sexuelle et de viol.

Perso j'utilise juste la barre d'url de chromium:

1. Ctrl+L
2. Entrer la recherche (accessoirement ça affiche aussi les suggestions de recherche)
3. Valider avec la touche "Enter"
4. Profit !

Sous firefox c'est pareil (sauf qu'il y a 2 barres séparées au lieu d'une seule, mais c'est une autre histoire), donc il suffit d'utiliser Ctrl+K à la place de Ctrl+L.

Effectivement je n'avais pas vu les infobulles.
Je n'ai rien contre linuxfr en soi, c'est juste le titre des liens de cette dépèche, je n'avais précédemment pas été confronté à ce problème.

Je ne critique pas du tout l'effort de tout le monde sur linuxfr et j'apprécie les articles de qualité qui sont écrits par l'ensemble de la communauté ici.

Je rebondissais juste sur le commentaire original qui n'avait, comme moi, pas fait le rapprochement entre le texte du message qui mentionnait « le site bons-constructeurs-ordinateurs.info » et le lien intitulé « Liste des bons et mauvais constructeurs d'ordinateur personnel et matériel informatique » qui ne semblaient totalement pas apparentés.

Mon but était juste d'essayer d'améliorer les choses, je suis désolé de ne pas faire aveuglément confiance à linuxfr ; bien que je le considère comme un site de qualité, j'applique quand même par automatisme les mêmes principe de précaution que sur tous les autres sites. (Idem sur le site de ma banque avec certificat validé ou n'importe quel autre site).
Je n'ai pas forcément le temps de regarder le code source de tous les sites sur internet, mais je fais totalement confiance à linuxfr en ce qui concerne les actions qui sont effectuées.

Le problème ici est simplement un problème de perte de temps, dans le cas actuel mes options sont:

• cliquer sur un lien qui semble plus ou moins correspondre au site mentionné précédemment, pour potentiellement m'apercevoir que ça ne correspond pas, revenir sur la page précédente, recopier l'adresse du site à la main et aller dessus.
• survoler le lien pour vérifier à l'avance que c'est le bon site (maintenant que je sais que cette fonctionnalité est disponible), ça oblige à pointer la souris sur le lien sans bouger et attendre l'apparition de l'infobulle, ce qui n'est pas très pratique (l'information donnée par le browser en bas à gauche de la fenêtre est beaucoup plus immédiate)
• sélectionner l'adresse du site dans le texte, faire bouton droit, "go to". Ce qui est au final la solution la plus simple, rapide et sûre.

Certains sites (page de recherche de google par exemple) ont un lien href normal afin d'avoir l'affichage correct de l'url dans le navigateur, et font un remplacement en javascript pour rediriger vers la page de redirection lors du clic. D'après ce que je vois, ça serait l'équivalent à ce qui est fait sur linuxfr actuellement, mais en replaçant le lien uniquement lors du clic.

C'est plus simple pour l'utilisateur puisque l'affichage de l'adresse de la page de destination est fait instantanément au survol et homogène pour par rapport à tous les autres sites web. Les contributeurs pourraient alors utiliser n'importe quel titre qui leur plairait sans perturber les lecteurs paranoïaques pressés.

Sinon, un rappel du de l'adresse mentionnée dans le texte dans le titre du lien aurait été suffisant pour faire la relation entre les deux. Ici on lit le texte qui parle de « bons-constructeurs-ordinateurs.info » et on ne le trouve pas facilement dans la liste des liens, par exemple :

• « bons-constructeurs-ordinateurs.info : liste des bons et mauvais constructeurs d'ordinateur personnel et matériel informatique »
• « Liste des bons et mauvais constructeurs d'ordinateur personnel et matériel informatique (bons-constructeurs-ordinateurs.info) »

Y'a des concepts intéressants, mais les pages wikipedia elle-mêmes ont un header énorme qui me semble vraiment pas pratique.

Pourquoi les gens vont sur wikipedia la majorité du temps? Pour lire.

Leur maquette comporte un header qui prend entre la moitié et le tiers de la page lors d'une lecture normale, ce qui est vraiment trop.
L'espace vertical hors contenu devrait être minimisé, pour laisser plus de place au contenu, surtout quand les écrans actuels sont beaucoup plus larges que haut (16/9). Sur ce point là, leur concept est assez mauvais.

Je trouve également que leur style minimaliste nuit un peu à la structuration des pages "portail" et ne permet pas au lecteur de facilement distinguer les différents blocs de contenu.

À vrai dire, la redirection de linuxfr combinée au texte du lien fait qu'on a aucune idée si c'est le bon lien ou pas.

Les internautes confirmés ont l'habitude de ne pas cliquer sur ce type de lien histoire d'éviter de tomber sur des pages de pub quelconque ou autre, du coup je préfère largement copier/coller une URL que de cliquer sur le lien.
(Au passage avec chromium il suffit de sélectionner le texte et de faire bouton droit -> go to)
Alors oui ça pourrit les stats, mais c'est de bonne guerre.

En même temps… What else?