BAud a écrit 12991 commentaires

Je suis puni ?

nope, c'est simplement que temporairement (dans l'attente de la refonte de l'espace rédaction) c'est limité à ceux qui ont le rôle de "writer" (avoir soumis une dépêche).

Bah, suffit de faire comme nous procédions auparavant, une page sur un wiki et zou :-)

Peut être qu'une dépêche est en cours ?

eh non, celle reçue contenait moins que ton journal et uniquement le lien vers le tour en anglais.

Il y a http://linuxfr.org/redaction pour ceux qui le souhaitent.

Concernant les firmwares, il y a tout de même le travail fait sur http://fedoraproject.org/wiki/Firmware (dans la continuité de ce qui avait été démarré par Debian pour enlever les firmwares des sources du noyau, puis qui a été poussé sur le git mais séparé du kernel sur kernel.org à des fins de conservation si j'ai bien compris).

bin autant « capitaliser » sur le problème rencontré, tant techniquement que pour tenter d'obtenir d'avoir au minimum une pré-production, à l'identique de la prod', histoire d'éviter que ça se reproduise... Quand je dis capitaliser c'est aussi en profiter pour identifier combien a coûté le souci rencontré :

• temps d'indisponibilité, ce que ça a empêché de faire... (et ce que ça a généré comme coût)
• différence de chiffrage du temps évalué à y passer avant et temps que cela a effectivement pris
• nombre de fois où il est acceptable que ce genre de souci se reproduise...

Si on te répond que doubler l'infra pour des environnements qui ne serviront qu'une fois par an voire mois, bin indiquer les points notés ci-dessus :-) Garder comme autres arguments sous le coude que :

• l'environnement en double pourrait servir de fail-over ou de remplacement si problème sur le serveur principal (les disques ça pète régulièrement, une carte réseau peut griller...)
• dans le cas idéal, ce n'est pas un environnement supplémentaire qu'il faudrait mais un pour le "développement" (s'il y en a), un pour la qualification technique, un pour la qualification fonctionnelle (pour une appli), un pour la recette utilisateur, un pour les benchmarks, un pour la maintenance, un autre pour les montées de version, bon je dois en oublier :-) Il est possible de mutualiser pour optimiser un peu... mais bon généralement c'est tout de même 3 environnements au mini - en comptant la prod' - qui sont recommandés.
• évaluer ce que la virtualisation peut apporter (pour pouvoir créer des environnements à la volée, sans avoir à acheter trop de matériel à chaque fois...), prévoir plus de place disque ça aide, doubler ou tripler le volume envisagé initialement (il y a toujours besoin de plus :/).

Dans l'admin, il y a le volet technique effectivement, mais il y a aussi tous les argumentaires pour justifier de pouvoir bosser correctement et dans de bonnes conditions plutôt qu'avec des bouts de ficelle.

Pour ta vingtaine de serveurs, puppet pour gérer les déploiements peut sembler overkill, mais bon ça permet aussi de scripter une mise en production et de la répéter sur un environnement amont à la prod' sans rien casser, sachant qu'il restera toujours un cas de plus non prévu (sinon spa drôle).

Sinon, comment ça des versions variées de debian ? Tout n'est pas en Squeeze ?

je me suis permis de corrigé^Wcorriger beaucoup d'autres points, la LAL me le permettant :-) (bon choix de licence).
Notamment, j'ai remarqué défitdéfi :-) (mais j'ai pu en oublier :/)

ou pas...

bin, vu que dans ce cas la 403 serait interdite aussi... non par non, ça fait vrai à ce que je sache... oui, c'est une démonstration par l'absurde :)

plus spécifiquement :

• nombre de postes à administrer (pas forcément les mêmes solutions pour une dizaine ou une centaine...)
• types de postes : serveurs d'applications, serveurs d'infrastructures, postes clients, postes nomades voire
• diversité des OS : windows (même si je pense que ceux-là mériteraient leur infra à part tellement c'est compliqué pour bien le faire...), unix (AIX, les Slowlaris même si en voie de disparition..., Linux selon la ou les distros... autres ?)
• niveau de maturité des projets (cycle de développement avec environnements dédiés développement, qualification/recette/préproduction, production ?)

bon, yaurait plus à dire, ça dépendra de tes réponses ;-)

ça veut dire que si tes clients l'ont selon une licence libre (la GPL comme évoqué), bin c'est respectueux du libre (pas forcément de l'esprit, selon certains mais bon...). Qu'un de tes clients le redistribue en libre aussi, avec la même licence est légitime et libre, ils ne le feront pas forcément.

Pour une appli web, regarder du côté de l'AGPL v3 : autrement, ton client pourrait redistribuer via la GPL, sans que tu en bénéficies en tant qu'upstream :/).

qui pour trouver un pont entre l'algèbre et la géométrie ?

ah c'est déjà fait grâce à Andrew_Wiles qui a résolu une conjoncture dont la démonstration tenait dans une marge selon l'auteur, avec un pont avec l'analytique en plus... bon, bin c'est plié.

bien vu :)

tant que quelqu'un redistribue le code source...
Il peut n'y avoir distribution que du binaire... (dont celui de versions modifiées)

La GPL identifie une « forme préférée pour les modifications », ce qui est intéressant aussi.
La BSD c'est génial pour du code interprété, car identique à la GPL (en plus simple et sans effets collatéraux) :)

ou léser, mais avec un grand B (bon ça passe mieux à l'oral...)

Justement, avec un journal il peut y avoir de la modération a posteriori ; en revanche, il n'y en a pas a priori comme c'est le cas pour une dépêche :-)

c'est aussi expliqué sur le wiki : karma

peut sévèrement compliquer la lecture quand les gens répondent sans citer.

il est possible d'utiliser la toolbar pour surfer à -42

c'est plutôt de la grammaire, plus précisément l'accord au pluriel :)

hint: threads :)

En fait, pour les flims sur DVD, autant l'illustrer directement maintenant que LinuxFr.org le permet

Je vous laisse retrouver les contenus parlant de drm sur LinuxFr.org en les tagguant correctement.

tous les flux sont listés sur la page de plan du site http://linuxfr.org/plan et effectivement c'est de l'Atom

tu as une explication de la particularité du certificat sur http://linuxfr.org/aide#aide-certificatssl

et le lien http://www.ed-diamond.com/produit.php?ref=os3&id_rubrique=12&caracteristique=&caracdisp=

Et je rajouterais bien à la dépêche (si ça convient, à étoffer au besoin...), « l'heure de la confirmation » pour OpenSilicium, comme synthèse de l'édito de Denis Bodor. Cette fois-ci, la robotique mais pas seulement : contrôleur de servomoteurs FPGA sur plate-forme Armadeus, mobilité avec android, expérimenter avec arduino et autres sujets. Vivement la suite avec encore des articles variés, suivis et de nombreux sujets.

dire que le tag réseau social t'aurait évité de copier/coller autant de liens :-)

Que ce soit aux RMLL d'Amiens ou de Mont-de-Marsan, ce n'est pas l'impression que j'ai eue... l'un des objectifs de la libération du code étant de permettre d'avoir plus de partenaires (aux USA par exemple), permettant de monter un écosystème là où la R&D de Clamart ne serait pas forcément allé (justement par éloignement, manque de contact privilégié...).

une simple recherche google sur code aster montre qu'il y a au moins des gens à Cosne-sur-Loire et http://www.code-aster.org/V2/spip.php?article63 indique que tu peux aussi aller en Autriche :) Que cherchais-tu spécifiquement ? Dans quel domaine ?

Ne t'inquiète pas, tu peux (re-)parcourir http://linuxfr.org/tags/concours/public pour voir tous les commentaires vexatoires que tu n'as pas encore eu :) (ça t'empêchera de répondre sur le moment, de tourner 7 fois ton clavier avant d'appuyer sur le bouton "Poster le commentaire"). Tu peux écrire les questions en les reformulant plus positivement dans une faq, ça te fera des réponses toutes prêtes pour justifier de continuer à faire un concours pour tous ceux qui ont oublié de s'exprimer et se sont tout de suite inscrits :D ou vont le faire hein, s'ils trouvent l'idée pour gagner).

Toute ressemblance avec des faits passés serait purement fortuite...

ou mageia pour le côté macédonien on va dire :)