totof2000 a écrit 9656 commentaires

Personnellement il m'est déjà arrivé de ne pas pouvoir terminer une mise à jour un jour J, et de relancer la manip deux ou trois jours après et miracle, ça marche. J'étais probablement tombé sur un bug qui a été résolu peu de temps après, mais je n'&ai pas eu le temps de m'y remettre. peut-être qu'en cherchant j'aurais trouvé, mais c'était un soir très tard, j'ai préféré aller me coucher.

Tout ça pour dire que je ne dis pas que ça va se transformer en 2 heures systématiquement, mais que potentiellement, il est possible que ça se transforme en une indisponibilité de longue durée. Et ça je ne peux me le permettre.

L'avantage sous Mac (et Windows), si je veux la dernière version d'un logiciel, je la télécharge/achète, et c'est bon. Je peux l'utiliser.

1/ Ce n'est pas toujours si simple.
2/ si tu ne raques pas un max pour chaque mise à jour de chaque logiciel, tu n'as rien, ou alors tu dois supporter un tas de crapware avec les softs "gratuits". Et pour enlever ces pourritures, c'est la galère.

3/ l'offre proposée est au mieux à jour au moment de la sortie de la distribution. Ensuite, si on veut évolué à partir de là, soit on attend, soit on bidouille.

C'est la même chose pour Windows ou mac : tu dois attendre que l'éditeur te fournisse une version suffisamment stable et testée (à moins d'avoir un éditeur pas sérieux), ce qui prend du temps.

La vision que les gens ont de l'informatique, qui est faite pour leur simplfier la vie, se complique généralement vite sous toutes les distribution GNU/Linux orientées desktop dès qu'ils ont besoin de sortir de l'utilisation prévue de leur OS.

C'est loin d'être un problème propre au monde Linux. Essaie de sortir des sentiers battus sur un MAC par exemple, et tu verras.

Je suis sérieux : je n'ai absolument pas compris ou tu voulais en venir, ce que tu voulais dire.

J'en ai déjà parlé ici même.

Disons qu'au vu de mon utilisation et de mes besoins, je ne peux prendre le risque de passer 3 à 5 mn par jour qui sont suceptibles de se transformer en 3 à 5h.

Soit la version a été intégrée dans les ports et tu l'installes, soit tu fais toi-même lla compilation, et vu que tu es gentil tu le mets à disposition ;)

Plus sérieusement : je ne sais pas à quel rythme sortent les versions de ports sous FreeBSD (je ne me suis mis sérieusement il y a peu de temps). Pour apache par exemple : http://www.freshports.org/www/apache24/ Mais d'après ce que j'en ai lu, ça ressemble à du rolling release.

Rien compris …

Elle est en rien exagérée, c'est du vécu.

Génial, je vais consacrer un ordinateur pour faire des mises à jour. Et je l'utilise quand ? Faire des mises à jour, ce n'est pas à mon avis la raison d'être d'une machine de bureau.

C'est pour ça qu'il dit que ça peut s'automatiser. Et si c'est vrai que c'est un travail de longue haleine, on peut créer un outil qui automatisera la génération de conf de l'outil d'automatisation.

Arch c'est stable quand tu ne fais pas de mise à jour.

Sinon, soit ça passe, soit ça casse.

Depuis longtemps sous freeBSD : pkg_add et depuis peu pkg.

Mais il arrive parfois de devoir recompiler un petit truc mais c'est assez rare.

… les distributions ne sont pas pensées ainsi. Une distribution est pensée et testée comme un tout (pas de séparation système/userland).

Utilise un système comme FreeBSD par exemple. Il y a une nette séparation entre le système et les applications qui sont disponible via les ports.

Sinon, tu t'installes une distrib LTS (avec support 2ans) et tu installes tes softs via pkgsrc (issu de NetBSD mais dispo sur un tas de plateformes). pkgsrc est régulièrement mis à jour (4 fois par an environs). Tu ne disposes pas forcément de la toute dernière version des softs, et tous les softs Linux ne sont pas forcément dispo, mais si tu y trouves ton bonheur, ça peut faire un bon compromis.

Oui mais :

1/ Pour apprendre ce n'est pas drôle
2/ J'utilise une machine de type Unix pour mes tests, mais je devrai faire ça sur un microcontrôleur de type AVR.

Systemd qui ne prend plus en comptel a fermeture du couvercle du portable donc surchauffe du processeur et des circuits internes et portable bon pour la casse.

il vaudrait mieux que je crée d'abord le LV avec des disques vides et que je copie les données du disque plein dans mon nouveau LV.

Oui, mais tu peux procéder ainsi :
- créer un volume group sur 1 disque (pvcreate + vgcreate)
- créer ton lv sur ce VG (lvcreate)
- créer ton FS par dessus
- copier tes données de l'ancien disque sur le nouveau disque

Une fois que tu es sur de ton coup, et que cette étape est validée, tu récupère l'ancien disque (sous réserve que tu n'aies pas tes partitions système dessus tel que /usr, /var …) que tu initialises pour utiliser avec lvm (pvcreate)
ensuite tu l'ajoutes à ton vg (vgextend)

Tu peux ensuite étendre ton lv sur ton nouveau disque (lvextend) puis étendre ton fs (resize2fs).

Si c'est juste pour lui une question de se former et qu'il parle juste de faire ça sur sa machine… il est fort probable qu'il soit dans une config très simple sans SAN derrière, et que ça ne lui pose pas spécialement de problème.

Effectivement si c'est juste pour se former sur une machine perso …. celà dit ce n'est pas ce que j'ai cru comprendre en lisant le message, d'ou mon avertissement. Sinon, ce que je dis est aussi valable pour des VM style VMWare, ou on a la possibilité d'agrandir les volumes à chaud.

Sinon une autre possibilité: la virtualisation (kvm/qemu ou virtualbox) et tester du lvm sur des disques et machines virtuelles. Ça permet de casser sans risque, voir de monter des pseudo-volumes physiques et de voir comment le lvm les agrège, etc.

Je trouve cette solution plus propre et moins risquée.

C'est l'expérience qui parle.

Ne fais pas ça : ne mélange surtout pas de partitions LVM et non LVM sur le même disque (sauf la partition /boot sur les systèmes démarrant à partir de Grub Legacy car il n'est pas capable de lire une partition LVM). Et évite de faire un fdisk (toujours exception faite du disque de boot) avant le pvcreate, en particulier si en dessous tu as des volumes qui peuvent être agrandis à chaud (type volumes SAN par exemple). Si tu le fais, ça risque de te compliquer la vie.

Je pensais qu'Unix (et un peu Debian), c'était KISS !

Unix, oui; Mais GNU is Not Unix. Et Debian, c'est : "pourquoi faire simple quand on peut faire compliqué" ( Et je ne parle même pas de GNU/Linux depuis l'arrivée de systemd …).

C'est évident.

Désolé, pas pu m'empêcher … :D (Pour les grincheux, ce commentaire est à but humoristique).

Parait qu'il est bronsonnisé.

Apple n'est pas un fondeur.

Qualcomm n'est pas le premier fondeur.

Ce n'est que du vent