dd (Disk Dub) a quand même plusieurs utilités. Sa fonction principale (et originelle) sert bien à dupliquer des disques, mais il propose bien plus d'options que le simple bs.
Si spécifier la taille d'un bloc paraît inutile, c'est justement parce que cela fait double emploi avec la couche « périphérique bloc » du système d'exploitation, qui est censée lisser tout cela et nous permettre d'y accéder comme à un flux ordinaire. Par contre, quand on utilisait des raw devices, il était nécessaire de faire des accès atomiques de la taille d'un secteur et, par conséquent, alignés sur eux (pas question de copier deux demi-secteurs consécutifs, par exemple). Et là, il est quasiment impossible de manipuler sérieusement un volume sans recourir à ce genre d'outils.
En outre, dd propose ibs et obs qui permettent de spécifier une taille de bloc différente en entrée et en sortie. Utile pour le genre de périphérique, ou pour balancer des données à travers des sockets qui exigent des trames de taille fixe.
Dernier point mais non des moindres : il existe l'option noerror qui permet de continuer le traitement même en cas d'erreurs de lecture qui, sur un disque, correspondraient à des secteurs défectueux. C'est quand même un gros avantage sur cp qui, par ailleurs, n'est pas fait pour être interrompu. dd a le bon goût d'indiquer où il en est quand on le stoppe prématurément.
Du coup, il vaut mieux ne pas spécifier comme taille de bloc celle du volume entier car, à la moindre erreur, c'est justement le reste « du volume entier » qui est passé ou rempli avec des zéros. En ce sens, il est plus intéressant de choisir comme taille de bloc celle d'un secteur ou d'un bloc du système de fichier (généralement 4096 octets) et ensuite de la multiplier par un certain facteur pour profiter de la RAM disponible et limiter les appels système, mais en restant raisonnable pour les raisons évoquées. Un bloc de la taille d'une piste est généralement un bon compromis.
Au contraire, chez moi, ça fait bien longtemps que ça marche et que je n'ai plus eu à avoir recours à un câble croisé. En fait, il suffit qu'un seul des points de terminaison soit capable de se « retourner ». Et généralement, à moins d'avoir un produit d'entrée de gamme, les puces Ethernet des cartes-mères sont capables de le faire seul.
Si, effectivement. Je ne connaissais pas la variable $BASH_COMMAND.
Tu peux décomposer le contenu de cette variable en un tableau et vérifier si l'un des éléments est une étoile seule (ou à la limite une suite d'étoiles, exclusivement).
Est-ce qu'il n'y a pas une astuce pour demander confirmation lorsque l'on tape par erreur "rm *" ?
Sous bash, la pratique habituelle (et généralement configurée par les distributions elles-mêmes) consiste à définir un alias avec alias rm=rm -i puis à utiliser « rm -ffichiers » quand on « sait ce que l'on fait ».
Une autre astuce consiste à déclarer « rm » (ou n'importe quoi d'autre) comme une fonction sous Bash pour pouvoir contrôler son comportement plus finement en fonction des paramètres, avant de rappeler l'exécutable original.
Il n'y a malheureusement pas d'option pour vérifier si on tape « * » en particulier car ce caractère est développé par le shell lui-même en la liste des fichiers du répertoire courant, et ce AVANT d'appeler l'exécutable ou la fonction. Ceux-ci n'ont alors aucun moyen de savoir si c'est un caractère joker qui a généré cette liste ou si l'utilisateur les a tous spécifiés expressément.
la connexion met plusieurs minutes à s'établir (auparavant c'était moins de 10 secondes environ).
Ça, c'est généralement caractéristique d'un timeout. Ton logiciel doit chercher à se connecter à un serveur tiers qui, lui, ne doit plus répondre depuis le début de la panne et il faut attendre le délai de grâce avant que le logiciel décide d'abandonner et de passer à la solution de secours, qui peut être soit un serveur secondaire, soit des informations conservées en cache.
Ça arrive également quand c'est le DNS qui ne répond plus : toutes les connexions directement basées sur les adresses des hôtes à atteindre fonctionnent mais tout ce qui utilise un nom de domaine se met à rester plusieurs minutes en attente. Et comme cela peut être transparent pour l'utilisateur ou se trouver à un niveau très bas, il peut être parfois assez difficile d'identifier la source du problème.
Ça peut enfin se produire même si le serveur ne répondait déjà plus mais retournait quand même un refus de connexion explicite. S'il se décide à faire la carpe à la place, soit parce qu'il a réellement été éteint ou mis hors ligne, soit parce qu'un firewall trop zélé a décidé de filtrer l'ICMP, ça peut aussi engendrer les mêmes effets du jour au lendemain.
le mot de passe m'est systématiquement demandé (alors que je l'avais précédemment enregistré) et même si je l'enregistre pour toujours.
Possible qu'il s'agisse de la même cause. Si le serveur n'est plus le même, le certificat ne sera plus valide non plus.
Une autre chose qu'il m'est arrivé, notamment avec Evolution : lorsque le serveur retournait un « Internal Error » lors d'une connexion, le logiciel ne comprenait pas le code d'erreur. Il retombait donc sur le comportement « Connexion Refusée » standard et côté interface utilisateur, il me redemandait mon mot de passe en boucle, et ce pour chacune des boîtes situées sur le même serveur. :-\
N'hésite pas à poser tes questions ici dans programmation.autre, par exemple. Histoire de mettre facilement le pied à l'étrier (par exemple : voir d'emblée ce qu'est l'index/staging area).
Autre technique intéressante : rapatrier avec Git un projet d'envergure déjà existant (le noyau Linux en étant bien sûr l'archétype, mais on peut faire moins gros), non pas pour y travailler, mais pour se faire la main en conditions réelles. C'est plus facile de voir à quoi servent les branches, les reflogs et toutes les fonctionnalités qui ont émaillé l'outil au fil du temps en explorant un dépôt bien fourni qu'en faisant des cas d'école sur un répertoire qui ne contient qu'une demi-douzaine de commits.
Enfin, n'hésite pas à choisir un client pour Git. Personnellement, j'utilise « tig » mais il en existe pléthore. C'est plus facile de se balader dans un dépôt avec ce genre d'outil qu'en utilisant simplement git log --graph
Tu as l'air d'avoir bien résumé la situation toi-même et d'avoir une vision assez précise de la chose. Il serait dommage de ne pas en profiter pour franchir le pas et approfondir le tout, en effet…
Que me conseillez-vous pour partager mes projets? Dois-je me mettre à Git? Avez-vous d'autres solutions?
Je dirais plutôt que, vu la situation, c'est « une bonne occasion de se mettre à Git ».
Plus précisément, Git est aujourd'hui aussi populaire que répandu, mais il rebute parfois un peu les néophytes comme les habitués d'autres SCM. Une fois qu'on a compris le principe général, le tout devient somme toutes assez simple mais le mieux reste quand même de se le faire expliquer par quelqu'un qui connaît bien l'outil lorsque l'on fait ses premiers pas. Après, on peut pratiquement tout utiliser sans difficulté notoire.
Sache aussi qu'il est très intéressant d'utiliser un logiciel de versioning même lorsque l'on travaille seul (et pas simplement pour le code). Ça permet de conserver automatiquement la trace des différentes versions de ce que l'on écrit sans se soucier de les classer explicitement, ça permet de revenir facilement en arrière, ça permet de forker quand on veut démarrer un nouveau projet similaire à un autre et, in fine, ça permet de partager automatiquement son travail une fois que l'on a atteint un stade intéressant pour son entourage.
C'est aussi très intéressant pour conserver un code toujours propre : en général, il est facile d'ajouter des lignes de code à un fichier existant mais il est plus difficile de prendre la décision de supprimer des blocs lorsqu'ils ont demandé du travail pour être mis au point. En général, ils finissent en commentaires jusqu'à ce qu'ils soient suffisamment vieux pour être effacés… à condition qu'on ait pensé à écrire la date dans le commentaire en question. S'appuyer sur un SCM quand on développe permet d'effacer immédiatement ce qui ne sert à rien car non seulement rien n'est définitivement perdu, mais parce qu'il est très facile de les retrouver et même les mettre en évidence à l'aide d'un diff entre deux révisions.
Et si malgré ça rien ne te séduit, tu peux quand même faire un « git init » dans ton répertoire de travail, ajouter tout ton travail dans un seul gros commit initial sans rien d'autre, et t'en servir pour le partager sur une forge officielle.
GRUB est le « loader » qui te permet de lancer soit ton système Linux dans différents mode ou en choisissant ton noyau, soit de lancer d'autres systèmes d'exploitation. Mais en principe, il est aujourd'hui configuré pour présenter un menu explicite. Si tu vois uniquement la ligne de commande, c'est que soit ta distribution est minimaliste, soit l'installation n'a pas pu aller jusqu'à son terme.
Essaie d'appuyer simplement sur « Entrée » quand tu vois ce message, pour voir s'il démarre normalement.
Ce que tu décris n'a rien à voir avec chroot en particulier : tu peux monter les partitions de n'importe quel disque dur depuis un système opérationnel, fût-ce un Live CD, sans avoir à recourir à chroot en particulier. Et le plus beau : tu peux très bien monter les partitions d'un Windows quelconque depuis un système Linux, Live CD ou non, et les modifier à loisir. Et pas seulement les fichiers des utilisateurs : tu peux modifier le système, la base de registres, etc. voir réinstaller un système entier si ça te chante. En principe, c'est vrai dans l'autre sens aussi, à ceci près que Windows n'est généralement pas fait pour et ne propose pas d'outil a priori pour le faire. Il faut s'équiper.
C'est donc tout-à-fait normal en soi et heureusement qu'on peut le faire, car c'est également de cette façon qu'on dépanne les systèmes qui ne démarrent plus.
Par ailleurs, un disque dur est un support de stockage. Ce n'est pas un coffre-fort. Il n'a donc pas vocation à dissimuler son contenu a priori non plus. Au contraire, il doit en garantir l'accessibilité, la disponibilité et l'intégrité pendant toute sa durée de vie (laquelle devrait être théoriquement infinie car les particuliers établissent rarement des plans de migration).
Si tu veux protéger tes données, il faut mettre en place un dispositif de sécurité explicite et identifié à l'avance : soit tu mets physiquement un cadenas sur le boîtier de ta machine et tu paramètres ton BIOS/UEFI pour ne pas démarrer par défaut sur les lecteurs externes (certains boîtiers sont spécialement équipés pour qu'on puisse le faire), soit tu utilises un fichier ou une partition chiffrée pour y déposer les informations réellement confidentielles (voir https://linuxfr.org/forums/linux-general/posts/chiffrer-disque-avec-cles-de-chiffrement-stockee-sur-peripherique-amovible ).
L'objectif serait de pouvoir traduire les textes de lois en programmes écrit avec ce langage.
Pas bête. On appellerait ça une compilation !
On pourrait se baser sur le XML comme méta-langage et utiliser XSLT pour faire des transpositions en droit européen. :-)
Il serai possible de faire des simulations en envoyant des paramètres en entrée dans une loi et voir ce qui en sort.
Ce qui serait surtout génial, c'est de pouvoir faire des sandboxes, pour que nos chers politiques puissent s'amuser à loisir sans que ce soit automatiquement au dépens de la population…
L'idée m'est venue lorsque j'ai tenté de déchiffrer la loi sur les copropriétés pour savoir ce que j'avais le droit de faire sans passer par un avocat spécialiste.
Avec la transcription des lois en programme on pourrai faire des espèces de test unitaire pour vérifier qu'une loi n'en casse pas une autre.
Les modifications d'une loi précédente deviendrai des patch.
Sur le premier lien, même si le projet est encore incomplet, il est intéressant de constater à quel point des siècles de révision de la loi et de maintien monacal de ses textes pourrait se comparer à un projet communautaire de relativement petite envergure comme il en existe des milliers sur les forges actuelles.
Je pense qu'aujourd'hui, le versioning pourrait facilement être étendu à tous les secteurs d'activité, pour devenir une méthode de travail générale « issue du monde du développement logiciel ». Au niveau managérial, c'est à prendre en compte en parallèle de la démocratisation du télé-travail, par exemple.
Je viens de contribuer (anonymement) à ce questionnaire et cela m'évoque un point qui appelle une petite remarque. On peut lire notamment, à plusieurs reprises :
Quels types de contact aviez-vous avec les autres participants du projet ?
- Mail
- Forum
- Chat
- Appels téléphoniques ou vidéo
- Contact direct
- Autre
Si historiquement c'est bien le mail qui a été le principal vecteur de l'effort de développement, il faut absolument prendre en compte aujourd'hui l'impact des logiciels de versioning et des hébergeurs de projets comme Github, qui à eux-deux permettent de prendre automatiquement en charge tout l'aspect « logistique » de la chose.
Je pense qu'aujourd'hui, il n'est pas exagéré de dire que ce type d'outil représente à lui seul autant d'activité que le reste des technologies présentées ici réunies.
Sur les projets publics, c'est à la fois le moyen le plus rapide d'obtenir et d'installer tout l'état de l'art concernant un projet en particulier, jusqu'à ses modifications les plus récentes, et c'est aussi la façon la plus certaine de retrouver le projet officiel puisque non seulement le développeur en charge du projet utilise les mêmes outils pour ses propres moyens, mais va aussi les partager par cette même voie.
Ça n'a l'air de rien mais lorsqu'un projet ne s'appuie pas dessus, la personne qui souhaite s'impliquer doit généralement retrouver le site web officiel du projet, s'assurer que c'est le bon, vérifier les dates de dernières mises à jour du contenu du site, récupérer la dernière « nightly build » ou package de développement officiel, puis récupérer les derniers patches en date sur la mailing list et les appliquer lui-même.
À l'usage, le dernier patch que j'ai envoyé et qui a donné lieu à une vraie modification l'a été sur le bugtracker du dépôt Github d'une des bibliothèques de ma distribution. Non seulement le bug tracker envoie automatiquement un mail aux personnes concernées (et/ou intéressées), mais on est également à peu près sûr que si le projet est actif, alors les développeurs le verront puisque leur espace de travail est au même endroit. En comparaison, j'avais déjà fait des bugs reports sur un bugzilla d'un projet GNOME et ils sont toujours restés lettres mortes.
Dans le même esprit, fin des années 1990, j'avais entrepris de désassembler et commenter les ROMs de mon vieux huit bit sur lequel j'avais fait mes premières armes. Cela avait beaucoup intéressé un autre développeur du même cercle, qui avait fini par faire la même chose dans son coin. Dans la première partie des années 2000, on en était encore à s'envoyer des disquettes par la poste, très occasionnellement, et qui ont fini par se perdre ou s'abîmer. Lui-même avait perdu une bonne partie de son travail à un moment, il m'avait même demandé si j'avais, moi, conservé son travail. Je n'en ai retrouvé que quelques bribes.
On a fini par laisser tomber la chose pendant près d'une dizaine d'années. Et plus récemment, un certain regain d'intérêt de la part de la communauté l'a remise au devant de la scène et comme le développeur en question s'était mis à Mercurial de son côté, j'ai fini par ouvrir un dépôt Atlassian pour les partager facilement (l'avantage supplémentaire étant que ce site permettait aussi de conserver le projet confidentiel, ce qui était nécessaire parce que les ROMs en question n'étaient pas libres à la base).
Ce qui est intéressant dans cette dernière anecdote, c'est que non seulement ce genre de structure est un formidable accélérateur pour les projets libres et/ou collaboratifs, mais que l'on constate que leur seule disponibilité est susceptible de revigorer des projets considérés comme morts depuis longtemps. On a coutume de dire que le libre s'est en majeure partie appuyé sur l'explosion du mail et de l'Internet grand public, ce qui est vraisemblable. Je pense que ces outils ont provoqué une deuxième révolution, probablement aussi importante.
Du coup, si c'est l'objet de ton étude, il serait intéressant de se pencher dessus en particulier, et de voir comment ils sont susceptibles de transformer le travail de bureau en général, spécialement à une heure ou le télé-travail est de plus en plus mis en avant.
N'hésite pas à venir redemander de l'aide si tu n'y arrives pas.
Mais d'ici là, essaie de faire « git log --patch » sur ta propre branche avant de la pousser. Cela te permettra de voir clairement quels sont les changements enregistrés par git et qui seront donc appliqués tels quels par le dépôt sur lequel tu les enverras ou qui décidera de les rapatrier lui-même.
1 - encore une fois on ne merge pas les contenus des fichiers
2 - on s'arrange lui et moi pour ne pas avoir de conflit dans les noms de nos fichiers (chacun des fichiers est prefixé par nos initiales).
Dans ce cas, c'est bel et bien un merge ordinaire. Il n'y aura jamais de fusion de fichiers imposée si vous vous arrangez déjà pour ne jamais travailler sur les mêmes (et si pour une raison ou une autre, tu t'y retrouvais confronté quand même, c'est qu'il se serait passé quelque chose en amont qui nécessiterait une décision de ta part pour être résolue).
Donc, tu fais tes modifs de ton côté, tu les commites en local avec « git commit », tu pousses tes propres modifs avec « git push » et tu récupères celles de ton collègue avec « git pull ». C'est la manière habituelle de travailler.
Il faut savoir qu'avec Git, comme avec d'autres logiciels de versioning, un « git pull » est équivalent à un « git fetch » suivi d'un « git merge » de la branche distante avec son homologue locale. Une branche est formée par la lignée de ses commits successifs, chacun faisant référence au précédent, et chaque commit décrit les changements apportés à la branche par rapport à l'état précédent.
C'est donc bien l'idée : si ton collègue travaille sur des fichiers A, B et C et que tu travailles sur des fichiers X, Y, et Z, alors son commit décrira quelque chose comme « +A; +B; +C; » et le tien « +X; +Y; +Z ». Fusionner les branches importera ses propres commits dans ton dépôt, ce qui y appliquera ses modifications, dont les effets concerneront des fichiers indépendants de ceux sur lesquels tu travailles.
En résumé : tu peux très bien fusionner une branche sans avoir à fusionner de fichiers.
Ça veut bien dire que tu veux synchroniser les branches et obtenir — dans ton dépôt — les fichiers de ton collègue et vice-versa, n'est-ce pas ? Dans ce cas, il s'agit d'un merge ordinaire.
Plus précisément, ici, tu vas d'abord faire un « commit » en local, et git verra que les seuls changements apportés à ton dépôt par rapport à l'état précédent est l'ajout de tes deux fichiers « Mon_Fichier1 et 2 ». Et c'est exactement cela qui sera enregistré dans le commit. Quand tu vas faire « git push » ensuite, c'est ce commit-là qui sera envoyé et qui appliquera les mêmes changements au dépôt distant. Donc, même si ton collège fait la même chose de son côté avec les siens, vous vous retrouverez avec la somme des deux changements et aucun de vous n'aura marché sur les pieds de l'autre.
Sinon, prend le problème à l'envers :
– Soit tu veux récupérer uniquement les « noms » de fichiers à leur place dans le dépôt, sur le FS. Dans ce cas, que doit-il se passer si tu en ouvres un ?
— Soit tu veux justement récupérer le contenu de la branche « distante » puisque ces fichiers appartiennent à ton collègue → merge ordinaire, là aussi ;
— Si tu veux simplement afficher les fichiers de ton collègue, que doit-il se passer si celui-ci a eu la bonne idée de créer chez lui un fichier qui existait déjà chez toi sous le même nom ? La question n'est pas anodine car elle va nous permettre de savoir ce que tu as réellement en tête et, de là, t'orienter correctement. Peut-être même est-ce pour cela que tu as cette idée : justement pour savoir si un nom de fichier est libre ou déjà réservé…
— Vous souhaitez travailler chacun de votre côté et exporter à la fin uniquement les choses qui vous intéressent vers un dépôt commun officiel qui, lui, doit être synchrone : voir la solution de NeoX ;
— Tu souhaites avoir une « vue » sur le dépôt de ton collègue (et réciproquement) sans avoir à l'importer directement au sein du tien ? C'est le principe de la branche « remote ». Celle-ci est répliquée en local quand tu fais « git fetch » (et notamment, tous les objets associés sont rappatriés) mais reste distincte, et reflète l'état de la branche distante même si celle-ci est reconstruite. Tu peux ensuite y associer une vraie branche locale sur laquelle tu peux éventuellement travailler et fusionner l'avancée de la branche distante. C'est le cas de « master » (local) et « origin/master » (remote) quand tu utilises le modèle par défaut. Si tu veux jeter un œil à ce qui se passe à côté, tu peux faire un checkout sur la branche remote et revenir ensuite sur la tienne.
La clés privée est-elle dans un format lisible (permettant par exemple de l'exporter sur un support non informatique)?
Ça dépend de la méthode de chiffrage que tu as choisie. Si c'est un système s'appuyant sur une passphrase, alors il suffit d'écrire cette passphrase telle quelle dans le fichier concerné.
Aurais-tu une estimation de l'impact sur les ressources machine?
Aucune idée, parce que je n'utilise pratiquement pas les partitions chiffrées. En fait, j'ai créé quelques fichiers ordinaires de quelques méga-octets que je monte en loopback lorsque j'en ai besoin et qui sont ensuite exploités comme des volumes habituels. Ils me servent à contenir les quelques informations réellement confidentielles comme des listes de mots de passe. Je les monte et démonte sur demande à l'aide d'un script lorsque j'ai besoin de les consulter.
Si tu sais à quel endroit est déjà monté ton périphérique amovible, alors une simple ligne de commande du style :
[ -e /répertoiredetaclé/tonfichier ] && cryptsetup --key-file /répertoiredetaclé/tonfichier open /dev/tapartition MonVolume && mount /dev/mapper/MonVolume /monpointdemontage
… devrait suffire. Après, il te suffit de l'ajouter aux scripts de démarrage gérés par init ou systemd selon ta distribution (et son âge). Tu peux également demander à udev ou systemd (là encore, selon la distrib et son âge) de définir un événement correspondant à l'insertion de la clé sur lequel le script sera appelé, après montage de la clé.
Par contre, les volumes ne seront pas automatiquement démontés si tu retires la clé après les avoir montés. Tu peux demander à le faire faire de la même façon mais si un processus quelconque (par exemple un shell) est au même moment dans un des répertoires de ta partition chiffrée, le démontage échouera.
Je ne sais pas s'il « existe un logiciel » tout fait et dédié à cette tâche en particulier mais, à mon avis, si tu utilises cryptsetup ou une solution similaire, tu dois pouvoir t'en sortir avec un simple script. Le problème est que si tu veux que ta partition soit montée au boot, ton périphérique amovible doit être présent dès ce moment et à chaque démarrage. De fait, ça en fait un périphérique un peu moins amovible.
Quel comportement souhaites-tu obtenir ? Est-ce que tu veux déverrouiller automatiquement tes partitions dès lors que tu introduis un dongle une ou clé USB spéciale dans l'emplacement idoine ?
Hello,
En fait, c'est un peu comme emménager dans une maison vide : il y a beaucoup de place mais celle-ci va très vite être exploitée.
Tu n'as pas besoin d'autant de places pour démarrer mais, très vite, tu vas devoir d'une part installer tous les logiciels qui t'intéressent et, d'autre part, te laisser de la place pour ton propre dossier personnel « home ». Enfin, le système lui-même doit avoir suffisamment de place pour travailler (création des logs, des différents fichiers temporaires, etc).
L'avantage est que les logiciels que tu vas rapatrier sous Linux sont libres, qu'ils sont donc proposés par défaut sur les serveurs de la distribution que tu utilises et qu'à tout moment, tu peux demander à faire installer le logiciel dont tu as besoin à l'aide d'une simple commande (« apt-get » sur les systèmes basés sur Debian, « yum » ou « dnf » sur les RedHat/CentOS/Fedora, etc). Le produit est installé en quelques secondes sans que tu aies, généralement, à rebooter ou à faire quoi que ce soit d'autres. Certaines lignes de commandes te proposent même d'installer directement le package adéquat si tu appelé une commande inconnue sur ton système mais qui correspond à un package recensé.
Il est toujours un peu délicat d'estimer correctement la place à allouer à chaque partition quand on refait un PC depuis zéro, mais si tu le réinstalles effectivement depuis le départ et que tu disposes d'un disque dur assez large, alors ce n'est pas la peine de se restreindre a priori.
[^] # Re: cp
Posté par Obsidian . En réponse au message comment calculer le bs d'un dd. Évalué à 10.
dd (Disk Dub) a quand même plusieurs utilités. Sa fonction principale (et originelle) sert bien à dupliquer des disques, mais il propose bien plus d'options que le simple bs.
Si spécifier la taille d'un bloc paraît inutile, c'est justement parce que cela fait double emploi avec la couche « périphérique bloc » du système d'exploitation, qui est censée lisser tout cela et nous permettre d'y accéder comme à un flux ordinaire. Par contre, quand on utilisait des raw devices, il était nécessaire de faire des accès atomiques de la taille d'un secteur et, par conséquent, alignés sur eux (pas question de copier deux demi-secteurs consécutifs, par exemple). Et là, il est quasiment impossible de manipuler sérieusement un volume sans recourir à ce genre d'outils.
En outre, dd propose ibs et obs qui permettent de spécifier une taille de bloc différente en entrée et en sortie. Utile pour le genre de périphérique, ou pour balancer des données à travers des sockets qui exigent des trames de taille fixe.
Dernier point mais non des moindres : il existe l'option noerror qui permet de continuer le traitement même en cas d'erreurs de lecture qui, sur un disque, correspondraient à des secteurs défectueux. C'est quand même un gros avantage sur cp qui, par ailleurs, n'est pas fait pour être interrompu. dd a le bon goût d'indiquer où il en est quand on le stoppe prématurément.
Du coup, il vaut mieux ne pas spécifier comme taille de bloc celle du volume entier car, à la moindre erreur, c'est justement le reste « du volume entier » qui est passé ou rempli avec des zéros. En ce sens, il est plus intéressant de choisir comme taille de bloc celle d'un secteur ou d'un bloc du système de fichier (généralement 4096 octets) et ensuite de la multiplier par un certain facteur pour profiter de la RAM disponible et limiter les appels système, mais en restant raisonnable pour les raisons évoquées. Un bloc de la taille d'une piste est généralement un bon compromis.
[^] # Re: Il te semble mal ....
Posté par Obsidian . En réponse au message connecter 2 pc en ethernet. Évalué à 8. Dernière modification le 27 juin 2017 à 18:52.
Au contraire, chez moi, ça fait bien longtemps que ça marche et que je n'ai plus eu à avoir recours à un câble croisé. En fait, il suffit qu'un seul des points de terminaison soit capable de se « retourner ». Et généralement, à moins d'avoir un produit d'entrée de gamme, les puces Ethernet des cartes-mères sont capables de le faire seul.
[^] # Re: diffamation
Posté par Obsidian . En réponse au journal Linagora à l'Assemblée Nationale ?. Évalué à 3.
Absolument.
Un propos diffamatoire et faux est une « calmonie ».
[^] # Re: alias rm=rm -i
Posté par Obsidian . En réponse au message Comment éviter d'effacer des fichiers avec rm *. Évalué à 4.
Si, effectivement. Je ne connaissais pas la variable $BASH_COMMAND.
Tu peux décomposer le contenu de cette variable en un tableau et vérifier si l'un des éléments est une étoile seule (ou à la limite une suite d'étoiles, exclusivement).
# alias rm=rm -i
Posté par Obsidian . En réponse au message Comment éviter d'effacer des fichiers avec rm *. Évalué à 7.
Sous bash, la pratique habituelle (et généralement configurée par les distributions elles-mêmes) consiste à définir un alias avec alias rm=rm -i puis à utiliser « rm -f fichiers » quand on « sait ce que l'on fait ».
Une autre astuce consiste à déclarer « rm » (ou n'importe quoi d'autre) comme une fonction sous Bash pour pouvoir contrôler son comportement plus finement en fonction des paramètres, avant de rappeler l'exécutable original.
Il n'y a malheureusement pas d'option pour vérifier si on tape « * » en particulier car ce caractère est développé par le shell lui-même en la liste des fichiers du répertoire courant, et ce AVANT d'appeler l'exécutable ou la fonction. Ceux-ci n'ont alors aucun moyen de savoir si c'est un caractère joker qui a généré cette liste ou si l'utilisateur les a tous spécifiés expressément.
[^] # Re: Si vous avez des questions vous pouvez m'envoyer un message en privé.
Posté par Obsidian . En réponse au message [Offre d'emploi] Doctolib - Devops/Sysadmin senior CDI. Évalué à 4.
s/pas/plus/
Ça a existé il y a longtemps…
# Timeout
Posté par Obsidian . En réponse au message mot de passe FTP dans Thunar (suite). Évalué à 2.
Bonjour,
Ça, c'est généralement caractéristique d'un timeout. Ton logiciel doit chercher à se connecter à un serveur tiers qui, lui, ne doit plus répondre depuis le début de la panne et il faut attendre le délai de grâce avant que le logiciel décide d'abandonner et de passer à la solution de secours, qui peut être soit un serveur secondaire, soit des informations conservées en cache.
Ça arrive également quand c'est le DNS qui ne répond plus : toutes les connexions directement basées sur les adresses des hôtes à atteindre fonctionnent mais tout ce qui utilise un nom de domaine se met à rester plusieurs minutes en attente. Et comme cela peut être transparent pour l'utilisateur ou se trouver à un niveau très bas, il peut être parfois assez difficile d'identifier la source du problème.
Ça peut enfin se produire même si le serveur ne répondait déjà plus mais retournait quand même un refus de connexion explicite. S'il se décide à faire la carpe à la place, soit parce qu'il a réellement été éteint ou mis hors ligne, soit parce qu'un firewall trop zélé a décidé de filtrer l'ICMP, ça peut aussi engendrer les mêmes effets du jour au lendemain.
Possible qu'il s'agisse de la même cause. Si le serveur n'est plus le même, le certificat ne sera plus valide non plus.
Une autre chose qu'il m'est arrivé, notamment avec Evolution : lorsque le serveur retournait un « Internal Error » lors d'une connexion, le logiciel ne comprenait pas le code d'erreur. Il retombait donc sur le comportement « Connexion Refusée » standard et côté interface utilisateur, il me redemandait mon mot de passe en boucle, et ce pour chacune des boîtes situées sur le même serveur. :-\
[^] # Re: une expérience
Posté par Obsidian . En réponse au journal Endurance des SSD. Évalué à 10.
Il va falloir s'y faire : c'est un disque dur quantique ! :-)
[^] # Re: git
Posté par Obsidian . En réponse au message Comment partager mes projets ?. Évalué à 2.
N'hésite pas à poser tes questions ici dans programmation.autre, par exemple. Histoire de mettre facilement le pied à l'étrier (par exemple : voir d'emblée ce qu'est l'index/staging area).
Autre technique intéressante : rapatrier avec Git un projet d'envergure déjà existant (le noyau Linux en étant bien sûr l'archétype, mais on peut faire moins gros), non pas pour y travailler, mais pour se faire la main en conditions réelles. C'est plus facile de voir à quoi servent les branches, les reflogs et toutes les fonctionnalités qui ont émaillé l'outil au fil du temps en explorant un dépôt bien fourni qu'en faisant des cas d'école sur un répertoire qui ne contient qu'une demi-douzaine de commits.
Enfin, n'hésite pas à choisir un client pour Git. Personnellement, j'utilise « tig » mais il en existe pléthore. C'est plus facile de se balader dans un dépôt avec ce genre d'outil qu'en utilisant simplement git log --graph
Bon courage.
# Que me conseillez-vous ?
Posté par Obsidian . En réponse au message Comment partager mes projets ?. Évalué à 9. Dernière modification le 23 mai 2017 à 18:21.
Salut,
Tu as l'air d'avoir bien résumé la situation toi-même et d'avoir une vision assez précise de la chose. Il serait dommage de ne pas en profiter pour franchir le pas et approfondir le tout, en effet…
Je dirais plutôt que, vu la situation, c'est « une bonne occasion de se mettre à Git ».
Plus précisément, Git est aujourd'hui aussi populaire que répandu, mais il rebute parfois un peu les néophytes comme les habitués d'autres SCM. Une fois qu'on a compris le principe général, le tout devient somme toutes assez simple mais le mieux reste quand même de se le faire expliquer par quelqu'un qui connaît bien l'outil lorsque l'on fait ses premiers pas. Après, on peut pratiquement tout utiliser sans difficulté notoire.
Sache aussi qu'il est très intéressant d'utiliser un logiciel de versioning même lorsque l'on travaille seul (et pas simplement pour le code). Ça permet de conserver automatiquement la trace des différentes versions de ce que l'on écrit sans se soucier de les classer explicitement, ça permet de revenir facilement en arrière, ça permet de forker quand on veut démarrer un nouveau projet similaire à un autre et, in fine, ça permet de partager automatiquement son travail une fois que l'on a atteint un stade intéressant pour son entourage.
C'est aussi très intéressant pour conserver un code toujours propre : en général, il est facile d'ajouter des lignes de code à un fichier existant mais il est plus difficile de prendre la décision de supprimer des blocs lorsqu'ils ont demandé du travail pour être mis au point. En général, ils finissent en commentaires jusqu'à ce qu'ils soient suffisamment vieux pour être effacés… à condition qu'on ait pensé à écrire la date dans le commentaire en question. S'appuyer sur un SCM quand on développe permet d'effacer immédiatement ce qui ne sert à rien car non seulement rien n'est définitivement perdu, mais parce qu'il est très facile de les retrouver et même les mettre en évidence à l'aide d'un diff entre deux révisions.
Et si malgré ça rien ne te séduit, tu peux quand même faire un « git init » dans ton répertoire de travail, ajouter tout ton travail dans un seul gros commit initial sans rien d'autre, et t'en servir pour le partager sur une forge officielle.
[^] # Re: Tu ne dois pas souvent dormir...
Posté par Obsidian . En réponse au journal [TRÈS_HS] « Moyen de gamme », sur lemonde.fr, nan mais je rêve. Évalué à 10.
Ça me permet de me rendre compte que j'avais manqué celui-ci :
[^] # Re: Tootella is UP
Posté par Obsidian . En réponse au journal Tootella is down. Évalué à 2.
C'est une bonne nouvelle !
Mais question volontairement naïve : le registrar n'envoie pas un mail pour prévenir d'une expiration ? Surtout au bout de cinq ans…
# Oui.
Posté par Obsidian . En réponse au message probleme au demarrage. Évalué à 2.
Bonjour,
GRUB est le « loader » qui te permet de lancer soit ton système Linux dans différents mode ou en choisissant ton noyau, soit de lancer d'autres systèmes d'exploitation. Mais en principe, il est aujourd'hui configuré pour présenter un menu explicite. Si tu vois uniquement la ligne de commande, c'est que soit ta distribution est minimaliste, soit l'installation n'a pas pu aller jusqu'à son terme.
Essaie d'appuyer simplement sur « Entrée » quand tu vois ce message, pour voir s'il démarre normalement.
# Pourquoi chroot ?
Posté par Obsidian . En réponse au message Chroot: accès aux fichiers /home/. Évalué à 6.
Bonjour,
Ce que tu décris n'a rien à voir avec chroot en particulier : tu peux monter les partitions de n'importe quel disque dur depuis un système opérationnel, fût-ce un Live CD, sans avoir à recourir à chroot en particulier. Et le plus beau : tu peux très bien monter les partitions d'un Windows quelconque depuis un système Linux, Live CD ou non, et les modifier à loisir. Et pas seulement les fichiers des utilisateurs : tu peux modifier le système, la base de registres, etc. voir réinstaller un système entier si ça te chante. En principe, c'est vrai dans l'autre sens aussi, à ceci près que Windows n'est généralement pas fait pour et ne propose pas d'outil a priori pour le faire. Il faut s'équiper.
C'est donc tout-à-fait normal en soi et heureusement qu'on peut le faire, car c'est également de cette façon qu'on dépanne les systèmes qui ne démarrent plus.
Par ailleurs, un disque dur est un support de stockage. Ce n'est pas un coffre-fort. Il n'a donc pas vocation à dissimuler son contenu a priori non plus. Au contraire, il doit en garantir l'accessibilité, la disponibilité et l'intégrité pendant toute sa durée de vie (laquelle devrait être théoriquement infinie car les particuliers établissent rarement des plans de migration).
Si tu veux protéger tes données, il faut mettre en place un dispositif de sécurité explicite et identifié à l'avance : soit tu mets physiquement un cadenas sur le boîtier de ta machine et tu paramètres ton BIOS/UEFI pour ne pas démarrer par défaut sur les lecteurs externes (certains boîtiers sont spécialement équipés pour qu'on puisse le faire), soit tu utilises un fichier ou une partition chiffrée pour y déposer les informations réellement confidentielles (voir https://linuxfr.org/forums/linux-general/posts/chiffrer-disque-avec-cles-de-chiffrement-stockee-sur-peripherique-amovible ).
[^] # Re: Je propose la création d'un langage informatique
Posté par Obsidian . En réponse à la dépêche Questionnaire LinuxFr.org pour la présidentielle française 2017. Évalué à 5.
Pas bête. On appellerait ça une compilation !
On pourrait se baser sur le XML comme méta-langage et utiliser XSLT pour faire des transpositions en droit européen. :-)
Ce qui serait surtout génial, c'est de pouvoir faire des sandboxes, pour que nos chers politiques puissent s'amuser à loisir sans que ce soit automatiquement au dépens de la population…
Ça, plus sérieusement, ça a commencé à se faire ici : « le code civil sur Github » et on parlait ici aussi.
Sur le premier lien, même si le projet est encore incomplet, il est intéressant de constater à quel point des siècles de révision de la loi et de maintien monacal de ses textes pourrait se comparer à un projet communautaire de relativement petite envergure comme il en existe des milliers sur les forges actuelles.
Je pense qu'aujourd'hui, le versioning pourrait facilement être étendu à tous les secteurs d'activité, pour devenir une méthode de travail générale « issue du monde du développement logiciel ». Au niveau managérial, c'est à prendre en compte en parallèle de la démocratisation du télé-travail, par exemple.
# Git et compagnie
Posté par Obsidian . En réponse au message Questionnaire logiciel libre pour mémoire de master éco-socio. Évalué à 6.
Je viens de contribuer (anonymement) à ce questionnaire et cela m'évoque un point qui appelle une petite remarque. On peut lire notamment, à plusieurs reprises :
Si historiquement c'est bien le mail qui a été le principal vecteur de l'effort de développement, il faut absolument prendre en compte aujourd'hui l'impact des logiciels de versioning et des hébergeurs de projets comme Github, qui à eux-deux permettent de prendre automatiquement en charge tout l'aspect « logistique » de la chose.
Je pense qu'aujourd'hui, il n'est pas exagéré de dire que ce type d'outil représente à lui seul autant d'activité que le reste des technologies présentées ici réunies.
Sur les projets publics, c'est à la fois le moyen le plus rapide d'obtenir et d'installer tout l'état de l'art concernant un projet en particulier, jusqu'à ses modifications les plus récentes, et c'est aussi la façon la plus certaine de retrouver le projet officiel puisque non seulement le développeur en charge du projet utilise les mêmes outils pour ses propres moyens, mais va aussi les partager par cette même voie.
Ça n'a l'air de rien mais lorsqu'un projet ne s'appuie pas dessus, la personne qui souhaite s'impliquer doit généralement retrouver le site web officiel du projet, s'assurer que c'est le bon, vérifier les dates de dernières mises à jour du contenu du site, récupérer la dernière « nightly build » ou package de développement officiel, puis récupérer les derniers patches en date sur la mailing list et les appliquer lui-même.
À l'usage, le dernier patch que j'ai envoyé et qui a donné lieu à une vraie modification l'a été sur le bugtracker du dépôt Github d'une des bibliothèques de ma distribution. Non seulement le bug tracker envoie automatiquement un mail aux personnes concernées (et/ou intéressées), mais on est également à peu près sûr que si le projet est actif, alors les développeurs le verront puisque leur espace de travail est au même endroit. En comparaison, j'avais déjà fait des bugs reports sur un bugzilla d'un projet GNOME et ils sont toujours restés lettres mortes.
Dans le même esprit, fin des années 1990, j'avais entrepris de désassembler et commenter les ROMs de mon vieux huit bit sur lequel j'avais fait mes premières armes. Cela avait beaucoup intéressé un autre développeur du même cercle, qui avait fini par faire la même chose dans son coin. Dans la première partie des années 2000, on en était encore à s'envoyer des disquettes par la poste, très occasionnellement, et qui ont fini par se perdre ou s'abîmer. Lui-même avait perdu une bonne partie de son travail à un moment, il m'avait même demandé si j'avais, moi, conservé son travail. Je n'en ai retrouvé que quelques bribes.
On a fini par laisser tomber la chose pendant près d'une dizaine d'années. Et plus récemment, un certain regain d'intérêt de la part de la communauté l'a remise au devant de la scène et comme le développeur en question s'était mis à Mercurial de son côté, j'ai fini par ouvrir un dépôt Atlassian pour les partager facilement (l'avantage supplémentaire étant que ce site permettait aussi de conserver le projet confidentiel, ce qui était nécessaire parce que les ROMs en question n'étaient pas libres à la base).
Ce qui est intéressant dans cette dernière anecdote, c'est que non seulement ce genre de structure est un formidable accélérateur pour les projets libres et/ou collaboratifs, mais que l'on constate que leur seule disponibilité est susceptible de revigorer des projets considérés comme morts depuis longtemps. On a coutume de dire que le libre s'est en majeure partie appuyé sur l'explosion du mail et de l'Internet grand public, ce qui est vraisemblable. Je pense que ces outils ont provoqué une deuxième révolution, probablement aussi importante.
Du coup, si c'est l'objet de ton étude, il serait intéressant de se pencher dessus en particulier, et de voir comment ils sont susceptibles de transformer le travail de bureau en général, spécialement à une heure ou le télé-travail est de plus en plus mis en avant.
[^] # Re: Conflits de merge ?
Posté par Obsidian . En réponse au message Git : comment merger une arborescence de fichiers ? (pas leur contenu). Évalué à 2.
N'hésite pas à venir redemander de l'aide si tu n'y arrives pas.
Mais d'ici là, essaie de faire « git log --patch » sur ta propre branche avant de la pousser. Cela te permettra de voir clairement quels sont les changements enregistrés par git et qui seront donc appliqués tels quels par le dépôt sur lequel tu les enverras ou qui décidera de les rapatrier lui-même.
[^] # Re: Conflits de merge ?
Posté par Obsidian . En réponse au message Git : comment merger une arborescence de fichiers ? (pas leur contenu). Évalué à 3.
Bonjour,
Dans ce cas, c'est bel et bien un merge ordinaire. Il n'y aura jamais de fusion de fichiers imposée si vous vous arrangez déjà pour ne jamais travailler sur les mêmes (et si pour une raison ou une autre, tu t'y retrouvais confronté quand même, c'est qu'il se serait passé quelque chose en amont qui nécessiterait une décision de ta part pour être résolue).
Donc, tu fais tes modifs de ton côté, tu les commites en local avec « git commit », tu pousses tes propres modifs avec « git push » et tu récupères celles de ton collègue avec « git pull ». C'est la manière habituelle de travailler.
Il faut savoir qu'avec Git, comme avec d'autres logiciels de versioning, un « git pull » est équivalent à un « git fetch » suivi d'un « git merge » de la branche distante avec son homologue locale. Une branche est formée par la lignée de ses commits successifs, chacun faisant référence au précédent, et chaque commit décrit les changements apportés à la branche par rapport à l'état précédent.
C'est donc bien l'idée : si ton collègue travaille sur des fichiers A, B et C et que tu travailles sur des fichiers X, Y, et Z, alors son commit décrira quelque chose comme « +A; +B; +C; » et le tien « +X; +Y; +Z ». Fusionner les branches importera ses propres commits dans ton dépôt, ce qui y appliquera ses modifications, dont les effets concerneront des fichiers indépendants de ceux sur lesquels tu travailles.
En résumé : tu peux très bien fusionner une branche sans avoir à fusionner de fichiers.
# Conflits de merge ?
Posté par Obsidian . En réponse au message Git : comment merger une arborescence de fichiers ? (pas leur contenu). Évalué à 3.
Salut,
J'ai moi aussi un peu de mal à voir où tu veux en venir. Je lis :
Ça veut bien dire que tu veux synchroniser les branches et obtenir — dans ton dépôt — les fichiers de ton collègue et vice-versa, n'est-ce pas ? Dans ce cas, il s'agit d'un merge ordinaire.
Plus précisément, ici, tu vas d'abord faire un « commit » en local, et git verra que les seuls changements apportés à ton dépôt par rapport à l'état précédent est l'ajout de tes deux fichiers « Mon_Fichier1 et 2 ». Et c'est exactement cela qui sera enregistré dans le commit. Quand tu vas faire « git push » ensuite, c'est ce commit-là qui sera envoyé et qui appliquera les mêmes changements au dépôt distant. Donc, même si ton collège fait la même chose de son côté avec les siens, vous vous retrouverez avec la somme des deux changements et aucun de vous n'aura marché sur les pieds de l'autre.
Sinon, prend le problème à l'envers :
– Soit tu veux récupérer uniquement les « noms » de fichiers à leur place dans le dépôt, sur le FS. Dans ce cas, que doit-il se passer si tu en ouvres un ?
— Soit tu veux justement récupérer le contenu de la branche « distante » puisque ces fichiers appartiennent à ton collègue → merge ordinaire, là aussi ;
— Si tu veux simplement afficher les fichiers de ton collègue, que doit-il se passer si celui-ci a eu la bonne idée de créer chez lui un fichier qui existait déjà chez toi sous le même nom ? La question n'est pas anodine car elle va nous permettre de savoir ce que tu as réellement en tête et, de là, t'orienter correctement. Peut-être même est-ce pour cela que tu as cette idée : justement pour savoir si un nom de fichier est libre ou déjà réservé…
— Vous souhaitez travailler chacun de votre côté et exporter à la fin uniquement les choses qui vous intéressent vers un dépôt commun officiel qui, lui, doit être synchrone : voir la solution de NeoX ;
— Tu souhaites avoir une « vue » sur le dépôt de ton collègue (et réciproquement) sans avoir à l'importer directement au sein du tien ? C'est le principe de la branche « remote ». Celle-ci est répliquée en local quand tu fais « git fetch » (et notamment, tous les objets associés sont rappatriés) mais reste distincte, et reflète l'état de la branche distante même si celle-ci est reconstruite. Tu peux ensuite y associer une vraie branche locale sur laquelle tu peux éventuellement travailler et fusionner l'avancée de la branche distante. C'est le cas de « master » (local) et « origin/master » (remote) quand tu utilises le modèle par défaut. Si tu veux jeter un œil à ce qui se passe à côté, tu peux faire un checkout sur la branche remote et revenir ensuite sur la tienne.
[^] # Re: SpiderOak
Posté par Obsidian . En réponse au message Sauvegardes incrémentales en ligne, chiffrées localement ?. Évalué à 5.
J'ai lu « MultideskOS » sur le coup. Heureusement que j'ai revérifié… :-)
[^] # Re: Probablement…
Posté par Obsidian . En réponse au message Chiffrer disque avec clés de chiffrement stockée sur périphérique amovible. Évalué à 3.
Ça dépend de la méthode de chiffrage que tu as choisie. Si c'est un système s'appuyant sur une passphrase, alors il suffit d'écrire cette passphrase telle quelle dans le fichier concerné.
Aucune idée, parce que je n'utilise pratiquement pas les partitions chiffrées. En fait, j'ai créé quelques fichiers ordinaires de quelques méga-octets que je monte en loopback lorsque j'en ai besoin et qui sont ensuite exploités comme des volumes habituels. Ils me servent à contenir les quelques informations réellement confidentielles comme des listes de mots de passe. Je les monte et démonte sur demande à l'aide d'un script lorsque j'ai besoin de les consulter.
[^] # Re: Probablement…
Posté par Obsidian . En réponse au message Chiffrer disque avec clés de chiffrement stockée sur périphérique amovible. Évalué à 3. Dernière modification le 17 novembre 2016 à 03:02.
Si tu sais à quel endroit est déjà monté ton périphérique amovible, alors une simple ligne de commande du style :
[ -e /répertoiredetaclé/tonfichier ] && cryptsetup --key-file /répertoiredetaclé/tonfichier open /dev/tapartition MonVolume && mount /dev/mapper/MonVolume /monpointdemontage
… devrait suffire. Après, il te suffit de l'ajouter aux scripts de démarrage gérés par init ou systemd selon ta distribution (et son âge). Tu peux également demander à udev ou systemd (là encore, selon la distrib et son âge) de définir un événement correspondant à l'insertion de la clé sur lequel le script sera appelé, après montage de la clé.
Par contre, les volumes ne seront pas automatiquement démontés si tu retires la clé après les avoir montés. Tu peux demander à le faire faire de la même façon mais si un processus quelconque (par exemple un shell) est au même moment dans un des répertoires de ta partition chiffrée, le démontage échouera.
# Probablement…
Posté par Obsidian . En réponse au message Chiffrer disque avec clés de chiffrement stockée sur périphérique amovible. Évalué à 3.
Je ne sais pas s'il « existe un logiciel » tout fait et dédié à cette tâche en particulier mais, à mon avis, si tu utilises cryptsetup ou une solution similaire, tu dois pouvoir t'en sortir avec un simple script. Le problème est que si tu veux que ta partition soit montée au boot, ton périphérique amovible doit être présent dès ce moment et à chaque démarrage. De fait, ça en fait un périphérique un peu moins amovible.
Quel comportement souhaites-tu obtenir ? Est-ce que tu veux déverrouiller automatiquement tes partitions dès lors que tu introduis un dongle une ou clé USB spéciale dans l'emplacement idoine ?
[^] # Re: des reponses
Posté par Obsidian . En réponse au message Quelques questions avant de me lancer dans linux.. Évalué à 3.
Hello,
En fait, c'est un peu comme emménager dans une maison vide : il y a beaucoup de place mais celle-ci va très vite être exploitée.
Tu n'as pas besoin d'autant de places pour démarrer mais, très vite, tu vas devoir d'une part installer tous les logiciels qui t'intéressent et, d'autre part, te laisser de la place pour ton propre dossier personnel « home ». Enfin, le système lui-même doit avoir suffisamment de place pour travailler (création des logs, des différents fichiers temporaires, etc).
L'avantage est que les logiciels que tu vas rapatrier sous Linux sont libres, qu'ils sont donc proposés par défaut sur les serveurs de la distribution que tu utilises et qu'à tout moment, tu peux demander à faire installer le logiciel dont tu as besoin à l'aide d'une simple commande (« apt-get » sur les systèmes basés sur Debian, « yum » ou « dnf » sur les RedHat/CentOS/Fedora, etc). Le produit est installé en quelques secondes sans que tu aies, généralement, à rebooter ou à faire quoi que ce soit d'autres. Certaines lignes de commandes te proposent même d'installer directement le package adéquat si tu appelé une commande inconnue sur ton système mais qui correspond à un package recensé.
Il est toujours un peu délicat d'estimer correctement la place à allouer à chaque partition quand on refait un PC depuis zéro, mais si tu le réinstalles effectivement depuis le départ et que tu disposes d'un disque dur assez large, alors ce n'est pas la peine de se restreindre a priori.
Bon courage et bienvenue sous Linux.
[^] # Re: etonnant moyen d'apprendre
Posté par Obsidian . En réponse au message Recherche d'exercices a faire avec le SHELL Unix. Évalué à 2.
« Our free trial of kung-fu has expired ! »