zul a écrit 443 commentaires

Comment tu as compilé clang ? Par défault, llvm+clang (2.8) sont compilé en mode Release + Assert. Essaye en mode Release only, ça change "un peu" la donne. (sur le svn, par défaut c'est en Debug donc je parle pas des perfs :)).

Personnellement, je l'utilise tous les jours sous Linux x86-64 et je n'ai pas eu tant de problème que ça. clang++ compile globalement plus vite que g++ (même 4.5.1), et il affiche des messages d'erreurs compréhensibles. Le code généré est toutefois un peu moins bon que celui fourni par g++.

Alors oui, on peut râler, apple patati patata, mais bon le code est sous licence BSD, et n'importe qui peut l'améliorer. En attendant, llvm fournit une bonne base pour faire des analyseurs statiques, des IDE, des expérimentations de nouveaux langages, là ou gcc et son architecture ultra monolithique emmerde le monde. SI il y'a des bugs, on peut les corriger, non, le code est libre (et y'a des bugs dans gcc aussi heing sur les architectures exotiques :)).

Enfin, on peut se plaindre du support processeur de llvm mais gcc a aussi supprimé le support d'un tas d'architectures matériels (voir tous les ports où NetBSD utilisant encore un gcc3). Dans le même temps, llvm fonctionne assez bien sur FreeBSD pour avoir été integré au base système.

Je n'en doute pas, enfin l'intérêt premier des monade c'est de garantir par le système de typage la présence (et surtout l'absence) de certaines action impures. Je ne vois pas vraiment sur de l'intérêt en python (à par pour montrer qu'on puisse le faire, ou rigoler sur la théorie des catégories)).

La signature dans un langage dynamique, ça se limite à peu près à l'arité de la fonction ce qui nous amène pas bien loin.

Pour les typeclass, on peut évidemment se tirer une balle dans le pied mais bon, on y peut pas grand chose (à par oui peutêtre rajouter un moteur de preuve dans le compilateur et un générateur de claque). Mais ça reste moins erreur prone puisqu'on explicite qu'on veut que ce "type" réponde à un certain typeClass (donc à une certaine sémantique), en l'implémentant d'une certain façon.

Le problème vient probablement de définitions divergeantes sur la chose. Tout dépend de ce qu'on appelle type, typage statique et dynamique et duck typing. D'après la définition de Wikipedia, (que je partage), le duck typing est une technique utilisée dans les langages dynamiques, où l'on utilise sa liste de méthodes plutôt qu'un hierarchie de classes / mixin / interface autre pour déterminer si l'appel est valide ou pas.

La programmation générique, et / ou l'inférence de type (qui n'est pas vraiment l'apanage des langages de script vu que ça vient plutôt de ML / haskell ...) sont si tu veux du "duck typing static", mais font pour moi partie du système de typage (voir typeclass en Haskell, feu concept en C++) . De plus, en général, la notion de typeclass / concept est un peu plus riche que l'existence d'une "méthode", et en générale une plus forte connotation sémantique. Ça permet d'éviter des choses étranges parce que des objets différents ont un nom de méthode en commun, mais avec des sémantiques absolument pas cohérentes.

Typage statique et duck typing en même temps ? C'est pas un poil contradictoire ?

csh et tcsh n'ont jamais proné la compatibilité avec sh (le seul truc qui est posix). Et oui, écrire des scripts avec csh, c'est
1/ mal parce http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/
2/ mal parce que niveau standard c'est bof

Quand à la portabilité, en général, il faut distinguer deux cas :
- les scripts d'admin pour soit, son parc, vous faites bien ce que vous voulez, si vous introduisez des choses un peu fantasques sur le parc, c'est vous qui aurez du boulot en plus

- les choses qui ont vocation à être redistribuée, alors là, les bashimes me font hurler. Oui tous les systèmes Unix n'ont pas un bash de base, et vivent très bien sans bash. Le standard c'est le bourne shell, ça demande pas un effort énorme d'écrire un script shell portable. C'est marrant comment les logiciels libres se targuent de respecter les standards, et ne sont pas foutu de respecter des choses comme Posix (je parle pas des autres gnuismes qu'on peut trouver dans du code C ou autre).

Psi est un bon candidat (pas que pour Windows au passage). Après pour le son et la vidéo, pas encore mais ça devrait arriver (ça fait tellement qu'on dit ça après ...)

J'ai du mal à comprendre ton assertion :) Tu veux dire que parce que Linux est sous GPL, y'a aucun driver pas libre qui se charge dedans (nvidia.ko par exemple) ou alors que parce que Linux est sous GPL, on peut utiliser ce fameux nvidia.ko partout ? (tu peux remplacer nvidia par n'importe quel autre driver propriétaire à vrai dire).

Même si il était GPL, on serait de toute façon bien embété pour l'utiliser dans du code BSD, sans devoir en changer la licence.

Sauf que tous les frigos sont tous plus ou moins égaux. Le sondage a un sens complétement différent, si tu considère Linux uniquement, ou les autres systèmes libres, en particulier, les drivers Nvidia et ATI ne sont pas dispos sur tous les Unix libres.

Concernant les shells scripts, je savais pas que c'était si dur d'installer un vrai /bin/sh sous GNU/Linux pour avoir des scripts portables. Rien à voir de particulier avec BSD en soit, on veut juste pas de bashime / linuxisme à tout bout de champ.

Oui un contrat de classe, ça pourrait être bien (enfin même c'est bien tout court). Après je suis pas sûr que des classes avec des ctor avec 15 arguments, ils aient des invariants de classe très clair :).

Et sinon, je préfère largement aussi la solution où la compilation échoue, que les solutions où le runtime pourrait detecté une erreur (même si la systémisation via contrat / contrat de classe c'est mieux que rien). Y'a assez de trucs qui peuvent chier au runtime pour pas en plus rajouter des choses qui pourraient être correct par construction (typiquement ce genre de choses, la gestion des types, ....).

My 2 cents, de quelqu'un qui est très très loin des j2ee et autres méga techno IT

Je n'ai rien en particulier contre Hibernate, je connais uniquement de nom (moins j'utilise de Java, mieux je me porte). Je réagissais juste à cette "manie" de faire des ctor vide et de setter les propriétés par la suite, qui me semble une plaie du point de vue sémantique objet. De plus, arguer que ça matche la représentation interne de l'objet, c'est encore pire : un objet doit présenter une sémantique clair lié à son rôle, pas à son implémentation : a Cat is a Cat, quelque soit son implémentation.

Qu'est qui assure que l'objet Cat soit dans un état cohérent à un moment T ? Comment on fait lorsqu'on rajoute des propriétés à Cat ?

Le constructeur sert justement à créer un objet, sémantiquement cohérent (avant le constructeur il n'existe pas, après il existe et il est cohérent). Utiliser des setters dans tous les sens te fait juste perdre cette garantie (tu génère un objet Cat sans aucun sens, puis tu rajoute des informations en espérant ne rien oublier (et que personne ne l'utilise avant qu'il ne soit bien construit). Si on veut vraiment éclaircir le problème des arguments du constructeurs, les arguments nommés sont probablement une solution plus élégantes.

Frédéric Mitterand a jamais été de gauche mais sinon le reste est assez bien vu :D (l'autre on se demande, mais lui c'est sûr :D)

Qt malheureux, Qt ... QT appartient à Apple, et c'est pas du tout libre aux dernières nouvelles

J'aurai pas dit que Debian, gentoo, et archlinux sont des distros end-user. En l'occurence, ubuntu, fedora, et probablement suse utilise SeLinux de base. Ce sont elles les distribs end-user, "modernes" celles qui se propagent.

Concernant ftp, aucune de ces distributions ne lance un serveur ftp par défaut, donc je ne vois pas où tu veux en venir. De plus, je considère aussi comme une mauvaise implémentation une implémentation qui laisse l'accès anonymous par défaut cad sans explicitement l'indiquer)

Après bien sûr, je ("personnellent") serait probablement capable de configurer SeLinux, mais bon, on parle du "end-user", de l'admin à la windows. On peut ensuite demander aux distros end-user de faire une bonne configuration (ce qui n'a pas l'air le cas) (pulseaudio c'est intégré par ces distros, alors même que bon ça reste un choix technique discutable, donc ils devraient assuré la conf SeLinux qui va avec).

Un bon système de sécurité doit avoir un paramètre par défault safe, surtout pour un truc destiné aux end-user. SeLinux c'est installé sur toutes les distribs modernes, et si tu crois vraiment que tout le monde configure au petit oignon SeLinux, hum bah, ouvre les yeux :D SeLinux pas grand monde y touche, même les admins. On peut ensuite reporter la faute sur les distributions si ça te fait plaisir, mais le fait reste : la configuration par "défault sur la majorité des distro" n'est pas bonne (genre carrément insafe) et ça semble trop compliqué pour le commun des mortels à configurer => deux mauvaises choses pour un sous-système de sécurité.

Sans avoir décortiquer l'exploit, je pense que comme dans l'exploit précédent, pulseaudio n'est pas un pré-requis absolu, mais qu'il a utilisé plus ou moins le même vecteur d'attaque que précédement.

Sinon le patch de Linus, hum, une ligne, mais qui ne résoult pas le problème intrinséque (le problème c'est que sock->ops->sendpage pointe sur rien à priori). En faisant ça, on élimine le bug dans ce cas, mais on peut très bien le réintroduire plus tard (vu qu'on a toujours pas fixé le vrai bug (et qu'un mec dans 2 ans, il aura probablement oublié que dans certains cas, l'opération sendpage est non valide).

Clairement, dans le genre stat qui sert à rien, ça se pose pas mal. Le médian de l'ensemble d'une classe, sans considérer la région (Paris Nice Province profonde DOM/TOM, ça change de tout au tout) et l'ancienneté, ça signifie pas grand chose.

1500€ en Province pour un débutant à bac+3, c'est à mon avis dans le marché . À Toulouse, aux dernières informations dans le privée, à bac+5, on commence en moyenne vers 1700-1800€ (et Toulouse c'est probablement plus chère que Nancy). Donc pas une différence affolante.

Content pour tous ceux pour qui a ça semble désespérement bas (si ils ont un salaire à la hauteur :)) mais il ne faut pas se faire un fausse idée du marché. Perso je m'en fous, je suis doctorant après avoir bossé dans le privé, y'a pas photo pour moi (niveau salaire mais surtout niveau intérêt:)). On peut vivre largement correctement avec 1500€ en Province (evidemment, faut pas être un con consommateur :D)).

Bien sûr que le système de package résoult le problème. Je dis juste qu'on ne peut pas "juste" récupérer la dernière version du logiciel, et que cela induit plein d'autres conséquences sur le système, donc sur sa sécurité (en particulier un mix stable / testing / sid, ça doit pas être génial pour les mises à jour de sécurité).

Après ça marche "très" bien, y'a des gens qui tournent "très" bien en sid tout le temps, un mix c'est pas vraiment pire pour la cohésion du système mais ça reste pas vraiment la panacée, surtout pour des gens qui s'inquiètent de la sécurité.

Oui mais debian ... :) Niveau sécurité, faut pas en parler avant quelques années :)

De plus, notons bien :

Pinning allows you to run certain packages from one version (stable, testing, unstable) without the necessity of upgrading your entire system. However, pulling in packages from "later" distributions are prone to pull in libraries as well, which might have you end up with a system that has the disadvantages of stable (old software), the disadvantages of unstable/testing (security support not as good as stable, bugs) without the advantages of either.


Enfin, ça reste encore plus difficile de savoir ce qu'on a sur le système. Evidemment, on a le package "récent" mais quid des dépendances ? et des libs en dépendances qui ont cassé leur API entre temps (un truc qui arrive jamais dans le monde libre) => d'autres softs cassés sauf si ils sont mis à jour, etc ... Clairement pas la panacée. Je préfère encore le faire à la main, au moins, je sais ce que j'ai récupéré et le système va pas m'exploser à la tête.

Hum c'est sûrement toi qui a jamais utilisé Linux. Ce qu'il dit est globalement vrai, à par deux trois logiciels fournis en binaire statique (firefox, OpenOffice), utiliser la dernière version d'un logiciel c'est assez chiant, c'est soit :
- mettre à jour la distro et donc tout récupérer ce qui vient avec
- se taper tout à la main (avec les nouvelles dépendances et tout).

Après, on en tire les conclusions qu'on veut, lui il a pas envie de se faire chier, c'est son choix.

Quand à juger de l'intelligence d'une personne sur le choix de son système d'exploitation, hum bah je pense qu'on sait de quelle côté est l'intelligence. La seule chose qu'on peut juger c'est de ses qualités techniques, et là encore, je pense que tu as du boulot pour rattraper.

Bonne continuation quand même :)

La différence fondamentale, c'est que si tu foire ta recette, ça ne met en péril que tes papilles gustatives et celles de tes convives (au pire). Dans l'autre cas, c'est tout le réseau Internet qui subit (tu va me dire, un peu plus, un peu moins de spam ... :))

De plus, je ne prétend pas qu'il faille savoir tout, mais bon la compréhension globale de son système + la lecture des docs officielles, ça n'a jamais tué personne (et ça contient tout ça)). La configuration semble correcte dans un certain nombre de cas, mais :
- 1/ ça peut évoluer dans le temps
- 2/ faut s'occuper des mises à jour
- 3/ il n'y a raremetn qu'un logiciel qui rentre en compte, c'est la globalité qui compte

Un admin correct doit donc comprendre un "gros" minimum ce qu'il fait, auto hebergement ou pas. Mais la "nouvelle" génération Linux semble oublier complétement que la beauté et la sécurité des Unix libre vient principalement qu'on peut facilement (en y mettant du sien) comprendre ce qu'il se passe. La sécurité de Linux est aussi grande que celle de Windows si on éduque pas les gens.

Mais quand tu veux monter un serveur de courrier « complet », sans forcément savoir ce que cela signifie, tu vas voir où ? Le serveur complet, en l'occurrence, c'est un serveur SMTP (avec SSL et TLS), une configuration DNS pour SPF et DKIM, des milters SPF et DKIM, et un serveur de boîtes aux lettres (POP et IMAP).

Pareil, quand tu veux monter un service personnel complet, sans trop savoir ce que tu peux effectivement faire. Là, en l'occurrence, ce service complet c'est le courrier, des listes de distribution, le web, la messagerie instantanée et la téléphonie.


Voilà typiquement ce qu'il ne faut pas faire. Si tu n'essaye pas de comprendre un minimum ce que tu fais, bah c'est la porte ouverte aux boites à spam, boites à zombies et cie.

Le wiki représente pas mal cet état de fait. A par la page courrier qui est a peu près correcte (comprendre qu'on peut trouver 2-3 informations pas complètement trivial en lisant le fichier de conf ou la man page), les autres sont carrément vides, du genre faite ça, faite ça, c'est bien et cherchez pas à comprendre (on dirait un recueil de mauvais tutoriaux). De plus, la majorité des choix, que ce soit niveau distribution que logiciel ne sont même pas argumentés (Debian c'est propre, j'ai failli m'arrêter là, hahaha, et aussi Debian n'accepte que les projets bien documentés (hahaha)).

De plus, à quoi bon parler d'auto héberment en général puisque tu parle ensuite uniquement de Debian (les commandes, la structure de la configuration, les outils). Il serait à mon avis bien plus pertinent d'enrichir la documentation officielle de Debian si elle ne traite pas de ses points, ou au pire un debian-wiki (doit bien y 'en avoir une bonne dizaine avec tous ses debian-zealots).

Bon courage quand même :) (Pas trop quand même, ça reste assez inutile amha à par 2-3 infos sur les fournisseurs).

Tout dépend si tu considère la proposition comme undivisible ou pas. Les associations visant à aider les sans-papiers ne font entrer personne sur le territoire, elles ne rentrent pas dans cette catégorie. Evidemment, si la proposition est divisible, on va vers du n'importe quoi bien caractéristique de notre bon gouvernement (vers 9h20 je voulais être optimisite, mais bon ça m'a passé assez vite dans la journée :D).