benja a écrit 1211 commentaires

Petite correction: son nom est Philip Walder.

Pour que NM fonctionne il faut avoir un /etc/network/interfaces compatible (cad sans les cartes gèrées par NW). Le daemon NW s'occupe d'un peu près tout, tout seul (assigner les ip, mettre les bonnes routes,..); ifplugd,ifup/down ne doivent plus gèrer ces interfaces. Si tu as upgradé, c'est possible que tes cartes ne sont pas gèrées par NW et il faut d'abord les désactiver.
cf. https://help.ubuntu.com/community/WifiDocs/NetworkManager

Sutourt quand tu nous montre ensuite qu'avec seulement 1% de ce potentiel, tu peux créer un commentaire jugé tellement pertinent.

-1

perso, d'un point de vue utilisateur, tous ces machins et ces systèmes sont un gros frein au fait de contribuer du code.

Qu'entends-tu par « utilisateur » ? Je suppose que c'est l'utilisateur (curieux, motivé et connaissant la programmation) d'un programme (et non d'un scm) qui désire améliorer son fonctionnement.

Je dirais que s'il ne veut pas utiliser les outils utilisé par les développeurs de ce logiciel et s'il ne veut pas courrir après les librairies de développement; il peut se contenter d'un apt-get source & build-dep. Pour faire une petite contribution ponctuelle, c'est amplement suffisant. Pour quelque chose d'encore plus trivial (qui ne nécessite pas de recompilation), il peut consulter le viewcvs et y télécharger directement le fichier qu'il désire modifier. Il fait un bête patch et l'envois. Un gros frein ?

Maintenant, si cet "utilisateur" décide de s'impliquer un peu plus dans ce projet, il n'aura de tout de façon pas d'autres choix que de se familiariser avec les outils utilisé. Généralement, les projets fournissent des indications succintes pour récupérer les sources et recompiler le logiciel. Il passe donc de ce statut d'« utilisateur » à celui de développeur. Et petit à petit, il comprend à quel point ce logiciel de gestion de source (distribué) est un gros coup d'accélérateur au développement du projet...

Serait-ce cette même histoire qui aurait marqué Douglas Adam ?

En fait, c'est prévu pour qu'en cas de fs plein (pour un utilisateur), root aie encore une marge de manoeuvre pour réparer les dégats (avec comme effet secondaire la non-impactation immédiate des services qui tournent en root).

Le danger d'un disque plein c'est d'avoir une application critique se prendre une erreure du noyau lorsqu'elle doit écrire sur le disque. Par exemple une mise-à-jour du système qui foire à cause de cas. Jusqu'à présent, dpkg a toujours bien gèrer cette situation chez moi mais il ne faut pas trop compter sur le fait que l'application aie prévue ce cas de figure (car cet un problème qui peut devenir très complexe en fonction des application et je ne pense pas que linux offre toutes les fonctionnalité nécessaire à la prévention de ce genre d'erreures).

Note que modifier ce paramètre a juste l'effet de retarder la pleinitude du disque pour les applications lancées par un utilisateur, le risque de perdre des donnée est sans doutes plus important avec les applications utilisateurs (mal codées) qui n'arrivent plus a enregistrer leur état. Dans cette optique là (pour un /home par ex), on peut dire qu'il est plus sûr de baisser (voir de positionner à zéro) ce paramètre puisqu'il retarde la pleinitude du disque. Par contre, pour le / il est important que laisser ce paramètre à une valeur raisonnable, pour qu'un processus qui remplis le /tmp (s'il est sur la même partition) ne puisse pas affecter les services système.

En pratique, si tu fais attention, tu peux sans problème mettre ce paramètre à zéro. La vm du noyau arrivant plus ou moins bien à différer les écritures arrivant sur un disque plein en attendant qu'il se vide. D'ailleurs, je connais pas d'autre fs qui ont une option comparable. Les quotas et/ou la séparation des /tmp, /home et /var sur une autre partition que / sont quand même bien mieux adaptés pour se protéger contre ce genre de mésaventures.

man tune2fs
-m reserved-blocks-percentage
Set the percentage of reserved filesystem blocks.
ou
-r reserved-blocks-count
Set the number of reserved filesystem blocks.

Je pense que ce paramètre est positionné, par défaut, à 5% par mkfs.ext[23]. C'est clair que sur de gros disque, c'est beaucoup trop. Normalement, seul root peut utiliser cet espace réservé.

Même avec un plan, il faudra amha constuire des outils ou du moins utiliser des méthodes d'usinage différentes pour réaliser les pièces. Enfin cela dépendant de quel degré de similitude on recherche... Ensuite, recylcler une chose pour la reconstuire ensuite a un coût écologique inutile (mais ca ne "crée" pas d'emplois...).

Par contre, avoir les plans ouvrirait pleins de possiblités (sans devoir investir dans la rétro-conception). Par exemple remplacer une électronique obsolète par une conception moderne d'un boitié original. Que sais-je ?

Oh zut ! Je viens de tomber sur un troll.

Pour les (futurs?) fans d'ocaml, il y a le serveur web/framework http://ocsigen.org/ qui est vraiment sympa.

Oui c'est bien cela. Merci pour tout et bon courrage :-)

> À titre d'exemple, sa division francophone (http://squat.net/connect-fr/ ) a donné lieu aux nocturnes des RMLL2005.

J'en garde un très bon souvenir. Merci à eux.
Durant cette soirée, quelqu'un a présenté un projet (si je me souviens bien) à propos de télécommunication & de médias participatifs en Afrique du Nord (???). Quelqu'un s'en souvient-il et aurait-il le lien de l'association/projet ?

Le jour où IE sera open source, t'inquiète pas que vous aurez aussi droit à la gloire, les femmes et tout ça...

Tiré de l'article yahoo:

It's the second time we are at Cebit and last year we already had some actions regarding infringing products," said Thomas Hartmann, senior manager at Societa Italiana per lo Sviluppo dell'Elettronica SpA (Sisvel), in an interview with IDG News Service. The company analyzes the exhibitor list of Cebit and other trade fairs before it begins to identify exhibitors that might have products that are infringing on MPEG audio patents, he said.

"So normally the day before the fair we run through all the halls, see what products are on display and on the first morning when the fair starts we do the same thing again so if there are obviously products which are unlicensed then we possibly have to file a criminal complaint," said Hartmann.

En gros, la dite société vend des licences et profite du Cebit pour se faire un gros coup de pub/terrorisme juridique.
La consultation de son site internet est assez amusante (quoique un peu effrayante).

Ça c'est un problème d'auto-détection du doctype pour les pages qui n'en proposent pas (qui sont mal codées quoi). Il suffit de sélectionner le bon encodage à partir du menu Affichage->Codage du texte. Il y a aussi moyen de choisir l'encodage par défaut à partir des préférences (typiquement mettre iso8859-1 à la place d'utf8).

Pareil mais avec l'instabilité en plus...

Sauf que

OpenBSD systems using default installations are vulnerable because the
default pre-compiled kernel binary (GENERIC) has IPv6 enabled and
OpenBSD's firewall does not filter inbound IPv6 packets in its default
configuration.
However, in order to exploit a vulnerable system an attacker needs to
be able to inject fragmented IPv6 packets on the target system's local
network. This requires direct physical/logical access to the target's
local network -in which case the attacking system does not need to have
a working IPv6 stack- or the ability to route or tunnel IPv6 packets to
the target from a remote network.

Donc bon il y a un vrai risque pour certains.

Ça fait un baille qu'ipf (IPFilter) à dégagé d'OpenBSD. Maintenant c'est pf (Packet Filter). Néanmoins ils ont une syntaxe de configuration quasi équivalente.

Le rapport avec la choucroutte ?

(mais où est passée la case -1 ?)

Concernant ta remarque sur les lcd, il faut savoir que la lampe est prévue pour s'allumer un certain nombre de fois. Donc bon, il faut savoir faire le bon compromis (cela ne sert à rien d'éteindre complètement l'écran pour le rallumer 1 minute plus tard mais d'un autre côté cela use la lampe de la laisser brûler indéfiniment).

> ce qui apporte de l'eau au moulin FPU.

Tu ne peux pas avoir de kernel panic dus à une fpu défaillante ! Enfin si t'as envie d'acheter un nouveau proc, il fallait le dire tout de suite mais tu risque de rester avec ton soucis de stabilité...

Au pire si tu ne peux pas trouver le matériel nécessaire à tester tous les composants, tu peux toujours aller voir ton revendeur pour t'aider à faire des tests.

j'ai un cancer... .doc !

Ça change quelque chose ? Que contient /etc/parpersize ?

Avant d'acheter un nouveau cpu, est-tu sur que c'est bien la cause de ton problème ?
Premièrement, n'y a pas de code utilisant la fpu dans le kernel donc les panics que tu obtiens ne sont pas la faute de la fpu.
Ensuite, l'erreure que lucifer détecte n'est peut-être pas fatale (p.e. une fonctionnalité non existante) et donc tout à fait normale.

Peux-tu reproduire ce test sur une différente configuration équivalente (même cpu). Tu peux aussi essayer de remplacer la carte mère sur ton pc pour voir si les erreures persistent.

Quelle version de noyau utilise-tu ? L'as-tu mis à jour récemment ? Est-il personnalisé ? Bref, as-tu changé d'autres choses sur ton pc avant que ces problèmes n'apparaissent ?

N'y a-t-il pas des interrupteurs qui commutent à l'inversion de charge et qui permettent justement d'éviter les arcs électriques et les phénomènes d'auto-induction ?

Ne serait-ce pas en relation avec SELinux par hasard ?