galactikboulay a écrit 620 commentaires

Il faut bien garder une chose à l'esprit, c'est que la perfection n'est pas de ce monde, et surtout pas en programmation /o\

Perso, pour un projet assez complexe, j'essaie d'arriver à quelque chose de globalement fonctionnel rapidement, quitte à ce qu'il y ait des parties écrites à l'arrache au début (en s'arrangeant toutefois pour que l'interfaçage avec le reste soit propre). Une fois que l'ensemble est fonctionnel et que tous les concepts sont validés, je réécris les morceaux sales. C'est plus motivant pour moi dans la mesure où j'ai qqch à montrer.

C'est très difficile de manière générale de partir sur quelque chose de "parfait" (en termes de structures de données, d'algorithmes, ...). Il y aura toujours un point de détail qui ne satisfera pas à un moment donné. Il faut essayer ne pas se focaliser dessus, sachant que rien ne t'empêche d'y revenir plus tard.

Déjà testé, ça marche pas tellement. Au lieu de te demander quand est-ce que ça va sortir, on te demande quand est-ce que ce sera prêt.

C'est simple, si tu recois régulierement des emails te demandant telle ou telle feature, tu auras envie de les implémenter.

Oui, enfin ça, ça dépend aussi de comment c'est demandé. Je travaille sur un projet où on me demande d'implémenter une feature particulière (qui serait extrêmement utile, tout le monde s'accorde là-dessus), mais qui prend des mois à développer. Quand on te saoûle toutes les semaines du style "alors ça en est où ?" (sous-entendu bouge toi le c.l faignasse) et que tu as très peu de monde qui participe (voire pas du tout pour ceux qui te réclament la feature en question), c'est pas très motivant non plus...

Ne pas regarder de film avec Tom Cruise ? /o\

C'est ce que je me suis dit au départ aussi, mais le problème est que tu peux verrouiller la désactivation du mode VT, et du coup ce n'est plus réactivable par la suite.

Oui effectivement, j'aurais du tout lire. En fait, une fois un bit de verrouillage positionné, il n'est pas possible de réactiver le VT. Tu parles d'une feature...

Les instructions x86 pour faire ça sont rdmsr/wrmsr, qui ne font que 2 octets, donc pour les retrouver il faut chercher, mais ça doit pouvoir se faire. Après, j'ai peur qu'il y ait une somme de contrôle quelquepart qui empêche l'outil de flashage de flasher n'importe quoi.

Ce n'est pas possible de patcher le noyau et de forcer cette activation à travers les registres MSR ? Parce que je ne vois pas tellement comment HP pourrait faire pour brider matériellement le processeur par rapport à ça.

Et puis à 150 contre 2, franchement c'était équilibré, ça ne risquait pas de finir en lynchage, non pas du tout.

Avoir accès à la Freebox permettrait par exemple:

- Pour pouvoir programmer ses propres règles iptables
- Monter des tunnels VPN ou IPv6
- Mettre des règles de QoS particulières
- Utiliser l'USB pour mettre un disque externe (pour faire serveur de fichier) ou un dongle Wifi (quand on a pas eu la bonne idée de prendre la carte Wifi proposée par Free ;) ...)

Certes, tout cela est faisable avec un autre équipement derrière mais bon tout le monde n'en a pas forcément à dispo et n'a pas envie de laisser un PC allumé (bruit, consommation électrique, etc.)

On peut aussi utiliser une autre marque de routeur ADSL, le problème c'est qu'on perd la téléphonie et la télévision.

Ah parce que Broadcom et Sigma Designs (*) font des noyaux Linux ? Première nouvelle.

* Broadcom et Sigma Designs sont chacun d'eux de graaaands contributeurs au libre. Pour ceux qui ne s'intéressent pas trop au hardware, sachez que Broadcom ne fournit quasiment aucun datasheet, que ce soient pour des chips Ethernet, Wifi, xDSL ou ce que vous voulez.

Faudrait voir à arrêter la fumette: la PS3 sera basée sur un processeur Cell, c'est à dire un coeur PowerPC avec des DSPs à côté. Ce n'est donc pas du tout du x86. Ensuite, en terme de hardware graphique, c'est certainement différent des cartes vidéos présentes sur PC, et quoi qu'il en soit, les modules pour la gestion "jeu" (son, dessin 2D/3D, etc.) ne seront sans doute disponibles que sur cette plateforme sous forme propriétaire.

Dans l'absolu, les modules binaires uniquement ne devraient même pas exister, dans la mesure où ces modules sont chargés dans l'espace d'adressage du noyau (cf http://www.gnu.org/licenses/gpl-faq.html#MereAggregation). De plus, la compilation des modules requiert nécessairement l'utilisation des headers du noyau, et il me semble avoir lu que Linus Torvalds spécifiait clairement que l'utilisation de ces headers implique une distribution en GPL.

OK je vois que tu t'es posé la même question que moi en voyant cette mention, parce que je crois que chez Netgear ces headers y sont aussi. J'ai vu d'autres firmwares où ils n'y étaient pas (ou du moins des versions extrêmement réduites).

Enfin, en tout cas, vu cette politique débile (même pas de specs ou de code pour la partie Ethernet), dès que je peux éviter d'acheter du Broadcom je le fais. Et c'est aussi ce que je conseille à mon entourage quand on me demande un avis.

Où est-ce que tu vois les sources des drivers Broadcom ? J'ai téléchargé l'archive, il y a certes des fichiers d'include et les fameux modules objets en ".o", mais des sources en C j'ai pas vu. J'ai des gros doutes sur le fait que ces sources soient distribuées sachant que chez Broadcom ce sont des gros maniaques du NDA.

Un peu trop facile, le 1er lien sur Google en faisant un copier/coller de ta phrase.

http://www.euractiv.com/fr/elections/segolene-royal-revele-v(...)

Pour le reste il y a Eurocard Mastercard /o\

allez hop -->[]

Hum je crois que nous avons affaire à un serial killer.

Et est-ce qu'il a un tatouage sur tout le torse façon Michael Scofield ?

->[]

Les cours de programmation système se font sur des machines Linux (avant c'était du Solaris). Le prof de système préfèrera s'arracher les testicules que de parler de Windows ou de proposer des TPs sur cette plateforme.

En cours de réseau "avancé": mise en place de serveurs DHCP (ISC), DNS (BIND), routage (Zebra/Quagga), filtrage avec iptables, analyse de trames avec Ethereal. Tout ça sur de la Fedora ou de la Debian (suivant le chargé de TP). Très orienté MS tout ça....

Le plus simple et le plus pertinent à mon avis, c'est :

1. de boycotter, la publicité n'a rien à faire dans une université, surtout quand c'est une entreprise condamnée pour abus de position dominante qui vient fourguer sa camelote (et je reste poli). On se demande en quoi venir parler de la Xbox-360 est pertinente dans une école d'ingé.

2. de distribuer des tracts comme l'a fait Attac-UTC (apparemment ce dont parle l'auteur du journal) pour contrer ces dérives honteuses.

Je propose "cacamoo", et je sors par la même occasion /o\

1) Restons sérieux 2 minutes, tu ne peux décemment pas comparer les possibilités du shell unix avec des outils style grep/sed/awk/... et cette fonction de recherche ;)

2) De soft qui a des problèmes ou de soft malicieux. Ce que je veux dire, c'est que des modifs dans la base de registres sont à mon sens plus difficile à traquer que sur des fichiers textes dans un système de fichier.

3) Je trouve ça gênant de ne pas avoir de timestamp (je voulais en parler dans le post précédent et j'ai zappé). Savoir quand ton named.conf ou autre a été modifié pour la dernière fois est quand même bien pratique. Si on continue sur l'exemple du DNS, dans le cas d'un programme malicieux, tu peux tout de suite voir facilement si ton named.conf a bougé et comment. Sous Windows, si t'as une clé de registre rajoutée/modifiée/supprimée en douce, c'est moins évident je pense.

4) ah ça je connaissais pas, merci pour l'info.

5) Autre inconvénient que je vois à la base de registres: le fait que tout soit centralisé rend moins facile l'extraction des infos de configuration pour les recopier sur une autre machine. Copier un named.conf, un smb.conf ... c'est un peu plus simple que d'aller extraire les clés.

Par contre, pouvoir importer des fichiers .reg c'est pas mal.

1) Si j'ai besoin de rechercher quelquechose, à coup de "grep" et/ou de "find" dans /etc, je finis par le retrouver. Avoue que sous Windows, naviguer dans la base de registres n'est pas aussi trivial que se balader dans un système de fichiers!

2) Si le soft est bien foutu, il se créée dans le home directory un ".truc", et dans ce cas là, rien de plus simple que shooter le répertoire.

Si c'est un fichier de conf global au système, c'est souvent dans /etc ou /usr/local/etc. C'est assez simple de retrouver les derniers fichiers créés/modifiés.

Si vraiment tu retrouves pas, un coup de strace pour repérer les fichiers accédés et le tour est joué.

Entre une base de registres qui contient des clés avec des identifiants 128 bits absolument pas parlants, et où il est difficile de savoir facilement ce qui a été modifié / rajouté, et des fichiers textes avec certes plein de formats différents mais modifiables avec n'importe quel éditeur de texte, mon choix est vite fait.

Exemple: si je te demande d'aller chercher les infos IP d'une carte réseau précise dans la base de registres, tu trouves ça facile ? J'ai fait ça régulièrement pour aller changer la MTU, à chaque fois je suis obligé de faire une recherche sur le net (surtout qu'en plus c'est pas forcément au même endroit suivant les version de windows) pour retrouver où c'est planqué dans l'arborescence.

Autre exemple: j'ai eu le cas d'un soft qui foirait de temps en temps son installation, mais avait le temps de rajouter pleins de clés. Tu relances l'install, il te dit qu'il est installé. T'essaies de le désinstaller, il ne veut pas (c'est un soft hautement daubique, mais c'est pas vraiment le sujet). Challenge: virer toutes les clés qu'il a pu ajouter.

Disons que le fait d'avoir un certain nombre de ports ouverts par défaut sous Windows (au hasard, le 135/tcp) - dont le rôle n'est pas forcément clair pour le quidam moyen - offre fatalement plus de possibilités qu'une machine où quasiment aucun service n'est dispo par défaut. Certes en ce qui concerne blaster, sasser and co, les correctifs étaient dispo avant me semble-t'il, encore faut-il faire les updates (responsabilité de l'utilisateur, on est bien d'accord).

Sinon pour m'être fait "rootkiter" une machine Windows, j'ai l'impression que tout ce qui est "hooking" des APIs permet de dissimuler plus facilement les activités suspectes. Le rootkit planquait des ports TCP, des fichiers (*), des processes, des clés de registre bref la totale. Ce n'est peut-être qu'une impression, mais sous un Unix j'ai le sentiment que faire un truc de ce style portable et qui marche à tout les coups c'est un peu plus le bordel.

(*) Le nommage des fichiers système Windows est quand même à revoir, tu avoueras qu'il n'est pas facile comme ça de deviner à quoi sert tel ou tel fichier (genre "lsass.sys", c'est quand même pas très parlant). Si au pire j'ai un doute, sur une Debian "dpkg -S <...>" ou sur une Redhat un coup de "rpm -qf <...>" renseignent bien sur le package qui est "propriétaire" du fichier.

De manière générale et IMHO, le shell pourri, le manque d'outils par défaut comme lsof, /proc, le foutoir des répertoires systèmes, les ports "bizarres" ouverts par défaut, la base de registres... font que le système apparait comme une grosse boite noire, et qu'il faut certainement bcp plus de temps pour le maitriser à fond qu'un Unix. Et un système qu'on ne maitrise pas sur le bout de doigts, c'est potentiellement plus vulnérable.

Ton troll était plutôt bien amené (infos techniques, comparaison entre différents navigateurs - y compris ceux en mode texte), mais le dernier paragraphe ruine tout.