ainsi on ne peut modifier que la dernière entrée pour garder une cohérence sur la chaîne
falsifiable ?
inexistant?
et si on peut tout recalculer pour changer une entrée ancienne,
un système de log à distance ! là où on n'a pas accès au serveur…
après faut en vouloir pour tricher sur le serveur distant pour une TPE…
on pourrait aussi imaginer un système où la clé du dernier enregistrement est transmise sur un serveur web, pour garantir à la fois la transparence des opérations et la confidentialité des données ?
enregistrer les logs sur un média non réinscriptible ?
un truc qui investit dans la théorie de la Terre plate
un truc qui ne propose pas de compte personnel (sérieux ?…)
de revoir mon jugement sur la Poste Bancale, sur la base de témoignages de zélotes clients depuis 10 ans avant la création de la banque (nan mais, sérieux ???)
Donc on est d'accord il n'y a pas d'alternative vertueuse et crédible, mais continuez à moinsser, j'ai presque pas dit du mal des banques, je mérite.
En cas de problème, contacter l'Autorité de Contrôle Prudentiel et de Résolution, Banque de France.
Un axiome (du grec ancien αξιωμα/axioma, « considéré comme digne, convenable, évident en soi » — lui-même dérivé de αξιος (axios), « digne ») désigne une proposition indémontrable utilisée comme fondement d'un raisonnement ou d'une théorie mathématique. https://fr.wikipedia.org/wiki/Axiome
Je crains que le terme d'axiome soit peu rigoureux pour qualifier mon article.
Ce que je publie reste mon avis. Tu es libre d'argumenter à ta façon.
Sélection du paquet python-hachoir-core précédemment désélectionné.
(Lecture de la base de données… 341307 fichiers et répertoires déjà installés.)
Préparation du dépaquetage de …/python-hachoir-core_1.3.3-4_all.deb …
Dépaquetage de python-hachoir-core (1.3.3-4) …
Sélection du paquet python-hachoir-parser précédemment désélectionné.
Préparation du dépaquetage de …/python-hachoir-parser_1.3.4-2_all.deb …
Dépaquetage de python-hachoir-parser (1.3.4-2) …
Sélection du paquet python-hachoir-metadata précédemment désélectionné.
Préparation du dépaquetage de …/python-hachoir-metadata_1.3.3-2_all.deb …
Dépaquetage de python-hachoir-metadata (1.3.3-2) …
Sélection du paquet python-hachoir-regex précédemment désélectionné.
Préparation du dépaquetage de …/python-hachoir-regex_1.0.5-2_all.deb …
Dépaquetage de python-hachoir-regex (1.0.5-2) …
Sélection du paquet python-hachoir-subfile précédemment désélectionné.
Préparation du dépaquetage de …/python-hachoir-subfile_0.5.3-3_all.deb …
Dépaquetage de python-hachoir-subfile (0.5.3-3) …
Sélection du paquet python-urwid précédemment désélectionné.
Préparation du dépaquetage de …/python-urwid_1.2.1-2+b1_amd64.deb …
Dépaquetage de python-urwid (1.2.1-2+b1) …
Sélection du paquet python-hachoir-urwid précédemment désélectionné.
Préparation du dépaquetage de …/python-hachoir-urwid_1.1-3_all.deb …
Dépaquetage de python-hachoir-urwid (1.1-3) …
Sélection du paquet python-hachoir-wx précédemment désélectionné.
Préparation du dépaquetage de …/python-hachoir-wx_0.3-3_all.deb …
Dépaquetage de python-hachoir-wx (0.3-3) …
Traitement des actions différées (« triggers ») pour man-db (2.7.0.2-5) …
Traitement des actions différées (« triggers ») pour menu (2.1.47) …
Paramétrage de python-hachoir-core (1.3.3-4) …
Paramétrage de python-hachoir-parser (1.3.4-2) …
Paramétrage de python-hachoir-metadata (1.3.3-2) …
Paramétrage de python-hachoir-regex (1.0.5-2) …
Paramétrage de python-hachoir-subfile (0.5.3-3) …
Paramétrage de python-urwid (1.2.1-2+b1) …
Paramétrage de python-hachoir-urwid (1.1-3) …
Paramétrage de python-hachoir-wx (0.3-3) …
Traitement des actions différées (« triggers ») pour menu (2.1.47) …
Appuyez sur Entrée pour continuer.
Je suis d'avis que le respect des standards, permet d'éviter bien des inconvénients concernant cette problématique, et est en soi un test de non régression. Un code valide HTML4 le restera, et un code valide HTML5 le restera aussi. Il reste à gérer la transition de l'un vers l'autre, ce qui n'est déjà pas si simple.
Un code invalide, sera bien plus difficile à transposer puisqu'il sera bourré d'exceptions arbitraires. Un peu comme placer un ascenseur dans un bâtiment ancien (administratif par exemple), là où rien n'a été prévu pour.
Quant aux modèles de construction de logiciels, je ne connais ni leurs limites, ni les avantages qui les rendent indispensables.
Peut-être en est-il qui fournissent d'excellentes recettes de spaghettis.
Le ton que tu emploies correspond à ton langage. Tu t'exprimes avec tes mots à toi, sur des sujets qui te tiennent hackeur, et probablement que tu souhaites contribuer à faire avancer, dans la mesure de tes moyens et compétences.
Aussi j'essaie de te lire et en retirer des enseignements, ou arguments à mettre en balance, bien que n'ayant visiblement ni ta formation, ni ton savoir.
Ainsi ton message peut être interprété comme une demande de remise en cause fondamentale basée sur quelque chose de tangible mais difficile à traduire pour moi.
Quant au compte à qui tu as répondu, il semble qu'il soit désormais fermé.
Pour en revenir à l'article précité, on peut découper les commentaire ainsi, grâce aux "Sujet du commentaire".
Ce n'est loin s'en faut pas suffisant, mais tient compte des utilisateurs qui ont souhaité prendre la peine d'affiner la description de l'information additive et de son évolution, vers un sens qui semblait attirer leur attention, et qu'ils souhaitaient, tout comme toi, contribuer à faire avancer.
Parmis les commentaires s'en trouve un traitant d'accessibilité.
Pour mettre un sujet en évidence, on le met en gras.
Il est déjà en titre et les titres sont en gras, comment le mettre en gras ou en évidence ?
On peut fournir l'adresse du noeud (node) http://linuxfr.org/nodes/103492/comments/1565305
mais ce faisant disparaît la conversation qui s'y attache.
Ainsi la souplesse de http://linuxfr.org arrive à ses limites, et pour obtenir un résultat qui contienne cette conversation précise, dans son unicité, et détachée des autres commentaires qui ont des sujets différents, et le faire ressortir, il faut transformer le code, et pour cela il est necessaire d'obtenir un code que l'on pourra débarrasser de toutes les fonctionnalités de présentation et d'interaction.
D'un autre côté, faut-il que le noeud, unitaire, devienne arborescence à son tour, et ne puisse plus être isolé pour sa propre unicité ?
Je ne dis pas que c'est utile à linuxfr.org pour cet exemple, mais cela illustre mon propos de l'intérêt de pouvoir manipuler fond et forme, et pour celà d'éviter les codes mélangés réalisés pour être une fin en soit, où il est impossible de démêler l'information pour la rendre accessible en un autre contexte.
Il aurait été instructif de mentionner le nombre de ligne par commentaire, les mots les plus utilisés, les mots les plus en rapport avec le sujet ou les thèmes associés (delta), mais une structure saine permet largement de l'ajouter ensuite, ou de réexploiter toute information à des fins statistiques.
Et si linuxfr.org n'est pas compatible avec la norme qu'il utilise, est-il possible qu'il le devienne ? à quel prix et pourquoi ?
Enfin, si juger du sens d'un contenu n'est pas le travail de l'architecte du contenu, juger de l'utilité de sa réutilisation ne devrait pas l'être non plus.
Effectivement, la plus-value réalisée par les robots et spider tient du référencement, mais aussi de l'exploitation des contenus qu'ils permettent. Le contenu leur est aussi destiné.
Le concepteur de l'outil ne devrait selon moi pas avoir à pallier à (il paraît que pallier à existe d'après https://fr.wiktionary.org/wiki/pallier ) des codes déficients dont il ne peut connaître par avance quels défauts ont pu être imaginés par le développeur (c'est que ça a de l'imagination, un développeur).
Aussi les concepteurs de tels outils devraient s'attacher à tenir compte d'un standard afin d'analyser les contenus et les exploiter, standards développés précisément dans ce but, et rien que le standard. Ce qu'ils ne font heureusement pas, à lire les titres et descriptions de Google par exemple, lorsqu'ils ont peu de sens… mais sont exploités quand même, puisque même un contenu mal fichu peut être utile.
Aussi l'architecte (au sens général) de l'outil qui sert d'interface à l'utilisateur, quel qu'il soit (du GET à IExplorer, ou Weeboob…), ne devrait pas non plus se soucier des erreurs rencontrées sur les pages, et se concentrer sur les fonctionnalités de l'outil. Ce que là non plus il ne fait heureusement pas, et les navigateurs insérant des fonctions permettant de lire les contenus mal fichus ou non standards.
La description des contenus, peut être simplement de fixer ces liens internes cassés, ou pages déplacées sans redirection. Plutôt que d'imposer à l'utilisateur de chercher et l'outil de recherche de pallier. Ces concepteurs de sites ayant autant peu d'intérêt pour les références des sites externes, qu'ils ont la volonté de capter l'utilisateur, lui imposant un parcours précis pour accéder à l'information. Peut-être mal formés au concept de Toile (Web) et de réseau (network), ou le faisant volontairement pour limiter l'accès à leurs informations, ce qui devient hors-propos.
Reste la question du contenu, de l'information.
Si tout est information, tout peut être considéré comme contenu, et le contenant pouvant être lui aussi information ou simple enveloppe dépourvue d'intérêt. L'un et l'autre sont valable.
Pour cette article j'avais fixé, traitant du fond et de la forme, la limite à ce qui est effectivement statique, l'information brute.
Dès lors qu'elle est dynamique, elle n'est plus brute, et devient évanescente (contenu quantique ?). Elle n'est plus la même selon le contexte, et n'est plus une #entité.
On a alors affaire à un contenant qui vient modifier l'information brute, ou une application qui attend un paramètre pour fournir un résultat, comme « un nombre au hasard entre 1 et 6 ». Dans ce cas, l'information serait la formule, et ne fournirait pas de résultat. Le résultat deviendrait le contenu brut, dès lors qu'il serait soit fournissant le résultat statique, soit fournissant la formule, le paramètre, et son résultat.
Que le code soit effectué sur le serveur, ou sur le client n'a pas d'impact sur ce point.
On pourrait soulever le problème de la Licence libre qui impose de fournir le code, sur demande, à l'utilisateur.
Pour un logiciel libre, condition nécessaire pour que le logiciel puisse être modifié et redistribué (soit de façon libre avec ls GPL, soit de façon fermée avec BSD).
Pourtant, si ce code n'est pas exécuté sur le client, il semble que cette obligation n'est valable que pour le déploiement de l'applicatif sur un serveur, aussi il ne devrait concerner que les codes compilés, puisque les codes interprétés sont en clair sur le serveur, c'est à dire la diffusion du code source au bénéficiaire de la redistribution.
l'industrie entiere ne veut pas entendre parler de secondes vies dans les pays occidentaux des produits high tech.
Les besoins de recyclage des matières premières peut-il en être la cause ?
Ces matériaux indispensables pour construire de nouveaux produits, mais de façon toujours plus économique.
La filière du recyclage est-elle au point / efficace ?
C'est bien parce que certains titres sont là pour l'accroche qu'il y a parfois des second titres. A une époque révolue, on utilisait des titres à rallonge.
Aussi, ayant séparé la forme du contenu, les contenus contextuels, les métadonnées, il reste la structure du document qui porte la donnée.
Cette structure standardisée peut désormais être facilement manipulée et reconstruite à l'infini.
L'argument revenant souvent dans ces colonnes, qui veut que le CSS et le JavaScript se justifient par l'accessibilité, est valable, mais pas dans le cas d'un contenu distribué à un ensemble hétérogène d'individus et de lecteurs (n'oublions pas les robots et autres spiders qui viennent apporter une plus-value démesurée à la distribution du contenu).
Le maître d'oeuvre du site web ne peut savoir à qui il s'adresse précisément, à moins de faire le choix de restreindre son audience. Aussi, il a tout à perdre à chercher à développer pour une audience spécifique, et tout à gagner à coder pour le plus grand nombre. Ce qui peut se faire en suivant les standards du W3C, et tenant compte des exceptions de sociétés commerciales (je pense à Apple ou Microsoft), en rendant ces exception lisses. C'est à dire qu'elles n'interfèrent pas avec les standards, qu'elles ne rendent ni le code inutilisable pour le standard, ni plus complexe à développer pour s'accrocher à des détails qui devraient rester secondaires.
Le maître d'oeuvre n'a pas à s'occuper de l'accès par son audience de façon technique, ou plus exactement, la meilleure façon d'en tenir compte, est de suivre les normes qui prennent déjà en charge ces contraintes techniques, et évitent de les réinventer. Il n'a pas non plus à se soucier de pallier à des contraintes de navigateurs, c'est le travail de l'architecte du navigateur.
Dès lors, ce que l'on appelle la lourdeur du respect des normes, devient un moyen de glisser sur les difficultés et de s'en détacher, pour se concentrer sur l'essentiel, par exemple d'autres modèles de contraintes permettant de transporter et distribuer plus de données, de façon plus efficace, comme par l'audio, la video, la transcription, la traduction et la description des contenus.
Peut-être aussi transformer de coûteuses heures de travail qualifié de développement applicatifs non pérennes, et de surcroît limitants, en la contribution ou le financement d'API modèles, ou la prise en charge sérieuse des contraintes liées à l'accessibilité des données.
Un exemple simple est d'opérer un suivi des accès en erreur (fallback), et d'y remédier par l'action plutôt que par le déni.
Comme par exemple rechercher la raison d'un lien cassé, plutôt que d'attendre de l'utilisateur qu'il effectue lui-même ces recherches.
Ces recherches alourdissent la charge de travail de l'utilisateur, celle des services qu'il utilisera pour ce faire, gonflant la bande passante inutilement, etc… Dès lors que l'on sait l'utilisateur (l'audience), de par des demandes récurrentes, mesuré généralement avec plusieurs zéros, a tendance à se augmenter et se à multiplier.
Cette l'audience est elle-même créatrice de diffusion, et la toile (web) en marche se constitue naturellement. Pour se convaincre de la redondance des requêtes et des contenus, il suffit de lancer une recherche sur Google, qui vous proposera plusieurs requêtes déjà effectuées, et bon nombre de résultats.
Aussi la correction de ces erreurs, la recherche et la résolution des problèmes, ne peut qu'avoir l'effet d'un cercle vertueux. Bien plus efficace que le développement de codes censés apporter de l'accessibilité (sur des détails) tout en nuisant à celle-ci (en général). Ne serait-ce que pour le respect de liens partenaires venant gratuitement augmenter votre visibilité.
Le développement JavaScript pour l'accessibilité, doit ainsi se comprendre dans le respect des standards, par l'agglomération de codes réutilisables, API ou briques de développement, mais de façon systématiquement détachée du contenu auquel il s'applique, pour qu'il ne devienne pas un carcan dont on serait fier.
Il vaut mieux construire des développements sains sur une base saine, et obtenir de la valeur ajoutée avec un code propre, servi par une gestion efficace des ressources.
Nous avons donc constaté le DOCTYPE se rapportant à une norme qu'il ne suivait pas.
Effectivement tout est donnée ou information, à des degrés divers, et ce que j'appelais l'information brute de la page analysée, concerne l'essence de la page, sa raison d'être, ce qui la distingue de toute autre sur le site web.
Le mot "acer" écrit sur mon écran est une information, le on-mouse-over est une information, le mozilla Firefox ou konqueror ou lynx qui s'affiche en haut de la fenêtre est une information. On les distinguera plus facilement du nom de la page (ou titre) rattaché à cette page, mais qui n'est pas l'information contenue dans cette page. Il s'agit de son nom permettant de le retrouver, et le nom ne devrait pas se substituer à ce qu'il nomme, sans quoi ce qu'il nomme serait inutile.
Il semble qu'à l'origine du head, on trouvait comme pour un fichier C, les données externes (prérequis) permettant d'évaluer le contenu (main ou body). Si aucune distinction entre les spécifications précisées dans l'entête et le contenu ne peuvent se différencier autrement que par le "c'est comme ça", c'est une tradition, c'est une convention… alors l'entête n'a pas de raison d'être.
Dans le contenu lui-même, il y a plusieurs degrés d'informations. Celles liées à l'affichage (css), celles liées à l'interaction (javascript), et celles liées à la structure du document (DOM écrit en Xhtml, le X étant je crois là pour sa validité avec le XML, à la différence du HTML, dont le HTML5 est une évolution me semble-t-il).
Pour l'accessibilité, seul le DOM devrait avoir de l'importance, car CSS et JavaScript restent rattachés au contexte, qu'il soit navigateur (sa marque, sa version, son utilisation poste de travail ou mobile, tablette, etc), ou son utilisateur (pas doué du mulot, malvoyant, etc), ou même base de données, archivage, transformation (XSL) d'un contexte à l'autre.
Un document non standard, très joli, avec plein de codes dans tous les sens qui ont beaucoup d'intérêt et de justifications, est juste soit difficile à transformer, soit perdra toute information non conforme.
Enfin le titre contenu dans la balise de l'entête, peut ne pas être le titre du document qui s'affiche, il peut être une simple référence, tel un code barre, ou contenir diverses informations codifiées concernant la place du document ou son thème…
Comme dans une bibliothèque, les métadonnées, telles que le titre, l'auteur, le nombre de pages, la taille de l'ouvrage, etc, ne sont pas l'oeuvre, mais viennent la décrire. Ces données ne sont pas utiles à qui veut l'adapter (transformation) vers un autre média ou en faire une oeuvre dérivée (film, bd, etc).
Pour avoir fait subir à mes 2 SSD en raid0 de pareils tests (moins poussés toutefois) avec dd,
puis abandonné l'idée du raid, vu les performances qui s'effondraient et restaient en-deçà
d'un disque simple (l'explication si je me souviens bien serait la bande passante indiquée par smartctl plus haut),
les 2 disques étant monté sur le même connecteur à la carte mère,
je m'interroge sur la distribution des accès physique des SSD.
En effet, sur ce disque monté donc seul sur la nappe, je m'étais aperçu qu'en reproduisant des tests avec dd (ou mv ou rsync),
les délais s'allongeaient et les performances diminuaient.
Je n'avais pas creusé sur les raisons de ces baisses de performance, n'étant pas spécialiste.
Peut-être cela peut s'expliquer par :
- mon incompétence
- une logique du SSD
- des commandes inappropriées
- des caches du linux qui parasitaient mon test, qui auraient peut-être du être effectués en INIT 1.
- une usure naturelle du media neuf, au bout de quelques jours…
Aussi une question s'ajoute à ces constatations : est-il judicieux d'utiliser un ssd
- pour la swap
- pour toute autre utilisation permettant
. - d'alléger la RAM
. - ou accélérer des traitements (/tmp)
Ce :
- d'une part d'un point de vue des performances,
- mais aussi d'un point de vue de la fiabilité du support ainsi sollicité.
PS : n'ayant pas lu l'intégralité de l'article, vu le boulot qui m'attend,
et je m'en excuse vu sa qualité, il est possible que des éléments de réponse y soient contenus.
GET https://developer.mozilla.org/en-US/docs/Learn/Accessibility/CSS_and_JavaScript|grep "CSS and JavaScript are accessible?"
echo"""CSS and JavaScript are accessible?EditCSS and JavaScript don't have the same immediate importance for accessibility as HTML, but they are still able to help or damage accessibility, depending on how they are used. To put it another way, it is important that you consider some best practice advice to make sure that your use of CSS and JavaScript doesn't ruin the accessibility of your documents."""
[^] # Re: Contact
Posté par Patrick Trauquesègues . En réponse au journal les logiciels libres sont libres de droits. Évalué à -8.
Dans quelle mesure peux-tu affirmer qu'il faut leur demander de modifier le texte ?
[^] # Re: Quelle facilité de la conclusion!
Posté par Patrick Trauquesègues . En réponse au journal les logiciels libres sont libres de droits. Évalué à -5.
Dans quelle mesure peux-tu affirmer qu'il est écrit une connerie ?
# site de la Cour de Cassation
Posté par Patrick Trauquesègues . En réponse au journal les logiciels libres sont libres de droits. Évalué à -4.
https://www.courdecassation.fr
# adresse des mentions légales du site de la Cour de Cassation
Posté par Patrick Trauquesègues . En réponse au journal les logiciels libres sont libres de droits. Évalué à 8.
https://www.courdecassation.fr/mentions_legales_9247.html
[^] # Re: traduction
Posté par Patrick Trauquesègues . En réponse à la dépêche Thème Sécurité RMLL 2017 : de la confidentialité à l'IoT en passant par…. Évalué à 0.
Je parlais des conférences elles-mêmes (relativement aux précédents commentaires), si enregistrement/transcription il y a.
[^] # traduction
Posté par Patrick Trauquesègues . En réponse à la dépêche Thème Sécurité RMLL 2017 : de la confidentialité à l'IoT en passant par…. Évalué à 0.
rien n'empêche de traduire la conf
… si ?
https://translate.google.com/translate?sl=en&tl=fr&js=y&prev=_t&hl=fr&ie=UTF-8&u=http%3A%2F%2Flinuxfr.org%2Fnews%2Ftheme-securite-rmll-2017-de-la-confidentialite-a-l-iot-en-passant-par&edit-text=&act=url
# un système de log avec une clé relative à l'enregistrement précédent ?
Posté par Patrick Trauquesègues . En réponse au journal AUTO-ENTREPRENEURS : Logiciel de facturation obligatoire au 1er janvier 2018. Évalué à 1.
ainsi on ne peut modifier que la dernière entrée pour garder une cohérence sur la chaîne
falsifiable ?
inexistant?
et si on peut tout recalculer pour changer une entrée ancienne,
un système de log à distance ! là où on n'a pas accès au serveur…
après faut en vouloir pour tricher sur le serveur distant pour une TPE…
on pourrait aussi imaginer un système où la clé du dernier enregistrement est transmise sur un serveur web, pour garantir à la fois la transparence des opérations et la confidentialité des données ?
enregistrer les logs sur un média non réinscriptible ?
# une version démarquée de Firefox
Posté par Patrick Trauquesègues . En réponse à la dépêche Nouvelles versions logicielles du projet GNU avril et mai 2017. Évalué à 3.
démarquée -> dégriffée ?
# Autorité de Contrôle et de Régulation, ACPM, Banque de France
Posté par Patrick Trauquesègues . En réponse au journal Boursorama n’aime pas qu’on bloque des choses. Évalué à 1.
En cas de problème, contacter l'Autorité de Contrôle Prudentiel et de Résolution, Banque de France.
[^] # Peut-être en est-il [MVC] qui fournissent d'excellentes recettes de spaghettis
Posté par Patrick Trauquesègues . En réponse au journal #spaghettis xhtml standard, sauce javascript. Évalué à -1.
Un axiome (du grec ancien αξιωμα/axioma, « considéré comme digne, convenable, évident en soi » — lui-même dérivé de αξιος (axios), « digne ») désigne une proposition indémontrable utilisée comme fondement d'un raisonnement ou d'une théorie mathématique.
https://fr.wikipedia.org/wiki/Axiome
Je crains que le terme d'axiome soit peu rigoureux pour qualifier mon article.
Ce que je publie reste mon avis. Tu es libre d'argumenter à ta façon.
[^] # Re: Super interéssant
Posté par Patrick Trauquesègues . En réponse au journal An unexpected Linux : reverse engineering. Évalué à -2. Dernière modification le 29 mai 2017 à 03:02.
# aptitude
hachoir-metadata VirtualBox\ VMs/Nouveau\ groupe/unstable20161204/unstable20161204.webm
hachoir-urwid --debug VirtualBox\ VMs/Nouveau\ groupe/unstable20161204/unstable20161204.vdi
Mais au deuxième fichier pris au hasard, il semble qu'il me faille creuser un peu plus avant d'utiliser de tels outils…
Bon, rien à voir avec cet article d'anthologie.
[^] # Re: KISS : faire simple, faire accessible
Posté par Patrick Trauquesègues . En réponse au journal #spaghettis xhtml standard, sauce javascript. Évalué à -3. Dernière modification le 29 mai 2017 à 01:51.
Effectivement, le code ASCII est toujours utilisé et lu, bien qu'on soit en droit de lui préférer l'uft-8.
Google a surpassé Altavista, sans perte de fonctionnalités, me semble-t-il. Il n'y a pas eu de régression.
http://www.misterfast.com/moteur-de-recherche-altavista.html
Ce qui est parfois nommé principe de non-régression :
http://dico.developpez.com/html/1141-Gestion-de-projet-tests-de-non-regression.php
https://fr.wikipedia.org/wiki/Test_de_r%C3%A9gression
Un article en exemple : "Non régression : une notion simple mais complexe"
http://www.freelance-info.fr/non-regression-une-notion-simple-mais-complexe,123.html
Je suis d'avis que le respect des standards, permet d'éviter bien des inconvénients concernant cette problématique, et est en soi un test de non régression. Un code valide HTML4 le restera, et un code valide HTML5 le restera aussi. Il reste à gérer la transition de l'un vers l'autre, ce qui n'est déjà pas si simple.
Un code invalide, sera bien plus difficile à transposer puisqu'il sera bourré d'exceptions arbitraires. Un peu comme placer un ascenseur dans un bâtiment ancien (administratif par exemple), là où rien n'a été prévu pour.
Quant aux modèles de construction de logiciels, je ne connais ni leurs limites, ni les avantages qui les rendent indispensables.
Peut-être en est-il qui fournissent d'excellentes recettes de spaghettis.
[^] # Re: L'adresse de la page analysée aurait pu être présente dans l'article
Posté par Patrick Trauquesègues . En réponse au journal #spaghettis xhtml standard, sauce javascript. Évalué à 0. Dernière modification le 28 mai 2017 à 18:16.
La page analysée
http://www.news.va/en/news/pope-francis-mercy-friday-visit-to-ostia-housing-p
et la page de référence dans le code étaient différentes.
http://en.radiovaticana.va/news/2017/05/19/pope_francis_mercy_friday_visit_to_ostia_housing_project/1313488
Même si ça n'était pas évident, à la lecture du code…
[^] # il-devrait-etre-obligatoire-d-avoir-une-boite-aux-lettres
Posté par Patrick Trauquesègues . En réponse au journal #spaghettis xhtml standard, sauce javascript. Évalué à -3. Dernière modification le 28 mai 2017 à 17:59.
Sommaire
Ce Tanguy ?
http://linuxfr.org/users/elessar/journaux/coup-de-gueule-il-devrait-etre-obligatoire-d-avoir-une-boite-aux-lettres
Ca ne risque pas d'arriver, effectivement.
Le ton que tu emploies correspond à ton langage. Tu t'exprimes avec tes mots à toi, sur des sujets qui te tiennent hackeur, et probablement que tu souhaites contribuer à faire avancer, dans la mesure de tes moyens et compétences.
Aussi j'essaie de te lire et en retirer des enseignements, ou arguments à mettre en balance, bien que n'ayant visiblement ni ta formation, ni ton savoir.
Ainsi ton message peut être interprété comme une demande de remise en cause fondamentale basée sur quelque chose de tangible mais difficile à traduire pour moi.
Quant au compte à qui tu as répondu, il semble qu'il soit désormais fermé.
Pour en revenir à l'article précité, on peut découper les commentaire ainsi, grâce aux "Sujet du commentaire".
Ce n'est loin s'en faut pas suffisant, mais tient compte des utilisateurs qui ont souhaité prendre la peine d'affiner la description de l'information additive et de son évolution, vers un sens qui semblait attirer leur attention, et qu'ils souhaitaient, tout comme toi, contribuer à faire avancer.
Parmis les commentaires s'en trouve un traitant d'accessibilité.
Pour mettre un sujet en évidence, on le met en gras.
Il est déjà en titre et les titres sont en gras, comment le mettre en gras ou en évidence ?
On peut fournir l'adresse du noeud (node)
http://linuxfr.org/nodes/103492/comments/1565305
mais ce faisant disparaît la conversation qui s'y attache.
Ainsi la souplesse de http://linuxfr.org arrive à ses limites, et pour obtenir un résultat qui contienne cette conversation précise, dans son unicité, et détachée des autres commentaires qui ont des sujets différents, et le faire ressortir, il faut transformer le code, et pour cela il est necessaire d'obtenir un code que l'on pourra débarrasser de toutes les fonctionnalités de présentation et d'interaction.
D'un autre côté, faut-il que le noeud, unitaire, devienne arborescence à son tour, et ne puisse plus être isolé pour sa propre unicité ?
Je ne dis pas que c'est utile à linuxfr.org pour cet exemple, mais cela illustre mon propos de l'intérêt de pouvoir manipuler fond et forme, et pour celà d'éviter les codes mélangés réalisés pour être une fin en soit, où il est impossible de démêler l'information pour la rendre accessible en un autre contexte.
Tu fais bien d'insister sur l'accessibilité des boites aux lettres !
http://linuxfr.org/users/elessar/journaux/coup-de-gueule-il-devrait-etre-obligatoire-d-avoir-une-boite-aux-lettres#comment-1565305
Re: Tu fais bien d'insister sur l'accessibilité des boites aux lettres !
http://linuxfr.org/users/elessar/journaux/coup-de-gueule-il-devrait-etre-obligatoire-d-avoir-une-boite-aux-lettres#comment-1565497
Re: Tu fais bien d'insister sur l'accessibilité des boites aux lettres !
http://linuxfr.org/users/elessar/journaux/coup-de-gueule-il-devrait-etre-obligatoire-d-avoir-une-boite-aux-lettres#comment-1565571
Re: Tu fais bien d'insister sur l'accessibilité des boites aux lettres !
http://linuxfr.org/users/elessar/journaux/coup-de-gueule-il-devrait-etre-obligatoire-d-avoir-une-boite-aux-lettres#comment-1565850
Le Titre : Journal Coup de gueule : il devrait être obligatoire d'avoir une boîte aux lettres
Adresse : http://linuxfr.org/users/elessar/journaux/coup-de-gueule-il-devrait-etre-obligatoire-d-avoir-une-boite-aux-lettres
Auteur : Tanguy Ortolo (page perso, jabber id)
Date : le 03/10/14 à 11:28
Licence : CC by-sa
Tags : poste boîte_aux_lettres timbre en_ville, courrier, Tagger
La structure des commentaires
Non merci
http://linuxfr.org/users/elessar/journaux/coup-de-gueule-il-devrait-etre-obligatoire-d-avoir-une-boite-aux-lettres#comment-1565287
Re: Non merci (27 fois)
combat d'arrière garde
http://linuxfr.org/users/elessar/journaux/coup-de-gueule-il-devrait-etre-obligatoire-d-avoir-une-boite-aux-lettres#comment-1565292
Re: combat d'arrière garde (27 fois)
Justificatifs sécurisés
http://linuxfr.org/users/elessar/journaux/coup-de-gueule-il-devrait-etre-obligatoire-d-avoir-une-boite-aux-lettres#comment-1565481
Re: Justificatifs sécurisés (1 fois)
La Poste ne livre pas de Colis
http://linuxfr.org/users/elessar/journaux/coup-de-gueule-il-devrait-etre-obligatoire-d-avoir-une-boite-aux-lettres#comment-1565300
Re: La Poste ne livre pas de Colis (14 fois)
Il faut le glisser sous la porte…
http://linuxfr.org/users/elessar/journaux/coup-de-gueule-il-devrait-etre-obligatoire-d-avoir-une-boite-aux-lettres#comment-1565301
Tu fais bien d'insister sur l'accessibilité des boites aux lettres !
http://linuxfr.org/users/elessar/journaux/coup-de-gueule-il-devrait-etre-obligatoire-d-avoir-une-boite-aux-lettres#comment-1565305
Re: Tu fais bien d'insister sur l'accessibilité des boites aux lettres ! (3 fois)
Idéologique
http://linuxfr.org/users/elessar/journaux/coup-de-gueule-il-devrait-etre-obligatoire-d-avoir-une-boite-aux-lettres#comment-1565308
Re: Idéologique (17 fois)
Autre solution
http://linuxfr.org/users/elessar/journaux/coup-de-gueule-il-devrait-etre-obligatoire-d-avoir-une-boite-aux-lettres#comment-1565315
Re: Autre solution (29 fois)
C'est qui le patron ?
http://linuxfr.org/users/elessar/journaux/coup-de-gueule-il-devrait-etre-obligatoire-d-avoir-une-boite-aux-lettres#comment-1565472
Coup de gueule !
http://linuxfr.org/users/elessar/journaux/coup-de-gueule-il-devrait-etre-obligatoire-d-avoir-une-boite-aux-lettres#comment-1565486
Rien à voir avec la choucroute …
http://linuxfr.org/users/elessar/journaux/coup-de-gueule-il-devrait-etre-obligatoire-d-avoir-une-boite-aux-lettres#comment-1565517
Re: Rien à voir avec la choucroute … (3 fois)
Excellente idée …
http://linuxfr.org/nodes/103492/comments/1565547
Il aurait été instructif de mentionner le nombre de ligne par commentaire, les mots les plus utilisés, les mots les plus en rapport avec le sujet ou les thèmes associés (delta), mais une structure saine permet largement de l'ajouter ensuite, ou de réexploiter toute information à des fins statistiques.
Et si linuxfr.org n'est pas compatible avec la norme qu'il utilise, est-il possible qu'il le devienne ? à quel prix et pourquoi ?
Enfin, si juger du sens d'un contenu n'est pas le travail de l'architecte du contenu, juger de l'utilité de sa réutilisation ne devrait pas l'être non plus.
Contenus associé :
#code4good
https://careers.jpmorgan.com/careers/programs/code-for-good
https://validator.w3.org/nu/?doc=https://careers.jpmorgan.com/careers/programs/code-for-good
[^] # Re: KISS : faire simple, faire accessible
Posté par Patrick Trauquesègues . En réponse au journal #spaghettis xhtml standard, sauce javascript. Évalué à -1.
Effectivement, la plus-value réalisée par les robots et spider tient du référencement, mais aussi de l'exploitation des contenus qu'ils permettent. Le contenu leur est aussi destiné.
Le concepteur de l'outil ne devrait selon moi pas avoir à pallier à (il paraît que pallier à existe d'après https://fr.wiktionary.org/wiki/pallier ) des codes déficients dont il ne peut connaître par avance quels défauts ont pu être imaginés par le développeur (c'est que ça a de l'imagination, un développeur).
Aussi les concepteurs de tels outils devraient s'attacher à tenir compte d'un standard afin d'analyser les contenus et les exploiter, standards développés précisément dans ce but, et rien que le standard. Ce qu'ils ne font heureusement pas, à lire les titres et descriptions de Google par exemple, lorsqu'ils ont peu de sens… mais sont exploités quand même, puisque même un contenu mal fichu peut être utile.
Aussi l'architecte (au sens général) de l'outil qui sert d'interface à l'utilisateur, quel qu'il soit (du GET à IExplorer, ou Weeboob…), ne devrait pas non plus se soucier des erreurs rencontrées sur les pages, et se concentrer sur les fonctionnalités de l'outil. Ce que là non plus il ne fait heureusement pas, et les navigateurs insérant des fonctions permettant de lire les contenus mal fichus ou non standards.
La description des contenus, peut être simplement de fixer ces liens internes cassés, ou pages déplacées sans redirection. Plutôt que d'imposer à l'utilisateur de chercher et l'outil de recherche de pallier. Ces concepteurs de sites ayant autant peu d'intérêt pour les références des sites externes, qu'ils ont la volonté de capter l'utilisateur, lui imposant un parcours précis pour accéder à l'information. Peut-être mal formés au concept de Toile (Web) et de réseau (network), ou le faisant volontairement pour limiter l'accès à leurs informations, ce qui devient hors-propos.
Reste la question du contenu, de l'information.
Si tout est information, tout peut être considéré comme contenu, et le contenant pouvant être lui aussi information ou simple enveloppe dépourvue d'intérêt. L'un et l'autre sont valable.
Pour cette article j'avais fixé, traitant du fond et de la forme, la limite à ce qui est effectivement statique, l'information brute.
Dès lors qu'elle est dynamique, elle n'est plus brute, et devient évanescente (contenu quantique ?). Elle n'est plus la même selon le contexte, et n'est plus une #entité.
On a alors affaire à un contenant qui vient modifier l'information brute, ou une application qui attend un paramètre pour fournir un résultat, comme « un nombre au hasard entre 1 et 6 ». Dans ce cas, l'information serait la formule, et ne fournirait pas de résultat. Le résultat deviendrait le contenu brut, dès lors qu'il serait soit fournissant le résultat statique, soit fournissant la formule, le paramètre, et son résultat.
Que le code soit effectué sur le serveur, ou sur le client n'a pas d'impact sur ce point.
On pourrait soulever le problème de la Licence libre qui impose de fournir le code, sur demande, à l'utilisateur.
Pour un logiciel libre, condition nécessaire pour que le logiciel puisse être modifié et redistribué (soit de façon libre avec ls GPL, soit de façon fermée avec BSD).
Pourtant, si ce code n'est pas exécuté sur le client, il semble que cette obligation n'est valable que pour le déploiement de l'applicatif sur un serveur, aussi il ne devrait concerner que les codes compilés, puisque les codes interprétés sont en clair sur le serveur, c'est à dire la diffusion du code source au bénéficiaire de la redistribution.
Les termes employés peuvent être inexacts ou approximatifs, tout comme les raisonnements et conclusions, n'étant, je le rappelle, pas un spécialiste.
Le maître d'oeuvre, concepteur du site ou développeur au sens large : https://fr.wikipedia.org/wiki/Ma%C3%AEtrise_d'%C5%93uvre
Le client au sens commercial, appelé ici bénéficiaire : https://fr.wikipedia.org/wiki/Ma%C3%AEtrise_d'ouvrage
[^] # Recyclage des matières premières
Posté par Patrick Trauquesègues . En réponse au journal Et si l'open hardware démocratisait l'usage d'ordinateurs recertifiés (v2). Évalué à 2. Dernière modification le 27 mai 2017 à 16:45.
Les besoins de recyclage des matières premières peut-il en être la cause ?
Ces matériaux indispensables pour construire de nouveaux produits, mais de façon toujours plus économique.
La filière du recyclage est-elle au point / efficace ?
[^] # KISS : faire simple, faire accessible
Posté par Patrick Trauquesègues . En réponse au journal #spaghettis xhtml standard, sauce javascript. Évalué à 0.
C'est bien parce que certains titres sont là pour l'accroche qu'il y a parfois des second titres. A une époque révolue, on utilisait des titres à rallonge.
Aussi, ayant séparé la forme du contenu, les contenus contextuels, les métadonnées, il reste la structure du document qui porte la donnée.
Cette structure standardisée peut désormais être facilement manipulée et reconstruite à l'infini.
L'argument revenant souvent dans ces colonnes, qui veut que le CSS et le JavaScript se justifient par l'accessibilité, est valable, mais pas dans le cas d'un contenu distribué à un ensemble hétérogène d'individus et de lecteurs (n'oublions pas les robots et autres spiders qui viennent apporter une plus-value démesurée à la distribution du contenu).
Le maître d'oeuvre du site web ne peut savoir à qui il s'adresse précisément, à moins de faire le choix de restreindre son audience. Aussi, il a tout à perdre à chercher à développer pour une audience spécifique, et tout à gagner à coder pour le plus grand nombre. Ce qui peut se faire en suivant les standards du W3C, et tenant compte des exceptions de sociétés commerciales (je pense à Apple ou Microsoft), en rendant ces exception lisses. C'est à dire qu'elles n'interfèrent pas avec les standards, qu'elles ne rendent ni le code inutilisable pour le standard, ni plus complexe à développer pour s'accrocher à des détails qui devraient rester secondaires.
Le maître d'oeuvre n'a pas à s'occuper de l'accès par son audience de façon technique, ou plus exactement, la meilleure façon d'en tenir compte, est de suivre les normes qui prennent déjà en charge ces contraintes techniques, et évitent de les réinventer. Il n'a pas non plus à se soucier de pallier à des contraintes de navigateurs, c'est le travail de l'architecte du navigateur.
Dès lors, ce que l'on appelle la lourdeur du respect des normes, devient un moyen de glisser sur les difficultés et de s'en détacher, pour se concentrer sur l'essentiel, par exemple d'autres modèles de contraintes permettant de transporter et distribuer plus de données, de façon plus efficace, comme par l'audio, la video, la transcription, la traduction et la description des contenus.
Peut-être aussi transformer de coûteuses heures de travail qualifié de développement applicatifs non pérennes, et de surcroît limitants, en la contribution ou le financement d'API modèles, ou la prise en charge sérieuse des contraintes liées à l'accessibilité des données.
Un exemple simple est d'opérer un suivi des accès en erreur (fallback), et d'y remédier par l'action plutôt que par le déni.
Comme par exemple rechercher la raison d'un lien cassé, plutôt que d'attendre de l'utilisateur qu'il effectue lui-même ces recherches.
Ces recherches alourdissent la charge de travail de l'utilisateur, celle des services qu'il utilisera pour ce faire, gonflant la bande passante inutilement, etc… Dès lors que l'on sait l'utilisateur (l'audience), de par des demandes récurrentes, mesuré généralement avec plusieurs zéros, a tendance à se augmenter et se à multiplier.
Cette l'audience est elle-même créatrice de diffusion, et la toile (web) en marche se constitue naturellement. Pour se convaincre de la redondance des requêtes et des contenus, il suffit de lancer une recherche sur Google, qui vous proposera plusieurs requêtes déjà effectuées, et bon nombre de résultats.
Aussi la correction de ces erreurs, la recherche et la résolution des problèmes, ne peut qu'avoir l'effet d'un cercle vertueux. Bien plus efficace que le développement de codes censés apporter de l'accessibilité (sur des détails) tout en nuisant à celle-ci (en général). Ne serait-ce que pour le respect de liens partenaires venant gratuitement augmenter votre visibilité.
Le développement JavaScript pour l'accessibilité, doit ainsi se comprendre dans le respect des standards, par l'agglomération de codes réutilisables, API ou briques de développement, mais de façon systématiquement détachée du contenu auquel il s'applique, pour qu'il ne devienne pas un carcan dont on serait fier.
Il vaut mieux construire des développements sains sur une base saine, et obtenir de la valeur ajoutée avec un code propre, servi par une gestion efficace des ressources.
[^] # fr.wikipedia.org/wiki/Header
Posté par Patrick Trauquesègues . En réponse au journal #spaghettis xhtml standard, sauce javascript. Évalué à 0.
Nous avons donc constaté le DOCTYPE se rapportant à une norme qu'il ne suivait pas.
Effectivement tout est donnée ou information, à des degrés divers, et ce que j'appelais l'information brute de la page analysée, concerne l'essence de la page, sa raison d'être, ce qui la distingue de toute autre sur le site web.
Le mot "acer" écrit sur mon écran est une information, le on-mouse-over est une information, le mozilla Firefox ou konqueror ou lynx qui s'affiche en haut de la fenêtre est une information. On les distinguera plus facilement du nom de la page (ou titre) rattaché à cette page, mais qui n'est pas l'information contenue dans cette page. Il s'agit de son nom permettant de le retrouver, et le nom ne devrait pas se substituer à ce qu'il nomme, sans quoi ce qu'il nomme serait inutile.
Il semble qu'à l'origine du head, on trouvait comme pour un fichier C, les données externes (prérequis) permettant d'évaluer le contenu (main ou body). Si aucune distinction entre les spécifications précisées dans l'entête et le contenu ne peuvent se différencier autrement que par le "c'est comme ça", c'est une tradition, c'est une convention… alors l'entête n'a pas de raison d'être.
Dans le contenu lui-même, il y a plusieurs degrés d'informations. Celles liées à l'affichage (css), celles liées à l'interaction (javascript), et celles liées à la structure du document (DOM écrit en Xhtml, le X étant je crois là pour sa validité avec le XML, à la différence du HTML, dont le HTML5 est une évolution me semble-t-il).
Pour l'accessibilité, seul le DOM devrait avoir de l'importance, car CSS et JavaScript restent rattachés au contexte, qu'il soit navigateur (sa marque, sa version, son utilisation poste de travail ou mobile, tablette, etc), ou son utilisateur (pas doué du mulot, malvoyant, etc), ou même base de données, archivage, transformation (XSL) d'un contexte à l'autre.
Un document non standard, très joli, avec plein de codes dans tous les sens qui ont beaucoup d'intérêt et de justifications, est juste soit difficile à transformer, soit perdra toute information non conforme.
Enfin le titre contenu dans la balise de l'entête, peut ne pas être le titre du document qui s'affiche, il peut être une simple référence, tel un code barre, ou contenir diverses informations codifiées concernant la place du document ou son thème…
Comme dans une bibliothèque, les métadonnées, telles que le titre, l'auteur, le nombre de pages, la taille de l'ouvrage, etc, ne sont pas l'oeuvre, mais viennent la décrire. Ces données ne sont pas utiles à qui veut l'adapter (transformation) vers un autre média ou en faire une oeuvre dérivée (film, bd, etc).
https://fr.wikipedia.org/wiki/Header
# L'adresse de la page analysée est présente dans l'article
Posté par Patrick Trauquesègues . En réponse au journal #spaghettis xhtml standard, sauce javascript. Évalué à -1.
Merci pour vos analyses.
L'adresse analysée, peu visible, se situe juste au-dessus de commentaires.
http://en.radiovaticana.va/news/2017/05/19/pope_francis_mercy_friday_visit_to_ostia_housing_project/1313488
Il s'agissait d'un des rares passages compatibles avec XHTML,
bien que contenant du CSS :
[^] # CQFD
Posté par Patrick Trauquesègues . En réponse au journal #spaghettis xhtml standard, sauce javascript. Évalué à -5.
Merci pour ton analyse.
Tu as parfaitement raison quand tu écris
Pour un validateur HTML c'est sûr mais ça tombe bien c'en est pas.
Il s'agit bien d'une flopée de scripts indigestes pour un validateur.
# typo
Posté par Patrick Trauquesègues . En réponse au journal #spaghettis xhtml standard, sauce javascript. Évalué à -5.
Spaghetti (pluriel) ne prend pas d'"s" à la fin.
[^] # Re: variabilité physique
Posté par Patrick Trauquesègues . En réponse au journal HOW TO : Bench this SSD. Évalué à 1.
Voici les données brutes :
dd if=/dev/zero of=/raid_sata/swap_256Mo.dd bs=1M count=256
256+0 enregistrements lus
256+0 enregistrements écrits
268435456 octets (268 MB) copiés, 0,926959 s, 290 MB/s
dd if=/dev/zero of=/raid_sata/swap_256Mo.dd bs=1M count=256
256+0 enregistrements lus
256+0 enregistrements écrits
268435456 octets (268 MB) copiés, 0,882427 s, 304 MB/s
dd if=/dev/zero of=/raid_sata/swap_256Mo.dd bs=1M count=256
256+0 enregistrements lus
256+0 enregistrements écrits
268435456 octets (268 MB) copiés, 0,870653 s, 308 MB/s
dd if=/dev/zero of=/raid_sata/swap_256Mo.dd bs=1M count=256
256+0 enregistrements lus
256+0 enregistrements écrits
268435456 octets (268 MB) copiés, 0,815218 s, 329 MB/s
dd if=/dev/zero of=/tmp/swap_256Mo.dd bs=1M count=256
256+0 enregistrements lus
256+0 enregistrements écrits
268435456 octets (268 MB) copiés, 0,464421 s, 578 MB/s
dd if=/dev/zero of=/tmp/swap_256Mo.dd bs=1M count=256
256+0 enregistrements lus
256+0 enregistrements écrits
268435456 octets (268 MB) copiés, 1,68271 s, 160 MB/s
dd if=/dev/zero of=/tmp/swap_256Mo.dd bs=1M count=256
256+0 enregistrements lus
256+0 enregistrements écrits
268435456 octets (268 MB) copiés, 1,69978 s, 158 MB/s
:~$ dd if=/dev/zero of=/tmp/swap_256Mo.dd bs=1M count=256
256+0 enregistrements lus
256+0 enregistrements écrits
268435456 octets (268 MB) copiés, 1,65426 s, 162 MB/s
A noter : raid_sata est sur la même nappe.
# variabilité physique
Posté par Patrick Trauquesègues . En réponse au journal HOW TO : Bench this SSD. Évalué à 3. Dernière modification le 24 mai 2017 à 03:04.
Pour avoir fait subir à mes 2 SSD en raid0 de pareils tests (moins poussés toutefois) avec dd,
puis abandonné l'idée du raid, vu les performances qui s'effondraient et restaient en-deçà
d'un disque simple (l'explication si je me souviens bien serait la bande passante indiquée par smartctl plus haut),
les 2 disques étant monté sur le même connecteur à la carte mère,
je m'interroge sur la distribution des accès physique des SSD.
En effet, sur ce disque monté donc seul sur la nappe, je m'étais aperçu qu'en reproduisant des tests avec dd (ou mv ou rsync),
les délais s'allongeaient et les performances diminuaient.
Je n'avais pas creusé sur les raisons de ces baisses de performance, n'étant pas spécialiste.
Peut-être cela peut s'expliquer par :
- mon incompétence
- une logique du SSD
- des commandes inappropriées
- des caches du linux qui parasitaient mon test, qui auraient peut-être du être effectués en INIT 1.
- une usure naturelle du media neuf, au bout de quelques jours…
egg:
dd if=/dev/zero of=/tmp/swap_256Mo.dd bs=1M count=256
256+0 enregistrements lus
256+0 enregistrements écrits
268435456 octets (268 MB) copiés, 0,426325 s, 630 MB/s
dd if=/dev/zero of=/tmp/swap_256Mo.dd bs=1M count=256
256+0 enregistrements lus
256+0 enregistrements écrits
268435456 octets (268 MB) copiés, 1,56507 s, 172 MB/s
dd if=/dev/zero of=/tmp/swap_256Mo.dd bs=1M count=256
256+0 enregistrements lus
256+0 enregistrements écrits
268435456 octets (268 MB) copiés, 1,54366 s, 174 MB/s
:~$ dd if=/dev/zero of=/tmp/swap_256Mo.dd bs=1M count=256
256+0 enregistrements lus
256+0 enregistrements écrits
268435456 octets (268 MB) copiés, 2,20899 s, 122 MB/s
Aussi une question s'ajoute à ces constatations : est-il judicieux d'utiliser un ssd
- pour la swap
- pour toute autre utilisation permettant
. - d'alléger la RAM
. - ou accélérer des traitements (/tmp)
Ce :
- d'une part d'un point de vue des performances,
- mais aussi d'un point de vue de la fiabilité du support ainsi sollicité.
PS : n'ayant pas lu l'intégralité de l'article, vu le boulot qui m'attend,
et je m'en excuse vu sa qualité, il est possible que des éléments de réponse y soient contenus.
# correction
Posté par Patrick Trauquesègues . En réponse au journal # et pour ceux qui l'auraient loupé... CSS and JavaScript are accessible?. Évalué à -8.
La mise en forme de l'article aurait du être :
[^] # Re: Accessibilitant
Posté par Patrick Trauquesègues . En réponse au journal #REM on saura peut-être faire le café et pas vous ficher dehors. Évalué à -2.
merci de continuer ici :
http://linuxfr.org/users/patrick32/journaux/et-pour-ceux-qui-l-auraient-loupe-css-and-javascript-are-accessible