Quzqo a écrit 833 commentaires

Mosaïcaire de fenêtres. ... et paf c'est l'été, nuits chaudes et suceurs de sang virevoltants.

D'autant que ce qui était dans /dev/.<xxx>, soit sur un montage tmpfs, donc en mémoire, va se retrouver désormais écrit dans le système de fichiers racine avec tous les risques inhérents à ce genre de pratique (des données volatiles dans /).

Il reste effectivement la possibilité, comme souligner par certains, de monter /run en mémoire (tmpfs) mais ça reste redondant avec /var/run (si on laisse de côté le problème au boot, avant montage de /var)...

Ne serait-ce donc pas cette démarche qu'il faudrait privilégier du côté de Linux plutôt que l'apparition d'un /run ?
D'autant que ce qui était dans /dev/.<xxx>, soit sur un montage tmpfs, donc en mémoire, va se retrouver désormais écrit dans le système de fichiers racine avec tous les risques inhérents à ce genre de pratique (des données volatiles dans /).

Tout cela ne me parait pas franchement fiable/logique, genre pansement sur une jambe de bois, et tout cela pour quoi ? gagner quelques millièmes de secondes au boot ? Rester permissif dans la gestion des dépendances des rc.d ?
Histoire de fusionner trois FS (/dev/.<xxx>, /etc, /lib/rw) en un, on rend plus vulnérable /. Je ne vois pas où est l'intérêt.

Mais quand on voit que certains que certains écrivent déjà dans /etc ou /lib/rw (données volatiles dans la configuration statique ou sous la racine), un /run en plus ne doit pas faire peur... :/

Pour ma part, j'aurai surtout retenu le

• Bonne orthographe

dans les offres d'emploi.

A ma connaissance, cela n'a jamais été le cas (au moins pour SFR & Bouygues n'ayant jamais été chez Orange).
Le but (pour l'opérateur) reste tout de même de ne pas favoriser le report de minutes mais que le client atteigne les limites de son forfait pour lui en vendre un plus cher ou, au moins, un nouveau assorti de réengagement.
Je ne dis pas que ce soit très "fair play" mais, commercialement, c'est logique *

Après, j'avoue ne pas comprendre sur quelle base on peut se plaindre du report des minutes alors qu'on a souscrit un forfait et non une offre à la carte.
Le principe du menu c'est bien de payer tout ce que l'on commande même si on ne mange pas tout. A la carte, on peut s'arrêter avant le dessert... mais chaque plat est plus cher.
Les opérateurs ont le dont d'avoir des tonnes d'offres, tarifs et conditions révoltantes mais, au moins sur ce point, ils appellent "un chat"²

(*) sachant tout de même que des offres débiles commercialement, il y en a eu chez tous les opérateurs (depuis le millénium premier du nom vraiment illimité chez BT aux offres promotionnelles "à la carte" de SFR qui permettaient de résilier sans frais)

Pour l'avoir rencontré à l'occasion d'une présentation/discours, j'avoue que je n'ai ni apprécié l'individu ni son intégrisme.
Et pour avoir passé plusieurs années "engagées" (association, promotion, activité indépendante), je pense effectivement une approche pragmatique est beaucoup plus efficace qu'une approche purement éthique même s'il me parait important de ne pas galvauder les valeurs du Logiciel Libre.

Mais au-delà de ces considérations, j'ai surtout été impressionné par la place que semble prendre le LL dans sa vie. Il n'y a de place pour rien d'autre. Alors qu'à mes yeux, la Liberté se gagne d'abord sur d'autres fronts (éducation qui doit apporter une indépendance de pensée principalement) que le LL qui "n'est que" un outil véhiculant certaines valeurs (déjà pas si mal !).

Bref, faire avancer la "cause" demande sans doute des personnes telles que RMS mais il ne m'aura pas laisser un souvenir exemplaire.

Le problème reste principalement de définir "subversif".

Sachant qu'aujourd'hui, de plus en plus d'activités peuvent être reconnues comme illégales sans intervention (et/ou contre poids) de la justice (Hadopi, Loppsi 2) mais sur simple intervention du pouvoir exécutif, voire d'une entité privée, je ne sens pas forcément motivé pour publier tacitement des éléments potentiellement à charge.

En outre, nous n'avons aucune prise sur l'usage qui peut en être fait ni ne pouvons exercer notre droit sur ce type d'informations personnelles.

Je suis d'accord avec nombre de tes arguments.

Je souhaite juste souligner que le principe des class actions n'est pas la panacée en ce qu'il constitue limite une incitation à la procédure judiciaire (tellement il devient simple et déresponsabilisant d'avoir recours à la justice)... avec toutes les dérives de cette justice américaine qui n'aboutit pas à de la Justice mais à récompenser l'opportunisme. C'est à contre courant de ma conception de la Justice et je ne suis pas certain que nos textes feraient mieux pour limiter les dérives.

Pour le reste, je souligne aussi qu'il y a des alternatives à ce type de judiciarisation systématique mais cela suppose une responsabilisation à tous les niveaux (Etats, organes de régulation, contribuables). Je suis sans doute trop naïf...

Et en dernier recours, s'abstenir d'acheter. Par exemple, j'apprécie certaines choses dans les solutions Microsoft mais le modèle de licence et de nombreuses clauses me rebutent. Je n'achète pas (et n'utilise pas, au moins à titre personnel). Ta solution à toi (à supposer qu'il y ait un argument légal) serait de faire un procès pour modifier la/les clauses ?

Pour finir, j'aimerais aussi préciser que la notion de besoin/indispensable est toute relative et que cela ne justifie que rarement une pseudo obligation à acheter, ou faire un procès si le contrat est abusif, au moins à mes yeux.

Merci pour cette dépêche qui me rend encore moins productif (si faire se peut..)

Juste une question concernant les huge pages : pourquoi ne pas avoir l'approche inverse à savoir allouer par défaut des huge pages et les fragmenter si besoin ? Ce ne serait pas plus simple pour garantir la disponibilité d'espaces d'allocation contigus, à priori ?

A contrario, vouloir trouver une solution judiciaire à chaque conflit, et donc faciliter cette voie (avec les class actions par exemple), ne me semble profitable pour personne.
C'est accroitre le coût de la Justice (et donc "appauvrir" le contribuable avec un budget de l'Etat limité), réduire le service rendu (au travers de clauses contractuelles par exemple), et alourdir la note payée par le consommateur final (contre-mesures commerciales/tarifaires).
La judiciarisation du conflit c'est le rendre monnayable.

Dans d'autres domaines, médical par exemple, le soin s'est vu drastiquement limité ces dernières années "grace" aux nombreux procès de malades (moins de soignants dans certaines spécialités à risques, baisse de la qualité de soin, diminution du risque pris et limitations imposées par les décharges) alors que d'autres voies étaient possibles (prévention/intervention du conseil de l'ordre par exemple).

Dans le cas d'offres commerciales, il y a aussi d'autres possibilités offertes au consommateur, notamment refuser l'achat.

Peut-être que si on favorisait l'esprit critique (à priori) de ce dernier plutôt que le tribunal (à posteriori), nous ferions un grand pas dans le sens de la sélection naturelle...

Il y a quelques années, le LCD n'était qu'un rêve de chercheur et on n'envisageait même pas le principe de l'"encre électronique".
Rien ne dit que demain, on ne pourra pas allier les deux technologies selon l'usage multimédia qu'on souhaite faire de son "(i)smartpad" sachant que je me vois mal lire un ouvrage ET visionner un film en même temps.

Par ailleurs, ça n'a d'antinomique que l'habitude/usage qu'on en a comme l'a été le téléphone mobile vs ordinateur/netbook/portable avant de devenir smartphone (avec ses avantages et inconvénients).

PS: à mes yeux mais je me trompe peut-être, le multimédia inclut les livres électroniques.

Heu... c'est bien involontaire car je n'ai aucune "sympathie" pour l'iPad (en tant que produit technophile) et je ne savais même pas que la lecture électronique de ce dernier reproduisait le bruit des pages qu'on tourne.

Quoiqu'il en soit, je dois être bien vieux jeu ou un peu bête mais s'il y a de petits plaisirs que j'apprécie encore beaucoup et qui me font rechigner à passer au tout électronique ce sont bien, outre le format, l'odeur du papier (qui reste mon dernier élément de choix entre deux livres) et le bruit des pages que l'on tourne...

Ne serait-ce que pour de la documentation technique, je trouve le principe d'annoter, intéressant (surtout si ces annotations peuvent être annexées).
Au-delà, il m'est arrivé souvent par le passé de noter/annoter certaines citations d'un bouquin, juste parce que le passage m'a marqué.

Tout ça pour dire que les annotations sont (ou peuvent) être utiles

Je suis globalement d'accord avec toi.

Cependant, après avoir testé le reader Sony (http://www.sony.fr/product/rd-reader-ebook/prs-650?cid=14003644%2F), j'ai été bluffé par la qualité de lecture (technologie je-sais-pas-quoi Ink) et je pense que le jour où une tablette saura allier lecture video + e-book, le produit/concept deviendra intéressant.

Aujourd'hui, l'iPad et consorts présentent deux inconvénients rhédibitoires (à mes yeux):
* un écran brillant (globalement la véritable plaie de tous les produits "portables")
* une connectivité et une autonomie (le reader Sony a prêt de deux semaines d'autonomie mais n'offre effectivement que la lecture) trop limitée.

A l'inverse, côté reader (Sony, je ne connais que celui-là), l'usage me parait lui trop limité (pour un objet de ce niveau de prix) et, même la lecture l'est: pas de lecture audio décente, pas d'annotation, pas de bruit lorsqu'on tourne les pages...

Bref, il y a encore de nombreuses axes d'amélioration sur ce marché et mon côté raisonnable décourage de succomber :)

La seule limitation de la solution RAID est tout de même que la défaillance peut provenir d'autre chose qu'un (ou plusieurs) disques : ton controleur.
Dans ce cas, rare je le conçois, tes données sont potentiellement vérolées et irrécupérables.

Bref, c'est satisfaisant dans une majorité de cas mais ça ne remplace pas une "véritable" solution de sauvegarde/archivage... qui malheureusement demande des interventions récurrentes (externalisation, stockage, vérification des supports).

Histoire de regarder ce que tu "vois" depuis chez toi tu dois pouvoir avoir recours à Nmap.
Sachant que tu n'as pas l'air de pouvoir le pinguer, fais le sans avoir recours au ping.
La syntaxe de base serait quelque chose comme ça (découverte TCP sans ping): [root]> nmap -sT -P0 <adresse IP cible> Un tour d'horizon de nmap expliquant les approches/options possibles est accessible sur Usage and Examples

Si tu sais que le serveur est sécurisé (type portsentry ou autre), je te conseille d'avoir recours à une méthode peu intrusive (pas de -sC -A par exemple) ou ton adresse Free sera définitivement interdite (via iptables, /etc/hosts.*, ...).

Si tu ne vois aucune explication, il te reste encore les solutions :
* tunnel ssh avec ton adresse IP de Résidence Universitaire qui y accède si tu as un ordinateur allumé en permancence là bas
* lancer un serveur ssh "perso" depuis le serveur distant sur un port non privilégié (mais je dois que l'administrateur apprécie)

En espérant t'avoir aidé.

PS: essaie aussi des trucs bêtes du type préciser l'utilisateur ssh (ssh <user>@<host> plutôt que ssh <host>) et activer les traces avec -vvv (ssh -vvv <user>@<host>). Ce sont des erreurs qui peuvent arriver à tout le monde (login différent sur des machines différentes ou configuration du client ssh qui interdit certaines méthodes d'authentification par exemple)

Il n'empêche que du moyen/haut de gamme avec Windows Phone, j'ai du mal à voir l'intérêt pour une utilisation avancée.

Du coup, l'avenir de Maemo->Meego ne semble pas très clair...

Nokia compte-t-il faire comme HTC à savoir une offre Windows, une offre Android (Meego dans ce cas), plus une offre Symbian ?

Quoiqu'il en soit, je suis légèrement blasé d'avoir craqué pour un "haut de gamme" N900 (Maemo) et me retrouver avec un OS laissé pour compte (quasi aucune évolution) si Meego ne fait pas surface alors que le couple de départ N900/Maemo était assez prometteur.

Sachant que l'IDF concentre 20% de la population française (si le chiffre donné plus haut est vrai) et 50% des annonces, je te laisse conclure...

A minima, tu peux ajouter:
Espace: EADS Astrium (incuant SPOT Image) & Cassidian (anciennement Defence & Security)
Automobile: Siemens (équipementier)

Mais je pense que le Kompass est un meilleur ami que ma connaissance du paysage toulousain :)

Oui c'est effectivement un énorme gain de temps (et on peut mieux maitriser ses mises à jour).
<ma vie>
En revanche, ayant déménagé en passant d'une offre 24M (quasi effectif) à du 512/128 (pas effectif), 6km du DSLAM, ce sera ma "première" mise à jour de mirroir Debian après une révision majeure.
Je vais sentir passer les mises à jour massives 32-bit & 64-bit.
Et au final, je ne peux même plus prétendre être un mirroir autre que local.
La Bretagne est un trou perdu en pleine nature... Seule source de regret :S
</ma vie>

Pour répondre à tes critiques, je souhaiterai juste préciser que :
* paquets patchés
De mon point de vue, ce n'est clairement du côté d'une équipe de développement que l'on trouve les meilleures qualités d'intégrateurs (hormis de rares cas). Pour le coup, je suis plus confiant dans l'intégration (et donc la modification des "livraisons" upstream) faite par une distribution (Debian ou pas) d'autant que cette dernière a une vision plus globale du "microcosme".
* gestionnaire de paquet
Je t'invite à parfaire ta connaissance du couple apt/dpkg sur http://www.debian.org/doc/manuals/debian-reference/ch02.en.h(...) & la documentation relative au packaging.
Pour avoir pas mal travailler sur les problématiques d'installation et d'automatisation de déploiement, je dois dire que le système de packaging est parmi ceux les plus complets pour ce qui est de l'installation binaire, source, dépendance, configuration et intégration de niveau système (ordinateur) ou système de systèmes (système complet et cohérent au sens fonctionnel, non informatique)
* Lancement des démons
Je n'ai pas souvenir que Debian ait vocation à être une distribution orientée sécurité. D'ailleurs en relisant le contrat social, j'en retiens qu'il s'agit d'une distribution libre, communautaire, transparente, orientée utilisateurs et respectueuse des standards.

Bref, même si étant un utilisateur Debian (autant pour ses possibilités que pour son "éthique") je suis sans doute partial, je pense que Debian n'est sans doute pas la distribution dont tu as besoin (à chacun ses goûts) mais que tes critiques ne sont pas justifiées.

Cela dépend vraiment des utilisateurs je pense.
De mon point de vue, ça n'a pas grande utilité dans un browser avec un espace d'affichage "conséquent"... peut-être à l'ère des NetBook (9") mais je n'en ai pas (et aucun besoin). Consulter directement le site me parait plus approprié.
Côté mobile, il y a des lecteurs RSS bien plus ergonomiques qu'un browser pour cela et eux se synchronisent à la demande (peut-être est-ce le cas pour Firefox, je ne sais pas), intéressant sur des forfaits limités en data.
Par ailleurs, ça prend juste de la place dans la barre personnelle (toujours pour mon utilisation) et c'est une chose qui manque chez moi.

Bref, je vois d'un bon oeil que ce soit supprimé surtout s'il est possible de l'ajouter ultérieurement au besoin.

Pour ma part, je pense aussi que ça donne la possibilité d'activer dynamiquement le kernel tracing (désolé pour le "franglicisme").

En revanche, je ne suis pas trop d'accord avec :
si (unlikely(point_de_tracing_activé))
alors vrai_travail_de_tracing;
sinon ne_rien_faire
De cette façon les noyaux normaux qui n'activent pas le tracing, et qui sont l'immense majorité, ne patissent pas du coût des opérations...à l'exception du petit test initial !

car, pour ce que j'en comprend, le branchement prédictif se fait sur
si (condition)
alors ...
Le code présenté serait donc optimisé pour le cas où le tracing est activé.
Dans le cas contraire, le branchement prédictif est erroné et le contexte CPU doit être rechargé.
Quelqu'un pourrait confirmer ?

De même, je m'interroge sur le bénéfice du saut/jump (qui est une rupture de contexte puisqu'il introduit une discontinuité dans la séquence des instructions) à moins que les processeurs actuels soient en mesure d'"anticiper" un saut (i.e. précharger le contexte en tenant compte du saut) ou que le pipeline d'instructions soit suffisamment court pour ne pas être impacté. (impensable sur les générations Intel P3/P4).
Du coup, j'ai du mal à comprendre comment les performances ont pu être améliorées avec :

Le premier test se fait en idle (c'est à dire avec une machine inoccupée).
Avant le patch : 32 cycles
Après le patch : 2 cycles

Le second test s'effectue après avoir lancé le test tbench pour générer de l'activité sur la machine.
Avant le patch : 88 cycles
Après le patch : 4 cycles

Si là encore quelqu'un peut éclairer ma lanterne :)

Pour ma part, ce que je conseillerai aux développeurs, sans partir dans des considérations de niveau Ingénierie Système (besoin, concepts, exigences, spécifications...), serait de s'intéresser aussi aux problématiques IVQ (Intégration, Validation & Qualification).
Ca permettrait déjà de se comprendre au niveau de l'équipe de réalisation et d'anticiper ("Risques & Opportunités", le truc qui passe à 10000 au-dessus des têtes en général hormis le PM)...

Produire des spécifications intelligibles serait aussi un sujet à débattre (avec celui de savoir les lire) :)

Bref, le développeur (terme bien vague) devrait être le trait d'union entre architecture et intégration à minima... pas seulement un technicien (avec moult langages) hors pair.

Dans cette logique, je te conseille de jeter un oeil du côté des bibliothèques MOTIF/X11 pour ksh. Il y a quelques années, tous les outils d'admin' Solaris (et AIX peut-être) étaient fait ainsi.

Un équivalent doit être possible en bash d'ailleurs...

Le plus souvent cryptique, ça permet tout de même de faire des choses très intéressantes sans tout une chaine de compilation derrière

Indépendamment, La syntaxe d'un langage est aussi affaire de goût.
Pour ma part, j'ai toujours adoré Perl et ses expressions régulières.
A contrario, j'ai horreur de Ruby.
On ne doit pas être sur les mêmes "Rails" :)