Quand on sauvegarde avec un éditeur, il peut soit :
réécrire le fichier en place, mais s’il y a un problème au moment de l’écriture, le fichier peut être incohérent ;
écrire dans un nouveau fichier, puis une fois que celui-ci est complètement écrit sans erreur, remplacer l’ancien par lui.
Je pense que la grande majorité des éditeurs récents font le deuxième choix.
Si un éditeur fait le premier choix, le fichier sera changé en cours d’exécution par un interpréteur qui le lit ligne par ligne.
En éditant le fichier avec vi, j’obtiens le même comportement que cosmoff. Ce qui m’étonne, ce n’est pas tant que bash ligne le fichier ligne par ligne (il conserve des caractéristiques du Bourne shell, qui date d’une autre époque ; enfin c’est quand même déjà étonnant), que le fait qu’il ne verrouille même pas le fichier avec interdiction d’écriture pendant qu’il l’exécute !
Si un éditeur fait le deuxième choix, bash continue de lire le fchier d’origine (même s’il est supprimé du système de fichiers et plus visible dans le répertoire, il est maintenu tant qu’un processus le garde ouvert).
Si j’édite le fichier avec vim, l’exécution n’est pas modifiée.
Peut-être certaines distributions ont-elles un lien sur vim à la place de vi, et dans ce cas toujours le comportement comme si le fichier n’avait pas été modifié en cours d’exécution.
Cela dit, je n’avais jamais remarqué cette caractéristique de bash, probablement parce que j’évite d’utiliser vi (celui d’origine) et que je n’utilise probablement pas régulièrement autre chose qui ait le même comportement.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
L’heure romaine : le jour est divisé en douze heures du lever au coucher du soleil.
Je suppose que vous avez deviné le « truc » : les heures ne sont pas aussi longues en hiver qu’en été (ni la nuit que le jour)…
Comment ça, ce n’est pas pratique ? Ça n’a pas empêché les Romains de construire des monuments et des ponts qui ont résisté jusqu’à notre époque (y compris à des crues violentes), donc ça ne peut pas être si mauvais que ça.
Que restera‐t‐il de ce que nous faisons actuellement dans deux mille ans, à part de la pollution ?
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
La plupart des distributions actuelles fournissent une image live permettant de démarrer directement la distribution à partir d’une clé USB.
Le mieux, c’est d’en profiter pour les essayer, histoire de voir si ton matériel est bien supporté, si l’environnement graphique est lourd (en occupation mémoire et en réactivité) ou pas, si l’ergonomie de l’environnement te convient (au delà de leur environnement par défaut, plusieurs distributions fournissent des variantes live avec des environnements différents)…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Il n'y a pas d'équivalents à apt dans les distributions que tu cites ?
Si, mais en dehors des noms qui ne sont pas les mêmes, la syntaxe peut aussi être très différente.
Si on passe sur les noms de commande différents, pour installer un paquet d’un dépôt, c’est similaire (commande install nom_du_paquet) sur Debian/Ubuntu, Fedora et openSUSE (et pas du tout sur Arch Linux et Gentoo). Par contre, pour des opérations moins simples, c’est moins simple…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
J'ai essayé rapidement […] et ça ne passait pas, pour info.
Je viens d’essayer sur une Xubuntu 18.04.
Ça ne passe pas si on n’indique qu’un nom de paquet, mais ça passe si on indique un chemin (peut-être fait-il la différence sur la présence de la barre oblique), en tout cas sur Ubuntu.
Donc si l’on est dans le répertoire où l’on a téléchargé le fichier, apt install opera-stable….deb ne marchera pas, mais apt install ./opera-stable….deb marchera.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
La méthode dite "en ligne de commande" est universelle, ou tout du moins transposable sur toutes les versions de linux
Euh… ça m’étonnerait qu’elle fonctionne sur mon Arch Linux, ou sur Fedora, openSUSE, Gentoo, Void Linux… Peut-être faut-il prévenir leurs développeurs que ce ne sont pas des « versions de Linux ».
Cela dit, tu es sûrement de bon conseil : comme beaucoup de gens confondent Linux et Ubuntu, il y a de bonnes chances que Tapinabule ait une Ubuntu.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
il est possible qu'il existe des hooks pour apt qui permettraient ça…
Peut-être pas, je suis sûr qu’il y a une distribution qui permet d’installer indifféremment avec la même commande un paquet du dépôt ou local, mais je dois confondre avec Fedora. Je l’ai beaucoup utilisée, même si ce n’est plus le cas depuis quelques années.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
À ma connaissance, apt install ne peut installer qu'un logiciel provenant d'un des dépôts configurés dans /etc/apt/sources.list ou /etc/sources.list.d/mondepot.list (la page de manuel est floue sur le sujet, cela dit).
J’avais un doute… Il me semble l’avoir déjà fait, mais je peux me tromper. Pour être sûr, il faudrait essayer. Pour essayer, il faudrait avoir une Ubuntu ou une Debian sous la main, ce qui n’est pas le cas d’où j’écris (j’en ai au boulot, mais je n’y suis pas)…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Posté par Arthur Accroc .
En réponse au journal Mon retour sous KDE.
Évalué à 4.
Dernière modification le 13 février 2019 à 23:07.
D’après un de mes collègues qui l’a installée (je n’ai pour ma part essayé que la version live), elle utilise btrfs, fait un snapshot à chaque mise à jour, et permet de booter sur le snapshot précédent juste en le sélectionnant au démarrage.
Ça lève la petite incertitude, typique d’une mise à jour avec une distribution en rolling release comme Arch, d’un gros bug upstream qui empêcherait le démarrage sur ton matériel (c’est quand même rare, ça a dû m’arriver une fois en plusieurs années, un gros bug du pilote du noyau par rapport à ma puce graphique) et obligerait une intervention un peu difficile (démarrer en mode rescue voire sur une clé USB, downgrader le paquet fautif…).
D’un autre côté, ça demande sûrement plus de place disque et de faire du ménage sur btrfs (supprimer les vieux snapshots et certains trucs à faire de temps en temps sur btrfs dont je ne me rappelle plus) ; cela dit, sur Arch, il faut faire le ménage du cache de paquets.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Posté par Arthur Accroc .
En réponse au message Opera avec Mint.
Évalué à 8.
Dernière modification le 13 février 2019 à 22:40.
Bonjour,
J'ai trouvé sur des sites des liens de téléchargement "Opera pour Linux"
Il ne faut surtout pas suivre des liens sur des sites, c’est le meilleur moyen de récupérer un logiciel malveillant en sus ou une version compromise (diffuser une version compromise de navigateur pourrait permettre à des escrocs de récupérer des numéros de carte bleue).
Soit il est connu du gestionnaire de paquets de la distribution (je rejoins alouali sur le fait qu’il faudrait savoir laquelle c’est pour répondre précisément), dans ce cas le mieux est de l’utiliser pour l’installer.
Soit il faut le télécharger depuis le site officiel de l’éditeur, https://www.opera.com/. Et l’installer avec une commande du genre (sous Ubuntu, Linux Mint ou Debian ; sous openSUSE, Fedora ou autre, ça va être sensiblement moins facile, le fichier n’est pas au bon format pour elles) :
cd Téléchargements
sudo apt install opera-stable….deb
Après avoir tapé opera, enfoncer la touche Tab (celle juste à gauche de A) pour compléter le nom de fichier.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Tu retournes l'affaire là … le plombier chez lui sait très bien comment marche un réseau d'eau mais à autre chose à foutre que de jouer de la pince mutliple, pour se servir un verre d'eau, il ouvre simplement le robinet.
Avant d’emménager, il a le choix entre acheter une maison prête à habiter ou faire construire mais se charger lui-même de la plomberie.
Idem pour le mécano qui veut utiliser son véhicule pour faire ses courses, il ne va pas commencer par remonter la batterie, le carbu etc .. il a autre chose à faire il veut que son véhicule fonctionne simplement en mettant la clé dedans.
Pour se procurer une voiture, il a le choix d’en acheter une neuve, ou de restaurer lui-même un modèle de collection.
Peut-être ferais-tu le choix à leur place d’acheter une maison clés en main et une voiture neuve, mais ce n’est pas le choix de tous.
Mon père travaillait dans le bâtiment, il a construit sa maison lui-même avec l’aide d’amis.
C’est moins évident pour quelqu’un qui n’est pas de la partie, mais il y a des non professionnels qui entretiennent et réparent leur voiture eux-mêmes (probablement moins avec les voitures récentes, elles sont faites pour éviter ça…). J’ai même un ami qui n’est pas du bâtiment et qui a construit sa maison lui⁻même (il a mis beaucoup de temps pour la finir complètement…).
Se monter un Linux from scratch, ce n’est rien à côté de construire une maison. Et s’installer Arch Linux, encore moins.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
J'suis loin d'être débutant ou un "utilisateur de base" … Je suis un utilisateur plutôt expert mais pour autant, je n'ai aucune envie de me faire chier,on PC est un outil de travail et non pas la cible de mon travail. Je veux installer mon OS 5 minutes chrono en faisant next, next et next.
Du coup, tu te mets quand même en position d’utilisateur de base (du point de vue système). C’est pas honteux, hein ! On est tous utilisateur de base de quelque chose. On a le droit d’utiliser un robinet sans vouloir devenir plombier et on peut être pilote de course sans savoir démonter et remonter un moteur.
Mais du coup, Arch n’est pas le bon choix par rapport à tes attentes.
Je ne m’enlèverai jamais de l'idée qu'une rolling c'est nettement moins béton qu'une stable Debian, Ubuntu ou Mint
Peut-être. Par contre, quand on fait la mise à jour de version de distribution pas rolling, on a intérêt à avoir une sauvegarde !
J’ai vu assez souvent des mises à jour d’une version d’Ubuntu à la suivante bloquer au milieu et laisser le système complètement cassé (peut-être nettement moins avec les versions récentes qu’avec le passage de la 12.04 à la 14.04). Sans compter qu’une fois que ça marche, on se retrouve avec des plaisanteries comme des services qu’on n’avait sciemment pas installés ou activés dans l’ancienne et qui sont activés alors qu’ils ne sont pas configurés (par exemple, avec le passage de la 16.04 à la 18.04, systemd-timesyncd qui prend le pas sur ntpq qui était lui bien configuré).
Sous Fedora, avec l’ancien système de mise à jour de version, le blocage qui laissait le système tout cassé était encore bien plus fréquent que sous Ubuntu ; plus qu’un incident, c’était un grand classique. Avec le nouveau, il faut juste avoir beaucoup de place dans /var pour héberger tous les paquets qu’on avait installés sur l’ancienne (et faire un peu de nettoyage à la main à la fin), mais c’est beaucoup plus fiable.
Quoiqu’il en soit, c’est quand j’en ai eu marre d’essuyer les plâtres des mises à jour de version ou de réinstaller que je suis passé à Arch pour mon usage personnel. Non pas que ça fasse moins de problèmes à gérer, mais ils sont répartis dans le temps. Ça m’évite d’avoir à trouver un moment où j’aie beaucoup de temps disponible et pas trop besoin de l’ordinateur pour faire une mise à jour majeure.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Les distro classiques sont pas LTS, et des merdes j'en ai eu aussi un paquet avec. Les dernières exaspérations en date, c'est Fedora-KDE, une expérience horrible : une dizaine de bugs particulièrement pénibles rencontrés en 30 min, donc 5 côté KDE.
En même temps, choisir Fedora pour utiliser KDE, c’est comme aller à Marseille pour manger de la choucroute. Les développeurs de Fedora s’investissent sur Gnome, pas sur KDE.
Certains environnements privilégient la stabilité à la nouveauté et sont assez rarement cassés, quelque soit la distribution, mais pour Gnome et KDE, c’est mieux si les développeurs de la distribution sont prêts à passer du temps dessus.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Deux tentatives en plusieurs année, une fois une Arch, crash après une update … et récemment donc Manjaro dont j'étais super content, j'aime bien avoir tout up to date … jusqu'a un crash de l'environnement de bureau après une update également.
Principe de base d’une rolling-release : en suivant quasiment toutes les versions d’upstream, tu n’en rates quasiment aucun des bugs (à part bien sûr ceux qui sont détectés et corrigés avant les versions finales, heureusement)… Dans une distribution classique (non rolling), les logiciels n’ont pas forcément moins de bugs, mais ils ne changent pas.
Si tu ne fais rien, Arch conserve les paquets qui ont été installés dans le cache, afin de permettre de downgrader en cas de souci. Évidemment, si tu ne purges jamais (pacman -Sc), à un moment, ça pose un problème de place…
Mon conseil, c’est de purger le cache des paquets avant de faire la mise à jour (et surtout pas juste après).
En cas de souci après la mise à jour, tu sais que ça vient d’un des paquets qui sont en doublons et qu’il faut essayer de les downgrader en commençant par ceux qui semblent le plus liés au problème.
Toutefois sans sauvegarde de ton répertoire utilisateur, ça ne te met pas à l’abri d’un logiciel qui pourrit lui-même sa configuration…
Et puis quand c’est le noyau qui pose problème et ne démarre même pas (c’est rare, mais il arrive qu’un pilote devienne incompatible avec la version d’un de tes matériels), comme Arch ne conserve pas l’ancienne version, il faut être capable de démarrer sur le système live (celui qui sert pour l’installation), monter le système du disque, passer en chroot et downgrader le noyau.
Qui plus est, il faut vérifier sur le site qu’il n’y a pas de mise à jour délicate demandant une intervention ou au moins arriver à se débrouiller avec les problèmes signalés par pacman (il y a intérêt à en comprendre les messages ; mieux vaut vérifier sur le site).
En résumé, Arch et les distributions qui en sont dérivées demandent une certaine maîtrise ou un certain investissement pour acquérir celle-ci.
Avec la maîtrise suffisante, je pense qu’on peut espérer n’installer Arch qu’une seule fois pour toute la durée de vie d’une machine. Cela dit, la machine vieillissant, si on se retrouve dans une situation comme un chipset nVidia mal supporté par nouveau et plus par les dernières versions du pilote propriétaire, on peut devoir se rabattre une autre distribution, juste pour la présence du pilote souhaité.
Enfin bref, Arch n’est pas faite pour l’utilisateur de base qui veut juste un système qui fonctionne en trois clics. D’ailleurs, elle n’a plus d’installateur (officiel), ni graphique, ni même en mode texte (juste des instructions pour installer « à la main »), je pense que ça clarifie la situation… jusqu’à ce que des débutants installent une dérivée qui a un installateur graphique.
Quant à la fiabilité des autres distributions, y compris LTS, elle se discute aussi. Apparemment, sous Ubuntu 18.04 LTS, la LED Verr. Maj. ne fonctionne plus dans les consoles texte. Au boulot, on en a aussi deux, sur des portables de marques différentes, qui depuis peu gèlent quand l’écran se met en veille depuis peu (on n’a pas encore eu le temps de trouver si c’est un problème logiciel ou matériel).
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Si tu veux des logiciels à jours, quite à parfois tomber sur des bugs, je te conseille plutôt arch , et je te conseillerai plutôt l'installateur zen (mais il en existe d'autres)
Arch est ma distribution de prédilection, mais openSUSE Tumbleweed fait aussi l’affaire pour avoir des logiciels très à jour et elle est plus abordable pour des débutants.
Cela dit, merci de l’info sur l’existence d’installateurs graphiques pour Arch.
Le défaut d’openSUSE, c’est peut-être pour trouver de l’aide en français : elle semble boudée en France.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Posté par Arthur Accroc .
En réponse au journal Mon retour sous KDE.
Évalué à 6.
Dernière modification le 09 février 2019 à 06:40.
Une distribution qui a depuis longtemps un très bon support de KDE : openSUSE. C’est son environnement graphique par défaut, avec une intégration supérieure à la normale (par exemple, des applications comme Firefox et LibreOffice sont modifiées pour utiliser le dialogue de fichiers de KDE), et il y a des contributeurs à KDE parmi ses développeurs.
Depuis quelques années, elle a une déclinaison rolling release : openSUSE Tumbleweed.
Quand je l’ai essayée (la version Tumbleweed) l’année dernière pour voir si un portable tout récent supportait Linux (bien que la dernière Ubuntu gelait au démarrage dessus), j’ai plutôt eu une bonne surprise, notamment concernant son ergonomie. Malgré ma réticence pour KDE, si je devais choisir entre elle et l’environnement par défaut d’Ubuntu ou pire un Gnome 3 vanilla, il n’y aurait pas photo. Qui plus est, elle tournait parfaitement sur le fameux portable.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Je soupçonne le mode graphique des consoles texte Linux, dit « framebuffer ».
Quand il a été développé, l’utilisation courante de Linux était plutôt avec X11. Donc la performance n’a sûrement pas été une priorité par rapport à la simplicité, pour la compatibilité (ça doit fonctionner même avec un chip graphique non supporté, en mode VESA), la robustesse, le temps de développement…
À ce qu’il me semble, les *BSD utilisent toujours le mode texte des cartes graphiques pour leurs consoles, ce qui explique la rapidité.
Sous Linux aussi, il était bien plus rapide (au prix d’un affichage plus grossier avec assez peu de colonnes et de lignes de caractères).
Il a longtemps été possible de l’utiliser en ajoutant par exemple vga=80x25 aux paramètres du noyau Linux dans le gestionnaire de démarrage, mais je ne sais pas si ça l’est encore maintenant, à moins de ne pas utiliser X : les consoles sont plus étroitement liées au pilote graphique utilisé pour X.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Je viens de tomber sur un petit truc qui montre qu'il est compliqué de lécher l'expérience utilisateur.
Ça n’a peut-être pas bon goût, non plus. ☺
L'utilisateur inattentif appuie sur l'interrupteur pour allumer la machine dans tous les cas. Ayant choisi dans Plasma que cet évènement déclenche une suspension, cela le met en veille quand seulement l'écran était en veille.
Ce n’est pas mon réglage habituel (je préfère que ça m’affiche une fenêtre demandant quoi faire), mais j’ai essayé le même réglage que toi avec Xfce et XScreenSaver, et quand XScreenSaver s’est déclenché, l’appui sur le bouton réveille l’écran et ne déclenche pas la mise en veille (XScreenSaver l’intercepte manifestement). Par contre, même une fois l’écran rallumé, il ne semble pas y avoir moyen de la déclencher immédiatement sans déverrouiller d’abord.
Bon, programmer exactement le comportement que tu souhaites semble plus faisable avec un économiseur d’écran qui communique avec la gestion d’énergie, donc intégré à l’environnement (ce n’est pas le cas avec Xfce, qui ne fournit pas son propre économiseur d’écran). Bonne chance avec le rapport de bug pour Plasma.
Sinon, avant la mode actuelle de la disparition des touches des claviers, il y a eu celle qui consistait à leur ajouter des touches multimédia. Certains claviers ont ainsi une touche dédiée à la mise en veille. Il est possible aussi au niveau de beaucoup de BIOS de paramétrer si les prises USB sont actives en veille et si un appui sur le clavier réveille la machine. C’est plutôt pratique : la touche de mise en veille pour mettre en veille, toute autre touche pour réveiller ; directement au clavier, sans risque lié à un mauvais paramétrage du bouton de mise en route.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
C’est déjà bien d’avoir réussi à installer des distributions dessus : sur un modèle à peine plus vieux, ça coinçait à cause d’un UEFI 32 bits. La plupart des distributions ne supportent que l’UEFI 64 bits, parce que normalement les machines récentes sont en 64 bits avec un UEFI 64 bits aussi, et que les plus anciennes n’avaient pas d’UEFI.
C’était spécifique à ces ordinateurs bas de gamme de marque Thomson. Pour à peine quelques dizaines d’euros de plus, on trouvait un ordinateur d’une autre marque sans ces problèmes.
Je ne sais pas si les Thomson sont enfin passés à un UEFI 64 bits ou si ce sont les distributions qui ont ajouté le support de l’UEFI 32 bits. Mais dans le doute, j’éviterais d’en acheter.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
À noter que -m ne semble pas fonctionnel.
C’est -v qu’il faut utiliser pour limiter la mémoire.
Par exemple, pour limiter firefox à 2 Go de mémoire, le lancer avec un script contenant :
#!/bin/bashulimit -v 2097152exec firefox
À noter que Firefox se vautre très salement quand il atteint la limite de mémoire. Ça peut être gênant si c’est au moment où tu es en train de faire quelque chose d’important (vu que de nos jours, on fait de plus en plus de trucs depuis un navigateur)…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
La signature des paquets ne devrait‐elle pas protéger contre tout paquet illégitime ?
Si quelqu’un substitue un paquet signé par un paquet malveillant, à moins qu’il n’ait récupéré une clé publique de la distribution ou cassé l’algorithme de signature, son paquet ne peut pas avoir de signature valide.
Ou alors les paquets .deb ne seraient‐ils pas signés ?
J’avais pourtant cru comprendre avant qu’Arch mette en place la signature de ses paquets en 2012 qu’elle était en retard à ce sujet sur les distributions majeures.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Je souhaiterais passer sur LINUX. J'ai donc récupéré un vieil ordinateur portable HP "Pavilion N5311"pour tester LINUX. J'ai compris qu'il fallait une version très légère, je suis tombé sur LUBUNTU apparemment qui conviendrait, à priori.
Je ne connais pas spécialement ce modèle d’ordinateur. Il est vieux comment ? Notamment, combien a-t-il de mémoire, quel processeur a-t-il ?
Parce que s’il n’a qu’un processeur 32 bits (c’est à craindre si le BIOS ne permet pas de démarrer sur USB), la dernière Lubuntu ne fonctionnera pas dessus, elle n’est que 64 bits.
Le type de processeur, la quantité de mémoire, la taille du disque conditionneront la distribution Linux qu’on pourra éventuellement mettre dessus.
À part Debian, je ne sais pas s’il reste encore beaucoup de distributions Linux qui proposent encore une version 32 bits. À moins que ça n’ait changé, une Debian est par contre moins triviale à installer qu’une Ubuntu.
J'ai essayé avec un CD gravé avec une image ISO, mais ça ne marche pas non plus malgré le démarrage sur CD de l'ordinateur. Je penses que c'est à cause du MAC qui à gravé le CD ; peut-être une incompatibilité.
Il n’y a pas de raison que la machine qui a gravé cause une incompatibilité. Par contre, il faut absolument que l’image ISO soit gravée en brut sur le CD avec un logiciel qui permet cela et pas comme un fichier dans le système de fichiers du CD.
Il faut aussi que le BIOS du PC soit paramétré pour démarrer le CD avant le disque dur.
Peut-on ramener l'installation par USB dans WIndows et après lui demander de s'exécuter au démarrage ?
C’est peut-être possible, mais sûrement très complexe.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Ça dépend de l’éditeur
Posté par Arthur Accroc . En réponse au message impossible de modifier un exécutable lorsqu'il est en exécution . Évalué à 4.
Quand on sauvegarde avec un éditeur, il peut soit :
Je pense que la grande majorité des éditeurs récents font le deuxième choix.
Si un éditeur fait le premier choix, le fichier sera changé en cours d’exécution par un interpréteur qui le lit ligne par ligne.
En éditant le fichier avec vi, j’obtiens le même comportement que cosmoff. Ce qui m’étonne, ce n’est pas tant que bash ligne le fichier ligne par ligne (il conserve des caractéristiques du Bourne shell, qui date d’une autre époque ; enfin c’est quand même déjà étonnant), que le fait qu’il ne verrouille même pas le fichier avec interdiction d’écriture pendant qu’il l’exécute !
Si un éditeur fait le deuxième choix, bash continue de lire le fchier d’origine (même s’il est supprimé du système de fichiers et plus visible dans le répertoire, il est maintenu tant qu’un processus le garde ouvert).
Si j’édite le fichier avec vim, l’exécution n’est pas modifiée.
Peut-être certaines distributions ont-elles un lien sur vim à la place de vi, et dans ce cas toujours le comportement comme si le fichier n’avait pas été modifié en cours d’exécution.
Cela dit, je n’avais jamais remarqué cette caractéristique de bash, probablement parce que j’évite d’utiliser vi (celui d’origine) et que je n’utilise probablement pas régulièrement autre chose qui ait le même comportement.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
# L’heure romaine
Posté par Arthur Accroc . En réponse au journal [HS] Etes-vous pour rester à l'heure d'été ou à l'heure d'hiver ?. Évalué à 4.
L’heure romaine : le jour est divisé en douze heures du lever au coucher du soleil.
Je suppose que vous avez deviné le « truc » : les heures ne sont pas aussi longues en hiver qu’en été (ni la nuit que le jour)…
Comment ça, ce n’est pas pratique ? Ça n’a pas empêché les Romains de construire des monuments et des ponts qui ont résisté jusqu’à notre époque (y compris à des crues violentes), donc ça ne peut pas être si mauvais que ça.
Que restera‐t‐il de ce que nous faisons actuellement dans deux mille ans, à part de la pollution ?
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
# Il faut essayer !
Posté par Arthur Accroc . En réponse au message choix d'un linux. Évalué à 3.
Bonjour,
La plupart des distributions actuelles fournissent une image live permettant de démarrer directement la distribution à partir d’une clé USB.
Le mieux, c’est d’en profiter pour les essayer, histoire de voir si ton matériel est bien supporté, si l’environnement graphique est lourd (en occupation mémoire et en réactivité) ou pas, si l’ergonomie de l’environnement te convient (au delà de leur environnement par défaut, plusieurs distributions fournissent des variantes live avec des environnements différents)…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Linux, c’est pas pareil
Posté par Arthur Accroc . En réponse au message Opera avec Mint. Évalué à 3.
Salut Julien_J06,
Si, mais en dehors des noms qui ne sont pas les mêmes, la syntaxe peut aussi être très différente.
Si on passe sur les noms de commande différents, pour installer un paquet d’un dépôt, c’est similaire (commande install nom_du_paquet) sur Debian/Ubuntu, Fedora et openSUSE (et pas du tout sur Arch Linux et Gentoo). Par contre, pour des opérations moins simples, c’est moins simple…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # apt install ./opera-stable….deb
Posté par Arthur Accroc . En réponse au message Opera avec Mint. Évalué à 3.
Je viens d’essayer sur une Xubuntu 18.04.
Ça ne passe pas si on n’indique qu’un nom de paquet, mais ça passe si on indique un chemin (peut-être fait-il la différence sur la présence de la barre oblique), en tout cas sur Ubuntu.
Donc si l’on est dans le répertoire où l’on a téléchargé le fichier,
apt install opera-stable….debne marchera pas, maisapt install ./opera-stable….debmarchera.« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Linux or not Linux ?
Posté par Arthur Accroc . En réponse au message Opera avec Mint. Évalué à 2.
Euh… ça m’étonnerait qu’elle fonctionne sur mon Arch Linux, ou sur Fedora, openSUSE, Gentoo, Void Linux… Peut-être faut-il prévenir leurs développeurs que ce ne sont pas des « versions de Linux ».
Cela dit, tu es sûrement de bon conseil : comme beaucoup de gens confondent Linux et Ubuntu, il y a de bonnes chances que Tapinabule ait une Ubuntu.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Il faudrait essayer…
Posté par Arthur Accroc . En réponse au message Opera avec Mint. Évalué à 2.
Peut-être pas, je suis sûr qu’il y a une distribution qui permet d’installer indifféremment avec la même commande un paquet du dépôt ou local, mais je dois confondre avec Fedora. Je l’ai beaucoup utilisée, même si ce n’est plus le cas depuis quelques années.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Il faudrait essayer…
Posté par Arthur Accroc . En réponse au message Opera avec Mint. Évalué à 2.
J’avais un doute… Il me semble l’avoir déjà fait, mais je peux me tromper. Pour être sûr, il faudrait essayer. Pour essayer, il faudrait avoir une Ubuntu ou une Debian sous la main, ce qui n’est pas le cas d’où j’écris (j’en ai au boulot, mais je n’y suis pas)…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Une rolling release… sans le risque de se retrouver bloqué au démarrage
Posté par Arthur Accroc . En réponse au journal Mon retour sous KDE. Évalué à 4. Dernière modification le 13 février 2019 à 23:07.
D’après un de mes collègues qui l’a installée (je n’ai pour ma part essayé que la version live), elle utilise btrfs, fait un snapshot à chaque mise à jour, et permet de booter sur le snapshot précédent juste en le sélectionnant au démarrage.
Ça lève la petite incertitude, typique d’une mise à jour avec une distribution en rolling release comme Arch, d’un gros bug upstream qui empêcherait le démarrage sur ton matériel (c’est quand même rare, ça a dû m’arriver une fois en plusieurs années, un gros bug du pilote du noyau par rapport à ma puce graphique) et obligerait une intervention un peu difficile (démarrer en mode rescue voire sur une clé USB, downgrader le paquet fautif…).
D’un autre côté, ça demande sûrement plus de place disque et de faire du ménage sur btrfs (supprimer les vieux snapshots et certains trucs à faire de temps en temps sur btrfs dont je ne me rappelle plus) ; cela dit, sur Arch, il faut faire le ménage du cache de paquets.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
# Attention !
Posté par Arthur Accroc . En réponse au message Opera avec Mint. Évalué à 8. Dernière modification le 13 février 2019 à 22:40.
Bonjour,
Il ne faut surtout pas suivre des liens sur des sites, c’est le meilleur moyen de récupérer un logiciel malveillant en sus ou une version compromise (diffuser une version compromise de navigateur pourrait permettre à des escrocs de récupérer des numéros de carte bleue).
Soit il est connu du gestionnaire de paquets de la distribution (je rejoins alouali sur le fait qu’il faudrait savoir laquelle c’est pour répondre précisément), dans ce cas le mieux est de l’utiliser pour l’installer.
Soit il faut le télécharger depuis le site officiel de l’éditeur, https://www.opera.com/. Et l’installer avec une commande du genre (sous Ubuntu, Linux Mint ou Debian ; sous openSUSE, Fedora ou autre, ça va être sensiblement moins facile, le fichier n’est pas au bon format pour elles) :
Après avoir tapé opera, enfoncer la touche Tab (celle juste à gauche de A) pour compléter le nom de fichier.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Question de choix
Posté par Arthur Accroc . En réponse au journal Mon retour sous KDE. Évalué à 4.
Avant d’emménager, il a le choix entre acheter une maison prête à habiter ou faire construire mais se charger lui-même de la plomberie.
Pour se procurer une voiture, il a le choix d’en acheter une neuve, ou de restaurer lui-même un modèle de collection.
Peut-être ferais-tu le choix à leur place d’acheter une maison clés en main et une voiture neuve, mais ce n’est pas le choix de tous.
Mon père travaillait dans le bâtiment, il a construit sa maison lui-même avec l’aide d’amis.
C’est moins évident pour quelqu’un qui n’est pas de la partie, mais il y a des non professionnels qui entretiennent et réparent leur voiture eux-mêmes (probablement moins avec les voitures récentes, elles sont faites pour éviter ça…). J’ai même un ami qui n’est pas du bâtiment et qui a construit sa maison lui⁻même (il a mis beaucoup de temps pour la finir complètement…).
Se monter un Linux from scratch, ce n’est rien à côté de construire une maison. Et s’installer Arch Linux, encore moins.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Rolling ou pas
Posté par Arthur Accroc . En réponse au journal Mon retour sous KDE. Évalué à 3.
Du coup, tu te mets quand même en position d’utilisateur de base (du point de vue système). C’est pas honteux, hein ! On est tous utilisateur de base de quelque chose. On a le droit d’utiliser un robinet sans vouloir devenir plombier et on peut être pilote de course sans savoir démonter et remonter un moteur.
Mais du coup, Arch n’est pas le bon choix par rapport à tes attentes.
Peut-être. Par contre, quand on fait la mise à jour de version de distribution pas rolling, on a intérêt à avoir une sauvegarde !
J’ai vu assez souvent des mises à jour d’une version d’Ubuntu à la suivante bloquer au milieu et laisser le système complètement cassé (peut-être nettement moins avec les versions récentes qu’avec le passage de la 12.04 à la 14.04). Sans compter qu’une fois que ça marche, on se retrouve avec des plaisanteries comme des services qu’on n’avait sciemment pas installés ou activés dans l’ancienne et qui sont activés alors qu’ils ne sont pas configurés (par exemple, avec le passage de la 16.04 à la 18.04, systemd-timesyncd qui prend le pas sur ntpq qui était lui bien configuré).
Sous Fedora, avec l’ancien système de mise à jour de version, le blocage qui laissait le système tout cassé était encore bien plus fréquent que sous Ubuntu ; plus qu’un incident, c’était un grand classique. Avec le nouveau, il faut juste avoir beaucoup de place dans /var pour héberger tous les paquets qu’on avait installés sur l’ancienne (et faire un peu de nettoyage à la main à la fin), mais c’est beaucoup plus fiable.
Quoiqu’il en soit, c’est quand j’en ai eu marre d’essuyer les plâtres des mises à jour de version ou de réinstaller que je suis passé à Arch pour mon usage personnel. Non pas que ça fasse moins de problèmes à gérer, mais ils sont répartis dans le temps. Ça m’évite d’avoir à trouver un moment où j’aie beaucoup de temps disponible et pas trop besoin de l’ordinateur pour faire une mise à jour majeure.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Le rapport avec la choucroute
Posté par Arthur Accroc . En réponse au journal Mon retour sous KDE. Évalué à 2.
En même temps, choisir Fedora pour utiliser KDE, c’est comme aller à Marseille pour manger de la choucroute. Les développeurs de Fedora s’investissent sur Gnome, pas sur KDE.
Certains environnements privilégient la stabilité à la nouveauté et sont assez rarement cassés, quelque soit la distribution, mais pour Gnome et KDE, c’est mieux si les développeurs de la distribution sont prêts à passer du temps dessus.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Arch et dérivées
Posté par Arthur Accroc . En réponse au journal Mon retour sous KDE. Évalué à 4.
Principe de base d’une rolling-release : en suivant quasiment toutes les versions d’upstream, tu n’en rates quasiment aucun des bugs (à part bien sûr ceux qui sont détectés et corrigés avant les versions finales, heureusement)… Dans une distribution classique (non rolling), les logiciels n’ont pas forcément moins de bugs, mais ils ne changent pas.
Si tu ne fais rien, Arch conserve les paquets qui ont été installés dans le cache, afin de permettre de downgrader en cas de souci. Évidemment, si tu ne purges jamais (pacman -Sc), à un moment, ça pose un problème de place…
Mon conseil, c’est de purger le cache des paquets avant de faire la mise à jour (et surtout pas juste après).
En cas de souci après la mise à jour, tu sais que ça vient d’un des paquets qui sont en doublons et qu’il faut essayer de les downgrader en commençant par ceux qui semblent le plus liés au problème.
Toutefois sans sauvegarde de ton répertoire utilisateur, ça ne te met pas à l’abri d’un logiciel qui pourrit lui-même sa configuration…
Et puis quand c’est le noyau qui pose problème et ne démarre même pas (c’est rare, mais il arrive qu’un pilote devienne incompatible avec la version d’un de tes matériels), comme Arch ne conserve pas l’ancienne version, il faut être capable de démarrer sur le système live (celui qui sert pour l’installation), monter le système du disque, passer en chroot et downgrader le noyau.
Qui plus est, il faut vérifier sur le site qu’il n’y a pas de mise à jour délicate demandant une intervention ou au moins arriver à se débrouiller avec les problèmes signalés par pacman (il y a intérêt à en comprendre les messages ; mieux vaut vérifier sur le site).
En résumé, Arch et les distributions qui en sont dérivées demandent une certaine maîtrise ou un certain investissement pour acquérir celle-ci.
Avec la maîtrise suffisante, je pense qu’on peut espérer n’installer Arch qu’une seule fois pour toute la durée de vie d’une machine. Cela dit, la machine vieillissant, si on se retrouve dans une situation comme un chipset nVidia mal supporté par nouveau et plus par les dernières versions du pilote propriétaire, on peut devoir se rabattre une autre distribution, juste pour la présence du pilote souhaité.
Enfin bref, Arch n’est pas faite pour l’utilisateur de base qui veut juste un système qui fonctionne en trois clics. D’ailleurs, elle n’a plus d’installateur (officiel), ni graphique, ni même en mode texte (juste des instructions pour installer « à la main »), je pense que ça clarifie la situation… jusqu’à ce que des débutants installent une dérivée qui a un installateur graphique.
Quant à la fiabilité des autres distributions, y compris LTS, elle se discute aussi. Apparemment, sous Ubuntu 18.04 LTS, la LED Verr. Maj. ne fonctionne plus dans les consoles texte. Au boulot, on en a aussi deux, sur des portables de marques différentes, qui depuis peu gèlent quand l’écran se met en veille depuis peu (on n’a pas encore eu le temps de trouver si c’est un problème logiciel ou matériel).
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: on est vendredi
Posté par Arthur Accroc . En réponse au message Linux sous Windows (non fonctionnel). Évalué à 1.
Arch est ma distribution de prédilection, mais openSUSE Tumbleweed fait aussi l’affaire pour avoir des logiciels très à jour et elle est plus abordable pour des débutants.
Cela dit, merci de l’info sur l’existence d’installateurs graphiques pour Arch.
Le défaut d’openSUSE, c’est peut-être pour trouver de l’aide en français : elle semble boudée en France.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # KDE… rolling release…
Posté par Arthur Accroc . En réponse au journal Mon retour sous KDE. Évalué à 6. Dernière modification le 09 février 2019 à 06:40.
Une distribution qui a depuis longtemps un très bon support de KDE : openSUSE. C’est son environnement graphique par défaut, avec une intégration supérieure à la normale (par exemple, des applications comme Firefox et LibreOffice sont modifiées pour utiliser le dialogue de fichiers de KDE), et il y a des contributeurs à KDE parmi ses développeurs.
Depuis quelques années, elle a une déclinaison rolling release : openSUSE Tumbleweed.
Quand je l’ai essayée (la version Tumbleweed) l’année dernière pour voir si un portable tout récent supportait Linux (bien que la dernière Ubuntu gelait au démarrage dessus), j’ai plutôt eu une bonne surprise, notamment concernant son ergonomie. Malgré ma réticence pour KDE, si je devais choisir entre elle et l’environnement par défaut d’Ubuntu ou pire un Gnome 3 vanilla, il n’y aurait pas photo. Qui plus est, elle tournait parfaitement sur le fameux portable.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
# Framebuffer
Posté par Arthur Accroc . En réponse au message Lenteurs terminal. Évalué à 2.
Je soupçonne le mode graphique des consoles texte Linux, dit « framebuffer ».
Quand il a été développé, l’utilisation courante de Linux était plutôt avec X11. Donc la performance n’a sûrement pas été une priorité par rapport à la simplicité, pour la compatibilité (ça doit fonctionner même avec un chip graphique non supporté, en mode VESA), la robustesse, le temps de développement…
À ce qu’il me semble, les *BSD utilisent toujours le mode texte des cartes graphiques pour leurs consoles, ce qui explique la rapidité.
Sous Linux aussi, il était bien plus rapide (au prix d’un affichage plus grossier avec assez peu de colonnes et de lignes de caractères).
Il a longtemps été possible de l’utiliser en ajoutant par exemple vga=80x25 aux paramètres du noyau Linux dans le gestionnaire de démarrage, mais je ne sais pas si ça l’est encore maintenant, à moins de ne pas utiliser X : les consoles sont plus étroitement liées au pilote graphique utilisé pour X.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
# Avec Xfce et XScreenSaver
Posté par Arthur Accroc . En réponse au journal Petits détails du quotidien. Évalué à 2.
Ça n’a peut-être pas bon goût, non plus. ☺
Ce n’est pas mon réglage habituel (je préfère que ça m’affiche une fenêtre demandant quoi faire), mais j’ai essayé le même réglage que toi avec Xfce et XScreenSaver, et quand XScreenSaver s’est déclenché, l’appui sur le bouton réveille l’écran et ne déclenche pas la mise en veille (XScreenSaver l’intercepte manifestement). Par contre, même une fois l’écran rallumé, il ne semble pas y avoir moyen de la déclencher immédiatement sans déverrouiller d’abord.
Bon, programmer exactement le comportement que tu souhaites semble plus faisable avec un économiseur d’écran qui communique avec la gestion d’énergie, donc intégré à l’environnement (ce n’est pas le cas avec Xfce, qui ne fournit pas son propre économiseur d’écran). Bonne chance avec le rapport de bug pour Plasma.
Sinon, avant la mode actuelle de la disparition des touches des claviers, il y a eu celle qui consistait à leur ajouter des touches multimédia. Certains claviers ont ainsi une touche dédiée à la mise en veille. Il est possible aussi au niveau de beaucoup de BIOS de paramétrer si les prises USB sont actives en veille et si un appui sur le clavier réveille la machine. C’est plutôt pratique : la touche de mise en veille pour mettre en veille, toute autre touche pour réveiller ; directement au clavier, sans risque lié à un mauvais paramétrage du bouton de mise en route.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Thomson, pas un cadeau
Posté par Arthur Accroc . En réponse au lien Endless OS simple rapide convivial pour remplacer Windows sur un PC THOMSON Neo avec processeur ATOM. Évalué à 4.
C’est déjà bien d’avoir réussi à installer des distributions dessus : sur un modèle à peine plus vieux, ça coinçait à cause d’un UEFI 32 bits. La plupart des distributions ne supportent que l’UEFI 64 bits, parce que normalement les machines récentes sont en 64 bits avec un UEFI 64 bits aussi, et que les plus anciennes n’avaient pas d’UEFI.
C’était spécifique à ces ordinateurs bas de gamme de marque Thomson. Pour à peine quelques dizaines d’euros de plus, on trouvait un ordinateur d’une autre marque sans ces problèmes.
Je ne sais pas si les Thomson sont enfin passés à un UEFI 64 bits ou si ce sont les distributions qui ont ajouté le support de l’UEFI 32 bits. Mais dans le doute, j’éviterais d’en acheter.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Tutoiement
Posté par Arthur Accroc . En réponse au journal En Francilie, on aime les oignons !. Évalué à 3.
La salle est toute petite, il ne veut qu’un seul gen…
→🚪
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
# À l’ancienne
Posté par Arthur Accroc . En réponse au message "Unresponsive script" : limiter Firefox. Évalué à 3.
man bash
/ulimit
À noter que -m ne semble pas fonctionnel.
C’est -v qu’il faut utiliser pour limiter la mémoire.
Par exemple, pour limiter firefox à 2 Go de mémoire, le lancer avec un script contenant :
À noter que Firefox se vautre très salement quand il atteint la limite de mémoire. Ça peut être gênant si c’est au moment où tu es en train de faire quelque chose d’important (vu que de nos jours, on fait de plus en plus de trucs depuis un navigateur)…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
# Signature des paquets ???
Posté par Arthur Accroc . En réponse au lien Un méchant bug de sécurité identifié et corrigé dans Linux apt. Évalué à 4.
La signature des paquets ne devrait‐elle pas protéger contre tout paquet illégitime ?
Si quelqu’un substitue un paquet signé par un paquet malveillant, à moins qu’il n’ait récupéré une clé publique de la distribution ou cassé l’algorithme de signature, son paquet ne peut pas avoir de signature valide.
Ou alors les paquets .deb ne seraient‐ils pas signés ?
J’avais pourtant cru comprendre avant qu’Arch mette en place la signature de ses paquets en 2012 qu’elle était en retard à ce sujet sur les distributions majeures.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Clé USB amorçable
Posté par Arthur Accroc . En réponse au message Installation .uefi. Évalué à 2.
Sur la façon de créer depuis Windows une clé USB amorçable, il y a par exemple une indication là.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
# Contenu de la clé USB
Posté par Arthur Accroc . En réponse au message Installation .uefi. Évalué à 5. Dernière modification le 16 janvier 2019 à 00:43.
Bonjour,
Le plus probable, c’est qu’elle n’est pas préparée comme il faut.
Il faut une distribution qui fournit une image bootable depuis une clé USB, y compris en UEFI. Laquelle essaies-tu ?
Il faut bien que cette image soit copiée en brut sur la clé USB et pas juste comme un fichier sur le système de fichiers existant de la clé.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
# Demande de précisions, quelques réponses
Posté par Arthur Accroc . En réponse au message Je n'arrive pas à installer LUBUNTU sur un vieux ordinateur. Évalué à 3.
Je ne connais pas spécialement ce modèle d’ordinateur. Il est vieux comment ? Notamment, combien a-t-il de mémoire, quel processeur a-t-il ?
Parce que s’il n’a qu’un processeur 32 bits (c’est à craindre si le BIOS ne permet pas de démarrer sur USB), la dernière Lubuntu ne fonctionnera pas dessus, elle n’est que 64 bits.
Le type de processeur, la quantité de mémoire, la taille du disque conditionneront la distribution Linux qu’on pourra éventuellement mettre dessus.
À part Debian, je ne sais pas s’il reste encore beaucoup de distributions Linux qui proposent encore une version 32 bits. À moins que ça n’ait changé, une Debian est par contre moins triviale à installer qu’une Ubuntu.
Il n’y a pas de raison que la machine qui a gravé cause une incompatibilité. Par contre, il faut absolument que l’image ISO soit gravée en brut sur le CD avec un logiciel qui permet cela et pas comme un fichier dans le système de fichiers du CD.
Il faut aussi que le BIOS du PC soit paramétré pour démarrer le CD avant le disque dur.
C’est peut-être possible, mais sûrement très complexe.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone