Pour être vraiment complet, Maven peut être utilisé comme Framework permettant de mener un processus allant de la modélisation à la création d'une distribution.
Dit comme ça, ça reste très vague je l'avoue.
Pour donner un exemple plus concret, nous l'utilisons actuellement pour :
° Modéliser un système (équivalent d'un fichier de déploiement automatique de distribution Linux mais avec un modèle fonctionnel, pas seulement fonction/package, et pour un parc entier de machines, sans la partie OS -prérequis-)
° Créer l'arborescence de développement/intégration
° Rapatrier les différents pakages (nos applications métiers)
° Créer & instancier les données de configuration
° Créer les templates de développement spécifiques (non modélisables) avec leur configuration
° Créer les templates de documentation
° Valider les dépendances (définies par le modèle)
° Générer la documentation
° Repackager les applications configurées/développées
° Mettre à jour le repository
° Créer une distribution (CD/DVD) réunissant installation unifiée du système et documentation à jour
S'approprier Maven et réaliser les développements spécifiques à notre métier a été "lourd" mais un processus d'intégration qui prenait par le passé plusieurs mois (échelle d'une année), représente actuellement quelques semaines à 2-3 mois selon la complexité du projet.
Cela permet aussi d'imposer une méthodologie reproductible, réutilisable en phase de maintenance et... capitalisable (au travers de la modélisation amont et des packages).
Merci Maven.
PS: environ 30% de nos applications sont développées en Java. Ce langage n'est donc pas le seul à bénéficier de ce framework (même s'il bénéficie au mieux de ses avantages).
Voilà !
Je me souviens maintenant pourquoi je ne postais plus sur LinuxFR depuis si longtemps : cette impossibilité à échanger de façon modérée ou à proposer un avis un tant soit peu divergent de la "bonne pensée" linuxienne.
Quelque part ça me fait bien rire, d'un rire un peu triste, de voir que le ton ici n'a pas changé malgré les années passées.
Si tu veux...
Une autre hypothèse à envisager serait que ton propos initial n'était pas clair d'où ma compréhension erronée et mon jugement non pertinent ^^
Je n'ai pas dit le contraire seulement il ne tient pas la comparaison avec un shell type ksh/bash en termes d'environnement, interprétation des variables (variable de variable avec eval par exemple), possibilités de boucles ou conditions, variables typées voire même norme (POSIX)...
Pas plus que de permettre l'intégration de drivers propriétaires. Et pourtant les mécanismes existent...
Et propriétaire ou non, ce n'est pas trop la question à mes yeux.
Xen (avant Citrix, depuis j'avoue être paumé) a longtemps fait/proposé des modifications dans le noyau sans pour autant qu'elles soient intégrées à la branche officielle.
A ce compte là, les "devs du noyau" ne sont pas là pour faire tourner quoique ce soit. Ils pourraient d'ailleurs faire des trucs dans leur coin, sans communiquer.
Ce n'est pourtant pas ainsi que ça fonctionne. A croire que ce n'est pas ce qu'"ils" veulent (en supposant que les "devs du noyau" parlent d'une seule voix) mais qu'ils souhaitent plutôt offrir le maximum de services aux applications (au sens très large). Etonnant non pour un système d'exploitation...
"Leur pilote vise à faire tourner un guest Linux dans leur hyperviseur Windows. Qu'est-ce qu'on en a à foutre de ce "cadeau" ?"
Heu... p't'être faire tourner Linux sur du Windows non ?
Après, personne n'est obligé d'offrir de la m**** en guise de cadeau effectivement (personnellement j'aurais un peu honte de présenter un travail à moitié fait).
"API interne seulement. En ce qui concerne l'API qui s'interface avec le userland ça reste stable (et heureusement !). "
l'ABI (donc API) n'est pas stable au sens ou elle change souvent (i.e. fréquement), hors userland. On en peut donc pas qualifier cela d'interne ni de stable.
A bien des égards, c'est un avantage... sauf dans celui des drivers (entre autres), ce qui oblige les éditeurs (proprio) à de gros efforts.
Foison de nouvelles fonctionnalités (même bas niveau), sans pouvoir en profiter... Donc, résultat mitigé à mes yeux *
* oui, on peut viser le tout-libre mais entre souhait et réalité, certains choix sont parfois nécessaires. La véritable liberté est ici à mes yeux : pouvoir vivre et assumer le choix de ses contradictions.
A l'inverse, je pense franchement que pour marketer, il faut avoir recours de près ou de loin à du mensonge.
Pas forcément un mensonge éhonté mais plutôt enjoliver la réalité, taire certains points gênants...
Si apparaitre dans les linéaires de la grande distribution signifie marketing... je ne suis pas pressé d'y voir nos LL.
Et je continue à soutenir les vertus de l'éducation en matière de LL, de proche en proche... pas au travers de grandes campagnes de sensibilisation avec plein de petits bouts de marketing dedans.
Un utilisateur convaincu devient fidèle... et ne change pas son fusil d'épaule à chaque changement de vent.
Sur cette base, on ne peut pas espérer d'adhésions massives, mais des adhésions durables. C'est une démarche de fond, sur le long terme. Mais, au final, les gens qui nous entourent adhèrent pour de "bonnes" raisons (ou qui me semblent bonnes :), et ce cercle grandit au fil du temps.
Patience et discipline... \o/
"ou alors ca devient VRAIMENT compliquer, comme modifier directement les records de la base ldap pour l'AD"
Dommage de prendre typiquement l'exemple d'un protocol (LDAP) compliqué par essence qu'il s'agisse du schéma, de l'interrogation ou de la mise à jour des données.
Un utilitaire (MS) comme ldifde te permet de faire cela en ligne de commande.
Il est fourni de base avec les versions server : équivalent (dans la logique MS) à installer un package LDAP client sous Linux.
Bref, je pense que ton exemple n'est pas pertinent.
Au-delà de ça, la logique LDAP-Active Directory (*) est bien plus perturbante que la complexité de l'outil fourni en ligne de commande.
(*) schéma minimaliste, hiérarchie LDAP non valorisée, respect de la norme succinct...
Globalement, les "Consoles d'administration" Windows (ajout fonctionnels selon les services installés) ne sont pas mal foutues (par rapport au clic-clic accessible de base) mais manquent cruellement
1/ de cohérence
2/ d'adoption hors des softs MS.
Mais il faut voir aussi qu'en partant d'une base cmd.exe, il est quasiment impossible d'avoir des fonctionnalités évoluées de scripting (fournies par le shell csh/ksh/bash... sous Linux) : builtin, boucles, variables (typées selon le shell), environnement, fork...
Plus généralement, les produits MS, ça devient aujourd'hui 80% de discours marketing mais de moins en moins d'innovations (hors ergonomie) et des décennies de retard technologique.
Côté avancée technologique, on peut citer : virtualisation (HyperV), mises à jour, ligne de commande, interface "3D", intégration, déploiement "massif"...
Ca donne l'impression que MS place ses efforts dans la préservation de ses acquis plutot que dans l'innovation (budget com/marketing, support matériel sans valorisation, segmentation de l'offre **) sur la base de bla-bla.
Hier Exchange 2003, aujourd'hui Excahnge 2007 + sharedPoint : même fonctionnalités (à nu pouillème) mais de 1 licence -> 2 licences \o/
"Après pour les autres utilisations je ne pense pas que l'impact sur le marché soit vraiment important, ce sont les gamers qui achètent les grosses carte graphiques"
Comparaison nVidia (avec Processeur de traitement parallèle, i.e. CUDA) :
- Gamme grand public : 8 références* dont haut de gamme GeForce GTX 295 ~480€
- Gamme professionnelle : 12 références dont haut de gamme Quadro FX 5800 ~3500-4000€, Quadro NVS 450 ~450€
Penses-tu toujours qu'il n'y a que les "gamers" pour acheter de grosses cartes graphiques ?
* "véritables" références (caractéristiques GPU) faisant partie de l'offre officielle du constructeur
Et accessoirement, ces traitements, câblés ou programmables, dans le GPU/processeur parallèle constituent une véritable optimisation des performances... dans un contexte donné et précis.
Le souci est qu'aujourd'hui avec CUDA et consorts, les développeurs voudraient faire du GPU/processeur parallèle un processeur générique avec gestionnaire de mémoire intégré et puissance de calcul supérieur au processeur central...
Curieusement, ça exige 1/ des efforts 2/ de diminuer ses prétentions...
Bien qu'étant un novice en regard de la 3D, je reste tout de même avec l'impression que cette version 3.1, même si elle apporte de conséquentes innovations techniques, ne va pas révolutionner le "petit" monde des jeux vidéos et cela pour au moins trois raisons :
° Elle arrive fort tard par rapport à la sortie de DirectX 10.x alors qu'il aurait été de bon ton de "profiter" du flou des API introduit avec Vista et la version 10
° En termes de jeux, on ne peut pas limiter l'intérêt d'une API au rendu 2D/3D. Là où DirectX apporte un support multimédia complet (3D, video, son, réseau et périphériques) aux développeurs, OpenGL est limité à la 2D/3D. L'abstraction est donc "globalement" bien moins intéressante.
° Bénéficier aujourd'hui d'une 3D performante signifie utiliser des pilotes propriétaires (oublions les chipset Intel...) et ces pilotes, outre leurs limitations (proprio), sont peu supportés (voir entre autres les derniers articles concernant ATI et le point de vue des mainteneurs sur les forums Phoronix) et surtout peu performants en OpenGL. Curieux tout de même qu'il y ait des outils de benchs à foison en DirectX et si peu pour OpenGL (mais les piètres performances ne sont sans doute pas la seule raison).
Au final, je ne sais pas ce qu'il en est pour la 3D professionnelle et OpenGL mais côté jeux et plus généralement multimédia, OpenGL a encore bien des obstacles à franchir avant d'occuper une place de choix sur nos Desktop.
Le seul avantage que j'y vois (ne connaissant pas ses attraits purement techniques) est son caractère multiplateforme.
Et pour ce qui est des interfaces de programmation disponibles sur les CG, cela reste encore limité par le caractère fortement parallélisable et, intrinsèquement, à forte itération (sans renouvellement intensif des données traitées) du fait des goulots d'étranglement matériels *
Cela reste donc aujourd'hui plus marketing qu'utile pour le grand public à mon avis.
(visiblement de cadet des soucis d'un mainteneur de paquet de Debian)
Hum oui, je pense que tu as bien cerné le Contrat Social de Debian, principalement le point 4...
Après qu'il puisse y avoir des dysfonctionnement c'est certain; chaque distribution demeure perfectible.
Toutefois, même moi qui ne suis plus que de très loin les news Debian, je savais qu'elle allait supprimer les blobs binaires à l'horizon Lenny. Sachant que 1+1 = 2, il n'était pas franchement compliqué d'anticiper les problèmes avec du matériel un peu "limite" (dans le sens où ces blobs sont à mes yeux une hérésie, non dans le principe* mais au même titre que les drivers videos proprio). Tu te dis utilisateur Debian; tu devais donc avoir au moins eu vent de cette histoire.
Au-delà, il s'agit d'un souci généralisable à tout ce matériel "proprio" comportant blobs ou pilotes non libres (cartes vidéos ou réseau entre autres).
L'utilisateur a fait le choix d'un tel matériel; c'est à lui d'en assumer les conséquences.
Nous devrions plutot conserver notre énergie pour faire évoluer la logique des constructeurs afin que ce type de problème ne se présente plus.
Mais ce n'est certainement pas à la distribution d'écorner son éthique à mes yeux. Dans notre société de consommation, il y a encore cette possibilité de faire des choix "raisonnés" et éthiquement satisfaisant (en lieu et place du je-veux-tout-tout-de-suite-pour-pas-cher-du-tout). J'espère préserver cette possibilité encore longtemps.
* un blob binaire, c'est le reflet d'un choix du constructeur :
- économie de ROM/RAM sur le matériel
- souplesse de configuration (évite le flashage à chaque release) et donc là aussi économie (temps et utilitaire de flashage)
Dans le premier cas, ce que l'utilisateur ne paie pas avec le matériel, il devra le payer ailleurs (CPU+RAM sur son PC grossièrement) : mauvais calcul
Dans le second cas, il n'y a pas de raison que cela reste un blob binaire. La raison "IP" (i.e Intellectual Property) est un faux fuyant du constructeur.
Bref, et il ne s'agit que de mon avis, je partage ce choix de supprimer les blobs et c'est à chacun d'en mesurer/assumer les conséquences, pas à la distribution.
SMIT reste à mes yeux la meilleure interface d'administration sous *NIX.
Montrer les outils et la syntaxe des commandes exécutées pour chaque manipulation effectuée reste le meilleure moyen d'appréhender le système et j'avoue que ça reste la meilleure interface de ce type rencontrée (entre AIX, Sun Solaris, HPUX, Linux Debian/SuSE/RedHat, BSD *mouhaha*, True64)
Comparé SMIT à du YaST ou consort est inimaginable tant l'administration est simplifiée avec la logique de SMIT.
Combien de fois je peste pour retrouver la syntaxe ou les fichiers modifiés par YaST, simplement parce qu'il ne permet pas de faire ce que je souhaite ou que la configuration réalisée ne fonctionne pas... (ex: DNS, SASL, LDAP...) ou que je ne comprends pas la logique des options de l'IHM.
Bref, je ne doute pas qu'openSuSE soit une bonne distribution mais, question administration, pour rien au monde je n'abandonnerai Debian (serveur) & (X)Ubuntu (workstation).
Reste plus qu'à trouver un équivalent de SMIT et ce serait le bonheur parfait :)
Non, ce qu'il reproche en définitive à Linux c'est la profusion accessible et difficilement décryptable à priori.
Ce foisonnement est effectivement troublant pour bien des gens, moi le premier (enfin parfois).
Avec Windows, on a cette impression de simplicité car on installe un OS, cohérent vu de loin, sans se préoccuper des logiciels (qui sont pourtant ce qui intéresse l'utilisateur au final). Mais c'est sans parler des drivers à venir, de la customisation de l'OS et des applications. A partir de là, tout se complique mais la sphère Windows a souvent tendance à l'oublier...
Avec Linux, on installe une distribution qui inclue l'ensemble, de l'OS à l'application finale. Et les détracteurs profitent trop souvent de ce tout utilisable pour entretenir les confusions ou les comparaisons qui n'ont pas lieu d'être.
Au fil des ans, j'ai aussi une impression similaire bien qu'assortie d'une conclusion différente.
Quand il y a quelques années je passais des jours et des jours à faire reconnaitre un matériel par le noyau, à chercher une documentation sur une particularité matérielle avant d'installer ou à trouver le patch nécessaire pour démarrer, aujourd'hui je réinstalle tout un parc en quelques jours, sur du matériel très récent avec de la virtualisation dans tous les sens et des services opérationnels, à minima identiques aux précédents.
Tout ce temps "économisé" peut ainsi être "investi" dans l'exploration d'autres applications voire d'autres domaines fonctionnel ou dans l'aide aux utilisateurs.
L'avantage c'est que maintenant avec Windows, même sur une base d'une version de l'OS tous les 5 ans, il a l'avantage énorme d'être occupé à tout réinstaller, au mieux, chaque semestre.
Pour ma part, j'ai abandonné totalement Windows (hors poste bureautique obligatoire au boulot) depuis 3 ans.
A aucun moment je ne regrette ce choix (étant pourtant joueur, mais on s'adapte :). Je reste juste encore désorienté parfois avec tout ce choix.
Lorsqu'on réalise qu'il s'agit de richesse plus que de profusion anarchique... Encore faut il aller plus loin que l'évidence marketing \o/
Au final, tes interventions sont à l'image de la communauté *BSD que j'ai pu croiser.
Moi, moi, moi... sans écouter l'autre au delà de l'évidence.
C'est dommage.
1/ S'il ne s'agissait que d'un PKG_PATH...
2/ Tu as beaucoup de chance. Pour ma part, depuis SuSe 1.x ou Fedora 3.x je n'ai jamais rien perdu sur un FS journalisé Linux. Concernant OpenBSD, je t'invite à passer chez moi à l'occasion... Quoiqu'il en soit, la vérification automatique ou manuelle du FS est décevante, reflet des possbilités du FS lui-même (et je ne parle pas de la logique de partitionnement). Au passage, Xfs n'est pas issu de Linux (à ma connaissance).
3/ pour ton information, j'utilise apt et dpkg exclusivement. Je cherche encore le clic. Question fonctionnalité, je t'invite à lire les man de ces utilitaires ainsi que les spécifications pour te convaincre de leurs fonctionnalités.
Pour terminer, je pense savoir lire et je ne crois pas que la difficulté ait été insurmontable, la communauté un tantinet plus malheureusement... preuve en est avec tes propos.
Mon souhait était d'expérimenter PF pour mettre en production à terme. Et effectivement, j'exerce ma pleine et entière liberté en refusant ce terme et en affirmant que cette expérience fut décevante. Ne t'en déplaise.
Enfin, je doute qu'on puisse parler d'amitié (i.e. ton "amicalement") avec des airs supérieurs et un manque caractérisé d'ouverture d'esprit et de respect...
Pour ma part, il y a trois choses que je n'apprécie vraiment chez OpenBSD :
1/ le système de packaging extrêment pauvre (simplicité, configuration, mise en route et documentation associée)
Sur ce point, la doc (officielle et littérature de "référence"), je l'ai lue et relue dans tous les sens sans jamais trouver de réponse qui aille au bout des choses.
2/ la robustesse du système de fichier est à pleurer. On se croirait revenu 20 ans en arrière quand une coupure brusque du système signifiait 4h de maintenance.
3/ les fonctionnalités de l'installer sont pauvres (bien que suffisantes dans les cas simples)
Alors franchement, tes leçons sont à l'image de la communauté *BSD que j'ai pu croiser sur les forums "RTF pauvre débile" et "ma conception de la liberté est LA vérité".
Très peu pour moi (bien que j'adhère plus à la logique de Libre *BSD que Linux en suspens...) et c'est d'autant plus dommage que de nombreuses solutions techniques sont très séduisantes.
Pour ma part c'est l'inverse...
SuSe imposée par mon employeur, je fais tout pour aller vers une distribution qui permet de faire quelque chose, quitte à passer un temps qui se concrétisera en résultat. Comme quoi...
SuSe, ça me fait penser à un OpenBSD avec des IHM de partout (YaST*), la sécurité en moins et pas grand chose dedans.
"Les pilotes de cartes réseau sont en général assez simple et peu buggués..."
Je crois que les derniers pilotes Intel e1000 ne sont pas de ton avis.
https://lists.ubuntu.com/archives/ubuntu-devel-announce/2008(...)
"Reports have been coming in that the e1000e ethernet driver for Intel GigE chipsets, as included upstream in Linux 2.6.27, may under certain conditions irreparably damage your ethernet hardware by corrupting the on-board firmware."
En réalité, Emacs a connu un réel début de popularité avec l'avènement de l'ADSL et des disques durs à grande capacité (> 40 Go).
Auparavant, il était resté confidentiel car il faut bien avouer qu'une copie sur supports amovibles multiples n'est pas pratique à trimballer.
Gageons effectivement que le Blu-Ray participera à la décongestion des réseaux et des serveurs de téléchargement...
Ceci explique aussi le retard accumulé sur Vi (sans parler de Vim) après tant d'années passé dans la clandestinité.
En toute honnêteté, j'ai un peu le sentiment que ce problème est accentué par l'utilisation de SuSE (RedHat je ne connais pas/plus assez pour juger).
Dans une optique Debian et/ou Ubuntu (avec des cycles de vie de version différents), le principe stable/testing/unstable voire experimental permet de conserver un système de base très peu modifié tout en profitant de versions logicielles récentes. Dans les rares autres cas, le nombre de backports demeure appréciable et suffisant. Au pire, une compilation règle les derniers soucis.
Il est excessivement rare de devoir aller jusqu'à mettre à jour la libc ou autre composant de "bas niveau" entrainant incompatibilités et installations multiples, hors sortie de versions majeures (pas fréquent du côté de Debian ^^) ou mises à jour de sécurité... ou bidouillages incessants aussi (genre desktop) :)
Quant bien même une installation du système de base deviendrait nécessaire (mise à jour majeure ou besoin de version logicielle), la configuration reste peu touchée et reste cantonnée à de la migration de formats ou à un complément de configuration le plus souvent (si la nouvelle version ne le fait pas pour vous). Cette étape est de plus soit guidée par le système de packaging (dpkg, apt et frontend dans le cas Debian) soit suffisament documentée pour rester simple.
Et on ne fait pas cela tous les 4 matins non plus.
A l'inverse, le "Système Manager" type SuSE (YaST) reste une boite noire qui opère pas mal de modifications hors contrôle de l'utilisateur (scripts de mises à jour de la configuration lancés lors de la valiation des changements).
Cela nécessite beaucoup moins d'intervention dans la majorité des cas simples. Mais à contrario, seuls les cas simples sont gérés au travers de YaST ce qui signifie mettre réellement les mains dans le cambouis lorsqu'on souhaite particulariser son installation (et pas toujours simple de retrouver ses petits) et réinitialisation de sa configuration personnalisée en cas de reinstallations majeures.
Bref, les distributions type SuSE offre une facilité de façade (sans être péjoratif) mais ne sont sans doute pas adaptées à une utilisation un tant soit peu avancée à partir du moment où on ne souhaite pas suivre leur rythme de release (vrai pour Ubuntu aussi dans une moindre mesure).
Bon après, on ne peut pas non plus prétendre systématiquement faire le grand écart entre système de base et versions logicielles de niveau utilisateur car chaque application souhaite bénéficier des dernières fonctionnalités offertes par ce même système de base.
Et d'autres OS ne font pas mieux (voire XP et directX 10 par exemple) du reste.
Sauf que si tu dois automatiser le traitement d'images, il est tout de suite plus compliqué d'avoir un opérateur derrière son écran, qu'il s'agisse de traitement batch ou en flux.
Pour ce qui est du traitement d'images satellites par exemple (dont un certain nombre aurait mérite à s'appuyer sur des logiciels éprouvés plutot que de "réinventer la roue"), la majorité des traitements s'effectue de manière automatique, quitte à avoir un contrôle visuel en fin de chaine.
Il est plus intéressant de nos jours, avec la puissance de calcul disponible, de traiter une image, même multi-spectrale, par défaut puis de contrôler et de refaire le traitement avec des paramètres différents au besoin que d'avoir un opérateur effectuant toujours les mêmes opérations, sans valeur ajoutée... si ce n'est dans 0,5% des cas.
Bien que n'y connaissant pas grand chose en formats de compression (je n'ai pas d'avis à priori sur l'ogv ni le h624), je crois que le rapport de compression n'a aps grand chose à voir avec la notion de qualité entre formats (j'insiste sur le "entre formats").
Pour moi, chaque format utilise certains algorithmes de compression et de "simplification" de l'image originelle. De même que chaque codec utilise des options de compression par défaut plus ou moins destructeurs.
Selon ces choix, la performance de compression peut être plus ou moins bonne mais cela ne renseigne pas sur les pertes (même si on pourrait penser qu'un résultat de compression 2x moins volumineux serait moins bon) de qualité.
En résumé, "vidéo en .ogv = 34mo" ne dit rien sur les algos/options utilisées (même par défaut), pas plus que "fmpeg -sameq -i ./mavid.ogv mavid.avi = 74mo" + "transcoder (...) en mp4-avc = 7mo"... à moins de tenter de reproduire et de se plonger dans la doc.
Sachant qu'on ne dispose pas de la video originale...
Donc, si tu pouvais éclairer notre lanterne sur ces deux formats/codec, par avance merci :)
"Linux date de 1991, focaliser un an de sa vie sur un outil qui a moins de 20 ans en formation initial ne me parait pas très sage."
En même temps, AIX par exemple date de 1986. Il a donc plus de vingt ans et pourtant... une certification AIX concerne une version et non le système lui-même. Et cette version n'a certainement pas une telle durée de vie.
De la même façon, je doute qu'entre Solaris 1.0 et OpenSolaris actuel il y ait grand chose de commun (pour une utilisation avancée ou experte. Même les passages Solaris 8, 9, 10 ont vu énormément de nouveautés.
Par ailleurs, ces "dinosaures " (sans être péjoratif) seraient plutôt en perte de vitesse dans le monde de l'netreprise vis-à-vis de Linux et ce sans parler de systèmes ayant rendu l'âme ou n'évoluant plus (je pense à Compaq True64, Netware, SCO...).
Bref, dans le domaine IT, se former est aussi prendre un pari sur l'avenir selon les tendances du moment comme ses aspirations. En outre, parier sur Linux ne peut pas être un mauvais pari puisque cela ouvre aussi des portes côté Unix et tout un ensemble de technologies informatiques connexes (réseau, interopérabilité...).
Il s'agit ici de certification. Il est donc difficille d'y ajouter UNIX proprio et *BSD.
Mais je reste d'accord avec toi. Seule une connaissance conjointe Unix, *BSD et Linux présente aujourd'hui une valeur ajoutée sur le long terme. Cependant, cette connaissance ne peut être acquise qu'avec l'expérience et côté formation, il faut bien commencer quelque part.
Linux ne me parait pas être le plus "mauvais bout" :)
[^] # Re: Et sinon c'est quoi Maven ?
Posté par Quzqo . En réponse à la dépêche Première relecture publique de la traduction de Maven - The definitive guide. Évalué à 5.
Dit comme ça, ça reste très vague je l'avoue.
Pour donner un exemple plus concret, nous l'utilisons actuellement pour :
° Modéliser un système (équivalent d'un fichier de déploiement automatique de distribution Linux mais avec un modèle fonctionnel, pas seulement fonction/package, et pour un parc entier de machines, sans la partie OS -prérequis-)
° Créer l'arborescence de développement/intégration
° Rapatrier les différents pakages (nos applications métiers)
° Créer & instancier les données de configuration
° Créer les templates de développement spécifiques (non modélisables) avec leur configuration
° Créer les templates de documentation
° Valider les dépendances (définies par le modèle)
° Générer la documentation
° Repackager les applications configurées/développées
° Mettre à jour le repository
° Créer une distribution (CD/DVD) réunissant installation unifiée du système et documentation à jour
S'approprier Maven et réaliser les développements spécifiques à notre métier a été "lourd" mais un processus d'intégration qui prenait par le passé plusieurs mois (échelle d'une année), représente actuellement quelques semaines à 2-3 mois selon la complexité du projet.
Cela permet aussi d'imposer une méthodologie reproductible, réutilisable en phase de maintenance et... capitalisable (au travers de la modélisation amont et des packages).
Merci Maven.
PS: environ 30% de nos applications sont développées en Java. Ce langage n'est donc pas le seul à bénéficier de ce framework (même s'il bénéficie au mieux de ses avantages).
[^] # Re: Conclusion hâtive
Posté par Quzqo . En réponse au journal Microsoft : Essaye encore petit scarabée !. Évalué à -1.
Je me souviens maintenant pourquoi je ne postais plus sur LinuxFR depuis si longtemps : cette impossibilité à échanger de façon modérée ou à proposer un avis un tant soit peu divergent de la "bonne pensée" linuxienne.
Quelque part ça me fait bien rire, d'un rire un peu triste, de voir que le ton ici n'a pas changé malgré les années passées.
Bonne suite et bonne pensée unique :)
[^] # Re: Il n'empêche...
Posté par Quzqo . En réponse au journal Microsoft , Linux, BestBuy. Évalué à 2.
Une autre hypothèse à envisager serait que ton propos initial n'était pas clair d'où ma compréhension erronée et mon jugement non pertinent ^^
[^] # Re: Il n'empêche...
Posté par Quzqo . En réponse au journal Microsoft , Linux, BestBuy. Évalué à 2.
[^] # Re: Conclusion hâtive
Posté par Quzqo . En réponse au journal Microsoft : Essaye encore petit scarabée !. Évalué à 0.
Et propriétaire ou non, ce n'est pas trop la question à mes yeux.
Xen (avant Citrix, depuis j'avoue être paumé) a longtemps fait/proposé des modifications dans le noyau sans pour autant qu'elles soient intégrées à la branche officielle.
A ce compte là, les "devs du noyau" ne sont pas là pour faire tourner quoique ce soit. Ils pourraient d'ailleurs faire des trucs dans leur coin, sans communiquer.
Ce n'est pourtant pas ainsi que ça fonctionne. A croire que ce n'est pas ce qu'"ils" veulent (en supposant que les "devs du noyau" parlent d'une seule voix) mais qu'ils souhaitent plutôt offrir le maximum de services aux applications (au sens très large). Etonnant non pour un système d'exploitation...
[^] # Re: Conclusion hâtive
Posté par Quzqo . En réponse au journal Microsoft : Essaye encore petit scarabée !. Évalué à 2.
Heu... p't'être faire tourner Linux sur du Windows non ?
Après, personne n'est obligé d'offrir de la m**** en guise de cadeau effectivement (personnellement j'aurais un peu honte de présenter un travail à moitié fait).
"API interne seulement. En ce qui concerne l'API qui s'interface avec le userland ça reste stable (et heureusement !). "
l'ABI (donc API) n'est pas stable au sens ou elle change souvent (i.e. fréquement), hors userland. On en peut donc pas qualifier cela d'interne ni de stable.
A bien des égards, c'est un avantage... sauf dans celui des drivers (entre autres), ce qui oblige les éditeurs (proprio) à de gros efforts.
Foison de nouvelles fonctionnalités (même bas niveau), sans pouvoir en profiter... Donc, résultat mitigé à mes yeux *
* oui, on peut viser le tout-libre mais entre souhait et réalité, certains choix sont parfois nécessaires. La véritable liberté est ici à mes yeux : pouvoir vivre et assumer le choix de ses contradictions.
[^] # Re: Et alors ?
Posté par Quzqo . En réponse au journal Microsoft , Linux, BestBuy. Évalué à 3.
Pas forcément un mensonge éhonté mais plutôt enjoliver la réalité, taire certains points gênants...
Si apparaitre dans les linéaires de la grande distribution signifie marketing... je ne suis pas pressé d'y voir nos LL.
Et je continue à soutenir les vertus de l'éducation en matière de LL, de proche en proche... pas au travers de grandes campagnes de sensibilisation avec plein de petits bouts de marketing dedans.
Un utilisateur convaincu devient fidèle... et ne change pas son fusil d'épaule à chaque changement de vent.
Sur cette base, on ne peut pas espérer d'adhésions massives, mais des adhésions durables. C'est une démarche de fond, sur le long terme. Mais, au final, les gens qui nous entourent adhèrent pour de "bonnes" raisons (ou qui me semblent bonnes :), et ce cercle grandit au fil du temps.
Patience et discipline... \o/
[^] # Re: Il n'empêche...
Posté par Quzqo . En réponse au journal Microsoft , Linux, BestBuy. Évalué à 2.
Dommage de prendre typiquement l'exemple d'un protocol (LDAP) compliqué par essence qu'il s'agisse du schéma, de l'interrogation ou de la mise à jour des données.
Un utilitaire (MS) comme ldifde te permet de faire cela en ligne de commande.
Il est fourni de base avec les versions server : équivalent (dans la logique MS) à installer un package LDAP client sous Linux.
Bref, je pense que ton exemple n'est pas pertinent.
Au-delà de ça, la logique LDAP-Active Directory (*) est bien plus perturbante que la complexité de l'outil fourni en ligne de commande.
(*) schéma minimaliste, hiérarchie LDAP non valorisée, respect de la norme succinct...
Globalement, les "Consoles d'administration" Windows (ajout fonctionnels selon les services installés) ne sont pas mal foutues (par rapport au clic-clic accessible de base) mais manquent cruellement
1/ de cohérence
2/ d'adoption hors des softs MS.
Mais il faut voir aussi qu'en partant d'une base cmd.exe, il est quasiment impossible d'avoir des fonctionnalités évoluées de scripting (fournies par le shell csh/ksh/bash... sous Linux) : builtin, boucles, variables (typées selon le shell), environnement, fork...
Plus généralement, les produits MS, ça devient aujourd'hui 80% de discours marketing mais de moins en moins d'innovations (hors ergonomie) et des décennies de retard technologique.
Côté avancée technologique, on peut citer : virtualisation (HyperV), mises à jour, ligne de commande, interface "3D", intégration, déploiement "massif"...
Ca donne l'impression que MS place ses efforts dans la préservation de ses acquis plutot que dans l'innovation (budget com/marketing, support matériel sans valorisation, segmentation de l'offre **) sur la base de bla-bla.
Hier Exchange 2003, aujourd'hui Excahnge 2007 + sharedPoint : même fonctionnalités (à nu pouillème) mais de 1 licence -> 2 licences \o/
[^] # Re: Fallais y penser !!!
Posté par Quzqo . En réponse à la dépêche Processeur graphique : NVIDIA est mal parti pour les années à venir. Évalué à 4.
Comparaison nVidia (avec Processeur de traitement parallèle, i.e. CUDA) :
- Gamme grand public : 8 références* dont haut de gamme GeForce GTX 295 ~480€
- Gamme professionnelle : 12 références dont haut de gamme Quadro FX 5800 ~3500-4000€, Quadro NVS 450 ~450€
Penses-tu toujours qu'il n'y a que les "gamers" pour acheter de grosses cartes graphiques ?
* "véritables" références (caractéristiques GPU) faisant partie de l'offre officielle du constructeur
Et accessoirement, ces traitements, câblés ou programmables, dans le GPU/processeur parallèle constituent une véritable optimisation des performances... dans un contexte donné et précis.
Le souci est qu'aujourd'hui avec CUDA et consorts, les développeurs voudraient faire du GPU/processeur parallèle un processeur générique avec gestionnaire de mémoire intégré et puissance de calcul supérieur au processeur central...
Curieusement, ça exige 1/ des efforts 2/ de diminuer ses prétentions...
Rien de nouveau sous le soleil...
# Direct3D, pas DirectX
Posté par Quzqo . En réponse à la dépêche Spécifications OpenGL 3.1. Évalué à 5.
° Elle arrive fort tard par rapport à la sortie de DirectX 10.x alors qu'il aurait été de bon ton de "profiter" du flou des API introduit avec Vista et la version 10
° En termes de jeux, on ne peut pas limiter l'intérêt d'une API au rendu 2D/3D. Là où DirectX apporte un support multimédia complet (3D, video, son, réseau et périphériques) aux développeurs, OpenGL est limité à la 2D/3D. L'abstraction est donc "globalement" bien moins intéressante.
° Bénéficier aujourd'hui d'une 3D performante signifie utiliser des pilotes propriétaires (oublions les chipset Intel...) et ces pilotes, outre leurs limitations (proprio), sont peu supportés (voir entre autres les derniers articles concernant ATI et le point de vue des mainteneurs sur les forums Phoronix) et surtout peu performants en OpenGL. Curieux tout de même qu'il y ait des outils de benchs à foison en DirectX et si peu pour OpenGL (mais les piètres performances ne sont sans doute pas la seule raison).
Au final, je ne sais pas ce qu'il en est pour la 3D professionnelle et OpenGL mais côté jeux et plus généralement multimédia, OpenGL a encore bien des obstacles à franchir avant d'occuper une place de choix sur nos Desktop.
Le seul avantage que j'y vois (ne connaissant pas ses attraits purement techniques) est son caractère multiplateforme.
Et pour ce qui est des interfaces de programmation disponibles sur les CG, cela reste encore limité par le caractère fortement parallélisable et, intrinsèquement, à forte itération (sans renouvellement intensif des données traitées) du fait des goulots d'étranglement matériels *
Cela reste donc aujourd'hui plus marketing qu'utile pour le grand public à mon avis.
* mais je me trompe peut être sur ce point
[^] # Re: Le Release Manager de Debian est un froussard!
Posté par Quzqo . En réponse à la dépêche Debian GNU/Linux 5.0 : Lenny. Évalué à 3.
Hum oui, je pense que tu as bien cerné le Contrat Social de Debian, principalement le point 4...
Après qu'il puisse y avoir des dysfonctionnement c'est certain; chaque distribution demeure perfectible.
Toutefois, même moi qui ne suis plus que de très loin les news Debian, je savais qu'elle allait supprimer les blobs binaires à l'horizon Lenny. Sachant que 1+1 = 2, il n'était pas franchement compliqué d'anticiper les problèmes avec du matériel un peu "limite" (dans le sens où ces blobs sont à mes yeux une hérésie, non dans le principe* mais au même titre que les drivers videos proprio). Tu te dis utilisateur Debian; tu devais donc avoir au moins eu vent de cette histoire.
Au-delà, il s'agit d'un souci généralisable à tout ce matériel "proprio" comportant blobs ou pilotes non libres (cartes vidéos ou réseau entre autres).
L'utilisateur a fait le choix d'un tel matériel; c'est à lui d'en assumer les conséquences.
Nous devrions plutot conserver notre énergie pour faire évoluer la logique des constructeurs afin que ce type de problème ne se présente plus.
Mais ce n'est certainement pas à la distribution d'écorner son éthique à mes yeux. Dans notre société de consommation, il y a encore cette possibilité de faire des choix "raisonnés" et éthiquement satisfaisant (en lieu et place du je-veux-tout-tout-de-suite-pour-pas-cher-du-tout). J'espère préserver cette possibilité encore longtemps.
* un blob binaire, c'est le reflet d'un choix du constructeur :
- économie de ROM/RAM sur le matériel
- souplesse de configuration (évite le flashage à chaque release) et donc là aussi économie (temps et utilitaire de flashage)
Dans le premier cas, ce que l'utilisateur ne paie pas avec le matériel, il devra le payer ailleurs (CPU+RAM sur son PC grossièrement) : mauvais calcul
Dans le second cas, il n'y a pas de raison que cela reste un blob binaire. La raison "IP" (i.e Intellectual Property) est un faux fuyant du constructeur.
Bref, et il ne s'agit que de mon avis, je partage ce choix de supprimer les blobs et c'est à chacun d'en mesurer/assumer les conséquences, pas à la distribution.
[^] # Re: Quelques remarques...
Posté par Quzqo . En réponse à la dépêche Test d'openSUSE 11.1. Évalué à 2.
Montrer les outils et la syntaxe des commandes exécutées pour chaque manipulation effectuée reste le meilleure moyen d'appréhender le système et j'avoue que ça reste la meilleure interface de ce type rencontrée (entre AIX, Sun Solaris, HPUX, Linux Debian/SuSE/RedHat, BSD *mouhaha*, True64)
Comparé SMIT à du YaST ou consort est inimaginable tant l'administration est simplifiée avec la logique de SMIT.
Combien de fois je peste pour retrouver la syntaxe ou les fichiers modifiés par YaST, simplement parce qu'il ne permet pas de faire ce que je souhaite ou que la configuration réalisée ne fonctionne pas... (ex: DNS, SASL, LDAP...) ou que je ne comprends pas la logique des options de l'IHM.
Bref, je ne doute pas qu'openSuSE soit une bonne distribution mais, question administration, pour rien au monde je n'abandonnerai Debian (serveur) & (X)Ubuntu (workstation).
Reste plus qu'à trouver un équivalent de SMIT et ce serait le bonheur parfait :)
[^] # Re: argumentaire foireux
Posté par Quzqo . En réponse au journal Béranger passe à Windows. Évalué à 4.
Ce foisonnement est effectivement troublant pour bien des gens, moi le premier (enfin parfois).
Avec Windows, on a cette impression de simplicité car on installe un OS, cohérent vu de loin, sans se préoccuper des logiciels (qui sont pourtant ce qui intéresse l'utilisateur au final). Mais c'est sans parler des drivers à venir, de la customisation de l'OS et des applications. A partir de là, tout se complique mais la sphère Windows a souvent tendance à l'oublier...
Avec Linux, on installe une distribution qui inclue l'ensemble, de l'OS à l'application finale. Et les détracteurs profitent trop souvent de ce tout utilisable pour entretenir les confusions ou les comparaisons qui n'ont pas lieu d'être.
Au fil des ans, j'ai aussi une impression similaire bien qu'assortie d'une conclusion différente.
Quand il y a quelques années je passais des jours et des jours à faire reconnaitre un matériel par le noyau, à chercher une documentation sur une particularité matérielle avant d'installer ou à trouver le patch nécessaire pour démarrer, aujourd'hui je réinstalle tout un parc en quelques jours, sur du matériel très récent avec de la virtualisation dans tous les sens et des services opérationnels, à minima identiques aux précédents.
Tout ce temps "économisé" peut ainsi être "investi" dans l'exploration d'autres applications voire d'autres domaines fonctionnel ou dans l'aide aux utilisateurs.
L'avantage c'est que maintenant avec Windows, même sur une base d'une version de l'OS tous les 5 ans, il a l'avantage énorme d'être occupé à tout réinstaller, au mieux, chaque semestre.
Pour ma part, j'ai abandonné totalement Windows (hors poste bureautique obligatoire au boulot) depuis 3 ans.
A aucun moment je ne regrette ce choix (étant pourtant joueur, mais on s'adapte :). Je reste juste encore désorienté parfois avec tout ce choix.
Lorsqu'on réalise qu'il s'agit de richesse plus que de profusion anarchique... Encore faut il aller plus loin que l'évidence marketing \o/
[^] # Re: [ X ] m'en fout
Posté par Quzqo . En réponse au sondage Debian Lenny sortira :. Évalué à 1.
Moi, moi, moi... sans écouter l'autre au delà de l'évidence.
C'est dommage.
1/ S'il ne s'agissait que d'un PKG_PATH...
2/ Tu as beaucoup de chance. Pour ma part, depuis SuSe 1.x ou Fedora 3.x je n'ai jamais rien perdu sur un FS journalisé Linux. Concernant OpenBSD, je t'invite à passer chez moi à l'occasion... Quoiqu'il en soit, la vérification automatique ou manuelle du FS est décevante, reflet des possbilités du FS lui-même (et je ne parle pas de la logique de partitionnement). Au passage, Xfs n'est pas issu de Linux (à ma connaissance).
3/ pour ton information, j'utilise apt et dpkg exclusivement. Je cherche encore le clic. Question fonctionnalité, je t'invite à lire les man de ces utilitaires ainsi que les spécifications pour te convaincre de leurs fonctionnalités.
Pour terminer, je pense savoir lire et je ne crois pas que la difficulté ait été insurmontable, la communauté un tantinet plus malheureusement... preuve en est avec tes propos.
Mon souhait était d'expérimenter PF pour mettre en production à terme. Et effectivement, j'exerce ma pleine et entière liberté en refusant ce terme et en affirmant que cette expérience fut décevante. Ne t'en déplaise.
Enfin, je doute qu'on puisse parler d'amitié (i.e. ton "amicalement") avec des airs supérieurs et un manque caractérisé d'ouverture d'esprit et de respect...
[^] # Re: [ X ] m'en fout
Posté par Quzqo . En réponse au sondage Debian Lenny sortira :. Évalué à 3.
1/ le système de packaging extrêment pauvre (simplicité, configuration, mise en route et documentation associée)
Sur ce point, la doc (officielle et littérature de "référence"), je l'ai lue et relue dans tous les sens sans jamais trouver de réponse qui aille au bout des choses.
2/ la robustesse du système de fichier est à pleurer. On se croirait revenu 20 ans en arrière quand une coupure brusque du système signifiait 4h de maintenance.
3/ les fonctionnalités de l'installer sont pauvres (bien que suffisantes dans les cas simples)
Alors franchement, tes leçons sont à l'image de la communauté *BSD que j'ai pu croiser sur les forums "RTF pauvre débile" et "ma conception de la liberté est LA vérité".
Très peu pour moi (bien que j'adhère plus à la logique de Libre *BSD que Linux en suspens...) et c'est d'autant plus dommage que de nombreuses solutions techniques sont très séduisantes.
[^] # Re: [ X ] m'en fout
Posté par Quzqo . En réponse au sondage Debian Lenny sortira :. Évalué à 4.
SuSe imposée par mon employeur, je fais tout pour aller vers une distribution qui permet de faire quelque chose, quitte à passer un temps qui se concrétisera en résultat. Comme quoi...
SuSe, ça me fait penser à un OpenBSD avec des IHM de partout (YaST*), la sécurité en moins et pas grand chose dedans.
Bien sur, ceci n'est pas un troll.
[^] # Re: Petite question: noyau monolithique?
Posté par Quzqo . En réponse à la dépêche Nouvelle version 2.6.27 du noyau Linux. Évalué à 1.
Je crois que les derniers pilotes Intel e1000 ne sont pas de ton avis.
https://lists.ubuntu.com/archives/ubuntu-devel-announce/2008(...)
"Reports have been coming in that the e1000e ethernet driver for Intel GigE chipsets, as included upstream in Linux 2.6.27, may under certain conditions irreparably damage your ethernet hardware by corrupting the on-board firmware."
[^] # Re: polymique...
Posté par Quzqo . En réponse à la dépêche Mono 2.0 : le singe continue ses grimaces. Évalué à 8.
Là on voit que tu ne connais pas mon amie....
[^] # Re: Cool !
Posté par Quzqo . En réponse à la dépêche Debian Lenny is a Live !. Évalué à 3.
Auparavant, il était resté confidentiel car il faut bien avouer qu'une copie sur supports amovibles multiples n'est pas pratique à trimballer.
Gageons effectivement que le Blu-Ray participera à la décongestion des réseaux et des serveurs de téléchargement...
Ceci explique aussi le retard accumulé sur Vi (sans parler de Vim) après tant d'années passé dans la clandestinité.
# Préoccupation SuSE ?
Posté par Quzqo . En réponse au journal [Troll du vendredi] Mettre au même niveau la base des distributions stables en regard des logiciels utilisateurs est-il vraiment une bonne chose ?. Évalué à 2.
Dans une optique Debian et/ou Ubuntu (avec des cycles de vie de version différents), le principe stable/testing/unstable voire experimental permet de conserver un système de base très peu modifié tout en profitant de versions logicielles récentes. Dans les rares autres cas, le nombre de backports demeure appréciable et suffisant. Au pire, une compilation règle les derniers soucis.
Il est excessivement rare de devoir aller jusqu'à mettre à jour la libc ou autre composant de "bas niveau" entrainant incompatibilités et installations multiples, hors sortie de versions majeures (pas fréquent du côté de Debian ^^) ou mises à jour de sécurité... ou bidouillages incessants aussi (genre desktop) :)
Quant bien même une installation du système de base deviendrait nécessaire (mise à jour majeure ou besoin de version logicielle), la configuration reste peu touchée et reste cantonnée à de la migration de formats ou à un complément de configuration le plus souvent (si la nouvelle version ne le fait pas pour vous). Cette étape est de plus soit guidée par le système de packaging (dpkg, apt et frontend dans le cas Debian) soit suffisament documentée pour rester simple.
Et on ne fait pas cela tous les 4 matins non plus.
A l'inverse, le "Système Manager" type SuSE (YaST) reste une boite noire qui opère pas mal de modifications hors contrôle de l'utilisateur (scripts de mises à jour de la configuration lancés lors de la valiation des changements).
Cela nécessite beaucoup moins d'intervention dans la majorité des cas simples. Mais à contrario, seuls les cas simples sont gérés au travers de YaST ce qui signifie mettre réellement les mains dans le cambouis lorsqu'on souhaite particulariser son installation (et pas toujours simple de retrouver ses petits) et réinitialisation de sa configuration personnalisée en cas de reinstallations majeures.
Bref, les distributions type SuSE offre une facilité de façade (sans être péjoratif) mais ne sont sans doute pas adaptées à une utilisation un tant soit peu avancée à partir du moment où on ne souhaite pas suivre leur rythme de release (vrai pour Ubuntu aussi dans une moindre mesure).
Bon après, on ne peut pas non plus prétendre systématiquement faire le grand écart entre système de base et versions logicielles de niveau utilisateur car chaque application souhaite bénéficier des dernières fonctionnalités offertes par ce même système de base.
Et d'autres OS ne font pas mieux (voire XP et directX 10 par exemple) du reste.
[^] # Re: x264
Posté par Quzqo . En réponse au journal Quelle est la meilleure méthode pour compresser des fichiers AVI .... Évalué à 1.
[^] # Re: Pas d'IG ?
Posté par Quzqo . En réponse à la dépêche G'MIC : Un nouvel outil libre de manipulation d'images.. Évalué à 6.
Pour ce qui est du traitement d'images satellites par exemple (dont un certain nombre aurait mérite à s'appuyer sur des logiciels éprouvés plutot que de "réinventer la roue"), la majorité des traitements s'effectue de manière automatique, quitte à avoir un contrôle visuel en fin de chaine.
Il est plus intéressant de nos jours, avec la puissance de calcul disponible, de traiter une image, même multi-spectrale, par défaut puis de contrôler et de refaire le traitement avec des paramètres différents au besoin que d'avoir un opérateur effectuant toujours les mêmes opérations, sans valeur ajoutée... si ce n'est dans 0,5% des cas.
[^] # Re: x264
Posté par Quzqo . En réponse au journal Quelle est la meilleure méthode pour compresser des fichiers AVI .... Évalué à 2.
Pour moi, chaque format utilise certains algorithmes de compression et de "simplification" de l'image originelle. De même que chaque codec utilise des options de compression par défaut plus ou moins destructeurs.
Selon ces choix, la performance de compression peut être plus ou moins bonne mais cela ne renseigne pas sur les pertes (même si on pourrait penser qu'un résultat de compression 2x moins volumineux serait moins bon) de qualité.
En résumé, "vidéo en .ogv = 34mo" ne dit rien sur les algos/options utilisées (même par défaut), pas plus que "fmpeg -sameq -i ./mavid.ogv mavid.avi = 74mo" + "transcoder (...) en mp4-avc = 7mo"... à moins de tenter de reproduire et de se plonger dans la doc.
Sachant qu'on ne dispose pas de la video originale...
Donc, si tu pouvais éclairer notre lanterne sur ces deux formats/codec, par avance merci :)
[^] # Re: Paris, Paris... Toujours Paris !
Posté par Quzqo . En réponse à la dépêche IP-formation : la formation administrateur Linux menacée. Évalué à 2.
En même temps, AIX par exemple date de 1986. Il a donc plus de vingt ans et pourtant... une certification AIX concerne une version et non le système lui-même. Et cette version n'a certainement pas une telle durée de vie.
De la même façon, je doute qu'entre Solaris 1.0 et OpenSolaris actuel il y ait grand chose de commun (pour une utilisation avancée ou experte. Même les passages Solaris 8, 9, 10 ont vu énormément de nouveautés.
Par ailleurs, ces "dinosaures " (sans être péjoratif) seraient plutôt en perte de vitesse dans le monde de l'netreprise vis-à-vis de Linux et ce sans parler de systèmes ayant rendu l'âme ou n'évoluant plus (je pense à Compaq True64, Netware, SCO...).
Bref, dans le domaine IT, se former est aussi prendre un pari sur l'avenir selon les tendances du moment comme ses aspirations. En outre, parier sur Linux ne peut pas être un mauvais pari puisque cela ouvre aussi des portes côté Unix et tout un ensemble de technologies informatiques connexes (réseau, interopérabilité...).
Il s'agit ici de certification. Il est donc difficille d'y ajouter UNIX proprio et *BSD.
Mais je reste d'accord avec toi. Seule une connaissance conjointe Unix, *BSD et Linux présente aujourd'hui une valeur ajoutée sur le long terme. Cependant, cette connaissance ne peut être acquise qu'avec l'expérience et côté formation, il faut bien commencer quelque part.
Linux ne me parait pas être le plus "mauvais bout" :)
[^] # Re: Paris, Paris... Toujours Paris !
Posté par Quzqo . En réponse à la dépêche IP-formation : la formation administrateur Linux menacée. Évalué à 1.