freem a écrit 5059 commentaires

Je pense que sur des serveurs, des outils comme cfengine, chef, puppet & co doivent permettre d'éviter ce genre d'erreurs non? Enfin, je dis ça, mais je ne sais pas m'en servir, paille, voisin, poutre, tout ça… (ceci étant dit, c'est en haut de ma todo list, j'ai même déjà fait quelques recherches sur le sujet, notamment comment intégrer cfengine à runit/demontools, mais la doc est terriblement pourrie quand même, et il ne semble même pas y avoir un IRC :/).

Sinon, il est aussi possible avec certains clients dhcp d'exécuter un script lorsque l'on reçoit un bail DHCP.
Du coup, en écrivant les scripts qui vont bien (qui doivent, entres autres, configurer le réseau correctement par contre), il devrait être possible d'identifier le réseau sur lequel on est (par exemple, en obtenant l'adresse MAC du serveur DHCP, en demandant au daemon wpa_supplicant, en vérifiant la présence d'un nom DNS connu, etc… avec tous les risque d'usurpation d'identité à prendre en compte, bien entendu, sauf si l'on sait que l'on a une machine spécifique sur laquelle on peut vérifier une identité par exemple SSH, je ne vois pas trop comment éviter ce problème de toute façon).

Je me demande à quel point c'est différent de ce qui était fait par opera v5 (que je n'ai jamais connu, je ne savais même pas ce qu'était un réseau à l'époque)?

S'ils en sont à ce point (pourquoi pas, après tout, il faut bien vivre), ils pourraient s'inspirer plus largement dudit modèle: une version avec publicité incluse, une autre sans mais aux build payants (d'autres projets open source pratiquent ce genre de méthode, pour le build payant) qui n'inclue pas cette fonctionnalité publicitaire. Sachant que, de toute façon, ceux qui le veulent vraiment peuvent recompiler et patcher pour virer les pubs, et je suis persuadé qu'on verra quelques-un de ces «forks» ici et la.

Par contre, quand j'ai découvert opera, j'avais découvert un navigateur qui était vraiment différent de ses concurrents. Alors que quand je regarde firefox, navré mais, de mon point de vue utilisateur, il n'apporte rien par rapport à chromium (ah si, il fait chauffage quand j'essaie de lire une video en streaming, et j'ai des freeze sur des onglets de sites sales remplis de JS (comportements que je n'ai pas sur d'autreS, je précise, autres dont le point commun est d'être basés sur chromium) et… de pub…) sauf un côté open source… ah non, même pas, chromium l'est aussi.

Aujourd'hui, la seule raison qui fait que je pense que Firefox est utile, c'est qu'il s'agit d'un des rares (avec Edge, qui du coup est également utile) à avoir un moteur de rendu différent et qui supporte le JS (l'autre argument geek étant qu'il est libre, mais des browser libres, je peux en citer quelques autres), l'intérêt du moteur de rendu différent étant de réduire potentiellement la dépendance à un outil unique pour un outil aussi important de nos jours que le WWW. L'ajout de pub risque de le faire plus de mauvaise publicité qu'autre chose, et réduit encore son intérêt à mes yeux.

Pour en revenir au sujet.
Des pubs, ok, pourquoi pas. Pas de build payant pour les éviter, bon, tant pis. Mais la question importante, il me semble, c'est outre l'analyse des données en local, que l'on peut de toute façon rendre caduque en virant les histo & co, c'est quelles technologies seront disponibles par ces pubs, parce que voila, on connaît l'imagination des attaquants pour détourner des outils qui ne font à priori rien de mal.
Ici, on parle d'uploader sur des millions de PCs du contenu potentiellement exécutable, ça me semble risqué, non? Ça me semble un bon moyen aussi pour un site d'identifier un utilisateur en embarquant du JS!

D'un autre côté, pour voter, il faut avoir au moins consulté (pas lu, ni même le début: consulté, c'est à dire ouvrir la page). Et comme souvent les plus bruyants sont les négatifs…
Enfin, tu as peut-être aussi été downvoté parce que les gens considèrent que tu devrais faire un journal, cette section est trop jeune pour avoir encore ses us et coutumes :)

Exemple ici mais c'est hard-codé. Pas le choix, avec sed.

Nah, grymoire mériterais plus qu'un simple lien, à mon sens, mais il est si ancien (comme il se doit pour un tel ouvrage) que je doute qu'un bookmark serait accepté :) ou alors, il faudrait une collection de liens de ce niveau, par thèmes. Un truc pour aider les gens à la barbe naissante tout comme ceux pour qui elle est déjà fleurie.

Pour la 1ère catégorie, je commence à penser qu'il faudrait un tutoriel sur l'utilisation de linuxfr…

Zut, j'allais éditer comme suit:

[EDIT]
Je viens de voir que ce lien est dans le négatif. Je ne sais pas pourquoi, et je m'en fiche, vu que je ne peux pas voir à priori le nombre de votes.
Personnellement, j'ignore la plupart des liens (je suis arrivé ici par la section derniers commentaires, en bas, et j'ai été intrigué par le titre, j'en ai lu le lien du coup :)), parce que je ne trouve pas intéressant de juste lâcher des liens sans 2 lignes au sujet de leur rôle et contexte, mais il est probablement que ce soit lié à l'«auto-promotion» (ce qui n'a rien de mal à mes yeux) qui peut mal passer auprès de certains, qui ne dirons pas forcément la raison de leur downvote. J'imagine que c'est ce qui a motivé ton commentaire.

Ce qui est dommage dans votre système, c'est de ne pas connaître les auteurs "anonymes" des downvotes. C'est extrêmement "déresponsabilisant".

Je n'ai jamais vu, je crois, de site permettant de lister les downvoters.
Et au final, je trouve que le nombre de pertinentages et de moinssages permets souvent d'avoir un bon aperçu du type de pertinence du message (à partir d'un échantillon minimum de votes, bien entendu. Je considère qu'a partir de 10, on a une note qui commence a refléter un message intéressant, pour lequel la suite s'applique potentiellement):

• s'il est globalement apprécié (75% minima étant positifs), soit c'est du contenu amusant (pour notre communauté) soit c'est du contenu qui introduit des éléments intéressants;
• s'il est globalement neutre (entre 35% et 65% de positifs) on sait qu'il s'agira d'une opinion sujette à débat;
• s'il est globalement inutile (entre 75% et 90% d'inutiles) on sait que la plupart de la communauté est en désaccord, ou trouve le message déplacé. En fonction de la taille et de la forme, on devine rapidement si ça vaut la peine de lire malgré tout;
• à partir de 90% d'inutiles, on peut se poser sérieusement la question du troll, voire du spam.

Évidemment, pour que ces raisonnements tiennent, il faut un certain nombre de votes (le nombre 10 est faible, en fait je pense que je le mettrais plutôt dans les 20, -/+5 selon les périodes), et j'ai volontairement laissé des zones blanches parce qu'en fait, selon le sujet, le jour, les phases de la lune, et bien d'autres paramètres, un message peut ne pas coller pour celui qui le lira, ou une catégorie être plus ou moins controversée avec en fin de période une note négative pour des messages pertinents. C'est des statistiques au pifomètre après tout, et l'instrument à beau être précis, vu que personne ne sait convertir l'unité de mesure dans une plus classique, l'interprétation des résultats est délicate.

Du coup, je pense que j'y suis attaché, à ce système, même si mes interventions sont régulièrement dans les négatifs :)

Le problème de prendre ses responsabilités varie en fonction de la culture, et ici les gens sont assez peu sensibles (selon mon impression) aux consensus globaux et aux modes, même si on a aussi nos guéguerres. En espérant que ça te fasse voir ce mécanisme sous un jour différent :)

Pfff… j'étais en train de le dire -.-' tu m'as devancé. Par contre y'a pas que sed.

Pour awk, sed, et autres outils unix, il y a un site que j'aime bien: grymoire. C'est pas joli, ça cause pas le https, mais c'est bien foutu et c'est efficace pour peu qu'on lise l'anglais.
Ce que j'appelle bien foutu, c'est des exemples minimaux (donc, qui n'illustrent qu'un seul point) et des explications pour aller avec.

M'enfin, en gros, awk travaille ligne par ligne, comme sed, mais en plus, il ajoute 2 notions importantes: les champs, et un langage de programmation. Les premiers te permettent de manipuler (les manipulations supportent les regex, au passage) une ligne par champs (mais il peut être nécessaire de spécifier le séparateur, comme dans ton cas) et le 2nd te permets entres autre de ne déclencher des traitement que quand une condition à été remplie, par exemple parser la 1ère ligne pour savoir quelle colonne contiens le champs que tu souhaites manipuler.

Pour le reste, je te laisse à la doc, elle sera plus explicite que moi.

Il y a moyen que awk soit plus adapté, mais si tu tiens à utiliser sed, alors il te faudra hard-coder la position de la colonne qui t'intéresse, par exemple si c'set en 3ème position (en partant de 1) et en supposant que ce caractère n'intervienne qu'une seule fois par champ: sed -i 's/^\([^;]*;[^;]*;[^.]\)\.\(.*)$/\1,\2/g'.

Bon, on peut probablement mieux faire, même avec sed, mais bon, awk aurait été plus adapté à mon sens (même si je ne saurais pas le faire vite fait).

À savoir que mon exemple échoue dès lors que tu te retrouves avec des champs contenant un ; échappé avant la colonne de prix, aussi.

donc sur les serveurs mais sur la partie bureautique, ils sont à la ramasse…

C'est à dire? Tu as entendu parler d'une faille de sécurité non corrigée pendant longtemps alors que toutes les autres distros qui font du support sur le temps avaient corrigé le problème?

Et cela n'a donc rien à voir avec makepkg, tu pourrais très bien faire une ArchLinux avec un support de 5 ans si tu avais déjà gens motivés pour faire la maintenance.

Bien sûr, ce problème n'a rien à voir avec le système de paquet: il est lié au fait de ne pas être une rolling release. Une rolling release peut se contenter de suivre le code originelle. Les autres sont obligées de patcher, surtout si l'upstream n'en a rien à foutre des versions de plus de 6 mois (de mémoire, il me semble que c'est une source de problèmes pour kde, mais je dis sûrement de la merde vu que je ne m'intéresse pas aux bureaux lourds).

Mais il est clair que les paquets debian sont compliqués à faire, bien plus qu'un RPM, bien plus qu'un paquet ArchLinux et je te raconte pas pour eopkg…

C'est bien de le répéter à l'envi. Maintenant, il faudrait probablement citer avec une vraie comparaison, comme ça, on pourrait peut-être voir s'il y a une raison derrière cette complexité.

Arch publie des bouts de code downloadés et empaquetés sans modifs. Debian maintiens une distro sur plusieurs années en corrigeant les problèmes de sécurités de bases de code parfois obsolète.

Donc, la différence, c'est que Debian nécessite un travail de développement sur les paquets, qui n'est pas pertinent dans une rolling release.

Je comprends maintenant pourquoi j'ai toujours détesté manipuler des .deb.

Heureusement que je n'ai pas attendu ton commentaire pour comprendre pourquoi les utilisateurs les plus bruyants (je suis sûr que ce n'est pas la majorité, ceci dit. Enfin, j'espère.) d'arch me les cassent…

Les deux sont clairement intéressants.
Un code fiable, c'est utile (parce que faire un truc inexploitable rapidement, c'est inutile), un code rapide aussi (parce que réaliser des calculs tellement lentement que le résultat est obsolète quand on l'a, c'est tout aussi inutile).
Et il y a d'autres avantages aussi, comme la compacité du blob, la possibilité de vérifier que les dépendances sont installées (à plusieurs reprises j'ai eu ce genre de problèmes avec des paquets debian qui contenaient des applications pythons: libfoobar.so non trouvée. Amuses-toi à retrouver le paquet qui aurait dû être installé automatiquement…) via des outils comme ldd, la possibilité même de lier en statique pour avoir un truc vraiment petit et qui démarre à la vitesse de l'éclair…

Je disais juste que, personnellement, en tant que développeur, ce que j'apprécie le plus chez les compilateurs, c'est bien le fait qu'ils peuvent me signaler quand je fais de la merde (et ça arrive assez souvent pour que je n'aie aucune envie d'utiliser sérieusement des langages interprétés).

Si la vitesse est vraiment critique, je pense qu'il faut déjà réfléchir l'application autrement, et pas juste la passer à un compilo.
Déjà, ça va dépendre du CPU cible: s'il a, ou non, des caches, combien de coeurs logiques sont présents, est-ce que l'application à vraiment besoin de pointeurs de 64 bits (parce que 8 octets, sur une ligne de cache, ça fait beaucoup, alors que pour pas mal d'applications 4 suffiraient probablement).
Ensuite il y a l'architecture du soft.

Bref, c'est toujours sympa de récupérer de la vitesse, mais si c'est critique, je doute que juste passer dans une moulinette soit la façon la plus efficace de travailler.

Pour moi, le compilo, c'est surtout un outil d'analyse statique.
Un code compilé, avec tous les warnings activés et considérés comme des erreurs, garantit l'absence de nombreux bugs, je pense notamment aux problèmes de transtypage (-1 == 0xFFFF? Vraiment? Ça dépends.), au bug d'indentation, au code qui n'est pas atteignable, aux variables jamais utilisées alors qu'elles le devraient, aux conflits de noms (ah, ma méthode bar de la classe hello à une variable foo, alors que ma classe à également une propriété foo => ça pue les bugs, présents ou à venir), et j'en oublie.

Malheureusement, le site de ta distribution manque cruellement de documentation (et le lien pour installer redirige vers une page qui se contente d'afficher de la pub…) donc ça va être compliqué de taper dans le mille :)

Si ta distribution te permets, lors de l'installation, d'avoir un accès à une ligne de commande, essaies de lancer la commande efibootmgr avec l'utilisateur root.
Si le système te réponds, comme je le soupçonne fortement: «EFI variables are not supported on this system.» ou pire, s'il ne connaît même pas la commande, c'est simple: le démarrage UEFI n'est peut-être pas supporté out-of-the-box.

Un UEFI (successeur du BIOS) ne détecteras que les OS enregistrés correctement. S'il n'en trouve pas, il n'indiqueras aucun «disque» de démarrage.
Du coup, je suis quasi sûr que ton UEFI démarre en mode «moderne» (le mode «legacy» permettant la compatibilité avec les anciens mécanismes d'amorçage), donc nécessite une partition de démarrage en FATxx (souvent du FAT32, mais d'autres FAT marchent aussi) préparée pour un démarrage par UEFI, que ta distribution ne fait peut-être pas correctement.

La doc pour installer syslinux du wiki d'archilinux contiens une section qui indique ce qu'un démarrage UEFI va chercher par défaut, quand on n'a pas encore eu la possibilité de démarrer en mode UEFI:

When booted in BIOS mode, efibootmgr will not be able to set EFI nvram entry for /EFI/syslinux/syslinux.efi. To work around, place resources at the default EFI location: esp/EFI/syslinux/* -> esp/EFI/BOOT/* and esp/EFI/syslinux/syslinux.efi -> esp/EFI/BOOT/bootx64.efi

Donc, si je résume un peu tout en français, pour préparer un système qui sera visible par un UEFI (sans secure boot, je précise, je ne connais pas du tout ce qu'il faut pour secure boot) il te faut:

• un disque utilisant une table de partition de type GPT (toutes les distributions ne font pas nécessairement ça par défaut!);
• une partition formatée en FAT32;
• mettre le drapeau «ESP» sur cette partition;
• qu'il y ait dans cette partition un fichier à l'emplacement suivant: EFI/BOOT/ (*) nommé bootx64.efi qui contiens le programme d'amorçage de ton système.

Normalement, à partir de là, tu devrais voir ton système dans le BIOS.
Si, comme supposé par d'autres, c'est un problème de 64 bits vs 32 bits, tu dois probablement utiliser un fichier nommé bootx32.efi (j'en ai vus dans ma debian, même si je n'y ai jamais eu recours). Au pire, rien n'empêche d'avoir les 2 côte à côte.
Dernier point: personnellement, j'utilise syslinux, mais il en existe d'autres qui ont moins d'inconvénients (qui requièrent moins de manipulations lors de mise à jour de noyau, en fait).
Ceci dit, l'avantage de syslinux, c'est sa simplicité de configuration, et comme il ne fait rien automatiquement, il est pratique pour diagnostiquer.

*: à partir du point de montage de la-dite partition, c'est à dire si elle se situe dans /dev/sdc10, il te faut par exemple faire en root: mount /dev/sdc10 /tmp; mkdir -p /tmp/EFI/BOOT et mettre un fichier bootx64.efi ici.

Tu as 1 seul disque (hd0) avec 3 partitions : https://www.gnu.org/software/grub/manual/grub/html_node/Naming-convention.html

Oui, mais la 3ème (hd0,msdos5) est une partition étendue, donc, une «fausse» partition (de 1 à 4, ce sont les partitions primaires d'un disque formaté en ms-dos, la 5 c'est l'éventuelle partition étendue, au-dessus ce sont les partitions virtuelles. Bon, c'est juste ce que j'ai déduit de tous les disques que j'ai manipulés, je peux me tromper et je n'ai pas de source officielle sur le sujet). Ce qui me surprend, c'est que justement, il n'y ait pas de partition au-dessus.

Peut-être un problème lié à l'ordre d'amorçage (sur quel périphérique chercher l'OS)?

Sinon, tu démarres en mode BIOS ou UEFI?

Déjà, quelques questions:

Ta machine à déjà démarré en dual boot?
Tu as fait des mises à jour sur un des systèmes entre le moment ou il démarrait et celui ou il ne démarre plus?

Ensuite, une suggestion:

Si tes données utilisateur (ton /home) sont situées sur une partition dédiée, je te suggère fortement de les récupérer à l'aide d'une clé USB ou d'un CD de récupération avant toute manipulation. Même chose pour celles que tu utilises sous Windows (reste à savoir comment tu as fait tes partitions, mais ça, il n'y a que toi qui le sait).
Si tu ne peux récupérer tes données de cette façon et qu'elles sont importantes à tes yeux, alors fait une copie complète du disque dur, afin de pouvoir travailler dessus par la suite une fois ton système à nouveau fonctionnel.

Ensuite, une fois ceci fait, je te suggère de réinstaller grub directement, ça sera probablement le plus simple pour avoir un système à nouveau fonctionnel, en espérant que je ne me trompe pas sur mon analyse qui suit).
Si jamais ce n'est pas possible, je te suggère, si tu as les moyens de réinstaller ton windows, de changer le format de ta table de partition en GPT (qui permettra notamment d'installer grub sans que cet outil ne dissimule son obésité dans des secteurs théoriquement non accessibles), puis de réinstaller windows et enfin de réinstaller Mint. Et de réserver 2 partitions pour tes données utilisateur, cette fois-ci: une pour linux, et une pour windows, sachant que depuis linux tu seras capable d'utiliser une partition de type NTFS (le format de windows), l'inverse n'étant pas nécessairement vrai (il existe des outils pour accéder à du ext3 sous windows, mais la dernière fois que j'ai essayé, c'était pas terrible du tout).

Pour ce qui est de ce que je suppose de ta situation:

Pour vous donner de l'info, j'ai tapé la commande ls. Cela a donné :

(hd0) (hd0,msdos5) (hd0,msdos2) (hd0,msdos1)

Puis j'ai tapé la commande set. La réponse est :

cmdpatch=(hd0)
prefix=(hd0,msdos6)/boot/GRUB
root=hd0,msdos6

À vue de nez, on dirait que la partition secondaire numéro 6, celle qui contiens probablement la partition système de ton linux Mint, à été détruite (en tout cas, grub ne semble pas la trouver). Il faudrait idéalement vérifier de l'extérieur (en démarrant un système complet sur un CD ou une clé usb) si c'est bien le cas.
Ce qui m'intrigue, c'est que normalement grub devrait toujours te proposer de sélectionner un système avant ça. Du coup, je me demande si ce n'est pas un peu plus grave.

Vu que tu utilises une table de partition de type MS-DOS, et que grub utilise une astuce sur ce format pour stocker ses données de démarrage, je pense que j'irai creuser du côté d'une table de partition endommagée: ça expliquerait qu'une partition ait disparu et que tu n'arrives pas sur le menu de démarrage standard de grub, ce qui me fait penser fort à une mise à jour qui se serait mal passée.

Ça ne te seras peut-être pas très utile, mais sait-on jamais…

Pas faux.

Je suis tombé sur cette information en lisant ceci: https://lwn.net/Articles/749992/

[edit]

Zut, bug de connexion qui à causé un double post… à supprimer?

Chez moi, il faut double-tabuler en cas d'ambiguité et c'est pas spécialement lent (il me sort quasi-instantanément Display all 10244 possibilities? (y or n)).

Chez moi, il faut double tabuler à chaque fois que l'on veut afficher une liste avec bash, par exemple, avec zsh:

mkdir /tmp/foobar /tmp/foorab
cd /tmo/foo<tab>

affiche la liste. Avec bash, il faut le faire 2 fois. Donc, quand on veut d'une part compléter jusqu'à l'ambiguïté, et d'autre part afficher la liste, il faut tabuler un total de 3 fois avec bash, 2 fois avez zsh (chez moi, et avec mes config, qui est custo uniquement pour zsh). Notes que je me dis que ça serait sympa que, dans le cas ou /tmp/foo n'existe pas, une seule tabulation affiche la liste. Ça serait probablement le plus intéressant, et aucun des deux ne semble le faire ici.

À mon avis tu as un truc cassé dans ta config.

Pas impossible, sauf que je ne modifie plus ma config bash depuis que j'utilise zsh.

J'aime bien zsh, mais de là à prétendre que la complétion intelligente de bash est incomparablement moins bonne, c'est peut-être pousser le bouchon un peu loin quand même.

J'ai pourtant lourdement insisté que c'est le comportement ici, que j'ai, et que ça peut varier en fonction de systèmes.
Notamment, j'utilise Debian stable avec certains paquets rétroportés, le tout sur un système minimaliste.

Ce que ça implique:

• déjà, si tu utilises un autre distro, tu as probablement des versions des softs plus récents;
• ensuite, il n'est pas impossible que Debian ait des patchs qui affectent l'auto-complétion;
• il est probable que certains paquets ne soient pas installés (le paquet bash-autocompletion l'a été quand j'ai testé, ceci dit) soit parce que pas listés dans les dépendances (depends, recommends ou suggests… j'ai déjà eu le cas sur des depends sur certains paquets debian) soit parce que je les considère inutiles dans mon usage (plus probable).

Ce que j'ai dit, c'est qu'à l'époque ou j'ai lâché bash, sur les systèmes que j'utilisais c'était clairement le cas. J'ai aussi mentionné le fait que depuis au moins un comportement de bash s'est amélioré de ce point de vue.

Si jamais je voulais mentionner un shell interactif de mauvaise qualité, ce n'est pas bash que je citerais, d'autant qu'il est largement suffisant pour la plupart des usages et plus simple à configurer que zsh.

A supposer que Ubuntu puisse se passer de Debian, pourquoi le fait il sans le faire vraiment? :))

Parce que tous les forks ne sont pas agressifs, et qu'il est plus simple de maintenir un fork qui reste le plus proche de l'upstream possible tout en gardant les spécificités sous forme de patchs, ce que le système de paquets de Debian permets relativement aisément.
À noter que c'est ce que fait Devuan également :)

https://wiki.ubuntu.com/MarkShuttleworth#Is_Ubuntu_a_Debian_fork.3F_Or_spoon.3F_What_sort_of_silverware_are_you.2C_man.3F

A lire quelques lignes au hasard, il semble que ma réponse soit un bon résumé :)

Mais je pense que pour répondre à la question «Ubuntu est-elle un fork de Debian?» il faut déjà définir ce qu'est un fork. Pour moi, un fork, c'est partir d'une base (de code source, de configurations, de documentation, peu importe) déjà existante et la modifier pour aller dans une direction qui n'est pas celle voulue par la base.
Ensuite, un fork peut devenir totalement décorellé de l'original, ou rester proche, re-fusionner ou contribuer, ce n'est pas important.

Du coup, selon ma définition, Ubuntu est totalement un fork de Debian, mais ce n'est pas un fork qui s'est fait dans le conflit, contrairement à Devuan. Iceweasel était un fork de Firefox, également, même si le code restait très proche de l'original et si je suis persuadé qu'ils ont reversé des patchs acceptés par l'upstream.

T'abuses, t'aurais pu mettre le lien qui va bien quand même.

À moins que ça ne soit un usage détourné du SOI pour faire auto-compléter par un autre de linuxfr?