Install sur un PC puis transfert du DD sur un autre PC : possible ?
35 réponses
Alf92
Bjr,
J'ai un (vieux) PC dont le lecteur de DVD est HS et pour lequel le boot
sur USB n'est pas possible.
Puis-je faire l'nstall de Linux Mint (v19.3 car en 32bots...) sur un
autre PC puis transferer le DD sur un ce vieux PC ?
Si oui y aura-t-il une nouvelle découverte des périphériques +
installation des bons drivers ?
Merci.
jp willm , dans le message <rs4edb$7q7$, a écrit :
Tu mets tous les init non systemd dans le même sac ?
Non.
Francois Lafont
Hello, Je rebondis juste sur systemd, dont je suis un défenseur et je crois savoir que ce n'est pas forcément la majorité ici. :) On 12/24/20 2:09 PM, Marc SCHAEFER wrote:
Je dois dire que j'ai beaucoup testé avant de passer Í systemd, et qu'Í part quelques bugs facilement corrigeables, je n'ai pas eu trop de souci avec buster. Juste quelques soucis avec certaines fonctions avancés comme les namespaces dans apache2 en virtualisation.
Je suis d'accord. Je sais que systemd a souvent été critiqué mais personnellement, étant un utilisateur de Debian/Ubuntu, je considère que le passage Í systemd a été très largement bénéfique. Personnellement, je n'ai quasiment jamais eu de bugs (effectivement peut-être sur 2 ou 3 trucs un peu avancés) et, surtout, pour « daemoniser » un programme, globalement ça se fait en 5 lignes super basiques de fichier INI. Alors qu'avant (sous sysvinit ou upstart pour Ubuntu), il fallait sérieusement se gratter la tête et se farcir de la doc, tu pouvais y passer ta journée sans problème. Franchement si tu compares la daemonisation d'un programme sous systemd et sous sysvinit, y'a juste pas photo. VoilÍ . :) -- François Lafont
Hello,
Je rebondis juste sur systemd, dont je suis un défenseur et je crois savoir
que ce n'est pas forcément la majorité ici. :)
On 12/24/20 2:09 PM, Marc SCHAEFER wrote:
Je dois dire que j'ai beaucoup testé avant de passer Í systemd, et qu'Í
part quelques bugs facilement corrigeables, je n'ai pas eu trop de souci
avec buster. Juste quelques soucis avec certaines fonctions avancés
comme les namespaces dans apache2 en virtualisation.
Je suis d'accord. Je sais que systemd a souvent été critiqué mais personnellement,
étant un utilisateur de Debian/Ubuntu, je considère que le passage Í systemd a été
très largement bénéfique. Personnellement, je n'ai quasiment jamais eu de bugs
(effectivement peut-être sur 2 ou 3 trucs un peu avancés) et, surtout, pour
« daemoniser » un programme, globalement ça se fait en 5 lignes super basiques de
fichier INI. Alors qu'avant (sous sysvinit ou upstart pour Ubuntu), il fallait
sérieusement se gratter la tête et se farcir de la doc, tu pouvais y passer ta
journée sans problème. Franchement si tu compares la daemonisation d'un programme
sous systemd et sous sysvinit, y'a juste pas photo.
Hello, Je rebondis juste sur systemd, dont je suis un défenseur et je crois savoir que ce n'est pas forcément la majorité ici. :) On 12/24/20 2:09 PM, Marc SCHAEFER wrote:
Je dois dire que j'ai beaucoup testé avant de passer Í systemd, et qu'Í part quelques bugs facilement corrigeables, je n'ai pas eu trop de souci avec buster. Juste quelques soucis avec certaines fonctions avancés comme les namespaces dans apache2 en virtualisation.
Je suis d'accord. Je sais que systemd a souvent été critiqué mais personnellement, étant un utilisateur de Debian/Ubuntu, je considère que le passage Í systemd a été très largement bénéfique. Personnellement, je n'ai quasiment jamais eu de bugs (effectivement peut-être sur 2 ou 3 trucs un peu avancés) et, surtout, pour « daemoniser » un programme, globalement ça se fait en 5 lignes super basiques de fichier INI. Alors qu'avant (sous sysvinit ou upstart pour Ubuntu), il fallait sérieusement se gratter la tête et se farcir de la doc, tu pouvais y passer ta journée sans problème. Franchement si tu compares la daemonisation d'un programme sous systemd et sous sysvinit, y'a juste pas photo. VoilÍ . :) -- François Lafont
jp willm
Le 26/12/2020 Í 11:30, Nicolas George a écrit :
jp willm , dans le message <rs4edb$7q7$, a écrit :
Tu mets tous les init non systemd dans le même sac ?
Non.
Ok. -- jp willm https://willms.pagesperso-orange.fr/ https://www.youtube.com/channel/UCJwHW5GwrK1fq16cxUoBOUw
Le 26/12/2020 Í 11:30, Nicolas George a écrit :
jp willm , dans le message <rs4edb$7q7$1@news.gegeweb.eu>, a écrit :
Tu mets tous les init non systemd dans le même sac ?
jp willm , dans le message <rs4edb$7q7$, a écrit :
Tu mets tous les init non systemd dans le même sac ?
Non.
Ok. -- jp willm https://willms.pagesperso-orange.fr/ https://www.youtube.com/channel/UCJwHW5GwrK1fq16cxUoBOUw
Stéphane CARPENTIER
Le 24-12-2020, Marc SCHAEFER a écrit :
systemd est un gros logiciel monolithique qui -- Í mon avis -- s'oppose aux concepts UNIX: mais c'est une tendance assez actuelle qu'un simple logiciel dépende Í dbus, voire systemd.
Dire que systemd fait des trucs qu'il n'a pas Í faire, je suis d'accord avec ça. Mais ce sont des choses qui sont nécessaires et qui ne sont pas faites ailleurs. En plus, comme par défaut tous les process qui continuent de tourner sans père sont par défaut rattaché au PID 1, ça a un peu de sens qu'il s'en occupe. Par contre, d'après ce que j'en ai vu, systemd n'est pas monolithique.
Et vu que ma distribution préférée a décidé de faire le pas, je l'ai fait aussi. Et probablement que d'ici ma prochaine mise Í jour de version en 2024, l'init aura re-changé, donc je n'investis pas trop de savoir faire non plus.
C'est peu probable que ça change si vite. Parce que je n'ai pas l'impression que les alternatives Í systemd montent en visibilité.
Etonnamment, même sur des alix (256 MB de mémoire), passer Í systemd n'a pas été aussi catastrophique que ça. Ca boote plus lentement,
C'est surprenant parce que systemd fait tout pour augmenter la vitesse du boot. Pour moi, c'est loin d'être le plus gros avantage de systemd, mais c'est toujours le premier mis en avant. D'ailleurs, c'est tellement leur argument que tu as des outils dédiés pour ça. Juste poyr savoir combien de temps le boot a pris : « systemd-analyze » puis, pour savoir ce qui prend du temps : « systemd-analyze blame » ou alors sous forme graphique pour voir aussi les dépendances, tu peux faire : « systemd-analyze plot ».
le système bouffe plus de mémoire, il y a un peu plus d'I/O,
Ça aussi, c'est surprenant parce que j'avais essayé de voir et de base, c'est pas le système qui bouffe mes ressources. Ensuite, il y a plusieurs façons d'utiliser systemd. La façon archlinux ou LFS qui ne lance que ce que tu veux lancer. Et l'autre extrême, la façon ubuntu qui lance tout ce dont l'utilisateur pourra être éventuellement avoir besoin un jour et comme ça doit rester facile pour lui, il faut que ce soit disponible sans qu'il se pose la moindre question. Inutile de dire que dans un cas, il y a des possibilités que ça charge plus l'ordinateur que dans l'autre. Pareil, pour ça, tu as des outils. Par exemple, « systemd-cgls » qui t'aide Í voir qu'est-ce que tourne sur ta machine et pourquoi.
Mes tests précédents avec jessie et stretch étaient bien plus calamiteux, des choses simples ne fonctionnant plus correctement, les logs étant pleins, les machines crashaient, etc.
Je sais que certains reprochent Í systemd d'avoir des logs en binaire et pas en texte brut. La raison est valable, mais est tellement improbable sur une machine perso que je suis bien content d'avoir journalctl pour chercher dans mes logs. Il y a plein d'autres outils que je trouve très pratique pour savoir ce qui tourne sur ma machine. -- Si vous avez du temps Í perdre : https://scarpet42.gitlab.io
Le 24-12-2020, Marc SCHAEFER <schaefer@alphanet.ch> a écrit :
systemd est un gros logiciel monolithique qui -- Í mon avis -- s'oppose
aux concepts UNIX: mais c'est une tendance assez actuelle qu'un simple
logiciel dépende Í dbus, voire systemd.
Dire que systemd fait des trucs qu'il n'a pas Í faire, je suis d'accord
avec ça. Mais ce sont des choses qui sont nécessaires et qui ne sont pas
faites ailleurs. En plus, comme par défaut tous les process qui
continuent de tourner sans père sont par défaut rattaché au PID 1, ça a
un peu de sens qu'il s'en occupe.
Par contre, d'après ce que j'en ai vu, systemd n'est pas monolithique.
Et vu que ma distribution préférée a décidé de faire le pas, je l'ai
fait aussi. Et probablement que d'ici ma prochaine mise Í jour de
version en 2024, l'init aura re-changé, donc je n'investis pas trop de
savoir faire non plus.
C'est peu probable que ça change si vite. Parce que je n'ai pas
l'impression que les alternatives Í systemd montent en visibilité.
Etonnamment, même sur des alix (256 MB de mémoire), passer Í systemd n'a
pas été aussi catastrophique que ça. Ca boote plus lentement,
C'est surprenant parce que systemd fait tout pour augmenter la vitesse
du boot. Pour moi, c'est loin d'être le plus gros avantage de systemd,
mais c'est toujours le premier mis en avant.
D'ailleurs, c'est tellement leur argument que tu as des outils dédiés
pour ça.
Juste poyr savoir combien de temps le boot a pris : « systemd-analyze »
puis, pour savoir ce qui prend du temps : « systemd-analyze blame » ou
alors sous forme graphique pour voir aussi les dépendances, tu peux
faire : « systemd-analyze plot ».
le système bouffe plus de mémoire, il y a un peu plus d'I/O,
Ça aussi, c'est surprenant parce que j'avais essayé de voir et de base,
c'est pas le système qui bouffe mes ressources. Ensuite, il y a
plusieurs façons d'utiliser systemd. La façon archlinux ou LFS qui ne
lance que ce que tu veux lancer. Et l'autre extrême, la façon ubuntu qui
lance tout ce dont l'utilisateur pourra être éventuellement avoir besoin
un jour et comme ça doit rester facile pour lui, il faut que ce soit
disponible sans qu'il se pose la moindre question. Inutile de dire que
dans un cas, il y a des possibilités que ça charge plus l'ordinateur que
dans l'autre.
Pareil, pour ça, tu as des outils. Par exemple, « systemd-cgls » qui
t'aide Í voir qu'est-ce que tourne sur ta machine et pourquoi.
Mes tests précédents avec jessie et stretch étaient bien plus
calamiteux, des choses simples ne fonctionnant plus correctement, les
logs étant pleins, les machines crashaient, etc.
Je sais que certains reprochent Í systemd d'avoir des logs en binaire et
pas en texte brut. La raison est valable, mais est tellement improbable
sur une machine perso que je suis bien content d'avoir journalctl pour
chercher dans mes logs. Il y a plein d'autres outils que je trouve très
pratique pour savoir ce qui tourne sur ma machine.
--
Si vous avez du temps Í perdre :
https://scarpet42.gitlab.io
systemd est un gros logiciel monolithique qui -- Í mon avis -- s'oppose aux concepts UNIX: mais c'est une tendance assez actuelle qu'un simple logiciel dépende Í dbus, voire systemd.
Dire que systemd fait des trucs qu'il n'a pas Í faire, je suis d'accord avec ça. Mais ce sont des choses qui sont nécessaires et qui ne sont pas faites ailleurs. En plus, comme par défaut tous les process qui continuent de tourner sans père sont par défaut rattaché au PID 1, ça a un peu de sens qu'il s'en occupe. Par contre, d'après ce que j'en ai vu, systemd n'est pas monolithique.
Et vu que ma distribution préférée a décidé de faire le pas, je l'ai fait aussi. Et probablement que d'ici ma prochaine mise Í jour de version en 2024, l'init aura re-changé, donc je n'investis pas trop de savoir faire non plus.
C'est peu probable que ça change si vite. Parce que je n'ai pas l'impression que les alternatives Í systemd montent en visibilité.
Etonnamment, même sur des alix (256 MB de mémoire), passer Í systemd n'a pas été aussi catastrophique que ça. Ca boote plus lentement,
C'est surprenant parce que systemd fait tout pour augmenter la vitesse du boot. Pour moi, c'est loin d'être le plus gros avantage de systemd, mais c'est toujours le premier mis en avant. D'ailleurs, c'est tellement leur argument que tu as des outils dédiés pour ça. Juste poyr savoir combien de temps le boot a pris : « systemd-analyze » puis, pour savoir ce qui prend du temps : « systemd-analyze blame » ou alors sous forme graphique pour voir aussi les dépendances, tu peux faire : « systemd-analyze plot ».
le système bouffe plus de mémoire, il y a un peu plus d'I/O,
Ça aussi, c'est surprenant parce que j'avais essayé de voir et de base, c'est pas le système qui bouffe mes ressources. Ensuite, il y a plusieurs façons d'utiliser systemd. La façon archlinux ou LFS qui ne lance que ce que tu veux lancer. Et l'autre extrême, la façon ubuntu qui lance tout ce dont l'utilisateur pourra être éventuellement avoir besoin un jour et comme ça doit rester facile pour lui, il faut que ce soit disponible sans qu'il se pose la moindre question. Inutile de dire que dans un cas, il y a des possibilités que ça charge plus l'ordinateur que dans l'autre. Pareil, pour ça, tu as des outils. Par exemple, « systemd-cgls » qui t'aide Í voir qu'est-ce que tourne sur ta machine et pourquoi.
Mes tests précédents avec jessie et stretch étaient bien plus calamiteux, des choses simples ne fonctionnant plus correctement, les logs étant pleins, les machines crashaient, etc.
Je sais que certains reprochent Í systemd d'avoir des logs en binaire et pas en texte brut. La raison est valable, mais est tellement improbable sur une machine perso que je suis bien content d'avoir journalctl pour chercher dans mes logs. Il y a plein d'autres outils que je trouve très pratique pour savoir ce qui tourne sur ma machine. -- Si vous avez du temps Í perdre : https://scarpet42.gitlab.io
David Larochette
Le 23/12/2020 Í 15:01, Alf92 a écrit :
question subsidiaire : le support de LM 9.3 est assuré jusqu'en avril 2023. je suppose donc que les mises Í jour cesserons. Ok. mais pourrai-je après cette date encore installer des programmes issus de dépots ?
Oui, pour l'instant, les paquets sons conservés depuis la v2 ; mais il n'y a aucune assurance que cela demeure.
Le 23/12/2020 Í 15:01, Alf92 a écrit :
question subsidiaire : le support de LM 9.3 est assuré jusqu'en avril 2023.
je suppose donc que les mises Í jour cesserons. Ok.
mais pourrai-je après cette date encore installer des programmes issus de dépots ?
Oui, pour l'instant, les paquets sons conservés depuis la v2 ; mais il
n'y a aucune assurance que cela demeure.
question subsidiaire : le support de LM 9.3 est assuré jusqu'en avril 2023. je suppose donc que les mises Í jour cesserons. Ok. mais pourrai-je après cette date encore installer des programmes issus de dépots ?
Oui, pour l'instant, les paquets sons conservés depuis la v2 ; mais il n'y a aucune assurance que cela demeure.
