barmic a écrit 10455 commentaires

Je n'y connais pas grand chose, mais peut être que l'avantage de ne pas utiliser de tableau c'est de ne pas fixer une structuration dans la page. Si tu veux permettre à tes utilisateur d'avoir un menu horizontal ou vertical l'usage d'un tableau peut être gênant là où un changement de CSS peut être plus simple.

Je crois que depuis quelques temps il est d'usage sur le web de n'employer les tableaux que pour des données tabulaires et plus pour s'en servir comme gestionnaire de layout. Je présume que ça permet d'avoir un meilleur découplage entre contenu et forme et que d'un point de vu sémantique c'est meilleur.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Le premier danger, objectivement, pour les utilisateurs de Linux sur mobile, c'est Google ou Netflix, pas le pirate improbable.

C'est qui les utilisateurs de linux ? Parce que si tu pense a une utilisation de bureau c'est loin d'être l'unique cible de linux et ce n'est pas son utilisation la plus répandue.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Mais ce n'était absolument pas une critique de SPIP, juste une réponse à sa remarque :

J'espère que cette réponse te donnera envie de voir un plus comment la bête se comporte en vrai.

Et comme je ne suis pas une société, une association ou un média, je ne parle que de mon cas.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Ça fait combien de temps qu’il a été décidé de modifier le rythme de sortie des versions ?

Je crois que je l'ai toujours connu ainsi, donc avant le 2.6.19.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Je suppose que tu pensais plus à CMS qu'à CRM.

En effet.

J'espère que cette réponse te donnera envie de voir un plus comment la bête se comporte en vrai.

Je ne publie pas sur de site perso, mais ça va peut être changé. Personnellement plus que la puissance c'est la facilité de prise en main qui serait un critère de choix, je n'ai pas le courage (ni le besoin) d'avoir quelque chose de très sophistiqué.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

En effet, j'étais pas encore bien réveillé et comme j'ai lu un billet sur cremCRM à peu près en même temps ça s'est téléscopé dans ma petite tête.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Je connais SPIP (de nom) depuis des lustres, j'avais l'impression qu'il était en forte perte de vitesse (arrivé assez tôt dans l'écosystème des CRM, il a maintenant une foule de concurrents), qu'en est-il en réalité ? Des CRM comme joomla (par exemple) sont ils vraiment en concurrence avec SPIP ou est ce que ça ne répond pas vraiment au même besoin ?

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

— Une série d’amendes partant de 1.000 dollars pour les contrevenants, 7.000 dollars pour les organisateurs, porte-parole, dirigeants, 25.000 dollars pour les associations et le tout doublé en cas de récidive !

[humour]C'est une manière comme une autre de faire face à la crise[/humour]

— Le droit de manifester serait interdit dans les établissements et dans un périmètre de 50 mètres, et les organisateurs de manifestations seraient tenus huit heures avant de communiquer parcours, heure, durée, lieux et moyens de transports à un service de police qui serait en droit d’apporter des modifications à l’itinéraire !

Je ne dis pas que le reste n'est pas révoltant, mais cette partie là existe aussi en France depuis longtemps. Je ne connais pas les termes exact, mais pour faire une manifestation, nous sommes tenus d'indiquer aux forces de l'ordre l'heure et le parcourt de la manif'. Celle-ci peut alors être autorisée ou non. Mais ce n'est pas parce qu'elle n'est pas autorisée qu'elle n'a pas lieux (c'est juste plus sportif).

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Sauf que généralement les demandent d'explications pour des logiciels sont des demandent d'explications pas une remarque du type « j'ai pas trop compris, ça m'ennuie ».

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

De façon générale, quand on intègre une nouvelle pièce, je ne vois comment on pourrait éliminer le débat technique. Il est normal que la communauté des développeurs du noyau critique ou soutienne un patch intrusif. Et convaincre un groupe hétéroclite est souvent difficile. Cela m'inquiéterait beaucoup si un module de ce genre pouvait entrer dans Linux comme une lettre à la poste, juste avec l'accord d'un ou deux mandataires Linux.

Si le débat était toujours réellement technique oui, mais souvent c'est vraiment quelque chose qui deviens philosophique (« selon moi ce type de code ne devrait pas être dans tel sous système (bon il se fait que je gère ce sous-sytème est que, peut être, je n'ai tout simplement pas envie d'avoir la charge ce code en plus »). Ça n'est pas une critique contre les hackers en particuliers (que j'admire sous bien des points), mais il me semble ressortir de certaines de ces discussions que des fois ben les réactions sont plus épidermiques que constructives (c'est pareil en entreprise, hein).

Personnellement je suis un peu dégouté je viens de passer toutes mes installations à 3.3.6 ce week end…

Je suis peut-être parano, mais je ne passe jamais aux nouvelles versions majeures du noyau. En tout cas pas sur les machines dont la stabilité est importante pour moi. Je crois que la 3.3.6 est plus fiable que la 3.4 dont les nouvelles fonctionnalités n'ont pas été testées à très grande échelle. Alors si aucune des nouveautés ne me semble immédiatement utile, en particulier en terme de support matériel, j'attends que de nouvelles versions mineures sortent.

Je ne parle que de machine personnelle si un noyau crash je reboot sur la version précédente sans me poser plus de question.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Ce n'est pas la première fois que patrick_g nous relate une discussion qui s'éternise sur des choix techniques. Ça m'attriste toujours j'ai l'impression que le bazar est très loin derrière nous et que les hackers du noyau ont construit une jolie cathédrale. À peu près à chaque fois que quelque chose de nouveau arrive en sécurité, il faut compter 18 à 24 mois pour le voir intégré parce qu'au moins 2 hackers de renom se prennent le choux pour savoir si une vision ou une autre est là mieux.

Je comprends leur intérêt pour la qualité d'un code qui a 20 ans et qui risque bien de rester encore un paquet d'années, mais souvent la question semble être plus proche de querelles de clocher et/ou idéologiques que des arguments fondés sur de la technique et réellement objectif. C'est d'autant plus criant que l'on voit ici que YAMA était prêt il y a un peu moins de 2 ans !

Ce qui est dommage c'est que pour pouvoir intégrer quelque chose qui n'est pas consensuel, il faut non seulement avoir un code de qualité, mais aussi avoir le cuir épais et la tête dur. Pour quelques anecdotes comme celle là combien de fonctionnalités ne sont jamais intégré faute de s'être fait écharpé par la LKML ?

---

Personnellement je suis un peu dégouté je viens de passer toutes mes installations à 3.3.6 ce week end…

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Non c'est déjà arrivé. patrick est plus rapide que les mainteneurs de kernel.org :)

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Les panneaux sur le coté c'est cool, les onglets en haut sont énormes (et donnent envie de vomir en effet). S'adapter aux ratio des écrans modernes c'est à la fois utiliser la largeur, mais aussi être économes en hauteur ce que ces onglets ne sont pas.

Faudra voir ce qu'ils font exactement.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

La principale raison pour laquelle une éventuelle fusion entre les 2 projets est bonnement impossible, c'est pour raisons de licences (merci Oracle!) :
- Apache OpenOffice (license Apache) ne peut reprendre le code de LibreOffice.
- LibreOffice (dual-licence LGPLv3+ et MPLv2 )peut quant à elle reprendre le code de Apache OpenOffice.

Je bosse suffisamment sur des technologies Oracle pour ne pas apprécier cette boite, mais là tu te fou un peu de leur gueule. Oracle (en refilant le bébé à Apache) a choisi la licence la plus permissive, celle qui permet de donner du code à LibreOffice. C'est la document Fondation qui elle a choisi une licence qui interdit une réutilisation dans les projets Apache ainsi que pour tout ce qui est sous licence BSD ou MIT par exemple. Alors oui historiquement la « DocFo » a fait le choix avant Oracle, mais, on le vois aujourd'hui, Oracle a fait ce choix pour que des entreprises comme IBM puissent continuer à travailler avec OOo.

La majeure partie des dev actuels de Apache OpenOffice Incubator sont fournis par IBM qui soutient d'ailleurs activement financièrement le projet. A terme, le but pour IBM est bel et bien de s'approprier AOO en lui injectant le code de Lotus Symphony, lui-même dérivé d'OpenOffice.org (la vraie raison).

« S'approprier » quel joli terme. Le code restera libre (même si principalement développé par IBM), un peu lorsque OOo était développé principalement par Sun (et quelques rares entreprises comme RedHat et Novell).

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

C'est réentrant si tu utilise un type atomic sur le quel tu peux faire une opération du style inc_and_get(), mais c'est effectivement limité à des cas particuliers.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Tu as tout à fait raison mon exemple était mauvais c'est le premier qui m'est passé par l'esprit, j'essaierais de trouver mieux la prochaine fois.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Vous connaissez vraiment des gens qui pensent comme eux dans votre entourage ?

C'est vraiment triste mais oui. Je ne sais pas comment il s'y est pris mais notre ancien président a réellement réussi à décomplexer la droite et ce genre de discourt (que ce soit sur notre protection sociale ou sur la sécurité) se trouve de plus en plus banalisé.

Personnellement la seconde vidéo, je n'ai pas pu continuer plus de 4 minutes (je n'ai pas envie de m'énerver plus que ça).

Ça donne vraiment envie de s'engager dans la politique pour tenter de faire reculer ce genre d'idées.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Ça aurait été faisable à la main évidemment, mais là c'est beaucoup plus court et simple. Ça permet rapidement de faire des choses complexes sans trop de se prendre la tête.

Merci je connaissais mais sous un autre nom (je ne sais plus le quel).

De manière pas aussi simple ça doit pouvoir s'implémenter via un compteur déclaré en static de la finction en C et C++ :

int foo () {
    static int count = 0;
    switch(count++) {
      case 0:
        return 1;
      case 1:
        return 2;
      default:
        return 3;
    }
}

C'est évidement plus lourd à écrire. Par contre il faut que les variables soient déclarée en static pour qu'elles soient sauvegardés et que le code puisse se être séparé (un yield dans un boucle peut devenir comliqué à passer dans cette forme).

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Mauvais exemple: Ce n'est pas parce que exists() te dit que le répertoire n'existe pas que ton mkdir ne va pas échouer avec une erreur du type "le répertoire existe déjà", et inversement.

Tu as raison je suis allé un peu vite.

Mais sinon, s'amuser à réimplémenter de façon buggée toutes les vérifications que peut faire le mkdir() actuel dans le code qui l'appelle, c'est pas vraiment une bonne idée, surtout si ton mkdir() change souvent (ici c'est pas le cas, mais avec d'autres fonctions …).

J'ai pas compris ce que tu voulais dire.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

C'est quoi les continuations ? C'est pas simples à googliser comme terme.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

De ce que j'en sais les exceptions sont assez lourdes que ce soit en C++ ou en Java (bien sûr en relatif), les utiliser comme comportement par défaut n'est donc pas une bonne idée.

Ca se discute au cas par cas. Vaut-il mieux faire des centaines tests ou un bloc try catch ?

Encore une fois, c'est bien pour la gestion des erreurs. Pour les cas nominaux c'est contre-intuitif et lourd.

Tu as aussi de bonne chance de noyer ton traitement « normal » dans tes traitement d'erreur : un catch parmi les autres est le bon.

C'est pour ça que les exceptions sont typées…

Je n'ai pas dis que c'était impossible, juste que c'est contre-intuitif. Ce n'est pas parce que quelque chose est techniquement possible que c'est bien de le faire.

Plutôt que le cas "machin" imaginaire que tu proposes, regarde ce qui ce fait dans boost.graph.

J'ai pas retrouvé la discussion à ce sujet dans leurs archives : http://lists.boost.org/Archives/boost/ ni d'exemples d'utilisation.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Si c'est pour voir ça (sic)

Justement, si tu vois ça, tu es certain que le développeur a voulu ignorer l'exception, pas qu'il a juste oublié.

Au fait en C++ et en Java, il n'est pas obligé de catcher les exceptions. En C++ c'est jamais obligatoire (on est même pas obligé de les déclarer dans le profil de la méthode). En Java les RuntimeExceptions ne sont pas obligé d'être catché (et je crois que c'est la même chose pour les Errors.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Dans quel langage exactement ?

En C++ par exemple.

Et pourquoi est-ce que les performances devraient prendre le pas sur le traitement correct des erreurs ?

Non je pense qu'il a voulu dire que ça doit se limiter à la gestion d'erreur qui elles même devraient être exceptionnelles (sinon il vaut probablement mieux utiliser une approche proactive ce qui permet d'avoir un algo qui n'a pas de saut de n'importe où vers l'un des bloc catch puis de tenter de repartir de cela pour continuer).

Par exemple mkdir -p devrait probablement plutôt faire quelque chose comme :

try {
    if(!exist(dir)) {
        mkdir(dir);
    }
catch(...) {}

que :

try {
    mkdir(dir);
}
catch (IOException e) {
    if (/* exception dut à préexistence de dossier */) { /* OSEF */ }
    else { /* Erreur */ }
}

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Mauvais exemple utiliser les exception pour sortir autrement qu'en erreur c'est une mauvaise idée.

Pourquoi?

Ce n'est pas un usage « normal » des exceptions donc ça a tendance à induire en erreur. Utilisé comme ça c'est chercher à réinventer un goto avec un mécanisme plus sophistiqué et qui n'est pas prévu pour. De ce que j'en sais les exceptions sont assez lourdes que ce soit en C++ ou en Java (bien sûr en relatif), les utiliser comme comportement par défaut n'est donc pas une bonne idée. Tu as aussi de bonne chance de noyer ton traitement « normal » dans tes traitement d'erreur : un catch parmi les autres est le bon. Bien sur je présume que c'est le premier mais ce n'est pas vraiment distinguable. Tu risque fort d'avoir à faire de la gestion d'erreur dans ton catch qui n'est pas une erreur tu es donc repartis pour :

try {
    machin;
} catch (Resultat &r) {
    try {
        /* tout se passe bien */
    } catch (...) {
        /* Erreur */
    }
} catch (...) {
    /* Erreur */
}

ou alors pour éviter la duplication des traitements d'erreur :

try {
    try {
        machin;
    } catch (Resultat &r) {
        /* tout se passe bien */
    }
} catch (...) {
    /* Erreur */
}

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Sur Aix ou à la rigueur Marseille, pourquoi pas mais en week end parce la semaine je suis dans la capitale des Alpes

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)