J'ai tenté plusieurs versions minimaliste des linux (DSL, Slack, Puppy…), mais si elle fonctionnent toutes, elles sont vraiment trop minimaliste et ne me conviennent pas.
La question de base c'est que veux-tu faire avec ?
Naviguer aujourd'hui sur Internet avec ce genre de machine, alors que la plupart des sites sont basés sur du javascript exécuté sur navigateur sera certainement difficile.
Je ne parle même pas de suites burautiques, ou de traîtement d'images. Quant à la video … ?
Mais pourquoi vouloir réduire ? Il faut comparer ce qui est comparable. Si tu rajoutes un disque à LVM, est-ce que tu vas le réduire ? La réponse est non, car c'est impossible.
Bien sûr que si, quand tu fais de la réorganisation de données.
Si tu rajoutes une partition qui prend tout le disque, histoire de flagger le disque comme étant un disque LVM, pourquoi vouloir la réduire par la suite ? Il faut comparer des cas d'usages comparables.
D'ou l'intéret de ne PAS mettre de lvm sur ton disque.
J'ai envie de dire que c'est encore plus casse-bonbon si tu rajoutes directement un disque, puisque tu ne peux pas le réduire, à moins de le changer !
Bien sur que si tu peux … man pvresize.
Tout à fait. Et grosso modo, pour un cas d'usage classique, elle recommande simplement de créer une seule et unique partition qui prend tout le disque plutôt que d'utiliser directement le disque, afin de pouvoir marquer la partition comme étant une partition utilisée par LVM.
On s'en fout de "marqauer le disque" comme tu dis. lsblk est bien plus fiable.
Ok, cela en dit long sur le débat. Si on n'est pas d'accord avec toi, c'est qu'on a de mauvaises habitudes.
Non c'est un constat issu de 20 années d'expérience en admin système, avec des problèmes à gérer que je n'aurais pas eu si les admins du dimanche savaient ce qu'ils font et pourquoi (après de mon côté, je sais quye certains ont probablement râlé sur certaines habitudes d'admin du dimanche que j'ai pu avoir - et je me suis déjà ralé dessus d'ailleurs parce que certaines de mes mauvaises habitudes m'ont généré des problèmes inutiles).
Alors donne moi un (juste un, je ne suis pas gourmand) avantage à utiliser directement le disque au lieu d'une partition.
déjà donné : agrandir un disque SAN ou un disque sur une VM.
Aparamment tu n'as pas lu le lien que tu as envoyé …
Au début :
The underlying physical storage unit of an LVM logical volume is a block device such as a partition or whole disk. To use the device for an LVM logical volume the device must be initialized as a physical volume (PV). Initializing a block device as a physical volume places a label near the start of the device.
Et à la fin …
Although it is not recommended, there may be specific circumstances when you will need to divide a disk into separate LVM physical volumes. For example, on a system with few disks it may be necessary to move data around partitions when you are migrating an existing system to LVM volumes.
Donc :
pas recommandé d'avoir un disque séparé en plusieurs PV. Donc exit la solution de créer une partition lorsqu'on agrandit un disque.
si tu crées une seule partition, tu prend des risques et tu te crées du travail inutile à devoir la retailler. Je ne sais même pas si ça se fait à chaud …
Conclusion, pour se faciliter la vie, pas de partition sur les volumes lvm, hormis le disque de boot qui en général contient le disque système et n'est que très rarement agrandi à la volée.
Merci pour le lien .. .ça m'évite de faire des recherches.
Si au moins tu étayais pour dire POURQUOI c'est mieux et plus propre.
Je te l'ai dit : permet d'augmenter l'espace disque disponible sur un volume. Il est beaucoup plus simpmle de le faire sans partition.
J'ai bossé dans des contextes ou l'augmentation d'espace disque ne se faisait pas par ajout de disques mais par augmentation de l'espace alloué à un volume (baies SAN ou VM ). Alors, c'est gentil de vouloir ajouter des partitions, mais pour peu que l'admin du dimanche ait déjà fait ça 4 fois sur des partitions primaires (ce qui m'est déjà arrivé …), t'es emmerdé.
Dans le cas ou tu veux changer un disque défectueux, si tu as ajouté tes partitions LVM sur le même disque, tu te retrouves a devoir déplacer les données de plusieurs pvs aui sens LVM plutot que d'un seul. Risque d'oubli, et plus de boulot inutile.
Ensuite … il m'est déjà arrivé de voir des trucs amusants : disque physique partagé entre plusieurs VG. Ca c'est pas propre. Si tu dédies un disque à un vg, tu n'est pas censé pouvoir faire ce genre de choses. (la encore essaie de remplacer un disque physique qui est partitionné entre plusieurs VG - j'ai pas eu à le faire mais ça m'aurait gonflé)
Une partition, comme son nom l'indique, est un élément qui te permet de découper en partie un disque pour en faire des choses différentes. Je ne comprends pas la logique de "couper en un". La seule raison pour avoir des partitions sur un disque Linux avec du LVM, c'est pour le disque de boot, afin que le hardware puisse lancer le système. En dehors ça ne cause plus de problèmes que de solutions.
Quand on travaille sur des volumes SAN ou des VMs qui permettent l'extension de disque à chaud, on en vient vite à haïr les partitions sur des disques autre que les disques de démarrage.
Après chez soi, chacun fait ce qu'il veut, mais sur des serveurs pro …
J'ai toujours vu du LVM sur des partitions, non sur les disques eux-mêmes (bien que cela soit possible, on est d'accord).
C'est dû a de mauvaises habitudes …
Sur des systèmes bien faits (AIX, HP-UX), aucune partition pour les pv que tu ajoutes. Les partitions sur du LVM sous Linux sont pour beaucoup des pratiques d'admin du dimanche qui ne savent pas ce qu'ils font et qui sont en mode pavlov (Disque => Partition => lvm (ou autre chose …).
C'est classique (on s'attend à des partitions sur un disque),
Pourquoi faire ? A quoi sert une partition sur un disque?
Pour moi et (et je pense beaucoup d'administrateurs systèmes), un disque sans partitions (MBR ou GPT) c'est un disque non formaté (et donc non utilisé).
Parce que ce sont des admin systèmes qui ont de mauvaises habitudes.
J’avoue. Mais j’ai l’habitude de toujours créer une partition, même unique. L’avantage, c’est qu’on contrôle précisément sa taille, ce qui est utile quand on assemble des volumes RAID avec des disques dont les tailles peuvent être légèrement différentes.
Mauvaise habitude. Elle est peut-être utile pour du raid (là je ne vois pas l'intéret dans l'immédiat), mais pour lvm c'est complètement inutile. Dans le cas de VM, ça pousse à faire des manips délicates ou d'avoir un truc crade quand on veut étendre le disque, alors qu'étendre le PV se fait à chaud avec 1 commande (je t'avoue que quand je tombe sur ce cas de figure, je demande un plus gros disque et je déplace les données sur un disque propre, mais ça fait du travail inutile et de la perte de temps pour tout le monde).
Désolé, j’ai davantage l’habitude de manipuler des disques bien réels, du genre qu’on ne peut pas étendre à coup de qemu-img resize.
La on parle de VM … avec des disques bien souvent de l'ordre de la vingtaine de GB. Et il est souvent avantageux sur ce type de VM d'ajouter de l'espace sur un disque existant que d'ajouter des disques. Après ça nécessite de changer un peu ses habitudes.
Ca m'a déjà été utile de procéder comme ça sur un disque physique qui commençait à rendre l'ame : récupération du disque avec ddrescue sur un disque plus gros, et extension du pv via lvm, sans avoir à jouer avec les tables de partition.
Disons que la VM a maintenant un deuxième disque sdb, avec une seule partition sdb1
Surtout pas malhereux …
Tu vas faire comment si tu dois étendre le disque ?
Pas besoin de partitionner le disque, il suffit juste de faire un pvcreate sur /dev/sdb. Le partitionnement sur le disque de boot n'a de raison d'être que pour démarrer la machine.
Je pensais, en effet, que la question du sens comme celle de la qualité du projet que défendent des entrepreneurs était la clé pour chacun d'entre vous. J'ai parfois l'impression d'en être bien loin.
Il faudrait qu'il retourne sur le terrain … La qualité pour beaucoup ça n'a pas de sens … Aujourd'hui on veut délivrer vite quitte à rogner sur la qualité, en ne raisonnant qu'à court terme et en faisant trimer justement ceux qui demandent des salaires mirobolants. Parce que justement le manque de qualité fait qu'on a besoin de personnes qui coutent cher pour rattraper les problèmes à la volée. Non seulement faut être doué mais faut aussi avoir du temps … et le temps c'est de l'argent (parce que faut pas rever … un bug de prod tous les jours qui fait que les personnes vont faire 50h par semaine au lieu de 35, les employeurs ne paieront pas … donc faut bien trouver son compte).
Ah puis ya aussi l'aspect éthique : pouvoir forcer qqn à bypasser ses principes pour livrer de la merde qui brulerea dans les semaines a venir … ça se paye. PErso faut me payer très cher pour me forcer à faire quelque chose en dehors de mes convictions.
A force de chercher l'offre mieux disante sans réfléchir à la réelle construction de carrière, sans faire le choix du manager qui va faire grandir et qui va inspirer, vous allez limiter les discussions avec vos futurs employeurs aux simples aspects transactionnels.
Ce mec n'a pas mis les pieds dans une entreprise depuis des années, surtout en société de services.
Les managers "qui vous font grandir" sont très rares. En général le manager va chercher à se faire grandir lui même bien souvent au détriment de son quipe, qui va devoir trimer pour que le manager puisse cacher a ses N+1, N+x son incompétence, et ça s'ajoute à chaque mlaillon de la chaine.
Sans parler des formations qui sont assez rares de nos jours …
Perso je connais pas mal de personnes qui demandent un salaire élevé, et qui sur ce salaire se payent les formations que leur employeur "censé les faire grandir" ne leur donne pas.
Pendant longtemps la plupart des distributions ont utilisé le sysvinit de Miquel van Smoorenburg sans que personne ne semble s’inquiéter d’un manque d’hétérogénéité.
Certes mais je pouvais facilement m'en passer et utiliser un autre système d'init …
Pendant longtemps la plupart des distributions ont utilisé le sys(k)logd de Greg Wettstein and Stephen Tweedie sans que personne ne semble s’inquiéter…
Oui mais je pouvais facilement utiliser une alternative.
Il y a sûrement des choses à critiquer dans systemd (citez-moi un programme qui ne soit pas critiquable), mais à mon avis pas celle-là.
Ca en plus du fait que systemd ne se contente pas d'être un système de démarrage ?
1.C'est pas genre un cheval mort le meme Systemd aujourd'hui ?
C'est à dire ?
Tu confondrais pas Systemd et le kernel ?
Non
Si tu considère que tout le monde a une version du kernel Linux différente (argument de hétérogénéité) pourquoi ça serait pas pareil pour Systemd, qui évolue très vite lui aussi ?
Bien sûr, mais c'est pas parce que le noyau est un potentiel vecteur d'attaque commun qu'on doit en poser d'autres …
4.Pourquoi te focaliser sur Systemd ? Il t'a fait mal quelque part ?
Honnêtement, sur ma machine je fais attention quand certaines librairies se mettent à jour
et j'ai toujours une appréhension quand je reboote suite à un changement noyau (même si je sais comment me sortir de ce genre de problème)
Pour moi c'est exactement ça … Je veux choisir de faire mes mises à jour au moment ou je peux potentiellement passer du temps à dépanner (et pas quand je dois imprimer en urgence un courrier important).
De ton côté tu vois les avantages d'un mode de fonctionnement, que je ne remets nullement en cause. Mais c'est juste avoir des oeilleres et refuser de voir que ce que tu fais ne peut pas forcément être fait ailleurs.
Sur d'anciens desktops ou laptops, le boot USB ne marche simplement pas (j'ai un vieux fujitsu comme ça). Sans ISO tu ne peux rien faire.
Ensuite, il est difficile chez certains hébergeurs de ne monter autre chose qu'une image iso popur un boot (ou rescue).
Perso, je préfère largement le stick usb, mais l'iso n'est certainement pas encore à jeter. Pourquoi ne pas laisser encore les deux cohabiter tranqulliement ?
Et c'est, évidemment, problématique et aberrant puisqu'on perd l'essentiel quand on veut commenter (encore des choix technique de mon point de vue peu réfléchis).
Ouai c'est ce que vendent tous les concepteurs de langages, ça permet de démarrer avec quelque chose.
Perso je ne suis pas fan des bindings …. Pour moi c'est un mal nécessaire en attendant de trouver mieux.
ça ne marche pas toujours très bien (en rust par exemple c'est compliqué de maintenir les propriétés du langage)
C'est effectivement une des raisons pour lesquelles je n'aime pas le binding … mais d'un autre coté ça permet, comme tu le dis, pour quelqu'un qui veut déjà faire la transition d'un soft écrit dans un langage donné vers un autre de commencer par quelque chose. Mais l'idéal c'est que ça reste transitoire.
La masse de bibliothèque c, java, python et js est absolument délirante
Oui, mais peut-être un peu trop pour certains langages (JS). En rust ça commence à venir … mais c'est clair que ça ne se fera pas du jour au lendemain. Cela dit certains gros acteurs du logiciel s'y mettent, j'espère que ça accélerera les choses.
À l'époque où je m'étais amusé avec go faire de l'amqp ça ne se faisait pas trop avec la dernière version du langage.
La tu mets le doigt sur ce qui est pour moi un besoin des langages bas niveaux tels que C, C++, Ada et rust : une stabilité de la norme, qui permettra d'implémenter des surcouches qui elles se baseront sur un socle stable. Ca vient je pense … Si on regarde deux ou trois ans en arrière (l'époque ou j'ai commencé à m'intéresser à Rust), on sent qu'il y a des choses qui bougent, un certain engouement. Apres, c'est pas impossible que cet engouement ne reste pas.
Maintenant, juste pour préciser … je ne suis pas un "fanboy" de Rust … Je ne suis pas convaincu qu'il faille convertir en rust tous les programmes écrits en C, et je sais que Rust a ses défauts, mais je suis d'avis que Rust remplacera avantageusement C dans beaucoup de cas d'usage ou le C impose de se creuser la tête et fait prendre des risques sur la sécurité. A l'inverse je crois également que certains bout de code n'aurnt aucun intéret a être réécrits en Rust parce qu'ils sont très bien comme ils sont, font le boulo, avec une mémoire qui a été bien gérée par le développeur.
On dit des fois qu'il faut être 10 ou 100 fois meilleur pour créer une conversion.
De mon avis … Je partazge ton point de vue sur une bonne partie de ce que tu dis. PAr contre pour Rust par rapport au C, je pense qu'il y a un faisceau d'éléménts qui plaident en sa faveur, dont un particulier : le coté gestion safe de la mémoire contrôlé à la compilation, sans (trop) d'impact au runtime. Et ça c'est quelque chose qu'on ne trouve pas en C, et qui dans les systèmes modernes est de plus en plus problématique. De mon avis … il faudrait que le C évolue pour permettre nativement une gestion safe de la mémoire de la même façon pour ne pas être abandonné progressivement.
Perso ça ne me choque pas, le C malgré ses nombreux défauts est un bon langage, qui a rendu de très bon services. Il n'a pas a rougir de ses défauts, on a su s'adapter …
Pour moi tu as juste oublié le seul langage à ma connaissance qui serait pertinent de citer dans ta liste : forth.
Je trouve ça dommage car c'est un langage que je trouve intéressant. Cela dit aujourd'hui je ne suis pas sûr que ce soit une bonne idée de l'utiliser pour un nouveau projet.
Ah ? Vu le nombre d'applications écrites avec Java, Javascript, Python… Le pourcentage doit être élevé.
Oui, 90% n'est pas un faible pourcentage … ça reste élevé. Mais je reste convaincu qu'il y a plus de 1% d'applications qui ne pourraient pas fonctionner avec un GC (enfin tel qu'ils sont implémentés aujourd'hui).
# Ne t'attend pas forcément à grand chose pour cette machine
Posté par totof2000 . En réponse au message Vieux matériel. Évalué à 4.
La question de base c'est que veux-tu faire avec ?
Naviguer aujourd'hui sur Internet avec ce genre de machine, alors que la plupart des sites sont basés sur du javascript exécuté sur navigateur sera certainement difficile.
Je ne parle même pas de suites burautiques, ou de traîtement d'images. Quant à la video … ?
# Robots basés sur micro:bit
Posté par totof2000 . En réponse au journal Le Père Noël, Linux et les robots. Évalué à 3. Dernière modification le 28 décembre 2021 à 10:54.
https://www.kubii.fr/190-robots-microbit
https://learn.adafruit.com/microbit-crickit-robot
https://www.lextronic.fr/robot-simple-robotics-kit-pour-microbit-54243.html
https://www.kubii.fr/190-robots-microbit
https://www.generationrobots.com/fr/437-micro-bit
https://www.waveshare.com/kitibot-for-micro-bit-acce-c.htm
https://www.mouser.fr/new/dfrobot/dfrobot-micro-maqueen-robot/?gclid=CjwKCAiAiKuOBhBQEiwAId_sK6MdJALNF5BIfEdBD8eCcYiy1FE7XWwmP5AyeXqcBNdZ2zvG7Fu0eBoCDrMQAvD_BwE
https://www.dfrobot.com/category-140.html?sort=p.date_added&order=DESC
Certains de ces robots disposent de libs python pour être programmés.
Il y a des versions plus ou moins opensource. A toi de chercher et de trouver ton bonheur.
[^] # Re: hou la ça remonte a loin ;)
Posté par totof2000 . En réponse au message Mais à qui appartient cette partition ?. Évalué à 0.
Bien sûr que si, quand tu fais de la réorganisation de données.
D'ou l'intéret de ne PAS mettre de lvm sur ton disque.
Bien sur que si tu peux … man pvresize.
On s'en fout de "marqauer le disque" comme tu dis. lsblk est bien plus fiable.
[^] # Re: hou la ça remonte a loin ;)
Posté par totof2000 . En réponse au message Mais à qui appartient cette partition ?. Évalué à 2.
Non c'est un constat issu de 20 années d'expérience en admin système, avec des problèmes à gérer que je n'aurais pas eu si les admins du dimanche savaient ce qu'ils font et pourquoi (après de mon côté, je sais quye certains ont probablement râlé sur certaines habitudes d'admin du dimanche que j'ai pu avoir - et je me suis déjà ralé dessus d'ailleurs parce que certaines de mes mauvaises habitudes m'ont généré des problèmes inutiles).
déjà donné : agrandir un disque SAN ou un disque sur une VM.
[^] # Re: hou la ça remonte a loin ;)
Posté par totof2000 . En réponse au message Mais à qui appartient cette partition ?. Évalué à 3.
Aparamment tu n'as pas lu le lien que tu as envoyé …
Au début :
The underlying physical storage unit of an LVM logical volume is a block device such as a partition or whole disk. To use the device for an LVM logical volume the device must be initialized as a physical volume (PV). Initializing a block device as a physical volume places a label near the start of the device.
Et à la fin …
Although it is not recommended, there may be specific circumstances when you will need to divide a disk into separate LVM physical volumes. For example, on a system with few disks it may be necessary to move data around partitions when you are migrating an existing system to LVM volumes.
Donc :
pas recommandé d'avoir un disque séparé en plusieurs PV. Donc exit la solution de créer une partition lorsqu'on agrandit un disque.
si tu crées une seule partition, tu prend des risques et tu te crées du travail inutile à devoir la retailler. Je ne sais même pas si ça se fait à chaud …
Conclusion, pour se faciliter la vie, pas de partition sur les volumes lvm, hormis le disque de boot qui en général contient le disque système et n'est que très rarement agrandi à la volée.
Merci pour le lien .. .ça m'évite de faire des recherches.
[^] # Re: hou la ça remonte a loin ;)
Posté par totof2000 . En réponse au message Mais à qui appartient cette partition ?. Évalué à 2.
Je te l'ai dit : permet d'augmenter l'espace disque disponible sur un volume. Il est beaucoup plus simpmle de le faire sans partition.
J'ai bossé dans des contextes ou l'augmentation d'espace disque ne se faisait pas par ajout de disques mais par augmentation de l'espace alloué à un volume (baies SAN ou VM ). Alors, c'est gentil de vouloir ajouter des partitions, mais pour peu que l'admin du dimanche ait déjà fait ça 4 fois sur des partitions primaires (ce qui m'est déjà arrivé …), t'es emmerdé.
Dans le cas ou tu veux changer un disque défectueux, si tu as ajouté tes partitions LVM sur le même disque, tu te retrouves a devoir déplacer les données de plusieurs pvs aui sens LVM plutot que d'un seul. Risque d'oubli, et plus de boulot inutile.
Ensuite … il m'est déjà arrivé de voir des trucs amusants : disque physique partagé entre plusieurs VG. Ca c'est pas propre. Si tu dédies un disque à un vg, tu n'est pas censé pouvoir faire ce genre de choses. (la encore essaie de remplacer un disque physique qui est partitionné entre plusieurs VG - j'ai pas eu à le faire mais ça m'aurait gonflé)
Une partition, comme son nom l'indique, est un élément qui te permet de découper en partie un disque pour en faire des choses différentes. Je ne comprends pas la logique de "couper en un". La seule raison pour avoir des partitions sur un disque Linux avec du LVM, c'est pour le disque de boot, afin que le hardware puisse lancer le système. En dehors ça ne cause plus de problèmes que de solutions.
[^] # Re: hou la ça remonte a loin ;)
Posté par totof2000 . En réponse au message Mais à qui appartient cette partition ?. Évalué à 1.
Mais pourquoi faire ça ?
Pour moi : 1 PV (physical volmume) = 1 disque.
La encore, pourquoi faire ça ?
[^] # Re: hou la ça remonte a loin ;)
Posté par totof2000 . En réponse au message Mais à qui appartient cette partition ?. Évalué à 3.
Pour appuyer mon point de vue :
https://www.redhat.com/sysadmin/lvm-vs-partitioning
https://unix.stackexchange.com/questions/252353/does-lvm-need-a-partition-table
Quand on travaille sur des volumes SAN ou des VMs qui permettent l'extension de disque à chaud, on en vient vite à haïr les partitions sur des disques autre que les disques de démarrage.
Après chez soi, chacun fait ce qu'il veut, mais sur des serveurs pro …
[^] # Re: hou la ça remonte a loin ;)
Posté par totof2000 . En réponse au message Mais à qui appartient cette partition ?. Évalué à 1.
C'est dû a de mauvaises habitudes …
Sur des systèmes bien faits (AIX, HP-UX), aucune partition pour les pv que tu ajoutes. Les partitions sur du LVM sous Linux sont pour beaucoup des pratiques d'admin du dimanche qui ne savent pas ce qu'ils font et qui sont en mode pavlov (Disque => Partition => lvm (ou autre chose …).
Pourquoi faire ? A quoi sert une partition sur un disque?
Parce que ce sont des admin systèmes qui ont de mauvaises habitudes.
[^] # Re: hou la ça remonte a loin ;)
Posté par totof2000 . En réponse au message Mais à qui appartient cette partition ?. Évalué à 1. Dernière modification le 22 décembre 2021 à 10:37.
Mauvaise habitude. Elle est peut-être utile pour du raid (là je ne vois pas l'intéret dans l'immédiat), mais pour lvm c'est complètement inutile. Dans le cas de VM, ça pousse à faire des manips délicates ou d'avoir un truc crade quand on veut étendre le disque, alors qu'étendre le PV se fait à chaud avec 1 commande (je t'avoue que quand je tombe sur ce cas de figure, je demande un plus gros disque et je déplace les données sur un disque propre, mais ça fait du travail inutile et de la perte de temps pour tout le monde).
La on parle de VM … avec des disques bien souvent de l'ordre de la vingtaine de GB. Et il est souvent avantageux sur ce type de VM d'ajouter de l'espace sur un disque existant que d'ajouter des disques. Après ça nécessite de changer un peu ses habitudes.
Ca m'a déjà été utile de procéder comme ça sur un disque physique qui commençait à rendre l'ame : récupération du disque avec ddrescue sur un disque plus gros, et extension du pv via lvm, sans avoir à jouer avec les tables de partition.
[^] # Re: hou la ça remonte a loin ;)
Posté par totof2000 . En réponse au message Mais à qui appartient cette partition ?. Évalué à 1. Dernière modification le 21 décembre 2021 à 23:06.
Crade !!! en plus ça sert à rien. Laisse les choses propores pour ceux qui doivent passer derriere toi STP.
[^] # Re: hou la ça remonte a loin ;)
Posté par totof2000 . En réponse au message Mais à qui appartient cette partition ?. Évalué à 1.
Surtout pas malhereux …
Tu vas faire comment si tu dois étendre le disque ?
Pas besoin de partitionner le disque, il suffit juste de faire un pvcreate sur /dev/sdb. Le partitionnement sur le disque de boot n'a de raison d'être que pour démarrer la machine.
[^] # Re: Une solution: le revenu universel unique
Posté par totof2000 . En réponse au lien Chasseurs de têtes : arrêtez de demander plus que le SMIC. Évalué à 3.
Dans certains pays on éduque les enfants à planter des légumes, ou à fabriquer des vêtements, ou des jouets, ou des smartphones …
# La qualité ... Mort de rire ...
Posté par totof2000 . En réponse au lien Chasseurs de têtes : arrêtez de demander plus que le SMIC. Évalué à 10.
Il faudrait qu'il retourne sur le terrain … La qualité pour beaucoup ça n'a pas de sens … Aujourd'hui on veut délivrer vite quitte à rogner sur la qualité, en ne raisonnant qu'à court terme et en faisant trimer justement ceux qui demandent des salaires mirobolants. Parce que justement le manque de qualité fait qu'on a besoin de personnes qui coutent cher pour rattraper les problèmes à la volée. Non seulement faut être doué mais faut aussi avoir du temps … et le temps c'est de l'argent (parce que faut pas rever … un bug de prod tous les jours qui fait que les personnes vont faire 50h par semaine au lieu de 35, les employeurs ne paieront pas … donc faut bien trouver son compte).
Ah puis ya aussi l'aspect éthique : pouvoir forcer qqn à bypasser ses principes pour livrer de la merde qui brulerea dans les semaines a venir … ça se paye. PErso faut me payer très cher pour me forcer à faire quelque chose en dehors de mes convictions.
[^] # Re: AH ah ah
Posté par totof2000 . En réponse au lien Chasseurs de têtes : arrêtez de demander plus que le SMIC. Évalué à 10.
Ce mec n'a pas mis les pieds dans une entreprise depuis des années, surtout en société de services.
Les managers "qui vous font grandir" sont très rares. En général le manager va chercher à se faire grandir lui même bien souvent au détriment de son quipe, qui va devoir trimer pour que le manager puisse cacher a ses N+1, N+x son incompétence, et ça s'ajoute à chaque mlaillon de la chaine.
Sans parler des formations qui sont assez rares de nos jours …
Perso je connais pas mal de personnes qui demandent un salaire élevé, et qui sur ce salaire se payent les formations que leur employeur "censé les faire grandir" ne leur donne pas.
[^] # Re: Linux n'est pas uniforme
Posté par totof2000 . En réponse au journal Coût de piratage des serveurs Linux. Évalué à 3.
Par contre ici on arrive à faire courir les aficionados du canasson … :)
[^] # Re: Linux n'est pas uniforme
Posté par totof2000 . En réponse au journal Coût de piratage des serveurs Linux. Évalué à 2.
Certes mais je pouvais facilement m'en passer et utiliser un autre système d'init …
Oui mais je pouvais facilement utiliser une alternative.
Ca en plus du fait que systemd ne se contente pas d'être un système de démarrage ?
[^] # Re: Linux n'est pas uniforme
Posté par totof2000 . En réponse au journal Coût de piratage des serveurs Linux. Évalué à 2.
C'est à dire ?
Non
Bien sûr, mais c'est pas parce que le noyau est un potentiel vecteur d'attaque commun qu'on doit en poser d'autres …
Oui.
[^] # Re: Linux n'est pas uniforme
Posté par totof2000 . En réponse au journal Coût de piratage des serveurs Linux. Évalué à 4.
Pour moi c'est exactement ça … Je veux choisir de faire mes mises à jour au moment ou je peux potentiellement passer du temps à dépanner (et pas quand je dois imprimer en urgence un courrier important).
[^] # Re: Entièrement d'accord
Posté par totof2000 . En réponse au lien L'heure de la retraite pour les images ISO des distributions ?. Évalué à 3.
De ton côté tu vois les avantages d'un mode de fonctionnement, que je ne remets nullement en cause. Mais c'est juste avoir des oeilleres et refuser de voir que ce que tu fais ne peut pas forcément être fait ailleurs.
Sur d'anciens desktops ou laptops, le boot USB ne marche simplement pas (j'ai un vieux fujitsu comme ça). Sans ISO tu ne peux rien faire.
Ensuite, il est difficile chez certains hébergeurs de ne monter autre chose qu'une image iso popur un boot (ou rescue).
Perso, je préfère largement le stick usb, mais l'iso n'est certainement pas encore à jeter. Pourquoi ne pas laisser encore les deux cohabiter tranqulliement ?
[^] # Re: Et pour les dépêches
Posté par totof2000 . En réponse à l’entrée du suivi Pouvoir voir le contenu et le fil des commentaires quand on veut commenter. Évalué à 1 (+0/-0).
Encore du dénigrement …
[^] # Re: Comparer Go et Rust, c'est comme si on comparait une F1 et un 38 tonnes.
Posté par totof2000 . En réponse au lien Rust versus Go : round 1, fight !. Évalué à 2.
Perso je ne suis pas fan des bindings …. Pour moi c'est un mal nécessaire en attendant de trouver mieux.
C'est effectivement une des raisons pour lesquelles je n'aime pas le binding … mais d'un autre coté ça permet, comme tu le dis, pour quelqu'un qui veut déjà faire la transition d'un soft écrit dans un langage donné vers un autre de commencer par quelque chose. Mais l'idéal c'est que ça reste transitoire.
Oui, mais peut-être un peu trop pour certains langages (JS). En rust ça commence à venir … mais c'est clair que ça ne se fera pas du jour au lendemain. Cela dit certains gros acteurs du logiciel s'y mettent, j'espère que ça accélerera les choses.
La tu mets le doigt sur ce qui est pour moi un besoin des langages bas niveaux tels que C, C++, Ada et rust : une stabilité de la norme, qui permettra d'implémenter des surcouches qui elles se baseront sur un socle stable. Ca vient je pense … Si on regarde deux ou trois ans en arrière (l'époque ou j'ai commencé à m'intéresser à Rust), on sent qu'il y a des choses qui bougent, un certain engouement. Apres, c'est pas impossible que cet engouement ne reste pas.
Maintenant, juste pour préciser … je ne suis pas un "fanboy" de Rust … Je ne suis pas convaincu qu'il faille convertir en rust tous les programmes écrits en C, et je sais que Rust a ses défauts, mais je suis d'avis que Rust remplacera avantageusement C dans beaucoup de cas d'usage ou le C impose de se creuser la tête et fait prendre des risques sur la sécurité. A l'inverse je crois également que certains bout de code n'aurnt aucun intéret a être réécrits en Rust parce qu'ils sont très bien comme ils sont, font le boulo, avec une mémoire qui a été bien gérée par le développeur.
[^] # Re: Comparer Go et Rust, c'est comme si on comparait une F1 et un 38 tonnes.
Posté par totof2000 . En réponse au lien Rust versus Go : round 1, fight !. Évalué à 2.
De mon avis … Je partazge ton point de vue sur une bonne partie de ce que tu dis. PAr contre pour Rust par rapport au C, je pense qu'il y a un faisceau d'éléménts qui plaident en sa faveur, dont un particulier : le coté gestion safe de la mémoire contrôlé à la compilation, sans (trop) d'impact au runtime. Et ça c'est quelque chose qu'on ne trouve pas en C, et qui dans les systèmes modernes est de plus en plus problématique. De mon avis … il faudrait que le C évolue pour permettre nativement une gestion safe de la mémoire de la même façon pour ne pas être abandonné progressivement.
Perso ça ne me choque pas, le C malgré ses nombreux défauts est un bon langage, qui a rendu de très bon services. Il n'a pas a rougir de ses défauts, on a su s'adapter …
[^] # Re: Comparer Go et Rust, c'est comme si on comparait une F1 et un 38 tonnes.
Posté par totof2000 . En réponse au lien Rust versus Go : round 1, fight !. Évalué à 2.
Pour moi tu as juste oublié le seul langage à ma connaissance qui serait pertinent de citer dans ta liste : forth.
Je trouve ça dommage car c'est un langage que je trouve intéressant. Cela dit aujourd'hui je ne suis pas sûr que ce soit une bonne idée de l'utiliser pour un nouveau projet.
[^] # Re: Le choix est simple
Posté par totof2000 . En réponse au lien Rust versus Go : round 1, fight !. Évalué à 1.
Oui, 90% n'est pas un faible pourcentage … ça reste élevé. Mais je reste convaincu qu'il y a plus de 1% d'applications qui ne pourraient pas fonctionner avec un GC (enfin tel qu'ils sont implémentés aujourd'hui).