En général, pour la date, si je veux être portable, j'utilise deux notations :
- YMD
- timestamp
On obtient le second avec date %+s
Je crois que un des problèmes des exemples, c'est que ce sont des trucs assez classiques et qu'il existe donc déjà sous UNIX des bonnes manières pour faire vite et propre en bash.
Là ou le shell windows va devenir intéressant, c'est quand on va rentrer dans des choses systèmes et mélanger un peu tout cela.
Dans les langages de scripts, on peut faire un peu pareil avec sous Windows les modules de type Win32 (Win32:: sous Perl). Mais il faut faire le "wrapper". On peut cependant imaginer qu'avec .Net et l'introspection, il soit possible, notament avec la force de frappe de Microsoft, de mettre au point un wrapper automatique, soit lors des mises a jour des logiciels, soit avec un mécanique du type AUTOLOAD pour Perl.
Si je comprends bien, il ne devrait mettre que des slots 16x sur les cartes mères ;-)
Pour ce qui est des cartes graphiques, j'ai une nvidia sur port PCI, elle marche vraiment très bien pour ce que j'en fait (deux écrans). De temps en temps, je me demande combien d'utilisateurs (en entreprise) utilisent réellement le port AGP.
Vu le calcul que nous eu au niveau de la carte réseau gigabit, je vais finir par mettre la carte réseaux sur le port le plus rapide et la carte graphique sur le port le plus lent.
D'ailleur sur ce thème, comment on sais sur quel type de port sont les composants intégré comme le réseau ou la partie graphique (bas de gamme) ?
Il y a des outils pour administrer les clusters qui ont la particularité d'avoir des noeuds homogène dans de nombreux cas.
Sinon, pour un parc hétérogène, ssh ne suffit pas. ClusterSsh aide et permet d'administrer par exemple un vingtaine de machine en parallèle mais ce n'est pas suffisant.
Très vite se pose le problème de la gestion au quoditien...
Personnellement, j'utilise cfengine qui autoconfigure tous mes postes Linux et permet de gérer de manière souple et dans le temps des machines très différentes de manière centralisé.
Parce que tu te vois avoir des cartes de tous les formats !
Soyons raisonable. Tout cela coute cher et n'a que peu d'intérêt. Les PC ne vont pas avoir tous les slots dans le futur. Il va forcément y avoir un tri qui va se faire.
C'est un véritable problème au niveau acquisition. On ne change pas un PC d'acquisition tous les jours. Au niveau d'une manip expérimentale, la durée de vie de cette manip est bien plus longue que celle du PC. Et on ne change pas sa partie acquisition aussi facilement que cela.
Bref, un changement de bus, c'est un évênement important. Là, pour le moment, on est un peu dans le brouillard.
On m'a parlé par exemple de manip d'astrophysique ou les programmes de recherche sont très long et font intervenir de nombreuse équipes de recherche. Pour ce genre de manip, les choix sont fait très en avance et lorsque la manip tourne, ils peuvent être une génération en arrière.
Combien de manip tourne encore avec des cartes sur bus ISA ?
Je sais qu'on n'aime pas dire du mal de python sur ce site mais de la à perdre des points...
Sinon, je sais que .Net est ouvert sur les langages, cela n'empêche que Microsoft pousse particulièrement C# devant les autres.
Au niveau des langages de scripts qui existe, je persiste à penser que Ruby est plus proche de l'esprit .Net que Python (Ben oui, en Python, on se traine le self pour chaque méthode... C'est pas mieux en Perl).
Ensuite, Ruby est aussi basé sur une syntaxe à la C, bien plus que Python.
Bref, je ne critique pas le choix du shell de Microsft ici au niveau syntaxe. Mais à partir du moment ou ils ont fait un choix pour privilégier un langage compilé à typage fort (C#) et un langage shell, je dis simplement qu'ils auraient pu faire le choix pour un langage de script.
J'ai fait exprès de mettre Ruby pour ne pas tomber dans le troll Perl/Python.
Python, c'est bien mais comme Perl, c'est pas du pur objet.
Ruby est complètement objet dès le début, avec l'intropection et tout et tout. Bref, cela me parait clairement un meilleur choix pour l'architecture .Net. Et c'est pas parce que je suis fanat de Ruby, je ne l'a jamais vraiment utilisé...
Oui, enfin c'est un peu le bordel ce PCI-E. 1x, 4x, 8x, 16x ! C'est quoi ce bazard (en plus, il y a tous les autres PCI...).
Je veux faire de l'acquisition, j'achète quoi comme carte ?
Je crois qu'il faut que cela décante un peu et qu'il reste éventuellement que deux slots : un rapide et un lent. Là, avec la multiplication des types de slots, ca fait plutôt peur.
Pourquoi n'avoir pas choisi les deux seuls format : PCI-E 16x et 4x
Moi, le PCI-E 1x, je ne l'aime pas. Ce petit machin, j'ai du mal à croire que ma carte va tenir correctement dedans. En plus, avec tous les périphériques en USB2 ou en IEEE1394b (voire ethernet), c'est quoi qu'on va mettre sur ce genre de slot ?
C'est clair que le shell UNIX est au coeur du système et que de très grande partie sont scripté en shell.
Un des problèmes est que Windows ne démarre pas en mode terminal même si j'ai cru voir qu'une version de Vista le pourra. Le problème suivant est je n'ai pas connaissance qu'une seule partie de l'OS soit pour le moment en script. Il y a donc encore du boulot pour avoir un système souple et adaptable facilement.
Sur un UNIX, toute la connaissance que l'on apprend dans le terminal peut ensuite être réutiliser au coeur du système. C'est très positif.
Ce nouveau shell windows, c'est bien mais n'aurait-il pas été plus intéressant pour Microsoft d'intégrer un langage de script existant (et non de shell) à .Net, un langage dont le coeur est objet, je pense à Ruby par exemple, pour ensuite reprogrammer un partie de Windows en script justement.
En effet, dès que je commence à avoir de l'awk avec du sed... je considère que Perl est plus adapté et plus maintenable (et non, je programme pas comme un gorais en Perl et oui, on peut faire du Perl lisible).
C'est un peu l'approche de debian
- simple, couche base du système -> bash
- compliqué -> Perl
Il ai vrai que l'on voit aussi de plus en plus de python...
L'objectif d'un shell est aussi d'être interactif, de la à faire des gros programmes... Enfin, si le shell windows remplace à la fois command.exe et le vbs système, je crois que personne ne va pleurer. Sauf que malheureusement, il n'y a pas un portage minimal sur les anciens OS !
Le principe de base du shell est d'être unifié avec l'approche fichier d'UNIX.
Donc, on doit tout pouvoir rediriger dans un fichier puis traiter ce fichier plus tard ou balancer dans un pipe. Bref, il n'y a pas de différence entre pipe et fichier.
La, si le pipe n'est pas un "fichier", cela change tout.
C'est vrai qu'on a tendance à balancer dans un fichier en remplacement d'un stockage dans une variable. Mais quand même...
Si le D-BUS principal tombe et que tous les autres tombent alors, cela perds pas mal de son intérêt ! Cela veut dire que l'on ne peut pas relancer le D-BUS sytème sans perturber les autres violament.
Au niveau fam et gamin, en pratique, cela est remplacé par inotify directement par le noyau. Par contre, on doit pouvoir utiliser D-BUS pour la transmission finale ?
Quand à la fin, que gconf utilise dans le futur D-BUS pour transmette ses informations, pourquoi pas. Mais cela n'a effectivement rien à voir. Un des objectifs de gconf est quand même de centraliser les paramètres de configurations des applications. Après, gconf fait plus que cela mais justement, je fait partie des personnes qui trouve qu'il en fait bien trop ;-) Si D-BUS lui enlève une partie du boulot, tant mieux.
Je n'en ai pas fait beaucoup mais c'est vrai que cela m'a pris en général ma soirée.
D'un autre coté, je ne la trouve pas si mal cette dépêche.
Un point important à mon sens avec D-BUS est que normalement, cela ne tourne pas en root. Chacun a le sien. Je ne sais pas par contre comment les D-BUS communiquent entre eux ? (Le D-BUS utilisateur est-il client du D-BUS système) Cela est un plus par exemple avec le service 'fam' de notification de mofication de fichier qui devait absolument tourner en root, avec les problèmes que l'on connait pour les périphériques amovibles (il faut voir les astuces qui ont été réalisés sur ce point là à une époque pas si lointaines).
Un autre point important est que D-BUS est un bus de messages et de signaux. Cela n'a donc rien à voir avec un système de variable globale de type base de registre ou gconf. Cela me fait plus penser au système de message à la base d'OpenStep. Or tout le monde sait qu'OpenStep (donc GnuStep) qui fonctionne par message avec un langage objet dynamique (ObjectiveC) a montré depuis des années une souplesse de fonctionnement et d'adaptation aux problèmes avec une API d'une incroyable stabilité.
Je ne sais pas précisement pour la licence Apache mais pour une licence BSD, on peut, à ma connaissance, très bien faire un fork et passer le projet sous GPL.
Donc, si c'est aussi possible pour Apache, on pourrait très bien avoir un Apache3 sous GPL ou, en pratique, seules les nouvelles portions de code seraient réellement en GPL.
BSD est compatible GPL mais pas l'inverse... Un projet BSD peut donc très bien finir en GPL.
En quoi Suse est plus intégrée que Debian ? Je ne parle pas des dérivées de Debian...
Honnètement, la qualité de l'intégration d'une debian stable est impressionante. Je n'ai pas essayé Suse mais sur les autres distributions citées, effectivement, il y a des petits soucis ici ou là.
Ce que thunderbird ne fait pas (mais Claws le fait-il ?), c'est de rajouter dans une réponse le champ Reply-To: avec l'adresse mis à To: dans le courriel original, si celui-ci n'est pas l'adresse par défaut.
Je m'explique. Je reçois des courriels destiné à 'support', mais sur le serveur, support est redirigé vers mon compte 'sytoka'. Bilan, lorsque je répond, c'est sous l'identité sytoka et non support. Cependant, je veux que si la personne réponde, elle le soit à support et non à sytoka... D'ou le champ Reply-To.
Bref, un système de gestion de ticket de type 'rt' résoud ce genre de problématique mais bon, c'est pratique pour une personne d'avoir un 'alias' correspondant à sa fonction sans que cela soit une boite mail à part entière : secretariat, compta...
Une question que je me pose et qui est aussi valable pour OCS :
Comment sais il que le logiciel est déjà installé et en cas de mise à jour, comment cela se passe-t-il ?
Je pense par exemple à Firefox qui a souvent des mises à jour. Suffit-il de mettre la nouvelle version de Firefox dans la file d'attente et hop, le système se débrouille soit pour l'installer, soit pour le mettre à jour.
Xen marche très bien. Si tu as des doutes, parle en au CRI de l'université de Nantes (Centre de Ressources Informatique, terme moins pompeux que DSI). Si mes souvenirs sont bons, ils virtualisent 250 serveurs sur 40 machines physiques !
Bon, tout n'est pas du Xen, il y a du vserver. Il faut savoir choisir en fonction de l'application.
Personnellement, je fais fonctionner XP sous qemu avec la virtualisation complète de qemu et cela marche super bien.
Je ne suis pas les listes de diffusion au jour le jour mais j'ai l'impression que cela échange pas mal entre qemu et Xen. Je ne vois pas pourquoi Xen n'arriverait pas à faire ce que fait très bien qemu.
Ce n'est pas parce qu'on n'aime pas Windows qu'il faut dire des bêtises. Soyons objectif, des serveurs sous Windows, il y en a des quantités et qui marchent bien.
Il est clair que la virtualisation avec Xen, vserver... apporte aussi un autre type de solution que le Hurd mais finalement pas si éloigné.
Par ailleurs, il faut savoir que la virtualisation résoud aussi un gros problème pour Microsoft vu que sous Windows, tout tourne en root. Avec la virtualisation, Microsoft a une bonne occasion de résoudre ce problème, un service = une machine virtuelle.
Bref, les hyperviseurs ont une force de frappe d'un paquet de développeurs qui sont près à graver une partie de la solution dans le silicium.
Encore une fois, c'est pas forcément le meilleur qui gagne mais ceux qui gagne montrent qu'ils arrivent à s'adapter.
[^] # Re: Je me marre ...
Posté par Sytoka Modon (site web personnel) . En réponse au journal PowerShell: tapez rm -rf c:\Windows ! ;). Évalué à 1.
- YMD
- timestamp
On obtient le second avec date %+s
Je crois que un des problèmes des exemples, c'est que ce sont des trucs assez classiques et qu'il existe donc déjà sous UNIX des bonnes manières pour faire vite et propre en bash.
Là ou le shell windows va devenir intéressant, c'est quand on va rentrer dans des choses systèmes et mélanger un peu tout cela.
Dans les langages de scripts, on peut faire un peu pareil avec sous Windows les modules de type Win32 (Win32:: sous Perl). Mais il faut faire le "wrapper". On peut cependant imaginer qu'avec .Net et l'introspection, il soit possible, notament avec la force de frappe de Microsoft, de mettre au point un wrapper automatique, soit lors des mises a jour des logiciels, soit avec un mécanique du type AUTOLOAD pour Perl.
Bref, ca manque d'un langage de script...
[^] # Re: Concurrence Intel
Posté par Sytoka Modon (site web personnel) . En réponse au journal OpenGraphic. Évalué à 3.
Si je comprends bien, il ne devrait mettre que des slots 16x sur les cartes mères ;-)
Pour ce qui est des cartes graphiques, j'ai une nvidia sur port PCI, elle marche vraiment très bien pour ce que j'en fait (deux écrans). De temps en temps, je me demande combien d'utilisateurs (en entreprise) utilisent réellement le port AGP.
Vu le calcul que nous eu au niveau de la carte réseau gigabit, je vais finir par mettre la carte réseaux sur le port le plus rapide et la carte graphique sur le port le plus lent.
D'ailleur sur ce thème, comment on sais sur quel type de port sont les composants intégré comme le réseau ou la partie graphique (bas de gamme) ?
[^] # Re: ya du progrès
Posté par Sytoka Modon (site web personnel) . En réponse au journal PowerShell: tapez rm -rf c:\Windows ! ;). Évalué à 4.
Sinon, pour un parc hétérogène, ssh ne suffit pas. ClusterSsh aide et permet d'administrer par exemple un vingtaine de machine en parallèle mais ce n'est pas suffisant.
Très vite se pose le problème de la gestion au quoditien...
Personnellement, j'utilise cfengine qui autoconfigure tous mes postes Linux et permet de gérer de manière souple et dans le temps des machines très différentes de manière centralisé.
[^] # Re: Concurrence Intel
Posté par Sytoka Modon (site web personnel) . En réponse au journal OpenGraphic. Évalué à 3.
Soyons raisonable. Tout cela coute cher et n'a que peu d'intérêt. Les PC ne vont pas avoir tous les slots dans le futur. Il va forcément y avoir un tri qui va se faire.
C'est un véritable problème au niveau acquisition. On ne change pas un PC d'acquisition tous les jours. Au niveau d'une manip expérimentale, la durée de vie de cette manip est bien plus longue que celle du PC. Et on ne change pas sa partie acquisition aussi facilement que cela.
Bref, un changement de bus, c'est un évênement important. Là, pour le moment, on est un peu dans le brouillard.
On m'a parlé par exemple de manip d'astrophysique ou les programmes de recherche sont très long et font intervenir de nombreuse équipes de recherche. Pour ce genre de manip, les choix sont fait très en avance et lorsque la manip tourne, ils peuvent être une génération en arrière.
Combien de manip tourne encore avec des cartes sur bus ISA ?
[^] # Re: Amis journalistes
Posté par Sytoka Modon (site web personnel) . En réponse au journal PowerShell: tapez rm -rf c:\Windows ! ;). Évalué à 2.
Bon d'un point de vu syntaxe, c'est pas très beau. Peut être des redirection < et > particulière serait les bienvenues.
[^] # Re: Amis journalistes
Posté par Sytoka Modon (site web personnel) . En réponse au journal PowerShell: tapez rm -rf c:\Windows ! ;). Évalué à 4.
Sinon, je sais que .Net est ouvert sur les langages, cela n'empêche que Microsoft pousse particulièrement C# devant les autres.
Au niveau des langages de scripts qui existe, je persiste à penser que Ruby est plus proche de l'esprit .Net que Python (Ben oui, en Python, on se traine le self pour chaque méthode... C'est pas mieux en Perl).
Ensuite, Ruby est aussi basé sur une syntaxe à la C, bien plus que Python.
Bref, je ne critique pas le choix du shell de Microsft ici au niveau syntaxe. Mais à partir du moment ou ils ont fait un choix pour privilégier un langage compilé à typage fort (C#) et un langage shell, je dis simplement qu'ils auraient pu faire le choix pour un langage de script.
[^] # Re: Amis journalistes
Posté par Sytoka Modon (site web personnel) . En réponse au journal PowerShell: tapez rm -rf c:\Windows ! ;). Évalué à 2.
Python, c'est bien mais comme Perl, c'est pas du pur objet.
Ruby est complètement objet dès le début, avec l'intropection et tout et tout. Bref, cela me parait clairement un meilleur choix pour l'architecture .Net. Et c'est pas parce que je suis fanat de Ruby, je ne l'a jamais vraiment utilisé...
[^] # Re: Concurrence Intel
Posté par Sytoka Modon (site web personnel) . En réponse au journal OpenGraphic. Évalué à 1.
Je veux faire de l'acquisition, j'achète quoi comme carte ?
Je crois qu'il faut que cela décante un peu et qu'il reste éventuellement que deux slots : un rapide et un lent. Là, avec la multiplication des types de slots, ca fait plutôt peur.
Pourquoi n'avoir pas choisi les deux seuls format : PCI-E 16x et 4x
Moi, le PCI-E 1x, je ne l'aime pas. Ce petit machin, j'ai du mal à croire que ma carte va tenir correctement dedans. En plus, avec tous les périphériques en USB2 ou en IEEE1394b (voire ethernet), c'est quoi qu'on va mettre sur ce genre de slot ?
[^] # Re: Amis journalistes
Posté par Sytoka Modon (site web personnel) . En réponse au journal PowerShell: tapez rm -rf c:\Windows ! ;). Évalué à 2.
Un des problèmes est que Windows ne démarre pas en mode terminal même si j'ai cru voir qu'une version de Vista le pourra. Le problème suivant est je n'ai pas connaissance qu'une seule partie de l'OS soit pour le moment en script. Il y a donc encore du boulot pour avoir un système souple et adaptable facilement.
Sur un UNIX, toute la connaissance que l'on apprend dans le terminal peut ensuite être réutiliser au coeur du système. C'est très positif.
Ce nouveau shell windows, c'est bien mais n'aurait-il pas été plus intéressant pour Microsoft d'intégrer un langage de script existant (et non de shell) à .Net, un langage dont le coeur est objet, je pense à Ruby par exemple, pour ensuite reprogrammer un partie de Windows en script justement.
[^] # Re: Je me marre ...
Posté par Sytoka Modon (site web personnel) . En réponse au journal PowerShell: tapez rm -rf c:\Windows ! ;). Évalué à 5.
En effet, dès que je commence à avoir de l'awk avec du sed... je considère que Perl est plus adapté et plus maintenable (et non, je programme pas comme un gorais en Perl et oui, on peut faire du Perl lisible).
C'est un peu l'approche de debian
- simple, couche base du système -> bash
- compliqué -> Perl
Il ai vrai que l'on voit aussi de plus en plus de python...
L'objectif d'un shell est aussi d'être interactif, de la à faire des gros programmes... Enfin, si le shell windows remplace à la fois command.exe et le vbs système, je crois que personne ne va pleurer. Sauf que malheureusement, il n'y a pas un portage minimal sur les anciens OS !
[^] # Re: Amis journalistes
Posté par Sytoka Modon (site web personnel) . En réponse au journal PowerShell: tapez rm -rf c:\Windows ! ;). Évalué à 4.
Le principe de base du shell est d'être unifié avec l'approche fichier d'UNIX.
Donc, on doit tout pouvoir rediriger dans un fichier puis traiter ce fichier plus tard ou balancer dans un pipe. Bref, il n'y a pas de différence entre pipe et fichier.
La, si le pipe n'est pas un "fichier", cela change tout.
C'est vrai qu'on a tendance à balancer dans un fichier en remplacement d'un stockage dans une variable. Mais quand même...
Bref, ce nouveau shell, faut le voir à l'usage.
[^] # Re: perdu ! j'parlerai pas de D-Bus/KPart/Dcop
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche D-Bus 1.0, future fondation de nos bureaux. Évalué à 2.
Au niveau fam et gamin, en pratique, cela est remplacé par inotify directement par le noyau. Par contre, on doit pouvoir utiliser D-BUS pour la transmission finale ?
Quand à la fin, que gconf utilise dans le futur D-BUS pour transmette ses informations, pourquoi pas. Mais cela n'a effectivement rien à voir. Un des objectifs de gconf est quand même de centraliser les paramètres de configurations des applications. Après, gconf fait plus que cela mais justement, je fait partie des personnes qui trouve qu'il en fait bien trop ;-) Si D-BUS lui enlève une partie du boulot, tant mieux.
[^] # Re: D-Bus et Upstart
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche D-Bus 1.0, future fondation de nos bureaux. Évalué à 2.
# Java et Solaris
Posté par Sytoka Modon (site web personnel) . En réponse au journal La Java de Sun est libre. IBM n'est pas content.. Évalué à 2.
Sun a fait très attention à ne pas mettre Solaris sous licence GPL à l'époque mais sous une autre licence, incompatible...
En mettant Java en GPL, ils se coupent un peu l'herbe sous le pied pour renforcer l'intégration de Java dans Solaris ?
Au dela de cela, est-ce une remise en cause à moyen terme de la licence Solaris pour finalement validé la démarche de la FSF au travers de la GPL ?
[^] # Re: perdu ! j'parlerai pas de D-Bus/KPart/Dcop
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche D-Bus 1.0, future fondation de nos bureaux. Évalué à 8.
D'un autre coté, je ne la trouve pas si mal cette dépêche.
Un point important à mon sens avec D-BUS est que normalement, cela ne tourne pas en root. Chacun a le sien. Je ne sais pas par contre comment les D-BUS communiquent entre eux ? (Le D-BUS utilisateur est-il client du D-BUS système) Cela est un plus par exemple avec le service 'fam' de notification de mofication de fichier qui devait absolument tourner en root, avec les problèmes que l'on connait pour les périphériques amovibles (il faut voir les astuces qui ont été réalisés sur ce point là à une époque pas si lointaines).
Un autre point important est que D-BUS est un bus de messages et de signaux. Cela n'a donc rien à voir avec un système de variable globale de type base de registre ou gconf. Cela me fait plus penser au système de message à la base d'OpenStep. Or tout le monde sait qu'OpenStep (donc GnuStep) qui fonctionne par message avec un langage objet dynamique (ObjectiveC) a montré depuis des années une souplesse de fonctionnement et d'adaptation aux problèmes avec une API d'une incroyable stabilité.
[^] # Re: Pour résumer l'article..
Posté par Sytoka Modon (site web personnel) . En réponse au journal La Java de Sun est libre. IBM n'est pas content.. Évalué à 8.
Donc, si c'est aussi possible pour Apache, on pourrait très bien avoir un Apache3 sous GPL ou, en pratique, seules les nouvelles portions de code seraient réellement en GPL.
BSD est compatible GPL mais pas l'inverse... Un projet BSD peut donc très bien finir en GPL.
[^] # Re: A quel niveau...
Posté par Sytoka Modon (site web personnel) . En réponse au journal Samba est "fâché" par l'accord Novell/MS. Évalué à 4.
Honnètement, la qualité de l'intégration d'une debian stable est impressionante. Je n'ai pas essayé Suse mais sur les autres distributions citées, effectivement, il y a des petits soucis ici ou là.
[^] # Re: déçu
Posté par Sytoka Modon (site web personnel) . En réponse au journal Sun Java GPLisé : comfirmation. Évalué à 3.
Non, c'est un accord gagnant-gagnant pour le monde libre (et tant mieux).
Je ne suis pas sur que cela enchante Borland (delphi) et Microsoft (.Net) pour donner deux exemples.
[^] # Re: rapport avec Sylpheed ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sylpheed-Claws devient Claws Mail. Évalué à 3.
Je m'explique. Je reçois des courriels destiné à 'support', mais sur le serveur, support est redirigé vers mon compte 'sytoka'. Bilan, lorsque je répond, c'est sous l'identité sytoka et non support. Cependant, je veux que si la personne réponde, elle le soit à support et non à sytoka... D'ou le champ Reply-To.
Bref, un système de gestion de ticket de type 'rt' résoud ce genre de problématique mais bon, c'est pratique pour une personne d'avoir un 'alias' correspondant à sa fonction sans que cela soit une boite mail à part entière : secretariat, compta...
[^] # Re: HelpDesk
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche H-inventory : Un nouvel Asset Manager OpenSource. Évalué à 2.
[^] # Re: HelpDesk
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche H-inventory : Un nouvel Asset Manager OpenSource. Évalué à 2.
Comment sais il que le logiciel est déjà installé et en cas de mise à jour, comment cela se passe-t-il ?
Je pense par exemple à Firefox qui a souvent des mises à jour. Suffit-il de mettre la nouvelle version de Firefox dans la file d'attente et hop, le système se débrouille soit pour l'installer, soit pour le mettre à jour.
[^] # Re: Lien entre OS et processeur
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Xen 3.0.3 virtualise sans modification l'OS invité. Évalué à 4.
Bon, tout n'est pas du Xen, il y a du vserver. Il faut savoir choisir en fonction de l'application.
Personnellement, je fais fonctionner XP sous qemu avec la virtualisation complète de qemu et cela marche super bien.
Je ne suis pas les listes de diffusion au jour le jour mais j'ai l'impression que cela échange pas mal entre qemu et Xen. Je ne vois pas pourquoi Xen n'arriverait pas à faire ce que fait très bien qemu.
[^] # Re: En fait Hurd est loin d'être tout seul....
Posté par Sytoka Modon (site web personnel) . En réponse au journal Hurd, une si belle idée et pourtant.. Évalué à 3.
Cela dit, si je peux éviter, j'évite...
[^] # Re: Résultats de quelques investigations
Posté par Sytoka Modon (site web personnel) . En réponse au journal Hurd, une si belle idée et pourtant.. Évalué à 2.
Par ailleurs, il faut savoir que la virtualisation résoud aussi un gros problème pour Microsoft vu que sous Windows, tout tourne en root. Avec la virtualisation, Microsoft a une bonne occasion de résoudre ce problème, un service = une machine virtuelle.
Bref, les hyperviseurs ont une force de frappe d'un paquet de développeurs qui sont près à graver une partie de la solution dans le silicium.
Encore une fois, c'est pas forcément le meilleur qui gagne mais ceux qui gagne montrent qu'ils arrivent à s'adapter.
[^] # Re: Malheureusement...
Posté par Sytoka Modon (site web personnel) . En réponse au journal Hurd, une si belle idée et pourtant.. Évalué à 3.
Par ailleurs, son support s'arrètera avant 2010 ;-(
Bref, on n'aime ou on n'aime pas les centrales mais on n'aime pas XP !