Oui c'est ça le problème, vi est préinstallé par défaut sur les distro Linux et pas Emacs.
Je suis d'accord, vi est installé par défaut, mais le shell est par défaut en mode emacs, c'est un truc que je n'ai jamais compris sur les UNIX et UNIX like…
Oui, surtout que je ne comprenais tellement pas ce que tu disais que je t'ai relu 3 ou 4 fois avant de faire un test. J'ai fait le test et je me suis dit que ça faisait trop longtemps qu'il n'avait plus utilisé cut ;)
Je pense que tu sous estimes les capacités de filtrage de awk, grep et cut sont très efficaces dans beaucoup de cas mais awk pour le filtrage complexe à de gros avantages.
Je n'ai regardé que le premier lien et il est illisible, faire des copier/coller avec les flags markdown qui vont bien n'auraient-ils pas été plus lisible et accessible pour tout le monde ?
C'est quoi cette manie des screenschots ? De la windoserie de merde adapter à Linux ?
La notation octale a la peau dur malgré l’incompréhension de son fonctionnement par la grande majorité des utilisateurs.
La notation symbolique a été inventée depuis longtemps à cause de ça, par exemple le symbole pour lecture est 'r' (read), l'écriture 'w' (write), l'exécution 'x' (execute).
Si tu veux appliquer des droits à au propriétaire (user) tu utilises la lettre 'u' au groupe la lettre 'g' au reste du monde la lettre 'o' (others).
Ex : chmod u=rw,go=r toto Propriétaire (User) = read et write, group et others = read only.
'=' tu appliques un droit
'+' tu ajoutes un droit, ex sur l'exemple précédent ajouter le droit d'écriture au groupe : chmod g+w toto
'-' tu retires un droit, ex sur l'exemple précédent supprimer le droit de lecture au monde : chmod o-r toto
[kangs<<test>>:0s:tmp]$ touch toto
[kangs<<test>>:1s:tmp]$ chmod u=rw,go=r toto
[kangs<<test>>:0s:tmp]$ ll toto
-rw-r--r--+ 1 kangs users 0 1 mars 19:17 toto
[kangs<<test>>:0s:tmp]$ chmod g+w toto
[kangs<<test>>:0s:tmp]$ ll toto
-rw-rw-r--+ 1 kangs users 0 1 mars 19:17 toto
[kangs<<test>>:0s:tmp]$ chmod o-r toto
[kangs<<test>>:0s:tmp]$ ll toto
-rw-rw----+ 1 kangs users 0 1 mars 19:17 toto
Ça se mémorise vite et tu évites les erreurs bêtes, après ça ce n'est que la base, man chmod pour plus d'infos.
Le plus gros de l'énervement est qu'il ne semble pas connaître le monde de la production, en production une défaillance (les dégradations de performance en font partie) ont un coût. Quand on est DBA de production on a pour objectif de rendre le service optimal le plus vite possible. On peut éventuellement donner des avis/conseilles mais ils ne seront pas entendus.
Le manager ne va pas financer une correction si le problème est résolu par des options du SGBDR. Il pensera que c'était un problème du SGBDR mais pas du code. Si le problème devient récurrent et pèse financièrement, que ma hiérarchie est convaincue par mes arguments alors une discussion devient possible. Mes boss parlent avec les autres boss, s'ils sont convaincus (et il y a de gros lourd) alors on pourra (les DBA) discuter avec les dev.
Ensuite faut pas rêver, je fais partie de la génération ou avant d'être admin de quoi que ce soit il fallait avoir été développeur, donc je peux facilement discuter et coder si je connais le langage. Beaucoup de mes jeunes collègues sont directement arrivés en production, ils ne connaissent rien au dev. Certain apprennent vite les principes fondamentaux du SQL, d'autres ne supportent même pas l'idée de devoir coder (même du ksh).
Le gros énervement vient donc du fait qu'il pense que les DBA et les dev devraient plus discuter, mais vu ces arguments j'ai l'impression qu'il n'a jamais essayé de discuter avec des DBA de productions pour connaître leurs attentes principales d'un SGBDR. J'ai l'impression qu'il développe un logiciel destiner à la production sans savoir ce qu'est une production.
ACID, je pense que les devs connaissent (en tout cas, l'acronyme me parle, et une rapide lecture semble indiquer que c'est assez proche de ma façon d'écrire), par contre le reste, je veux bien à minima une explication rapide. Ou, au pire, un lien vers une explication qui soit relativement accessible au dev que je suis.
La forme normale est une façon de concevoir un schéma transactionnel, le but étant par exemple d'éviter les 'deadlock', faciliter la concurrence etc. La plus connue et la plus utilisée étant la 3iéme forme normale (3NF) il y en a d'autre, mais je ne pense pas les avoir vus implémentées.
Write Ahead Mode, quand tu fais des insert, update, delete ils ne sont pas faits sur le disque mais en mémoire (sous Oracle et je pense les autres éditeurs aussi, il y a des cas particulier comme pour les LOB), mais toutes les instructions d'une transaction sont loguées dans un journal de transaction, le coût de l'IO tu l'as uniquement au commit, car avant de rendre la main le moteur doit te garantir qu'il pourra rejouer les instructions s'il y a un plantage. Bien sur les blocs mémoire sont écrits sur le disque, mais de façon asynchrone, d’où l'importance de la taille du cache pour les bases OLTP s’il y a beaucoup de transactions concurrentes.
Par contre, de mon point de vue, c'est sale. Une BDD faite correctement ne devrais pas exposer son modèle physique, juste une liste de procédures stockées, une API en fait.
J'ai essayé de l'expliquer 1 000 fois, on m'a systématiquement répondu trop de boulot…
J'ai même abandonné d'essayer d'expliquer la différence entre une jointure et un filtre.
Cela étant dit, je le répète, c'est aux SGBDR de s'adapter aux pratiques majoritaires. C'est comme ça que l'informatique évolue.
Aujourd’hui on doit gérer des applications dont le moyen de persistance est une abstractions. Je ne sais pas si c'est bien ou non, mais la masse fait que l'on va dans se sens. C'est aux éditeurs de s'adapter (et c'est ce qu'il font) de proposer des solutions "génériques" qui correspondent à ce que la majorité fait.
Entendre en développeur tenir un discourt datant des années 90 en 2018 me consterne.
Il ne faut toutefois pas tomber dans le piège de la reproduction à l’identique. Prenons le cas des hints dans Oracle, par exemple. Cela permet à un DBA de modifier les plans d’exécution des requêtes écrites par les développeurs, sans toucher à l’application. Cela permet de corriger certains défauts de l’application, sans parler avec les développeurs, ce qui, au final, n’est pas forcément une bonne chose, car c’est une occasion perdue d’échanger avec eux, de les faire monter en compétence sur les sujets liés à l’utilisation de la base de données. Et puis, surtout, d’une version à l’autre de votre SGBD les hints peuvent changer de manière assez drastique, obligeant à revoir l’ensemble des requêtes arrangées.
Les grosses applications en entreprise sont basées sur SAP, SIEBEL, PEOPLESOFT (pour les plus connus) et sont très critiques, beaucoup de logiciels de niches sont développés par des startups et sont très critiques, beaucoup d'applications propres à une entreprise sont basées sur des frameworks qui génèrent le code SQL et sont plus ou moins critiques.
LE point commun de toutes ces applications : ON S'EN BRANLE DU SGBDR !
Donc aujourd'hui le strict minimum que doit apporter un SGBDR aux DBA, c'est de pouvoir ajouter des hints à la volée, interdire des plans, stabiliser un ensemble de plans & co. Ces entreprises (SAP étant une exception) ne vont pas faire beaucoup d'efforts et les startups n'en font presque pas voir pas du tout.
J'ai vécu un enfer avec une base spatiale (d'une startup) pour les réseaux ferrés en Oracle 9i, le CBO n'intervenait pas dans les requêtes spatiales (le plan était produit uniquement à partir d'heuristiques), il fallait donc les aider avec des hints, mais en 9i seul les développeurs pouvaient les ajouter ! Et ils nous ont menés en bateau pendant des mois et n'ont jamais rien fait. Aujourd'hui j'aurais pu résoudre, je pense, les problèmes de performance avec les outils disponibles.
Il faut arrêter avec ce pseudo dialogue avec les développeurs, il existe très peu et est juste parfois impossible à cause des outils utilisés.
Aujourd'hui ont (les DBA mais tout type d'administrateurs) gère des parcs de 100 à 2000 serveurs de productions avec j'aimais plus de 18 DBA, on est évalué sur le temps passé à résoudre un problème pas à discuter avec les équipes de devs. Le SQL et le SGBDR ne sont pas le langage et outil préférés (ou maîtrisés) des développeurs. Beaucoup voient un SGBDR comme un système de fichier portable (d'ailleurs sur ce site de nombreuse dépêches et commentaire vont dans se sens). Donc le jour ou les écoles (peu importe le niveau) enseigneront les principes fondamentaux comme les transactions (résumées par ACID), ce qu'est une 3NF et le W.A.L modes cela pourra peut-être évolué, mais pour l'instant c'est le SGBDR qui s'adaptent aux pratiques majoritaires des développeurs et à leur déchargent chaque SGBDR va se comporter différemment (le CBO ne serra jamais parfais) ! Donc c'est aux SGBDR de fournir des outils pour adapter le code, le dév ne pourra pas faire une version par SGBDR.
de là, je vois que vous conseillez plus KVM que Vbox, avec comme "gestionnaire" virt-manager OU promox ?
Donc sous linux, pour utiliser KVM tu as le choix entre virt-manager ou VirtualBox (je ne connais pas promox). Ce sont des interfaces différentes. (Sous MSWindows Vbox utilise Hyper-V)
Le point positif de VirtualBox c'est qu'il est disponible sur les Linux, MSWindows, Mac OS X, Solaris.
Le problème avec VirtualBox ce sont les extensions que tu peux télécharger gratuitement (ta distribution ne peut pas les fournir), mais elles sont considérées par Oracle comme des démos et sont sous licence propriétaires, il faut payer pour avoir un support (et les patchs je pense).
Il me semble que les 2 sont intégrés au noyau. Je pense qu'ils sont équivalents pour un usage personnel / basique.
Pas vraiment.
xen (citrix) n'est pas intégré au noyau officiel car citrix n'a pas voulu suivre les méthodes d'intégrations des développeurs du kernel linux (plein de petits patchs vs un gros patch).
KVM est officiellement le logiciel de virtualisation linux, il est nativement intégré dans le noyaux, tu peux l'utiliser via VirtualBox ou libvirt.
Perso j'utilise openSUSE parce qu’il proposait un noyau XEN depuis longtemps (avant les LEAPS & tumbleweed), aujourd’hui je suis sous LEAP 4.3 et j'utilise VirtualBox, les noyaux XEN m'ayant posées des problèmes en bureautique traditionnel sous les précédentes versions. Je n'ai pas essayé XEN avec LEAP vu que VirtualBox ne me pose aucun soucis.
De mon point de vue, aujourd’hui, sur une distribution moderne préférer KVM pour un usage desktop, qui fait partie intégrante du noyau Linux.
Franchement je ne comprends pas ce genre de réponse.
Aujourd'hui tout le monde est convaincu que si je sais travailler sous des UNIX like ou pas c'est parce que j'ai commencé dessus. Par lassitude je ne démens plus, mais pour info je suis arrivé dans l'informatique pro au milieu des années 90, à ce moment là la grosse mode était NT4 !
Pendant mes 6 premières années j'ai bossé sur NT4, 80% en tant que developper MFC (oui j'ai pas eu de chance) 5% à développer en proc*C sous HPUX 10.2 avec le 'vi' de l'époque pour écrite le code (là j'ai pensé que j'étais maudit), le reste était de l'admin basic NT4.
J'utilisais peu le 'vi' original par rapport à Visual Studio, mais j'étais beaucoup intrigué par lui. J'ai fini par faire du proc*c à 100%, toujours sur HPUX10 et son 'vi'. A l'époque les admins ajoutaient toujours un 'set -o vi' dans le profil des comptes (les admins linux sont moins éclairés, ils oublient systématiquement de configurer '/etc/inputrc' correctement, mais c'est peut être un reproche à faire aux distribs).
J'ai d'abord compris le mode vi par le shell, quand j'ai compris que les commandes étaient (presque) identiques entre 'vi' et le 'shell' en mode 'vi' j'ai adoré et je ne me suis jamais lassé. Par contre je n'ai pas de mal à comprendre qu'une personne qui est habituée à Windows ou aux destkops Linux avec leurs éditeurs ou il n'y a rien à apprendre pour taper du texte, ne puissent pas appréhender 'vi' ou il est nécessaire d'apprendre l'éditeur avant de ne pas faire grand chose.
[^] # Re: Monsieur essaye de masquer la réalité
Posté par Kangs . En réponse au journal Le débat est clos. Évalué à 3.
Je suis d'accord, vi est installé par défaut, mais le shell est par défaut en mode emacs, c'est un truc que je n'ai jamais compris sur les UNIX et UNIX like…
[^] # Re: N'importe quoi !
Posté par Kangs . En réponse à la dépêche Interview de Dimitri Fontaine, contributeur majeur à PostgreSQL. Évalué à -10. Dernière modification le 11 mars 2018 à 23:30.
Je n'aurais jamais cru pouvoir lire de tels de conneries de ma vie. Le prochain dîner de cons je t'invite.
[^] # Re: Forum
Posté par Kangs . En réponse au journal Portage de TapTempo en C à la Unix-like. Évalué à 3.
Ce n'est que pur coïncidence ça devait arriver ;)
[^] # Re: plusse ou moinsse ?
Posté par Kangs . En réponse au journal Portage de TapTempo en VBA. Évalué à 10. Dernière modification le 08 mars 2018 à 20:03.
+, l'effort est remarquable, je pense qu'il devait sacrément s'ennuyer aujourd'hui…
[^] # Re: awk vs cut
Posté par Kangs . En réponse au journal taptempo.awk : une approche plus unix ?. Évalué à 1.
Oui, surtout que je ne comprenais tellement pas ce que tu disais que je t'ai relu 3 ou 4 fois avant de faire un test. J'ai fait le test et je me suis dit que ça faisait trop longtemps qu'il n'avait plus utilisé cut ;)
[^] # Re: awk vs cut
Posté par Kangs . En réponse au journal taptempo.awk : une approche plus unix ?. Évalué à 1.
Désolé je n'avais effectivement pas lu "nombre variable d'espaces"
[^] # Re: awk vs cut
Posté par Kangs . En réponse au journal taptempo.awk : une approche plus unix ?. Évalué à 0.
Là c'est toi qui sous estime cut :
Si tu voulais les champs de 3 à 5 :
-f3-5[^] # Re: awk vs cut
Posté par Kangs . En réponse au journal taptempo.awk : une approche plus unix ?. Évalué à 4.
Je pense que tu sous estimes les capacités de filtrage de awk, grep et cut sont très efficaces dans beaucoup de cas mais awk pour le filtrage complexe à de gros avantages.
[^] # Re: Github ou GitLab
Posté par Kangs . En réponse au journal Portage de TapTempo en Java. Évalué à 2.
Merci ;)
# Github ou GitLab
Posté par Kangs . En réponse au journal Portage de TapTempo en Java. Évalué à -9.
pour partager du code tu connais ?
# Paster & Copy
Posté par Kangs . En réponse au message un problème dans mon code sur langage C. Évalué à 6.
Je n'ai regardé que le premier lien et il est illisible, faire des copier/coller avec les flags markdown qui vont bien n'auraient-ils pas été plus lisible et accessible pour tout le monde ?
C'est quoi cette manie des screenschots ? De la windoserie de merde adapter à Linux ?
[^] # Re: attention au root
Posté par Kangs . En réponse au message copier un dossier entre deux ordinateurs. Évalué à 3.
Je pense surtout que tu aimes le calcul mental, chacun son truc ;)
[^] # Re: attention au root
Posté par Kangs . En réponse au message copier un dossier entre deux ordinateurs. Évalué à 5.
La notation octale a la peau dur malgré l’incompréhension de son fonctionnement par la grande majorité des utilisateurs.
La notation symbolique a été inventée depuis longtemps à cause de ça, par exemple le symbole pour lecture est 'r' (read), l'écriture 'w' (write), l'exécution 'x' (execute).
Si tu veux appliquer des droits à au propriétaire (user) tu utilises la lettre 'u' au groupe la lettre 'g' au reste du monde la lettre 'o' (others).
Ex :
chmod u=rw,go=r totoPropriétaire (User) = read et write, group et others = read only.'=' tu appliques un droit
'+' tu ajoutes un droit, ex sur l'exemple précédent ajouter le droit d'écriture au groupe :
chmod g+w toto'-' tu retires un droit, ex sur l'exemple précédent supprimer le droit de lecture au monde :
chmod o-r totoÇa se mémorise vite et tu évites les erreurs bêtes, après ça ce n'est que la base, man chmod pour plus d'infos.
[^] # Re: N'importe quoi !
Posté par Kangs . En réponse à la dépêche Interview de Dimitri Fontaine, contributeur majeur à PostgreSQL. Évalué à 1.
Le plus gros de l'énervement est qu'il ne semble pas connaître le monde de la production, en production une défaillance (les dégradations de performance en font partie) ont un coût. Quand on est DBA de production on a pour objectif de rendre le service optimal le plus vite possible. On peut éventuellement donner des avis/conseilles mais ils ne seront pas entendus.
Le manager ne va pas financer une correction si le problème est résolu par des options du SGBDR. Il pensera que c'était un problème du SGBDR mais pas du code. Si le problème devient récurrent et pèse financièrement, que ma hiérarchie est convaincue par mes arguments alors une discussion devient possible. Mes boss parlent avec les autres boss, s'ils sont convaincus (et il y a de gros lourd) alors on pourra (les DBA) discuter avec les dev.
Ensuite faut pas rêver, je fais partie de la génération ou avant d'être admin de quoi que ce soit il fallait avoir été développeur, donc je peux facilement discuter et coder si je connais le langage. Beaucoup de mes jeunes collègues sont directement arrivés en production, ils ne connaissent rien au dev. Certain apprennent vite les principes fondamentaux du SQL, d'autres ne supportent même pas l'idée de devoir coder (même du ksh).
Le gros énervement vient donc du fait qu'il pense que les DBA et les dev devraient plus discuter, mais vu ces arguments j'ai l'impression qu'il n'a jamais essayé de discuter avec des DBA de productions pour connaître leurs attentes principales d'un SGBDR. J'ai l'impression qu'il développe un logiciel destiner à la production sans savoir ce qu'est une production.
[^] # Re: N'importe quoi !
Posté par Kangs . En réponse à la dépêche Interview de Dimitri Fontaine, contributeur majeur à PostgreSQL. Évalué à 1. Dernière modification le 28 février 2018 à 11:35.
La forme normale est une façon de concevoir un schéma transactionnel, le but étant par exemple d'éviter les 'deadlock', faciliter la concurrence etc. La plus connue et la plus utilisée étant la 3iéme forme normale (3NF) il y en a d'autre, mais je ne pense pas les avoir vus implémentées.
Write Ahead Mode, quand tu fais des insert, update, delete ils ne sont pas faits sur le disque mais en mémoire (sous Oracle et je pense les autres éditeurs aussi, il y a des cas particulier comme pour les LOB), mais toutes les instructions d'une transaction sont loguées dans un journal de transaction, le coût de l'IO tu l'as uniquement au commit, car avant de rendre la main le moteur doit te garantir qu'il pourra rejouer les instructions s'il y a un plantage. Bien sur les blocs mémoire sont écrits sur le disque, mais de façon asynchrone, d’où l'importance de la taille du cache pour les bases OLTP s’il y a beaucoup de transactions concurrentes.
[^] # Re: N'importe quoi !
Posté par Kangs . En réponse à la dépêche Interview de Dimitri Fontaine, contributeur majeur à PostgreSQL. Évalué à 0.
J'ai essayé de l'expliquer 1 000 fois, on m'a systématiquement répondu trop de boulot…
[^] # Re: N'importe quoi !
Posté par Kangs . En réponse à la dépêche Interview de Dimitri Fontaine, contributeur majeur à PostgreSQL. Évalué à 3.
J'ai même abandonné d'essayer d'expliquer la différence entre une jointure et un filtre.
Cela étant dit, je le répète, c'est aux SGBDR de s'adapter aux pratiques majoritaires. C'est comme ça que l'informatique évolue.
Aujourd’hui on doit gérer des applications dont le moyen de persistance est une abstractions. Je ne sais pas si c'est bien ou non, mais la masse fait que l'on va dans se sens. C'est aux éditeurs de s'adapter (et c'est ce qu'il font) de proposer des solutions "génériques" qui correspondent à ce que la majorité fait.
Entendre en développeur tenir un discourt datant des années 90 en 2018 me consterne.
[^] # Re: N'importe quoi !
Posté par Kangs . En réponse à la dépêche Interview de Dimitri Fontaine, contributeur majeur à PostgreSQL. Évalué à -10.
Tu racontes vraiment n'importe quoi.
# N'importe quoi !
Posté par Kangs . En réponse à la dépêche Interview de Dimitri Fontaine, contributeur majeur à PostgreSQL. Évalué à -2.
Les grosses applications en entreprise sont basées sur SAP, SIEBEL, PEOPLESOFT (pour les plus connus) et sont très critiques, beaucoup de logiciels de niches sont développés par des startups et sont très critiques, beaucoup d'applications propres à une entreprise sont basées sur des frameworks qui génèrent le code SQL et sont plus ou moins critiques.
LE point commun de toutes ces applications : ON S'EN BRANLE DU SGBDR !
Donc aujourd'hui le strict minimum que doit apporter un SGBDR aux DBA, c'est de pouvoir ajouter des hints à la volée, interdire des plans, stabiliser un ensemble de plans & co. Ces entreprises (SAP étant une exception) ne vont pas faire beaucoup d'efforts et les startups n'en font presque pas voir pas du tout.
J'ai vécu un enfer avec une base spatiale (d'une startup) pour les réseaux ferrés en Oracle 9i, le CBO n'intervenait pas dans les requêtes spatiales (le plan était produit uniquement à partir d'heuristiques), il fallait donc les aider avec des hints, mais en 9i seul les développeurs pouvaient les ajouter ! Et ils nous ont menés en bateau pendant des mois et n'ont jamais rien fait. Aujourd'hui j'aurais pu résoudre, je pense, les problèmes de performance avec les outils disponibles.
Il faut arrêter avec ce pseudo dialogue avec les développeurs, il existe très peu et est juste parfois impossible à cause des outils utilisés.
Aujourd'hui ont (les DBA mais tout type d'administrateurs) gère des parcs de 100 à 2000 serveurs de productions avec j'aimais plus de 18 DBA, on est évalué sur le temps passé à résoudre un problème pas à discuter avec les équipes de devs. Le SQL et le SGBDR ne sont pas le langage et outil préférés (ou maîtrisés) des développeurs. Beaucoup voient un SGBDR comme un système de fichier portable (d'ailleurs sur ce site de nombreuse dépêches et commentaire vont dans se sens). Donc le jour ou les écoles (peu importe le niveau) enseigneront les principes fondamentaux comme les transactions (résumées par ACID), ce qu'est une 3NF et le W.A.L modes cela pourra peut-être évolué, mais pour l'instant c'est le SGBDR qui s'adaptent aux pratiques majoritaires des développeurs et à leur déchargent chaque SGBDR va se comporter différemment (le CBO ne serra jamais parfais) ! Donc c'est aux SGBDR de fournir des outils pour adapter le code, le dév ne pourra pas faire une version par SGBDR.
[^] # Re: suite à ces avis, affinons la question
Posté par Kangs . En réponse au message Quel linux pour héberger plusieurs machines virtuelles ?. Évalué à 1.
Donc sous linux, pour utiliser KVM tu as le choix entre virt-manager ou VirtualBox (je ne connais pas promox). Ce sont des interfaces différentes. (Sous MSWindows Vbox utilise Hyper-V)
Le point positif de VirtualBox c'est qu'il est disponible sur les Linux, MSWindows, Mac OS X, Solaris.
Le problème avec VirtualBox ce sont les extensions que tu peux télécharger gratuitement (ta distribution ne peut pas les fournir), mais elles sont considérées par Oracle comme des démos et sont sous licence propriétaires, il faut payer pour avoir un support (et les patchs je pense).
[^] # Re: Simplicité avant tout
Posté par Kangs . En réponse au message Quel linux pour héberger plusieurs machines virtuelles ?. Évalué à 4.
Pas vraiment.
xen (citrix) n'est pas intégré au noyau officiel car citrix n'a pas voulu suivre les méthodes d'intégrations des développeurs du kernel linux (plein de petits patchs vs un gros patch).
KVM est officiellement le logiciel de virtualisation linux, il est nativement intégré dans le noyaux, tu peux l'utiliser via VirtualBox ou libvirt.
Perso j'utilise openSUSE parce qu’il proposait un noyau XEN depuis longtemps (avant les LEAPS & tumbleweed), aujourd’hui je suis sous LEAP 4.3 et j'utilise VirtualBox, les noyaux XEN m'ayant posées des problèmes en bureautique traditionnel sous les précédentes versions. Je n'ai pas essayé XEN avec LEAP vu que VirtualBox ne me pose aucun soucis.
De mon point de vue, aujourd’hui, sur une distribution moderne préférer KVM pour un usage desktop, qui fait partie intégrante du noyau Linux.
[^] # Re: Très bonne idée !
Posté par Kangs . En réponse au journal Un tap tempo en ligne de commande. Évalué à 4.
Oui, ton raisonnement se tient et me convient.
[^] # Re: Très bonne idée !
Posté par Kangs . En réponse au journal Un tap tempo en ligne de commande. Évalué à 4.
Aux fils des corrections/évolutions il y aura peu être plus de lignes de code, donc bon…
[^] # Re: Simplicité avant tout
Posté par Kangs . En réponse au message Quel linux pour héberger plusieurs machines virtuelles ?. Évalué à 2.
A été déployé sur de très grosses architectures ?
Sinon sur mon PC je ne vois pas…
[^] # Re: Notepad++ !!!
Posté par Kangs . En réponse au journal Quel IDE pour quel langage. Évalué à 5.
Franchement je ne comprends pas ce genre de réponse.
Aujourd'hui tout le monde est convaincu que si je sais travailler sous des UNIX like ou pas c'est parce que j'ai commencé dessus. Par lassitude je ne démens plus, mais pour info je suis arrivé dans l'informatique pro au milieu des années 90, à ce moment là la grosse mode était NT4 !
Pendant mes 6 premières années j'ai bossé sur NT4, 80% en tant que developper MFC (oui j'ai pas eu de chance) 5% à développer en proc*C sous HPUX 10.2 avec le 'vi' de l'époque pour écrite le code (là j'ai pensé que j'étais maudit), le reste était de l'admin basic NT4.
J'utilisais peu le 'vi' original par rapport à Visual Studio, mais j'étais beaucoup intrigué par lui. J'ai fini par faire du proc*c à 100%, toujours sur HPUX10 et son 'vi'. A l'époque les admins ajoutaient toujours un 'set -o vi' dans le profil des comptes (les admins linux sont moins éclairés, ils oublient systématiquement de configurer '/etc/inputrc' correctement, mais c'est peut être un reproche à faire aux distribs).
J'ai d'abord compris le mode vi par le shell, quand j'ai compris que les commandes étaient (presque) identiques entre 'vi' et le 'shell' en mode 'vi' j'ai adoré et je ne me suis jamais lassé. Par contre je n'ai pas de mal à comprendre qu'une personne qui est habituée à Windows ou aux destkops Linux avec leurs éditeurs ou il n'y a rien à apprendre pour taper du texte, ne puissent pas appréhender 'vi' ou il est nécessaire d'apprendre l'éditeur avant de ne pas faire grand chose.